Sovereign HSE Watch: Predictive Risk and Early Warning on an HSE Control and Command Platform

HSE Risk Emerges Before Any System Sees It

In oil and gas the precursor signals of a major HSE event already exist across incident records, process sensors, cameras and files, and investigations from Texas City to Macondo show the cost of assembling them too late.

The abstract stated the assembly: eight source systems, four adapter families, twelve ontology objects, five services, four surfaces and six models, all inside one sovereign boundary. This chapter establishes why that assembly is the minimum the problem demands, what the operation needs to be able to answer, and what the public record shows it costs when the answer arrives after the event.

1.1  The Question and the Data It Requires

The question the HSE department needs answered is not whether an incident occurred but whether risk is emerging now, where it is concentrating, and what action would arrest it. Answering it requires joining incident, near miss, corrective action and inspection records with continuous process measurements, fire and gas detector readings, camera detections of workers, vehicles, hard hats, flame, smoke and zone breaches, and the scanned paper history that predates every digital system. It also requires the governance corpus itself: internal policies, procedures, standards and risk criteria, read together with the external frameworks the operator is measured against.

The regulatory ground has three layers. National HSE regulation in Pakistan applies at every site. Industry practice sets the measurement standard: the International Association of Oil and Gas Producers defines, in its Report 456 recommended practice, the process safety performance indicators upstream companies should use to manage process safety (Veiligheidvoorop 2018). Prescriptive codes such as OSHA and NFPA govern specific hazards, and the duty to prevent major accidents and limit their consequences is codified for dangerous substances in the UK's Control of Major Accident Hazards Regulations (HSE 2015). A platform that cannot cite the clause it judged against cannot support compliance monitoring, so the governance corpus enters the design as a source system, not as background reading.

1.2  The Documented Cost

The public record prices the failure to join precursor signals. At Texas City in March 2005 an explosion and fire killed 15 workers and injured 180; the US Chemical Safety Board found a safety culture leaning on lagging injury metrics while process safety indicators worsened out of view (CSB 2005). Five years later the Deepwater Horizon explosion at the Macondo well killed 11 workers, injured 17 and caused serious environmental damage, with warnings again distributed across systems and organizations (CSB 2010). That same year a heat exchanger at the Tesoro refinery in Anacortes ruptured and killed seven workers after a known damage mechanism went untracked as a live risk (CSB 2010b). Where no one dies, regulators still price the gap: the UK regulator fined Esso one million pounds after a structural collapse released around 2,400 kg of highly flammable liquefied petroleum gas at Fawley, and fined Shell UK 560,000 pounds for a major hydrocarbon release traced to poorly maintained pipework (HSE 2026; HSE 2025). Each is a join failure: the readings, the history and the governing standard all existed, and no single view assembled them in time.

1.3  The Operation as a Scenario

The operation is an oil and gas operator in Pakistan running an upstream exploration and production business: a gas processing plant with classified process areas, dispersed wellhead pads, a workshop and its gate, control room operator desks and site overview coverage. The physical environments differ in hazard character: the process area concentrates hydrocarbon risk, the wellhead pads are remote and exposed, and the workshop concentrates vehicle and human activity. The camera estate spans these location classes, and the detections in scope are worker presence, hard hat compliance, vehicle movement, flame, smoke and zone breach.

The people in the loop, by role, are HSE department leadership who own the risk-based view, site HSE supervisors who receive alerts and approve actions, investigation leads who reconstruct events, control room operators who act on real-time warnings, maintenance engineers who close the loop into equipment records, and executive management who read the consolidated picture. The design holds this scope in fixed counts: eight named source systems, four adapter families, twelve ontology objects, five services, four surfaces and six models, arranged in three rollout phases carrying seventeen items against twelve recorded requirements. Several operating sites sit inside the boundary, and every place is described by class, never by name.

Every Enterprise System Sees One Slice of Safety

Incident management, process control, fire and gas detection, cameras and file archives each hold one true slice of the operation, and the cost of the problem lives in the seams between them.

Chapter 1 established the question, the data it requires and the price of joining them too late. This chapter walks the existing systems one by one and shows the slice each holds; Figure 2 sets the slices side by side.

2.1  What Each System Sees and What It Misses

SAP EHS, PM and QM anchor the record side. They see incidents with severity and status, work orders and the equipment master, and inspection and audit findings with their checklists. They miss the live plant entirely: nothing in an incident record says what the process tags did in the hour before, what the detectors read, or what a camera faced at the moment of the event.

