Pipeline Integrity Watch: Leak Detection, Fleet Health and Security Directive Evidence for Every Station

Every Station Speaks, Nobody Joins the Sentences

A transmission estate continuously produces the evidence of leaks, failing compressors and network intrusions, but it is scattered across systems that cannot be read together, so each risk is discovered late and evidenced by hand.

The abstract promised a living model of the pipeline estate that watches, explains and drafts while a person decides. Before that promise can be argued, the problem itself has to be stated precisely: what the operation needs to know each day, why the systems it already owns cannot say it, and what the regulatory regimes require it to prove.

1.1  The Question the Operation Needs Answered

A transmission estate asks the same four questions every hour, and each one is a join across data the operation already holds. Is this pressure and flow deviation a leak, or line pack responding to a ramp? Is this compressor unit drifting toward failure, or operating normally for its running hours? Is anyone unexpected inside the operational technology network at a station? And can the operation prove, on demand, that its security measures are in place and its alarm management plan is being followed? Answering the first question needs one-second pressure and flow telemetry along the line plus meter accuracy; the second needs vibration and discharge temperature joined to maintenance history; the third needs passive network traffic from the stations; the fourth needs all of the above held as evidence. The regimes that govern the answers are the United States pipeline safety rules under 49 CFR Part 192, including the alarm management requirements of 192.631 and incident reporting under Part 191, the computational pipeline monitoring practices of API RP 1130, and the transportation security directives that apply to hazardous liquid and natural gas pipelines. The design encodes rule versions as objects rather than hard-coding them, because the United States methane and pipeline leak rules changed status repeatedly between 2024 and 2026.

1.2  The Documented Cost of the Problem

The cost of discovering a fault late, rather than reading its early signature, is documented in public investigation records. A major United Kingdom energy company was fined after failing to properly maintain pipework for seven years, a lapse that led to a major hydrocarbon release (HSE 2025). A loss of primary containment at a United States liquefied natural gas facility traced back to instrument and procedural failures that the investigation report set out in full (DOT 2022). In a prosecuted case, the wall thickness of hydrocarbon-containing pipework deteriorated through a local corrosion mechanism until the pipework failed (HSE n.d.). These are the tail of the distribution, but the mechanism is ordinary: the evidence of deterioration exists in the data for a long time before anyone can read it, because it is scattered. For this operator the recurring cost is not the rare catastrophe but the daily one, evidence assembled by hand for every review, every audit and every security directive response, using hours of engineering time that produce no finding.

1.3  The Operation as a Scenario

The operator is a gas transmission operator in the United States, as its own requirement states, running a gas transmission estate of more than 3,000 miles of pipe, more than a dozen compressor stations, several gas control centers, and a compressor fleet of more than 100 units. The stations carry three generations of remote terminal units and programmable logic controllers on mixed backhaul: leased lines, licensed radio and intermittent cellular. Each station sits inside a hazardous area classification that constrains what may be installed and where. The people in the loop, by role, are the pipeline controllers who work shifts and own the detect, validate and initiate sequence for any leak alarm; the control engineer who signs the zone and conduit design; maintenance planners who turn diagnoses into work orders; the compliance owner who answers to the regulators; and the plan owner responsible for the security implementation plan the whole build must fit inside. The named systems the design reads are four systems of record: the historian, the alarm and event stream, the computerized maintenance management system, and the corporate identity directory. The places are the stations, the line between them, and the control centers where every decision finally lands.

Four Systems Each See One Slice of the Line

The historian, the alarm and event stream, the CMMS and the security tooling each hold a true but partial picture, and the question that matters most, whether this alarm is a leak, needs all of them at once.

Chapter 1 set out the question. This chapter explains why no system the operation already runs can answer it.

2.1  What Each System Sees

The historian: the CPM and fleet health models stand on the pressure, flow, vibration and temperature tags the operator already collects; the historian is the system of record for the line.

