Visit a typical distributed bioenergy site and you’ll find a particular kind of operator workstation. There is a digester SCADA from one vendor. A CHP control panel from another. A greenhouse climate controller from a third. An interconnection meter from the utility. And — almost always — a spreadsheet on a second monitor that the operator uses to actually decide what to do.

That arrangement works at one site. It does not work at ten sites. It does not work at a hundred. And it is, in our view, the single largest reason distributed bioenergy has stayed niche.

Aurixen OS is what we built instead.

What “operating system” means here

We use the term operating system deliberately. Aurixen OS is not a SCADA. It is not a dashboard. It is not an MES. It is the software substrate that runs an Auric™ node — meaning it is the layer that knows about every subsystem at the same time, and is the layer the rest of the platform’s software depends on.

Concretely, Aurixen OS sees:

• Pulse™ digester state — temperature, mixing rate, gas production, substrate composition
• ExerGen™ state — load, electrical output, jacket water temperature, exhaust composition
• Greenhouse state — temperature, humidity, CO₂ concentration, nutrient solution chemistry, lighting schedule
• Grid intertie — local frequency, exported power, interconnection status
• Markets — electricity price, RNG/RIN price, weather forecast, feedstock logistics schedule

It sees all of them in the same data model. That sentence is doing a lot of work, so let’s unpack why.

The fragmentation problem

The reason a normal site needs a spreadsheet is that each vendor SCADA has its own data model, its own tag naming, its own alarm semantics, and its own definition of “the value of running right now.” When the operator has to decide whether to throttle the CHP to push more biogas into the RNG upgrader, they have to read three screens and do math in their head.

That math is exactly the math Aurixen OS does automatically, on a one-minute economic loop, with a unified data model under it.

The data model is what makes the fleet behavior possible. When Node Two comes online in 2027, it will not require a custom integration. It will speak the same data model as Node Zero, expose the same KPIs to the fleet layer, and be operable from the same console.

Three layers

Aurixen OS is architected in three layers, by design.

Edge layer

On-site industrial controllers and a hardened compute node run the 1 Hz physical control loop. This layer is where safety-critical interlocks live — emergency shutdowns, overpressure handling, gas-leak detection. The edge layer is designed to keep the node safe with zero network connectivity. If the WAN goes down, the node continues to operate within safe envelopes for as long as feedstock is available.

Node layer

Per-site state, telemetry buffering, recipe execution, and the operator HMI. The node layer is where the “single pane of glass” lives. It is also the layer that speaks the unified data model upward to the fleet layer, regardless of what hardware lives below it. Vendor swap-outs become straightforward: replace a Modbus driver, the rest of the stack doesn’t care.

Fleet layer

Multi-node aggregation. Performance dashboards, fleet alerts, software updates, and the historical store that feeds Auric DT™ and Auric AI™. The fleet layer is what makes a single operator able to be responsible for many nodes — not because the operator is being asked to context-switch faster, but because the layer presents a coherent fleet-level picture and surfaces the one or two nodes that need attention right now.

Auric AI lives inside, not above

It is worth being precise about Auric AI’s role. AI is not a separate product sitting on top of Aurixen OS. It is a subsystem inside Aurixen OS — a set of forecasting and optimization models that the OS calls when it needs a prediction about biogas yield, ExerGen output, or hourly RNG vs. electricity routing.

Authority remains with the OS, and ultimately with the edge layer. AI recommends. The OS decides. The edge layer enforces safety. This separation matters because it is the difference between a system you can audit and a system you can’t.

Why we wrote it ourselves

We considered the alternatives. There are industrial control platforms that handle parts of this. There are MES products that handle other parts. There are cloud SCADA products that integrate parts of it. None of them — in our review — make a single operator responsible for an integrated bioenergy + agriculture node a tractable job.

That is the bar Aurixen OS is built against. Not “be a better SCADA.” Be the operating layer for an Auric node, such that node operations can scale with software rather than headcount.

We’ll write more about Auric AI’s controller behavior — and how we keep it explainable and overridable — in a later post.