SCADA and its historian see the process itself, tag by tag at high frequency. They miss the HSE meaning of what they carry: a pressure excursion is a number, not a precursor, until someone connects it to the barrier that failed and the near miss reported last month. The fire and gas system sees the highest-consequence signals, detector readings and alarms. It misses everything around the alarm: the equipment's maintenance history, the people in the zone, and the procedure that governs the response.

The Vision AI estate sees people, vehicles and zone breaches frame by frame. It misses asset identity and history: a detection lands as a clip and a timestamp with no link to the work order, the open corrective action or the clause of the standard that was breached. The SQL databases see structured relational HSE data that sits beside the enterprise suite; the flat files and scanned records see the deep history, digitized but unstructured, unreadable by any model until it passes through OCR. Both miss the live plant. The identity provider sees who the people are and what roles they hold, without seeing anything they did.

2.2  What None of Them See Together

What none of them see together is one chronology: a detector alarm, the process tags in the minutes around it, the camera's view of the zone, the equipment's maintenance and inspection history, the corrective actions still open from the last similar event, and the clause of the internal standard or external framework that defines what should have happened. Building that chronology by hand is what investigations do today, after the fact; that is why lessons arrive after the next event, why near miss patterns stay invisible until they become incidents, and why a risk-based view of performance has to be assembled manually for every management review. Figure 2 shows each system's slice converging on the question none of them can answer alone: which risk is emerging, where, and what action arrests it.

Four Constraints Shape a Sovereign HSE Design

Data residency inside the operator's infrastructure, ownership of the model layer, an alert volume supervisors can actually absorb, and a first gate that can stop the work cheaply fix every downstream choice.

Chapter 2 showed that every source holds one true slice and that the value of the design lives in the join. This chapter fixes the four constraints that decide how the join may be built, then records what the design scoped in, what each scope decision bought and cost, and what it chose against.

3.1  Data Residency Inside the Boundary

The first constraint is that every weight, embedding, video frame and audit log stays on the operator's own infrastructure inside Pakistan, the requirement the ask itself states. This is hard in this industry because HSE data spans the information technology and operational technology sides of the plant, video is voluminous and personally sensitive, and the convenient path, a hosted AI API, would move exactly the material the sovereignty requirement protects out of the boundary. Residency also has a procurement dimension: the high-memory accelerator class the frontier tier needs is export-controlled for delivery into Pakistan, so the constraint shapes not only the architecture but the purchasing path, which the design names openly rather than working around silently.

3.2  Ownership of the Model Layer

The second constraint is that the operator owns the model layer, and licenses decide what it may own. A detector released under a copyleft license would force source disclosure of the whole serving stack, which a closed sovereign platform cannot accept; a language model whose license triggers on hosted service review may be perfectly lawful for purely internal use on-premises. The design therefore records, for every model, its license, its trigger conditions and why those conditions permit the operator to hold the weights. This is hard because license terms change between versions and checkpoints of the same model family, so the register names the exact checkpoints in the serving path, not just the model family.

3.3  An Alert Budget Supervisors Can Absorb

The third constraint is that detection produces more than humans can treat seriously. Anomaly detection on noisy sensor streams and continuous camera inference will fire far more often than a site supervisor can absorb, and alert fatigue quietly kills adoption before any model quality problem would. The design negotiates an alert budget with HSE supervisors before any threshold is set: everything below the budget enters a ranked queue rather than an alarm channel, and time to acknowledge, ignore rate and action rate are reported from the first week so the budget is managed as a live number, not a one-time setting.

3.4  A First Gate That Can Stop the Work Cheaply

The fourth constraint is that the first phase must be able to stop the work cheaply if the ground does not hold. Phase one reconstructs one real week of HSE history from the named sources, and its gate measures capture cost and OCR illegibility rates as real numbers before any digitization pipeline is priced; if degraded scans cannot ground the assistant, the design stops or rescores there. The same gate verifies that the operator's infrastructure can hold the frontier node class, so both the data question and the capacity question are settled at the cheapest point in the program.

3.5  Scoping Decisions

Three scope decisions fix the shape of everything downstream. Table 1 states each with what it buys and what it costs.

3.6  What the Design Chose Against