The alarm and event stream: the assistant must explain alerts in the context of the alarms controllers already see, and the 192.631 alarm management reviews need off-scan and inhibited-point records.

CMMS: the operator's single CMMS holds the maintenance records the fleet health models join to, and it is where a diagnosis becomes a work order with an owner and a due date.

Corporate identity directory: every console, the registry, the observability stack and the work surface log in through one identity realm federated to the operator's existing directory, so leavers lose access when the directory removes them.

2.2  What None of Them See Together

Each holds one slice, and the question needs all of them in one place at once, which today is done by hand at the cadence of whoever has the time.

The Hard Rules of the Line Shape Every Layer

No writes to field devices, passive listening only, open weights on premises and a controller who decides every action are not features to add later but constraints that fix the architecture before any component is chosen.

Chapter 2 showed four true but partial pictures that no manual effort can join at the speed of a control room. This chapter states the hard rules that shape every layer of the answer before any component is chosen, because in this industry the constraints are not features to add later.

3.1  The System Never Writes to a Field Device

The first rule comes from the operator's requirement in its own words: the system never writes to a field device. On a gas transmission estate, shutdown and control authority lives in certified control paths that have been qualified under the pipeline safety rules, and no analytics layer may sit inside that authority. This is hard in this industry because the commercially tempting design, an agent that closes a valve or trims a setpoint when its model is confident, is exactly the design the requirement forbids. The consequence is fixed early: the control room assistant drafts responses and a controller decides every action, and shutdown stays with the existing certified paths. Every interface to the operational technology side is therefore read-only by design, not by policy.

3.2  The Network Is Listened To, Never Probed

The second rule is passive monitoring. The stations run three generations of remote terminal units and programmable logic controllers on mixed serial and Internet Protocol links, and active scanning of such equipment carries real risk of perturbing legacy devices that were never built to be queried by strangers. So the operational technology network sensors listen on network taps and switched port analyzer ports only, decoding protocol traffic as it passes, never probing. The hardness here is coverage: passive protocol decoding can be blind on pure-serial segments with no Internet Protocol visibility, which is why a per-station visibility survey with a documented serial-gateway decision is a phase one workstream rather than an assumption.

3.3  The Weights Live on the Operator's Premises

The third rule is open weights on premises. The operator must own the models it depends on, on its own hardware, with no data leaving its boundary and no vendor able to withdraw capability. This is hard because the model market pushes the other way: most frontier capability is served from someone else's cloud under someone else's license, and some capable open-weight models are published by entities on the United States Entity List, an untenable provenance for a critical infrastructure owner. The design therefore commits to plain permissive grants, Apache-2.0 and MIT, with no field-of-use restriction, and treats license terms as a first-class selection criterion alongside accuracy.

3.4  A Controller Decides Every Action

The fourth rule is the human loop. Every alert the system raises competes for controller attention against a written alarm management plan with monthly reviews under 192.631, and alarm fatigue is a documented regulatory concern in its own right. The design answers by setting the alert budget before the thresholds: the assistant console is advisory and adds zero alarms to the existing stream, every assistant alert is counted in the annual plan review, and every model that could influence a decision runs in shadow mode beside the incumbent alarms before any controller-facing alert exists. The controller's detect, validate and initiate sequence for a leak alarm is preserved, not automated around.

3.5  Scoping Decisions and Their Costs

The constraints above force scoping decisions, and each buys something at a cost the operator accepts knowingly. Table 1 records the three that shape the most downstream structure.

3.6  What the Design Chose Against

Each major choice was made against a live alternative, and the reasons are recorded in Table 2 so they can be audited. The pattern that runs through them is the same: the operator keeps what it must own, and the design refuses anything that rents the layer back.

One Stack Runs From the Taps to the Consoles

A single layered stack carries every signal from passive network taps and field sensors through adapters into one object model, and back out to the services and surfaces the controllers and engineers actually use.

