Straight answers, before the call

No. OmniPath has no path to the SIS, ESD, fire and gas, or HIPPS. It writes setpoints to the regulatory control layer only.

No. The surge control line stays where your anti-surge vendor set it. We reduce how often the operating point approaches it.

No. Those controllers continue to run unchanged, at their existing scan rates, with their existing configuration. OmniPath operates a layer above them.

The watchdog times out and control reverts bumplessly to the incumbent controller at the last valid setpoint. Loss of OmniPath is a loss of optimization, not a loss of control. The failure mode is tested as part of commissioning and is repeatable on demand.

The constraint envelope widens automatically when a measurement degrades or drops out, and the policy becomes more conservative. We do not build any claim on measurement quality we don't have. Where flow or density quality is insufficient to place a defensible envelope, we say so and scope the pilot around it.

Historian tags — unit speeds, suction and discharge pressures and temperatures, flows where available, recycle valve positions, run status, ambient, fuel gas rate, gas composition where available. Read-only, one to two years of history for training, then a live read path. Shadow mode requires no write path at all.

We ask for high-rate data specifically. One-minute aggregates and aggressive historian compression remove exactly the valve movements that carry the recycle and throttling signal, which are the two things we are optimizing against. Worth checking your historian's compression deadbands before an export — it is a five-minute check that has saved projects a month.

No, and that is architectural rather than incidental. Inference and the hydraulic solver both run locally at the asset. Model updates arrive through the DMZ as signed artifacts on your schedule, and the site keeps running its current model if delivery is interrupted. Loss of connectivity costs you model updates and telemetry, never optimization.

Three reasons, none of them latency. The workload is a batched physics solver in a dynamic rollout — an 8-unit station with line pack is roughly 4.4 TFLOP per decision, and a coordinated three-station liquids line is 104 TFLOP. Second, that solver has to stay calibrated against high-rate local data; on a satellite-connected station, shipping it is not affordable, and a stale model solves the wrong pipeline. Third, a cloud optimizer writing setpoints needs a persistent path from the internet into your Level 3 zone on every cycle. We would rather not ask you to approve that, and most of you would not.

No, and it would not need a GPU if it were — the policy network is small enough to run on a CPU. The GPU does batched physics. Each decision screens thousands of candidate operating plans against a learned model, then verifies the best few against the real hydraulic solver across a model ensemble. That is the expensive part, it is embarrassingly parallel, and it is what a GPU is for.

Checked. The learned model screens the candidate space; the shortlist is then verified against the station hydraulic model before anything is written, and the verification result is logged alongside the action. If a candidate fails verification it is discarded. We would rather write the second-best plan we can prove than the best one we cannot.

For single-station optimization, no. Multi-station coordination benefits from neighbour state, and where it is available we use it. If a neighbour's telemetry goes stale or drops out, coordination degrades to single-station optimization rather than optimizing against a stale picture — the check is explicit and it is tested. A cloud-hosted coordinator would need every station connected simultaneously; at 99% availability each, five stations are jointly available only 95% of the time.

The calibrated hydraulic model keeps earning its place. It supports virtual flow metering where you have no meter, model-based fault detection, and independent corroboration of imbalance. Several of those address the same measurement gaps that force us to run a conservative envelope in the first place.

Ruggedized Jetson Orin–class compute in the safe-area or Division 2–rated control building, alongside the DCS and outside the classified envelope — the same reason your DCS has no hazardous-area rating. Sizing is set by measured solver throughput on your station's unit count and horizon, not by a catalogue number. Four connections: OT network, DMZ network on a physically separate interface, and 24 VDC. No process I/O, no field terminations, no marshalling.

Shadow mode is read-only and typically scopes as a monitoring addition. Supervisory setpoint writing is a change to the control narrative and goes through your normal MOC. We provide the scope-of-authority document, failure-mode analysis, and test procedure as pilot deliverables.

Shadow mode. The policy runs read-only alongside your operators and incumbent APC for months, and we report what it would have done against what actually happened, across seasonal ambient swings. You see the backtest and the live shadow record before anything writes a setpoint.

Discussed and fixed in the pilot agreement before any data moves. Your operating data remains yours in all cases.

In shadow mode, nothing happens and the disagreement is logged — those logs are the most valuable output of the pilot. In supervisory mode, the operator band constrains the policy, and the operator can take it off at any time from the HMI.