Table 2 records the choices the design made against, with the reason for each, ending with what sits outside the baseline altogether.

One Stack Runs From Systems of Record to Control Room

A system of context pattern places the systems of record below, one living HSE ontology in the middle, and the detection, prediction, assistant and agent applications above, all on the operator's own hardware.

Chapter 3 fixed the constraints that bound this design: the platform runs entirely on the operator's own infrastructure inside Pakistan, every decision stays with a named person, no system of record is replaced, and the first gate can stop the work cheaply. Constraints do not choose technologies; they choose a shape. This chapter states that shape, explains why it fits an HSE problem that is fundamentally about joining data rather than generating it, and then walks the stack stage by stage so an engineer can place every named component.

4.1  Systems of Record Below, One Ontology in the Middle

The design follows a system of context pattern. At the bottom sit the systems of record where HSE truth already lives and stays: SAP EHS, PM and QM for incidents, work orders, equipment master and inspections; the SCADA historian for process tags; the fire and gas system for detector readings and alarms; the operator's identity provider for who may see and approve what; and the relational databases and file archives that hold the long tail of HSE records. These systems remain authoritative. The platform reads them continuously and writes back along one governed path only: an approved recommendation recorded into SAP as the owning system. In the middle sits one object model, a living HSE ontology of twelve typed objects that Chapter 5 defines. Above it sit the applications the ask calls for: anomaly detection, forecasting, a cited natural-language assistant, dashboards and an agent work surface, all consuming ontology state rather than raw extracts.

The pattern fits because the stated problem is fragmentation, not absence: the data exists across enterprise systems, databases and manual files but cannot be joined, so emerging risks surface late and lessons from past events fade before they change practice. Extract-and-copy integration would multiply copies and let them diverge; the ontology joins in place, carries provenance on every object, and admits a new source by mapping it rather than rebuilding the model. Figure 3 shows the layered stack with the named component count at each layer: eight sources, four adapter families, twelve objects, five services and four surfaces, all on operator hardware.

4.2  The Stack Stage by Stage

Table 3 walks the same stack in data-flow order: a physical signal enters through sensing, crosses an adapter, lands on an ontology object, is enriched by inference, is exposed by a service, and reaches a named person through a surface. Reading the table top to bottom is reading one gas detection from sensor to decision. Two stages deserve emphasis. The inference stage names the models that Chapters 7 and 8 place and size in full: detection and tracking at the site edge, forecasting on the historian streams, embeddings and document parsing beside them, and a frontier language model on the central tier for assistant and agent reasoning. The services stage carries the five named services, each a governed capability with an owner, not a directory of dashboards.

Twelve Objects Turn Fragmented HSE Data Into One Argument

Twelve typed objects, each anchored in the system where its truth already lives, let one query reach from a gas detector reading through the incident it preceded to the corrective action it eventually justified.

Chapter 4 placed one object model at the middle of the stack and promised twelve objects. This chapter defines them: what each object holds, how typed links join them into one traversable argument, where the human approval loop lives, and one object exactly as the platform records it.

5.1  Every Object and the Links Between Them

The twelve objects fall into five kinds. Sites and assets: facility, the operating site with its area classification and shift pattern, and hse_equipment, safety-relevant equipment anchored in SAP PM with criticality and running hours. Records: hse_incident anchored in SAP EHS, near_miss with its potential severity and failed barrier, corrective_action with owner and closure evidence, and inspection_record anchored in SAP QM. Documents: hse_document, any policy, scan or report with its OCR status. Measurements and events: sensor_reading anchored in the SCADA historian, anomaly_event raised by a detection model, and agent_recommendation raised by an agent. People and authority: hse_person and hse_role, both anchored in the operator's identity provider. Every link is typed and directed, as Figure 4 shows: a facility hosts equipment and locates records; a sensor_reading is measured on equipment and precedes an anomaly_event; an anomaly_event affects equipment and triggers a recommendation; a recommendation cites a document, names an approver and, on approval, becomes a corrective action in SAP; an incident generates actions; an inspection raises findings as actions; a document evidences an incident.

The reach is the point. One query starts at a gas detector reading, walks to the equipment, to every anomaly detected on it, to the incident that followed, to the corrective actions that incident generated, and to the person who verified closure, with every step carrying its own provenance. A document store returns pages that match keywords; it cannot traverse from a measurement to the action it eventually justified. That traversal is what investigations otherwise reconstruct by hand from scattered records after the event, as the Macondo inquiry had to do (CSB 2010), and what leading-indicator practice in process safety assumes when it reads barrier health together with lagging outcomes (Veiligheidvoorop 2018).