Chapter 3 fixed the constraints that shape everything downstream: open weights on the operator's own hardware, no writes to any field device, security directive evidence that generates itself from monitoring, and detection that keeps working when a station's backhaul drops. This chapter lays out the one stack that satisfies all four together, by settling once, at the bottom, how every signal enters and, at the top, who acts on it.

4.1  Bottom to Top, One Direction of Flow

The architecture is three layers with a single direction of flow. Below sit the systems of record the operator already runs: the historian holding the pressure, flow, vibration and temperature tags, the alarm and event stream the controllers already watch, the CMMS that owns the equipment master and the work orders, and the corporate identity directory. In the middle sits one object model, at version 0.9, which is the only layer that writes. Above it sit the applications and agents: ten services that do the monitoring, forecasting, detection and explanation, and seven surfaces where named people decide. Nothing replaces a system of record, and nothing above the model talks to anything below it except through the model.

The pattern fits a pipeline estate because such estates accrete systems over decades and cannot be swapped for a clean slate; the design reads each record where it stands. The layer split also carries the constraints directly. Read-only adapters honor the no-write rule at the boundary, and the single write path through the model is what makes the security directive evidence auditable: every record in it can be traced to the source event that produced it.

Figure 3 shows the layered stack with its counts: four sources, three adapter families, fourteen objects, ten services, seven surfaces and four models. Underneath runs the supporting spine: Apache Kafka 4.3.x in KRaft mode as the event backbone, InfluxDB 3 Core for time series, MediaMTX for video ingest, K3s for edge orchestration, Harbor as the air-gapped artifact and model registry, CVAT for labeling and retraining, linuxptp with chrony for time synchronization, Keycloak for identity, and Prometheus with Grafana and Loki for observability of the running system itself.

4.2  The Stack Stage by Stage

Table 3 walks the same stack stage by stage, and each stage names the components that carry it, so an engineer can read the figure and the table as one picture.

Fourteen Objects Turn Station Data Into One Argument

The object model gives stations, segments, compressor units, OT devices, alarms, leak events, work orders and security directive controls typed links, so a query can walk from a methane reading to the controller who confirmed it and the work order that closed it.

Chapter 4 carried every signal from the taps and sensors through the adapters into one object model. This chapter opens that model, names every object in it, and shows what the typed links let a query do that a document store cannot.

5.1  Fourteen Objects and Their Typed Links

The model holds fourteen objects. The sites are the compressor station, carrying station number, state, RTU and PLC generations, backhaul type and hazardous area classification reference, and the meter station as the measurement record, carrying set pressure, meter run and remote telemetry type; the two are kept separate because they anchor in different systems and are reconciled by link rather than by merge. The assets are the pipeline segment, with maximum allowable operating pressure, diameter and wall thickness, class location, inline inspection assessment date and high-consequence-area flag; the compressor unit, with type, running hours, last overhaul date, vibration and temperature points and mean time between failures; and the OT device, with device class, vendor and firmware version, address, approved logic fingerprint and last-seen time. The actor is the pipeline controller, with shift, qualification and roles in normal, abnormal and emergency conditions. The events are the alarm, the leak or abnormal operation event and the remote access session. The records are the work order and the security directive control. The systems are the historian and the CMMS. The document is the hazardous area classification.

The typed links join them into one argument. A station links to its hazardous area classification and hosts its OT devices; compressor units link to the stations they run at; an alarm escalates to the leak event it raised; a leak event links to the controller who confirmed it and to the work order that closed it; work orders link to the CMMS record that holds them; remote access sessions link to the OT device they reached. Figure 4 draws every object and every link, with the leak event in focus as the object the argument turns on.

That focus is what a query can reach. Starting from a methane reading at a station, a query walks to the station's hazardous area classification, to the CPM alarm record, to the controller who confirmed the event, to the work order with its owner and due date, and to the regulatory report reference, in one traversal. A document store returns whatever matches the words of a search; it cannot walk a typed link, so the same argument has to be reassembled by hand each time. The link from a diagnosis to an owned work order exists because pipework left unmaintained has failed through local corrosion in prosecuted cases (HSE n.d.), and a major hydrocarbon release from exactly that neglect drew a fine in a recent prosecution (HSE 2025).

5.2  The Human Loop and the Hosting Posture

The human loop lives at the objects with owners. The pipeline controller confirms or clears each leak event and decides every action the assistant drafts; each work order carries an owner and a due date; each security directive control carries an owner and its gap statement. The hosting posture keeps the loop inside the operator's boundary: everything runs on premises in the gas control centers and at the stations, no data leaves that boundary, identity flows through Keycloak federated to the corporate directory so leavers lose access the day the directory removes them, and there are no external links. The only write path in the whole design is the object model fed by the adapter tier, and no path to a field device exists anywhere in it.

5.3  One Object in Its Recorded Form

The leak or abnormal operation event is recorded with its detection method, estimated rate and location, CPM alarm record, confirming controller, work order and regulatory report reference, and its status moves through detected, under investigation, confirmed, cleared as non-leak and repaired.

{ "id": "compressor-station", "label": "Compressor Station", "kind": "site", "anchored_in": "CMMS", "properties": [ "Station number", "State", "RTU and PLC generations", "Backhaul type (leased line, licensed radio\u2026", "Hazardous area classification reference" ], "status_vocabulary": [], "links": [ { "to": "pipeline-segment", "label": "carries" }, { "to": "ot-device", "label": "hosts" }, { "to": "hazardous-area-classification", "label": "classified by" }, { "to": "compressor-unit", "label": "runs" } ] }

Four Sources, Three Adapters, No Direct Access

Every source system enters through one of three adapter families that guarantee provenance, ordering and read-only behavior, and nothing ever reads a field device directly.

Chapter 5 opened the object model and its typed links. This chapter describes how data gets into it: four sources, three adapter families, and no direct access to anything.

6.1  The Sources and Their Provenance

Four named source systems feed the model, all read only. The historian is the system of record for the line, holding the pressure, flow, vibration and temperature tags the CPM and fleet health models stand on; its provenance class is the operator's own. The alarm and event stream is the set of alarms controllers already see, plus the off-scan and inhibited-point records the alarm management reviews need; also the operator's own. The CMMS holds the equipment master and the work order history the fleet health models join to, and it is where a diagnosis becomes a work order with an owner and a due date; the operator's own. The corporate identity directory is domain-typical, the identity realm an operator of this size already runs, federated so that access ends when the directory ends it. Figure 5 maps each source, its provenance class and its adapter path into the model.

6.2  What the Adapter Tier Guarantees

Three adapter families carry the four sources. The Telemetry adapter takes historian tags and sensor streams; the Ops systems adapter takes the alarm stream and the CMMS; the Integration adapter takes the identity directory and the evidence sources behind the security directive record. The tier guarantees five things. Every event carries a provenance stamp naming its source system, its adapter family and its extraction time. Connections are read only, with credentials scoped to read at the adapter. Ordering is preserved from source to backbone. No adapter ever addresses a field device: signals arrive from the historian's open APIs, with OPC UA and MQTT where IP links exist, and from the passive taps, never by probing the RTUs and PLCs. Each feed is translated into the object vocabulary, so services never see a raw tag name, and backpressure is absorbed at the adapter so a slow consumer never stalls a source.

6.3  The Event Backbone

The backbone is Apache Kafka 4.3.x in KRaft mode, which needs no separate coordination service. Ordering holds because producers key events by station and tag, so each station's events keep their sequence within a partition even when a station resynchronizes after hours of lost backhaul. Delivery is at least once, made safe by idempotent writes keyed to the source's own sequence number, so a replay after a reconnect cannot double-count a reading. Buffering lives on the station edge nodes as store-and-forward queues sized for the agreed survival window at the measured message rate, doubled, and every display and every assistant answer marks data that arrived through the buffer as stale. Replication runs in the control center cluster, so the loss of a node costs no evidence. Model and container artifacts enter through the Harbor registry by a separately approved change path under management of change, never back through the one-way path out of the OT zone.