5.2  Where the Human Loop Lives and How the Platform Is Hosted

The human loop lives on the two event objects. An anomaly_event moves through detected, acknowledged, approved or dismissed, and an agent_recommendation moves through proposed, under review, approved or rejected; no anomaly becomes a task and no recommendation becomes a write-back without a named person on one of those transitions. Approval authority is an attribute of a role, not a person: hse_role carries an approval authority and a data visibility scope, so a supervisor sees the sites their role covers and approves what their role permits, enforced at every surface through single sign-on against the operator's identity provider, federated through Keycloak on site.

The hosting posture follows from the sovereign constraint fixed in Chapter 3. All weights, footage, embeddings, ontology state and audit logs stay on the operator's own infrastructure inside Pakistan; nothing crosses the boundary, no external link leaves the object model, and the assistant's citations point inward to the operator's own documents and records. The only write path into a system of record is an approved agent_recommendation recorded into SAP as the owning system; every other interaction with a source is read-only.

5.3  One Object in Its Recorded Form

The corrective_action object, printed below in its recorded form, shows the full pattern: identity, kind, properties, a status vocabulary that ends in verified rather than merely closed, and the typed links that tie it to the incident that generated it and the person who owns it.

{
  "id": "facility",
  "label": "Operating Facility / Site",
  "kind": "site",
  "anchored_in": "",
  "properties": [
    "Facility name",
    "Operating area",
    "Area classification",
    "Shift pattern"
  ],
  "status_vocabulary": [],
  "links": [
    {
      "to": "hse_equipment",
      "label": "hosts"
    },
    {
      "to": "hse_incident",
      "label": "locates"
    }
  ]
}

Every Source Enters Through an Adapter, Never Directly

Eight named sources reach the ontology only through four adapter families that guarantee provenance, ordering and a replayable event backbone, so the chronology of any incident or near miss can be reconstructed.

Chapter 5 defined the twelve objects and the links that join them. Nothing reaches those objects directly from a source: this chapter describes the eight named sources, the four adapter families that alone may touch them, the guarantees the adapter tier makes, and the event backbone that carries every event into the ontology.

6.1  Eight Named Sources and Their Provenance Classes

Figure 5 maps the eight sources to their adapters, and each source carries a provenance class: a label stating where that source's truth originates and how much the platform must verify before trusting an event from it. SAP EHS, PM and QM is the system of record for incidents, work orders, equipment master and inspections, classed as domain-typical because its data model follows the sector's enterprise pattern; the exact landscape and its OData availability are confirmed after award before connector build finalizes. SCADA and the fire and gas system are operational telemetry and safety instrumentation respectively, and the detector alarms are the highest-consequence signals in the design. The Vision AI camera estate is derived sensing: detections land as events on ontology objects, not video, with footage retained on site under the operator's own retention rules. SQL databases are relational records entering through change data capture. Flat files and scanned records are an unstructured archive requiring OCR and parsing. The identity provider is the identity system of record. The eighth source is the operator's HSE governance corpus: its policies, procedures, standards, instructions and risk criteria, together with applicable regulatory requirements and recognized international frameworks such as IOGP Report 456 (Veiligheidvoorop 2018), which ground the assistant's citations.

6.2  What the Adapter Tier Guarantees

The adapter tier guarantees five things to every source. It extracts read-only: no adapter modifies a source system, and the single write-back path runs through the agentic layer into SAP as the owning system. It stamps provenance: every event carries its source system, provenance class, capture timestamp and adapter version, so any object in the ontology can state where each fact came from. It preserves order: capture timestamps come from one site-wide clock discipline, linuxptp and chrony driven by an OCP Time Card GNSS grandmaster with holdover, so a detector alarm, a camera detection and a process excursion sit in one chronology against the same clock. It degrades honestly: a scanned page with low OCR confidence lands in a needs review state rather than silently entering the retrieval corpus. And it is idempotent: replaying an adapter's events cannot double-count an incident or duplicate an alarm.

6.3  The Event Backbone: Ordering, Buffering, Replication

The event backbone is Apache Kafka 4.3 in KRaft mode with three dedicated controllers, running as a small cluster inside the operator's data center. Each source publishes to its own topics, partitioned by asset or facility key, so ordering holds within an asset's event stream; consumers commit offsets, so processing is at-least-once with idempotent handling on the ontology side. Brokers buffer while a source or a consumer is down, replication across brokers keeps the stream alive through a broker loss, and retention is set long enough that the ontology can be rebuilt by replay, which is exactly how phase one reconstructs one real week of HSE history as its first proof. The discipline matters because the alternative is forensic reconstruction: after the Texas City refinery explosion, investigators had to assemble the timeline from instrument and control-system records after the fact (CSB 2005). This backbone makes the chronology continuous, so the reconstruction an investigation needs is already sitting on the objects.

Detection Belongs on Site and Reasoning In-Country

Camera detection and time series forecasting run beside the streams they watch, the frontier reasoning model runs on one sovereign node in-country, and only events and citations, never raw footage, move between tiers.

Chapter 6 brought every source through an adapter onto one event backbone, ordered by a single site clock. This chapter places the compute that turns those streams into detections, forecasts and decisions: close to the cameras and sensors for everything that must not wait, and on one sovereign node in-country for everything that must reason across the whole operation.

7.1  Two Tiers and Their Arithmetic

Figure 6 places the platform's inference in two tiers. The site tier runs beside the streams it watches: RF-DETR detection checkpoints served through KServe on the operator's NPU and GPU edge compute, sized from measured stream and decode load, with Roboflow trackers holding identity across frames; Chronos-2 reading the SCADA and fire and gas historian for anomaly residuals and forecasts; and PaddleOCR-VL parsing scanned records at about 1.9 GB at 16 bit. The detection checkpoints are small, about 61 to 68 MB at 16 bit for the Apache-licensed Nano to Large sizes, so a single edge node holds detector, trackers and forecaster together. The central tier is one node in an in-country data center: eight GPUs of the 141 GB HBM class serve GLM 5.3 at FP8 through vLLM, and BGE-M3 produces the embeddings behind the retrieval assistant at about 1.1 GB at 16 bit.

The arithmetic for the frontier tier is the binding one. GLM 5.3 carries 753 billion filed parameters; at FP8, one byte per parameter, that is 753 GB of weights. The design applies a planning factor of 1.2 for key-value cache and activations, so the node must hold 904 GB. One node of eight 141 GB GPUs provides 1,128 GB of usable memory, leaving 375 GB beside the weights against the 151 GB the factor reserves as the KV cache ceiling. The site tier is sized the other way, bottom up: the design states its requirement as a compute class, and the phase-one survey verifies it against measured stream counts and decode load.

7.2  The Latency Budget

The budget is written per hop rather than as one number, because the three hops fail differently. Hop one is detection to event at the edge, where camera stream, detector and tracker share a node, so the budget is decode plus inference plus tracker association. Hop two is event to alert across the Kafka backbone, where the budget is queueing plus the dashboard's render path, and where the alert budget negotiated with HSE supervisors caps what enters at all; everything below the budget enters a ranked queue instead. Hop three is question to cited answer at the frontier node, where vLLM's batching sets the ceiling. Two disciplines keep the whole budget honest: time synchronization under linuxptp and chrony, driven by an OCP Time Card grandmaster with holdover, keeps detections, detector alarms and process tags in one defensible chronology, and process safety indicators are only as good as the timestamps beneath them (Veiligheidvoorop 2018).

7.3  What Crosses the Boundary and What Breaks

Only events and citations move between tiers. Detections, anomaly scores, forecast residuals, parsed document text and their references travel from the site tier to the central node; recommendations, their rationales and their citations travel back. Raw footage never leaves the site, and the frontier weights never leave the country.

Three failures have standing answers. If the link between site and center fails, the edge keeps detecting and Kafka buffers, replaying in order on reconnection so the chronology survives the gap. If power fails, Network UPS Tools watch the IP-rated enclosures, and hardened fanless switches with redundant DC feeds hold the read-only OT conduit through the DMZ. If the update path is the concern, there is no live pull to fail: the platform runs disconnected under OpenShift AI, and artifacts move as signed bundles through Harbor, so a stalled update stops work rather than silently shipping an unverified model into the sovereign boundary.

Licenses Decide What the Operator Can Own

Every weight the platform runs carries a license that lets the operator hold, fine tune and redeploy it inside its own boundary, which is why license terms, not leaderboards, decided the six-model stack.