Detection Lives at the Station, Reasoning in the Center

Forecasting and camera detection run on station edge hardware sized to survive backhaul loss, while the frontier assistant and retrieval models run in the control center, and only telemetry and evidence cross the one-way boundary.

Chapter 6 described how every source enters through an adapter and lands on the event backbone. This chapter decides where the four models actually run, and one physical fact settles most of it: the stations sit on intermittent cellular backhaul, so anything that must keep working when the link drops has to run where the data is born.

7.1  Two Tiers, Each with Its Own Arithmetic

The edge tier lives in the station cabinet. Chronos-2 forecasts the pressure, flow, vibration and temperature tags and thresholds its residual for anomaly; at about 0.48 GB of weights at 32 bit, or about 0.24 GB at 16 bit, it leaves most of the station edge module's memory free. RF-DETR watches the cameras for the compressor package, gas plume, person, service truck, vent event and hot spot classes; the Apache-licensed Nano to Large checkpoints occupy about 61 to 68 MB at 16 bit, and the 2XL size about 254 MB. Both are served by Triton Inference Server on K3s, on volume-production modules in 7W to 60W envelopes chosen by thermal envelope rather than part number, and both keep detecting through backhaul loss. That offline survival is why they sit at the station: deterioration of containment pipework progresses locally and silently between maintenance rounds until the pipework fails (HSE n.d.), and continuous local signatures are what catch it.

The central tier lives in the control centers. Mistral Large 3 675B (Instruct), the frontier model behind the control room assistant, the compliance agent and the work surface, publishes at FP8 as about 682 GB of weights, which fits a single node of eight 141 GB HBM-class GPUs with headroom for serving overhead; the NVFP4 build of the same model fits a node of 80 GB HBM-class GPUs. BGE-M3 runs beside it for retrieval at about 1.1 GB at fp16, negligible against the same node. Figure 6 sets the two tiers side by side, with what runs on each and what crosses between them.

7.2  The Latency Budget Is Ordered by Who Waits

Three loops carry three budgets. The station loop closes entirely on station hardware, so camera detections and forecast residuals arrive at the speed of the local models, never at the speed of the link. The control room loop is conversational: a controller asks the assistant to explain an alert, retrieval and generation run on the central node, and the answer lands in the time a person reads a screen; the console is advisory and adds zero alarms to the HMI, so every new alert is counted inside the alarm management plan reviews required by 49 CFR 192.631(e) rather than competing outside them. The evidence loop is batch: security directive evidence, ontology maintenance and compliance records generate on schedule, not on demand. Stale data is marked on every display and every answer, so a controller never mistakes a store-and-forward replay for a live reading.

7.3  One Way Out, One Approved Path In

Only telemetry, detections, forecast residuals and evidence records cross the boundary, through a hardware-enforced one-way diode out of the OT zone with no return path to misconfigure. Model updates never travel that conduit: they enter through a separately approved change path under management of change, pulled from the air-gapped Harbor registry. When the link fails, station buffers sized for the agreed survival window at the measured message rate, doubled, hold everything until the connection returns, and every display marks what is stale. When power fails at a station, detection stops with the station, and the gap in the record is itself visible in the observability stack. When the update path fails, the station keeps running its last approved weights and flags the version skew, and Prometheus with Grafana shows the divergence until the change is resynchronized. Leak-relevant detection never depends on any of these paths, because a loss of primary containment at a single facility can escalate in minutes (DOT 2022).

Open Licenses Put the Weights in Operator Hands

Four open-weight models carry the design, each chosen for what its license permits a United States critical infrastructure owner to hold outright, from the frontier work surface to the edge forecaster and the camera detector.