Chapter 7 fixed where each model runs and what its memory costs. This chapter fixes what each model is allowed to be: the license terms that let the operator hold the weights, fine tune them and redeploy them inside its own boundary, which is why the stack was chosen against licenses first and leaderboards second.

8.1  The Frontier Work Surface

Figure 7 stacks the six models against the tiers they serve. GLM 5.3 open weights anchor the stack: a mixture-of-experts model with 753 billion filed parameters, about 756 GB of weights at FP8 as published and roughly 1.5 TB at BF16, so it needs eight or more datacenter GPUs of the 141 GB class before any KV cache. It runs on the central node through vLLM and carries the agentic work surface, ontology maintenance, human-in-the-loop agent reasoning, the natural-language assistant and document generation. Its bespoke license permits commercial use with attribution and exempts purely internal use from the security-review trigger that applies to model-as-a-service offerings, which is exactly the posture an operator running everything inside its own boundary needs. It was chosen as the strongest open agentic model, and chosen against a hosted API, which would break data residency, and against a mid-size dense model standing in silently for the frontier class the work surface commits to.

8.2  The Site Tier

RF-DETR is the real-time detector on the Vision AI camera streams, finding workers, hard hats, vehicles, flame, smoke and zone breaches. Its Apache-2.0 Nano to Large checkpoints run at BF16 at about 61 to 68 MB, and the Plus XL and 2XL checkpoints are excluded from the serving path. It was chosen against Ultralytics YOLO26, whose AGPL-3.0 license would force source release of the whole serving stack on an operator that must own a closed sovereign product. Roboflow trackers supply Apache-2.0 motion tracking, keeping stable identity across frames for zone dwell and crossing rules without reintroducing copyleft behind an Apache detector. Chronos-2 is the Apache-2.0 universal forecaster, about 0.48 GB at 32 bit as published and about 0.24 GB at 16 bit, which handles multivariate and covariate-informed streams zero-shot, fitting mixed-quality HSE sensor series without per-tag training; it carries no field-of-use restriction, so the operator may hold, fine tune and redistribute the weights. PaddleOCR-VL 1.6 is the Apache-2.0 vision-language parser, about 0.9 billion parameters and about 1.9 GB at 16 bit, strong on degraded multilingual scans and small enough to run on a single site GPU beside the other models.

8.3  Retrieval and the Register

BGE-M3 is the embedding model behind the retrieval corpus: MIT licensed, with dense plus sparse plus multi-vector retrieval in one pass and an 8,192-token window, at about 2.27 GB at float32 as published, about 1.1 GB at 16 bit and about 0.6 GB at 8 bit. It was chosen because part numbers, tag names and error codes survive intact across a multilingual corpus of policies, standards and incident records. Table 4 then registers the full set: each model, the hardware classes and sizing rules, the sensing, the patterns the design stands on and the ground it runs on.

Shadow Mode Comes Before Any Alert Is Trusted

Three phases with seventeen items and explicit gates put a reconstructed real week of HSE history in shadow ahead of any live alert, and user acceptance sign-off, not a calendar date, is the binding exit.

Chapter 8 fixed the model stack and the licenses that let the operator hold every weight inside its own boundary. This chapter fixes the order in which those models earn the right to speak: nothing raises a live alert until it has first run in shadow against a reconstructed real week of the operator's own HSE history, and nothing ends the work except the department's own sign-off.

9.1  Three Phases and Their Gates