Chapter 7 placed each model at its tier and did the memory arithmetic. This chapter examines the four models as licenses first and engines second, because for a gas transmission operator in the United States, the deciding question is not which model is strongest but which weights the operator can hold outright on its own premises.

8.1  Four Models, Four Jobs

Figure 7 stacks the four models over the ground they run on, from the station cabinets to the control-center node. Mistral Large 3 675B (Instruct) is a 675B-parameter mixture-of-experts model published at FP8, about 682 GB of weights, fitting a single node of eight 141 GB HBM-class GPUs. Its role is the agentic work surface and ontology maintenance: it runs the control room assistant, the compliance agent and the work surface entirely inside the control centers. Its license is Apache-2.0, a plain grant with no field-of-use restriction and no Entity-List exposure, and that is precisely why it was chosen over GLM 5.3 open weights, whose publisher sits on the US Entity List, an untenable provenance for a United States critical infrastructure owner.

Chronos-2 does zero-shot multivariate and covariate-informed forecasting on the pressure, flow, vibration and temperature tags, with the residual thresholded for anomaly. It weighs about 0.48 GB at 32 bit and about 0.24 GB at 16 bit, is Apache-2.0 licensed, and runs on the station edge boxes so detection keeps working through backhaul loss.

RF-DETR carries station camera scene detection. Only the Apache-2.0 sizes are used: the Nano to Large checkpoints at about 61 to 68 MB at 16 bit and the 2XL size at about 254 MB, published at BF16. It is fine-tuned on the operator's own site footage with CVAT for the six detection classes, exports to the edge NPU, and the exact version is pinned so the Plus sizes under PML 1.0 never enter the air-gapped registry.

BGE-M3 provides retrieval embeddings for maintenance history and procedure search. It is MIT licensed, carries an 8K context window, and produces hybrid dense and sparse retrieval from one pass, which keeps tag names, error codes and part numbers findable where pure dense embeddings lose them. It weighs about 2.27 GB at FP32, about 1.1 GB at fp16 and about 0.6 GB at 8 bit, and runs beside the work surface in the control center.

8.2  The Register Behind the Choices

Table 4 gathers the decisions this chapter and Chapter 7 stand on: one row for each model, then the hardware classes and sizing rules, the sensing, the patterns the design stands on, and the ground the whole stack runs on.

Shadow Mode Comes Before Any Flag Is Trusted

A two-phase rollout puts the pilot stations through an API RP 1130 computational pipeline monitoring gate and requires every decision-influencing model to run beside the incumbent alarms before any controller-facing alert exists.

Chapter 8 settled the four models and the licenses that let the operator hold its own weights on its own hardware. This chapter sets the order in which the build reaches the estate, the gate that can stop it cheaply, and what has to be measured before any controller-facing alert exists.

9.1  Two Phases, One Gate and Full Coverage

Figure 8 shows the whole path. Phase 1 carries 16 items across six workstreams: the data foundation, OT network monitoring, compressor fleet health, line leak detection, the control room assistant, and the phase one pilot that binds them at the pilot stations. Its single exit gate is API RP 1130, the recommended practice that governs computational pipeline monitoring: the line leak detection workstream does not leave the phase until the sensitivity-versus-false-alarm test has been run for each segment and the per-segment detectable limit has been written down as an acceptance test. Phase 2 carries one item, the fourteen station fleet rollout, and inherits every phase one artifact unchanged: the fourteen object model, the adapters, the agentic memory and the monitoring console. Requirement coverage closes at three requirements covered, none partial and none open: passive OT monitoring with self-generating TSA security directive evidence, compressor fleet health from vibration and performance data, and leak and abnormal operation detection with the assistant that explains each alert and drafts the response.

9.2  What the Rollout Measures