The rollout runs as three phases carrying seventeen items, sequenced so the data foundation precedes detection, detection precedes agency, and agency precedes any write-back into the systems of record (Figure 8). Phase 1 carries five items across two workstreams, Sovereign Delivery and Assurance and Unified HSE Data Foundation: agree the HSE object model and the source inventory, stand up the sovereign ingestion connectors across the four adapter families, reconstruct one real week of HSE history from the SAP records, SCADA and fire and gas streams, the SQL databases and the scanned files, and verify the 141 GB HBM class node requirement against the site's capacity. Its exit gate is the first real proof: the reconstructed week reconciles against the systems of record, and the department signs off the object model that everything downstream will read. Phase 2 carries six items across three workstreams, AI Detection and Prediction, Agentic Layer and Assistant, and Control Room Visibility and Reporting: train the anomaly and predictive models on the reconstructed streams, stand up Vision AI detection on the camera estate behind the ONVIF reuse gates, and build the control and command dashboard. Its exit gate is shadow sign-off: every detector and forecaster has run against the reconstructed week without raising a live alert, and the alert budget has been negotiated with HSE supervisors before any threshold goes live. Phase 3 carries six items across two workstreams, Agentic Layer and Assistant and Sovereign Delivery and Assurance: stand up the agentic layer under human approval, open the agent work surface to the operator's own HSE teams, close the recommendation loop into SAP workflows, and prove the air-gapped operation pack. Its exit gate is user acceptance: the department's personnel sign off inside the platform, and that sign-off, not a calendar date, is the binding end of the program. Weekly on-site reviews re-baseline the plan as integration discovery lands, because the SAP landscape, data volumes and concurrent user counts are confirmed only after award. Twelve requirements map onto these gates. The baseline claims none as closed on paper; each requirement is tied to the phase whose gate proves it, and the final set closes only at user acceptance.

9.2  What the Rollout Measures

The rollout measures from the first week, before any model is trusted: reconciliation deltas between ontology objects and their systems of record; OCR capture and illegibility rates on the scanned records; anomaly precision as judged by the supervisors who acknowledge; time-to-acknowledge, ignore rate and action rate per alert source; forecast residual error on the SCADA and fire and gas series; and approval latency on agent recommendations. The indicator structure follows the process safety performance indicators recommended for upstream operators, which pair leading measures of barrier health with lagging outcomes (Veiligheidvoorop 2018). The design reports leading measures first, because a leading measure is the only kind a supervisor can act on the same shift.

9.3  What Fails and What the Design Does

Table 5 sets the failure modes the design carries explicitly and the behavior each one triggers.

9.4  Lessons

Shadow the flags before anyone trusts them. Every detector, forecaster and agent recommendation runs against the reconstructed week before it can raise anything live. Shadow mode converts model quality from a vendor claim into a number a supervisor has already seen, and it is the reason phase 2 cannot close on a schedule. Measure the scans before pricing the pipeline. Digitisation of degraded HSE records is priced only after the reconstructed week has produced real capture and illegibility rates. A needs-review state keeps illegible documents out of the retrieval corpus rather than letting them poison answers silently. Negotiate the alert budget before the thresholds. Anomaly alerts that exceed what supervisors can treat seriously would quietly kill adoption. The budget is agreed with HSE supervisors first, everything below it enters a ranked queue, and the ignore rate is reported from the first week so the budget stays honest. A gate is a proof, not a date. Each phase ends when its evidence exists: a reconciled week, a shadow run supervisors accept, an air-gapped pack and a signed acceptance. Milestones describe what must be true, and the calendar follows the evidence.

9.5  What Is Still Open

Three questions stay open at baseline. Whether the operator's data center can hold the frontier node changes the hardware order: settling it early converts the sizing requirement into a confirmed placement or an export-license path. Which SAP generation runs and whether OData is exposed changes the connector build: settling it finalises the ERP adapter. What the OCR legibility rate actually is on the scanned corpus changes the digitisation scope: settling it sizes the human review effort that keeps the retrieval corpus clean. Each is assigned to the phase-one survey or the reconstructed week, so all three close on measured readings rather than assumptions.

The Intelligence Should Stay with the Operator That Produced It

The object model, the fine-tuned weights, the decision record and the boundary itself belong to the operator, and CodeNinja's role maps only to the elements the design actually contains.

Chapter 9 ended at user acceptance, the moment the department's own people sign that the platform behaves as designed. This chapter states who owns what that signature covers: the model, the weights, the record of decisions and the boundary itself.

10.1  What the Operator Owns

The object model is the operator's. The twelve HSE objects, their typed links and their status vocabularies are defined with the department and held in the operator's graph store, and the model evolves under the operator's change control rather than a vendor's release train. The weights are the operator's: every model in the stack carries an open license, Apache-2.0 or MIT for the detectors, forecasters, embedder and parser, and the frontier model's bespoke license, whose terms permit purely internal commercial use, so any fine-tune trained on the operator's own incident and near-miss corpus is the operator's property on the operator's hardware. The decision record is the operator's: every acknowledgment, approval, rejection and dismissal is kept with its rationale and citations, and the next decision reads that record, which makes it the operator's evidence in any audit. The boundary is the operator's: identity, network segmentation, the read-only OT conduit and the air-gapped operation pack run on the operator's infrastructure under the operator's accounts.

10.2  The Offer Behind the Design

CodeNinja designed this system on Praxis, its platform for designing physical AI systems, and the design maps to its offer element by element: Adaptive Operations is the sensing, detection and forecasting of physical behavior across the camera estate, fire and gas detectors and process telemetry; Decision Systems is the recommendation layer in which a named approver decides every proposed action; Hyper Ontology is the twelve-object model that turns fragmented HSE data into one argument; Hyper Pragma is the work surface where the operator's own HSE teams build and run their agents; and Sovereign Infrastructure is the whole posture of open-weight licenses held on the operator's own, in-country, air-gappable hardware.

Sovereignty Is an Architecture, Not an Address

In one view the design is a single living HSE ontology over eight sources, fed by four adapter families that guarantee provenance and ordering, with detection and forecasting running beside the cameras and the historian, a cited assistant answering against the operator's own policies and standards, agents that recommend under human approval, and every weight, embedding and decision record held inside one national boundary where a named person owns each decision.

Running the same shape elsewhere takes an operator whose data already lives inside one boundary it controls, a phase-one survey that sizes the frontier node from filed parameter counts before anything is priced, an alert budget negotiated with supervisors before any threshold is set, and the willingness of the operator's own people to build and maintain their agents on the work surface; where those hold, the pattern transfers without redesign.

How Praxis Contextualized and Reasoned This Design

Every choice in this paper traces to a recorded read of the operator's requirement and intake answers, eight reasoning lenses, and the patterns and equipment classes those lenses returned, with nothing inferred.

Chapter 10 placed ownership of the model, the weights, the decision record and the boundary with the operator. This chapter turns to the design process itself and shows how any choice in this paper can be traced back to what justified it. Every design in this series is produced on Praxis, and the point of recording the reasoning is traceability: a reader who disagrees with a choice can find the record that produced it. Figure 9 sets out the ask, the lenses that read it, the patterns they returned and the equipment those patterns settled on.

11.1  Contextualizing the Ask

Praxis read the operator's requirement in full: an exploration and production company in Pakistan evaluating a sovereign, on-premises HSE control and command platform that consolidates fragmented data, turns it into predictive analysis and early warnings, grounds its guidance in the operator's own policies and in recognized frameworks including IOGP and OSHA, and supports its people through anomaly detection, a natural-language assistant and agents acting under human approval. Praxis assigned the ask to the sovereign physical operations family, oil and gas industry, and the country boundary came from the operator's own requirement. What was in the room: the requirement document, the attached scope and technical architecture, and the intake answer set, each listed in the register, read in full and available on request.

11.2  The Lenses

Table 6 shows the eight lenses Praxis applied, what each could see, what it cited and what it contributed. One lens returned nothing, and the table shows that gap rather than papering over it.

11.3  Patterns Adopted and Set Aside

The reasoning adopted three patterns. The write-layer doctrine holds that a detection which raises no action is a photograph, so every anomaly and recommendation lands on the object model with a recommended action and a named approver. The historian is treated as a first-class source, so sensor readings join the same chronology as camera events under disciplined time. And the accident record, in which refinery and rig disasters turned on signals that never reached a decision maker in time (CSB 2005; CSB 2010), fixed the ordering: detection and prediction before agency, agency before write-back. The reasoning set aside three. A people and vehicle positioning layer was dropped because no named source requires it and zone logic over the existing camera estate covers the safety rules in scope. A hardware data diode was reserved rather than specified, because the whole platform sits inside one sovereign boundary and the OT read path runs as a constrained read-only conduit. The case-study pattern was set aside because no comparable build exists in the record, and the paper says so.

11.4  Where the Reasoning Lands

The reasoning lands on equipment classes, not part numbers: one node of eight 141 GB HBM class GPUs for the frontier tier, with the sizing arithmetic shown in full; edge NPU and GPU compute sized from measured stream and decode load and verified by a phase-one survey; hardened fanless industrial switches for the plant-side drops; a GNSS grandmaster time card with holdover driving site-wide time; IP-rated enclosures on UPS power; and reuse of the existing camera estate subject to ONVIF gates, with any gaps priced as new class purchases. Every one of these was recorded reading: a count from the register, a license from its terms, a class from arithmetic the reader can repeat. Nothing in this design is inferred.