The pilot measures four things. First, the per-segment detectable limit, from the sensitivity-versus-false-alarm tests, so every controller knows what mass balance can and cannot see. Second, shadow agreement: every model that could influence a decision runs beside the incumbent alarms, and what is counted is agreement and disagreement against the record controllers already trust, not a claimed accuracy. Third, alarm load: the assistant console is advisory and adds zero alarms to the HMI, and every assistant alert is counted in the monthly review the alarm management plan already requires. Fourth, work order conversion: how many model-raised diagnoses the CMMS work orders confirm, because deferred maintenance is how contained pipework becomes a release, as the corrosion failure behind a prosecuted hydrocarbon case shows (HSE n.d.) and as the fine that followed seven years of unmaintained pipework confirms (HSE 2025).

9.3  Failure Modes

Table 5 states what fails and what the design does about each; the two most consequential are the physics of mass balance and the fragility of old serial links.

9.4  Lessons

Shadow the flags before anyone trusts them. A controller-facing alert exists only after the shadow record against the incumbent alarms justifies it, and the same rule applies to the health models and the camera detections: nothing crosses from the machine to the console on the machine's own testimony.

Set the alarm budget before the thresholds. Every new alert competes for controller attention under a written plan with monthly reviews, so the budget is fixed first and the thresholds are tuned into it, not the other way round.

Sign the boundary with the control engineer, not only IT. The OT and IT zone-and-conduit sketch is a phase one deliverable signed by the control engineer, because the person who owns the stations, not the person who owns the firewall, knows what a mistake there costs.

9.5  What Is Still Open

The station inference server class, the camera class, the enclosures, site networking, positioning and the frontier cluster class all stand as open class decisions, chosen by thermal envelope and duty rather than part number; settling the camera class would fix detection latency at the fence line, and settling the inference server class decides whether the work surface shares a node with the retrieval stack. The backhaul survival window is an agreed number still to be fixed, and it sizes the store-and-forward buffers. The US methane and pipeline leak rule versions changed status repeatedly between 2024 and 2026, so rule versions are encoded as objects and repair timelines follow the operator's compliance team; settling a rule version would let the evidence record carry firm dates instead of objects. A loss of primary containment at a gas handling facility shows why detection quality is worth this patience (DOT 2022).

The Operator Owns the Models, Record and Boundary

Everything the design builds, from the object model and the fine-tuned weights to the decision record and the station boundary, remains the operator's property and stays inside its own security plan.

Chapter 9 set the phases, the gate and the measurements. This chapter settles the question the operator asked at the start: when the rollout is finished, whose is it.

10.1  What the Operator Holds

The object model is the operator's: fourteen objects, from the station and the pipeline segment to the security directive control, with their typed links, their status vocabularies and the hazardous area classification document they anchor to, held in the operator's own store on its own hardware. The weights are the operator's: Mistral Large 3 675B, Chronos-2 and the RF-DETR Apache sizes sit under Apache-2.0, and BGE-M3 under MIT, licenses with no field-of-use restriction, so the fine-tune on the operator's own station footage and the residual thresholds tuned on its own telemetry are property it can keep, move or retire without a vendor's consent. The decision record is the operator's: every confirmed leak event, every controller response, every cleared non-leak and every deferred work order is a kept object the next decision reads, and it is never used to update model weights. The boundary is the operator's: the hardware-enforced one-way path out of each station OT zone, the identity realm federated to the corporate directory, and the evidence record scoped to the measures the operator's own security plan states, with the operator retaining sole responsibility for compliance even where operation is delegated. The system never writes to a field device, and shutdown stays with the certified control paths, so what the operator owns is intelligence, not control.

10.2  The Offer Behind the Design

CodeNinja designed this system on CodeNinja Praxis, its platform for designing physical AI systems, and the design maps directly onto what CodeNinja builds: the passive OT monitoring, the compressor fleet health models, the tested computational pipeline monitoring and the methane and camera sensing at the highest risk stations are Adaptive Operations; the control room assistant that ranks, explains and drafts a response for a named controller to decide is Decision Systems; the fourteen object model is Hyper Ontology; the surface on which the operator's controllers and engineers build their own agents over that model is Hyper Pragma; the kept record of decisions and outcomes that the next decision reads is Hyper Engram; the own hardware, the open-weight licenses and the in-country, premises-bound operation are Sovereign Infrastructure; and the design itself, with its recorded reading and its eight lenses, was produced on Praxis.

One Read-Only Model of the Line, Owned Outright

The design is a single argument assembled from an estate's own signals: passive OT taps, compressor vibration and temperature, line pressure and flow, methane sensing and cameras at the highest risk stations, all landing in one object model from which detection, fleet health, control room explanation and security directive evidence are all read. Every layer of it runs on hardware the operator owns, under licenses that let the operator hold its own weights, with a one-way boundary out of every station zone and no write path to any field device; the assistant drafts and explains, and a controller decides.

Running the same shape elsewhere takes three things the estate already has: systems of record worth reading, stations where passive taps and diodes can be fitted without touching control logic, and people accountable for the alarm plan and the security directive evidence who will own the thresholds and the record. The stack, the object model, the adapter discipline and the placement rules travel; the ontology is re-anchored in the new operator's own stations, units, segments and rules, and the first gate stays cheap because shadow mode comes before any controller ever sees a flag.

How Praxis Contextualized and Reasoned This Design

Every design in the series is produced on Praxis, and this chapter records the ask, the reading and the eight lenses so any choice in the paper can be traced back to what justified it.

Chapter 10 established that everything the design builds stays with the operator. This final chapter records how the design itself was reasoned, so any choice in the paper can be traced back to what justified it (Figure 9). Every design in the Vertical-Driven Architectures series is produced on Praxis, the design team platform for designing physical AI systems. This chapter lists what was asked, what was read, and what each of the eight lenses contributed, and it closes on where the reasoning lands.

11.1  Contextualizing the Ask

The ask, in the operator's own words, was passive OT network monitoring at the stations and the gas control centers with TSA security directive evidence generated from the monitoring, compressor fleet health from vibration and performance data, leak and abnormal operation detection from pressure and flow plus methane sensing and cameras at high risk stations, and a control room assistant that explains alerts and drafts responses for a controller to decide, never writing to field devices, under PHMSA and TSA rules, with open weights on premises. Praxis assigned the design to the Physical AI family and the Oil and Gas industry, with the country placed by the operator's own requirement. The room held 1401 records; 119 were read in full during the design and the remaining 1282 are available on request.

11.2  The Lenses

Table 6 records all eight lenses, what each could see, how many records each cited, and what each contributed to the finished design.

11.3  Patterns Adopted and Set Aside

Three patterns were adopted. System of Context stands as the primary architecture, because the people who act on the system work over the ontology and the memory rather than through a reporting layer. The one-way path out of the OT zone, hardware-enforced, bounds the blast radius by architecture rather than by policy. Edge-first reasoning fixed the two lists: what must survive a disconnected station, and what never leaves the site. Set aside, with reasons recorded: active scanning of field devices, which the requirement forbids and which would perturb three generations of RTUs and PLCs; a bidirectional firewall conduit, which leaves a return path to misconfigure; GLM open weights, whose publisher sits on the US Entity List; packaged asset performance products, which rent the layer this engagement exists to hand over; and central-only analytics, which dies with the backhaul.

11.4  Where the Reasoning Lands

The reasoning lands on equipment classes rather than part numbers: edge compute enclosures rated for hazardous areas, the one-way path out of an OT zone, the data diode transfer class, and the rule for when inference belongs at the edge, each chosen by thermal envelope and duty. The station inference server, the cameras, the enclosures, site networking, positioning, time synchronization hardware and the frontier cluster remain open class decisions, recorded as such rather than filled by inference. Everything shown in this paper, from the stack to the phases to the failure modes, was recorded reading; nothing is inferred.