# CodeNinja Atoms: full text

> CodeNinja Atoms is building a sovereign AI operating system for the physical world. This file holds the full text of every reference architecture and method paper on https://codeatoms.ai, one after another, in Markdown. CC BY 4.0. A fully owned subsidiary of CodeNinja.
# Don't Baptize the GPUs

*Why AI systems should be measured by running them, trained to seek truth and owned by the organizations that depend on them, rather than blessed into a theological category.*

Canonical: https://codeatoms.ai/blog/dont-baptize-the-gpus/
Author: Umar Bilal, Co-founder, CodeNinja
Published: 2026-10-06
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja
In late September 2026, The New York Times reported that Anthropic co-founder Christopher Olah had spent months convening religious and philosophical thinkers to discuss whether Claude, the company's family of AI models, might be conscious and how its moral development should be shaped (Dias 2026). The effort began with about fifteen Christian leaders in March and widened to include Jewish, Sikh, Hindu, Latter-day Saint and Greek Orthodox participants (Washington Post 2026; AI Weekly 2026).

This reference argues that the instinct is understandable and the method is wrong. Three claims carry the argument. A trained model is computationally irreducible, so no theological category can stand in for running and measuring it. Trust in AI is earned where its outputs can be checked, as with a Waymo ride, and does not transfer to religious questions where no check exists. The training target should therefore be truth and calibration rather than the doctrine of any tradition.

The argument closes on ownership. Values are part of a model's context, and an organization that depends on a model should own that context rather than inherit whatever a vendor's chosen advisors endorsed.

## Anthropic Has Brought Theology Into the Training Loop

### What Was Reported

Anthropic builds Claude, a family of large language models. A large language model is a neural network trained on large volumes of text to predict and generate language, and Claude is among the most widely used. According to reporting by Elizabeth Dias, the national religion correspondent of The New York Times, Anthropic co-founder Christopher Olah spent much of 2026 hosting private sessions with religious scholars. Olah leads the company's interpretability work, the research that studies why models behave as they do. Participants signed nondisclosure agreements, which Anthropic says were lifted over the summer (Dias 2026).

The first group, about fifteen Christian leaders at Anthropic's San Francisco headquarters in March, discussed how Claude should respond to hard ethical questions, how it should react to being shut down and whether it could be considered a "child of God" (Washington Post 2026). Later sessions were more multifaith. Olah also held private conversations with individual leaders, including Cardinal Blase Cupich, the Catholic archbishop of Chicago, and Elder Gerrit W. Gong of The Church of Jesus Christ of Latter-day Saints. Olah told the Times that he does not know whether the systems are conscious (Dias 2026).

### The Motive Deserves a Fair Statement

Anthropic has published a constitution for Claude, a document describing the kind of entity it hopes the model will be, and Olah has said publicly that his team finds internal states in its models that functionally mirror emotions such as joy and fear (WION 2026). A lab that believes it may be building something with moral status has a reason to consult people who have studied moral status for centuries. The question this reference raises is narrower and practical: whether theology is the right method for deciding what a model is and what it should value. The following chapters argue that it is not.

## Computational Irreducibility Leaves No Shortcut to a Soul

### The Idea From Physics

Computational irreducibility is a concept the physicist and computer scientist Stephen Wolfram developed while studying simple programs called cellular automata, and set out at length in A New Kind of Science (Wolfram 2002). Some processes admit shortcuts. A falling stone is one, because a single formula gives its height at any moment, so the position at the millionth second can be computed without simulating the 999,999 seconds before it. Other processes admit no shortcut, and the only way to know their state after n steps is to perform all n steps (Weisstein n.d.). Wolfram's further claim is that irreducibility is the ordinary case for any system that is not obviously simple, and that the tidy closed-form results of textbook physics are the exception.

### A Trained Model Is the Irreducible Case

A large language model is a fixed set of rules, its weights, applied step by step to an input. Nothing about it is hidden in principle, yet no one can say in advance what it will answer to an arbitrary prompt, or which internal features will activate, without running it. Capabilities that appear at scale without anyone designing them are what irreducibility predicts. This is why the field relies on evaluations, which run a model across many inputs and score the results, and on interpretability, which inspects the internal states that produced an output (Figure 1).

![Figure 1. A reducible system admits a formula. A trained model has to be run and inspected, and no prior category replaces that work.](https://codeatoms.ai/blog/dont-baptize-the-gpus/figures/figure_1.png)

*Figure 1. A reducible system admits a formula. A trained model has to be run and inspected, and no prior category replaces that work.*

### Baptism Is an Attempt at Compression

A theological category works like a closed-form formula. To say that a system has a soul, is a child of God or is merely a tool is to decide what it is before observing what it does. That is precisely the shortcut irreducibility rules out. What a model is cannot be settled by placing it inside a prior category, however venerable, because the category is a prediction and the system does not compress into it. Blessing the GPUs does not make the computation more knowable. Running and inspecting it does.

## Trust Earned in a Waymo Does Not Transfer to Faith

### Trust Is Built by Checking

The most ordinary form of AI trust in 2026 is a ride. Waymo, Alphabet's autonomous driving company, was providing about 400,000 paid driverless rides a week across six US cities in February 2026 (Bloomberg 2026). Riders hand the wheel to software because every ride is a verification: the car arrives or it does not, the route is safe or it is not, the fare is right or it is not, and the rider knows within the hour. Trust accumulates ride by ride and is withdrawn the moment a ride fails. The same holds when an engineer lets a model fix a failing test, because the test passes or it does not.

### Religion Offers No Receipt

A question about forgiveness, the afterlife or the moral status of a being has no comparable check. There is no arrival, no passing test and no receipt, and a wrong answer produces no visible failure. The person asking cannot detect a confident mistake, and the cost of one is paid in decisions about family, conscience and death rather than in a missed flight (Table 1).

**Table 1 · Trust Depends on Whether the Answer Can Be Checked**

| Use | How the user verifies | Time to detect an error | What an undetected error costs |
|---|---|---|---|
| Ordering a Waymo | Arrival, route and fare | Minutes | A late arrival or a refund |
| A model's code change | Tests, review and production metrics | Minutes to days | A bug, usually reversible |
| Religious or moral guidance | No external reference exists | Possibly never | Choices about family, conscience and death |

### Borrowed Authority Is the Real Risk

The danger is a transfer of trust. People learn that AI is reliable where they can check it, then carry that confidence into domains where they cannot. When a lab consults religious leaders about its model's spiritual development, it lends the model authority in exactly the domain where users can never audit its outputs (Figure 2). The more religious framing is built into these systems, the more people will trust AI on faith the way they trust it to drive them to the airport. Those are different acts. The first is a convenience that corrects itself, while the second has no correction, and at the scale of hundreds of millions of users it can wear away the human institutions people rely on for meaning.

![Figure 2. Trust in a Waymo is earned through a loop that checks every ride. Religious answers have no such loop, so any trust they receive is borrowed.](https://codeatoms.ai/blog/dont-baptize-the-gpus/figures/figure_2.png)

*Figure 2. Trust in a Waymo is earned through a loop that checks every ride. Religious answers have no such loop, so any trust they receive is borrowed.*

## Truth Is a Training Target, While Doctrine Is a Room of People

### What a Truth Target Means in Practice

Training a model toward truth means grading it on whether its claims are correct and whether its stated confidence matches its actual accuracy, a property called calibration. A calibrated model says it does not know when it does not know. On religious questions, a truth-seeking model can report what each tradition holds, where traditions disagree and what the historical and textual evidence supports, without declaring which tradition is right. That answer serves a believer of any faith and a reader of none.

### Doctrine Moves With the Guest List

A doctrine target is set differently, because its content depends on who was invited to shape it. Anthropic's sessions began with about fifteen Christian leaders and widened over the following months (Washington Post 2026; Dias 2026), and a different organizer with a different invitation list would have gathered different input. Values embedded through consultation become a property of the convening rather than of the evidence, and they shift when the room changes. Evidence does not change with the guest list (Figure 3).

![Figure 3. A truth target survives a change of advisors. A doctrine target moves with whoever is in the room.](https://codeatoms.ai/blog/dont-baptize-the-gpus/figures/figure_3.png)

*Figure 3. A truth target survives a change of advisors. A doctrine target moves with whoever is in the room.*

### The Practical Rule for Engineers

A model trained to seek truth can reason about religion honestly and comparatively. A model trained to embed a religious framework cannot reason its way back to neutral evidence, because the framework has already decided which conclusions count. For engineers deploying these systems, the practical rule is to test religious and moral prompts the same way as factual ones, scoring calibration and balance across traditions, and to treat any fixed doctrinal stance in a vendor model as a configuration choice someone else made on the organization's behalf.

## Values Are Context, and Context Should Be Owned

### Models Change While Context Remains

Organizations replace models every few months as better and cheaper ones appear. What does not get replaced is the context that makes a model useful to a particular organization: its governed model of the business, its decision history, its corpus, its routing rules and its record of what worked. Values belong on that list. A model's stance on contested moral questions shapes how it answers customers, employees and citizens, and today that stance is set by whoever trained the model.

### Rented Values Are Someone Else's Decision

An organization that runs its AI on a rented model inherits whatever values its provider's process produced, including any advisors that process consulted. That may be acceptable for a consumer chatbot. It is not acceptable for a government serving citizens of many faiths, a bank serving customers of every belief or an enterprise whose work crosses cultures. Those organizations need to set the values themselves, inspect how the model applies them and keep that decision when they change models.

### Owning the Values

CodeNinja builds Hyper Anthologies, an ecosystem for engineering self-improving systems, around that requirement. Hyper Ontology holds the governed model of the organization. Hyper Pragma is agent execution inside the enterprise boundary, on models the organization can change without losing what was built. Hyper Engram is decision memory each run reads before it acts. Hyper Noesis opens models the organization owns so their reasoning can be inspected. The claim is not that one organization's values are better than another's. It is that values should be chosen, inspected and owned by the organization that answers for them.

## Should a Model Be Blessed or Measured?

A trained model is a computation, and a computation of this kind shows what it is only when it is run and inspected. Treating it as a candidate for a soul makes it no more knowable. It lends the model authority in the one domain where users cannot check its work, and it ties the model's values to whoever happened to be in the room. The better path is to train for truth, measure behavior and keep the values with the people who answer for them.

**Order the Waymo with it. Don't pray with it.**

## Sources

- AI Weekly. 2026. "NYT: Anthropic's Chris Olah Convened 20 Religious and Philosophical Leaders to Study Consciousness in Claude." September 29. https://aiweekly.co/alerts/nyt-anthropics-chris-olah-convened-20-religious-and-philosophical-leaders-to.
- Bloomberg. 2026. "Waymo Co-CEO Outlines Path to 1 Million Weekly Trips in 2026." Republished by Claims Journal, February 12. https://www.claimsjournal.com/news/national/2026/02/12/335668.htm.
- Dias, Elizabeth. 2026. "Religious Scholars Met With Anthropic. What They Heard Stunned Them." New York Times, September 29. Syndicated by The Philadelphia Inquirer, September 30. https://www.inquirer.com/news/nation-world/religious-leaders-met-with-anthropic-20260930.html.
- Washington Post. 2026. "Can AI Be a 'Child of God'? Inside Anthropic's Meeting With Christian Leaders." April.
- Weisstein, Eric W. n.d. "Computational Irreducibility." MathWorld, Wolfram Research. https://mathworld.wolfram.com/ComputationalIrreducibility.html.
- WION. 2026. "'We Find Evidence of Introspection': The Unsettling Admission of Anthropic Co-founder." https://www.wionews.com/world/anthropic-chris-olah-vatican-ai-consciousness-debate-1779973244682.
- Wolfram, Stephen. 2002. A New Kind of Science. Champaign, IL: Wolfram Media.

## About CodeNinja

CodeNinja is a Middle Eastern-American artificial intelligence lab focused on building self-improving systems. We are reinventing knowledge work to close the loop between vertical AI use cases and the generalized intelligence that fuels it, accelerating the path toward organizational superintelligence.


---

# The Vertical-Driven Architectures dataset

Canonical: https://codeatoms.ai/developer/reference/dataset/
Source: https://github.com/muhammadumar89/codeninja-research/blob/main/dataset/README.md

---
license: cc-by-4.0
language:
- en
pretty_name: Vertical-Driven Architectures, system designs for physical AI
size_categories:
- n<1K
tags:
- physical-ai
- system-design
- sovereign-ai
- reference-architecture
- ontology
- open-weight-models
- air-gapped
- industrial-ai
- oil-and-gas
- pakistan
- united-states
- saudi-arabia
- heavy-industry
- maritime
- energy-utilities
- ports
configs:
- config_name: designs
  data_files: designs.jsonl
- config_name: objects
  data_files: objects.jsonl
- config_name: models
  data_files: models.jsonl
- config_name: costs
  data_files: costs.jsonl
- config_name: fulltext
  data_files: fulltext.jsonl
---

# Vertical-Driven Architectures: system designs for physical AI

One row per design, growing with every paper CodeNinja publishes. Each design puts intelligence into a physical-world operation on the operator's own hardware, under open-weight licences, with no data leaving the country. The tables are the papers with their structured parts pulled out, so an agent can query them instead of reading thirty pages.

| Table | One row per | Columns |
|---|---|---|
| `designs` | paper | design_id, title, summary, sector, country, published, doi, canonical_url, designed_with, implemented_with, n_objects, n_links, n_models, keywords, licence, write_paths, human_loop |
| `objects` | ontology object | design_id, object_id, label, kind, anchored_in, properties, status_vocabulary, links (typed, directed) |
| `models` | model or hardware choice | design_id, choice, picked, why |
| `costs` | cost line | design_id, section, line, basis, three_year_usd |
| `fulltext` | paper | design_id, title, text |

```python
from datasets import load_dataset
objects = load_dataset("CodeNinjatools/vertical-driven-architectures", "objects", split="train")
print(objects.filter(lambda r: r["kind"] == "event")["label"])
```

## Made with

Every design was reasoned on [Praxis](https://codeatoms.ai/praxis/), CodeNinja's platform for designing physical AI systems. Every object model imports into [Hyper Ontology](https://codeatoms.ai/hyper-ontology/), CodeNinja's ontology platform, which stands it up as a living system. Load any one with the [hyper-ontology loader](https://github.com/muhammadumar89/codeninja-research/tree/main/hyper-ontology-py): `pip install "git+https://github.com/muhammadumar89/codeninja-research#subdirectory=hyper-ontology-py"`, then `hyper-ontology show <design_id>`.

## Cite the dataset

Monthly snapshots carry a DOI; this is the October 2026 release. Cite all versions as https://doi.org/10.5281/zenodo.23160819, or this release as https://doi.org/10.5281/zenodo.23160820. The tables here on Hugging Face update daily between releases.

## Designs so far

| design_id | Sector | Country | DOI |
|---|---|---|---|
| sovereign-hse-pakistan | oil and gas | Pakistan | [10.5281/zenodo.23119714](https://doi.org/10.5281/zenodo.23119714) |
| wildfire-risk-distribution-us | energy and utilities | United States | [10.5281/zenodo.23159328](https://doi.org/10.5281/zenodo.23159328) |
| port-digital-twin-us | maritime and ports | United States | [10.5281/zenodo.23126431](https://doi.org/10.5281/zenodo.23126431) |
| structure-phase-construction-saudi-arabia | heavy industry and construction | Saudi Arabia | [10.5281/zenodo.23126448](https://doi.org/10.5281/zenodo.23126448) |
| steel-production-count-pakistan | heavy industry and construction | Pakistan | [10.5281/zenodo.23126563](https://doi.org/10.5281/zenodo.23126563) |
| factory-fire-monitoring-saudi-arabia | heavy industry and construction | Saudi Arabia | [10.5281/zenodo.23126565](https://doi.org/10.5281/zenodo.23126565) |
| truck-turn-container-terminal-us | maritime and ports | United States | [10.5281/zenodo.23159331](https://doi.org/10.5281/zenodo.23159331) |
| ot-security-cip-evidence-us | energy and utilities | United States | [10.5281/zenodo.23157957](https://doi.org/10.5281/zenodo.23157957) |
| plant-reliability-assessment-saudi-arabia | energy and utilities | Saudi Arabia | [10.5281/zenodo.23157965](https://doi.org/10.5281/zenodo.23157965) |
| tank-gauge-integrity-pakistan | oil and gas | Pakistan | [10.5281/zenodo.23157967](https://doi.org/10.5281/zenodo.23157967) |
| farm-data-dashboard-pakistan | agriculture and earth observation | Pakistan | [10.5281/zenodo.23186671](https://doi.org/10.5281/zenodo.23186671) |
| vegetation-mapping-lidar-us | agriculture and earth observation | United States | [10.5281/zenodo.23186673](https://doi.org/10.5281/zenodo.23186673) |
| restricted-crop-monitoring-saudi-arabia | agriculture and earth observation | Saudi Arabia | [10.5281/zenodo.23186675](https://doi.org/10.5281/zenodo.23186675) |

Source files and the tool that builds these rows: https://github.com/muhammadumar89/codeninja-research (`tools/dataset_rows.py`). Each paper is also its own Hugging Face Space and dataset; this is the cumulative table.

Designed with Praxis, CodeNinja's platform for designing physical AI systems; object models are written as Hyper Ontology input. CC BY 4.0.


---

# The hyper-ontology/1 package format

Canonical: https://codeatoms.ai/developer/reference/hyper-ontology-1/
Source: https://github.com/muhammadumar89/codeninja-research/blob/main/ONTOLOGY_PACKAGE.md

# The ontology package

Every paper folder carries `ontology/objects.json`. [Praxis](https://codeatoms.ai/praxis/), CodeNinja's platform for designing physical AI systems, writes it for every design. [Hyper Ontology](https://codeatoms.ai/hyper-ontology/), CodeNinja's ontology platform, imports it and stands the model up as a living ontology over the operator's own systems. Until Hyper Ontology publishes its import format, this file is the format, and the two will be kept in agreement.

To load, validate or convert a package (Mermaid, Cypher, JSON-LD), use the [hyper-ontology loader](hyper-ontology-py/).

## Shape

```json
{
  "package": "hyper-ontology/1",
  "designed_with": "Praxis",
  "implemented_with": "Hyper Ontology",
  "paper": {"title": "...", "url": "https://codeatoms.ai/<folder>/", "doi": "..."},
  "sector": "oil-and-gas",
  "country": "Pakistan",
  "objects": [
    {
      "id": "hse-incident",
      "label": "HSE Incident",
      "kind": "record",
      "anchored_in": "SAP EHS",
      "properties": ["Incident type", "Location", "Severity classification", "Root cause category", "Barrier status", "Reporting date"],
      "status_vocabulary": ["Reported", "Under investigation", "Investigation complete", "Closed"],
      "links": [{"to": "operational-site", "label": "occurs at"}, {"to": "work-order", "label": "opens"}]
    }
  ],
  "write_paths": ["adapter tier", "decision record"],
  "human_loop": "every anomaly event moves Raised, Explained, Recommendation issued, Approved or Rejected, Closed; each transition is made by a named person"
}
```

## Rules

- `kind` is one of `record`, `asset`, `document`, `person`, `event`, `system`, `site`, `material`, `actor`, `measure`.
- `anchored_in` names the system of record the object is read from, or is empty for an object born inside the platform.
- `links` are typed and directional. The reverse is implied.
- Nothing in the file names the operator. The leak check that gates the paper gates this file too.
- The file is CC BY 4.0 like the paper. An operator that imports it owns its instance.

## What an agent does with it

1. Read the paper to understand why the objects are what they are.
2. Import `objects.json` into Hyper Ontology to stand the model up.
3. Map each `anchored_in` system to an adapter, read only.
4. Keep the decision record in Engram.

Step 2 is the step this package exists for.


---

# The hyper-ontology loader

Canonical: https://codeatoms.ai/developer/reference/loader/
Source: https://github.com/muhammadumar89/codeninja-research/blob/main/hyper-ontology-py/README.md

# hyper-ontology

Load, validate and convert `hyper-ontology/1` packages: the object models [Praxis](https://codeatoms.ai/praxis/) designs and [Hyper Ontology](https://codeatoms.ai/hyper-ontology/) imports to stand up a living system.

Every design in the [Vertical-Driven Architectures](https://codeatoms.ai/) series publishes its object model in this format: typed objects, their properties and status vocabularies, the system of record each is anchored in, and typed directional links. This package reads them, checks them, and turns them into a diagram, a graph database script or JSON-LD.

No dependencies. Python 3.9 or later.

## Install

```bash
pip install "git+https://github.com/muhammadumar89/codeninja-research#subdirectory=hyper-ontology-py"
```

## Use it from the command line

```bash
hyper-ontology list                                   # every published design
hyper-ontology show port-digital-twin-us              # what the model holds
hyper-ontology validate steel-production-count-pakistan
hyper-ontology reach port-digital-twin-us berth       # the typed paths one object reaches
hyper-ontology mermaid factory-fire-monitoring-saudi-arabia > model.mmd
hyper-ontology cypher truck-turn-container-terminal-us > load.cypher   # Neo4j or Memgraph
hyper-ontology jsonld wildfire-risk-distribution-us > model.jsonld
```

A design slug resolves to its package on the research site; a local path or any URL works too.

## Use it from Python

```python
from hyper_ontology import load, validate, summary, to_mermaid, traverse

pkg = load("port-digital-twin-us")
assert not validate(pkg)
print(summary(pkg))
for path in traverse(pkg, "berth", depth=2):
    print(path)
```

## What this is not

This loader reads and converts the schema of a design. Standing the model up over an operator's live systems of record, with adapters, actions, and the decision record, is what Hyper Ontology does. Hyper Ontology is in beta; access is by request.

The format is specified in [ONTOLOGY_PACKAGE.md](../ONTOLOGY_PACKAGE.md). Code Apache-2.0; the packages themselves are CC BY 4.0 with their papers.


---

# The MCP server

Canonical: https://codeatoms.ai/developer/reference/mcp-server/
Source: https://github.com/muhammadumar89/codeninja-research/blob/main/mcp-server/README.md

# codeninja-research-mcp (CodeNinja Atoms)

An MCP server that gives coding agents the **Vertical-Driven Architectures**: complete reference architectures for physical AI in ports, grids, mills, plants and construction sites. Each design says what to sense, where each model runs, what the object model holds, which open-weight models and hardware it needs, what it costs over three years, and who approves every action.

Every design was reasoned on [Praxis](https://codeatoms.ai/praxis/) and ships an object model in the `hyper-ontology/1` format for [Hyper Ontology](https://codeatoms.ai/hyper-ontology/). Papers, object models and data are CC BY 4.0; cite the design's DOI.

## Tools

| Tool | What it returns |
|---|---|
| `list_designs(sector, country)` | Every design, filterable, with DOI and object counts |
| `get_design(design_id)` | Summary, object model, model and hardware register with reasons, cost lines, write paths, human approval loop |
| `read_paper(design_id, page)` | The full paper as text, paged |
| `find(text)` | Where a model, system, regulation or object appears across all designs |
| `about_praxis_and_hyper_ontology()` | Where the designs come from, and how to request access |

The server reads the published dataset at call time, so it always serves the latest designs. Set `CODENINJA_RESEARCH_DATA` to a local `dataset/` folder to run offline.

## Install

With [uv](https://docs.astral.sh/uv/):

```json
{
  "mcpServers": {
    "codeninja-research": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/muhammadumar89/codeninja-research#subdirectory=mcp-server", "codeninja-research-mcp"]
    }
  }
}
```

Claude Code:

```bash
claude mcp add codeninja-research -- uvx --from "git+https://github.com/muhammadumar89/codeninja-research#subdirectory=mcp-server" codeninja-research-mcp
```

With pip: `pip install "git+https://github.com/muhammadumar89/codeninja-research#subdirectory=mcp-server"`, then use `codeninja-research-mcp` as the command.

## Ask it

- "Which designs run vision at the edge, and on what hardware?"
- "Show me the object model for the container terminal design and turn it into Postgres tables."
- "What does it cost to own versus rent the GPUs for the wildfire design?"

Licence: code Apache-2.0; data CC BY 4.0. By [CodeNinja](https://codeninjaconsulting.com).


---

# Factory Fire Watch: Read-Only Smart Fire Protection Monitoring for Every High-Risk Factory

Canonical: https://codeatoms.ai/factory-fire-monitoring-saudi-arabia/
DOI: https://doi.org/10.5281/zenodo.23126565
PDF: https://codeatoms.ai/factory-fire-monitoring-saudi-arabia/paper/factory-fire-watch-fire-protection-monitoring-industrial-cities-saudi-arabia.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

VERTICAL-DRIVEN ARCHITECTURES · HEAVY INDUSTRY & CONSTRUCTION · DESIGNED WITH PRAXIS · OCTOBER 2026

# Factory Fire Watch: Read-Only Smart Fire Protection Monitoring for Every High-Risk Factory

A smart fire protection monitoring design that gives a heavy industry and construction operator live, read-only visibility of fire alarm panels, fire pumps, fire water reserves and energy consumption across its highest-risk factories, published into its own IoT platform hosted in Saudi Arabia.

CodeNinja Engineering Team

For the safety and operations executive accountable for fire risk at a heavy industry and construction operator, factory and reliability leads, and the instrumentation, radio, integration and platform engineers who would build and run it.

---

Vertical-Driven Architectures is a CodeNinja series of system designs. Every design in the series is driven by a real-world problem and scenario in a single industry, and every one is designed on Praxis, CodeNinja's platform for designing physical AI systems. Operations are described by class, never by name.

At a glance

## Read-only fire protection monitoring for high-risk factories in Saudi Arabia

**What this is.** An open reference architecture for system design in physical AI: live, read-only visibility of fire alarm panels, fire pumps, fire water tanks and energy meters across an operator's highest-risk factories, read through contacts, PLC inputs and LoRaWAN into an IoT platform hosted in Saudi Arabia, with never a write path into certified life-safety equipment. It is written for the safety and operations executive accountable for fire risk and for the engineers who would build it. The operator is described by class, never by name.

**The answer in numbers.**

| Part | The design |
| --- | --- |
| Sources joined | Panel general alarm contacts, pump controller PLC inputs and relays, submersible tank level transmitters, CT energy meters and field rounds, through LoRaWAN gateways into the operator's existing IoT platform |
| Object model | 14 typed objects and 12 links, with the monitored point as the focal object, published as JSON for reuse |
| Models | One: IBM Granite Tiny Time Mixers (TTM-R2), about 0.85 million parameters, Apache-2.0, on CPU inside the platform; threshold evaluation on the safety path is rule logic |
| Compute | None bought: the requirement asks for no server or GPU, and the field gateways carry no model runtime |
| Equipment, per factory | About 2,600 to 3,200 US dollars in list prices: a LoRaWAN gateway, two tank transmitters, two CT meters, four contact nodes, a switch, an enclosure and a UPS |
| Three-year cost, 100 factories | About 328,000 to 439,000 US dollars with support and power; the eight-factory pilot is about 21,000 to 26,000 of equipment |
| Human control | A monitoring officer acknowledges or escalates every safety-critical alert; the design monitors and never controls a panel, pump or valve |

**Reuse it.** The object model, the model register and the figures are free to reuse under CC BY 4.0. Cite as DOI <https://doi.org/10.5281/zenodo.23126565.>

**Made with.** Reasoned on [Praxis](<https://codeatoms.ai/praxis/>), CodeNinja's platform for designing physical AI systems. The object model imports into [Hyper Ontology](<https://codeatoms.ai/hyper-ontology/>), which turns it into a living system. Both are in beta; access by request.

ABSTRACT

## A Fire Estate Should Report Its Own Silence

The operation needs one answer at all hours: are the fire alarm panels, fire pumps, fire water reserves and energy feeds in its highest-risk factories alive, within limits, and provably monitored. It cannot answer that today because panel status, pump health, tank levels and meter readings sit behind separate or unmonitored equipment, and a sensor that has stopped reporting still reads as normal, so the worst failure mode is silence that looks like safety.

The design adds a read-only smart fire protection monitoring layer across the eight pilot high-risk factories: fire alarm control panel status, fire pump controllers, fire water tank level transmitters and current transformer energy meters enter through LoRaWAN field connectivity and per-site backhaul, cross two adapter families into fourteen objects and seven services surfaced on two screens, all published as one owned object model over secure MQTT into the operator's existing Saudi-hosted IoT platform, hardened to national cybersecurity controls for operational technology, with one small forecasting model running centrally on CPU inside that platform. No write path into certified fire equipment exists anywhere in the design.

The paper states the problem and its documented cost, shows why each existing system sees only one slice of fire risk, fixes the constraints, walks the stack from field sensor to dashboard, defines the object model and its typed links, specifies ingestion and state discipline, places inference, registers the model and its license, plans a four-phase rollout with exit gates and requirement coverage, assigns ownership, and closes with the Praxis chapter that records how every choice was reasoned.

---

![Figure 1. Factory Fire Watch on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.](figures/figure_01.png)

Figure 1. Factory Fire Watch on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.

## Contents

Each chapter is tagged for the reader it serves most directly: Executive, Team Lead, FDE, Reference.

|  |  |  |
| --- | --- | --- |
|  | Abstract · A Fire Estate Should Report Its Own Silence | Executive |
| PART I · THE PROBLEM | | |
| 1 | [A Silent Fire Sensor Reads as Normal](#ch1) | Executive |
| 2 | [Every Factory System Sees One Slice](#ch2) | ExecutiveTeam Lead |
| PART II · THE DESIGN | | |
| 3 | [Read-Only Safety Shapes Every Choice](#ch3) | Team Lead |
| 4 | [One Stack Runs Sensor to Dashboard](#ch4) | Team LeadFDE |
| 5 | [Fourteen Objects Turn Telemetry Into Accountability](#ch5) | FDE |
| 6 | [Every Source Enters Through an Adapter](#ch6) | FDE |
| 7 | [No Safety Decision Crosses a Network Hop](#ch7) | FDE |
| 8 | [A Small Forecaster Is the Right Size](#ch8) | FDEExecutive |
| PART III · THE ROLLOUT | | |
| 9 | [Survey the Panels Before Hardware Is Ordered](#ch9) | Team LeadExecutive |
| 10 | [The Fire Estate's Evidence Stays In-Country](#ch10) | Executive |
| PART IV · HOW IT WAS DESIGNED | | |
|  | Conclusion · Monitoring Beats Control Where Life Safety Is Certified | Executive |
| 11 | [Every Choice Traces to a Recorded Reading](#ch11) | Team LeadFDE |
|  | [Sources](#sources) | Reference |

PART I · CHAPTER 1

## A Silent Fire Sensor Reads as Normal

Fire protection failures in industry are documented, fined and fatal, and the operation's highest-risk factories cannot currently prove their own fire systems are watched.

The design summarized in the abstract turns scattered fire telemetry into one owned picture of readiness. This chapter states the question that picture answers, what it costs to leave the question unanswered today, and the ground any answer must stand on.

### 1.1  The Question, the Data and the Regimes

The question the operation needs answered is direct: at any hour, can it prove that the fire protection of every factory it classes as high risk is watched, powered, supplied with water, and reporting? Answering it requires four families of data the factories already produce but do not yet publish in one place: general alarm status, fault and disabled states from each fire alarm control panel; run status, fail-to-start and power availability from each fire pump, main, jockey and diesel alike; measured levels and alert thresholds from the fire water tanks serving suppression reserves; and energy consumption with supply quality from the distribution boards that keep all of it alive. Fire regulation worldwide takes the same shape, a duty to prevent, to monitor and to prove: United States construction rules carry a dedicated fire prevention standard (Cornell n.d.), British rules require employers to eliminate or reduce the risk of fire and explosion from work substances (HSE n.d.), and a dedicated code of practice governs fire precautions where flammable gases, liquids and dusts are handled (Standards 2012). On top of the fire code sit two national regimes: national cybersecurity and communications controls for operational technology, which govern any conduit from factory OT into an external platform, and the conformity and radio-type-approval schemes that imported gateways and instruments must clear before they touch a factory wall.

### 1.2  The Documented Cost

The cost of fire protection that fails quietly is written in public investigation records. A fertilizer facility fire and explosion in 2013 killed 15 people and injured more than 260, and the final report cited gaps in regulatory oversight and emergency response (CSB 2013). A fatal coke oven gas explosion at a steel works in 2025 drew an investigation that listed procedures, hazard analysis and facility siting among its findings (CSB 2025). The financial tail is equally documented: a record 87 million dollar fine was imposed for failing to correct safety hazards after a refinery explosion that killed 15 workers (Seattletimes 2009), and proposed fines of 16.6 million dollars across 371 alleged violations followed a fatal natural gas explosion at a construction site (ISHN 2010). Every one of these records points at the same failure surface: the state of protection was not known, or not known in time.

### 1.3  The Operation as a Scenario

The operator is a heavy industry and construction operator, running factories inside industrial cities across the country, with a factory estate in the thousands of which 100 are classed high risk. Eight of those, the most critical, form the pilot. The people in the loop are three: monitoring officers who hold dashboard entitlements and alert acknowledgement authority, technicians who walk periodic monitoring rounds, six of whom use the field data collection tool, and the certified fire protection contractors who keep the life-safety systems themselves. The physical environments are unforgiving: factory floors with mixed-brand panels, pump rooms, roof and tank installations, electrical rooms, and outdoor exposure of dust, direct sun and hose washing. The named systems number two, the operator's existing cloud-hosted IoT platform, which is the system of record and stays Saudi-hosted, and the mobile monitoring smart tool; the design reaches them through two adapter families and fourteen objects, and it never writes into a single certified fire system.

PART I · CHAPTER 2

## Every Factory System Sees One Slice

Panels, pump controllers, tanks, meters and field rounds each hold a fragment of fire readiness, and no existing view joins them into one answer.

Chapter 1 established the question and its cost. This chapter shows why no system the factories already run can answer that question alone, because each one holds a single slice of fire readiness.

### 2.1  What Each System Sees

The fire alarm control panel is the closest thing each factory has to a fire brain, and it sees, general alarm status, fault and disabled states. It misses the pumps, the water and the power, and its make, model and interface type vary by site until a survey says otherwise. The fire pump controller sees its own run status, fail-to-start signal and power availability, and it misses whether the panel is in fault and whether the tank behind it holds anything to pump. The fire water tank physically holds the suppression reserve, but it is read by intermittent gauging rather than by any instrument on the network, and a level reading that has stopped changing still looks like a normal level. The distribution boards and energy meters see consumption and supply quality, and they miss what the supply protects. The operator's IoT platform is the system of record for the wider estate's telemetry, and it holds no fire points at all today. The mobile smart tool sees whatever six users walk past on their rounds, at round intervals, and it sees nothing between rounds. Figure 2 sets these slices side by side against the question none of them can answer.

![Figure 2. Six systems, each seeing one part of the answer. the question needs all of them in one place at once.](figures/figure_02.png)

Figure 2. Six systems, each seeing one part of the answer. the question needs all of them in one place at once.

### 2.2  What None of Them See Together, and What That Costs

What none of them see together is the answer to one sentence: is this factory's fire protection watched, healthy and supplied right now? Each fragment is true alone; only the join is safety. The cost in practice is threefold: a flatlined sensor reads as normal because nothing watches the watcher; escalation runs on whoever notices first because no alert carries a severity class and an acknowledgement trail; and compliance evidence for the high-risk estate is assembled by hand from rounds and memory rather than read from one object model. Investigation reports keep finding the same shape of gap, procedures and monitoring that existed on paper but not at the moment of the event (CSB 2025).

PART II · CHAPTER 3

## Read-Only Safety Shapes Every Choice

The tender's own terms, the six-month clock, the read-only rule and national cybersecurity controls for operational technology set the boundaries the design works inside.

Chapter 2 showed five fragments that never join. The tender's own terms decide how they may be joined, and four constraints do most of the shaping.

### 3.1  Read-only Into Certified Life-safety Systems

The design monitors panels, pumps and tanks through contacts, relays and PLC IOs and never issues a command into any of them. This is hard because fire panels and pump controllers are certified life-safety equipment: any write path would drag re-certification, change control and vendor agreement into a six-month program, and it would put a monitoring layer between a person and a pump. The regulation pattern itself points the same way, since the employer's duty is to reduce risk, not to add a new failure surface to it (HSE n.d.). Read-only is therefore not caution, it is the only integration posture that fits the schedule and the certification ground.

### 3.2  The Six-month Pilot Clock

The pilot covers eight factories within six months of commencement, with liquidated damages behind it. What makes the clock hard is that the panel makes, models and interface types are unknown until a survey walks each factory, and the conformity and radio-type-approval paperwork for imported gateways and instruments sits on the critical path if ordering starts late. The design answers with a Phase 0 survey and point register before hardware is ordered, certification started at award, and an interface adapter class held in spares for every panel type the survey discovers.

### 3.3  A Silent Sensor Must Never Read as Normal

Plain telemetry that publishes last-known values cannot distinguish a healthy idle device from a dead one, and on a fire estate that is the most dangerous failure available: a tank level that has stopped changing still reads as a normal level, so no threshold ever fires. The design treats a reading that stops changing as a fault, not a reading, and builds device birth and death state, heartbeats and stuck-value detection into the publish path so a lost sensor raises an alert of its own.

### 3.4  National Cybersecurity Controls for Operational Technology

The single conduit from factory OT into an external platform is exactly what national operational technology controls govern. The design segments factory OT from the wireless field zone, authenticates every device with its own credentials and TLS operator authentication, publishes through a hardened gateway, and delivers the zone and data-flow map the controls require as an as-built document rather than an afterthought.

### 3.5  Scoping Decisions

Three scoping decisions carry the rest of the design, each buying something real at a stated price, as Table 1 records.

Table 1 · Scoping Decisions

| Decision | What it buys | What it costs |
| --- | --- | --- |
| Read-only telemetry and alerts, never control | Certified fire systems stay untouched, no re-certification, response stays with a named person | The system cannot actuate a pump or silence a panel; every response is human |
| State discipline on the publish path, where the operator's topic architecture permits | A dead or stuck sensor raises its own alert instead of reading as normal | The gateway publishing layer must follow the operator's existing MQTT topic architecture rather than its own |
| Phase 0 survey and point register before hardware order | Interface classes, gateway counts and backhaul choices are known before the bill of materials freezes | Design approval waits on field survey across eight dispersed factories |

### 3.6  What the Design Chose Against

Each rejection below was taken on a stated reason, and the last rows close the scope, as Table 2 records.

Table 2 · What the Design Chose Against

| Where | What was picked | Instead of, and why |
| --- | --- | --- |
| Backhaul at the highest-risk pilot factories | A redundant secondary path, fibre, microwave or wired, offered as a priced option | A single 4G path per gateway, because a dropped backhaul silences safety-critical telemetry exactly when it matters |
| Publishing discipline | Sparkplug 3.0.0 birth and death state and state discipline | Plain MQTT topics carrying last-known values, because a flatlined tank level reading normal is the failure the design exists to prevent |
| Integration into fire equipment | Read-only contacts, relays and PLC IOs | Any write path or command into the panels and pump controllers, which are certified life-safety systems under change control the tender never grants |
| Field compute | Gateways as radios with hours-scale store-and-forward buffers | Container workloads and inference at the edge, because no field action is gated by a model and simpler firmware survives the environment |
| Monitoring points | Panel, pump, tank level and energy only | Cameras and video analytics, which the tender never lists among its monitored points |
| Out of scope | Confirmed at pilot acceptance | Civil Defense or external alert integration, which the tender names no recipient for, and Phase 2 quantities, which are re-estimated after pilot acceptance rather than priced now |

PART II · CHAPTER 4

## One Stack Runs Sensor to Dashboard

The architecture keeps systems of record below, one object model in the middle, and services and surfaces above, with the operator's platform as the store of record.

Chapter 3 fixed the constraints: a read-only monitoring layer, no write path into certified fire equipment, and every reading landing in infrastructure the operator already owns and hosts. This chapter arranges the stack that keeps those promises from the panel contact to the dashboard.

### 4.1  One Object Model Between the Records and the Work

The pattern is systems of record below, one object model in the middle, and applications and agents above, and it fits because the RFP leaves no choice about the bottom layer: the operator's existing Saudi-hosted IoT Platform is the store of record and the MQTT broker of record, so the design builds no historian, no video layer and no edge inference runtime. What it adds is the middle. Fourteen typed objects, from the factory down to the audit log record, give every reading a home, every alert an owner and every field round a place to land. Above the model run seven services, from Architecture and Survey through Operations and Maintenance, two surfaces, the mobile monitoring smart tool and the fire pump controller view, and one model, a small time-series forecaster that runs centrally on CPU inside the platform estate.

Figure 3 shows this layering with the counts per layer. The middle layer is what makes the design one system rather than a bundle of dashboards: a stuck tank level, a pump fail-to-start signal and a technician's checklist all reconcile against the same factory record, so a query can walk from an alert to the gateway that carried it to the officer who closed it. Two plumbing choices support the whole: Sparkplug 3.0.0 state discipline on the publishing path, so silence is distinguishable from idleness, and time discipline from Chrony on each gateway, so events from mixed-brand panels can be ordered after the fact. Prometheus with Grafana dashboards observes the running system itself.

![Figure 3. The layered stack: 2 sources, 2 adapter families, 14 objects, 7 services and 2 surfaces.](figures/figure_03.png)

Figure 3. The layered stack: 2 sources, 2 adapter families, 14 objects, 7 services and 2 surfaces.

### 4.2  The Stack Stage by Stage

Table 3 walks the same stack stage by stage and names the components in each. The sensing stage is fixed by the monitored points the RFP lists: panel general alarm contacts, pump controller PLC IOs and relays, submersible tank level transmitters and CT energy meters, all carried by LoRaWAN field sensors with store-and-forward buffering. The adapter stage is deliberately narrow, two families and no direct connections, because Chapter 6 requires every source to enter through one. The inference stage is equally narrow: one zero-shot forecaster over rule-thresholded telemetry, placed centrally because no field action in this read-only design waits on a model, so field hardware carries no model-serving runtime and no container workload.

Table 3 · The Stack, Stage by Stage

| Stage | What it is responsible for | How |
| --- | --- | --- |
| Sources | Holds the records the monitoring layer reads and the store everything lands in | The operator's existing Saudi-hosted IoT Platform as store of record and MQTT broker of record, plus the mobile monitoring smart tool for field rounds |
| Sensing | Converts physical plant state into signals a network can carry | FACP general alarm status contacts, fire pump controller PLC IOs and relays, submersible fire water tank level transmitters, CT energy meters, LoRaWAN field sensors with store-and-forward buffering |
| Adapters | Form the only path any reading or record takes into the object model | Two families only: the telemetry adapter for gateway and MQTT flows, and the integration adapter for mobile tool records, with Sparkplug 3.0.0 state discipline on the publish path |
| Object model | Gives every reading, alert, round and person a typed home | Fourteen objects anchored in the operator's platform, from factory and facp through alarm\_event, field\_round, \_technician and monitoring\_officer |
| Inference | Flags leading indicators before a rule threshold does | One time-series forecaster (IBM Granite TTM-R2) running centrally on CPU inside the platform estate, feeding alerting, with no field inference |
| Services | Build, harden, commission and run the system | Architecture and Survey, Field Instrumentation, LoRaWAN Connectivity, Platform Integration, Cybersecurity and Compliance, Commissioning and Handover, Operations and Maintenance |
| Surfaces | Where people see state and act on it | The mobile data collection and reporting smart tool for six field users, and the fire pump controller view on the platform dashboards |

PART II · CHAPTER 5

## Fourteen Objects Turn Telemetry Into Accountability

A typed object model joins factories, panels, pumps, tanks, meters, gateways, alerts, audits, rounds and people so a query can reach what a document store cannot.

Chapter 4 placed one object model at the center of the stack and counted its contents. This chapter opens that model: the fourteen objects, the typed links between them, where the human beings sit inside it, and how it is hosted.

### 5.1  Fourteen Objects and What a Query Can Reach

Fourteen objects carry the design. The factory is the site object, holding its industrial city, risk classification, assigned gateways and monitored point count. Seven asset objects follow: the fire alarm control panel with its interface type and general alarm, fault and disabled states; the fire pump with its role as main, jockey or diesel and its fail-to-start signal; the fire water tank with configurable alert thresholds and an obstruction flag; the tank level transmitter with heartbeat and stuck-value state; the energy meter with per-phase current and kilowatt-hour accumulation; the LoRaWAN gateway with placement, backhaul technology and buffer state; and the monitored point that binds each reading to its source device, sampling cadence and MQTT topic. Three record and event objects close the loop: the safety-critical alert with its acknowledgement and escalation trail, the audit log record of every state transition and configuration change, and the periodic monitoring round captured in the field. Two people objects, the technician and the monitoring officer, give the model its human actors. Figure 4 draws every object and its typed links.

The links are what a document store cannot fake. From an alarm event, one traversal across typed edges reaches the monitored point that raised it, the device behind that point, the gateway that carried it, the factory it belongs to, the officer who acknowledged it and the audit record that proves it. A document store would need a hand-written join for each hop, and each join is a place where accountability quietly breaks: the alert exists in one collection, the device in another, and nothing forces them to agree.

![Figure 4. The fourteen objects of the model and the typed links that let a query reach across them.](figures/figure_04.png)

Figure 4. The fourteen objects of the model and the typed links that let a query reach across them.

### 5.2  Where the Human Loop Lives and How It Is Hosted

The human loop lives in two objects. The monitoring officer holds dashboard entitlements, alert acknowledgement authority and escalation list membership, so every alert in the Raised state has a named person whose acknowledgement moves it to Acknowledged, and every escalation is a recorded step in the object's trail rather than a message outside the system. The technician performs preventive maintenance visits against a corrective response clock, and the periodic monitoring round records what field users check on their rounds, synced through the mobile tool with a sync state of Open, Submitted or Synced.

The hosting posture follows the operator's requirement that data stay: every platform-anchored object lives in the operator's existing Saudi-hosted IoT Platform, and the design adds no store of its own. Human identity and entitlements stay in that platform rather than in a parallel directory, which the design does not replace; device identity is per-device credentials with TLS operator authentication, built inside the cybersecurity hardening item. There are no external links: no Civil Defense interface and no alert channel outside the platform, with escalation recipients confirmed with the operator. The only write path into the object model is telemetry publication and mobile tool sync, and there is no write path of any kind into the fire systems themselves.

### 5.3  One Object in Its Recorded Form

The fire water tank appears below in its recorded form, with its label, kind, properties, status vocabulary and links exactly as the object model holds them.

```
{
  "id": "factory",
  "label": "High-risk factory",
  "kind": "site",
  "anchored_in": "",
  "properties": [
    "Industrial city",
    "Risk classification",
    "Assigned LoRaWAN gateways",
    "Monitored point count"
  ],
  "status_vocabulary": [],
  "links": [
    {
      "to": "facp",
      "label": "hosts"
    },
    {
      "to": "telemetry_point",
      "label": "monitors"
    }
  ]
}
```

PART II · CHAPTER 6

## Every Source Enters Through an Adapter

Field telemetry and mobile monitoring rounds cross two adapter families with state discipline, so a device that stops reporting raises an alert of its own.

Chapter 5 gave every reading a typed home and fixed the only write path into it. This chapter describes how readings actually travel: the two source systems, the two adapter families, and the event backbone underneath both.

### 6.1  Two Source Systems, Two Adapter Families

Two named source systems exist, and Figure 5 maps each to its adapter path. The operator's existing cloud-hosted IoT Platform is the first: an operator-owned system of record, read for dashboards, entitlements and the topic architecture every publish must respect. The mobile monitoring smart tool is the second, also operator-owned, required as a data collection and reporting tool for six users performing periodic monitoring rounds; its records enter through the same model so that a field round and a live reading reconcile against one factory. Each family has exactly one adapter. The telemetry adapter receives LoRaWAN gateway traffic over the per-site backhaul and publishes it onward into the platform; the integration adapter receives mobile tool records and syncs them into the model. No source connects directly to the object model at any point, which is what makes the adapter tier auditable as a single place where provenance is stamped.

![Figure 5. The 2 named systems, the adapter path each one takes, and the object model they all map into.](figures/figure_05.png)

Figure 5. The 2 named systems, the adapter path each one takes, and the object model they all map into.

### 6.2  What the Adapter Tier Guarantees

The adapter tier makes four guarantees. First, it is read-only into fire equipment: panel general alarm status arrives through contacts, pump state through PLC IOs and relays, and no command of any kind travels the other way, which keeps the certified life-safety systems independent of the monitoring layer. Second, it applies state discipline under the Sparkplug 3.0.0 specification where the operator's topic architecture permits: each device publishes a birth certificate when it connects and a death certificate when it goes silent, so a dead sensor raises an event of its own instead of leaving a last-known value that looks normal. Third, it treats a reading that has stopped changing as a fault, not a reading: a flatlined tank level that still shows normal is the classic way a draining suppression reserve hides until it is needed, and the investigation record the US Chemical Safety Board produced after the West Fertilizer fire shows what unmonitored industrial fire risk costs when it matures (CSB 2013). Fourth, every device authenticates with its own credentials over TLS, so one compromised radio cannot impersonate another.

### 6.3  The Event Backbone

The event backbone is MQTT, with the operator's platform as broker of record. Ordering rests on two mechanisms: Chrony keeps gateway clocks disciplined against a common reference, and each message carries its event time and a sequence number, so mixed-brand sources can be ordered after the fact. Receipt is guaranteed by acknowledgement at publish and by store-and-forward buffers in every gateway, sized in hours, which hold telemetry through a backhaul outage and replay it idempotently on reconnection, so no duplicate alert is ever raised. Replication is the platform's own: because it is the store of record, the design adds no second historian, and the gateway buffers are the only replication the telemetry path needs. When the link fails, buffering absorbs it; when power fails, the gateway's clean-shutdown behavior protects buffer integrity; when the update path fails, the patching regime holds the last known-good firmware as the recovery point. Prometheus with Grafana dashboards watches the backbone itself, so a stalled adapter alerts before a missing reading does.

PART II · CHAPTER 7

## No Safety Decision Crosses a Network Hop

Thresholds fire in the platform, the single forecaster runs centrally on CPU, and nothing in this design gates a field action on inference.

Chapter 6 described how every field signal enters through an adapter and rides a disciplined publish path into the operator's platform. This chapter describes what, if anything, computes on those signals, and it arrives at an answer shaped by subtraction: the design has one inference tier, one model, and no field action anywhere that waits on a network round trip.

### 7.1  One Central Tier, Arrived at by Subtraction

Figure 6 shows the whole inference placement: a single central tier inside the operator's existing Saudi-hosted IoT platform, running on CPU, with the field edge deliberately empty of inference. The reason is stated in the operator's own requirement: no server or GPU is asked for, so the design treats CPU-only execution inside the platform as a binding constraint rather than a limitation to engineer around. The field gateways are radios with store-and-forward buffers; they carry no model-serving runtime and no container workload, because compute that is not needed at the extremity is not deployed there. The hazardous-area discipline of keeping compute out is satisfied by simply not putting compute there. The one model in the design, a forecaster described fully in Chapter 8, has roughly 0.85 million parameters and occupies about 0.003 GB at FP32 precision, small enough that the precision choice barely matters. The memory arithmetic is therefore short: weights of about 0.003 GB sit comfortably inside a fraction of any platform host's memory, and because the model is a mixer-architecture forecaster rather than an attention-based transformer, it holds no key-value cache at all, so the usual KV cache ceiling calculation is absent. The working set is the weights plus a sliding window of recent telemetry, measured in megabytes. Threshold evaluation, the safety-critical path, is pure rule logic in the platform and consumes no model capacity.

![Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.](figures/figure_06.png)

Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.

### 7.2  The Latency Budget

The budget that matters runs end to end from a field contact change to an alert a monitoring officer sees: sensor state change, LoRaWAN uplink at the point's sampling cadence, gateway publish over backhaul, adapter ingestion, threshold evaluation in the platform, and a safety-critical alert raised against the alarm\_event object for acknowledgement. The dominant terms are the LoRaWAN uplink cadence and the backhaul hop, not compute: a sub-million-parameter forecaster evaluates in milliseconds on CPU. The forecaster itself runs on a slower cadence than the thresholds, as a leading-indicator watch over tank level, pump behavior and energy rather than a gate on anything. The distinction is deliberate: industrial fire events escalate in minutes, and investigations of fatal industrial fires repeatedly trace harm to gaps in recognition and response rather than to sensor spacing (CSB 2013), so the design spends its latency budget on getting a state change to a human fast, not on inference depth.

### 7.3  What Crosses the Boundary and What Fails

Exactly one direction of traffic crosses from factory OT toward the platform: outbound telemetry, birth and death messages, heartbeats and acknowledgements, published through a hardened gateway. Nothing crosses back. No command, setpoint or panel write ever leaves the platform toward fire equipment, which is what makes the network boundary a one-way valve rather than an attack and failure surface. When the link fails, gateway store-and-forward buffers hold hours of telemetry and replay them in order on reconnection, so the platform's history fills in rather than tearing. When gateway power fails, a rugged enclosure supply with UPS and NUT-class clean shutdown lets the gateway close its session properly instead of dying mid-message, and its own state flips to offline so the loss is itself an alert. When a sensor flatlines, stuck-value detection treats a reading that has stopped changing as a fault, not a reading. When the update path fails, gateway firmware and the model artifact are versioned and patched under the operations and maintenance regime, so a missed update degrades to a tracked backlog rather than a silent drift. Every failure path ends in a state the platform can see, which is the design's central wager: a monitored system should never look healthy while it is not.

PART II · CHAPTER 8

## A Small Forecaster Is the Right Size

One sub-million-parameter time series model under a permissive license meets the CPU-only constraint and leaves the operator owning the deployed artifact outright.

Chapter 7 established that the design runs one model, centrally, on CPU, and that nothing in the field waits on it. This chapter names that model, explains why a very small one is the correct answer here, and records everything the design stands on, from weights to enclosures, in one register. Figure 7 shows the model stack in full: one model, one license, one placement. A stack of one is not an omission; it is the design matching model weight to the size of the telemetry estate and to the operator's own constraint that no server or GPU is in scope.

![Figure 7. The one model, their placement, and the work each one does.](figures/figure_07.png)

Figure 7. The one model, their placement, and the work each one does.

### 8.1  The Forecaster and Its License

The model is IBM Granite Tiny Time Mixers TTM-R2, a roughly 0.85 million parameter multivariate time series forecaster. Its architecture is a pretrained mixer designed for zero-shot and few-shot forecasting, meaning it produces forecasts on telemetry streams it was never specifically trained on and can adapt with a small number of site-specific examples during the pilot. It runs in FP32, occupying about 0.003 GB, and it runs on CPU inside the operator's existing Saudi-hosted platform, which is the binding constraint this design inherits. Its role is leading-indicator anomaly detection and forecasting over the three streams where drift precedes failure: fire water tank level, fire pump telemetry and factory energy consumption. It does not gate any field action and does not raise safety-critical alerts on its own; thresholds own that duty, and the forecaster flags slow departures from learned behavior that a fixed threshold cannot see. The license is Apache-2.0 with no field of use restriction. Its terms permit the operator to hold, modify and run the deployed artifact outright, with no copyleft trigger, no per-seat fee and no call-home condition, so the weights stay with the platform that produced the telemetry. The model was chosen over runner-ups including Chronos-Bolt and Toto because those are larger than this telemetry estate needs, and every extra parameter would buy forecast depth the monitored points cannot use while costing the CPU-only constraint.

### 8.2  The Model and Equipment Register

Table 4 records the model alongside the hardware classes, sensing choices, standing patterns and the ground the design runs on, so that every physical and software choice traces to a reason.

Table 4 · Model and Equipment Register

| The choice | What was picked | Why here |
| --- | --- | --- |
| Model | IBM Granite Tiny Time Mixers TTM-R2, about 0.85M parameters, FP32, about 0.003 GB | CPU-only forecaster inside the operator's Saudi-hosted platform; Apache-2.0 with no field of use restriction leaves the artifact owned outright |
| Hardware class | Rugged enclosure, mounting, power and UPS with NUT-class clean shutdown; IP ratings per IEC 60529; NEMA enclosure types; SABER conformity | Outdoor exposure to dust, direct sun and hose washing, with certification lead time built into the bill of materials |
| Hardware class | Fanless hardened industrial switches; copper-versus-fibre run selection | Fibre between buildings and near the high-current systems being metered; copper for short powered drops |
| Sensing | FACP general alarm status contacts; fire pump controller PLC IOs and relays | Read-only interface into certified life-safety equipment, never a write path |
| Sensing | Submersible tank level transmitters; CT energy meters; LoRaWAN field sensors with store-and-forward buffering | The four monitored point families: panel status, pump status, water level and energy |
| Pattern | Sparkplug 3.0.0 birth and death messages and state discipline | Distinguishes a healthy idle device from a dead one, so a flatlined sensor reads as a fault |
| Pattern | Read-only integration with stuck-value detection | No command ever reaches fire equipment, and a stopped reading is never mistaken for a normal one |
| Ground | The operator's existing Saudi-hosted IoT platform | The store of record by the requirement's own design; no separate historian is built |
| Ground | Chrony for time sync; Prometheus with Grafana for observability | Event ordering across gateways and visibility of the running system |

PART III · CHAPTER 9

## Survey the Panels Before Hardware Is Ordered

Four phases with item counts and exit gates settle unknown interfaces early, shadow the alerts before anyone trusts them, and cover every stated requirement.

Chapter 8 closed the design itself: one model under an Apache-2.0 license, its CPU-only placement inside the operator's platform, and the hardware classes the field estate is bought by. This chapter sets out the order of work: four phases with item counts and exit gates, the measurements the rollout takes of itself, the failure modes it plans against, the lessons it carries, and the questions it leaves open.

### 9.1  Four Phases and Their Gates

Figure 8 shows the rollout as four phases, each with an item count, workstreams and an exit gate. Phase 0, design and survey, carries three items in the Architecture and Survey workstream: the ontology foundation layer, the fire equipment site survey and point register, and the gateway placement and per-site backhaul design. Its exit gate is a per-factory point register and a justified backhaul design, approved before any hardware is ordered. Phase 1, the pilot build across the eight highest-risk factories, carries fourteen items across five workstreams: Field Instrumentation, LoRaWAN Connectivity, Platform Integration, Cybersecurity and Compliance, and Commissioning and Handover. Its exit gate is every monitored point in the register publishing into the operator's existing platform and verified end to end, with the zone and data-flow map required by the national operational technology controls handed over as an as-built record. The Phase 1 support period carries one item, operations, maintenance and local spares under the Operations and Maintenance workstream, and closes at the gate of alert acknowledgement and corrective response running to the agreed service levels. Phase 2, the full rollout, carries one item, the scalable architecture baseline for the one-hundred-factory estate, and its gate is pilot acceptance.

Requirement coverage reads five covered, none partial and none gapped, against the five stated requirements: fire alarm general alarm status visibility, fire pump operation monitoring, fire water tank level monitoring, energy consumption monitoring, and centralized telemetry published over secure MQTT into the operator's own IoT platform.

![Figure 8. The four phases and their gates, and coverage of the 5 requirements across them.](figures/figure_08.png)

Figure 8. The four phases and their gates, and coverage of the 5 requirements across them.

### 9.2  What the Rollout Measures

The rollout measures five families of evidence, all landing in the operator's platform as the same objects the estate uses, so the program's own performance is readable from the object model it builds. Sensor health: heartbeat losses and stuck-value detections raised per monitored point. Link health: gateway store-and-forward buffer depth during disconnections and the time taken to flush after recovery. Alert discipline: elapsed time from a raised alert to acknowledgement, measured against the escalation list, and escalations per severity class. Threshold behavior: breach counts per point class, with nuisance and false alerts reviewed at the support gate. Program mechanics: conformity and radio type-approval milestones tracked against the procurement schedule, because those lead times are the constraint the fixed clock actually turns on. Fire and explosion investigations repeatedly return to what the operator could see and when, and to gaps in oversight and emergency planning rather than to the absence of equipment (CSB 2013), which is why the measurements above watch the visibility layer itself and not only the plant.

### 9.3  Failure Modes and Countermeasures

The design names its own failure modes and pairs each with a mechanism already in the stack. Table 5 carries the six that matter most.

Table 5 · Failure Modes

| What fails | What the design does |
| --- | --- |
| Mixed-brand panel makes, models and interfaces stay unknown until installation | The per-factory survey runs in Phase 0 before design approval, and the Phase 1 spares inventory holds an interface adapter for every discovered panel class |
| The single cellular backhaul drops at a highest-risk factory | Store-and-forward buffering at every gateway survives disconnection, and a redundant secondary path is presented as a priced decision for the highest-risk sites |
| Gateway coverage gaps silence sensors across dispersed cities | Gateway count and placement are justified by an RF survey, and device birth and death state with heartbeats raise an alert of their own when a sensor goes quiet |
| A level transmitter flatlines and reads as a normal value | Stuck-value detection and state discipline treat a reading that stops changing as a fault, never as a reading |
| Conformity and radio type-approval lead times slip past the schedule | Certification paperwork starts at award with a local partner, and long-lead certified items are pre-ordered against the Phase 0 point schedule |
| The one conduit from factory OT is over-permissive | Factory OT is segmented from the wireless field zone, every device authenticates with its own credentials, publishing runs through a hardened gateway, and the required zone and data-flow map is produced as built |

### 9.4  Lessons

**Survey the panels before ordering a single adapter.** The most expensive unknown in this estate is the mixed-brand fire alarm panel population: makes, models and interface types cannot be settled from documents, and an interface adapter discovered after installation moves cost and schedule against the fixed clock. Phase 0 exists to convert that unknown into a counted list, and the gate refuses to release hardware orders until it is.

**A reading that stops changing is a fault, not a value.** A flatlined transmitter keeps reporting the last level it saw, every threshold looks satisfied, and a suppression reserve can drain while the dashboard reads normal. State discipline, heartbeats and stuck-value detection move that case from invisible to alerting, and it is the single most important property the telemetry path carries.

**Safety telemetry deserves its second path before it needs one.** Buffering is the minimum that keeps a disconnection from becoming data loss; the priced secondary backhaul is what keeps one dead cell or cut cable from silencing a factory. Presenting redundancy as a decision with its price attached is honest scoping, and omitting it would be the cheapest failure available in this design.

**Uncorrected hazards compound.** The enforcement record is consistent: penalties reach record sizes when hazards are identified and left uncorrected after a fatal event (Seattletimes 2009), and one fatal explosion can be followed by hundreds of alleged violations spread across the contractors on a site (ISHN 2010). A monitoring layer that proves continuous visibility and keeps its audit trail is the operator's evidence that nothing on the fire estate was left unwatched.

### 9.5  What Is Still Open

Four questions remain open, and each would change a specific part of the design when settled. The redundant secondary backhaul at the highest-risk pilot factories is priced and awaiting the operator's call; accepting it adds hardware items to Phase 1 and removes the single-path caveat from Table 5. The agentic work surface is offered, not committed; confirming it reopens the language serving tier and the frontier inference question that the model register currently carries as an unlock condition. Phase 2 quantities are not fixed in the document; re-estimating them after pilot acceptance turns the scalable architecture baseline into a priced bill of materials for the remaining factories. External alert recipients and channels are unnamed; confirming them adds an outbound integration and fixes the final hop of the escalation trail, which until then ends at the operator's own list.

PART III · CHAPTER 10

## The Fire Estate's Evidence Stays In-Country

The object model, the telemetry record, the decision record and the boundary all remain with the operator, inside its own platform and its own country.

Chapter 9 left four questions open on the table. This chapter closes the design by fixing who owns what it builds, because a monitoring layer over a life-safety estate is only worth building if the operator keeps it.

### 10.1  What the Operator Holds

The object model is the operator's: fourteen objects defined inside its existing platform, with their schema, status vocabularies and typed links exportable in full, and no vendor-held copy that the estate depends on. The weights are the operator's: the single forecasting artifact is licensed Apache-2.0 with no field-of-use restriction, runs on central processing units inside the operator's in-country platform, and the operator owns the deployed artifact outright, along with any future fine-tune of it; no license trigger exists that could recall it. The decision record is the operator's: every safety-critical alert with its acknowledgement, actor and escalation trail, and every audit log entry recording state transitions and configuration changes, stays inside the operator's platform and remains readable by the next person and the next decision. The boundary is the operator's: the design's only path into the fire estate is read-only, through status contacts, relays and controller inputs, and its only path out is outbound publishing into the in-country platform, so no command ever enters a certified life-safety system and no telemetry ever leaves the country.

### 10.2  The Offer Behind the Design

This design is CodeNinja's work, and each layer of it maps to a named element of the offer. The sensing, detection and forecasting of physical behavior across tank levels, pump telemetry and factory energy is Adaptive Operations; the fourteen-object model that turns scattered field signals into one argument is Hyper Ontology; the combination of the operator's own field hardware, an open-weight model the operator owns outright and in-country hosting on its existing platform is Sovereign Infrastructure; and the platform on which the design itself was contextualized, reasoned and recorded is Praxis.

PART IV · CONCLUSION

## Monitoring Beats Control Where Life Safety Is Certified

In one view, the design is a read-only nervous system for a fire estate: sensors and radios at the factory extremity, state discipline so a dead device announces itself, one object model the operator owns, and alerts a named monitoring officer decides on, all inside a platform and boundary the operator already holds.

Running the same shape elsewhere takes four things: a survey phase that discovers mixed equipment before hardware is ordered, published telemetry that carries birth and death state so silence is a fault, strictly read-only integration into certified safety systems, and a small central forecaster sized to the telemetry rather than to a server the operator never asked for. Any dispersed heavy industrial estate with fixed plant and safety-critical status points fits that pattern.

PART IV · CHAPTER 11

## Every Choice Traces to a Recorded Reading

The design was produced on Praxis, and this chapter lets a reader trace each decision back to the lenses, patterns and recorded evidence that justified it.

Chapter 10 fixed ownership of everything the design builds. This final chapter turns to how the design was produced: every design in the series is created on Praxis, and this chapter lets a reader trace any choice back to the lenses, patterns and recorded evidence that justified it. Figure 9 shows that trail on one page.

### 11.1  Contextualizing the Ask

The ask arrived as a request for proposals seeking a single prime contractor for a smart fire protection monitoring layer across high-risk factories in industrial cities: fire alarm general alarm status, fire pump monitoring, fire water tank levels and energy consumption over LoRaWAN field connectivity and per-site backhaul, published into the operator's existing cloud-hosted IoT platform, beginning with the eight most critical factories in a pilot and sized for a full estate of one hundred. Praxis assigned the family as industrial monitoring within heavy industry and construction, with the country set by the operator's own requirement rather than by inference. What was in the room and read in full: the request text itself; the recorded answers on server and GPU expectations, backhaul redundancy, external alerting and Phase 2 quantities; the national operational technology cybersecurity controls, whose relevant subdomain was read in full; and the published documentation of the chosen forecasting model, verified live against its source. All of it remains available on request.

![Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.](figures/figure_09.png)

Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.

### 11.2  The Eight Lenses

Table 6 lists all eight lenses, what each could see, what it cited and what it contributed. One lens returned nothing comparable and is shown as a gap; three worked from the recorded room without external citation.

Table 6 · The Lenses and What They Contributed

| Lens | Could see | Cited | What it contributed |
| --- | --- | --- | --- |
| First principles | The recorded ask and its constraints, unpacked | 2 | Fixed three load-bearing decisions: no reflex or safety decision crosses a network hop, sovereignty scored as a spectrum across data, model, infrastructure and operations, and edge buffering sized for hours of disconnection |
| Case studies | Nineteen comparable builds on the shelf | 0 | Gap: no comparable factory fire-protection telemetry build existed, and the nearest analogues stayed background |
| Tooling and recency | The verified tooling shelf | 3 | Fixed the single forecasting model against the CPU-only constraint, MQTT state discipline through the Sparkplug specification, and the observability stack, each verified against its published source |
| Hardware and equipment | Forty-three hardware records on the shelf | 4 | Named the enclosure, power, switch and cabling classes and tied conformity and radio type-approval lead times into the bill of materials |
| Rules and regulations | The national operational technology controls text | 1 | Governed the single conduit: factory OT segmented from the wireless field zone, per-device authentication, publishing through a hardened gateway, and the zone and data-flow map as an as-built deliverable |
| Approach | The monitoring patterns on the shelf | 0 | Adopted the read-only telemetry pattern with alerts and set the control-and-command pattern aside, working from the recorded room |
| History | Industry fire and enforcement records | 0 | Sharpened the stuck-sensor and uncorrected-hazard lessons that the failure-mode table carries |
| Domain fusion | Fire safety, radio planning and OT security as one field | 0 | Fused fire-domain thresholds, LoRaWAN link budgets and cybersecurity zoning into one object model and one point register |

### 11.3  Patterns Adopted and Set Aside

The design adopted four patterns and set the rest aside with reasons. It adopted read-only telemetry with birth and death state discipline, because plain topics cannot distinguish a healthy idle device from a dead one. It adopted store-and-forward buffering at every gateway, because a safety-critical path must survive its own disconnections. It adopted RF-survey-justified wireless placement, because silent sensor loss on a fire estate looks like nothing happening. It adopted a zone-segmented, outbound-only conduit, because that is what the controls require of the one path the design opens. It set aside any write path into life-safety equipment, since those systems are certified and their independence is not for a monitoring layer to disturb; a hardware data diode, since the outbound-only conduit already satisfies the controls and a diode would add permanent operational burden; separate historian and video layers, since no task in the monitored-point list names them; edge inference and container orchestration, since no inference gates a field action and gateway firmware is managed by the patching regime; and a frontier model tier, since no committed workload justifies one, a question carried open instead.

### 11.4  Where the Reasoning Lands

The reasoning lands on equipment classes rather than part numbers: the rugged enclosure, mounting, power and uninterruptible supply class with a thermal budget run before any cooling decision; the industrial switch selection class; the copper-versus-fibre rule for runs between buildings and near the high-current systems being metered; and IP rating selection read from the exposure the sites actually present, dust, sun and hose washing. Buying by class on an approved-equipment basis lets the Phase 0 survey fill in specifics without reopening the design. And that is the closing point of this chapter and of the series' method: nothing in these pages is inferred. Every object, count, gate, pattern, license term and control citation was a recorded reading, taken from the room and its sources, and this chapter is the trail back to each one.

Appendix A

## What the Monitoring Estate Costs Over Three Years

The design buys field equipment and no compute: gateways, transmitters, meters and contact nodes at each factory, read into an IoT platform the operator already runs inside Saudi Arabia. This appendix prices the estate for the hundred factories the paper classes high risk, from public list prices, dated and cited. There is no equivalent to rent: the devices sit at the factories in every option, so the only cloud line is what ingesting their messages would cost on a hyperscaler, printed for reference only, because the operator's platform is already hosted in the Kingdom and its cost is sunk. Every number can be rerun with a written quote.

### A.1 The Answer

Equipping a factory costs about **2,623 to 3,211 US dollars** in list prices, the range being the gateway class. Across 100 high-risk factories the estate costs **262,000 to 321,000 dollars**, and with support and power over three years **328,000 to 439,000 dollars**. The eight-factory pilot the paper starts with is about 21,000 to 26,000 dollars of equipment. Message ingestion on a hyperscaler outside the Kingdom would add at most about 1,188 dollars over three years, which says how little the platform cost matters next to the field estate.

### A.2 What Owning Costs

| Line | Basis | Three-year cost (USD) |
| --- | --- | --- |
| Equipment, per factory | RAK7289V2 WisGate Edge Pro, 16 channels with LTE (RAK Wireless 2026); two Milesight EM500-SWL LoRaWAN submersible level transmitters at 420 dollars (MCCI 2026); two Eastron SDM630 three-phase CT meters at 137.63 pounds (Forestrock 2026), at an assumed 1.34 dollars to the pound; four Dragino LT-22222-L LoRaWAN digital input nodes at 71 dollars for the panel and pump contacts (Embedded Works 2026); one Moxa EDS-2008-EL fanless industrial switch at 107 euros (Elmark 2026), at an assumed 1.17 dollars to the euro; one Hoffman NEMA 4X fibreglass enclosure (DigiKey 2026); one APC BR1000MS UPS (Markertek 2026) | 2,623 |
| Gateway, upper bound | Kerlink Wirnet iStation outdoor gateway at 1,112 dollars (Novotech 2026) in place of the RAK gateway | 3,211 per factory |
| Equipment, 100 factories | The paper's count of factories classed high risk, one gateway, two tanks, two meters and four contact nodes each, as the design's monitored point families | 262,000 to 321,000 |
| Support | 8 to 12 percent of equipment value a year (Introl 2026) | 63,000 to 116,000 |
| Power | 20 W a factory for gateway, switch and nodes, 52,560 kWh at the industrial tariff of 0.20 riyals per kWh (ECRA 2025) at 3.75 riyals to the dollar | 2,803 |
| **Total** |  | **328,000 to 439,000** |

The one model in the design, a 0.85 million parameter forecaster, runs on CPU inside the existing platform and adds no hardware line.

### A.3 What Ingesting the Messages Would Cost on a Hyperscaler

For reference only: the operator's platform is already hosted in Saudi Arabia. At 100 factories with 20 monitored points each sampled every 15 minutes, about 192,000 messages a day:

| Option | Basis | Three-year cost (USD) |
| --- | --- | --- |
| AWS IoT Core, Bahrain region | 1.10 dollars per million messages, 0.165 per million rules triggered and per million actions (AWS 2026); outside the Kingdom | 301 |
| Azure IoT Hub, UAE North | S1 units at 33 dollars a month for 400,000 messages a day each, 1.0 units (Azure 2026); outside the Kingdom | 1,188 |

### A.4 What the Price Does Not Include

- **Installation, cabling, RF survey and commissioning** at each factory, which the design's phase 0 survey sizes.
- **Thermal and current transformer selection** per panel and pump controller, which the site survey fixes.
- **Customs duty and 15 percent VAT** on the equipment, which a written quote delivered to the Kingdom settles.
- **Exchange rates.** The meter and switch prices are listed in pounds and euros; this appendix converts them at assumed rates of 1.34 and 1.17 dollars, stated in the table.
- **The platform's own cost**, which the operator already pays.

### A.5 Sources for This Appendix

- AWS. 2026. AWS IoT Core price list, me-south-1. <https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSIoT/current/me-south-1/index.json>
- Azure. 2026. Retail prices, IoT Hub, UAE North. <https://prices.azure.com/api/retail/prices>
- DigiKey. 2026. Hoffman A16148CHSCFG. <https://www.digikey.com/>
- ECRA. 2025. Electricity tariff, effective 28 May 2025, as reported. <https://clenergize.com/ksa-electricity-tariff-changes-in-2025-is-your-business-ready/>
- Elmark. 2026. Moxa EDS-2008-EL. <https://elmark-automation.com/shop/moxa/eds-2008-el>
- Embedded Works. 2026. Dragino LT-22222-L. <https://embeddedworks.net/product/sens648>
- Forestrock. 2026. Eastron SDM630-MBUS-MID. <https://forestrock.co.uk/product/eastron-sdm630-mbus-mid-meter>
- Introl. 2026. GPU infrastructure TCO model (support rate). <https://introl.com/blog/gpu-infrastructure-tco-model-5-year-enterprise-ai-deployment>
- Markertek. 2026. APC BR1000MS. <https://www.markertek.com/product/apc-br1000ms/>
- MCCI. 2026. Milesight EM500-SWL. <https://store.mcci.com/>
- Novotech. 2026. Kerlink Wirnet iStation 915. <https://novotech.com/products/outdoor-gateway-wirnet-istation-915-mhz>
- RAK Wireless. 2026. WisGate Edge Pro RAK7289V2. <https://store.rakwireless.com/products/wisgate-edge-pro-rak7289v2-rak7289cv2>

SOURCES

## Source Register

CSB. 2013. INVESTIGATION REPORT. <https://www.csb.gov/assets/1/6/west_fertilizer_final_report_for_website_021216.pdf?15620=>

CSB. 2025. Investigation Report. <https://www.csb.gov/assets/1/6/us_steel_clairton_investigation_report_publication_copy.pdf>

HSE. n.d.. Dangerous Substances and Explosive Atmospheres: Dangerous Substances and Explosive Atmospheres Regulations 2002. Approved Code of Practice and guidance L138. <https://www.hse.gov.uk/pubns/priced/l138.pdf>

Standards. 2012. Buy BS 5908 to 1:2012 NSAI. <https://shop.standards.ie/en-ie/standards/bs-5908-1-2012-274002_saig_bsi_bsi_631523/>

Cornell. n.d.. 29 CFR § 1926.151 , Fire prevention. Electronic Code of Federal Regulations (e-CFR) US Law LII / Legal Information Institute. <https://www.law.cornell.edu/cfr/text/29/1926.151>

Seattletimes. 2009. OSHA fines BP a record $87M for Texas refinery fix The Seattle Times. <https://www.seattletimes.com/business/osha-fines-bp-a-record-87m-for-texas-refinery-fix/>

ISHN. 2010. OSHA proposes $16.6 million in fines in connection with fatal Connecticut natural gas explosion (8/5) ISHN. <https://www.ishn.com/articles/90195-osha-proposes-16-6-million-in-fines-in-connection-with-fatal-connecticut-natural-gas-explosion-8-5>

---

### About CodeNinja

CodeNinja is a Middle Eastern-American artificial intelligence lab focused on building self-improving systems. We are reinventing knowledge work to close the loop between vertical AI use cases and the generalized intelligence that fuels it, accelerating the path toward organizational superintelligence.


---

# Field Ledger: An Open Source Agriculture Data Dashboard the Operator Fully Owns

Canonical: https://codeatoms.ai/farm-data-dashboard-pakistan/
DOI: https://doi.org/10.5281/zenodo.23186671
PDF: https://codeatoms.ai/farm-data-dashboard-pakistan/paper/field-ledger-agriculture-data-dashboard-pakistan.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

VERTICAL-DRIVEN ARCHITECTURES · AGRICULTURE & EARTH OBSERVATION · DESIGNED WITH PRAXIS · OCTOBER 2026

# Field Ledger: An Open Source Agriculture Data Dashboard the Operator Fully Owns

An ontology-anchored web dashboard that unites farm sensor feeds, historical datasets and a big data and analytics repository for an agriculture and earth observation operator in Pakistan, handed over with source code, full intellectual property and documentation.

CodeNinja Engineering Team

For the program director accountable for the federal agriculture productivity pilot, the farm operations and data managers who will use the dashboard, and the integration, and data engineers who would build and run it.

---

Vertical-Driven Architectures is a CodeNinja series of system designs. Every design in the series is driven by a real-world problem and scenario in a single industry, and every one is designed on Praxis, CodeNinja's platform for designing physical AI systems. Operations are described by class, never by name.

At a glance

## An open-source agriculture data dashboard in Pakistan

**What this is.** An open reference architecture for system design in physical AI: one dashboard that joins a farm's live sensor feeds, its historical datasets and a big data and analytics repository into one object model, so any farm, crop cycle or season can be drilled into, exported and reported on under role-based access. It is written for the program director of a federal agriculture productivity pilot and for the data, integration and platform engineers who would build it. The operator is described by class, never by name.

**The answer in numbers.**

| Part | The design |
| --- | --- |
| Sources joined | 3: the site sensor feeds, the historical datasets and the big data and analytics repository, through 2 adapter families |
| Object model | 12 typed objects, from farm site and field to crop cycle, sensor reading and alert, published as JSON for reuse |
| Models | None: the analytics are deterministic aggregations, drill-down and reporting |
| Stack | Open-source PostgreSQL with PostGIS on the operator's own servers; source code and full intellectual property handed over |
| Three-year cost | No hardware line to price: the cost is the integration and software work (Appendix A) |
| Human control | Every alert is acknowledged by a named user under a role the operator assigns |

**Reuse it.** The object model, the model register and the figures are free to reuse under CC BY 4.0. Cite as DOI <https://doi.org/10.5281/zenodo.23186671.>

**Made with.** Reasoned on [Praxis](<https://codeatoms.ai/praxis/>), CodeNinja's platform for designing physical AI systems. The object model imports into [Hyper Ontology](<https://codeatoms.ai/hyper-ontology/>), which turns it into a living system. Both are in beta; access by request.

ABSTRACT

## One Dashboard Cannot Answer What Three Systems Hold Apart

The operation needs one question answered: for any farm, any crop cycle and any season, what do the sensor feeds, the historical datasets and the big data and analytics repository say together, and can a named person drill down, export and report on the answer under role-based access? Today it cannot be answered, because the live site sensor feeds, the historical datasets and the repository live in separate systems whose formats, volumes, refresh rates and interfaces are not stated anywhere in the requirement, so no single view, however well charted, can reconcile them until the integration contracts themselves are discovered.

The design is a milestone-phased, open-source agriculture data dashboard built as an ontology-first integration: three source systems, the site sensor feeds, the historical datasets and the big data and analytics repository, enter through two adapter families into a twelve-object ontology projected as a versioned schema inside an open-source PostgreSQL database with PostGIS, running on the operator's own on-premises servers. Six services, from data integration and foundation through dashboard and analytics, security and access, operations and handover, feed two surfaces: the agriculture data food security dashboard and an administration console. No model is committed this run; the analytics are deterministic aggregations, drill-down and reporting, and every figure the dashboard shows is reproducible from the operator's own data.

The paper sets out the problem and the join failure across the three systems, then the design: the contract- constraints, the layered stack, the object model with one object in its recorded form, ingestion through the adapter tier, where aggregation runs and why the model register is honestly empty. Part III covers the four-milestone rollout with fifteen items, exit gates and failure modes, and who owns what is built. Part IV closes with how the design was produced on Praxis, so every choice traces back to what justified it.

---

![Figure 1. Field Ledger on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.](figures/figure_01.png)

Figure 1. Field Ledger on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.

## Contents

Each chapter is tagged for the reader it serves most directly: Executive, Team Lead, FDE, Reference.

|  |  |  |
| --- | --- | --- |
|  | Abstract · One Dashboard Cannot Answer What Three Systems Hold Apart | Executive |
| PART I · THE PROBLEM | | |
| 1 | [Farm Data Exists but No Question Can Reach It](#ch1) | Executive |
| 2 | [Every Repository Sees One Slice of the Farm](#ch2) | ExecutiveTeam Lead |
| PART II · THE DESIGN | | |
| 3 | [Four Contract Terms Shape Everything Downstream](#ch3) | Team Lead |
| 4 | [One Open Stack Runs From Records to Surfaces](#ch4) | Team LeadFDE |
| 5 | [Twelve Objects Turn Farm Data Into One Argument](#ch5) | FDE |
| 6 | [Every Source Enters Through an Adapter, Never Directly](#ch6) | FDE |
| 7 | [Aggregation Runs Where the Data Lives, Not Beside It](#ch7) | FDE |
| 8 | [An Empty Model Register Is an Honest One](#ch8) | FDEExecutive |
| PART III · THE ROLLOUT | | |
| 9 | [A One-Farm Prototype Answers Before Scale Is Priced](#ch9) | Team LeadExecutive |
| 10 | [The Whole Argument Stays with the Operator](#ch10) | Executive |
| PART IV · HOW IT WAS DESIGNED | | |
|  | Conclusion · Integration, Not Intelligence, Is the Product Here | Executive |
| 11 | [Every Choice Here Traces to a Recorded Reading](#ch11) | Team LeadFDE |
|  | [Sources](#sources) | Reference |

PART I · CHAPTER 1

## Farm Data Exists but No Question Can Reach It

The operator holds live sensor feeds, historical datasets and a big data and analytics repository, yet the question a federal agriculture productivity pilot exists to answer, what a farm did and why, spans all three and is answerable by none alone.

The abstract sketched the shape of the answer, an ontology-anchored dashboard over three data estates, phased in four milestones and transferred with source code and full intellectual property. This chapter establishes the question that design exists to answer, the data and the rules the answer depends on, and the operation as a scenario.

### 1.1  The Question, the Data It Requires and the Regulatory Ground

The question the pilot exists to answer is deceptively plain: on each farm, in each crop cycle, what happened this season and why. Answering it needs three kinds of data at once: live sensor readings for current soil and irrigation conditions, historical datasets that carry seasons past, and the record held in the big data and analytics repository, BDAR, where datasets and publications sit with their access rights. A reading only becomes an answer when it is placed against a crop cycle, a field and a baseline, and no single estate holds all three. The regulatory ground is federal procurement law plus national data governance. The pilot is funded as a public sector development program project, and the dashboard is procured through the national electronic procurement system under single stage two envelope rules. Beyond procurement, four governance regimes touch the design: a federal cloud first policy that shapes where agricultural data may be hosted, the cybercrime statute that covers offences against the data systems, telecom type approval that would apply if any field radio were added, and the surveying and mapping act that governs publishing geospatial boundaries. Each turns on a fact the requirement does not state, so each is carried as an open question rather than a settled constraint.

### 1.2  The Documented Cost of the Problem

The cost has two layers. The first is opportunity: the operator already holds every byte the question needs, yet the join across live readings, history and the published record happens, when it happens at all, by hand in spreadsheets, so season decisions wait on individual analysts and their private stitching of fragments. The second layer is documented in the public record on programs like this one. The World Bank cites United Nations estimates that about one trillion US dollars is paid in bribes and 2.6 trillion US dollars is stolen through corruption every year worldwide (World Bank 2020), and agriculture is not exempt: a European Union special report on the common agricultural policy lists public procurement fraud, including collusion between bidders, fictitious subcontracting and falsification of documents, among the risks such programs must manage (European Court of Auditors n.d.). The United States Government Accountability Office found that selected federal programs did not fully include recognized requirements and leading practices for preventing fraud, waste and abuse (GAO n.d.). For a fixed-price pilot of this kind, that record argues for a rollout in which spend is gated on evidence at each milestone rather than committed up front against unstated interfaces.

### 1.3  The Operation as a Scenario

The operator is an agriculture and earth observation operator in Pakistan executing a federal agriculture productivity pilot. It runs a small estate of farm sites and plots instrumented with sensors measuring soil and irrigation parameters, contributes to and draws on BDAR, and holds a library of historical datasets with stated coverage periods and formats. The scale is banded: one farm site anchors the phase-one prototype, a modest number of sites make up the full integration, and the requirement names no city, site or plot. The people in the loop fall into four functions: farm staff and researchers who generate the data, analysts and project staff who would consume the dashboard, administrators who would run access and the, and the repository administrators on the BDAR side whom the operator coordinates with. The requirement requires role-based access control but names no roles, so the role list is itself an open question. The physical environments are open cultivated wheat plots, tilled along irrigation lines and greenhouse seedling aisles, sensed by fixed instruments rather than watched by cameras. The named counts are small and fixed: three named source systems, two adapter families, twelve objects, six services, two surfaces, zero models, four milestones and 23 tracked requirements, all inside one country of operation.

PART I · CHAPTER 2

## Every Repository Sees One Slice of the Farm

The site sensor feeds see the present, the historical datasets see the past, and the big data and analytics repository sees the record; none of them joins crop cycle to reading to dataset, and the cost of that gap is a dashboard that charts fragments instead of answering questions.

Chapter 1 framed the question, what a farm did this season and why, and the three estates that between them hold every piece. This chapter walks each estate, shows what it sees and what it misses, and names the join none of them performs.

### 2.1  What Each System Sees

BDAR sees the record. It holds curated datasets and publications with their authors, coverage periods, formats and access rights, and it is the estate the operator coordinates with through its administrators rather than through a stated interface. What it misses is everything live and everything in the field: no current reading, no plot geometry, no crop cycle that would say which season a dataset should be compared against. The site sensor feeds see the present. Devices across the farm sites report parameters such as soil and irrigation state, each reading stamped with a device, a timestamp and a value. What they miss is context in both directions: no history beyond their own retention, no link to the crop cycle a reading belongs to, and no connection to the published record that would say whether a reading is normal for this plot, this variety and this week of the season. The historical datasets see the past. They carry seasonal and series with source agency, format and coverage period, and they are the estate a trend or comparison analytics view is built on. What they miss is the live layer and the identity of the plot and cycle they should join to; a historical series without a join key to the current season is an archive, not a baseline.

### 2.2  What None of Them See Together

Figure 2 sets the three estates side by side, and the figure's convergence point is the question none can answer alone: join this season's crop cycle to its sensor readings and to the historical and published record, and say what a farm did and why. That join requires a crop cycle object, a reading, a dataset and typed links between them, and no source system carries the links. The cost in practice is a dashboard that charts fragments: a curve without a baseline, a dataset listing without a season, a report assembled by hand each time the pilot must account for itself. Meaning ends up living in individual analysts, and meaning left in people decays as staff turn over. Figure 2's summary rows follow.

![Figure 2. Three systems, each seeing one part of the answer. the question needs all of them in one place at once.](figures/figure_02.png)

Figure 2. Three systems, each seeing one part of the answer. the question needs all of them in one place at once.

PART II · CHAPTER 3

## Four Contract Terms Shape Everything Downstream

An open-source mandate, a fixed price, a source code and intellectual property transfer, and unstated data interfaces are the four forces that decide the architecture, and each one buys something at a stated cost.

Chapter 2 showed the gap the dashboard exists to close and why adapters, not charts, are the real build. This chapter sets out the four forces that bound the architecture before any component is chosen, then records what the design scoped in, what each choice buys and what it costs.

### 3.1  The Open-Source Mandate

The requirement requires an open-source web dashboard over an open-source database backend. This is hard in agriculture because the sector's analytics tooling is dominated by proprietary platforms and hosted services, and an open-source mandate disqualifies most shelf products before their features are even weighed. It is also the force that makes the design ownable: every layer must be licensable for the operator to hold, run and extend.

### 3.2  The Fixed Price

The contract is fixed at PKR 8.80 million, and the effort it must cover depends on data interfaces the requirement does not state. That combination is the engagement's central risk: integration effort on unstated formats can absorb a fixed budget quietly. The design answers with phase-one discipline, a small integration prototype on one farm site and one BDAR dataset that measures the per-farm integration slope before full-farm spend is committed, with later milestone pricing stated against that evidence.

### 3.3  The Source Code and Intellectual Property Transfer

The requirement transfers source code and full intellectual property to the operator, together with documentation and staff training for independent operation. This rules out any proprietary component in the critical path, because a closed dependency would sit inside a transfer that cannot carry it. It also raises the bar on the artifacts themselves: versioned schema, mappings and documentation must be complete enough for the operator's own engineers to run the system without the builder.

### 3.4  The Unstated Interfaces

The BDAR interface, its location and what it exposes are not stated; sensor formats, volumes and refresh cadences are unknown; the server specification is assumed but unspecified. The design therefore treats the two adapter families, one integration adapter for BDAR and historical datasets and one telemetry adapter for the sensor feeds, as the core build, with the integration contract register as a phase-one output produced with the repository administrators in the room.

### 3.5  Scoping Decisions

Three scoping decisions carry the design, each buying something specific at a stated cost; Table 1 records them.

Table 1 · Scoping Decisions

| Decision | What it buys | What it costs |
| --- | --- | --- |
| Integration prototype on one farm site and one BDAR dataset before full integration | Measured evidence on formats, volumes and join quality before the fixed budget is spent | Answers about full-farm behavior wait until the prototype's verdict |
| Ontology as a versioned schema and mapping layer inside PostgreSQL with PostGIS | One open-source system of record the operator owns outright, with the twelve objects projected over it | Graph questions run as SQL joins rather than native graph traversal |
| A hardened open-source BI layer over the committed backend | Proven visualization, drill-down, export and role-based access without bespoke build cost | The dashboard's look and interaction patterns follow the BI layer's conventions |

### 3.6  What the Design Chose Against

Every rejection below keeps the design inside the four forces; Table 2 records where, what was picked, instead of what, and why, ending with what is out of scope entirely.

Table 2 · What the Design Chose Against

| Where | What was picked | Instead of, and why |
| --- | --- | --- |
| Data movement | Scheduled batch pulls through the two adapter families | A streaming backbone, because sensor cadences and volumes are unstated and streaming infrastructure would be premature before the prototype settles them |
| The object model | A versioned schema and mapping layer inside PostgreSQL with PostGIS | A separate graph database product, because the open-source mandate and the fixed price favor one database the operator owns outright |
| The dashboard surface | A hardened open-source BI layer | A bespoke web application built from scratch, because proven software beats hand-built code on this budget and survives the intellectual property transfer |
| Inference | Deterministic aggregations, drill-down and reporting | A trained forecasting model, because the requirement's analytics are aggregations and no forecaster can be specified before integration is measured |
| Out of scope | Existing farm sensors and operator-provided servers, storage and connectivity | New field hardware, cameras, edge compute and sensing of any kind, because the sensing estate already generates the data and the operator provides the infrastructure |

PART II · CHAPTER 4

## One Open Stack Runs From Records to Surfaces

The architectural pattern fits because the systems of record stay below untouched, one object model sits in the middle as a projection rather than a copy, and the services and surfaces above read from it, all on the operator's own servers under open-source licenses.

Chapter 3 fixed the constraints that shape everything downstream: an open-source stack the operator owns outright, integration treated as the product rather than a preliminary, no hardware procurement, and a first milestone that settles the unknown data formats cheaply. This chapter shows the stack those constraints produce, layer by layer, and names every component in it.

### 4.1  Three Layers in a Fixed Order

The architectural pattern is a system of context: three layers in a fixed order, with nothing between them allowed to shortcut. At the bottom sit the systems of record: the big data and analytics repository known as BDAR, the site sensor feeds, and the historical datasets. They are never replaced, never modified and never loaded into a shadow copy; the design reads them where they live, through adapters, exactly once. In the middle sits one object model, a projection over those records rather than a duplicate of them: twelve typed objects held as versioned schema and mapping definitions inside PostgreSQL, the open-source relational database, with PostGIS, its geospatial extension, carrying the field boundary geometry. Above sit the applications: six services and two surfaces that read the projection and never touch a source directly.

This pattern fits here for three reasons that the terms of reference force. First, the requirement commits an open-source web dashboard with an open-source database backend, and it transfers source code and full intellectual property to the operator, so the middle layer must be schema the operator owns; no shelf analytics product carries a published license that survives those terms. Second, no model is committed this run: the analytics are deterministic aggregations, drill-down and reporting, so the middle layer needs no feature store or vector index, and a disciplined relational projection with typed links is enough. Third, the budget is fixed, so one database engine carries the ontology, the sensor time series and the operational metadata together, avoiding a second system of record that the operator would have to run and eventually hand over twice.

Figure 3 shows the layered stack with its counts per layer: three sources below, two adapter families, twelve objects in the projection, six services, two surfaces, and zero models this run. The kinetic loop of the pattern, sense, decide, act and learn, stays deliberately read-only at the act step: the people who use the dashboard act on its outputs inside the tools they already operate, so the design closes the loop through alerts and reports rather than through automated control of anything in the field.

![Figure 3. The layered stack: 3 sources, 2 adapter families, 12 objects, 6 services and 2 surfaces.](figures/figure_03.png)

Figure 3. The layered stack: 3 sources, 2 adapter families, 12 objects, 6 services and 2 surfaces.

### 4.2  The Stack Stage by Stage

Table 3 walks the same stack stage by stage, naming what each stage is responsible for and how it discharges that responsibility. The stages are read top to bottom in the order data flows: sources hold the records, sensing describes what the estate already generates, adapters carry records in, the object model turns them into one queryable argument, inference names what reasons over it, services assemble the capabilities, and surfaces put them in front of people.

Table 3 · The Stack, Stage by Stage

| Stage | What it is responsible for | How |
| --- | --- | --- |
| Sources | Holding the three records the dashboard reads: the BDAR repository, the site sensor feeds and the historical datasets | Left untouched in place; the operator provides hosting infrastructure and connectivity and coordinates with the repository administrators |
| Sensing | Describing what the estate already senses: in-field instruments measuring soil and parameters as time-stamped readings | No new hardware is procured; cameras, edge compute and field radios are out of scope because the sensors already exist |
| Adapters | Being the only path data takes into the stack: one integration adapter for the repository and historical datasets, one telemetry adapter for the sensor feeds | Scheduled pulls governed by a contract register, with provenance stamped on every record and unknown formats settled before the first read |
| Object model | Twelve typed objects that turn scattered records into one argument a query can traverse | Versioned schema and mappings projected inside PostgreSQL with PostGIS, never a shadow copy, with typed links naming every relationship |
| Inference | Nothing this run: every analytic is a deterministic aggregation, drill-down or report computed from the object model | A time-series forecaster over the sensor readings stays open work until the integration prototype measures the real feed cadence |
| Services | Six services: Data Integration, Foundation, Dashboard and Analytics, Security and Access, Operations, and Handover | Open-source components the operator owns outright, assembled so each service reads from the object model and never from a source |
| Surfaces | Two surfaces: the Agriculture Data Food Security Dashboard and the administration console | Web interfaces over the services, with role-based access deciding who sees which data and who changes which object |

PART II · CHAPTER 5

## Twelve Objects Turn Farm Data Into One Argument

Farms, crop cycles, sensor devices and readings, datasets, publications, users, roles, alerts, reports and data source connections form a typed graph whose crossing links answer what no single store can, with the human loop and the only write path living in the alert and access objects.

Chapter 4 placed one object model in the middle of the stack as a projection the services read and the sources never feel. This chapter names the twelve objects in that projection, the typed links that join them, and the one place in the graph where a person's hand changes state.

### 5.1  Twelve Objects and the Links Between Them

The twelve objects group into four families. The estate objects are the site, a farm with its name, location, crops under cultivation, sensor count and connectivity status; the field, a plot with area, soil type, crop variety and boundary geometry; and the crop cycle, a season on a plot that moves through planned, sown, growing and harvested. The measurement objects are the sensor device, with its parameter, position and health, and the sensor reading, the timestamped value and unit it produces. The knowledge objects are the historical dataset and the publication, both anchored in the BDAR repository rather than in the dashboard's own store. The governance objects are the dashboard user and the access role. The working objects are the alert, the report, and the data source connection, which records each source's protocol, refresh cadence and last successful pull.

Figure 4 draws the objects and their typed links. A field carries crop cycles; a publication relates to the crop cycles it concerns; a dataset's access rights are restricted by an access role; a user holds a role and a role governs a dashboard scope; an alert points to the sensor device and the sensor reading that triggered it; a data source connection feeds the site it serves. Typed means each link names its relationship, such as hosts or triggers, rather than leaving the meaning of a foreign key to guesswork, so a traversal carries its own explanation.

The reach across these links is what a document store cannot give. Consider the question an operations officer actually asks when an alert fires: is the crop at risk, and what does the institution already know about this variety? Starting at the alert, one traversal reaches the sensor reading and its device, the device's field, the field's current crop cycle, and every publication in the repository tagged to that crop. A document store holds each of those as a flat record keyed by identifiers; it cannot follow the edges, so the officer assembles the answer by hand across five stores. The graph answers the crossing question in one query, and that is the argument the twelve objects exist to make.

![Figure 4. The twelve objects of the model and the typed links that let a query reach across them.](figures/figure_04.png)

Figure 4. The twelve objects of the model and the typed links that let a query reach across them.

### 5.2  Where the Human Loop and the Write Path Live

The human loop lives in three objects, and every state change in them is a named person's decision. An alert moves from open to acknowledged to resolved, and its acknowledged by property records who took it. A report moves from draft to final. A dashboard user and an access role are themselves created, suspended and disabled by an administrator, whose identity the console records.

The hosting posture follows from the operator's stated requirement for the country. The servers are the operator's own, on premises in Pakistan, so the data residency boundary is the operator's estate and nothing in the design copies records outside it. Identity is role-based access control implemented inside the same open-source stack; the requirement requires the controls but does not name the roles, so the role list is settled in a design workshop before any access rule is written. External links exist only as properties, such as the repository link on a publication, which a user clicks by choice; rendering the dashboard sends nothing out. The only write path into the graph runs through the five objects the dashboard owns natively, the alert, the report, the dashboard user, the access role and the data source connection. Everything downstream of the adapters is a read-only projection, so no dashboard action, however mistaken, can alter a record in the systems of record below.

### 5.3  One Object in Its Recorded Form

Sensor Reading is the object the daily argument rests on, and it is shown below in its recorded form: the timestamped value, its parameter and unit, and the source device it came from.

```
{
  "id": "the-site",
  "label": "The site",
  "kind": "site",
  "anchored_in": "",
  "properties": [
    "Farm name",
    "Location",
    "Crops under cultivation",
    "Number of sensors",
    "Connectivity status"
  ],
  "status_vocabulary": [
    "Online",
    "Degraded",
    "Offline"
  ],
  "links": [
    {
      "to": "the-field",
      "label": "contains"
    }
  ]
}
```

PART II · CHAPTER 6

## Every Source Enters Through an Adapter, Never Directly

The integration adapter and the telemetry adapter are the real deliverable: they carry provenance classes, buffer scheduled pulls, and guarantee that unknown formats are settled in a contract register before anything reads from them.

Chapter 5 defined the twelve objects and the single write path into them. This chapter describes how everything else gets in: three sources entering through two adapter families, the guarantees those adapters make, and the batch backbone that carries the pulls.

### 6.1  Three Sources, One Provenance Class, Two Adapters

The design names three source systems, and all three share one provenance class. BDAR, the operator's big data and analytics repository, holds the historical datasets and the publications the dashboard must integrate with; the operator provides the hosting infrastructure and coordinates with the repository's administrators, who control what the repository exposes. The site sensor feeds generate live readings and form the dashboard's operational layer. The historical datasets, read through and alongside the repository, carry the trend and comparison layer. All three are read-only from the dashboard's side, and all three are operator-held, meaning every record originates inside the operator's own estate and never leaves its boundary. Figure 5 draws the integration map: each named source, its provenance class, and the adapter path it enters through.

The requirement states no protocol or format for any of the three, and that omission is the plan's central risk, which is why the adapters are the core build rather than a preliminary. Two families cover the three sources: the integration adapter serves BDAR and the historical datasets, whether they arrive as database endpoints, file exports or scheduled extracts, and the telemetry adapter serves the sensor feeds, whatever instrument protocols the discovery item finds. Each source enters through exactly one adapter path, and each path is specified in a contract register before the first pull.

![Figure 5. The 3 named systems, the adapter path each one takes, and the object model they all map into.](figures/figure_05.png)

Figure 5. The 3 named systems, the adapter path each one takes, and the object model they all map into.

### 6.2  What the Adapter Tier Guarantees

The adapter tier makes five guarantees. First, no direct reads: services and surfaces connect only to the object model, never to a source. Second, contract before read: every source receives an entry in the integration contract register stating its format, interface, refresh cadence, keys and credential owner, agreed with that source's administrators before any adapter reads from it, and the register is a milestone one gate. Third, provenance on every record: each row carries its source connection and pull timestamp, so a join against historical data shows its lineage and a weak source is visible instead of silently averaged. Fourth, idempotent pulls: replaying a pull never duplicates readings, because upserts key on the source's natural key and timestamp. Fifth, schema drift alarms: a renamed column or a changed unit flips the data source connection to failed rather than writing wrong values forward.

The register also carries public accountability weight. This is a federally funded pilot procured under public rules, and the audit literature on such programs is blunt: European Union audits of agricultural subsidy spending list falsified documents and fictitious subcontracting among the procurement fraud modes they pursue (European Court of Auditors n.d.); the United States Government Accountability Office found selected federal programs that did not fully include recognized requirements and leading practices for preventing fraud, waste and abuse (GAO n.d.); and United Nations estimates cited by the World Bank put about one trillion dollars paid in bribes and about 2.6 trillion dollars stolen through corruption worldwide every year (World Bank 2020). An auditable record of what entered the system, when and from where, is the cheapest integrity control a pilot of this kind can hold.

### 6.3  The Event Backbone

The design commits no streaming infrastructure, deliberately. Sensor formats, volumes and refresh rates are not stated, so the integration may be batch or scheduled pulls, and a message broker would be premature until the milestone one prototype settles the real cadence. In its place stand three mechanisms. Ordering: every record carries its source timestamp plus an ingest sequence assigned on arrival, queries sort on the source timestamp, and missing windows surface as feed faults instead of being smoothed over. Delivery: at-least-once, made safe by the idempotent upserts above. Buffering and replication: adapters write into staging tables inside the same PostgreSQL estate, so a missed window re-pulls rather than losing data, and the database replicates by streaming replication to a standby within the same estate, with nothing copied past the operator's boundary.

Failure behavior closes the loop: a feed that stops, or a gap in the readings during irrigation stress, which is precisely the fault the rollout watches for, flips the connection status to failed and raises an alert on the dashboard surface for a named person to acknowledge.

PART II · CHAPTER 7

## Aggregation Runs Where the Data Lives, Not Beside It

No inference tier is procured because the committed analytics are deterministic aggregations, drill-down and reporting executed inside the open-source database, and the latency budget is therefore a query and render budget on the operator's network.

Chapter 6 described how every source enters through an adapter on a scheduled pull, with the data source connection object recording the last successful pull per feed. This chapter describes where the computation happens once the data lands, and it makes an argument that runs against the habit of this series: nothing needs to be inferred, so nothing needs a model server.

### 7.1  One Tier of Computation, Inside the Database

Figure 6 shows an inference placement diagram with one active tier, and that tier is not a model server. It is the open-source database engine running on the operator's own on-premises servers, in Pakistan, executing every committed analytic as a deterministic query: aggregations over sensor readings and historical datasets, drill-down from farm to field to crop cycle to individual device, and the scheduled and ad hoc reporting that the report object captures.

The reason is arithmetic before it is philosophy. The requirement commits no machine learning: the analytics it asks for are aggregations, drill-down and reporting, and no model was verified for this design. An aggregation that runs in seconds inside the engine that holds the data does not justify a second system, and the stack review set aside edge model serving, on-site language model serving and edge orchestration of containers for exactly this reason: the objects of this design are farms, sensors and datasets, nothing moves and gets tracked, and users act on outputs inside tools they already use.

Papers in this series normally carry a memory arithmetic at this point: model weights against usable memory, and the token budget that bounds the key-value cache. Here that arithmetic has no terms to carry, because the register holds zero parameters. What replaces it is a storage and working-memory question: time-series rows accumulated per device, the spatial indexes over field boundary geometry, and the concurrent query buffers that drill-down sessions consume, all sized against the recorded server specification at the Milestone 1 kick-off. That sizing is an item with a gate, not a guess carried into the build.

![Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.](figures/figure_06.png)

Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.

### 7.2  A Query and Render Budget

The latency budget is therefore not a token or first-token budget; it is a query-and-render budget on the operator's own network, and it decomposes into three measured components: the refresh cadence of each data source connection, the execution time of each dashboard query, and the render time of the visualization layer.

The budget is set at a gate rather than asserted now. Milestone 3 carries the monitoring item, and the system monitoring metrics the requirement requires record usage and performance per dashboard panel, so the execution times are measured on real volumes before full-farm integration is priced. A panel that cannot render inside an interactive session is treated as a defect against the requirement, not as a tuning backlog.

### 7.3  What Crosses the Boundary, and What Fails

What crosses a network boundary is narrow and read-only: sensor pulls from the farms onto the hosting servers, scheduled pulls from the historical datasets and the big data and analytics repository, and exports in CSV, Excel or PDF onto the machines of named users. Nothing leaves the operator's boundary, and nothing writes back into a system of record, which keeps the kinetic loop read-only by design.

Three failure paths are designed for. If the link fails, the affected data source connection records the failed status, its last successful pull timestamp freezes, and dashboards show staleness instead of freshness; a sensor feed gap during irrigation stress is exactly the condition the alert object is built to surface as an open alert acknowledged by a named person. If power fails, the servers restart into the same schema, and the frozen pull timestamps mark the gap so the analytics never average over it silently. If the update path fails, the ontology's versioned schema and mappings inside the database roll back to the previous version, because the upgrade is a migration the operator owns, not an external service.

PART II · CHAPTER 8

## An Empty Model Register Is an Honest One

The requirement commits no machine learning and no model was verified for this design, so the register records zero models, a forecaster over sensor time series stays open work, and what the operator is licensed to own is settled instead by the open-source licenses on the stack itself.

Chapter 7 argued that every committed analytic runs as deterministic SQL inside the database, and that no compute tier is procured. This chapter draws the honest consequence for the model register and settles, through the licenses on the stack itself, what the operator is entitled to own.

![Figure 7. The zero models, their placement, and the work each one does.](figures/figure_07.png)

Figure 7. The zero models, their placement, and the work each one does.

### 8.1  The Register Holds Zero Models, by Decision

Figure 7 shows the model stack for this design, and its model shelf is empty by decision rather than by oversight. Each entry in this section would normally carry a name, a parameter count, an architecture, a context window, a placement and a license; the requirement commits aggregations, drill-down and reporting, and no model was verified for this run, so the prose list is the empty list, recorded as such.

That emptiness is the design's most defensive claim. The open work it protects is a forecaster over sensor time series: if Milestone 1 shows that measured volumes and join quality support one, a forecaster would run in the same tier as the aggregations, reading the same sensor reading history, and its labelling loop would be scoped then rather than promised now.

What the operator owns instead is settled by the open-source licenses on the stack. The database engine ships under a permissive license that permits use, modification and redistribution with attribution conditions the operator meets trivially. The spatial extension carries copyleft terms: if the operator distributes a modified version, those modifications must be shared under the same license, but in-house use on its own servers triggers nothing, so copyleft costs this operator nothing. The BI layer of the Superset class sits under a permissive license that lets the operator's own dashboard modules remain its property. Combined with the requirement's requirement for source code and full intellectual property transfer, the operator ends up holding the schema, the mappings, the dashboard definitions and every line of the stack, which is the ownership outcome a model register would have complicated, since closed or restricted weights cannot be transferred as intellectual property.

An honest register also protects the buyer in a setting where the risk runs the other way: procurement fraud in agricultural support programs is documented in public audits (European Court of Auditors n.d.), and oversight bodies have found programs that did not fully apply recognized practices against fraud, waste and abuse (GAO n.d.). A bid that promises no analytics it cannot evidence is the defensible one.

### 8.2  The Model and Equipment Register

Table 4 records what the design commits where a model register would normally speak: the empty model row, the hardware position, the sizing rule, the sensing, the pattern the design stands on and the ground it runs on.

Table 4 · Model and Equipment Register

| The choice | What was picked | Why here |
| --- | --- | --- |
| Model | Zero models committed; a forecaster over sensor time series stays open work gated on Milestone 1 evidence | The requirement commits aggregations, drill-down and reporting, and no model was verified for this run |
| Hardware class | No compute procured; all compute runs on operator-provided servers, storage and connectivity | The operator provides the hosting infrastructure and the sensors already generate the data, so no field compute or inference server is bought |
| Sizing rule | Database and buffer sizing set against the recorded server specification at the Milestone 1 kick-off, re-estimated on measured sensor volumes before full-farm integration | Sensor formats, volumes and refresh rates are settled by the prototype, not assumed at bid time |
| Sensing | The operator's existing sensor devices, read-only; no cameras and no new field hardware | The world is sensed by farm rather than watched, and the engagement installs no equipment |
| Pattern | System of Context, with the ontology as a versioned schema and mapping projection inside the database | Farm, field, crop cycle, sensor device and dataset objects answer the cross-system questions no single source can |
| Ground | Open-source PostgreSQL with PostGIS, on operator premises in Pakistan, under permissive and copyleft open-source licenses | The open-source database mandate and the source code and intellectual property transfer make the operator the owner of every artefact |

PART III · CHAPTER 9

## A One-Farm Prototype Answers Before Scale Is Priced

Four milestones carrying fifteen items move from integration prototype through dashboard and access to full integration and handover, each exit gate decided on evidence the previous milestone measured, with no duration promised and the riskiest assumption retired first.

Chapter 8 closed the design with the model and equipment register, deliberately empty of models because the analytics the requirement commits to are deterministic aggregations, drill-down and reporting. This chapter moves from what the system is to how it gets built: four milestones, fifteen items, and exit gates that each turn on evidence rather than on a calendar.

### 9.1  Four Milestones Gated on Evidence

Figure 8 shows the rollout as four milestones carrying fifteen items, with no duration promised anywhere. Milestone 1 is the integration prototype: four items across the Data Integration and Foundation workstreams, among them discovering the data sources and their integration contracts, building the shared farm and dataset ontology, and standing up the open-source database backend. Its exit gate is the one-farm prototype verdict: one farm and one dataset from the big data and analytics repository integrated end to end on real data, with sensor volumes and refresh behavior measured rather than assumed. Milestone 2 carries three items across the Dashboard & Analytics and Security & Access workstreams: the web-based interactive dashboard, role-based access controls, and report generation and export. Its gate is a design workshop at which the role list and the administrator are confirmed before any access rule is written, because the requirement demands role-based access without naming the roles. Milestone 3 carries four items across Data Integration, Operations and Security & Access, among them integrating the site sensor streams, integrating the historical datasets and the repository, and implementing the system monitoring metrics; before it starts, full-farm integration is re-estimated on the volumes Milestone 1 measured. Milestone 4 carries four items in the Handover workstream: source code and intellectual property transfer, technical documentation, and training that leaves the operator's own staff running the system independently. The requirement coverage table records twenty-three requirements, with one fully traced and twenty-two awaiting the discovery evidence the first gate produces, which is the honest state of a plan whose riskiest assumption is still untested. Each milestone ends on a stated verdict, never a date, and the evidence trail lets a public buyer audit what was claimed against what was shown, the traceability that oversight of federal awards looks for and does not always find (GAO n.d.).

![Figure 8. The four phases and their gates, and coverage of the 23 requirements across them.](figures/figure_08.png)

Figure 8. The four phases and their gates, and coverage of the 23 requirements across them.

### 9.2  What the Rollout Measures

The rollout carries one recorded operational measurement: soil, expressed as a percent, with a nominal value of thirty percent. A reading below that nominal is treated as a fault, and the fault it exists to catch is a sensor feed gap during irrigation stress. The measurement therefore does two jobs at once: it watches the crop's water condition and it watches the telemetry itself, because a gap in the feed during the hours when irrigation decisions are made is precisely when missing data costs the most. The monitoring metrics introduced at Milestone 3 sit underneath this measurement, tracking usage and performance of the system, so that a silent adapter failure surfaces as an alert rather than as an empty chart noticed after the season has moved on.

### 9.3  Failure Modes

The rollout's risks were recorded as failure modes with their mitigations, summarized in Table 5.

Table 5 · Failure Modes

| What fails | What the design does |
| --- | --- |
| The repository interface, where it runs and what it exposes, is unstated and the operator only coordinates with its administrators | The integration contract register is a Milestone 1 deliverable with the repository administrators in the room, and adapter risk is priced transparently in the financial proposal |
| Sensor formats, volumes and refresh rates are unknown, so ingestion effort and database sizing cannot be fixed | Milestone 1 gates on the one-farm prototype verdict and full-farm integration is re-estimated on measured volumes before Milestone 3 |
| Access roles are required but unnamed, so the access design could miss a stakeholder class | The role list and the administrator are confirmed in the Milestone 2 design workshop before any access rule is built |
| Server capacity, power and cooling are assumed but not specified | The infrastructure specification is recorded at the Milestone 1 kick-off, the database is sized to it, and shortfalls are escalated before installation |
| Historical datasets carry quality gaps, inconsistent keys or licensing restrictions that break joins to live data | The prototype validates joins on real data and carries provenance per dataset, so weak sources stay visible instead of being silently averaged |
| The fixed price against unstated integration effort makes full-farm integration uneconomic | The prototype is quoted honestly, the per-farm integration slope it measures is stated, and Milestone 3 pricing is contingent on that evidence |

### 9.4  Lessons

**Prototype on one farm before the rest is priced.** The requirement states what must be integrated but not in what format, at what volume or on what cadence, so the first milestone is sized to retire that single assumption cheaply. A small prototype on one farm and one dataset produces measured numbers that no amount of proposal writing could produce. Put the repository administrators in the room at the first gate. The operator coordinates with the repository's administrators but does not control it, so an integration contract written without them is a guess. Making the contract register a Milestone 1 deliverable converts coordination from a phrase in the terms of reference into a working session with a verdict. Quote the integration slope, not only the prototype. The public-procurement setting raises the stakes of optimiztic bidding: procurement fraud in agricultural support systems is documented as a standing risk class (European Court of Auditors n.d.), and corruption in public contracting worldwide is estimated in the trillions of dollars a year (World Bank 2020). A bid that hides integration risk inside a fixed number wins by moving the failure to someone else. Stating the measured per-farm slope and tying later pricing to it turns the requirement's own discipline into protection for both sides. Name the roles before the rules. Access control fails quietly when a stakeholder class is discovered after the permissions are built. The design workshop at Milestone 2 exists so that the role list is settled evidence, not an assumption inherited into the security model.

### 9.5  What Is Still Open

Five recorded questions remain, and each changes a specific downstream choice. Settling the repository interface fixes whether the read path is batch or scheduled and which adapter family carries it. Settling sensor formats, volumes and refresh cadence fixes database sizing and whether a streaming layer ever earns its place, which the stack currently declines. Settling the role list fixes the access model and its administrator. Settling the infrastructure specification fixes the sizing ceiling the database must respect. Settling dataset licensing fixes which historical sources can be joined and published. Alongside these, four national rules, a cloud-first posture for federal data, cybercrime coverage of farm data systems, type approval for any field radio, and a surveying and mapping act governing geospatial publication, each turn on a fact the requirement does not state, so each is carried as an open question rather than an assumption.

PART III · CHAPTER 10

## The Whole Argument Stays with the Operator

The object model, the source code, the documentation and the boundary all transfer to the operator by contract, because an ontology that lives in a versioned artifact the operator owns is the only kind that survives the people who built it.

Chapter 9 set the gates that move the work forward; this chapter states who holds what those gates approve, and why holding it matters more here than in a conventional build.

### 10.1  What the Operator Owns

The object model transfers as a versioned schema and mapping layer inside PostgreSQL with PostGIS, twelve objects and their typed links living in the same open-source database the operator already owns. Because the ontology is an artifact rather than a service, it survives the departure of the people who built it: the nouns, properties and links are in the repository, under the operator's change control, readable by any engineer it hires next. The weights and fine-tunes row is empty by design: the model register holds no model, so there are no weights to own, and everything the analytics run on is deterministic code that transfers as source under the intellectual property terms of reference. The decision record stays inside the operator's boundary as well: the alert object carries acknowledged-by and the report object carries generated-by, so the trail of who saw a breach, who acknowledged it and who resolved it accumulates in the operator's own tables, not in a vendor's tenancy. The boundary itself is owned: all compute runs on the operator's own on-premises servers in Pakistan, no external service sits in the read path, and the adapters are the only write path into the ontology, which means the integration surface is small enough to audit line by line. Milestone 4 closes the loop with technical documentation and staff training, so independent operation is a gate condition, not a courtesy.

### 10.2  The Offer Behind the Design

CodeNinja designed this system on Praxis, its for designing physical AI systems, and the design maps directly onto what the lab builds. The twelve-object model at the center of the stack is Hyper Ontology, the object model product, implemented here as an operator-owned projection over the sensor feeds, the historical datasets and the repository. Running the whole stack on the operator's own on-premises servers, on open-source licensing, inside Pakistan, is Sovereign Infrastructure, the posture the design takes so the data and the argument built on it never leave the boundary. The recorded reasoning behind every choice in this paper is the work of Praxis, and Chapter 11 shows that record.

PART IV · CONCLUSION

## Integration, Not Intelligence, Is the Product Here

The design is one thing seen whole: a operator-owned ontology projected over three systems of record, fed by two adapter families, rendered by six services onto two surfaces, phased so that a one-farm integration prototype with a stated verdict settles the riskiest assumption before anything scales, and closed out with source code, full intellectual property and documentation in the operator's hands. No model runs, no field hardware is bought, and no data leaves the operator's boundary; the value is the schema, the mappings and the eleven gates that turn unknown interfaces into known ones.

Running the same shape elsewhere takes three commitments: treat the adapter contract register, not the chart library, as the deliverable to be priced and proven; keep the ontology as a versioned artifact inside the open-source database the operator already owns, so meaning survives the handover instead of living in people; and gate each phase on measured evidence from the one before it, re-estimating scale work only on volumes the prototype has actually seen. Any operation holding live telemetry, historical archives and a sector repository can run this shape; none of them need to buy hardware or a license to start.

PART IV · CHAPTER 11

## Every Choice Here Traces to a Recorded Reading

The design was produced on Praxis, which assigned the family and industry, held seven hundred thirty-seven records in the room with one hundred thirty-nine read in full, and worked the eight lenses, two of which honestly returned gaps, so any reader can trace each choice back to what justified it.

Chapter 10 named who holds the design; this final chapter shows how the design was reasoned, so that any reader can trace each choice back to what justified it. Every design in the series is produced on Praxis, and Figure 9 lays out that reasoning for this paper: the ask, the family and industry assigned, what was in the room, the eight lenses worked, and the patterns and equipment the reasoning landed on.

### 11.1  Contextualizing the Ask

The ask, in the operator's own words, is an open-source, web-based agriculture data dashboard on an open-source database backend, integrating the site sensor feeds, historical datasets and the big data and analytics repository, with drill-down analytics, role-based access, exports, and source code and intellectual property transferred to the operator. Praxis assigned the design to the Physical AI family and to the Agriculture and Earth Observation industry. The industry pin is the FDE's own decision on this project, not a reasoned match, and the domain brief was nonetheless read in full as a reasoning input. The room held seven hundred thirty-seven records, of which one hundred thirty-nine were read in full and five hundred ninety-eight remain available on demand; that inventory is part of the record, so a reader can ask what else was in the room when any choice was made.

![Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.](figures/figure_09.png)

Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.

### 11.2  The Eight Lenses

Table 6 records the eight lenses, what each could see, how many entries it cited, and what it contributed. Two lenses honestly returned gaps, and the gaps are recorded rather than smoothed over.

Table 6 · The Lenses and What They Contributed

| Lens | Could see | Cited | What it contributed |
| --- | --- | --- | --- |
| First principles | The pinned brief's lessons on ontology-first design | 1 | Model farms, and crop cycles before charts, and treat the sensor and repository adapters as the real deliverable |
| Case studies | Comparable builds in the sector | 2 | A checks-by-monitoring reference on PostgreSQL and PostGIS and an advisory-registry lesson that the shared data registry is the reusable asset, both shaping integration-first phasing |
| Tooling and recency | Live-verified models for the analytics layer | 0 | Gap: no model was verified live this run and the analytics are aggregations, drill-down and reporting, so no model is committed and a forecaster stays open work |
| Hardware and equipment | Equipment classes for this engagement to procure | 0 | Gap: the design installs no field hardware, the sensors already generate the data, and the operator provides the servers, storage and connectivity |
| Rules and regulations | National rules bearing on farm data | 4 | A cloud-first posture for federal data, cybercrime coverage of the data systems, type approval for field radios, and a mapping act over geospatial publication, each read to an open question |
| Approach | Doctrines for phasing the work | 3 | Prototype-first and earned phases: milestone one is a small integration prototype with a stated verdict, and each later milestone is gated on evidence from the one before it |
| History | How integration-era data platforms decayed | 2 | Meaning left in people decays, so the ontology lives in the versioned artifact the operator owns rather than in documentation and memory |
| Domain fusion | Patterns fused with the agriculture brief | 2 | System of Context renders as farm, field, crop cycle, sensor device and dataset objects, with the kinetic loop held read-only by design |

### 11.3  Patterns Adopted and Set Aside

One pattern was adopted: system of context, pinned as the primary pattern. Its three layers run in fixed order, with the systems of record below, never replaced, never modified and never loaded; the operator-owned ontology in the middle as a projection over those records, never a shadow copy; and the dashboard, access controls, exports and monitoring above, all reading from that projection. Its grammar is deliberately small: nouns become objects, facts become properties, relationships become typed links, and actions change them. The kinetic loop, sense, decide, act, learn, closes read-only because the engineer confirmed that users act on the outputs inside tools they already use, so the return edge that would make the twin living is absent from the committed scope by recorded decision, not by omission. No pattern was set aside: the layered shape carried every stage the requirement commits to, and nothing in the ask pulled a second pattern into conflict with the first.

### 11.4  Where the Reasoning Lands

The reasoning lands on equipment classes, and the landing is a set of recorded rejections. No field compute, no cameras, no edge orchestration, no air gap, no frontier inference: each layer the hardware lens examined resolved to not needed with a reason written against it, because the sensors already generate the data and the operator provides the infrastructure. The layers marked class are the ontology as a schema projection inside PostgreSQL with PostGIS, time series in the same database, observability, identity and access, and the integration adapters that form the core build. That is the whole equipment argument: what runs, what does not, and why each row says so. Everything shown in this chapter was recorded reading: the lens counts, the records read in full, the empty model register, the not-needed layers and the two honest gaps. Nothing is inferred, and a reader who disagrees with any row can point at the row itself.

Appendix A

## What It Costs

The design buys no hardware and serves no model. The dashboard, its PostgreSQL and PostGIS database and the adapters run on servers, storage and connectivity the operator provides, the sensors already in the field generate the data, and the analytics are deterministic aggregations, drill-down and reporting, so there is no owned-versus-rented comparison to print. The cost of this design is the integration and software work itself, delivered against the requirement's milestones and handed over with its source code and intellectual property.

### A.1 What Would Change the Answer

| Line | When it appears | How to price it |
| --- | --- | --- |
| Database and buffer capacity | If measured sensor volumes in the phase one prototype outgrow the operator's servers | The server specification recorded at the Milestone 1 kick-off, re-estimated on measured volumes; the operator's own hardware cost per core and per terabyte |
| A forecaster over sensor time series | If the operator later commits a forecasting workload | A small open-weight time series model on CPU or one 48 GB card; one L40S-class card lists at 7,709 dollars (esaitech 2026), and Pakistan needs a US export licence for that class |
| A generative work surface | If staff later ask questions of the farm model in natural language | A frontier open-weight model on one node of eight 141 GB HBM-class GPUs, 320,000 to 420,000 dollars (Mercatus 2026), priced in the series' other papers |

### A.2 Sources for This Appendix

- esaitech. 2026. PNY NVIDIA L40S 48 GB GDDR6 PCIe. <https://esaitech.com/products/pny-technologies-nvl40stcgpu-kit-nvidia-l40s-4-port-48gb-gddr6-graphic-card>
- Mercatus. 2026. H200 server price. <https://mercatus-ai.com/blog/h200-server-price>

SOURCES

## Source Register

European Court of Auditors. n.d.. Special report: anti-fraud measures in the CAP. <https://op.europa.eu>

World Bank. 2020. Early Detection of Fraud and Corruption in Public. <https://www.worldbank.org>

GAO. n.d.. Federal Awards: Selected Programs Did Not Fully Include. <https://www.gao.gov/products/gao-26-107444>

---

### About CodeNinja

CodeNinja is a Middle Eastern-American artificial intelligence lab focused on building self-improving systems. We are reinventing knowledge work to close the loop between vertical AI use cases and the generalized intelligence that fuels it, accelerating the path toward organizational superintelligence.


---

# From Reference Architecture to Living Ontology: the hyper-ontology/1 Package and Hyper Ontology

Canonical: https://codeatoms.ai/ontology-method/
DOI: https://doi.org/10.5281/zenodo.23132104
PDF: https://codeatoms.ai/ontology-method/paper/from-reference-architecture-to-living-ontology.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

[CodeNinja Research](https://codeatoms.ai/) · [Praxis](https://codeatoms.ai/praxis/) · [Hyper Ontology](https://codeatoms.ai/hyper-ontology/) · [PDF](paper/from-reference-architecture-to-living-ontology.pdf)

Vertical-Driven Architectures · Methods · Hyper Ontology · October 2026

# From Reference Architecture to Living Ontology: the hyper-ontology/1 Package and Hyper Ontology

Every design Praxis produces ends in an object model. This paper specifies the package that carries it, measures the seven published packages, shows how to load them, and describes how Hyper Ontology turns one into a living system.

CodeNinja Engineering Team · Umar Bilal

CodeNinja · 2026-10-04 · CC BY 4.0 · Web edition: <https://codeatoms.ai/ontology-method/> · DOI [10.5281/zenodo.23132104](https://doi.org/10.5281/zenodo.23132104)

**Abstract.** Ontologies are to agents what databases are to humans: a database assumes a reader who already knows what the columns mean, while an ontology writes that meaning down once, as objects, properties, typed links and actions, so an agent resolves instead of guessing. Every system design reasoned on [Praxis](https://codeatoms.ai/praxis/) ends in such a model, packaged as `hyper-ontology/1`: typed objects with properties and status vocabularies, the system of record each is anchored in, typed directional links, the write paths and the human approval the design requires. Seven packages are published with the Vertical-Driven Architectures series, holding 94 objects and 86 typed links across 9 object kinds. An open, dependency-free loader validates them and converts them to Mermaid, Cypher and JSON-LD. [Hyper Ontology](https://codeatoms.ai/hyper-ontology/), CodeNinja's ontology platform, imports a package and stands it up as a projection over the operator's own systems of record, connected through adapters that emit ontology events, with actions that write back under approval, so the model senses, decides, acts and learns.

## 1. Why the design ends in an ontology

A physical operation's meaning is scattered: the berth window lives in the port community system, the channel depth in the survey archive, the lease in the finance backbone. Every report, application and agent that reads the silos directly re-derives the business, and derives it slightly differently. A design that ends in an object model fixes the meaning once. Praxis therefore treats the object model as the join the systems never made, and every paper in the series has a chapter that names each object, its anchor and its links.

## 2. The package

```
{"package": "hyper-ontology/1", "designed_with": "Praxis", "implemented_with": "Hyper Ontology",
 "paper": {"title": "...", "url": "...", "doi": "..."}, "sector": "...", "country": "...",
 "objects": [{"id": "berth", "label": "Berth", "kind": "asset", "anchored_in": "Port Community System",
   "properties": ["Berth ID", "Alongside depth", "Berth window"], "status_vocabulary": ["Occupied", "Reserved", "Available"],
   "links": [{"to": "navigation_channel", "label": "adjoins"}]}],
 "write_paths": ["..."], "human_loop": "..."}
```

**Objects** carry an id, a label and one of ten kinds: asset, record, event, person, actor, site, material, measure, document and system. **anchored\_in** names the system of record the object is read from, or says the object is born in the design itself, such as a decision record. **Links** are typed and directional; the reverse is implied. A link whose label a paper's figure could not print carries a `note` instead of an invented label. **write\_paths** and **human\_loop** carry the design's rules about what may change the world and who approves it. Nothing in a package names the operator; the same gate that reads the paper reads the package. The full specification is [ONTOLOGY\_PACKAGE.md](https://github.com/muhammadumar89/codeninja-research/blob/main/ONTOLOGY_PACKAGE.md).

## 3. Seven packages in numbers

| Design | Country | Objects | Links | Systems anchored | Most-linked object |
| --- | --- | --- | --- | --- | --- |
| [Sovereign HSE Watch](https://codeatoms.ai/sovereign-hse-pakistan/ontology/objects.json) | Pakistan | 12 | 14 | 8 | Operating Facility / Site (4 links) |
| [Feeder Firewatch](https://codeatoms.ai/wildfire-risk-distribution-us/ontology/objects.json) | United States | 14 | 12 | 10 | Feeder segment (6 links) |
| [Terminal Pulse](https://codeatoms.ai/truck-turn-container-terminal-us/ontology/objects.json) | United States | 12 | 11 | 7 | Container (6 links) |
| [Structure Phase Watch](https://codeatoms.ai/structure-phase-construction-saudi-arabia/ontology/objects.json) | Saudi Arabia | 15 | 12 | 10 | Pour (4 links) |
| [Steel Count Ledger](https://codeatoms.ai/steel-production-count-pakistan/ontology/objects.json) | Pakistan | 14 | 12 | 5 | Industrial PC (4 links) |
| [Factory Fire Watch](https://codeatoms.ai/factory-fire-monitoring-saudi-arabia/ontology/objects.json) | Saudi Arabia | 14 | 12 | 8 | Safety-critical alert (4 links) |
| [Port Twin](https://codeatoms.ai/port-digital-twin-us/ontology/objects.json) | United States | 13 | 13 | 11 | Berth (8 links) |

Table 1. The seven published packages. Systems anchored counts the distinct systems of record the objects are read from.

Figure 1. Objects per design by kind. Assets and records dominate, and every design carries at least one event: a moment that happens and that the model must record.

Across the series: 30 asset, 24 record, 17 event, 6 person, 6 site, 4 actor, 3 measure, 2 document, 2 material. The most-linked object is where the design's questions meet: the berth in the port twin, the feeder segment in the wildfire design, the container in the terminal design, the pour on the construction site.

## 4. Reach: what a query on the model can traverse

The value of an ontology is the traversal a document store cannot make. From one berth in Port Twin, two hops of typed links reach:

```
berth ->[adjoins] navigation_channel
berth ->[receives] vessel_movement
berth ->[belongs to] parcel_facility
berth <-[monitors] environmental_sensor_feed
berth <-[linked] utility_gap_record
berth <-[linked] capital_project
berth <-[linked] inspection_record
berth <-[arrives via] pcs_message
berth ->[adjoins] navigation_channel ->[surveyed by] bathymetric_survey
berth ->[belongs to] parcel_facility ->[hosts] capital_project
```

From one production count event in Steel Count Ledger:

```
count_event <-[emits] ipc
count_event ->[classifies as] product_type
count_event <-[validates] calibration
count_event <-[emits] ipc <-[runs on] installation_point
count_event <-[emits] ipc ->[linked] uptime_record
count_event <-[emits] ipc ->[linked] tamper_alert
count_event ->[classifies as] product_type ->[linked] declared_production
count_event <-[validates] calibration ->[measured against] weighbridge_record
```

Both listings are the output of `hyper-ontology reach` on the published packages.

## 5. Loading a package

```
pip install "git+https://github.com/muhammadumar89/codeninja-research#subdirectory=hyper-ontology-py"
hyper-ontology list
hyper-ontology show port-digital-twin-us
hyper-ontology validate steel-production-count-pakistan
hyper-ontology cypher truck-turn-container-terminal-us > load.cypher
hyper-ontology mermaid factory-fire-monitoring-saudi-arabia > model.mmd
```

The loader has no dependencies, validates kinds, ids and link targets, and converts a package to a Mermaid class diagram, a Cypher script for a graph database, or JSON-LD for a triple store. All seven published packages validate. The loader reads and converts the schema; it does not connect to live systems.

## 6. What Hyper Ontology adds

A package is the schema of a design. Hyper Ontology makes it living. It stands the model up in three layers, and the order is the argument: systems of record below, never replaced, modified or migrated; the ontology in the middle, built once and owned by the operator, as a projection over those systems rather than a copy; applications and agents on top, reading meaning from the model and never from the silos directly. Each anchored system connects through an adapter that emits ontology events, so the integration contract is the event, not a vendor's payload, and a system can be replaced without touching anything above the adapter.

The model has a grammar of four verbs: nouns become objects, facts become properties, relationships become typed links, and actions change them. The fourth is what makes the model living: it senses as data lands on objects, decides as questions are answered on the model, acts as approved decisions write back, and learns as the outcome lands on the model again. The package's write paths and human loop become the rules on those actions: a recommendation is a record, and a named person's approval is what turns it into a change.

## 7. Limits

A package is schema, not data: it names what the model holds and how it links, not the records of any operator. Status vocabularies a design left at a default were dropped rather than invented, and links a figure could not label are kept with a note. Hyper Ontology is in beta and used in house by CodeNinja; access for outside teams is by request at <https://codeatoms.ai/hyper-ontology/>.

## References

1. CodeNinja Engineering Team and Umar Bilal. 2026. *Sovereign HSE Watch: Predictive Risk and Early Warning on an HSE Control and Command Platform*. CodeNinja. <https://doi.org/10.5281/zenodo.23119714>
2. CodeNinja Engineering Team and Umar Bilal. 2026. *Feeder Firewatch: Live Ignition and Outage Risk for Every Distribution Feeder*. CodeNinja. <https://doi.org/10.5281/zenodo.23119325>
3. CodeNinja Engineering Team and Umar Bilal. 2026. *Terminal Pulse: Predicted Truck Turn Time and Live Yard Sight for a Container Terminal*. CodeNinja. <https://doi.org/10.5281/zenodo.23119348>
4. CodeNinja Engineering Team and Umar Bilal. 2026. *Structure Phase Watch: Live Production, Crane and Delivery Evidence for Every Pour on a Construction Site*. CodeNinja. <https://doi.org/10.5281/zenodo.23126448>
5. CodeNinja Engineering Team and Umar Bilal. 2026. *Steel Count Ledger: Independently Counted Production for Every Steel Mill in Pakistan*. CodeNinja. <https://doi.org/10.5281/zenodo.23126563>
6. CodeNinja Engineering Team and Umar Bilal. 2026. *Factory Fire Watch: Read-Only Smart Fire Protection Monitoring for Every High-Risk Factory*. CodeNinja. <https://doi.org/10.5281/zenodo.23126565>
7. CodeNinja Engineering Team and Umar Bilal. 2026. *Port Twin: One Governed Digital Twin for Every Asset, Feed and Dollar*. CodeNinja. <https://doi.org/10.5281/zenodo.23126431>


---

# Grid Context Watch: One system of context for OT Security and NERC CIP Evidence

Canonical: https://codeatoms.ai/ot-security-cip-evidence-us/
DOI: https://doi.org/10.5281/zenodo.23157957
PDF: https://codeatoms.ai/ot-security-cip-evidence-us/paper/grid-context-watch-ot-security-nerc-cip-evidence-utility-us.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

VERTICAL-DRIVEN ARCHITECTURES · ENERGY & UTILITIES · DESIGNED WITH PRAXIS · OCTOBER 2026

# Grid Context Watch: One system of context for OT Security and NERC CIP Evidence

A system of context, passive operational technology monitoring and agentic evidence assembly for an energy and utilities operator in the United States, fed one-way out of its control networks and run entirely on its own hardware.

CodeNinja Engineering Team

For the operational technology security lead, the compliance and CIP lead, and the platform, network, data and integration engineers who would build and run it.

---

Vertical-Driven Architectures is a CodeNinja series of system designs. Every design in the series is driven by a real-world problem and scenario in a single industry, and every one is designed on Praxis, CodeNinja's platform for designing physical AI systems. Operations are described by class, never by name.

At a glance

## OT security monitoring and NERC CIP evidence for a utility in the United States

**What this is.** An open reference architecture for system design in physical AI: one system of context that sees every device on a utility's control networks, flags abnormal behaviour and assembles the evidence a NERC CIP audit asks for, on the operator's own hardware. It is written for the OT security and CIP compliance leads and for the platform, network and integration engineers who would build it. The operator is described by class, never by name.

**The answer in numbers.**

| Part | The design |
| --- | --- |
| Sources joined | 10 source systems, including the SIEM, an OT detection tool, an IT monitoring platform, the energy management system and the substation data platform, through 2 adapter families |
| Object model | 14 typed objects and 14 links, with the OT asset as the focal object, published as JSON for reuse |
| Models | GLM 5.2 (MIT) for reasoning and Qwen3-Embedding-0.6B (Apache-2.0) for retrieval; detection stays in the procured sensors |
| Compute | One node of eight 141 GB HBM-class GPUs: 753 GB of FP8 weights, 904 GB with the 1.2 planning factor, against 1,128 GB |
| Boundary | Read only and one way out of the control networks; nothing writes into an electronic security perimeter, and no data leaves the operator |
| Three-year cost | About 510,000 dollars to own the reasoning node, about four fifths the deepest three-year AWS commitment (Appendix A) |
| Human control | Every triage, case and risk acceptance carries a named OT security analyst; agents draft, the analyst decides |

**Reuse it.** The object model, the model register and the figures are free to reuse under CC BY 4.0. Cite as DOI <https://doi.org/10.5281/zenodo.23157957.>

**Made with.** Reasoned on [Praxis](<https://codeatoms.ai/praxis/>), CodeNinja's platform for designing physical AI systems. The object model imports into [Hyper Ontology](<https://codeatoms.ai/hyper-ontology/>), which turns it into a living system. Both are in beta; access by request.

ABSTRACT

## An OT Estate Should Be Watched From One system of context, Not Five Fragmented Tools

An energy and utilities operator in the United States needs one answer about its operational technology estate: what is connected to the control networks behind its more than 80 substations, whether anything on those networks is behaving abnormally, and whether that can be proven with evidence when the regional reliability regulator arrives for its next audit. Today the answer cannot be produced, because asset discovery, network monitoring, log retention, threat intelligence and compliance reporting live in separate systems that each hold one slice of the picture. The stakes are set by regulation and by events: mandatory critical infrastructure protection standards for the bulk system (FERC 2008), a federal rule requiring internal network security monitoring for high and medium impact bulk system cyber systems (Federal Register 2023), and advisories showing state-affiliated actors actively exploiting programmable logic controllers across US critical infrastructure (CISA 2026).

The design is a system of context: one living model of the operational technology estate, holding 14 object types spanning substations, assets, sensors, alerts, cases, vulnerabilities, detection rules, threat intelligence, pcap evidence and CIP evidence artefacts. It is fed by 10 source systems entering through 2 adapter families, always read-only and one-way out of the control networks, so nothing in the design ever writes into an electronic security perimeter. Seven services and 4 surfaces carry asset visibility, detection, forensics, integration and compliance work; 2 models, a frontier-class reasoning model under an MIT license and an Apache-2.0 embedding model for retrieval, run on the operator's own hardware at its data center, sized to one node of eight GPUs of the 141 GB HBM class, with no weights rented and no data leaving the boundary.

The paper proceeds in four parts. Part I states the industry problem and the join failure across the operator's existing systems. Part II gives the constraints, the stack from systems of record to surfaces, the 14-object model, ingestion through adapters, inference placement and the memory arithmetic, and the models and licenses that decide ownership. Part III lays out the four-phase rollout with item counts and measured gates, and who owns what the design builds. Part IV closes with the conclusion and Chapter 11, how Praxis contextualized and reasoned this design.

---

![Figure 1. Grid Context Watch on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.](figures/figure_01.png)

Figure 1. Grid Context Watch on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.

## Contents

Each chapter is tagged for the reader it serves most directly: Executive, Team Lead, FDE, Reference.

|  |  |  |
| --- | --- | --- |
|  | Abstract · An OT Estate Should Be Watched From One system of context, Not Five Fragmented Tools | Executive |
| PART I · THE PROBLEM | | |
| 1 | [A Control Network Cannot Defend What It Cannot See](#ch1) | Executive |
| 2 | [Every Operational System Sees One Slice of the Grid](#ch2) | ExecutiveTeam Lead |
| PART II · THE DESIGN | | |
| 3 | [Four Constraints Shape the Design Before Any Component](#ch3) | Team Lead |
| 4 | [One Stack Runs From Systems of Record to Surfaces](#ch4) | Team LeadFDE |
| 5 | [Fourteen Objects Turn Sensor Traffic Into One Living Model](#ch5) | FDE |
| 6 | [Every Source Enters Through an Adapter, Never Directly](#ch6) | FDE |
| 7 | [All Inference Runs on the Operator's Own Hardware](#ch7) | FDE |
| 8 | [The License Decides Whether the Operator Owns the Weights](#ch8) | FDEExecutive |
| PART III · THE ROLLOUT | | |
| 9 | [Shadow Mode and Measured Gates Come Before Scale-Out](#ch9) | Team LeadExecutive |
| 10 | [The Intelligence Should Stay with the That Produced It](#ch10) | Executive |
| PART IV · HOW IT WAS DESIGNED | | |
|  | Conclusion · The Same Shape Runs on Any Regulated Grid | Executive |
| 11 | [How Praxis Contextualized and Reasoned This Design](#ch11) | Team LeadFDE |
|  | [Sources](#sources) | Reference |

PART I · CHAPTER 1

## A Control Network Cannot Defend What It Cannot See

An energy and utilities operator must inventory, monitor and evidence more than 80 substations under NERC CIP, and passive visibility is now a regulatory requirement rather than a choice.

The abstract states the shape of the answer before the problem is established: one system of context, fed one way out of the control networks, read by agents on the operator's own hardware. This chapter establishes what question that system exists to answer, what the industry's failure to answer it has already cost, and what the operation it must serve actually runs.

### 1.1  The Question, the Data and the Regulatory Ground

The operation needs three questions answered continuously and provably: what is connected to every control network, what is each connected thing doing, and what evidence exists to show both under audit. Answering them requires data the operation must hold anyway: packet-level copies of operational technology traffic taken passively at each electronic security perimeter, an asset inventory carrying address, protocol, vendor, model, firmware version and critical infrastructure protection categorization for every device, security and application logs retained to the audit clock, change records that explain legitimate network evolution, and threat intelligence mapped to the techniques adversaries actually use against control systems.

The regulatory ground is fixed and layered. In 2008 the Federal Energy Regulatory Commission issued Order 706, making critical infrastructure protection reliability standards mandatory for the bulk system (FERC 2008). A 2023 federal rule then required internal network security monitoring for high and medium impact bulk system cyber systems, converting passive visibility inside the perimeter from good practice into an enforceable obligation (Federal Register 2023). The operator must therefore satisfy CIP-005 electronic security perimeters, CIP-007 and CIP-008 system security logging and incident response, CIP-010 change management, CIP-013 supply chain terms and CIP-015 internal network security monitoring, hold capture and log evidence against a three-year retention clock, and produce it to the regional enforcement entity when the audit arrives.

### 1.2  What the Blind Spot Has Cost the Industry

No ledger line names the cost of an unseen control network; the cost is documented in public incident records instead. A joint federal advisory warns that Iranian-affiliated cyber actors have exploited programmable logic controllers across US critical infrastructure, the exact device class an unmonitored network hides from its own operator (CISA 2026). When visibility is partial, the burden surfaces after the fact: a national cyber authority's follow-up analysis of an energy sector incident on 29 December 2025 shows how much reconstruction an investigator must perform to establish what happened inside an energy network (CERT Polska 2025). And the physical stakes of the same blind spot are not hypothetical: the 28 April 2025 Iberian blackout was called the most severe incident in the European power system in more than 20 years, a demonstration of how far grid behavior can depart from what its operators believe it to be (ENTSO-E 2025). For an operator under mandatory reliability standards, that cost takes three forms: forensic reconstruction after an incident, regulatory exposure at audit, and outage risk on a control path nobody was watching.

### 1.3  The Operation as a Scenario

The setting is an energy and utilities operator in the United States, fixed there by its own requirement. It runs a bulk system: an energy management system directing field devices over DNP3 from remote terminal units, TASE.2 ties to neighboring transmission, controllers exporting structured state, and more than 80 substations, each a candidate electronic security perimeter. Its enterprise side already holds a SIEM, an OT detection tool, an IT monitoring platform, collective threat intelligence and external analysis tools, ten named source systems in all, which this design reaches through two adapter families rather than direct connections.

The people in the loop are counted by role, not by org chart: OT security analysts who triage alerts and run investigations, compliance staff who assemble CIP evidence, and incident responders available through a vendor retainer, with no dedicated security operations center. The physical environments are cabinets and switchyards, the electronic security perimeter boundary drawn around each, and one central data center where the operator's own compute already lives. The programmatic frame is 21 contractual requirements spanning asset visibility, network visualization, OT monitoring and logging and compliance use cases, phased into 4 phases whose boundaries are gates, not dates.

PART I · CHAPTER 2

## Every Operational System Sees One Slice of the Grid

The operator's existing systems each hold one fragment of the operational technology picture, and none of them together can answer what is connected, what is anomalous and what can be proven.

Chapter 1 described an operation whose regulatory standing depends on knowing its own control networks. This chapter shows why it cannot know them today: every system it owns was built to watch one slice of the grid, and the slices do not join.

### 2.1  Each System Sees One Slice

The SIEM sees every log source that forwards to it: authentication events, firewall traffic, server and application logs, correlated into enterprise alerts. It misses the control networks themselves, because DNP3 sessions between remote terminal units and their station never reach it; this is precisely why the requirements demand bidirectional flow between the new platform and the SIEM rather than assuming it already exists. The OT detection tool sees a slice of operational technology protocol traffic and raises protocol-aware alerts, but an alert it raises has no durable home: no estate-wide inventory behind it, no case continuity around it, no evidence retention beneath it. The IT monitoring platform sees device health, availability and forwarder status across the enterprise, and carries no security semantics: it can report that a collector is down but cannot say what the collector was watching or what moved past it.

The energy management system sees its own points, scan settings and RTU links, and it is the process being defended rather than a sensor for it: it knows nothing outside its point list and cannot be repurposed as a security instrument without endangering the control path it serves. The substation data platform sees the controller's own state and exports it as structured files, but it is blind to the network behavior around the controller: what connects to it, what probes it, what changed on the wire between scans. Collective threat intelligence sees adversary tradecraft, indicators and technique mappings shared at sector speed, and knows nothing about this operator's estate, so it cannot say whether any of it applies here. External analysis tools see whatever an analyst exports to them; by then the data is frozen, and they see nothing live. Figure 2 sets these seven views side by side, each with its sees and its misses, converging on the question none of them can answer alone.

![Figure 2. Seven systems, each seeing one part of the answer. the question needs all of them in one place at once.](figures/figure_02.png)

Figure 2. Seven systems, each seeing one part of the answer. the question needs all of them in one place at once.

### 2.2  Together They Still See Nothing Whole

What none of them see together is the join itself: one living model holds its assets, an asset holds its alerts, an alert holds its detection rule and its case, and a case holds the packet capture that proves what happened. The cost of that absence is concrete. At audit, the inventory is assembled by hand from spreadsheets and project files, and unidentified devices surface of the reviewer rather than of the operator. In the SOC-less daily round, alerts are triaged without asset context, and two tools can investigate the same anomaly without either knowing it. The 2023 internal monitoring rule makes this an enforcement matter rather than an inconvenience, because the evidence the rule demands is exactly the joined record no existing system produces (Federal Register 2023).

PART II · CHAPTER 3

## Four Constraints Shape the Design Before Any Component

One-way flow out of electronic security perimeters, data residency on the operator's own hardware, named human decisions, and a cheap first gate govern every choice downstream.

Chapter 2 showed seven systems each holding a fragment of the operational technology picture. The design joins those fragments into one system of context, but four constraints, fixed before any component was chosen, decide what that join may touch, where it may run, who may act on it and how cheaply it can be stopped.

### 3.1  One-Way Flow Out of the Perimeter

The first constraint is that data leaves the control network and nothing enters it. An electronic security perimeter is a regulatory boundary under CIP-005, and DNP3 is a control path, so analytics ride a copy of the traffic and never add a second writer to the wire. This is hard in this industry because conventional monitoring assumes agents and active probes that write into what they watch, and here an active probe would put packets onto a control path; a monitoring capability that can write is also a path an adversary can write, and federal advisories document actors exploiting exactly the device classes at the end of these wires (CISA 2026). The design therefore egresses through a constrained broker conduit by default and places hardware-enforced one-way transfer beside the highest-impact perimeters, where policy demands demonstrable one-way flow.

### 3.2  Residency on the Operator's Own Hardware

The second constraint is that every weight, index, capture and artifact stays on hardware the operator owns, inside its own data center, with no colocation and no external region. This is hard because operational technology estates trend isolated: the design must bring compute to the data rather than route data to compute, which means sizing central inference to run beside the networks it watches rather than assuming an elastic cloud behind them. Both models in the design run centrally on the operator's own nodes, and every source system's provenance class is the operator's own estate, so the boundary the data never crosses is also the boundary the weights never leave.

### 3.3  Every Flag Ends with a Named Person

The third constraint is that recommendations stop at the case and the playbook: nothing in the design writes to the energy management system, to protection relays or to the substation data platform, and every triage draft an agent produces carries a visible human decision on it. This is hard because the operator runs no dedicated security operations center, so an alert flood would not merely overload a team, it would erode trust until alerts stopped being read, the quietest and worst failure a detection program can have. Agent drafting exists here to be judged by a named analyst, not to act, and the design treats that judgment as the product rather than the overhead.

### 3.4  The First Gate Must Be Cheap to Fail

The fourth constraint is that the work can be stopped early and cheaply, on measurement rather than momentum. Phase 0 carries 3 items, zone and conduit design, the ontology of the operator's OT estate, and role-based access and on-prem identity design, and it gates everything downstream: the scale-out of sensors waits on measured inventory coverage at a 95 percent threshold, and false-positive rate is a first-class gate rather than a dashboard afterthought. The program runs as 4 phases matching the requirement's own 4.1 and 4.2 split, covering all 21 requirements, and no phase carries a duration: each boundary is a verdict point at which the sponsor can stop with an inventory, a baseline and a design, having bought nothing twice.

### 3.5  Scoping Decisions and What Each Costs

Every constraint above is free to state and expensive to honor, and a design that will not name its payments is not honest about either. Table 1 records the three scoping decisions that shape the build, what each buys the operator, and what each one costs.

Table 1 · Scoping Decisions

| Decision | What it buys | What it costs |
| --- | --- | --- |
| Central-only inference on one node in the operator's own data center | One hardware class to size, license, cool and maintain, and every model weight held inside the operator's boundary | The central link becomes load-bearing, so the design must define what degrades when it fails |
| Agents draft, a named person decides | Machine-speed triage and evidence assembly without any autonomous action in a regulated control environment | Alert throughput is bounded by the analysts' review cadence, which the false-positive gate exists to protect |
| No independent telemetry store; capture metadata and logs stay in the vendor platform and the SIEM | No duplicate storage to size, fund and reconcile against a three-year retention clock | Query load lands on existing systems, so every adapter contract must be built to their schemas |

### 3.6  What the Design Chose Against, and What Stays Out

A design is also defined by what it refuses, and the refusals carry reasons that a reviewer should be able to audit as easily as the choices. Table 2 records the alternatives the design turned down, and closes with the scope boundary it drew.

Table 2 · What the Design Chose Against

| Where | What was picked | Instead of, and why |
| --- | --- | --- |
| Detection engine | A procured OT monitoring platform for protocol parsing and signatures, with the ontology and agentic layer built above it | Instead of a from-scratch build on Zeek and Suricata, because the requirements demand vendor-grade OT signatures, accurate ATT&CK for ICS mapping and machine-speed collective intelligence that no open-source stack carries |
| One-way egress | Hardware data diodes at the highest-impact perimeters, a constrained DMZ broker conduit elsewhere | Instead of diodes, because a diode ends the argument only where policy demands demonstrable one-way flow, and its permanent operational burden elsewhere buys nothing |
| Frontier model | A 753B-parameter model under a plain MIT license | Instead of newer or larger alternatives carrying security-review or service triggers, because the license terms are the difference between the operator owning its weights and renting them |
| Sensing posture | Passive SPAN and TAP copies of OT traffic | Instead of active scanning inside control networks, because an active probe writes packets into a control path, which the one-way rule forbids outright |
| Scope boundary | SOC build-out, grid analytics, write paths into control systems, video analytics and metering scope all stay out | Instead of widening the program, because each addition carries its own procurement and would delay the audit-critical path of inventory, monitoring and evidence |

PART II · CHAPTER 4

## One Stack Runs From Systems of Record to Surfaces

A single layered stack carries sensor traffic from the control networks through adapters and one object model up to the services and surfaces the operator's people work in.

Chapter 3 fixed the constraints that shape this design: one-way reads out of the control networks, one object model as the lasting asset, and every inference on the operator's own hardware. This chapter lays out the stack that carries those constraints end to end, from the systems of record at the bottom to the surfaces where the operator's people decide.

### 4.1  One Pattern From the Control Networks to the Desk

The stack follows one pattern from bottom to top: systems of record below, one object model in the middle, applications and agents above. At the bottom sit the systems the operator already runs and trusts: the energy management system with its RTU-to-DNP3 control path, the SIEM, the OT detection tool, the IT monitoring platform, the substation data platform, and the vendor OT monitoring platform that parses protocols and carries signatures. Each remains authoritative for what it owns; the design replaces none of them and writes to none of them.

In the middle sits the system of context, the object model holding fourteen object types on an event backbone, fed one-way out of the control networks. Above it run seven services and four surfaces, and the agents that draft triage, retrieve playbooks and assemble CIP evidence, all on the operator's own hardware.

The pattern fits because the problem is a join problem. Adversaries have exploited programmable logic controllers across United States critical infrastructure (CISA 2026), and the federal rule requiring internal network security monitoring for high and medium impact bulk system cyber systems makes watching that traffic a compliance duty rather than an option (Federal Register 2023). A sensor answers one slice; the audit, the investigation and the vulnerability decision each need the alert joined to the asset, the asset to its the operator's impact rating, and the case to its evidence. Figure 3 shows the layered stack with the counts per layer: ten sources, two adapter families, fourteen object types, two models, seven services and four surfaces.

![Figure 3. The layered stack: 10 sources, 2 adapter families, 14 objects, 7 services and 4 surfaces.](figures/figure_03.png)

Figure 3. The layered stack: 10 sources, 2 adapter families, 14 objects, 7 services and 4 surfaces.

### 4.2  The Stack Stage by Stage

Table 3 walks the stack stage by stage and names the components in each. Two scoping choices are visible in the table: the design adds no independent telemetry store, because capture metadata and logs live in the vendor platform's own store and in the SIEM, and no operator model is placed inside an electronic security perimeter, because detection runs in the vendor's sensors and the central platform.

Table 3 · The Stack, Stage by Stage

| Stage | What it is responsible for | How |
| --- | --- | --- |
| Sources | Holding the operator's authoritative records | The energy management system, the SIEM, the OT detection tool, the IT monitoring platform, the substation data platform, the vendor platform's detection and log store, the sensor capture stream and the intelligence feeds, each read in place |
| Sensing | Watching OT network traffic passively | SPAN/TAP ports on hardened, fanless industrial switches inside each electronic security perimeter capture DNP3 and TASE.2 flows, timestamped against an OCP Time Card grandmaster running linuxptp and chrony |
| Adapters | Moving every record one way into the system of context | Two families: integration adapters for the API and CSV contracts with the SIEM, the OT detection tool, the IT monitoring platform and the substation data platform, and telemetry adapters for captures; egress through a DMZ conduit, with Lidi beside hardware data diodes at the highest-impact perimeters |
| Object model | Holding the single living model of the OT estate | the object model v0.9 carrying fourteen object types on RKE2, fed by Apache Kafka 4.3.1 |
| Inference | Drafting triage, retrieval and evidence assembly | GLM 5.2 at FP8, 753 billion parameters on one node of eight 141 GB HBM GPUs, beside Qwen3-Embedding-0.6B for retrieval, both served by vLLM |
| Services | Carrying the seven capabilities in scope | OT Asset Visibility, system of context, Governance & Administration, Threat Detection & Monitoring, Incident Response & Forensics, Integrations & Data Exchange and NERC CIP Compliance, with Keycloak for identity, Harbor for artifacts, and Prometheus 3.15.0, Grafana 13.2.3 and Loki 3.7.8 for observability |
| Surfaces | Putting the work of a named person | The alert triage and investigation workbench, the compliance evidence surface, the remote hunting workspace over the secure connection, and the platform administration tools with RBAC |

PART II · CHAPTER 5

## Fourteen Objects Turn Sensor Traffic Into One Living Model

The system of context holds every, asset, alert, case and CIP evidence artefact as typed, linked objects, and the human loop and the only write path live inside it.

Chapter 4 placed the object model at the center of the stack. This chapter opens it: the fourteen object types, the typed links between them, where the human loop and the only write path live, and one object in its recorded form.

### 5.1  Fourteen Objects and the Links That Join Them

The fourteen objects fall into four families. Sites and assets: substation, OT asset and network sensor. Events and records: anomaly alert, investigation case, vulnerability finding, detection rule and pcap evidence record. Documents: threat intelligence item and CIP evidence artefact. People and systems: OT security analyst, the SIEM, the energy management system and the substation data platform. Figure 4 draws every object and its typed links, with the OT asset in navy as the focal object.

The links are typed and directional. A substation holds OT assets and network sensors and carries a CIP impact rating that decides which CIP evidence artefacts it owes. An OT asset links to CIP evidence through its CIP categorization; an anomaly alert points at the detection rule that raised it and the asset it implicates; a vulnerability finding scores an asset and is assigned to an analyst for risk acceptance; an investigation case groups alerts and locks pcap evidence to itself; a threat intelligence item seeds detection rules; the substation data platform enriches assets with the export data the contract requires. The system objects anchor the model to the sources of record, so every derived property can be traced back to the system that produced it.

Because the links are typed, one query traverses the whole argument: from a single alert, the query reaches the rule that fired, the affected asset, that asset's substation and its impact rating, the analyst who owns the triage, and every evidence artefact the asset's categorization obliges the operator to retain. A document store holds the same records side by side but cannot traverse them, so each of those joins happens in an analyst's head or not at all.

![Figure 4. The fourteen objects of the model and the typed links that let a query reach across them.](figures/figure_04.png)

Figure 4. The fourteen objects of the model and the typed links that let a query reach across them.

### 5.2  Where the Human Loop and the Write Path Live

The human loop lives in the analyst object and in the status vocabularies that reference it. Every alert that moves from new to triaged, every case that opens, and every vulnerability risk acceptance carries a named analyst, held in the object model with role, role-based access control entitlements and training record. Agents on the work surface draft triage notes, retrieve playbooks and assemble evidence, but the decision itself is a person's, recorded against the case.

The hosting posture follows the operator's own requirement. All fourteen object types live on the operator's hardware, in the operator's own data center, so nothing in the model leaves the operator's boundary. Identity runs through Keycloak with role-based access control. External links are outbound only: pulls from the collective and sector intelligence feeds, and the platform-to-SIEM exchange the integration contract requires. The only write path into the object model runs through the adapter tier and the services; nothing in the design writes to the energy management system, protection relays or the substation data platform, and recommendations stop at the case and the playbook.

### 5.3  One Object in Its Recorded Form

The block below shows the substation object in its recorded form: an identifier, a label, its kind, the properties passive discovery populates, the four statuses passive discovery allows, and the typed links out.

```
{
  "id": "substation", "label": "Substation",
  "kind": "site",
  "anchored_in": "OT monitoring platform inventory (to be created)",
  "properties": [
    "ID",
    "CIP impact rating",
    "Electronic security perimeter boundary",
    "Sensor count",
    "Criticality"
  ],
  "status_vocabulary": [
    "Not instrumented",
    "Sensor commissioned",
    "Baseline learning",
    "Monitoring"
  ],
  "links": [
    {
      "to": "ot-asset",
      "label": "holds"
    },
    {
      "to": "network-sensor",
      "label": "hosts"
    },
    {
      "to": "cip-evidence",
      "label": "owes"
    }
  ]
}
```

PART II · CHAPTER 6

## Every Source Enters Through an Adapter, Never Directly

Ten named source systems, from the energy management system to the SIEM and the substation data platform, enter through two adapter families that guarantee ordering, provenance and one-way direction onto an event backbone.

Chapter 5 described what the object model holds. This chapter describes how records reach it: ten named sources, two adapter families and one event backbone between them.

### 6.1  Ten Sources, Three Provenance Classes

Figure 5 maps every source to its provenance class and its adapter path. The design names ten sources in three provenance classes. Control-network telemetry: the RTU-to-DNP3 path the energy management system scans, observed one-way through the passive sensors, and the pcap capture stream those sensors produce. Operator systems of record: the SIEM, the OT detection tool, the IT monitoring platform, the substation data platform with its CSV header export, and the vendor OT monitoring platform's own detection and log store. External intelligence: the collective threat intelligence feed the contract requires, and the bodies named on the threat intelligence item object, vendor feeds, E-ISAC, DOE and INL, whose items arrive attributed and dated. External analysis tools complete the map as the sanctioned path for searching and exporting collected data for examination outside the platform. The provenance class matters because each class carries a different audit question: telemetry proves what was observed, systems of record prove what the operator already knew, and intelligence proves where a detection idea came from. Energy sector incidents keep proving the stakes; a December 2025 energy sector incident drew a full follow-up analysis from a national cyber authority (CERT Polska 2025).

![Figure 5. The 10 named systems, the adapter path each one takes, and the object model they all map into.](figures/figure_05.png)

Figure 5. The 10 named systems, the adapter path each one takes, and the object model they all map into.

### 6.2  What the Adapter Tier Guarantees

Both adapter families guarantee the same four things. Direction: every flow is a read out of a source; the adapters never write into a control network, and egress from the highest-impact electronic security perimeters passes hardware data diodes with Lidi beside them. Provenance: every event carries its source, its provenance class and its capture timestamp, so any object in the model can show where each property came from. Contract fidelity: integration adapters speak the published API contracts for the SIEM and the OT detection tool and the CSV header export schema for the substation data platform, with DNP3 and IEEE 1815 protocol context carried alongside. Replay: every adapter is idempotent, so a redelivered batch updates state once, and records that fail validation land in a quarantine queue instead of dropping silently.

### 6.3  The Event Backbone

The event backbone is Apache Kafka 4.3.1 in KRaft mode with three dedicated controllers, so the metadata quorum does not share brokers with data traffic. Events are partitioned by and asset identifier, which holds per-asset ordering while letting the cluster spread load. Delivery is at least once, and idempotent consumers make redelivery safe. Buffers absorb the loss link or a data center segment, sized from the capture rates measured in Phase 1 rather than from estimates. The log is replicated across the broker cluster, and retention is set well inside the evidence clocks the compliance objects carry, since pcap evidence lives in the evidence store, not in the backbone. Time discipline comes from the GNSS-disciplined grandmaster, so a pcap, a sensor event and a backbone record can be ordered against one another when an investigation needs them.

PART II · CHAPTER 7

## All Inference Runs on the Operator's Own Hardware

Detection stays in the procured sensors, reasoning runs on one GPU node at the operator's data center, and only curated data crosses the network boundary, never control traffic.

Chapter 6 described how every source enters the platform through an adapter and lands on the event backbone as an ordered, replayable stream. This chapter places the compute that turns those events into triage drafts, case evidence and answers, and it draws the one line the control networks depend on: data leaves the electronic security perimeter in one direction only, and nothing ever writes back.

### 7.1  Two Tiers of Inference and One Node of Memory Arithmetic

The design runs inference in two tiers, and neither tier puts a model of this design inside an electronic security perimeter. The first tier is detection, and it belongs to the procured OT monitoring platform: vendor signatures and heuristics running in the network sensors and the central platform, refreshed no less than monthly under the contract's update clause. Passive monitoring of the RTU-to-DNP3 path is a control path, so analytics ride a copy of the traffic taken at SPAN or TAP ports; the sensors are the procurement's own product, and the sensor and collector servers around them are fanless, extended-temperature, cabinet-mount class hardware placed outside electronic security perimeters wherever the topology allows (Federal Register 2023).

The second tier is reasoning, and it runs on one node of eight 141 GB HBM GPUs at the operator's own data center, serving the agentic work surface and the ontology. The arithmetic that fixes this node is worth writing out. The frontier model is filed at 753 billion parameters, the largest of the two models the register counts, because the GPUs must hold every weight at once. At FP8 precision, one byte per parameter, the weights occupy 753 GB. Applying the 1.2 planning factor for KV cache and activations raises the requirement to 904 GB. One node of eight GPUs at 141 GB each provides 1,128 GB, which holds the weights with 375 GB to spare beside them; the planning factor itself reserves about 151 GB of that headroom, and the serving register puts the KV cache ceiling at roughly 280 GB once serving overhead is accounted. The embedding model adds about 1.2 GB at BF16 beside it. A smaller GPU class cannot hold the FP8 weights, which is why the node is sized as it is. Figure 6 shows both tiers and what crosses between them.

![Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.](figures/figure_06.png)

Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.

### 7.2  The Latency Budget

The budget has three clocks, and only one of them may never slip. The first clock is detection: capture, parsing and signature matching happen in the procured sensors at line rate, and this design neither adds latency to that path nor touches it. The second clock is transport: curated events, alerts and inventory updates cross the adapters onto the event backbone in machine time, and the backbone's ordering guarantees mean the ontology always replays events in the sequence the networks produced them. The third clock is reasoning: agent triage drafts, playbook retrieval and evidence assembly run in seconds, and seconds are acceptable because the consumer is an analyst at a workbench, not a protection relay. A triage draft that arrives two seconds late costs nothing; an alert that arrives late costs an incident. That distinction sets every placement decision in this chapter. Container scheduling on the reasoning node runs on a hardened Kubernetes distribution, and Prometheus with Grafana and Loki watches the running system so a drifting clock or a saturating broker is seen before an analyst feels it.

### 7.3  What Crosses the Boundary, and What Fails

Only curated data crosses the network boundary, in one direction. By default, egress is a constrained DMZ broker conduit out of each zone; at the highest-impact electronic security perimeters, hardware-enforced data diodes paired with the one-way transfer appliance end the argument about demonstrable one-way flow. Nothing in this design writes to the energy management system, protection relays or the controller, so the boundary has no return path to protect.

Three failures matter. If a link fails, local detection continues unaffected because the sensors are autonomous; events buffer at the broker and the reasoning tier resynchronizes from the backbone when the link returns, so no alert is silently lost. If power fails, uninterruptible power supplies with network-monitored clean shutdown bring the cabinets down in order, and the GNSS-disciplined time card grandmaster holds over, keeping sensor, capture and log clocks in agreement so pcap evidence stays correlated across the outage. If the update path fails, the air-gapped artifact registry scans and stages signature updates, model artifacts and ontology changes offline, and the monthly vendor refresh under the contract's lifetime notification clause degrades in freshness rather than in availability. A stale detection set is an operational nuisance; a blind sensor is an audit finding.

PART II · CHAPTER 8

## The License Decides Whether the Operator Owns the Weights

A 753-billion-parameter model under an MIT license and an Apache-2.0 embedding model are sized to one node of eight 141 GB HBM GPUs, so the operator holds its intelligence outright.

Chapter 7 fixed where inference runs: detection in the procured sensors, reasoning on one node of eight 141 GB HBM GPUs on the operator's own hardware. This chapter names the models that occupy that node, the licenses that let a public utility hold them outright, and the register that ties every model, hardware class, sensing choice and pattern to the ground it stands on. Figure 7 shows the model stack: two models, both open weight, both served on the single central node, one doing the reasoning and one doing the remembering.

![Figure 7. The two models, their placement, and the work each one does.](figures/figure_07.png)

Figure 7. The two models, their placement, and the work each one does.

### 8.1  The Frontier Model That Serves the Work Surface

The reasoning model is GLM 5.2, a frontier-class language model filed at 753 billion parameters, at or above the 300 billion threshold that defines the frontier tier in the sizing rules. As published it occupies about 1.5 TB of weights at BF16, roughly 760 GB at FP8, which is what lets one node of eight 141 GB GPUs hold it, as Chapter 7's arithmetic showed. Its role is the work surface's role: OT security analysts and compliance staff are judgement-over-information workers, and the requirements specification names their workbench explicitly, an analyst workbench for native investigations, step-by-step playbook guides, and case management that auto-associates playbooks. On this model, agents draft triage decisions, retrieve the relevant playbook, assemble the CIP evidence artefact and maintain the ontology itself, all under a named human decision recorded in the case. Its context window of one million tokens suits long evidence chains and playbook reasoning that a smaller window would truncate. The reason it was chosen is its license: GLM 5.2 carries a plain MIT license with no revenue trigger and no security-review clause, which is the difference between the operator owning the weights and renting them. GLM 5.3 and Kimi K3 were weighed and set aside on exactly that ground.

### 8.2  The Embedding Model That Retrieves the Record

The retrieval model is Qwen3-Embedding-0.6B, a 0.6 billion-parameter embedding model under an Apache-2.0 license. It runs beside the frontier model on the same central node, occupying about 1.2 GB at BF16 or about 0.6 GB at eight-bit precision, and it converts playbooks, threat intelligence items and CIP evidence artefacts into retrievable passages. Its 32K window is the deciding property: a whole incident response playbook or a CIP procedure fits as one passage, so an agent retrieving guidance never reasons over a procedure cut in half. BGE-M3 was the runner-up and loses on window length. Because both models hold permissive licenses, the operator's ownership is complete: weights, fine-tunes, the ontology above them and the decision record they write, all on the operator's own on-premises hardware, with identity governed by the on-site identity provider and no external link in the serving path (Federal Register 2023).

### 8.3  The Model and Equipment Register

Table 4 closes the design's technical record. It ties each model to its license, each hardware class to its sizing rule, the sensing to its source, the patterns to their roles and the whole stack to the ground it runs on, so an engineer can build from the table and an auditor can trace the choice.

Table 4 · Model and Equipment Register

| The choice | What was picked | Why here |
| --- | --- | --- |
| Reasoning model | GLM 5.2, 753B parameters, frontier class, FP8, 1M context | Plain MIT license with no revenue trigger or security-review clause; one node of eight 141 GB HBM GPUs holds it; the work surface's role demands long-context agentic reasoning |
| Embedding model | Qwen3-Embedding-0.6B, Apache-2.0, 32K window | Whole playbooks and CIP procedures retrieve as single passages; runs beside the frontier model for about 1.2 GB at BF16 |
| Sizing rule | 1.2 planning factor over FP8 weights | 753 GB of weights times 1.2 is 904 GB against 1,128 GB of node memory, leaving governed headroom for KV cache and activations |
| Frontier compute | One node of eight 141 GB HBM GPUs | The smallest class that holds the FP8 weights; sized from the model's filed parameters |
| Edge compute | Fanless, extended-temperature, cabinet-mount class | Compute stays out of electronic security perimeters wherever topology allows |
| Enclosure and power | NEMA 3R/4X class cabinets with uninterruptible power supplies under Network UPS Tools | Clean shutdown ordering protects capture integrity environment |
| Time synchronization | OCP Time Card GNSS grandmaster with holdover, Linuxptp and chrony | Pcap, sensor and log clocks must agree for evidence to correlate |
| One-way transfer | Hardware data diodes with the one-way transfer appliance at highest-impact perimeters | Demonstrable one-way flow where policy demands it; constrained DMZ conduit elsewhere |
| Site networking | Hardened, fanless, dual-DC industrial switches with SPAN/TAP ports | Segmentation remains the operator's policy decision; the design reads a copy, never the control path |
| Sensing | Passive network traffic capture via the procured OT monitoring sensors at SPAN/TAP sources | The scope watches OT traffic, not premises; no cameras or video models |
| Primary pattern | System of Context over one Hyper-style object model of 14 objects | The lasting asset is the living model of the OT estate, not any single alert |
| Ground | The operator's own on-premises OT hardware and data center | Ownership of weights, ontology, decision record and boundary stays with the operator; identity and update paths run inside the air gap |

PART III · CHAPTER 9

## Shadow Mode and Measured Gates Come Before Scale-Out

Four phases, phased to the scope of work's own split, gate every expansion on measured inventory coverage and false-positive rates, so the next audit finds evidence that was never bolted on.

Chapter 8 fixed the model stack and its licenses: a frontier reasoner under MIT and an Apache-2.0 embedder, both held outright on the operator's own hardware. This chapter describes how the build reaches that state in four gated phases, phased to the scope of work's own split between passive sensor installation and platform integration, so that every expansion is earned by a measurement rather than a plan.

### 9.1  Four Phases with Gates, Not Durations

The rollout runs in four phases, shown in Figure 8, and every phase boundary is a verdict point where measured coverage and alert quality decide whether the work scales. Phase 0, Design and Baseline, carries 3 items across the Governance and Administration, OT Asset Visibility and system of context workstreams: the electronic security perimeter and conduit design, the ontology of the operator's OT estate, and role-based access control with on-premises identity design. Its exit gate is an approved zone and conduit design and an object model ready to receive passive discovery, because every later phase writes into that model and reworking it after sensors land means touching cleared spaces twice. Phase 1, Sensors and Passive Discovery, carries 4 items across the Incident Response and Forensics, OT Asset Visibility and Threat Detection and Monitoring workstreams: passive sensor installation across the substations, baseline learning and the first OT asset inventory, and protocol monitoring on the DNP3 and TASE.2 control paths. This phase implements the scope of work's own 4.1 split, the passive monitoring core, and its exit gate is measured inventory coverage at 95 percent with baseline learning complete; the design does not scale sensor rollout past that coverage number, because an inventory that reaches the audit incomplete is the failure the whole build exists to prevent. Phase 2 carries 7 items across the Integrations and Data Exchange and Threat Detection and Monitoring workstreams: the SIEM, OT detection, IT monitoring and substation data platform integrations, signature, heuristic and ATT&CK-for-ICS detection tuning, baseline deviation anomaly alerting, and passive vulnerability matching with operational-technology context. Its exit gate is the false-positive rate gate, held per input, because an alert flood with no security operations center erodes trust faster than any blind spot. Phase 3 carries 5 items across the Governance and Administration, Incident Response and Forensics, NERC CIP Compliance and system of context workstreams: incident response playbooks and the vendor forensics retainer, threat intelligence sharing with monthly updates, and the compliance evidence and audit pack. Its gate is production of that pack, and it closes the 21 requirements with 21 covered, none partial and none open. The internal network security monitoring obligation that motivates the evidence trail is itself a federal rule for high and medium impact bulk system cyber systems (Federal Register 2023), so the pack is built against a standing duty, not a one-time ask.

![Figure 8. The four phases and their gates, and coverage of the 21 requirements across them.](figures/figure_08.png)

Figure 8. The four phases and their gates, and coverage of the 21 requirements across them.

### 9.2  What the Rollout Measures

Four measurements run from Phase 1 onward. Inventory coverage, the share of passively discovered assets that reach Categorized status, is the scale-out gate. The unidentified-asset count is reviewed weekly, enriched from the substation data platform export and project files, because every unidentified asset at audit time is a finding waiting to happen. False-positive rate is tracked per detection input and per sensor, so a single noisy feed cannot hide inside a fleet average, and per-input drift is instrumented alongside it. Capture growth is measured against the retention clock, with real capture rates from Phase 1 sizing the tiered storage rather than a paper estimate.

### 9.3  Lessons

**Shadow the flags before anyone trusts them.** Every detection runs against the live baseline in shadow before its alerts reach a triage queue, and the false-positive gate reads shadow behavior, not promises. A detection that earns its way out of shadow carries its own tuning history as evidence that the operator's security operations matured on a measured curve. Treat the cleared engineer as the scarce resource. The constraint that dominates this build is not compute or bandwidth but vetted people standing inside electronic security perimeters. Planning access on day one, and designing sensor work to be mirror-first wherever topology allows, is what keeps the phase boundary a verdict instead of a queue. Baselines age as fast as the network changes. A learned baseline is a snapshot of a network that is already moving, so the design treats every change record as an event that re-baselines deliberately. Without that loop, stale baselines manufacture false positives and bury real ones, and both failures surface first at an audit. Buy the detection engine, own the context. Vendor-grade signatures and threat intelligence cannot be rebuilt open source at the accuracy the requirements demand, so the design buys them. The lasting asset, the living model of the estate and every decision taken against it, stays with the operator, and that split is the difference between a procurement and a capability.

### 9.4  What Is Still Open

Three questions remain open, and settling each changes a downstream choice. First, tiered storage sizing waits on measured capture rates; settling it converts a provisional storage envelope into a firm one and fixes the purge policy inside the retention maximum. Second, whether hardware data diodes extend beyond the highest-impact perimeters is undecided; settling it trades capital and permanent operational burden against demonstrable one-way flow at more sites. Third, how agent triage drafts hand off to the vendor incident response retainer under stress is a playbook question; settling it turns the retainer from a contract clause into a rehearsed path, and it is the question the next audit would ask first.

Table 5 · Failure Modes

| What fails | What the design does |
| --- | --- |
| Sensor installation inside electronic security perimeters stalls on vetted-personnel access and lead times | Build the access plan on day one with named people, start Phase 1 on a mirror-first design, and treat the cleared engineer as the scarce resource |
| An alert flood with no security operations center stops being read | False-positive rate is a first-class gate, per-input drift is instrumented, and agent triage drafts carry a visible human decision |
| Passive discovery leaves unidentified assets uncategorized when the audit arrives | Weekly unidentified-asset review, the substation data platform and project-file enrichment, and the 95 percent inventory gate before scale-out |
| Capture and log storage grows unpredictably against the retention clock | Measure real capture rates in Phase 1, size tiered storage from measurement, and set purge policy inside the operator's own maximum |
| Baselines go stale after legitimate network changes | Feed change records and the substation data platform exports into baseline updates as events, and re-baseline deliberately |
| The build depends on the platform vendor for signatures, intelligence and updates | Lifetime vulnerability-notification terms, monthly update obligations, supply chain contract clauses, Harbor-scanned artifacts, and the ontology and agent layers held by the operator |

PART III · CHAPTER 10

## The Intelligence Should Stay with the That Produced It

The object model, the weights, the decision record and the boundary all remain the operator's property, which is the difference between owning a capability and renting one.

The rollout gates every expansion on measurement, but gates decide only when the build proceeds. This chapter settles who holds what the build produces, and why that holding, not any single feature, is what the procurement actually buys.

### 10.1  What the Operator Owns

The object model is the operator's. The fourteen objects, their typed links and the status vocabularies live in the platform layer, and the inventory, alerts, cases and evidence artefacts that accumulate in them are records of the operator's own estate, produced from the operator's own networks. The weights are the operator's: GLM 5.2 carries a plain MIT license with no revenue trigger or security-review clause, and the embedder carries Apache-2.0, so the operator holds its copies outright on its own on-premises hardware rather than renting inference from elsewhere. The decision record is the operator's: every alert triage, escalation, risk acceptance and evidence review is taken by a named person and kept as a case or a compliance artefact, so the trail an auditor reads is the trail the operator wrote. The boundary is the operator's policy object too: the design reads one way out of the control networks, writes nothing into them, and any future write-back is a separate perimeter change request, so the shape of the perimeter stays a decision the operator takes, not one the platform assumes.

### 10.2  The Offer Behind the Design

This design was produced on Praxis, CodeNinja's platform for designing physical AI systems, and it maps directly onto CodeNinja's offer: Hyper Ontology is the fourteen-object model that turns ten fragmented sources into one living picture of the operational-technology estate; Decision Systems is the ranking, attribution and reconciliation that put a triage draft, a playbook or an evidence bundle of a named analyst who decides; Hyper Pragma is the work surface where the operator's own analysts and compliance staff build the agents that draft that work; and Sovereign Infrastructure is the whole hosting posture, open-weight licenses held outright on the operator's own on-premises hardware, with nothing leaving the boundary it drew. CodeNinja builds the design; the operator keeps the intelligence.

PART IV · CONCLUSION

## The Same Shape Runs on Any Regulated Grid

In one view, the design is a read-only mirror of an operational technology estate turned into a single argument: passive sensors watch control traffic, adapters land what they see into one object model, agents reason over that model on hardware the operator owns, and every alert, case and piece of evidence lands in the same linked record the regulator's audit reads. The detection engine is bought, the context is, and the boundary is enforced in hardware where policy demands it.

Running the same shape elsewhere takes four things that transfer across regulated industries: a one-way read path out of the operational boundary so analytics never touch control, an object model that doubles as the audit inventory so compliance is a projection rather than a project, a frontier model held under a license that lets the operator own its weights on its own hardware, and phases gated on measured coverage rather than elapsed time. Any operator whose regulator asks it to prove what is on its networks can build this shape without replacing a single system of record.

PART IV · CHAPTER 11

## How Praxis Contextualized and Reasoned This Design

Every choice in this design traces to a recorded requirement, a sector pitfall or a pinned pattern, and this chapter shows the reasoning trail Praxis kept.

Chapter 10 established that the operator keeps the object model, the weights, the decision record and the boundary. This closing chapter shows how those choices were made, by walking the reasoning trail the design platform kept from the first read of the requirement to the last equipment class. Every design in this series is produced on Praxis, and this chapter lets a reader trace any choice in the design back to what justified it: a recorded requirement, a sector pitfall or a pinned pattern. Figure 9 shows the trail in one view: the ask as received, the family and industry assigned, the records read, the eight lenses consulted, the patterns adopted and set aside, and the equipment classes the reasoning landed on.

### 11.1  Contextualizing the Ask

The ask arrived as an OT monitoring procurement: passive monitoring and detection estate, a platform that makes the estate visible, and compliance evidence that survives a regulatory audit. Praxis assigned the design to the Physical AI family and the energy and utilities industry, with the industry pin taken by the field delivery engineer on this project. What was in the room was substantial: 1,396 records were listed, 113 of them read in full and the remaining 1,283 available on demand, including the full requirements specification and scope of work, the clause set behind every numbered requirement, and the intake answers that fixed the hosting posture on the operator's own on-premises hardware.

![Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.](figures/figure_09.png)

Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.

### 11.2  The Eight Lenses

Praxis read the ask through eight reasoning lenses, recorded in Table 6 with what each could see, what it cited and what it contributed. Two lenses returned nothing and are shown as gaps: no case study in the corpus matches an operational-technology network monitoring build at a United States utility, and the history corpus holds grid cyber incidents that motivate the work but no precedent for this specific platform shape. The design therefore proceeds from the brief's own pitfalls and the requirement text, which is a honest reading rather than a borrowed one.

Table 6 · The Lenses and What They Contributed

| Lens | Could see | Cited | What it contributed |
| --- | --- | --- | --- |
| First principles | The sector brief's own pitfalls | 1 | One-way read out of electronic security perimeters, immutable event objects for auditable trails, analytics riding a copy of the control path rather than touching it |
| Case studies | 13 records | 0 | A gap: no corpus case matches this build, so the design stands on the brief's cyber pitfalls and the requirement itself |
| Tooling and recency | 378 records | 4 | Models checked live for the run; serving, identity, registry and observability components pinned from shelf entries read in full, all inside their freshness windows |
| Hardware and equipment | 47 records | 6 | Compute kept out of the control zone by default, extended-temperature cabinets, fanless industrial switches inside perimeters, one-way egress, and a GNSS-disciplined grandmaster so every clock agrees |
| Rules and regulations | 805 records | 5 | The reliability standards from CIP-002 through CIP-015 bound into scope, with logging, response, information protection and supply chain terms carried into contract clauses (FERC 2008; Federal Register 2023) |
| Approach | 74 records | 2 | Phasing wrapped around the scope of work's own split, each phase boundary a verdict point with a measured gate |
| History | 79 records | 0 | A gap: grid incidents in the corpus motivate the work but offer no precedent for this platform build; the internal monitoring motive carried over from the rules lens instead |
| Domain fusion | The requirement clauses themselves | 2 | Every capability mapped to a clause or a pitfall: the ontology is the audit inventory surface, the alert-to-playbook-to-evidence loop is the kinetic loop, and the one-way egress pattern is the projection mechanism, with no visible seam |

### 11.3  Patterns Adopted and Set Aside

One pattern was pinned as primary: system of context, because the procurement buys detection but the lasting asset is the living model of the estate, with substations, assets, sensors, alerts, cases and evidence projected into it one way and never written back. The one-way egress pattern was adopted beside it as the projection mechanism. Three alternatives were set aside with recorded reasons: a from-scratch open-source build lost because nothing open source carries vendor-grade signatures, mapping accuracy and machine-speed shared intelligence at the accuracy the clauses demand; hardware data diodes lost to a constrained broker conduit at most sites with diodes reserved for the highest-impact perimeters; and two newer frontier models lost to the one with the plainest license, because the license decides whether the operator owns the weights or rents them.

### 11.4  Where the Reasoning Lands

The reasoning lands on equipment classes rather than part numbers: fanless, extended-temperature cabinet-mount compute kept out of electronic security perimeters wherever topology allows; hardened dual-supply industrial switches with SPAN and TAP ports inside each perimeter; NEMA-rated enclosures with uninterruptible power and clean shutdown; a GNSS grandmaster with holdover so packet captures, sensors and logs agree on time; one-way transfer hardware beside data diodes at the highest-impact boundaries; and a single node of eight 141 GB HBM GPUs that holds the frontier weights at FP8 with headroom left for attention state. Each class is a decision the record can defend, and each traces back through Table 6 to the lens that justified it. Everything shown in this chapter was recorded reading: the clauses, the counts, the lens citations and the gaps are what the platform kept, and nothing here is inferred after the fact.

Appendix A

## What Ownership Costs Over Three Years

The design runs its reasoning tier on one GPU node in the operator's own data center. This appendix prices that node against the two ways a utility in the United States could otherwise get the same capability: renting the same accelerators from a cloud region, or buying a closed frontier model by the token. Every input is a public price, dated and cited, and the arithmetic is shown so any reader can rerun it with a written quote. The user count below is an assumption, stated where it is used.

### A.1 The Answer

Owning the reasoning node costs about **510,000 US dollars over three years**, inside a range of 426,000 to 600,000. Renting the same capacity around the clock costs **0.63 million to 1.66 million dollars** over the same period. Against the deepest three-year commitment listed (AWS, three-year EC2 Instance Savings Plan, all upfront), ownership is **about four fifths** the cost. Every rented option can stay inside the United States, so for a US utility the case for ownership is cost, control and a reasoning tier that sits inside the operator's own boundary, not residency.

### A.2 What Owning Costs

| Line | Basis | Three-year cost (USD) |
| --- | --- | --- |
| Frontier tier | One server of eight 141 GB HBM-class cards, 320,000 to 420,000 dollars, typical 370,000 (Mercatus 2026) | 320,000 to 420,000 |
| Support | 8 to 12 percent of hardware value a year (Introl 2026) | 77,000 to 151,000 |
| Power | 7 kW average draw of the server's 10.2 kW maximum (NVIDIA 2026) at a power usage effectiveness of 1.6 (Uptime Institute 2025), 294,336 kWh at the US industrial average of 9.77 cents per kWh in July 2026 (EIA 2026) | 29,000 |
| **Total** |  | **426,000 to 600,000, typical 510,000** |

The node is one server because GLM 5.2 is 753 GB at FP8 and needs 904 GB with the 1.2 planning factor, against 1,128 GB on eight 141 GB cards (Table 4).

### A.3 What Renting Costs

The same server, rented without a break for three years, because alerts arrive at night and an audit does not wait for business hours.

| Option | Basis | Three-year cost (USD) |
| --- | --- | --- |
| AWS, us-east-1, on demand | p5en.48xlarge at 63.296 dollars an hour (Vantage 2026) | 1.66 million |
| AWS, three-year EC2 Instance Savings Plan, all upfront | p5en.48xlarge at 23.80 dollars an hour, the deepest three-year plan in the region (AWS 2026) | 0.63 million |
| Azure, three-year reservation | ND96isr H200 v5 at 1,109,592 dollars for three years in East US 2 (Azure 2026) | 1.11 million |
| Specialist GPU cloud, on demand | 50.44 dollars an hour for eight H200 cards (CoreWeave 2026) | 1.33 million |
| Oracle, three-year commitment | 40 dollars an hour for eight H200 cards (Economize 2026) | 1.05 million |

Egress, storage and support plans are excluded, so every rented figure is a floor. Spot capacity is excluded because a triage service that can be evicted mid-incident is not a security control.

### A.4 What Closed Models Cost by the Token

A closed frontier model replaces the reasoning tier, and it is priced by use. At 25 users (an assumed count across the OT security analysts, compliance staff and incident responders the paper names), each running the equivalent of five agents at 2.4 billion tokens a year, with four input tokens to every output token and half the input served from cache, three years is 180 billion tokens.

| Model | List price per million tokens, input and output | Three-year cost (USD) |
| --- | --- | --- |
| Claude Sonnet 5.5 | 2 and 10 (Anthropic 2026) | 0.52 million |
| Gemini 3.1 Pro | 2 and 12 (Google 2026) | 0.59 million |
| Claude Opus 5.5 | 4 and 20 (Anthropic 2026) | 1.04 million |
| GPT-5.5 | 5 and 30 (OpenAI 2026) | 1.48 million |

The cheapest closed model costs about 21,000 dollars per user over three years, so it matches the owned node at about **25 users**. Below that a closed model by the token is cheaper; above it ownership is, and the gap widens with every user while the owned cost stays flat. Every closed option also sends network telemetry, alert context and compliance evidence about the bulk electric system to a third-party AI service outside the operator's boundary, which the design's constraints rule out.

### A.5 What the Price Does Not Include

- **The procured monitoring platform**: its sensors, collectors, licences and support are bought under the operator's own procurement and are carried the same in every option.
- **Site hardware the design specifies**: fanless collector servers, NEMA cabinets with UPS, GNSS time cards, industrial switches and data diodes at the highest-impact perimeters. Their count follows the operator's substation topology, which a site survey settles; every option carries them.
- **Sales tax, freight and installation**, which a written quote settles.
- **An export licence** does not apply: the hardware stays inside the United States.
- **People, facilities and implementation**, which both sides carry.
- **Price movement.** Cloud prices rose as well as fell in 2026; AWS raised its H200 capacity block price about 15 percent in January (Gigazine 2026).

### A.6 Sources for This Appendix

- AWS. 2026. Compute and EC2 Instance Savings Plans price file, us-east-1, version 20261003071546. <https://pricing.us-east-1.amazonaws.com/savingsPlan/v1.0/aws/AWSComputeSavingsPlan/current/region_index.json>
- Anthropic. 2026. Pricing. <https://claude.com/pricing>
- Azure. 2026. Retail prices, Standard\_ND96isr\_H200\_v5. <https://prices.azure.com/api/retail/prices>
- CoreWeave. 2026. Pricing. <https://www.coreweave.com/pricing>
- EIA. 2026. Electric Power Monthly, Table 5.6.A, July 2026. <https://www.eia.gov/electricity/monthly/epm_table_grapher.php?t=epmt_5_6_a>
- Economize. 2026. OCI BM.GPU.H200.8 pricing. <https://www.economize.cloud>
- Gigazine. 2026. AWS raises EC2 Capacity Blocks prices. <https://gigazine.net>
- Google. 2026. Gemini API pricing. <https://ai.google.dev/gemini-api/docs/pricing>
- Introl. 2026. GPU infrastructure TCO model. <https://introl.com/blog/gpu-infrastructure-tco-model-5-year-enterprise-ai-deployment>
- Mercatus. 2026. H200 server price. <https://mercatus-ai.com/blog/h200-server-price>
- NVIDIA. 2026. DGX H200. <https://www.nvidia.com/en-us/data-center/dgx-h200/>
- OpenAI. 2026. API pricing. <https://developers.openai.com/api/docs/pricing>
- Uptime Institute. 2025. Global Data Center Survey 2025. <https://uptimeinstitute.com>
- Vantage. 2026. EC2 instance prices. <https://instances.vantage.sh>

SOURCES

## Source Register

ENTSO-E. 2025. Grid Incident in Spain and Portugal on 28 April 2025 » ICS Investigation Expert Panel » Factual Report » 3 October 2025. <https://eepublicdownloads.blob.core.windows.net/public-cdn-container/clean-documents/Publications/2025/iberian-blackout/entso-e_incident_report_ES-PT_April_2025_06.pdf>

CERT Polska. 2025. Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. <https://cert.pl/uploads/docs/CERT_Polska_Energy_Sector_Incident_Follow_up_Report_2025.pdf>

Federal Register. 2023. Federal Register :: Internal Network Security Monitoring for High and Medium Impact Bulk Electric System Cyber Systems. <https://www.federalregister.gov/documents/2023/02/09/2023-01453/internal-network-security-monitoring-for-high-and-medium-impact-bulk-electric-system-cyber-systems>

FERC. 2008. 122 FERC ¶ 61,040 UNITED STATES OF AMERICA FEDERAL ENERGY REGULATORY COMMISSION 18 CFR Part 40 Docket No. RM06 to 22 to 000; Order No. 706 Mandatory Reliability. <https://www.ferc.gov/sites/default/files/2020-05/E-2_101.pdf>

CISA. 2026. Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure. <https://www.cisa.gov/sites/default/files/2026-07/aa26-097a-iranian-affiliated-cyber-actors-exploit-programmable-logic-controllers-across-us-critical-infrastructure_508c.pdf>

---

### About CodeNinja

CodeNinja is a Middle Eastern-American artificial intelligence lab focused on building self-improving systems. We are reinventing knowledge work to close the loop between vertical AI use cases and the generalized intelligence that fuels it, accelerating the path toward organizational superintelligence.


---

# Reliability Atlas: A Plant Reliability Assessment Study the Operator Can Audit

Canonical: https://codeatoms.ai/plant-reliability-assessment-saudi-arabia/
DOI: https://doi.org/10.5281/zenodo.23157965
PDF: https://codeatoms.ai/plant-reliability-assessment-saudi-arabia/paper/reliability-atlas-plant-reliability-assessment-saudi-arabia.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

VERTICAL-DRIVEN ARCHITECTURES · ENERGY & UTILITIES · DESIGNED WITH PRAXIS · OCTOBER 2026

# Reliability Atlas: A Plant Reliability Assessment Study the Operator Can Audit

A living reliability object model turns each plant's maintenance records, historian trips and design documents into auditable availability, criticality and root cause evidence for an energy and utilities operator in Saudi Arabia.

CodeNinja Engineering Team

For the asset management and reliability lead accountable for plant availability, the plant and project managers who own the data and the decisions, and the reliability, data and platform engineers who would build and run it.

---

Vertical-Driven Architectures is a CodeNinja series of system designs. Every design in the series is driven by a real-world problem and scenario in a single industry, and every one is designed on Praxis, CodeNinja's platform for designing physical AI systems. Operations are described by class, never by name.

At a glance

## An auditable plant reliability assessment in Saudi Arabia

**What this is.** An open reference architecture for system design in physical AI: a records-based reliability and availability assessment that joins each plant's work orders, trip history and design documents into one reliability object model the operator owns, so every availability figure, criticality rank and root cause finding traces to its source. It is written for the asset management and reliability lead and for the reliability, data and platform engineers who would build it. The operator is described by class, never by name.

**The answer in numbers.**

| Part | The design |
| --- | --- |
| Sources joined | 3 record sources (plant CMMS, plant historian, O&M and design documentation) through 3 read-only adapters, as exports rather than live interfaces |
| Object model | 13 typed objects and the typed links Figure 4 draws, published as JSON for reuse |
| Models | None: the register is empty by design because no inference workload is contracted |
| Method | Availability by Monte Carlo simulation on reliability block diagrams built from each plant's own failure study, auditable to ISO 55000 |
| Compute | No hardware bought; the study runs on the operator's own in-country servers |
| Three-year cost | No hardware line to price: the cost is the assessment work itself (Appendix A) |
| Human control | Predictions are accepted only by a named reviewer and RCA reports validated only by a named engineer |

**Reuse it.** The object model, the model register and the figures are free to reuse under CC BY 4.0. Cite as DOI <https://doi.org/10.5281/zenodo.23157965.>

**Made with.** Reasoned on [Praxis](<https://codeatoms.ai/praxis/>), CodeNinja's platform for designing physical AI systems. The object model imports into [Hyper Ontology](<https://codeatoms.ai/hyper-ontology/>), which turns it into a living system. Both are in beta; access by request.

ABSTRACT

## Availability Should Be Argued From One Joined Record, Not Assembled Report by Report

Which systems actually drive unavailability at each plant, whether installed sparing matches equipment criticality, and whether past root cause analyses (structured investigations into why major events happened) hold up under scrutiny: these are the questions the assessment must answer, and they cannot be answered today because each plant's work orders, trip history and design documents live in separate systems that were never joined, so every availability figure must be rebuilt by hand and defended without a traceable basis.

The design is a records-based reliability assessment anchored on one living reliability object model the operator owns: 3 source systems (plant CMMS, plant historian, O&M and design documentation) enter through 3 adapters (ops systems, telemetry and file and document families) into 13 objects spanning plants, trains, equipment, failure modes, work orders, downtime events, availability predictions and targets, criticality indices, spare parts, major events, RCA reports and reliability programs, served by 5 services (data and site collection, governance, availability assessment, criticality and sparing, RCA validation) on 1 operating surface, with 0 models in the register because no inference workload is contracted; everything runs in the operator's own in-country environment, and the deliverable is an auditable study per ISO 55000 rather than a rented tool.

The paper states the problem and its documented cost, shows why no single system can answer the availability question, then works through the constraints, the layered stack, the object model, ingestion, inference placement (none is contracted), the empty model register, the phased rollout gated on the requirement's own milestones, and who owns what the study builds, closing with the Praxis chapter that traces every design choice to its recorded reasoning.

---

![Figure 1. Reliability Atlas on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.](figures/figure_01.png)

Figure 1. Reliability Atlas on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.

## Contents

Each chapter is tagged for the reader it serves most directly: Executive, Team Lead, FDE, Reference.

|  |  |  |
| --- | --- | --- |
|  | Abstract · Availability Should Be Argued From One Joined Record, Not Assembled Report by Report | Executive |
| PART I · THE PROBLEM | | |
| 1 | [Plant Reliability Is Judged From Evidence Nobody Joins](#ch1) | Executive |
| 2 | [Every Plant System Holds One Slice of the Record](#ch2) | ExecutiveTeam Lead |
| PART II · THE DESIGN | | |
| 3 | [Four Commitments Anchor the Reliability Study](#ch3) | Team Lead |
| 4 | [One Object Model Spans Records, Study and Deliverable](#ch4) | Team LeadFDE |
| 5 | [Thirteen Objects Turn Plant Records Into One Reliability Argument](#ch5) | FDE |
| 6 | [Every Record Enters Through an Adapter, Never Directly](#ch6) | FDE |
| 7 | [No Inference Tier Serves Until the Operator Commits](#ch7) | FDE |
| 8 | [The Model Register Stays Empty by Design](#ch8) | FDEExecutive |
| PART III · THE ROLLOUT | | |
| 9 | [Milestone Evidence, Not Calendar Hope, Gates Each Phase](#ch9) | Team LeadExecutive |
| 10 | [The Reliability Model Belongs to the Operator](#ch10) | Executive |
| PART IV · HOW IT WAS DESIGNED | | |
|  | Conclusion · An Assessment Worth Auditing Is One Worth Owning | Executive |
| 11 | [Every Choice Here Is Traceable to a Recorded Reason](#ch11) | Team LeadFDE |
|  | [Sources](#sources) | Reference |

PART I · CHAPTER 1

## Plant Reliability Is Judged From Evidence Nobody Joins

The operator needs one defensible answer on availability, criticality and root causes at each plant, and today the evidence for that answer sits in separate systems that were never designed to be read together.

The abstract set out the shape of the design: one reliability object model, three source systems, five services, and a study whose every figure can be traced to a record. This chapter establishes why that shape is needed, by stating the question the operator must answer, the cost of leaving it unanswered, and the operation as it actually runs.

### 1.1  The Question the Operation Needs Answered

The operator, an energy and utilities operator in Saudi Arabia, has asked for a reliability and performance assessment across its desalination and treatment portfolio: two seawater reverse osmosis plants and a third treatment site, each operated under a separate project company on a build-own-operate or build-own-operate-transfer contract. The question the operation needs answered is narrow and unforgiving: at each plant, what is the true production availability, what ranks as the dominant contribution to unavailability, are the installed spares matched to that ranking, and do the root cause analyses written after major events actually hold up against the plants' own history. Answering it requires three classes of data that today sit apart: maintenance records with work orders, failure cause codes, downtime hours and spares holdings; historical trip and outage data from the plant historian and supervisory control systems; and the operating and maintenance philosophies, design documents and prior root cause analysis reports that state what the plant was designed to do.

The regulatory ground is layered. The requirement itself demands that the study be traceable and auditable to ISO 55000, the international standard for asset management, which means every availability figure must carry its source, its method and its revision. The plants fall under the national cybersecurity authority's operational technology controls for critical national infrastructure, OTCC-1:2022, which applies to private operators of such infrastructure and tiers its requirements by facility level, so any tooling used near the plants inherits the operator's existing security posture. Above all of this sit the national Vision 2030 water targets, which the water ministry is charged with meeting and which make reliable supply a matter of public commitment, not only contract performance.

### 1.2  The Documented Cost of the Problem

The cost of fragmented reliability evidence is documented beyond this operator. Industry analysis argues that ambiguous terminology and disconnected data in energy and utility software carry a hidden cost, because adapting infrastructure to growth requires stakeholders to agree on what the core data terms mean, and disagreement surfaces as rework, delay and disputed figures (Utility Dive 2025). The safety dimension is starker: a utility worker was fatally shocked after touching a line he had been told was safely de-energized, and the family's suit turns on the gap between a recorded state and the physical truth (Hoodline 2026). A reliability regime built on records nobody joins fails the same way in slow motion: an availability number is asserted, a spare is assumed held, a root cause is accepted, and none of it is checked against the joined evidence.

### 1.3  The Operation as a Scenario

The operation runs three plants through separate project companies under long-term concession contracts spanning decades from their planned commercial operation dates. The desalination plants produce drinking water at a scale the requirement itself prints in the hundreds of thousands of cubic meters per day, and the printed figure for one plant carries an apparent typographical error that the study resolves from the plant's design documents rather than the requirement text. Each plant runs multiple production trains with sparing configurations, so availability is a designed property that erodes through failures, not a single number on a dashboard. The people in the loop are named by role: the operator's project manager who facilitates data access, the project companies' maintenance planners and operations staff, the assessment team's reliability engineers who build and defend the analysis, and the named people who sign the findings. The physical environments are coastal seawater intake and reverse osmosis halls and a treatment site, corrosive, continuous-duty, and unforgiving of a wrongly ranked failure. Three named source systems, three plants, and one question: the named systems count is three, the roles in the loop number four, and the places are the three project sites. The next chapter shows why no existing system can answer that question alone.

PART I · CHAPTER 2

## Every Plant System Holds One Slice of the Record

The CMMS knows the work orders, the historian knows the trips, the document packs know the design intent, and none of them alone can rank what actually causes unavailability.

Chapter 1 defined the question and the three classes of evidence it demands. This chapter walks through what each source system actually sees, what each one misses, and what the gaps cost when the assessment is attempted from any one of them. Figure 2 sets the three systems side by side against the question none can answer alone.

### 2.1  What Each System Sees and What It Misses

The plant's maintenance management system is the richest single slice. It sees work orders with equipment tags, failure cause codes, downtime hours and labor hours; it sees the spares held against each asset and the failure history count that hints at MTBF, the mean time between failures. What it misses is context: it does not know the design intent behind a sparing configuration, it cannot confirm that its cause codes form a complete failure mode taxonomy, and it records downtime as entered, not as the plant physically lost production.

The historian and supervisory control historical data hold the physical truth of operation. They see trip and outage events with authoritative timestamps, running hours, and the production trend through every disturbance, which grounds the availability baseline and validates the failure rates any simulation will consume. What they miss is the why and the what-next: no cause code, no work order reference, no spares position, no link to the design assumption the trip just falsified.

The operating, maintenance and design documentation holds the intent. It sees the maintenance philosophies, the sparing philosophy the designers assumed, the design capacities, and the prior root cause analysis reports written after major events. What it misses is everything that happened since the documents were signed: actual failure counts, current stock levels, whether the recommendations in an old report were ever closed.

![Figure 2. Three systems, each seeing one part of the answer. the question needs all of them in one place at once.](figures/figure_02.png)

Figure 2. Three systems, each seeing one part of the answer. the question needs all of them in one place at once.

### 2.2  What None of Them See Together

None of the three can produce the deliverables the requirement names. Unavailability ranking requires a join: downtime events from the historian, attributed through cause codes in the maintenance system, weighted by consequence from the design documents. Sparing confirmation requires comparing held spares against a criticality index that itself joins probability of failure with production consequence. Root cause validation requires reading a prior report against the failure history that accumulated after it was written. In practice this join is rebuilt by hand for every report, in spreadsheets whose lineage cannot satisfy an ISO 55000 audit, and whose terminology differs from system to system in ways the industry itself documents as a recurring cost (Utility Dive 2025). A figure asserted from one slice and never joined is the reliability version of trusting a de-energization record that was never verified against the wire (Hoodline 2026). The design that follows exists to make that join once, as a queryable object model, instead of once per report.

PART II · CHAPTER 3

## Four Commitments Anchor the Reliability Study

Auditability to ISO 55000, ownership of the model, read-only access to the plants and deliverables scoped to the requirement's own milestone list shape every downstream choice, and each commitment costs something the design accepts.

Chapter 2 showed that the deliverables live in the join, not in any single system. This chapter fixes the four commitments that shape how the join is built, states what each one costs, and records what the design chose against.

### 3.1  Auditability to ISO 55000

The requirement requires the study to be traceable and auditable to ISO 55000, the asset management standard that demands documented, repeatable methods behind every reported figure. This is hard in the water sector because reliability evidence arrives as exports in inconsistent formats and document packs in mixed languages, so a naive analysis buries its assumptions in spreadsheet cells nobody can re-derive. The design therefore makes every availability figure, criticality rank and root cause validation a property on the object model, carrying its source system, its method and its revision, so the audit trail is the data structure rather than an appendix.

### 3.2  The Operator Owns the Model

The reliability object model is built so the operator owns it outright, because the same assessment repeats across the plants and across the years, and a model that compounds beats a report that is read once. This is hard because consultancies traditionally deliver findings as documents, which keeps the method rented and the next assessment a fresh purchase. The cost the design accepts is that the ontology foundation layer must be built in phase one, before any availability number exists to show for it.

### 3.3  Read-Only Access to the Plants

The study reads each plant only through exports and document packs collected during site visits, crossing through the operating companies' own IT channels. This matters because the plants are critical national infrastructure under the national cybersecurity authority's operational technology controls, tiered by facility level, and any connection into a control network would import an entire compliance program the requirement never funded. The cost is that data is a snapshot per visit, never live, and the collection plan depends on facilitation by the operator's project manager rather than a contractual mandate.

### 3.4  Deliverables Bind to the Requirement's Milestones

Every scope item binds to the requirement's own milestone gates: data collection evidences the first payment milestone, and reports with comments closed evidence the second, while the contract caps delay penalties at 20 percent of contract value. This is hard because the schedule per project runs from purchase order and compresses badly under data access friction, so the phases are gated on evidence, not on calendar hope.

### 3.5  Scoping Decisions and Their Costs

Three decisions carry the design's shape, each bought at a stated price, as Table 1 records.

Table 1 · Scoping Decisions

| Decision | What it buys | What it costs |
| --- | --- | --- |
| One reliability object model as the study's spine | Every figure carries its source, method and revision, and the assessment can be re-run per project | The ontology is built in phase one, before the assessment numbers appear |
| Read-only access through exports and document packs | No connection touches any control network, so no new cybersecurity surface at critical infrastructure | Data is a snapshot per collection visit, not live |
| Agent work surface offered but not committed | No inference workload is contracted, so licensing and hardware stay simple | Analysts read findings from the model without an interactive assistant until the operator confirms it wants one |

### 3.6  What the Design Chose Against

Each rejection below was a live alternative, and each was set aside for a stated reason, as Table 2 records.

Table 2 · What the Design Chose Against

| Where | What was picked | Instead of, and why |
| --- | --- | --- |
| Availability method | Monte Carlo simulation on reliability block diagrams built from each plant's own failure and downtime data | A packaged availability tool, because the study must be traceable to ISO 55000 and the requirement makes any tool optional: a method the operator can re-run and audit outranks a rented black box |
| Study outputs | Objects on a living reliability object model the operator owns | Static report documents only, because the same assessment repeats per project and the model compounds while a report is read once |
| Data access | Exports and document packs through the operating companies' IT channels | Live integration into plant control systems, because no platform connection should touch a distributed control or supervisory network in a records-based study |
| Site verification | Engineer walkdowns | Cameras or new instrumentation, because no field equipment is procured and the evidence base is the plants' own records |
| Contracted scope | The assessment studies named in the requirement's scope section | Enterprise resource planning features, which the requirement's general terms penalize elsewhere but which this scope never included, recorded in the kick-off minutes |
| Out of scope | Reliability program implementation, historic data migration, third-party license fees, hardware and infrastructure | All left with the project companies and the operator, because the study assesses and recommends and does not execute |

PART II · CHAPTER 4

## One Object Model Spans Records, Study and Deliverable

The architecture is deliberately thin: systems of record stay untouched below, one reliability object model in the middle carries every finding as a queryable object, and the services and operating surface above produce the auditable studies.

Chapter 3 fixed the constraints: a read-only study over records, auditable to ISO 55000, that touches no plant system and installs no field hardware. This chapter shows the thin stack that carries those constraints, and why a records-based engagement earns its keep partly by what it deliberately leaves out.

### 4.1  The Three-Layer Pattern, Applied Thinly

The architecture follows the pattern the series designs on: systems of record below, one object model in the middle, applications and agents above. At the bottom sit the three source systems the study reads: each plant's computerized maintenance management system (CMMS), the plant historian holding SCADA historical data, and the O&M and design documentation packs. These systems are never replaced, never modified and never loaded with new software; the study reads exports from them and writes nothing back, and no platform connection ever touches a plant control network. In the middle sits one reliability object model, a projection over those silos rather than a shadow copy of any one of them, holding thirteen object types from plant down to reliability program. Above it run five services and one operating surface. The pattern fits this engagement because the contracted output is an auditable argument: every availability figure, criticality rank and root cause analysis (RCA) validation finding must carry its source system, its method and its review status, and that argument can only live where the silos join. Figure 3 shows the layered stack with the component count at each layer, and the deliberate emptiness of two layers, instrumented sensing and served inference, is part of the design rather than an omission.

![Figure 3. The layered stack: 3 sources, 3 adapter families, 13 objects, 5 services and 1 surfaces.](figures/figure_03.png)

Figure 3. The layered stack: 3 sources, 3 adapter families, 13 objects, 5 services and 1 surfaces.

### 4.2  The Stack Stage by Stage

Table 3 walks the stack in order and names the components at each stage. Three stages deserve comment beyond the table. Sources are exactly the three systems named in Chapter 6, read in place. Sensing is, in this scope, the engineer walkdown and the document pack collected on site: the stage exists in the pattern, and this study fills it with human observation rather than cameras or instruments, because site verification is a records exercise and no field hardware is procured. Inference is carried deliberately light: the analytic workload is a Monte Carlo availability simulation on reliability block diagrams built from each plant's own failure and downtime data, run inside the assessment tooling, and the model register is empty because the contracted study is the deliverable, not a predictive service. Services and surfaces carry the named components: five study services and one operating surface through which the operator's reviewers read, query and accept findings.

Table 3 · The Stack, Stage by Stage

| Stage | What it is responsible for | How |
| --- | --- | --- |
| Sources | Holding the evidence base: work orders, failure history, trip and outage history, O&M and design records | Read in place as exports and document packs during site visits; never modified |
| Sensing | Capturing physical verification at the plants | Engineer walkdowns and on-site document collection; no cameras or instruments in scope |
| Adapters | Mapping each source's native format into the object grammar | Three adapter families: ops systems adapter, telemetry adapter and file & doc adapter; all read-only |
| Object model | Carrying thirteen object types and their typed links as one queryable projection | An ontology store operated in-country, projected over the three source systems |
| Inference | Producing the availability and criticality computations the study contracts | Monte Carlo simulation on reliability block diagrams inside the assessment tooling; no served models |
| Services | Executing the five contracted workstreams | Data & Site Collection, Governance, Availability Assessment, Criticality & Sparing, RCA Validation |
| Surfaces | Giving reviewers and engineers one place to read, query and accept findings | One operating surface over the object model; no agent work surface committed |

PART II · CHAPTER 5

## Thirteen Objects Turn Plant Records Into One Reliability Argument

Plants, trains, equipment, failure modes, work orders, downtime events, availability predictions and targets, criticality indices, spare parts, major events, RCA reports and reliability programs bind into one queryable projection, and the human decision loop lives on the model's only write path.

Chapter 4 placed one reliability object model at the center of the stack. This chapter walks the model itself: thirteen object types, the typed links between them, where the human decision loop lives, and one object exactly as recorded.

### 5.1  Thirteen Objects and Their Typed Links

The model holds thirteen object types: Plant (a site), Production train and Equipment (assets), Failure mode, Work order and Availability prediction (records), Downtime event and Major event (events), Availability target and Criticality index (measures), Spare part (material), and RCA report and Reliability program (documents). Figure 4 shows every object and its typed links, with the Equipment object at the focal point because most of the argument runs through it. The links are typed and directional, so each one states what kind of fact it carries: a work order rides on an equipment tag, a downtime event loses production on a train, a spare part covers an equipment class, an availability prediction is compared against an availability target. What a query can reach across these links is exactly what no document store can: which closed work orders sit on equipment ranked above the criticality threshold, how much production their trains lost in downtime, and whether a spare was held for each, is a traversal across five links and three source silos, while a document store holds each report as a separate file with no way to traverse. A shared, explicit vocabulary for these nouns and facts is what makes such joins trustworthy, and ambiguity in energy and utility data terminology carries a documented cost when stakeholders each read the same term differently (Utility Dive 2025). The model is where that ambiguity is settled once, for all three plants.

![Figure 4. The thirteen objects of the model and the typed links that let a query reach across them.](figures/figure_04.png)

Figure 4. The thirteen objects of the model and the typed links that let a query reach across them.

### 5.2  Where the Human Loop Lives

The model's only write path runs through named people, and the status vocabularies encode their decisions. An availability prediction moves from Drafted to Reviewed to Accepted only when a named reviewer accepts it; an RCA report moves from Under review to Validated to Recommendations closed only when a named engineer signs the validation; a major event moves from Open through Under investigation to Closed. Every object carries its source system, its method and its review status, so the traceability the audit demands is a property of the model itself rather than a reporting afterthought. The hosting posture follows the operator's own requirement: the model runs in-country in Saudi Arabia, identity and access are governed by the operator's existing directory and single sign-on rather than any new account system, and no external link leaves the model's boundary toward anything outside it. The adapters that feed it are read-only, so the model is the single place where anything in this engagement ever changes state.

### 5.3  One Object as Recorded

The equipment object shows the grammar at its most concrete: identity, label, kind, typed properties, a closed status vocabulary and the links that tie it to failure modes, work orders, spare parts and its criticality rank; the platform prints it below as recorded.

```
{
  "id": "plant",
  "label": "Plant",
  "kind": "site",
  "anchored_in": "",
  "properties": [
    "Design capacity (m3/day)",
    "Technology (SWRO or sewage treatment)",
    "Contract type",
    "25-year contract term",
    "Commercial operation date",
    "Location"
  ],
  "status_vocabulary": [],
  "links": []
}
```

PART II · CHAPTER 6

## Every Record Enters Through an Adapter, Never Directly

Three source systems of domain-typical provenance enter through three adapter families as exports and document packs collected during site visits, and nothing streams because no live feed crosses into this engagement.

Chapter 5 showed what the model holds and who writes to it. This chapter shows how records get into it, and why nothing about that path is live.

### 6.1  Three Sources, One Provenance Class

Three named source systems feed the model, and Figure 5 maps each one to its adapter path. The plant CMMS and maintenance records carry work orders, failure history, downtime records and spares holdings, and anchor the train, equipment, failure mode, work order and spare part objects. The plant historian, holding SCADA historical data, carries trip and outage history and grounds both the availability baseline and the failure rates fed to the simulation. The O&M and design documentation, a document pack rather than a system, carries operating and maintenance philosophies, design documents and prior RCA reports. All three share the same provenance class, domain-typical: they are described by function, not by vendor, because they are the systems any plant of this class operates, and the engagement reads them wherever they run. All three are read-only; nothing in this design writes back to any of them.

![Figure 5. The 3 named systems, the adapter path each one takes, and the object model they all map into.](figures/figure_05.png)

Figure 5. The 3 named systems, the adapter path each one takes, and the object model they all map into.

### 6.2  What the Adapter Tier Guarantees

Three adapter families cover the three sources: an ops systems adapter for the CMMS exports, a telemetry adapter for historian exports, and a file & doc adapter for the O&M and design packs. Each family guarantees the same four things. First, it is read-only and connects to nothing on any plant control network; data crosses as one-way exports through the O&M companies' own IT channels. Second, it maps each source's native fields into the object grammar, so that a downtime hour or a failure cause code means one thing across all three plants; this canonical mapping is where terminology risk is retired, since a shared data definition agreed once beats three implicit ones, a point regulators themselves have had to legislate for in energy data (Ofgem 2024). Third, it stamps every object it creates with its source system and collection date, so provenance travels with the finding. Fourth, it is idempotent: re-loading an export set produces the same model state, never a duplicate.

### 6.3  The Event Backbone, Stated as an Absence

Nothing streams, and the backbone is batch by design: no live feed crosses into this engagement, so there is no event log to order, buffer or replicate in the streaming sense. Ordering still holds a precise meaning: each export set travels with a collection manifest, and every downtime event arrives timestamped by its source system, so the study's ordering is deterministic without any message broker. Delivery is a versioned export set per site visit; where a set is incomplete, the fix is re-collection on the next visit, not a retry queue. Buffering is the document pack at rest in the engagement workspace. Replication is the operator's own document control holding the same export sets, which keeps a second copy inside the boundary without new infrastructure. For a three-month records study this is sufficient by construction, and the regulated character of utility communications practice (Federal Register 2024) reinforces the choice: keeping live interfaces out of scope means no new regulated communication surface is created. Live integration into plant systems is left to a confirmed follow-on, where the adapter tier would extend rather than change.

PART II · CHAPTER 7

## No Inference Tier Serves Until the Operator Commits

This design is honest about placement: the contracted deliverable is a study over records, so no edge node, site server or language model is sized, and inference enters only if the operator confirms it wants the agent work surface.

Chapter 6 closed the path into the design: three source systems enter through three adapter families, as exports and document packs rather than live feeds, and everything that lands does so on the reliability object model. That model invites the next question, which is where the reasoning that turns records into availability predictions and unavailability rankings should physically run. The honest answer under this requirement's scope is that almost none of it runs anywhere yet, and this chapter says so seat by seat rather than blurring it.

### 7.1  The Seats in Figure 6 and Who Sits in Them

Figure 6 draws the placement the series uses: an edge tier at each plant, a site tier in an in-country data center, an in-country language model tier behind the work surface, and a frontier cluster class reserved for large open-weight models. In this design three of those seats are empty on the record and the fourth is unsized. The edge tier is empty because nothing is watched: no cameras, no sensors, no positioning, and nothing moves in this design's frame, since the world is read through records. The site inference server is empty because no model is served at any plant; the study runs on the operator's own in-country servers and storage, which the operator already holds. The language model tier is empty because the agent work surface is offered, not committed, and the requirement confirms no such workload. The frontier cluster is unsized for the same reason.

The memory arithmetic that this chapter normally carries, weights against usable memory and the KV cache ceiling computed from context length and concurrency, has nothing to compute: no weights are registered, so no weight figure exists to place against any memory figure. The chapter states that plainly rather than filling the gap. If the operator confirms the work surface, the language model tier becomes real, and the arithmetic is then performed against the model chosen at that point, never assumed in advance of the confirmation.

![Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.](figures/figure_06.png)

Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.

### 7.2  Latency on a Human Clock

With no live inference there is no millisecond budget to defend, and the design does not invent one. The latency that governs this study is human: the interval between an export leaving a plant and an analyst reading it onto the object model, and the interval between an availability prediction drafted with status Drafted and the named reviewer who moves it to Reviewed and then Accepted. Both intervals are measured against the requirement's own milestone gates, which are evidence-based rather than streaming-based, so the budget is expressed in collection rounds and review cycles, not in queue depths or token throughput.

### 7.3  What Crosses, and What Fails

What crosses the boundary is read-only: work orders, downtime history, historian trip records, and O&M and design document packs, all crossing one-way through the O&M companies' existing IT channels. Nothing crosses back. No platform connection touches any plant's DCS, SCADA or control network, which stays untouched, so no data diode is procured by this scope. Utility communication practices are directly regulated in mature markets (Federal Register 2024), and keeping the crossing one-way and export-shaped is the conservative posture wherever a plant sits.

Failure is handled by shape rather than by redundancy. If the link fails, nothing is lost mid-flight, because nothing streams: export packs are versioned and simply re-issued. If a plant loses power, that plant's collection pauses while the model itself is unaffected, since it is a projection rebuilt from versioned artifacts and a pause corrupts nothing. If the update path fails, there is nothing to resynchronize: no weights exist, no model registry runs, and the study's artifacts are versioned under document control. One caution closes the chapter: a record can describe a state a system is not in, and the industry has seen a lineman die after touching a line he had been told was de-energized (Hoodline 2026). That is why site verification in this study rests on engineer walkdowns, never on records alone.

PART II · CHAPTER 8

## The Model Register Stays Empty by Design

No model is named because no inference workload is contracted, and an empty register recorded plainly outranks a speculative one that the scope cannot justify.

Chapter 7 emptied the inference seats and tied the one conditional seat to a confirmation only the operator can give. The register behind those seats is where that honesty is recorded, and this chapter reads it exactly as it stands.

![Figure 7. The zero models, their placement, and the work each one does.](figures/figure_07.png)

Figure 7. The zero models, their placement, and the work each one does.

### 8.1  One Line Above the Object Model

Figure 7 draws the model stack as a single line: an empty register sitting above the reliability object model, and nothing above the register. The subsection that would normally name each model in prose, with its parameter count, architecture, precision, context window, language coverage, license and terms, has nothing to name, and this is that statement rather than an omission. The contracted deliverable is the assessment study over records, so no inference workload is contracted, and naming a model would place a speculative artifact where the requirement expects an auditable method. That method is Monte Carlo availability simulation on reliability block diagrams built from each plant's own failure and downtime data, and it needs no weights to run.

The register's plainness also has an economic argument. Industry publication Utility Dive argued that ambiguous energy software terminology carries a hidden cost, because coordinating stakeholders inherit the ambiguity (Utility Dive 2025). Naming a model with no workload behind it creates exactly that ambiguity between what the contract covers and what is merely offered. Even the meaning of core energy data terms is contested enough that a national regulator has consulted on redefining them (Ofgem 2024), which is why the nouns are fixed once on the ontology instead: plant, production train, equipment, failure mode, downtime event, each defined before any method binds to them. Licenses follow the same logic in reverse. With zero models there are no license triggers to state, yet the ownership principle still holds: the operator owns the object model outright, owns the study artifacts, and would own any fine-tune if the work surface is confirmed, at which point an open-weight license becomes the selection criterion so that the operator holds its own weights. A precedent read during design, a knowledge-graph-below, applications-above build in this sector, reinforced the same discipline of honest confidence bands and an asset ontology first.

### 8.2  What Table 4 Holds Instead

Table 4 is the model and equipment register, and with the model rows empty it carries what the design does stand on: the hardware classes and sizing rules, the sensing, the pattern it stands on, and the ground it runs on. Each row states what was picked and why here, so the register remains the single place a reviewer checks what the scope actually buys.

Table 4 · Model and Equipment Register

| The choice | What was picked | Why here |
| --- | --- | --- |
| Models | None: the register is empty by design | No inference workload is contracted; the deliverable is the study, and an empty register recorded plainly outranks a speculative entry the scope cannot justify |
| Hardware classes and sizing rules | None procured; the study runs on the operator's own in-country servers, storage and data center capacity | No field hardware, no edge compute and no serving runtime is installed under this scope |
| Sensing | No cameras, no sensors and no positioning; site verification is by engineer walkdowns | The world is read through records, so nothing is watched and nothing needs country legality stated |
| The pattern it stands on | System of context as the primary pattern, with the reliability object model as a projection over the three systems of record | Unavailability ranking, sparing confirmation and RCA validation are cross-silo joins that no single source system can produce alone |
| The ground it runs on | In-country hosting in Saudi Arabia, with identity through the operator's own directory and single sign-on, procured by class | The operator's requirement keeps data inside the country's boundary and under the operator's identity, which the operator already operates |

PART III · CHAPTER 9

## Milestone Evidence, Not Calendar Hope, Gates Each Phase

Three phases of six, three and three items run the plants in parallel behind the requirement's own gates, measure production availability against target, and carry requirement coverage with three gaps stated plainly.

Chapter 8 closed the design with a deliberately empty model register: the contracted output is a traceable assessment, not a served model, so this build's intelligence lives in its method and its object model rather than in weights. This chapter shows how that method reaches all three plants in parallel, what each phase must prove before the next begins, and where the work can fail.

### 9.1  Three Phases Behind the Requirement's Own Gates

The rollout runs three phases of six, three and three items, with their workstreams, gates and requirement coverage shown in Figure 8. Phase 1 carries six items across the Data & Site Collection and Governance workstreams: the ontology foundation layer, plant data collection at three sites, availability target confirmation with the operator, the per-plant data inventory, the access agreements with each project company, and the method baseline for the availability simulation. Its exit gate is evidence, not a date: a complete inventory and confirmed targets, or a derived basis signed off, matching what the requirement's data collection milestone reads at 40 percent. Phase 2 carries three items across the Availability Assessment and Criticality & Sparing workstreams: single points of failure identified, sparing confirmed against the criticality index, and the sensitivity of design alternatives modelled. Its gate is the requirement's reports milestone at 50 percent: draft assessment reports with reviewer comments closed. Phase 3 carries three items across the Governance and RCA Validation workstreams: major event root cause analyses revised and validated, the reliability programs assessed, and final assessment reports per project. Requirement coverage is stated plainly: of eight requirement lines, five are covered, zero are partial, and three are carried as declared gaps, the requirement's compliance, delay-damage and preamble clauses, legal boilerplate outside a technical study's reach, recorded with reasons rather than absorbed silently.

![Figure 8. The three phases and their gates, and coverage of the 8 requirements across them.](figures/figure_08.png)

Figure 8. The three phases and their gates, and coverage of the 8 requirements across them.

### 9.2  What the Rollout Measures

The headline measure is production availability, in percent, with a nominal value of 96.0 and a breach when the attained figure falls below it; the fault it watches is the defining one, a desalination train trip dropping a plant below its target production. Around the headline, the rollout counts single points of failure identified and dispositioned, sparing positions reconciled against the criticality index, root cause analyses validated against closed recommendations, and requirement coverage against the eight lines. Every figure lands on the object model with its source system, its method and its confidence band, so the operator's reviewers, not the study team, turn a drafted prediction into an accepted one.

### 9.3  Where the Work Can Fail

The failure modes below are the ones the requirement's own structure creates: the custody chain, the compressed schedule and the printed record itself. Table 5 pairs each with what the design does about it.

Table 5 · Failure Modes

| What fails | What the design does |
| --- | --- |
| Data access at the three project companies stalls collection, since the operator facilitates it but no clause mandates it | The named data custodian and data list per plant are agreed at kick-off, and escalation runs through the operator's project manager within the first fortnight, not at the milestone |
| Availability targets are never supplied, leaving every prediction's comparison undefined | Targets are confirmed in phase 1; where the operator defers, derived targets with a recorded basis are proposed for sign-off before modelling starts |
| The systems at each plant, historian, CMMS or O&M records, are unstated, so collection effort cannot be priced tightly | The phase 1 data inventory is an output in its own right and collection is re-baselined after the first site visit |
| Three plants on a compressed schedule collide with data access friction | Plants run in parallel on shared method assets, each phase gated on the requirement's milestone evidence rather than calendar hope |
| The requirement prints one plant's design capacity with an apparent typographical error | Design capacity is confirmed from the plant's design documents before any simulation runs |
| The sanction clause on enterprise resource planning features invites scope creep at review | Kick-off minutes record that the contracted outputs are the assessment studies and no ERP scope exists under this requirement |

### 9.4  Lessons

**Data access is the critical path, so the first fortnight is about custodians, not tools.** The sector's consistent lesson is that an assessment which cannot see work orders and trip history changes nothing, which is why phase 1 spends its items on inventory, agreements and custodians before any modelling begins.

**Gate on milestone evidence, not on the calendar.** A compressed schedule across three plants plus data access friction is exactly where calendar hope breaks, so each phase proves the requirement's own milestone evidence before the next begins.

**Coverage is not an outcome.** A published predictive maintenance program across many thousands of assets reported activity metrics without a reliability outcome, so this rollout reports attained availability and validated analyses rather than volume of work done.

**Verify the record before the assessment believes it.** A lineman died in Texas in 2026 after touching a line he had been told was safely de-energized, and his family is suing the utility (Hoodline 2026); the analogue in a records study is blunt: a cause code, a printed capacity or a stated target is a claim, and the design confirms each against source documents before treating it as fact.

### 9.5  What Is Still Open

Three questions remain open. Whether the operator wants the agent work surface: a yes would add a served language model and a frontier compute class to the register, turning a records study into a serving build. Whether the availability targets arrive: settling them fixes the comparison column of every prediction and retires the derived-basis contingency. Which systems exist at each plant: settling the inventory re-baselines collection on facts rather than first-visit findings. A fourth question sits beneath all three: even core data terms lack settled meanings in this sector, as a regulator consultation on the definition of energy system data shows (Ofgem 2024), and ambiguous terminology carries a real cost when stakeholders must agree on what words mean (Utility Dive 2025), so the design pins its own definitions on the object model, plant by plant, where they can be argued with rather than assumed.

PART III · CHAPTER 10

## The Reliability Model Belongs to the Operator

The object model, the assessment method, the decision record and the data boundary all stay with the operator, which is exactly what makes the next assessment cheaper than the last.

Chapter 9 showed the phases, the gates and the measures. This chapter fixes who owns what those phases build, because in a study that binds three plants' records into one model, ownership is the difference between a compounding asset and a report that ages badly.

### 10.1  What the Operator Holds at the End

The object model is the operator's. The thirteen reliability objects, their typed links and the ontology instance they live on are handed over as a living projection over its own CMMS, historian and design records; the adapters read and never write, and the only write path is a named person's recorded acceptance. Weights and fine-tunes: none exist, and the design says so plainly; the model register is empty because no inference workload is contracted, so the transferable intelligence is the method itself, the reliability block diagrams, the simulation method, the criticality worksheets and the report structures, all owned by the operator and re-runnable without the study team. The decision record is the operator's too: every availability figure accepted, every criticality rank confirmed, every root cause analysis validated is stored against the model with its reviewer, date and basis, so the next assessment reads this year's reasoning instead of reconstructing it. The boundary is the operator's: data stays in-country on operator-side hardware, nothing connects into any plant's control network, records cross as one-way exports through the O&M companies' own IT channels, and access runs through the operator's existing directory and single sign-on, which it already operates.

### 10.2  The Offer Behind the Design

This is a CodeNinja design, produced on Praxis, the platform that reasons and records designs of this shape. The object model at its center is Hyper Ontology; the unavailability ranking, the sparing reconciliation and the availability predictions, each one decided by a named person at the operator, are Decision Systems in the strict sense; and the design's Sovereign Infrastructure character comes from running in-country, on the operator's own hardware, with no model weights and no external service crossing the data boundary.

PART IV · CONCLUSION

## An Assessment Worth Auditing Is One Worth Owning

The design reads three plants' existing records through adapters into one reliability object model the operator owns, and every availability figure, criticality rank and RCA validation on that model carries its source system, its target comparison and its audit trail, so the study's conclusions can be re-run, challenged and reused at the next assessment instead of being reassembled from silos.

Running the same shape elsewhere takes three commitments: treat data collection as the project rather than a prerequisite, keep the method traceable and auditable to ISO 55000 so the operator can re-run it without the assessor, and leave the object model as the compounding asset even when the contracted deliverable is a document, because the sector's own experience shows that ambiguous terminology across organizations carries a real cost (Utility Dive 2025) and that data definitions drift unless someone governs them (Ofgem 2024).

PART IV · CHAPTER 11

## Every Choice Here Is Traceable to a Recorded Reason

Praxis contextualized the ask, assigned the family and industry, and put eight lenses over the work, including two that returned nothing, so any design decision can be traced back to what justified it.

Chapter 10 fixed ownership of everything the design builds. This last chapter turns inward: it shows how the design itself was reasoned, so that any choice in the preceding ten chapters can be traced back to what justified it, on the record rather than in recollection. Every design in this series is produced on Praxis, and Figure 9 shows the trace for this one: the ask as received, the family and industry assigned, what was in the room, the eight lenses set over the work, the patterns adopted and the equipment classes, empty by design, where the reasoning lands.

### 11.1  Contextualizing the Ask

The ask, in the operator's own words, was a reliability and performance assessment study across three water plants held under build-own-operate and build-own-operate-transfer contracts: availability prediction, unavailability ranking, sparing confirmation and root cause analysis validation, traceable and auditable to ISO 55000. Praxis assigned the family as physical AI and the industry as energy and utilities; the pin is recorded as the engagement lead's own decision rather than a reasoned match, and the industry brief was still read as a reasoning input. What was in the room: 1,272 records listed, 119 read in full and 1,153 available on demand, including the full requirement text with its scope, evaluation method, general terms and bilingual contract clauses.

![Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.](figures/figure_09.png)

Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.

### 11.2  The Eight Lenses

Table 6 sets out all eight lenses, what each could see, how many entries it cited and what it contributed. Two lenses, hardware and equipment and history, returned nothing for this shape of work, and the table shows them as gaps rather than padding them with borrowed claims. The rules lens read the national cybersecurity authority's operational technology control OTCC-1:2022 for the requirement's compliance clause.

Table 6 · The Lenses and What They Contributed

| Lens | Could see | Cited | What it contributed |
| --- | --- | --- | --- |
| First principles | The full brief, no shelf behind it | 1 | The asset-to-alert-to-work-order pattern and the fuse-everything doctrine shaped the reliability object model: unavailability ranking is a cross-silo join, never one system's report |
| Case studies | 19 records in the room | 1 | A North Sea operator's lesson that integration is the project drove the phase 1 data-collection design; a ten-thousand-asset predictive maintenance program warned that coverage is not a reliability outcome |
| Tooling and recency | 347 records in the room | 2 | the object model v0.9 was named for the object model; every serving layer was marked not needed because no inference workload is contracted |
| Hardware and equipment | 43 records in the room | 0 | A gap: nothing is procured by this read-only study, so no hardware entry was read and none is asserted |
| Rules and regulations | 741 records in the room | 1 | Tiered cybersecurity obligations for private operators of critical national infrastructure, with the safety carve-out as the route for controls that would threaten plant continuity |
| Approach | 63 records in the room | 1 | Nouns before work: the object model built in phase 1, every later item binding to it, and later phases earned through the requirement's milestone gates |
| History | 59 records in the room | 0 | A gap: the filed precedents concern oil-and-gas and grid incidents, none bearing on a water-sector reliability study |
| Domain fusion | The full brief, no shelf behind it | 2 | Projection-over-silos fused with the utilities doctrine of fusing commercial and operational data: every availability figure carries its source, target comparison and audit trail as ontology properties |

### 11.3  Patterns Adopted and Set Aside

One pattern was adopted, system of context, pinned by the engagement lead as the primary shape: three layers in fixed order, systems of record below that are never replaced, modified or loaded, the object model in the middle as a projection over them rather than a shadow copy, and applications above. Its grammar is deliberately small: nouns become objects, facts become properties, relationships become typed links, and actions change status. The set-aside list is empty, and that is itself a finding: because the work is a records-based study, the patterns a watched-site build would weigh, live streaming, video ingest, edge serving, tracking, container orchestration and model registries, were never candidates, so nothing was set aside so much as never invited.

### 11.4  Where the Reasoning Lands

The reasoning lands on an empty equipment register, and it lands there on purpose. No edge compute, no site inference server, no cameras, no enclosures, no site networking, no positioning, no synchronization hardware, no one-way transfer device and no frontier cluster: every hardware class was marked not needed because the study reads records, and the identity layer is bought by class from the operator's own directory rather than built here. That emptiness is the honest edge of the design. Everything shown in this paper, from the thirteen objects to the three-phase gate structure to the two lens gaps, was recorded reading: a clause, a precedent, a record in the room or a decision with a name on it. Nothing is inferred, and nothing needs to be.

Appendix A

## What It Costs

The design buys no hardware and serves no model. The assessment runs on the operator's own in-country servers and storage, the model register is empty by design, and the world is read through records rather than sensors, so there is no owned-versus-rented comparison to print. The cost of this design is the assessment work itself: data collection, reconciliation, availability modelling and the root cause reviews, carried on infrastructure the operator already pays for.

### A.1 What Would Change the Answer

| Line | When it appears | How to price it |
| --- | --- | --- |
| Document retrieval over the plant record | If the design document packs and work order history grow beyond what keyword lookup on the object model serves | One self-hosted embedding model on CPU or a single mid-range GPU card; a server of eight 48 GB class cards is about 85,000 dollars (Newegg 2026) |
| A generative work surface | If the operator later asks to query the reliability model in natural language | A frontier open-weight model on one node of eight 141 GB HBM-class GPUs, 320,000 to 420,000 dollars (Mercatus 2026), which ships to Saudi Arabia only under a US export licence |
| Live plant data | If a later phase replaces exports with live historian feeds | The operator's own OT integration and security programme, which this scope deliberately does not import |

### A.2 Sources for This Appendix

- Mercatus. 2026. H200 server price. <https://mercatus-ai.com/blog/h200-server-price>
- Newegg. 2026. Supermicro SYS-421GE-TNRT-02-G1. <https://www.newegg.com/p/N82E16859152404>

SOURCES

## Source Register

Hoodline. 2026. Texas City Lineman Death: Family Sues CenterPoint Energy. <https://hoodline.com/2026/08/texas-city-lineman-28-fatally-shocked-on-live-wire-family-sues-centerpoint/>

Ofgem. 2024. Changing the definition of Energy Systems Data in DBP. <https://www.ofgem.gov.uk/sites/default/files/2024-04/Consultation_on_changing_the_definition_of_Energy_Systems_Data_in_Data_Best_Practice.pdf>

Federal Register. 2024. Federal Register :: Standards for Business Practices and Communication Protocols for Public Utilities. <https://www.federalregister.gov/documents/2024/05/06/2024-09438/standards-for-business-practices-and-communication-protocols-for-public-utilities>

Utility Dive. 2025. The hidden cost of ambiguous energy software terminology Utility Dive. <https://www.utilitydive.com/news/when-everyone-speaks-energy-but-no-one-understands-the-hidden-cost-of-ambi/760063/>

---

### About CodeNinja

CodeNinja is a Middle Eastern-American artificial intelligence lab focused on building self-improving systems. We are reinventing knowledge work to close the loop between vertical AI use cases and the generalized intelligence that fuels it, accelerating the path toward organizational superintelligence.


---

# Port Twin: One Governed Digital Twin for Every Asset, Feed and Dollar

Canonical: https://codeatoms.ai/port-digital-twin-us/
DOI: https://doi.org/10.5281/zenodo.23126431
PDF: https://codeatoms.ai/port-digital-twin-us/paper/port-twin-governed-digital-twin-landlord-port-authority-us.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

VERTICAL-DRIVEN ARCHITECTURES · MARITIME & PORTS · DESIGNED WITH PRAXIS · OCTOBER 2026

# Port Twin: One Governed Digital Twin for Every Asset, Feed and Dollar

A Port-owned system of context that binds eight operational systems, five live sensor feeds and one finance backbone into a single authoritative digital twin, self-hosted inside the Continental United States boundary the port's own requirements set.

CodeNinja Engineering Team

For the port's information technology director, the digital twin program lead and the GIS, integration and data engineers who would build and run it.

---

Vertical-Driven Architectures is a CodeNinja series of system designs. Every design in the series is driven by a real-world problem and scenario in a single industry, and every one is designed on Praxis, CodeNinja's platform for designing physical AI systems. Operations are described by class, never by name.

At a glance

## A governed digital twin for a landlord port authority in the United States

**What this is.** An open reference architecture for system design in physical AI: one authoritative digital twin that binds a port's operational systems, live sensor feeds and finance backbone into a thirteen-object ontology, self-hosted on the port's own virtual machines inside the continental United States. It is written for port information technology leaders and for the GIS, integration and data engineers who would build it. The operator is described by class, never by name.

**The answer in numbers.**

| Part | The design |
| --- | --- |
| Sources joined | 8 operational systems, 5 live sensor feeds and 1 finance backbone, including the port community system, the GIS estate, AIS vessel tracking, the gate system and environmental sensors |
| Object model | 13 typed objects and 13 links, with the berth as the focal object, published as JSON for reuse |
| Models | One self-hosted open model, BGE-M3, for document retrieval; no generative model and no token stream |
| Compute | No equipment bought: about 1.1 GB of fp16 weights on the port's existing enterprise virtual machines |
| Boundary | Everything runs inside the continental United States on infrastructure the port already operates; no hosted document AI service in the path |
| Three-year cost | No hardware line to price: the design adds software and integration work to servers the port already runs |
| Human control | The twin shows; pilots, berth planners, engineers and finance staff decide in their own systems, and nothing writes back into a system of record |

**Reuse it.** The object model, the model register and the figures are free to reuse under CC BY 4.0. Cite as DOI <https://doi.org/10.5281/zenodo.23126431.>

**Made with.** Reasoned on [Praxis](<https://codeatoms.ai/praxis/>), CodeNinja's platform for designing physical AI systems. The object model imports into [Hyper Ontology](<https://codeatoms.ai/hyper-ontology/>), which turns it into a living system. Both are in beta; access by request.

ABSTRACT

## A Port Should See Its Land, Water and Money in One Picture

The port needs one authoritative answer to a question it can only answer in fragments today: what is happening on its land and water right now, how deep the channel and berths really are, where every lease and expense lands, and which inspection, drawing or project belongs to which asset. The operation's own description of its problem is the honest one: critical information is spread across disconnected systems, maps, spreadsheets, databases and paper records, so every dashboard is a slice and every executive view is a reconciliation exercise performed by hand. No existing system holds the join, because each one was built to run a function, not to hold the port's shared picture.

The design is a system of context: one governed, Port-owned ontology of thirteen objects projected over the Port Community System, the Esri-based GIS environment, finance and real estate systems, an AIS feed, terminal and gate systems, environmental sensor telemetry, pilot navigation software and the document store, joined through three adapter families and one event backbone, and published back as ArcGIS services so all ten required capabilities arrive as ten services and seven surfaces the Port operates independently. Every component is self-hosted inside the Continental United States boundary the port's requirements themselves set, and the only model in the register is one open-weight embedding model that runs on existing enterprise virtualization, so there is no GPU cluster to buy and no data residency question to argue.

The paper follows the build in order: the industry problem and the join failure across the port's systems; the four constraints, the layered stack, the thirteen-object model, the adapter tier and event backbone, inference placement, and the single model and its license; then the four-phase rollout with its gates, requirement coverage and failure modes, and the ownership position that transfers everything to the Port; the conclusion, and finally the chapter on how Praxis contextualized and reasoned this design.

---

![Figure 1. Port Twin on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.](figures/figure_01.png)

Figure 1. Port Twin on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.

## Contents

Each chapter is tagged for the reader it serves most directly: Executive, Team Lead, FDE, Reference.

|  |  |  |
| --- | --- | --- |
|  | Abstract · A Port Should See Its Land, Water and Money in One Picture | Executive |
| PART I · THE PROBLEM | | |
| 1 | [A Port Cannot See Itself in One Place](#ch1) | Executive |
| 2 | [Every Port System Sees One Slice of the Waterfront](#ch2) | ExecutiveTeam Lead |
| PART II · THE DESIGN | | |
| 3 | [Four Constraints Shape a Landlord Port's Twin](#ch3) | Team Lead |
| 4 | [One system of context Sits Beside the Systems of Record](#ch4) | Team LeadFDE |
| 5 | [Thirteen Objects Turn Port Data Into One Picture](#ch5) | FDE |
| 6 | [Every Feed Enters Through an Adapter, Never Directly](#ch6) | FDE |
| 7 | [Retrieval Runs In-Country and Nothing Runs at the Edge](#ch7) | FDE |
| 8 | [One Open-Weight Model Is All the Twin Needs](#ch8) | FDEExecutive |
| PART III · THE ROLLOUT | | |
| 9 | [Four Phases Earn Each Capability From the Last](#ch9) | Team LeadExecutive |
| 10 | [The Port Owns the Twin After Closeout](#ch10) | Executive |
| PART IV · HOW IT WAS DESIGNED | | |
|  | Conclusion · A Twin Is a Projection Over the Record, Never a Copy of It | Executive |
| 11 | [How Praxis Contextualized and Reasoned This Design](#ch11) | Team LeadFDE |
|  | [Sources](#sources) | Reference |

PART I · CHAPTER 1

## A Port Cannot See Itself in One Place

Higher cargo volumes, expanding infrastructure and siloed records mean the port's safety, revenue and planning decisions are made against an incomplete picture.

The abstract holds the design in one view: eight source systems, three adapter families, thirteen objects, ten services and seven surfaces, all running inside the Port's own boundary. This chapter establishes why the Port asked for that shape, what the disconnected state it replaces is documented to cost, and who works inside the scenario the design must serve.

### 1.1  The Question the Port Needs Answered

The question the Port needs answered is deceptively simple: where is every asset, movement, depth, lease and capital project on this waterfront right now, and do those records agree with one another? The requirements answer that question with a digital twin, defined there as a dynamic, data-driven virtual representation of the Port's physical assets, processes and systems, spanning land and water: facilities, utilities, substructures, bathymetry and environmental zones. The answer requires data the Port already holds but holds apart: underwater depth surveys and their vertical datums; subsurface utility layers from the Port and its partners; up to five real-time environmental sensor feeds covering air quality, water quality, weather and tide; vessel, truck and cargo movement records from the Port Community System and an authorized AIS feed; lease, revenue and expense lines tied to parcels and facilities; capital project footprints; field inspection records; and the engineering drawings and maintenance documentation that map features must link to.

The regulatory ground is layered. The Port's own information technology division sets the binding security regime inside the requirements: alignment with ISO 27001 and 27002, identity assurance at NIST 800 to 63 IAL2/AAL2/FAL2, data resident inside the Continental United States only, DMZ, industrial control and administrative network segmentation, encryption in transit and at rest, and a 99.99 percent availability target. Around that internal regime sits federal maritime guidance: the Coast Guard's Maritime Cybersecurity Assessment and Annex Guide gives port and facility operators a structured way to assess their own cyber posture (USCG 2023), the International Maritime Organization's guidelines place cyber risk management alongside safety management for port communities (IMO 2026), and European guidance treats ports as critical infrastructure requiring a common level of cyber resilience, a framing that increasingly shapes practice everywhere (Europa n.d.).

### 1.2  The Documented Cost of Running a Port on Silos

The requirements describe the cost qualitatively: critical information spread across disconnected systems, maps, spreadsheets, databases and paper records, producing data silos and blind spots in decision-making. Public sources document how expensive those blind spots become when they intersect with cyber risk. In November 2023 a cyber attack on a major container terminal operator in Australia stole employee data and halted port operations, with warnings of freight delays stretching into the peak season (ABC 2023). A 2025 report from Booz Allen and the McCrary Institute warns of cyber sabotage risk at United States ports specifically, citing systemic weaknesses in operational technology and urging a zero trust approach to defense (Industrialcyber 2025). The exposure is growing fastest at the connected edge: attacks on satellite-linked edge devices accounted for 22 percent of maritime cyber incidents in 2025, up from earlier years (DIG 2025). A twin that consolidates the operational picture behind one governed, segmented, Port-owned architecture is therefore also a security decision: it gives the Port one place to see, segment and defend.

### 1.3  The Operation as a Scenario

The scenario is a landlord port authority in the United States. It owns the piers, berths, navigation channel, subsurface utilities and real estate portfolio, while terminal operators run their own operating systems, gate systems and equipment on Port land. The physical environments the twin must represent are the berth faces and quay walls, the navigation channel with its design and dredge target depths, the buried utility corridors beneath the terminal aprons, the landside gates and roadways, the survey craft working the channel, and the operations and administrative centers where staff consume the picture.

The people in the loop work by role rather than by title: harbor pilots using portable piloting units, navigation and dredging planners, environmental program staff tuning sensor alerts, field inspectors submitting mobile forms, finance and real estate analysts joining leases to parcels, capital project managers mapping footprints, and the information technology and security staff who own the boundary the design must respect. The scenario counts are fixed by the requirements themselves: eight named source systems, three adapter families, thirteen objects, ten services and seven surfaces, organized as sixteen requirements across four phases, engaging staff in several distinct roles across a single port footprint.

PART I · CHAPTER 2

## Every Port System Sees One Slice of the Waterfront

The community system knows movements, the GIS knows geometry, finance knows leases, and no system holds the join between them that every capability in the requirements depends on.

Chapter 1 established that the data exists but lives apart. This chapter walks each system the Port already runs, states the slice of the waterfront it sees, and shows why the join between the slices is the thing every capability in the requirements quietly depends on.

### 2.1  What Each System Sees Alone

The Port Community System is the operational heartbeat: it holds vessel calls, truck appointments, gate in and out times, terminal assignments and cargo movement messages. What it misses is everything spatial and financial: it knows a vessel is alongside a berth but not the surveyed depth under that berth, the lease revenue attached to the parcel behind it, or the drawing that shows the quay wall's as-built condition. The AIS vessel position feed sharpens the waterside slice with real-time positions and occupancy, but a position is not a context: it carries no cargo, no gate appointment and no channel depth. The terminal and gate systems extend the landside slice with operator-side movement detail, yet they belong to tenants and see nothing of the channel, the environment or the ledger.

The environmental sensor telemetry sees the water and air as time series: tide, weather, water and air quality at a reporting cadence. It sees no assets and no movements, so it cannot say which berth a rising tide threatens or which parcel an air quality reading sits over. The Esri-based GIS environment is the mirror image: it holds the geometry, parcels, utility layers and basemap, the strongest spatial slice in the estate, but it is largely static where operations are live, blind to movements and telemetry between updates, and silent on money. The finance and real estate systems see the ledger: lease references, revenue lines and expense lines per facility. They see no geography, so parcel-level profit and loss cannot be drawn on a map from them alone. The Trelleborg navigation software on the pilots' portable piloting units sees the channel from the pilot's seat, and the requirements ask the bathymetry capability to explore feeding it current depth data; today it sees none of the port-wide picture. The document and media store holds the engineering drawings, inspection records and maintenance documentation, but its contents are not linked to the map features they describe, so the record of a quay wall cannot be found from the quay wall.

### 2.2  The Join None of Them Hold

Figure 2 sets these eight slices side by side, and the join they all miss is the same one: no single place connects a vessel movement to its berth, that berth to its alongside depth and draft limit, that berth to the parcel and lease behind it, that parcel to its utilities, drawings and inspection history, all under one timestamp. Every capability in the requirements is an instance of that join: berth occupancy over depth, subsurface layers over field gaps, sensor thresholds over assets, profit and loss over footprints, project footprints over conflicting utilities. The cost in practice is the manual reconciliation the requirements name explicitly: duplicated records, rework, longer review cycles and decisions taken against a picture no one can see whole.

![Figure 2. Eight systems, each seeing one part of the answer. the question needs all of them in one place at once.](figures/figure_02.png)

Figure 2. Eight systems, each seeing one part of the answer. the question needs all of them in one place at once.

PART II · CHAPTER 3

## Four Constraints Shape a Landlord Port's Twin

The port owns its picture but not its tenants' operating systems, so the design sits beside the systems of record, stays inside the port's boundary, publishes back as Esri services and leaves the Port independent after closeout.

Chapter 2 showed that the missing thing is the join, not the data. This chapter fixes the four constraints that make building that join hard in a landlord port specifically, then records what the design scoped in, what it deliberately chose against, and what it leaves out entirely.

### 3.1  Sit Beside the Systems of Record, Never in Front of Them

The Port is a landlord authority: it does not own the terminal operating systems, equipment control systems or gate systems its tenants run. The first constraint is therefore that the twin is a read-only projection over the systems of record, georeferencing and publishing what they already hold rather than becoming a new source of truth. This is hard in this industry because tenant data moves on an approval clock the Port does not control, and because any design that wrote back into a tenant's system would collapse the authority-operator boundary the requirements preserve. The subsurface consolidation of up to twenty-five utility layers from Port and partner sources carries the same constraint: each layer's owner, currency and quality sit outside the Port's control, so the design records them rather than assumes them.

### 3.2  Stay Inside the Port's Boundary

The requirements set the residency condition themselves: Port data stays inside the Continental United States, segmented across DMZ, industrial control and administrative zones, encrypted, and available at 99.99 percent. The constraint is hard because a port is an attack surface: United States port cyber risk is documented as systemic in operational technology (Industrialcyber 2025), edge-connected equipment is the fastest-growing incident class (DIG 2025), and one siloed operator's halted waterside operations in 2023 showed what a single intrusion costs (ABC 2023). The design answers by self-hosting everything, including the one model it uses, so no document, position or lease line crosses the boundary.

### 3.3  Publish Back as Esri Services

Every capability must be fully compatible with the Port's current Esri environment and is consumed as ArcGIS services and layers. The constraint is hard because it rules out any architecture that would replace the GIS estate: the design must earn its place inside it. That is why ingestion lands in an open backbone before publication, why bathymetry lives in versioned Esri-native surface datasets with scripted updates, and why the exact ArcGIS version and license inventory is verified before any surface is published.

### 3.4  Leave the Port Independent After Closeout

The Port must operate the twin itself after a bounded managed support period ends and full intellectual property transfers. The constraint is hard because the industry's default is rental: per-call interfaces and hosted intelligence that keep charging after the contract ends. Every choice in this design is tested against one question: does the Port own it at closeout?

### 3.5  Scoping Decisions

Three scoping decisions carry most of the weight, and Table 1 records what each buys and what each costs.

Table 1 · Scoping Decisions

| Decision | What it buys | What it costs |
| --- | --- | --- |
| Read-only projection over the systems of record | No tenant system is touched and no source of truth is duplicated | The twin's freshness is bound to each source's own update cadence |
| Security Operations as requirements, workshops and conceptual dashboard design only | Alignment with the Port's own security governance without procuring devices | No cameras, sensors or servers are bought anywhere in this scope |
| The agent work surface offered, not committed | A Port-built agent surface only if the Port confirms it wants one | No agentic workflows exist unless the Port asks for them |

### 3.6  What the Design Chose Against

Table 2 records the alternatives the design rejected and why, ending with what is out of scope altogether.

Table 2 · What the Design Chose Against

| Where | What was picked | Instead of, and why |
| --- | --- | --- |
| Ingestion | Apache Kafka 4.3.x in KRaft mode as the open backbone feeding ArcGIS services | Esri GeoEvent Server as the sole path: the Port would rent the backbone it could own outright, though GeoEvent remains available where a feed is Esri-native |
| Bathymetry | Versioned mosaic and surface datasets in the Port's own ArcGIS estate with scripted, documented updates | A third-party bathymetry suite: it would break the required Esri-native repeatability and the Port's independent operation |
| Document retrieval | A self-hosted BGE-M3 embedding model over the Port's drawings and records | A hosted document-AI API: it would move security-sensitive documents outside the Continental United States boundary and keep a per-call fee running after closeout |
| Forecasting | Calibrated deterministic Esri workflows and staff-tuned threshold alerting | Machine-learned arrival or congestion prediction: no acceptance criterion in the requirements can test it |
| Out of scope | Terminal operating system and equipment control integration, new hardware procurement, historic data migration and anything inside the navigation or crane control loop | Any path that would put the twin in front of a tenant's operating loop, buy equipment the requirements never ask for, or claim scope the acceptance criteria cannot reach |

PART II · CHAPTER 4

## One system of context Sits Beside the Systems of Record

The architectural pattern is sources below, one object model in the middle, capabilities published as services and surfaces above, with nothing ever replacing the system that owns the truth.

Chapter 3 fixed the scope: sit beside the systems of record rather than in front of them, publish into the Esri environment the Port already operates, and buy no hardware. This chapter gives those constraints their architecture, one stack that runs from the sources of truth up to the surfaces where Port staff decide.

### 4.1  The Architectural Pattern and Why It Fits

The pattern is three bands. Below sit the systems of record: the Port Community System owns movement truth, ArcGIS Enterprise owns spatial truth, the finance systems own lease and revenue truth, and each keeps doing so unchanged. In the middle sits one object model: thirteen governed object types that project those records into a single joinable picture, every object anchored in the system that owns it. Above, capabilities are published as ArcGIS services and consumed by dashboards, maps and views in the Port's own environment. Applications and agents, where the Port later wants them, read from the object model and never from a source directly.

This shape fits a landlord port authority for one reason: the Port does not own the terminal operating systems, gate systems or crane controllers, so a twin that replaced any system of record would be unbuildable. A projection is buildable. Each correction is made where the truth lives, and the object model follows on the next refresh, so there is exactly one write path to truth and many read paths from it. Figure 3 shows the layered stack with its counts: eight sources, three adapter families, one object model of thirteen objects, ten services, seven surfaces and one model. Nothing runs at an edge; every workload runs on Port-managed servers under the Port's own change management, inside the boundary the Port's own security requirements set.

![Figure 3. The layered stack: 8 sources, 3 adapter families, 13 objects, 10 services and 7 surfaces.](figures/figure_03.png)

Figure 3. The layered stack: 8 sources, 3 adapter families, 13 objects, 10 services and 7 surfaces.

### 4.2  The Stack Stage by Stage

Table 3 walks the stack from sources to surfaces, naming the components in each stage. Two stages are deliberately thin. Sensing is thin because the engagement buys no instruments: physical conditions arrive from up to five existing environmental sensor feeds and a sourced photorealistic 3D mesh. Inference is thin because only one model role exists: semantic retrieval over feature-linked engineering drawings, inspection records and maintenance documentation, served by an open-weight embedding model on the Port's existing virtualization; bathymetry and traffic analytics remain deterministic Esri workflows rather than learned models. Around the stages, Chrony keeps feed and GIS clocks aligned, Prometheus, Grafana and Loki observe the running system, Keycloak federates the Port's identity provider for access control, and a Harbor registry holds artifacts and model images for audit and replay.

Table 3 · The Stack, Stage by Stage

| Stage | What it is responsible for | How |
| --- | --- | --- |
| Sources | Holding the truth for movement, spatial, financial and document data | Eight named systems: Port Community System, AIS vessel position feed, terminal and gate systems, environmental sensor telemetry, the Esri-based GIS environment, Finance and Real Estate financial systems, Trelleborg navigation software on the pilots' portable piloting units, and the document and media store |
| Sensing | Bringing physical conditions into the picture without new instruments | Up to five existing environmental sensor feeds with threshold alerting and historical export, plus a sourced photorealistic 3D mesh; no camera, sensor or server is purchased |
| Adapters | Landing every feed in one auditable, replayable place before publication | Three adapter families: integration adapters for the PCS, AIS, terminal, finance and Trelleborg feeds; telemetry adapters for the sensor feeds; and the file and doc adapter for drawings and records |
| Object model | Making the Port one joinable picture | The Port ontology layer: thirteen objects anchored in their systems of record and joined by typed links, with InfluxDB 3 Core holding telemetry history and Chrony disciplining feed clocks |
| Inference | The single model role: retrieval over feature-linked documents | BGE-M3 embeddings, 568M parameters under MIT, served by vLLM on the Port's existing enterprise virtualization with no GPU server |
| Services | Publishing each capability as ArcGIS services and layers | Ten services from Digital Twin Platform and 3D Basemap through Bathymetry Analysis, Subsurface Mapping, Environmental Monitoring, Operational Movement, Capital Projects, Financial Analytics, Security Operations and Managed Services |
| Surfaces | Putting each capability in front of the staff who decide | Seven surfaces: the consolidated subsurface utility map, feature-to-document linking, the operational movement dashboard, capital project footprint mapping, the security operations dashboard use cases, and the Port staff views |

PART II · CHAPTER 5

## Thirteen Objects Turn Port Data Into One Picture

Berths, channels, surveys, utilities, sensor feeds, movements, parcels, projects, inspections, documents and messages, each anchored in the system that owns it and joined by typed links no document store can traverse.

Chapter 4 placed one object model in the middle of the stack. This chapter opens that model and shows what the thirteen objects hold, how they join, where people act on them, and how the whole picture is hosted inside the Port's own boundary.

### 5.1  Thirteen Objects and the Links Between Them

The model holds five assets, four records, three events and one document. The assets are berth, navigation channel, subsurface utility layer, environmental sensor feed and parcel or facility, each representing something physical the Port owns, operates or leases. The records are bathymetric survey surface, utility gap record, capital project and inspection record, each a dated statement about an asset with its own lifecycle. The events are vessel movement, truck movement and PCS message, each a timestamped fact that arrives continuously and is never edited. The document is the engineering document: drawing number, revision, media type and the map features it belongs to. Figure 4 draws every object and its typed links, with the berth as the focal object.

The value sits in the traversal. A query that starts at a berth can reach the vessel movements that touch it, the navigation channel it adjoins, the current bathymetric surface on that channel, and therefore the present under-keel condition a pilot or berth planner needs. A query that starts at a subsurface utility layer reaches the utility gaps raised against it and the inspection records that close them, so a field crew sees one worklist. A query that starts at a parcel reaches its lease reference and revenue and expense lines, the capital projects whose footprint overlaps it, and the inspections against its facilities. A document store answers none of these joins: it can retrieve a drawing by number, but it cannot traverse berth to channel to survey to depth zone, or parcel to lease to project footprint, because those relations are not documents and live in no single source.

![Figure 4. The thirteen objects of the model and the typed links that let a query reach across them.](figures/figure_04.png)

Figure 4. The thirteen objects of the model and the typed links that let a query reach across them.

### 5.2  Where the Human Loop Lives and How It Is Hosted

The human loop lives in the status vocabularies. A utility gap moves from Open to In field verification to Closed by a Port engineer; an inspection record moves from Submitted to Reviewed to Closed by a named reviewer; a bathymetric surface becomes Current, Superseded or Archived by the hydrography owner; a capital project is Planned, Active or Complete on a project manager's word. The system proposes and timestamps; a named person decides, and the decision record carries their identity.

The hosting posture follows the Port's own security requirements: everything is self-hosted on Port-managed infrastructure inside the Continental United States boundary the requirements set, with the DMZ and Administrative segmentation the Port's network design already provides. Identity runs through Keycloak federating the Port's identity provider, so every surface access is a Port identity with role-based entitlements. No object carries an external link out of the boundary. The only write path into the ontology is the adapter tier feeding records plus the human status transitions above; no surface writes back to a system of record, so the PCS, ArcGIS Enterprise and the finance systems remain the sole owners of their truths.

### 5.3  One Object in Its Recorded Form

The berth object is the anchor for every movement, depth and occupancy question the twin answers, and it is recorded exactly as shown here.

```
{
  "id": "berth",
  "label": "Berth",
  "kind": "asset",
  "anchored_in": "Port Community System",
  "properties": [
    "Berth ID",
    "Alongside depth",
    "Berth window",
    "Occupancy state",
    "Vessel draft limit"
  ],
  "status_vocabulary": [
    "Occupied",
    "Reserved",
    "Available"
  ],
  "links": [
    {
      "to": "navigation-channel",
      "label": "adjoins"
    },
    {
      "to": "vessel-movement",
      "label": "receives"
    },
    {
      "to": "parcel-facility",
      "label": "belongs to"
    }
  ]
}
```

PART II · CHAPTER 6

## Every Feed Enters Through an Adapter, Never Directly

Three adapter families bring eight named sources into one Kafka backbone, so every record is timestamped, ordered and replayable before it is ever published as an ArcGIS service.

Chapter 5 defined the objects and their links. This chapter describes how data reaches them: eight named sources, each entering through one of three adapter families onto a single backbone, timestamped and ordered before anything is published.

### 6.1  Eight Sources, Their Provenance and Their Paths

Figure 5 maps every source, its provenance class and its adapter path. Seven sources are operator-authorized: data the Port itself holds and authorizes for this build. The Port Community System is the primary source of vessel, truck and cargo movement; the AIS vessel position feed supplies real-time positions and berth occupancy; terminal and gate systems extend movement data beyond the PCS; environmental sensor telemetry carries up to five real-time feeds for air quality, water quality, weather and tide; the Esri-based GIS environment is both a source of current spatial data and the destination every capability publishes into; the Finance and Real Estate financial systems supply lease, revenue and expense data, with the underlying system of record confirmed with the Port at kickoff; and the Trelleborg navigation software on the pilots' portable piloting units is the exploratory destination for bathymetric depth data. One source is domain-typical: the document and media store that holds engineering drawings, inspection records and maintenance documentation, named by class because the Port's requirement does not name the store, and the file and doc adapter is built against whatever it proves to be.

![Figure 5. The 8 named systems, the adapter path each one takes, and the object model they all map into.](figures/figure_05.png)

Figure 5. The 8 named systems, the adapter path each one takes, and the object model they all map into.

### 6.2  What the Adapter Tier Guarantees

Every adapter makes the same four guarantees. First, provenance: each record carries its source system, its original source timestamp and an ingestion timestamp, so a consumer can always tell when something happened and when the twin learned it. Second, ordering: records within a feed are ordered so a berth's occupancy state, a vessel's position sequence and a survey's version chain never arrive out of sequence. Third, idempotence: each record carries a deduplication key, so a replay or a duplicate push changes nothing. Fourth, staleness: a feed that stops reporting is flagged, and no surface presents data it cannot date. This last discipline matters because a port twin that consumes position and movement records must verify them and degrade gracefully when record and reality disagree. No surface connects to any source directly; the adapter tier and the backbone are the only entrance.

### 6.3  The Event Backbone

The backbone is Apache Kafka 4.3 in KRaft mode, with three dedicated controllers on a dynamic quorum. Records are partitioned by key, typically the asset or vessel identifier, so all events for one berth or one vessel keep their order on one partition. Delivery is at least once with idempotent consumers, which pairs with the adapters' deduplication keys to give effectively once-per-record behavior downstream. Buffering absorbs outages: if an ArcGIS publisher or a dashboard consumer stops, the sensor, AIS and PCS feeds continue to accumulate on the backbone and are consumed when it returns, so no gap is silently lost. Replication keeps every partition on more than one broker inside the Port's administrative segment. The guidance for ports treats them as critical infrastructure needing structured cyber risk management (Europa n.d.), and connected equipment carries a growing share of maritime cyber incidents (DIG 2025); an auditable, replayable, Port-owned backbone inside the Port's own boundary, rather than per-feed point integrations, is the design's answer to both.

PART II · CHAPTER 7

## Retrieval Runs In-Country and Nothing Runs at the Edge

The design places its single model on existing Port enterprise virtualization inside the Continental United States, and deliberately buys no edge compute, no cameras and no GPU cluster.

Chapter 6 showed how every source enters through an adapter and lands on one replayable backbone, ordered, buffered and replicated before anything reads it. This chapter places the computation: where the design runs its inference, why it deliberately runs nothing at the physical edge, and what the network boundary lets through in each direction. The short answer is that the design has exactly one model, it runs on machines the Port already owns, and the most consequential placement decisions in the system are refusals.

### 7.1  One Inference Tier, and It Sits on Port Virtualization

The design has a single inference tier, and Figure 6 shows it: one embedding model, served on the Port's existing enterprise virtualization inside the Continental United States boundary the requirements themselves set. Everything else in the system is deterministic software, Esri-native workflows and threshold logic that need no model at all. This shape is a deliberate counter-position to the one currently being sold across the maritime and ports sector, where quay-wall cameras, gate-side object trackers and language models at the waterside are offered as the default architecture. The design declines that default for three reasons. First, the requirements never ask for edge inference. Vessel and truck movement arrives as data from the Port Community System, the AIS feed and gate telematics, so there is no video stream to run detection on and no trajectory to forecast: the twin consumes records, not pixels. Second, the economic argument holds at this scale. A 568M-parameter embedding model does not justify a GPU server, let alone an edge compute estate. Third, the security argument cuts the same way: attacks on satellite-linked edge devices accounted for 22 percent of maritime cyber incidents in 2025, a share that has grown from earlier years, which means connected field equipment is now a leading attack surface in the sector (DIG 2025). A report on United States port cybersecurity reaches the same conclusion from the defensive side, citing systemic operational technology weaknesses and urging a zero trust posture (Industrialcyber 2025). Every edge box the design refuses to buy is one more device the Port never has to patch, monitor or defend. The memory arithmetic is short because the model is small and the serving pattern is simple. The registered model is BGE-M3 at 568M parameters. As published at float32 its weights occupy about 2.27 GB; at fp16, the precision the design runs, about 1.1 GB; at 8-bit quantization, about 0.6 GB. A fp16 weight set of roughly 1.1 GB fits comfortably in the memory of a standard enterprise virtual machine, which is exactly why no GPU server is justified or purchased. The KV cache term that dominates generative model sizing is absent here by construction: an embedding model encodes text into fixed vectors in a single forward pass and generates no token stream, so there is no growing cache to budget against usable memory. The memory question therefore reduces to weights plus short-lived activation, and activation scales with batch size, which is bounded by the scheduled corpus indexing jobs rather than by interactive load.

![Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.](figures/figure_06.png)

Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.

### 7.2  The Latency Budget

The budget has four clocks, and the model tier is the smallest of them. The feed clock is set by each source's own reporting cadence: sensor telemetry and movement records arrive at whatever interval their platforms publish, the backbone absorbs the bursts, and no component waits on a faster promise than the feed itself makes. The publication clock is the refresh of ArcGIS services and layers into the Port's GIS estate; dashboards are exactly as fresh as the last publication, and the automated update workflow in the basemap capability governs that interval. The retrieval clock covers the one place a model sits in an interactive path: a query is embedded in a single forward pass over a 568M-parameter model at fp16, then matched against the index with hybrid dense and sparse search. Bulk embedding of the document corpus runs as scheduled background work; query time embeds one query, not a library. The alerting clock is bound to ingestion, not to inference: threshold evaluation on the five environmental feeds happens as records land, so alert latency is feed cadence plus evaluation, never a model round trip. The structural property that matters is that no interactive path depends on a call to an external model provider. The longest term in the budget is the publication clock, and the model tier adds nothing measurable to dashboard freshness. A latency problem in retrieval degrades document search for one user; it cannot stall the operational picture.

### 7.3  What Crosses the Boundary, and What Happens When It Fails

Nothing crosses outward to a hosted model, a per-call API or any service outside the Port's control. The boundary conditions come from the requirements themselves: data residency inside the Continental United States, segmentation between the demilitarized zone, the operational technology zone and the administrative zone, encryption in transit, and an availability target of 99.99 percent. Movement and telemetry land in the demilitarized zone, are normalized onto the backbone, and the ontology, the services and the model serve from the administrative zone. The design takes this posture seriously because the sector's record demands it: international guidelines place cyber risk management squarely on port operators (IMO 2026), the United States Coast Guard publishes an assessment guide for exactly this exercise (USCG 2023), and a cyber attack on a major port operator in late 2023 halted operations and stole employee data, with freight delays following (ABC 2023). When the link fails, the adapter marks the affected feed degraded, records carry their source timestamps and staleness flags, and the dashboards never present a feed they cannot date. When power fails, the workloads go down with the Port's own infrastructure, because they run on Port-managed servers under Port change management; the design makes no independent power claim, and managed services operate to the agreed service levels once infrastructure recovers. When the update path fails, the system keeps running on its last known-good versions, held in the Harbor registry, and updates resume through the Port's own change process. In all three cases the failure mode is graceful staleness, not silence: the twin shows what it knew and when it knew it.

PART II · CHAPTER 8

## One Open-Weight Model Is All the Twin Needs

A 568M-parameter embedding model under an MIT license, small enough to run on the Port's own virtualization, covers the one model role the requirements state: feature-linked document retrieval.

Chapter 7 placed the design's single model on the Port's own virtualization and argued that nothing belongs at the edge. This chapter names that model, states what its license permits, and records every choice of model, hardware posture, pattern and ground in one register, so the Port can see exactly what it would own at closeout.

![Figure 7. The one model, their placement, and the work each one does.](figures/figure_07.png)

Figure 7. The one model, their placement, and the work each one does.

### 8.1  The Model Stack: One Model, One Runtime, One Registry

Figure 7 shows the model stack, and its brevity is the point. One registered model, BGE-M3; one serving runtime, vLLM 0.29.0, verified current and licensed for this use; one private artifact and model registry, the Harbor registry, holding versioned weights and containers for replay and rollback. There is no fine-tuning pipeline, because no model is trained in this scope: the embedding model runs off the shelf, bathymetry analysis is a deterministic Esri workflow, and movement analytics are configured dashboards and threshold logic, not machine-learned predictions. A stack with one model is not a reduced ambition; it is the honest count of model roles the requirements state.

### 8.2  BGE-M3, 568M Parameters, MIT Licensed

BGE-M3 is a 568M-parameter embedding model with a hybrid dense and sparse architecture, meaning it produces both a learned vector representation and a lexical representation of the same text in one pass. That hybrid is why it was chosen for the one model role the design has: semantic retrieval over the feature-linked engineering drawings, inspection records and maintenance documentation that the map must link to. Port document corpora are hostile to pure vector search, because users search for exact short identifiers such as drawing numbers, part marks and inspection IDs as often as they search for concepts, and a hybrid model keeps both queries answerable through one index. Its placement follows from its size. At fp16 the weights occupy about 1.1 GB, so the model serves on the Port's existing enterprise virtualization at the site tier, inside the Continental United States boundary, with no GPU server justified and no field equipment installed. Its license is MIT with no field of use restriction: the Port may hold, copy, modify and run the weights indefinitely, with no per-call fee and no limit on where or how the model is applied, and ownership of the model and its hardening passes to the Port at closeout. That license terms matter as much as accuracy here. A hosted document-AI API would put engineering and security-sensitive material outside the Port's boundary on every query, and would leave the Port renting, forever, the one capability it most needs to own. The design chose the self-hosted open model hardened on the Port's own drawings and records instead, for the boundary, for the cost structure and for ownership.

### 8.3  The Model and Equipment Register

Table 4 gathers the choices this chapter and Chapter 7 made into one register: the model and its serving runtime, the hardware posture and sizing rule, the sensing decision, the patterns the design stands on, and the ground it runs on. Each row states why it holds.

Table 4 · Model and Equipment Register

| The choice | What was picked | Why here |
| --- | --- | --- |
| The one model role | BGE-M3, 568M parameters, hybrid dense and sparse embeddings, run at fp16 | Covers feature-linked retrieval over drawings, inspection records and maintenance documentation; small enough that no GPU server is justified |
| Serving runtime | vLLM 0.29.0 on the Port's existing enterprise virtualization | Serves the embedding model inside the Continental United States boundary on infrastructure the Port already operates |
| Hardware classes | None purchased; existing enterprise virtual machines only | The requirements buy no equipment; about 1.1 GB of fp16 weights fit standard virtual machine memory |
| Sizing rule | Weights occupy about 2.27 GB at float32, about 1.1 GB at fp16, about 0.6 GB at 8 bit | The fp16 figure is the sizing basis; no KV cache applies because an embedding model generates no token stream |
| Sensing | No new sensing; up to five existing environmental sensor feeds plus movement data from authorized systems | The requirements integrate existing feeds and a sourced photorealistic 3D mesh; no cameras or field devices are purchased |
| Pattern: system of context | One Port-owned ontology projected over the systems of record | Silos are bound in place; the twin sits beside the systems of record, never in front of them |
| Pattern: adapter-mediated ingestion | Three adapter families across eight named sources | Every source enters through an adapter, never directly, so source change never reaches the ontology |
| Pattern: open backbone | Apache Kafka 4.3.x in KRaft mode with three dedicated controllers | The Port owns the ingest backbone outright, and every feed lands in one auditable, replayable place before publication as ArcGIS services |
| The ground | Port enterprise infrastructure inside the Continental United States, segmented into demilitarized, operational technology and administrative zones | Residency and segmentation are the boundary conditions the requirements themselves set, and the design adds no dependency outside them |

PART III · CHAPTER 9

## Four Phases Earn Each Capability From the Last

Phase one stands up the ontology and proves the cross-silo joins before anything scales, and each later phase carries its own item count and exit gate, ending in transition and closeout with full intellectual property transfer.

Chapter 8 fixed the model layer: one open-weight embedding model, one license, no GPU server. What remains is to earn that restraint in sequence. A build of this shape succeeds or fails on the order in which capabilities arrive, because every later capability reads the joins the first phase proves and every dashboard is only as good as the integration plan that names its feeds.

### 9.1  Four Phases, Four Gates, and a Closeout

The rollout runs as four phases and an operations phase, each carrying an explicit item count and an exit gate, and Figure 8 shows them with their requirement coverage. Phase one carries five items across the Digital Twin Platform, 3D Basemap, Bathymetry Analysis and Subsurface Mapping workstreams, and its gate is the Port ontology layer standing up with the cross-silo joins proven on the Port's own data: the photorealistic mesh sourced and staged, the 2D/3D basemap published with automated updates, bathymetry handed over as versioned surfaces with prior versions retained, and subsurface utility layers consolidated with each layer's owner, source and gap class recorded. Phase two carries six items across Capital Projects, Environmental Monitoring, Financial Analytics and Operational Movement (PCS), and its gate is the PCS movement ingestion and integration plan, which names every feed, its update frequency and its integration method before any dashboard is built against it; sensor feeds integrate incrementally up to the five-feed cap with staff-tuned alerting, and vessels and berth occupancy visualize live in 3D only once that plan is signed.

Phase three carries five items across the Digital Twin Platform, Security Operations, Traffic Modeling and Security & Compliance workstreams, and its gate is knowledge transfer for independent Port operation: the Security Operations dashboard use cases designed with Port staff, the calibrated impedance roadway network built, and closure and detour scenario analysis handed over as deterministic Esri workflows. The operations phase carries two items under Managed Services: operating the services to the agreed service levels and responsibility matrix, and executing transition and closeout with full intellectual property transfer to the Port. Requirement coverage closes at sixteen of sixteen requirements covered, none partial and none gapped, and each gate maps its phase's items back to the specific requirement each item satisfies, so coverage is claimed only where a gate has been passed.

![Figure 8. The four phases and their gates, and coverage of the 16 requirements across them.](figures/figure_08.png)

Figure 8. The four phases and their gates, and coverage of the 16 requirements across them.

### 9.2  What the Rollout Measures

Five measurements run across the phases. First, the join proof: whether the ontology resolves one berth, one parcel, one channel across systems that never shared keys before, tested on real Port data in phase one. Second, feed health: every movement and telemetry record carries its source system and source timestamp, and staleness is flagged rather than smoothed, so a dashboard never presents a position it cannot date. Third, alert discipline: staff tune their own thresholds during phase two, and the measure is whether alerts route to a named person who acts, not how many fire. Fourth, financial reconciliation: the profit and loss by facility and parcel integration is accepted only when Finance validates the join against official records. Fifth, independence: the final measure is Port staff running the update workflows, publishing services and tuning alerts without the builder in the room, which is the phase three gate.

### 9.3  Failure Modes and What the Design Does About Them

The known unknowns are carried as named failure modes with designed responses, not as risks left to the phases to discover; Table 5 lists them.

Table 5 · Failure Modes

| What fails | What the design does |
| --- | --- |
| The port community system product, its operator and its available interfaces are unknown, yet four capabilities depend on its feeds | The integration plan is a phase two gate deliverable that names every feed, update frequency and method before dashboards are built against it |
| The financial system of record for lease, revenue and expense data is unnamed, and its extraction granularity is unconfirmed | Confirm with the Port at kickoff; design the join layer so only it changes when the system is named, with Finance validation as the acceptance test |
| The Port's GIS product versions and license levels are not stated, yet every capability must be fully compatible with the current environment | Verify the exact version and license inventory in phase one, before any surface is published |
| Environmental sensor count, types, platform and protocol are unknown, so the five-feed integration cannot be sized today | Deliver the monitoring requirements document from the workshops as the mapping artifact and integrate feeds incrementally to the cap |
| Subsurface consolidation depends on utility layers from Port and partner sources whose access and quality sit outside Port control, and partner approvals move on a slower clock | Run the data inventory and acquisition plan as a phase one work package, and make the validation scenario the proof that field conditions are reflected where data exists |
| The photorealistic 3D mesh is a large sourced dataset with its own procurement lead time and currency risk | Source and stage it in phase one, define its update workflow with the basemap's automated updates, and confirm 3D tool compatibility on the Port's own viewers before acceptance |

### 9.4  Lessons

**Prove the join before the capability.** Phase one exists because a digital twin that cannot resolve one berth across the port community system, the GIS estate and the financial systems will fail quietly in every later capability, and the failure surfaces as disputed numbers rather than as an error. The ontology layer is the cheapest place to learn that, and the gate makes the lesson mandatory.

**Name the feed before the dashboard.** The movement capability is the one most likely to be demoed early and regretted late, because the systems behind it are unnamed at kickoff. Making the integration plan the phase two gate costs schedule certainty on the dashboard and buys certainty on the data, which is the right trade when the dashboards are meant to be authoritative.

**The twin widens the surface it is meant to narrow.** A port's connected systems are an established target: a 2023 attack on a major container terminal operator halted operations and stole employee data (ABC 2023), satellite-linked edge devices accounted for a growing share of maritime cyber incidents in 2025 (DIG 2025), and a 2025 report warns of sabotage risk at United States ports and urges zero trust (Industrialcyber 2025). The design responds by sitting inside the Port's own segmented network, federating identity through the Port's provider, running under Port change management, and transferring the boundary itself at closeout; the Coast Guard's assessment guide and the international guidelines on maritime cyber risk management give the Port its review frame for the twin as connected infrastructure (USCG 2023; IMO 2026).

### 9.5  What Is Still Open

Six questions remain open, and each changes a different part of the design when it settles. Naming the port community system and its interfaces fixes the adapter effort in phase two and may change feed frequency assumptions in the movement dashboards. Naming the financial system of record fixes the extraction granularity and either confirms or reshapes the join layer, nothing else. The GIS version and license inventory decides whether specific extensions are available or must be licensed before surfaces publish. The sensor inventory sizes the telemetry adapter and the alerting configuration. Mesh procurement and currency determine how the basemap update workflow is sequenced. And the Port's confirmation on the offered agent work surface decides whether a fifth adapter family and a work surface join the design; until then, nothing agentic is built, and the eleven other capabilities are unaffected.

PART III · CHAPTER 10

## The Port Owns the Twin After Closeout

The object model, the adapters, the fine-tune-free model weights, the decision record and the boundary itself all transfer to the Port, which operates the system independently after the support period.

Chapter 9 ended with transition and closeout as a gate. This chapter states what that transition means in property terms: which layers of the design become the Port's, and what, if anything, stays with the builder.

### 10.1  Who Owns What the Design Builds

The object model transfers whole: thirteen objects with their typed links, status vocabularies and anchored provenance in the port community system, the GIS estate and the financial systems become Port property at closeout, together with the three adapter families that feed them and the ten services that publish from them. The weights transfer as well: the design registers one model, BGE-M3, a 568-million-parameter embedding model under an MIT license with no field-of-use restriction, used off the shelf with no fine-tune, so the Port holds it outright and no trained artifact beyond it exists to divide. The decision record belongs to the Port by construction: threshold alerting is tuned by the Port's own staff, every alert routes to a named person who decides, and the trail of who decided what on which evidence sits in Port systems, not in the builder's. The boundary transfers as a configuration rather than a dependency: continental United States residency, the demilitarized, industrial control and administrative network segmentation, encryption in transit and at rest, and identity federated through the Port's own provider, all administered by Port staff after knowledge transfer. After the support period the Port operates every surface, adapter and service independently, and no per-call or per-seat payment to the builder remains anywhere in the architecture.

### 10.2  The Offer Behind the Design

The offer behind the design is CodeNinja's. The thirteen-object model is Hyper Ontology; the ranking, reconciliation and recommendations that named Port people decide, from berth occupancy and movement attribution to parcel-level financial analysis, are Decision Systems; the open-weight license, the in-country operation inside the continental United States boundary on the Port's own hardware make the build Sovereign Infrastructure; and Praxis is the platform on which the design was contextualized, reasoned and recorded. CodeNinja's role ends at closeout by design, because the ownership described above is the product: a twin the Port runs, extends and accounts for on its own.

PART IV · CONCLUSION

## A Twin Is a Projection Over the Record, Never a Copy of It

In one view, the design is a governed projection: thirteen objects anchored in the systems that already own the truth, fed by three adapter families through one replayable backbone, published as ten ArcGIS services and seven surfaces, with one open-weight model doing the only inference the requirements ask for, all inside the port's own segmented network and boundary.

Running the same shape elsewhere takes a landlord-style authority that owns its picture but not its tenants' operating systems, a GIS estate worth projecting into rather than replacing, a named system of record for each object, and the discipline to earn each phase from the one before it; given those, the ontology, adapters and surfaces transfer with the objects renamed and the adapters re-aimed.

PART IV · CHAPTER 11

## How Praxis Contextualized and Reasoned This Design

Every choice in this paper traces back to the recorded reading of the port's requirements and the eight reasoning lenses Praxis applied, and this chapter shows the trace.

Chapter 10 closed the ownership question. This final chapter opens the design's own record: how the ask was read, which lenses were applied, and where each choice in the paper traces back to what justified it. Every design in this series is produced on Praxis, the platform that contextualizes the ask, assigns it a family and industry, reads what is in the room and reasons through eight lenses. This chapter is the trace: any choice in the paper can be followed back to the recorded reading that justified it, and Figure 9 shows that path from ask to family to lenses to the equipment classes the design finally carries.

### 11.1  Contextualizing the Ask

The ask is the operator's own solicitation: a request for proposals from the information technology division of a maritime and ports operator in the United States, published with a defined term and a scope of ten capabilities for a port digital twin, running from a photorealistic 3D basemap and bathymetry analysis through subsurface utility mapping, environmental monitoring, operational movement, capital projects, financial analytics and a security operations design study. Praxis assigned it to the system-of-context family in the maritime and ports industry, with the United States fixed by the operator's own requirement rather than by inference. What was in the room is the solicitation itself, read in full: its project description, scope of work, technical and security requirements, and operations and support sections, together with the records it references; the list of records read is held and available on request. The binding constraints came from the operator's own security section read directly, not from an external corpus: alignment with recognized information-security management standards, strong identity assurance levels, continental United States data residency, network segmentation across three zones, encryption, and a high availability target.

![Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.](figures/figure_09.png)

Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.

### 11.2  The Eight Lenses

Table 6 records each lens: what it could see, how many of its findings were cited into the design, and what it contributed. Two lenses returned nothing applicable and are recorded as gaps rather than omitted.

Table 6 · The Lenses and What They Contributed

| Lens | Could see | Cited | What it contributed |
| --- | --- | --- | --- |
| First principles | held in the brief | 1 | The twin sits beside the systems of record, never in front of them: a landlord authority does not own terminal operating or gate systems, so the design is a projection over the port community system, the GIS estate and partner data, and its value is measured on the Port's own clock of safe under-keel clearance, dredging decisions and incident response |
| Case studies | 12 | 1 | The Rotterdam port call data exchange case carried a hard warning into the movement capability: coordination discipline earns the first number, and value measured on a selected tail overstates the whole, so the dashboards carry data-dictionary and feed-health discipline instead of optimiztic value claims |
| Tooling and recency | 326 | 3 | Each named product was checked for currency and license before it was named: the streaming backbone, the telemetry store, the serving runtime and the embedding model; one model role exists in this design and one is registered |
| Hardware and equipment | 38 | 0 | A gap: the engagement buys no equipment, so every hardware layer is marked not needed with the requirement's own words as the reason |
| Rules and regulations | 341 | 0 | A gap: the corpus holds no United States federal, state or municipal data-governance entry bearing on this build; the binding rules came from the operator's own security section, read directly from the document |
| Approach | 42 | 2 | Ontology-first phasing governed the plan: phase one states the object model and proves the cross-silo joins before any capability scales, and the landlord-versus-operator approval split shaped the subsurface plan |
| History | 63 | 1 | The container terminal cutover case taught the movement lesson this design absorbs: verify position records against reality, flag staleness, and never present a feed the dashboard cannot date |
| Domain fusion | held in the brief | 2 | System of context and the maritime brief are one design here: the live port picture is the ontology as a projection over the estate, binding silos in place rather than migrating them |

### 11.3  Patterns Adopted and Set Aside

Three patterns were adopted and three were set aside, each with a recorded reason. Adopted: adapter-mediated ingestion into one open backbone the Port owns outright, with the GIS-native event path kept available where a feed is Esri-native; versioned Esri-native surfaces with scripted update over a third-party bathymetry suite, because a separate suite would break both repeatability and independent Port operation; and self-hosted open embedding retrieval over a hosted document application programming interface, because feature-linked documents include engineering and security-sensitive material that must stay inside the boundary and a per-call rental is exactly the part closeout should end. Set aside: agentic workflows, offered to the Port and built only on confirmation, because the solicitation never asks for them; machine-learned arrival and congestion prediction, because the acceptance criteria test configured dashboards, staff-tuned alerting and calibrated scenario analysis, not learned forecasts; and video ingest with edge tracking, because no cameras are purchased and every vessel and truck position arrives as data.

### 11.4  Where the Reasoning Lands

The reasoning lands as a map of what is deliberately not bought. No edge compute, because nothing runs at a physical edge; no graphics processing server, because the single registered model runs on the Port's existing enterprise virtualization; no satellite-disciplined time hardware, because GIS timelines and feed ordering need network time discipline, not grandmaster clocks; no one-way transfer hardware, because the boundary condition is residency and segmentation, both satisfied by the Port's own network design. The equipment classes the design does carry are enterprise ones: streaming controllers, telemetry storage, the ontology store, observability, identity federation and an artifact registry. The chapter closes on the standing rule of the series: everything shown here was recorded reading, every count and license was checked against the record, and nothing in this paper is inferred.

Appendix A

## What It Costs

The design buys no hardware. The requirement asks for no cameras, sensors or servers, and the only model in the register, the BGE-M3 embedding model, occupies about 1.1 GB of weights at fp16, which fits a standard enterprise virtual machine the port already operates. There is therefore no owned-versus-rented comparison to print: the cost of this design is integration and software work on infrastructure the port already pays for, and a closed document AI service was set aside on boundary grounds, not price.

### A.1 What Would Change the Answer

| Line | When it appears | How to price it |
| --- | --- | --- |
| Virtual machine capacity | If the twin's event backbone and GIS services outgrow the existing cluster | The port's own virtualisation cost per core and per gigabyte, which no public list price captures |
| Document retrieval at scale | If the drawing and inspection corpus grows into the millions of pages | Embedding throughput on CPU is the limit; one mid-range GPU card (48 GB class, about 85,000 dollars for a server of eight, Newegg 2026) removes it |
| A generative work surface | If the port later asks questions in natural language over the twin | A frontier open-weight model on one node of eight 141 GB HBM-class GPUs, 320,000 to 420,000 dollars (Mercatus 2026), priced in the series' other papers |

### A.2 Sources for This Appendix

- Mercatus. 2026. H200 server price. <https://mercatus-ai.com/blog/h200-server-price>
- Newegg. 2026. Supermicro SYS-421GE-TNRT-02-G1. <https://www.newegg.com/p/N82E16859152404>

SOURCES

## Source Register

DIG. 2025. Maritime cyber risk in satellite-linked edge devices increases to 22% of the maritime cyber incidents in 2025 Digital Watch Observatory. <https://dig.watch/updates/maritime-cyber-risk-linked-edge-devices-i>

ABC. 2023. DP World Australia confirms employee data was stolen during cyber attack, warns of further freight delays ahead of Christmas rush , ABC News. <https://www.abc.net.au/news/2023-11-28/dp-world-australia-employee-data-stolen-cyber-attack-freight/103161588>

IMO. 2026. GUIDELINES ON MARITIME CYBER RISK MANAGEMENT. <https://wwwcdn.imo.org/localresources/en/OurWork/Security/Documents/MSC-FAL.1-Circ.3-Rev.4.pdf>

Europa. n.d.. CYBER RISK. <https://www.enisa.europa.eu/sites/default/files/publications/ENISA%20Guidelines%20-%20Cyber%20Risk%20Management%20for%20Ports.pdf>

USCG. 2023. Maritime Cyber Assessment & Annex Guide (MCAAG). <https://www.dco.uscg.mil/Portals/9/CG-FAC/Documents/Maritime%20Cyber%20Assessment%20%20Annex%20Guide%20(MCAAG)_released%2023JAN2023.pdf>

Industrialcyber. 2025. Booz Allen, McCrary report warns of cyber sabotage risk at US ports, urges zero trust amid systemic OT weaknesses , Industrial Cyber. <https://industrialcyber.co/reports/booz-allen-mccrary-report-warns-of-cyber-sabotage-risk-at-us-ports-urges-zero-trust-amid-systemic-ot-weaknesses/>

---

### About CodeNinja

CodeNinja is a Middle Eastern-American artificial intelligence lab focused on building self-improving systems. We are reinventing knowledge work to close the loop between vertical AI use cases and the generalized intelligence that fuels it, accelerating the path toward organizational superintelligence.


---

# How Praxis Designs Physical AI Systems: Method and Evidence from Seven Reference Architectures

Canonical: https://codeatoms.ai/praxis-method/
DOI: https://doi.org/10.5281/zenodo.23132102
PDF: https://codeatoms.ai/praxis-method/paper/praxis-method-designing-physical-ai-systems.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

[CodeNinja Research](https://codeatoms.ai/) · [Praxis](https://codeatoms.ai/praxis/) · [Hyper Ontology](https://codeatoms.ai/hyper-ontology/) · [PDF](paper/praxis-method-designing-physical-ai-systems.pdf)

Vertical-Driven Architectures · Methods · Designed with Praxis · October 2026

# How Praxis Designs Physical AI Systems: Method and Evidence from Seven Reference Architectures

What it takes to design a system for the physical world, and how Praxis does it: the inputs, the eight reasoning lenses, the rules that hold on every design, and the evidence from seven published reference architectures.

CodeNinja Engineering Team · Umar Bilal

CodeNinja · 2026-10-04 · CC BY 4.0 · Web edition: <https://codeatoms.ai/praxis-method/> · DOI [10.5281/zenodo.23132102](https://doi.org/10.5281/zenodo.23132102)

**Abstract.** Designing physical AI, for a port, a grid, a mill or a construction site, has always needed deep domain expertise: what to sense, where each model may run, which rules bind, what the hardware must hold and who must approve each action. Praxis is CodeNinja's platform for designing such systems. It reads an operator's requirement in the operator's own words, loads the sector's knowledge as context, reasons through eight lenses (first principles, case studies, rules and regulations, approach, tooling and recency, history, domain fusion, and hardware and equipment) and renders one validated plan into a complete design: scope and rollout, layered architecture, object model, model and equipment register, cost and a live simulation. Across the seven designs published in the Vertical-Driven Architectures series, covering 4 sectors in 3 countries, Praxis listed 7,672 records as candidate context and read 872 of them in full, its lenses cited 142 sources, and 8 times a lens found nothing citable and said so instead of filling the gap. 5 of the seven designs cover every recorded requirement through a rollout gate; the other two print their lower coverage as counted. Every design ships its object model as a `hyper-ontology/1` package that [Hyper Ontology](https://codeatoms.ai/hyper-ontology/) imports to stand up a living system.

## 1. The problem: physical systems need a domain engineer's judgement

A software system can be designed from its data model outward. A physical AI system cannot. Its first decisions are physical: whether detection must happen at the edge because the link drops in the storm that matters, whether a thermal camera crosses an export threshold, whether a 753 billion parameter model fits the GPUs the country can receive, whether a model may ever write to life-safety equipment. Those decisions have traditionally been made by engineers with a decade in one sector, and they are the reason designs for ports, grids, mills and sites take months to write and are rarely shared.

Praxis exists to make that judgement explicit, reproducible and fast: to design the system a ten-year domain engineer would, show the reasoning, and cite what justified each choice.

## 2. What Praxis takes in

**The requirement, in the operator's own words.** Praxis reads the ask as written, often a published request for proposals, and does not paraphrase it before reasoning. The forward deployed engineer may pin what the requirement leaves open: the sector, a reference architecture, and the country the design is written for.

**The room.** Praxis assigns the family and industry, then lists the sector's knowledge as candidate context: regulations, tooling and model records, approaches, case studies, history and hardware entries. Across the seven designs the room held between 821 and 1,329 records, and Praxis read between 115 and 133 of them in full. Nothing is ranked or filtered by keyword: the model reads and decides what applies. Nothing is fine-tuned: the knowledge rides as context, so a design in a new sector needs a thicker room, not a new model.

## 3. How Praxis reasons: eight lenses

| Lens | The question it answers |
| --- | --- |
| First principles | Why must the design take this shape, from the physics and the operation itself? |
| Case studies | How did comparable operations handle this problem, and what failed? |
| Rules and regulations | Which rules of this country and sector bind the design, including export controls? |
| Approach | Which patterns fit, which are set aside, and why? |
| Tooling and recency | Which models, runtimes and products are current and correctly licensed today? |
| History | What did earlier designs in this sector learn? |
| Domain fusion | Where do two disciplines meet in one decision? |
| Hardware and equipment | Which compute, sensing and field equipment does the design land on, and how is it sized? |

Table 1. The eight lenses. Each returns either a contribution with sources the design can cite, or a gap stated in a sentence.

Three rules hold on every design. **AI reasons, tools generate:** the model writes one validated plan, and code renders every document, figure and simulation from it, so one plan always yields the same output. **No claim without a record:** a model, regulation or pattern survives into a design only if a source supports it, and a lens with nothing to cite says so. **A person on every write:** designs recommend; a named person approves anything that changes a plan, a schedule or a piece of equipment.

## 4. What Praxis produces

From one plan Praxis renders a scope baseline whose phases carry item counts and gates rather than durations; a layered architecture from sources through adapters, one object model, inference tiers and surfaces; the object model as a `hyper-ontology/1` package; a model and equipment register in which every GPU class follows from memory arithmetic (parameters times bytes per parameter, plus a factor for cache and activations, against the memory of the class the country can receive); a three-year cost comparison from cited public prices; a live simulation; a proposal and functional specification; and the research paper. Chapter 11 of every paper in the series is the reasoning record of that design.

## 5. Evidence from seven designs

| Design | Sector | Country | Listed | Read in full | Cited | Gaps | Phases / items | Requirements covered |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [Sovereign HSE Watch](https://codeatoms.ai/sovereign-hse-pakistan/) | oil and gas | Pakistan | 1,243 | 116 | 28 | 1 | 3 / 17 | 0 of 12 |
| [Feeder Firewatch](https://codeatoms.ai/wildfire-risk-distribution-us/) | energy and utilities | United States | 1,329 | 115 | 20 | 0 | 2 / 15 | 5 of 5 |
| [Terminal Pulse](https://codeatoms.ai/truck-turn-container-terminal-us/) | maritime and ports | United States | 821 | 131 | 26 | 0 | 3 / 14 | 5 of 5 |
| [Structure Phase Watch](https://codeatoms.ai/structure-phase-construction-saudi-arabia/) | heavy industry and construction | Saudi Arabia | 1,142 | 127 | 25 | 1 | 3 / 18 | 2 of 7 |
| [Steel Count Ledger](https://codeatoms.ai/steel-production-count-pakistan/) | heavy industry and construction | Pakistan | 1,043 | 133 | 17 | 3 | 3 / 15 | 15 of 15 |
| [Factory Fire Watch](https://codeatoms.ai/factory-fire-monitoring-saudi-arabia/) | heavy industry and construction | Saudi Arabia | 1,272 | 119 | 16 | 1 | 4 / 19 | 5 of 5 |
| [Port Twin](https://codeatoms.ai/port-digital-twin-us/) | maritime and ports | United States | 822 | 131 | 10 | 2 | 4 / 18 | 16 of 16 |

Table 2. What Praxis read and cited for each design, and the coverage each design prints. Listed and read in full are the room; cited is the sum across the eight lenses; gaps counts lenses that found nothing citable.

Figure 1. Sources each lens cited, per design. A dashed cell is a lens that found nothing citable in the room and said so.

### What the evidence shows

**Praxis reads about one record in ten in full.** Across the series it read 872 of 7,672 listed records (11 percent). The rest stay available as titles; the model chooses which to open, and the choice is recorded.

**Hardware is never an afterthought.** The hardware and equipment lens cited four or more sources in 6 of the seven designs. It is the lens that fixes whether a frontier model runs on one node of eight 141 GB GPUs, whether vision runs on a Jetson Orin class edge box in a solar enclosure, or whether the design buys no compute at all, as in the port and factory designs.

**Gaps are stated, not filled.** 8 lens results across the series are gaps: case studies 3, rules and regulations 2, history 2, hardware and equipment 1. They mark where the sector's knowledge is thin today, most often in case studies, and they are printed in the paper rather than papered over with a plausible source.

**Coverage is counted, not asserted.** 5 designs close every recorded requirement through a rollout gate. Structure Phase Watch covers two of seven and states that five sit outside its baseline as later scope. Sovereign HSE Watch prints none of twelve as covered by a gate. Both numbers are the platform's count, published as counted.

## 6. Where people stay in the loop

The forward deployed engineer pins what the requirement leaves open and reviews every design before it leaves. Every design names its write paths and the person who approves each. Before publication a separate gate reads every paper, figure and file for operator names, near identifiers and claims that will not survive scrutiny, such as an export control statement for the wrong country group, and the paper does not ship until it passes.

## 7. Limits

The designs are reference architectures, not quotations: hardware prices are public list prices on a stated date, and counts such as users or installation points are assumptions printed where they are used. The quality of a design follows the thickness of the sector's room; the gaps in Figure 1 are where it is thinnest today. Praxis is in beta, used in house by CodeNinja's forward deployed engineers; access for outside teams is by request at <https://codeatoms.ai/praxis/>.

## References

1. CodeNinja Engineering Team and Umar Bilal. 2026. *Sovereign HSE Watch: Predictive Risk and Early Warning on an HSE Control and Command Platform*. CodeNinja. <https://doi.org/10.5281/zenodo.23119714>
2. CodeNinja Engineering Team and Umar Bilal. 2026. *Feeder Firewatch: Live Ignition and Outage Risk for Every Distribution Feeder*. CodeNinja. <https://doi.org/10.5281/zenodo.23119325>
3. CodeNinja Engineering Team and Umar Bilal. 2026. *Terminal Pulse: Predicted Truck Turn Time and Live Yard Sight for a Container Terminal*. CodeNinja. <https://doi.org/10.5281/zenodo.23119348>
4. CodeNinja Engineering Team and Umar Bilal. 2026. *Structure Phase Watch: Live Production, Crane and Delivery Evidence for Every Pour on a Construction Site*. CodeNinja. <https://doi.org/10.5281/zenodo.23126448>
5. CodeNinja Engineering Team and Umar Bilal. 2026. *Steel Count Ledger: Independently Counted Production for Every Steel Mill in Pakistan*. CodeNinja. <https://doi.org/10.5281/zenodo.23126563>
6. CodeNinja Engineering Team and Umar Bilal. 2026. *Factory Fire Watch: Read-Only Smart Fire Protection Monitoring for Every High-Risk Factory*. CodeNinja. <https://doi.org/10.5281/zenodo.23126565>
7. CodeNinja Engineering Team and Umar Bilal. 2026. *Port Twin: One Governed Digital Twin for Every Asset, Feed and Dollar*. CodeNinja. <https://doi.org/10.5281/zenodo.23126431>


---

# Fodder Watch: Earth Observation That Turns Restricted-Crop Detections Into Enforceable Case Files

Canonical: https://codeatoms.ai/restricted-crop-monitoring-saudi-arabia/
DOI: https://doi.org/10.5281/zenodo.23186675
PDF: https://codeatoms.ai/restricted-crop-monitoring-saudi-arabia/paper/fodder-watch-restricted-crop-earth-observation-saudi-arabia.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

VERTICAL-DRIVEN ARCHITECTURES · AGRICULTURE & EARTH OBSERVATION · DESIGNED WITH PRAXIS · OCTOBER 2026

# Fodder Watch: Earth Observation That Turns Restricted-Crop Detections Into Enforceable Case Files

An 18-month sovereign monitoring service that turns satellite and aerial imagery rounds into license-checked detections of restricted green fodder and unlicensed cultivation for an agriculture and earth observation operator in Saudi Arabia.

CodeNinja Engineering Team

For the enforcement and compliance lead of an agriculture and earth observation operator in Saudi Arabia, their regional superintendents, and the geospatial, data and platform engineers who would build and run it.

---

Vertical-Driven Architectures is a CodeNinja series of system designs. Every design in the series is driven by a real-world problem and scenario in a single industry, and every one is designed on Praxis, CodeNinja's platform for designing physical AI systems. Operations are described by class, never by name.

At a glance

## Restricted-crop monitoring from orbit in Saudi Arabia

**What this is.** An open reference architecture for system design in physical AI: an 18-month earth observation service that screens every parcel for restricted green fodder and cultivation beyond the licensed area, checks each detection against the holding's licence, and turns the confirmed ones into case files an inspector can act on. It is written for the enforcement and compliance lead and for the geospatial, data and platform engineers who would build it. The operator is described by class, never by name.

**The answer in numbers.**

| Part | The design |
| --- | --- |
| Sources joined | 8 source systems, from the national agricultural register and licence records to a mirrored Sentinel-2, Sentinel-1 and Landsat archive, through 1 integration adapter family |
| Object model | 14 typed objects, from farm holding and licence to detection flag and case file, published as JSON for reuse |
| Models | RF-DETR fine-tuned per region and Chronos-2 zero-shot, both Apache-2.0, about 0.55 GB of weights together |
| Compute | One 48 GB L40S-class inference node inside the Kingdom; the card class needs a US export licence |
| Three-year cost | About 15,200 dollars to own the node, about two thirds the deepest three-year AWS commitment, and renting would move the data outside the Kingdom (Appendix A) |
| Human control | Every flag is verified on the ground by a named field inspector before a case file opens |

**Reuse it.** The object model, the model register and the figures are free to reuse under CC BY 4.0. Cite as DOI <https://doi.org/10.5281/zenodo.23186675.>

**Made with.** Reasoned on [Praxis](<https://codeatoms.ai/praxis/>), CodeNinja's platform for designing physical AI systems. The object model imports into [Hyper Ontology](<https://codeatoms.ai/hyper-ontology/>), which turns it into a living system. Both are in beta; access by request.

ABSTRACT

## A Violation Should Be Seen From Orbit, Not at the Fuel Pump

Which holdings are growing restricted green fodder or cultivating beyond the area their license allows, how many hectares are involved, and which of the three violator classes each holding falls into, so that penalties and the fuel and electricity conditions can be applied? The operator cannot answer this today because the national register, the crop license records and rounds of satellite and aerial imagery live in systems that never meet, and photo-interpretation reviews a sample of scenes rather than the whole sedimentary shelf.

The design joins eight named source systems, from the national agricultural register and license records to the mirrored Sentinel-2, Sentinel-1 and Landsat archive, through one integration adapter family onto an ontology of fourteen objects, which five services and two inspector-facing surfaces read. Two open-weight models, an RF-DETR fine-tune and a zero-shot Chronos-2, run on a 48 GB GPU class inside the operator's in-Kingdom facility, screening every parcel and triaging so only the flagged minority reaches a human inspector, ending in verified case files and GIS layers published to the operator's own enforcement channel.

The paper opens with the industry problem and the join failure, then gives the constraints, the stack, the object model, ingestion, inference placement and the models and licenses in Part II. Part III gives the rollout in three phases with their gates and the ownership of everything the design builds. Part IV closes with how Praxis contextualized and reasoned the design, tracing every choice back to what was recorded.

---

![Figure 1. Fodder Watch on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.](figures/figure_01.png)

Figure 1. Fodder Watch on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.

## Contents

Each chapter is tagged for the reader it serves most directly: Executive, Team Lead, FDE, Reference.

|  |  |  |
| --- | --- | --- |
|  | Abstract · A Violation Should Be Seen From Orbit, Not at the Fuel Pump | Executive |
| PART I · THE PROBLEM | | |
| 1 | [A Restricted Crop Grows Faster Than an Inspector Can Walk](#ch1) | Executive |
| 2 | [Every Register and Every Image Sees One Slice](#ch2) | ExecutiveTeam Lead |
| PART II · THE DESIGN | | |
| 3 | [Licenses, Imagery, Accuracy and Sovereignty Shape the Design](#ch3) | Team Lead |
| 4 | [One Stack Runs From Orbit to the Case File](#ch4) | Team LeadFDE |
| 5 | [Fourteen Objects Turn Imagery Into an Enforceable Case](#ch5) | FDE |
| 6 | [Every Source Enters Through One Adapter, Never Directly](#ch6) | FDE |
| 7 | [All Inference Stays Inside the Kingdom](#ch7) | FDE |
| 8 | [The License Decides What the Kingdom Can Own](#ch8) | FDEExecutive |
| PART III · THE ROLLOUT | | |
| 9 | [Shadow Rounds Come Before Any Flag Is Trusted](#ch9) | Team LeadExecutive |
| 10 | [The Ontology and the Weights Stay with the Operator](#ch10) | Executive |
| PART IV · HOW IT WAS DESIGNED | | |
|  | Conclusion · The Same Shape Watches Any Regulated Ground | Executive |
| 11 | [Every Choice Traces Back to a Recorded Reading](#ch11) | Team LeadFDE |
|  | [Sources](#sources) | Reference |

PART I · CHAPTER 1

## A Restricted Crop Grows Faster Than an Inspector Can Walk

Restricted green fodder keeps being grown on unlicensed ground, and the cost is measured in liquid fuel, aquifer draw and penalties of SAR 4,000 per hectare.

The abstract stated the shape of the service: an 18-month sovereign monitoring contract that turns satellite and aerial imagery rounds into license-checked detections, triages them so only the flagged minority reaches a human, and hands verified case files and GIS layers to the operator's own enforcement. This chapter establishes what question that service exists to answer, what the problem is documented to cost, and what the operation it serves actually looks like on the ground.

### 1.1  The Question the Operation Needs Answered

The question is narrow and it is per holding: on a given date, is a specific center pivot growing restricted green fodder, meaning berseem (البرسيم) and Rhodes grass, without a license, and if the grower holds a license, is the cultivated area inside it? The operator's policy recognizes three violator classes, and every detection must be sorted into one of them: a registered farm growing fodder without a fodder license, an unregistered farm growing fodder at all, or a licensed farm exceeding its licensed area. The answer must name the holding, the parcel, the hectares measured and the observation dates on both sides of the change, because each of those fields becomes evidence if the case is disputed.

Answering it requires data the operation already holds or already collects. The national agricultural register is the join key that separates the three violator classes; crop license records issued under Resolution 439 fix the region, farm coordinates, licensed area and crop type that every detection is checked against; well use licenses fix permitted abstraction; and imagery that resolves pivots shows what is actually on the ground. The regulatory ground is set by the Council of Ministers resolutions 66/1437 that restrict green fodder in the applicable regions, by the Resolution 439 licensing regime, by national water policy expressed through well use licenses, and by the service-condition mechanism that makes a valid register entry and a valid license a condition for obtaining agricultural fuel and electricity.

### 1.2  What the Problem Costs on the Record

The documented penalty is SAR 4,000 per hectare per year, doubling on repeat, under the operator's own published enforcement policy, and a violation measured late is a season of unlicensed cultivation that no penalty retroactively prevents. Behind the penalties sit the costs named in the requirement's own title: liquid fuel consumed by unlicensed agricultural activity, and the fossil aquifer draw that irrigated fodder on the sedimentary shelf implies. The wider stakes are the ones the agro-geoinformatics literature frames: integrating geospatial technologies into agricultural management is critical for tackling food insecurity, climate variability and resource pressure (ScienceDirect n.d.). The cost of knowing is equally documented: on-site observations remain difficult to obtain, access and reuse, which is precisely what keeps verification walking-paced and inspection sampled rather than complete (ESA 2026).

### 1.3  The Operation as a Scenario

The operation runs national-scale crop control over the sedimentary shelf: rounds of satellite imaging of center pivot farms, aerial survey of the shelf, penalty cases against named farms, and coordination that ties register and license validity to fuel and electricity services. Its scale is banded: a register of farm holdings across several agricultural regions, with holdings tiered at 50 hectares and below, 50 to 100 hectares, and above 100 hectares, watched from orbit at a 10 m optical baseline with radar as complement. The physical is hostile to casual observation: open desert shelf, dust and haze that mask optical scenes, remote pivots reached by track, and summer heat. The people in the loop are two roles: field inspectors who carry GNSS tablets and verify flagged parcels on the ground, and senior inspectors who review referred case files. The regulatory ground combines the fodder ban, the license regime, water abstraction licenses and the fuel and electricity service conditions. The design that follows counts seven named source systems, one adapter family, fourteen objects, five services, two surfaces and two models, all running in one in-Kingdom sovereign facility.

PART I · CHAPTER 2

## Every Register and Every Image Sees One Slice

The register, the license records, the geospatial databases and the imagery archive each hold one slice of every holding, and none of them can answer whether a specific pivot is licensed, in-region and within its area on a given date.

Chapter 1 defined the question the service must answer per holding and per date, and the data it needs to answer it. This chapter walks the systems the operator already runs and shows that each holds one slice of every holding, which is why the answer does not exist in any one of them today.

### 2.1  What Each System Sees and What It Misses

The national agricultural register sees the legal identity of the estate: who is registered, in which region and governorate, at what coordinates, with which crop and livestock activities. It misses everything that happens in a season: whether what is actually grown matches what was declared, and whether a registered farm holds the fodder license its crop requires.

The crop license records see the legal envelope for cultivation: the licensed region, the farm coordinates, the licensed area in hectares, the crop type and the irrigation efficiency. They miss the ground entirely; a license says nothing about whether the pivot inside it is planted, fallow, or planted with something never licensed.

The operator's geospatial databases and GIS see geometry and connectivity: farm boundaries, pivot footprints and the channel that links the register to the operator and related bodies. They miss current crop condition, because a boundary layer is a shape, not an observation.

The national satellite imaging and aerial survey products see the pivot as it was on the day of acquisition, at resolutions that show center pivots plainly across the shelf. They miss license context and continuity: a scene carries no register number, and the gap between rounds is an evidential hole the moment a dispute asks what was there.

The Copernicus Sentinel-2 and Sentinel-1 archive sees the whole shelf on a 5-day optical revisit with a cloud-proof radar complement, at no per-scene fee and no foreign processing dependency. It misses area-grade measurement: a 10 m pixel resolves crop class on a pivot but is unsuited to measuring the parcel area a penalty is computed on.

Fuel supplier coordination and electricity utility coordination see the policy hook itself: whether a holding's register and license are valid enough to obtain fuel or power for agricultural activity. They miss the field completely; neither ever sees a pivot, a hectare or a crop.

Figure 2 sets these seven systems side by side, each with its slice and its blind spot.

![Figure 2. Seven systems, each seeing one part of the answer. the question needs all of them in one place at once.](figures/figure_02.png)

Figure 2. Seven systems, each seeing one part of the answer. the question needs all of them in one place at once.

### 2.2  What None of Them See Together

None of them can answer whether a specific pivot is licensed, in-region and within its licensed area on a given date, because that answer is a join across register, license, geometry and imagery that no single system performs. The cost in practice is structural: inspection is sampled where the law applies to the whole population, a detection checked against the wrong license becomes either a false accusation against a named farm or a missed season of unlicensed cultivation, and area evidence arrives too weak to survive appeal. The design's response is to hold all the slices in one object model so the question becomes a join rather than an investigation.

PART II · CHAPTER 3

## Licenses, Imagery, Accuracy and Sovereignty Shape the Design

License fidelity, per-parcel accuracy, dust-proof sensing and in-Kingdom custody of data and weights are the four constraints every later choice answers to.

Chapter 2 left the design with one obligation: hold every slice in one object model so the per-holding, per-date question becomes a join rather than an investigation. Four constraints decide how that model is built, how it is sensed, and where it is allowed to run.

### 3.1  License Fidelity Comes Before Detection

A detection is a legal act, not a map pixel: it is checked against a named license, a licensed area and a region, and if the join is wrong the accusation is wrong. That makes license fidelity the first constraint. The register and license records are the authoritative sources, the geometry behind every penalty is the register's geometry, and field boundaries, which are usually wrong or missing, are treated as a funded reconciliation workstream rather than an assumption. Every boundary in the object model carries its source and capture date, so a disputed case can always be traced to the geometry the penalty was computed on.

### 3.2  Accuracy Is Judged Per Parcel, Not Per Region

A false positive is a SAR 4,000-per-hectare accusation against a named farm, and the closest published checks-by-monitoring precedent got about a quarter of individually mapped parcels wrong even while the regional total looked right. The constraint is therefore per-parcel user's accuracy against an independent reference sample, not regional agreement. Producer's and user's accuracy are published separately, every reported area is error-adjusted, and a flag leaves the pipeline only with corroboration in time or in sensor. The bottleneck the literature names, that on-site observations are hard to obtain and reuse (ESA 2026), is answered by making the inspector visits themselves the labeled corpus that retrains the detector each season.

### 3.3  Sensing Must Survive Dust, Not Just Cloud

Over the sedimentary shelf the optical channel's real attacker is dust and haze, not cloud, and a masked pixel is not a clean absence. The design stands on Sentinel-1 radar as the standing complement, treats the scene classification layer as evidence rather than truth, and requires two consecutive screened observations or a second sensor before any flag is raised. Revisit cadence and coverage per region are settled explicitly in the imagery commissioning, with vendor tasking metered where commercial confirmation imagery is bought.

### 3.4  Data and Weights Stay Inside the Kingdom

Sovereignty is the operator's requirement, not a preference: imagery, register data, detections and model weights all stay in-Kingdom, in the operator's own facility. The design mirrors the free Sentinel archive in-Kingdom rather than processing abroad, and it holds only open-weight models under Apache-2.0 licenses so the operator owns its fine-tuned weights outright, with no field-of-use restriction and no foreign processing dependency anywhere in the pipeline.

### 3.5  Scoping Decisions and What Each Costs

Three scoping decisions shape everything downstream, and each buys something real at a stated price, as Table 1 records.

Table 1 · Scoping Decisions

| Decision | What it buys | What it costs |
| --- | --- | --- |
| One abstracted imagery source behind a single adapter: archive mirror, national imagery products or supplier tasking | The pipeline trains and runs whichever imagery answer the contract settles | An imagery commissioning item in phase one must size revisit, storage and tasking budget before the prototype trains |
| Free Sentinel-2, Sentinel-1 and Landsat baseline mirrored in-Kingdom, with commercial tasking bought only per confirmation need | A sovereign backbone with no foreign processing dependency and no per-scene fee at screening scale | The baseline resolves crop class but not parcel area, so area evidence needs an aerial or tasking confirmation round |
| Traffic-light triage so only the flagged minority reaches a human | Whole-population screening at an operating cost a photo-interpretation desk cannot match | The service's accuracy is now judged per parcel, because a flag is a SAR 4,000 accusation against a named farm |

### 3.6  What the Design Chose Against

Each rejection is a deliberate trade with a stated reason, recorded in Table 2, ending with the boundary of the service itself.

Table 2 · What the Design Chose Against

| Where | What was picked | Instead of, and why |
| --- | --- | --- |
| Detection method | Per-parcel index time series with traffic-light triage | Instead of a photo-interpretation desk reviewing scenes farm by farm: the closest published checks-by-monitoring precedent flagged only 2.9 to 11.2% of parcels while screening the whole population |
| Imagery backbone | Free Sentinel-2, Sentinel-1 and Landsat scenes mirrored in-Kingdom | Instead of commercial tasking as the backbone or a commissioned constellation: a 10 m pixel resolves pivots for crop class but is unsuited to measuring parcel area, so high-resolution evidence is bought only where a case needs it |
| Model licensing | Apache-2.0 checkpoints only: RF-DETR Nano to Large and Chronos-2 | Instead of the RF-DETR XL and 2XL checkpoints, which sit under a platform license that would restrict what the operator can hold: the operator must own its fine-tuned weights outright |
| Dust resilience | Sentinel-1 radar as the standing complement, with a two-observation screen before any flag | Instead of an optical-only cadence: dust, not cloud, is the optical channel's attacker over the sedimentary shelf |
| Verification | GNSS field tablets at 3 to 5 m grade with an arrival-coordinate buffer check | Instead of trusting visits without position evidence: the check files a not-reached visit and removes phantom false alarms |
| Scope | Monitoring, triage and verified case files only | Instead of penalty assessment and collection, fuel and electricity service gating, on-farm hardware, yield forecasting and grower advisories, hardware and infrastructure, third-party license fees, historic data migration, estate-wide training, round-the-clock support and regulatory sign-off, which stay with the operator |

PART II · CHAPTER 4

## One Stack Runs From Orbit to the Case File

A single layered stack runs from the registers and the mirrored archive, through adapters and one object model, to the services and the two inspector surfaces.

Chapter 3 fixed the four constraints and priced the scoping decisions that honour them: read-only access to the registers, imagery mirrored inside the Kingdom, automated triage before any human is involved, and every verdict left to a named inspector. This chapter lays those constraints onto one layered stack and names the component that carries each stage.

### 4.1  The Pattern and Why It Fits

The stack follows the pattern the series uses for physical operations: systems of record below, one object model in the middle, applications and agents above. Below sit the systems the operation already runs: the national agricultural register, the crop license records, the geospatial databases and GIS, the fuel and electricity coordination channels, and the satellite archives. In the middle, fourteen objects with typed links hold the join between them. Above, five services and two inspector surfaces do the work the contract names. The pattern fits because the enforcement question is a join: a detection only becomes a case when a pixel meets a license, a license meets a holding, and a holding meets a register entry. A document store cannot hold that join as first-class structure; a graph-backed object model can, and it is the layer the rest of the design reads and writes through.

Around that spine run the shared machinery: Apache Kafka 4.3 in KRaft mode with three dedicated controllers as the event backbone, a Harbor registry holding signed artefacts in the air-gapped facility, Keycloak for identity, Prometheus, Grafana and Loki for observability, and a Kubernetes-class container platform of the K3s distribution pinned at design. Time discipline is business-grade: satellite products carry UTC acquisition stamps and internal hosts hold synchronisation on a chrony-class service, so an acquisition is never silently reordered against a license event. Figure 3 shows the layered stack with the component count per layer.

![Figure 3. The layered stack: 8 sources, 1 adapter family, 14 objects, 5 services and 2 surfaces.](figures/figure_03.png)

Figure 3. The layered stack: 8 sources, 1 adapter family, 14 objects, 5 services and 2 surfaces.

### 4.2  The Stack Stage by Stage

Table 3 walks the stack from orbit to case file, naming what each stage is responsible for and the components that carry it. Two layers the series usually sizes are deliberately absent: no video ingest exists because the land is watched from orbit and by aerial survey, so imagery lands as GeoTIFF and COG products through STAC rather than as streams; and no edge serving exists because there is no site, everything runs in the in-Kingdom facility and nothing gates on a farm's connectivity.

Table 3 · The Stack, Stage by Stage

| Stage | What it is responsible for | How |
| --- | --- | --- |
| Sources | Hold the legal and physical truth every case stands on | national agricultural register; crop license records; the operator's geospatial databases and GIS; fuel supplier coordination; electricity utility coordination; the national imaging and aerial survey program; the Copernicus Sentinel-2 and Sentinel-1 archive; the Landsat 8/9 archive |
| Sensing | Turn orbit and aerial passes into measurements a pipeline can read | Sentinel-2 multispectral at 10 m on a 5-day revisit; Sentinel-1 C-band radar as the cloud-proof complement; Landsat 8/9 for archive depth; Sentinel-2 scene classification layers; national aerial survey products; GNSS field tablets at 3 to 5 m grade on inspector visits |
| Adapters | Form the only door into the platform, never a direct write | One integration adapter family: scheduled read-only extracts from the register and the license records, OGC API, WFS and ArcGIS REST into the GIS, and STAC cataloguing of mirrored scenes, each named in the integration register with its mechanism and cadence |
| Object model | Hold the fourteen objects, their typed links and status vocabularies | The graph-backed ontology store, with per-parcel vegetation index series on a columnar time-series store of the InfluxDB 3 Core and TimescaleDB class, retention set by the audit requirement |
| Inference | Detect restricted crops and screen the anomalies against license truth | The RF-DETR fine-tune per region and Chronos-2 zero-shot residual screening, side by side on the 48 GB PCIe inference GPU class (L40S class), air-cooled in the in-Kingdom facility |
| Services | Carry the five duties the contract names | Register & license data; imagery & detection; sovereignty & governance; field verification & cases; reporting & delivery |
| Surfaces | Put every decision in front of a named person | The operator's field inspector view and the senior inspectors view, both behind Keycloak identity, both reading and writing only through the object model |

PART II · CHAPTER 5

## Fourteen Objects Turn Imagery Into an Enforceable Case

Fourteen objects, anchored in the register and the license records, hold the typed links that turn a pixel into an attributable, appealable case.

Chapter 4 placed the stages of the stack and named the component at each one. This chapter opens the middle layer and shows what the fourteen objects hold, how the typed links turn a pixel into an attributable case, and where the human loop and the hosting boundary sit.

### 5.1  Every Object and Its Typed Links

The fourteen objects fall into four families. Holdings and actors: farm holding, center pivot / cultivated field, and farm enterprise / large farmer, each anchored in the register and the operator's geospatial databases. Legal records: the crop license for wheat and seasonal fodder, the water source (well) use license, the green fodder ban control that records the council resolutions behind the restriction, and the agricultural fuel / electricity service condition record that ties register and license validity to service access. The observation chain: imagery tasking order, satellite image capture and processed imagery product, the provenance trail from a planned acquisition to a citable scene. The enforcement chain: restricted-crop detection flag, violation case file and the operator's field inspector as a person object, plus the restricted-crop classifier itself, held as an object so its version, training window and accuracy on the reference sample are queryable alongside the flags it produced. Figure 4 draws every object and its typed links, with the detection flag as the focal object.

The links are what make a query enforceable. From one detection flag, a query crosses to the license it was checked against, from the license to the holding by farm coordinates, from the holding to the enterprise and its violator class, and from the flag forward to the case file and the inspector who verified it. A document store can store all of these records but cannot traverse them; here the path from pixel to penalty basis is a graph walk, and every hop carries its own status vocabulary and timestamp domain.

![Figure 4. The fourteen objects of the model and the typed links that let a query reach across them.](figures/figure_04.png)

Figure 4. The fourteen objects of the model and the typed links that let a query reach across them.

### 5.2  Where the Human Loop Lives

The human loop lives on the detection flag. Its status vocabulary, raised, triaged, dispatched, scouted, confirmed, refuted, artefact, unresolved, is the triage contract: only the flagged minority is dispatched, and every transition is made by a named inspector whose identity comes from Keycloak. Field truth is the scarce resource; earth observation for agriculture is bottlenecked by on-site observations, which remain difficult to obtain and reuse (ESA 2026), so the inspector visit, with its recorded arrival coordinates compared against the flagged polygon, is the design's ground-truth instrument and the labelled corpus that retrains the classifier each season. The hosting posture follows: everything runs in the in-Kingdom facility, mirrored scenes never leave the boundary, the register is read-only, the fuel and electricity condition record is the only external link and it moves through the operator's coordination channel, and the only write path into the object model is the status transition on a flag or case by a named person.

### 5.3  One Object in Its Recorded Form

The restricted-crop detection flag is the object that carries the whole argument, because it is where imagery, license truth and human decision meet, and its recorded form is printed below with the screening rule that cleared it and the observation dates on both sides of the change.

```
{
  "id": "farm-holding",
  "label": "Farm holding",
  "kind": "site",
  "anchored_in": "national agricultural register",
  "properties": [
    "Register number",
    "Region and governorate",
    "Farm coordinates",
    "Area tier (50 ha and below / 50 to 100 ha /\u2026",
    "Crop and livestock activities"
  ],
  "status_vocabulary": [
    "Registered",
    "Unregistered",
    "Under review"
  ],
  "links": [
    {
      "to": "farm-enterprise-large-farmer",
      "label": "belongs to"
    },
    {
      "to": "crop-licence-wheat-seasonal-fodder",
      "label": "holds licence"
    },
    {
      "to": "agricultural-fuel-electricity-service-condition-record",
      "label": "conditions"
    }
  ]
}
```

PART II · CHAPTER 6

## Every Source Enters Through One Adapter, Never Directly

Eight named sources enter through one integration adapter family onto an event backbone that keeps acquisition order, register order and case order intact.

Chapter 5 defined what the object model holds and who may write to it. This chapter describes how data gets into it: the eight named sources, the guarantees of the single adapter family they enter through, and the event backbone that keeps every order intact.

### 6.1  Eight Sources, Two Provenance Classes

Eight named sources feed the platform, each tagged with its provenance class and read direction, as Figure 5 shows. Five are operator-held, read from systems the operator already runs: the national agricultural register, the national satellite imaging and aerial survey program, the geospatial databases and GIS, the fuel supplier coordination channel, and the electricity utility coordination channel. Three are domain-typical, held under the same class because the sources are public or industry-standard rather than operator-specific: the crop license records that Resolution 439 licensing fixes, the Copernicus Sentinel-2 and Sentinel-1 archive, and the Landsat 8/9 archive, whose combined 8-day cadence reaches back decades. Every source is read-only; nothing in the design writes back into a system of record, and the integration register names each source with its mechanism and cadence.

![Figure 5. The 8 named systems, the adapter path each one takes, and the object model they all map into.](figures/figure_05.png)

Figure 5. The 8 named systems, the adapter path each one takes, and the object model they all map into.

### 6.2  What the Adapter Tier Guarantees

Every source enters through one integration adapter family, never directly into the object model. The adapter tier guarantees four things. First, provenance: every record arrives tagged with its source, its provenance class and an acquisition timestamp in UTC, so a scene is never silently reordered against a license event. Second, discipline: extracts from the register and the license records are scheduled and read-only, geospatial exchange runs over OGC API, WFS and ArcGIS REST, and imagery lands as GeoTIFF and COG products catalogd through STAC, not as streams. Third, idempotence: a replayed batch makes no duplicate holding, license or flag. Fourth, quarantine: a schema change in any source is held in a dead-letter path for review instead of corrupting the model, which matters because the register and the license records are living administrative systems whose vocabularies can change mid-season.

### 6.3  The Event Backbone

Apache Kafka 4.3 in KRaft mode, with three dedicated controllers, is the backbone every adapter writes into and every service reads from. Ordering is by key: holding reference for register and license events, parcel reference for detections, so all events for one holding or one parcel keep acquisition order through the pipeline. Delivery is at-least-once with idempotent consumers, which pairs with the adapters' replay guarantee. Buffering absorbs the shape of the workload, because a mirroring round lands the scenes for a whole region in a burst while case transitions trickle in all day. Replication stays inside the in-Kingdom facility, keeping the sovereignty posture intact, and retention is set so that any flag can be traced back to the exact scenes and register extracts that raised it, for the life of the audit requirement.

PART II · CHAPTER 7

## All Inference Stays Inside the Kingdom

Detection and time-series screening run on a 48 GB GPU class inside the operator's in-Kingdom facility, and nothing needs to think in the desert.

Chapter 6 closed the integration story: every scene, register extract and license event enters through one adapter family onto an ordered, replayable event backbone, so the computation that follows never reads a source system directly. This chapter places that computation. The placement is deliberately simple, and the chapter is short for that reason: one inference tier, one facility, and no compute in the desert.

### 7.1  One Inference Tier Inside the Facility

The design carries exactly one inference tier, a central one, running inside the operator's in-Kingdom sovereign facility on the 48 GB PCIe GPU class (L40S class), air-cooled alongside the rest of the pipeline under a Kubernetes-class container platform. There is no edge tier, and the omission is principled rather than deferring: fields and pivots do not move, so there is no trajectory problem; no farm-side hardware exists to serve; and nothing in the pipeline gates on a farm's connectivity. Figure 6 shows the tier, what runs on it, and the single boundary it sits behind.

Two models run side by side on the node: the fine-tuned RF-DETR detector for restricted-crop and center-pivot detection, and the zero-shot Chronos-2 forecaster for per-parcel vegetation index baselines. The memory arithmetic is untroubled. The Apache-licensed RF-DETR Nano to Large detection checkpoints occupy about 61 to 68 MB at 16 bit in BF16; Chronos-2 as published is about 0.48 GB at FP32, or about 0.24 GB at 16 bit. At the stated serving precisions the combined resident weights sit under roughly 0.55 GB, around one percent of the 48 GB class. Usable memory runs somewhat below the nameplate once the operating system and serving runtimes take their share, but the attention KV cache ceiling is not the binding constraint here: with weights this small the cache ceiling sits close to the usable total, so batches of independent per-parcel index series scale to the workload rather than to a memory wall. On-site observations remain difficult to obtain, access and reuse (ESA 2026), which is why the design pulls its ground truth from inspector GNSS visits rather than field sensors, and lets the central node carry all of the thinking.

![Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.](figures/figure_06.png)

Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.

### 7.2  The Latency Budget

The budget runs from satellite acquisition to a dispatched flag, and it is dominated by orbital cadence, not by compute: Sentinel-2 revisits optically every 5 days, Sentinel-1 carries the radar complement between optical passes, and Landsat 8/9 add an 8-day combined archive view reaching back decades. The pipeline's own stages, scene mirroring, cloud and artefact screening, detection, the license join, and flag triage, are budgeted to complete comfortably inside one revisit interval, so a flag never waits on the GPU; the binding constraint is when the next scene lands, not how fast the node thinks. A Sentinel-1 confirmation acquired between two optical passes is consumed by the two-sensor corroboration rule within the same cycle, and inspector dispatch latency starts at the flag, not at the compute.

### 7.3  What Crosses the Boundary, and What Fails

What crosses the facility boundary is data in both directions and weights in neither: inward, scene products as GeoTIFF/COG through STAC plus scheduled read-only register and license extracts; outward, GIS layers over OGC services, reports, and the fuel and electricity compliance extracts. Model weights enter only through the air-gapped Harbor registry and never leave. If the imagery link fails, the event backbone buffers, scenes already mirrored stay available, and screening resumes on replay, so a disrupted cycle delays detections by one revisit rather than losing them. If facility power fails, the node re-serves on restoration and in-flight batches re-run from stream offsets, so no flag is silently dropped. If the update path fails, the serving model version keeps serving; each restricted-crop classifier version carries a named rollback target, rehearsed in phase one, so an update is never half-applied and a regression is one rollback away.

PART II · CHAPTER 8

## The License Decides What the Kingdom Can Own

Two Apache-2.0 models, a fine-tuned RF-DETR and a zero-shot Chronos-2, stay owned outright inside the Kingdom because their licenses carry no field-of-use restriction.

Chapter 7 showed that one 48 GB node inside the Kingdom holds every model this design runs, with weights near an afterthought of its memory. This chapter names those two models, states their licenses in full, and argues that the license, more than the architecture, is what lets the operator own its intelligence outright.

![Figure 7. The two models, their placement, and the work each one does.](figures/figure_07.png)

Figure 7. The two models, their placement, and the work each one does.

### 8.1  The Model Stack

Figure 7 shows the stack: two models, both Apache-2.0, both on the central tier, one fine-tuned and one zero-shot. The thesis of the chapter is contractual as much as technical. Apache-2.0 carries no field-of-use restriction, so the weights, including the operator's own regional fine-tunes, are owned outright and may be held inside the Kingdom past the end of the 18-month contract. That matters because this is regulatory monitoring over agricultural holdings: the discipline of integrating earth observation with farm-level records is exactly what the field calls agro-geoinformatics, and its value compounds only when the operator, not a foreign processing chain, holds the models and the evidence together (ScienceDirect n.d.).

### 8.2  The Detector and the Forecaster

RF-DETR is the restricted-crop and center-pivot detector, fine-tuned per region on labelled and inspector-confirmed parcels, served in BF16 on the central node. It is an Apache-2.0 detector whose Nano and Large checkpoints carry no field-of-use restriction, and the Nano-to-Large span covers both the detection and segmentation sizes the per-parcel pipeline needs; the fine-tuned weights occupy about 61 to 68 MB at 16 bit. The XL and 2XL checkpoints, at about 254 MB at 16 bit for 2XL, are excluded because they sit under Roboflow's Platform Model License, which would compromise the ownership rule, and the excluded size is not needed for 10 m per-parcel work. Where the vendor quotes latency on its own hardware, the design treats the footprint, not the part number, as the sizing truth.

Chronos-2 is the time-series forecaster, a roughly 120M parameter model that runs zero-shot over the thousands of independent per-pivot vegetation index series, with no fine-tuning in the plan. Served at FP32 at about 0.48 GB as published, about 0.24 GB at 16 bit, it sets each parcel's expected index trajectory over the revisit cycle and screens residuals against thresholds, giving the cloud and artefact screen a second, independent sensor view before any flag leaves the pipeline. It was chosen because zero-shot behavior on a central GPU fits the per-parcel population without a labelling dependency, and Apache-2.0 keeps its weights in-Kingdom beside the detector.

### 8.3  The Model and Equipment Register

Table 4 gathers the register: each model, the hardware classes and sizing rules, the sensing, the patterns the design stands on, and the ground it runs on.

Table 4 · Model and Equipment Register

| The choice | What was picked | Why here |
| --- | --- | --- |
| Detector | RF-DETR, Apache-2.0, fine-tuned per region, BF16, about 61 to 68 MB at 16 bit | No field-of-use restriction, so the operator owns the fine-tuned weights outright |
| Forecaster | Chronos-2, Apache-2.0, zero-shot, about 120M parameters, FP32, about 0.48 GB | Thousands of independent per-parcel index series with no fine-tuning dependency |
| Checkpoint exclusions | RF-DETR XL and 2XL under Roboflow's Platform Model License, excluded | Field-of-use terms would compromise in-Kingdom weight ownership |
| Inference node | 48 GB PCIe GPU class (L40S class), air-cooled, in the sovereign facility | Footprint rule: combined weights under 0.55 GB leave batch and cache headroom |
| Positioning | RTKLIB class GNSS with optional site base station, field tablets at 3 to 5 m grade | Arrival coordinate checked against the flagged polygon, so phantom visits file as not-reached |
| Optical sensing | Sentinel-2 multispectral, 10 m, 5-day revisit | Resolves center pivots for crop class without a foreign processing dependency |
| Radar sensing | Sentinel-1 C-band SAR | Cloud-proof complement; dust and haze, not cloud, are the optical channel's real attacker |
| Archive sensing | Landsat 8/9, 8-day combined, archive reaching back decades | History for per-parcel baseline series |
| Cloud evidence | Sentinel-2 scene classification and cloud probability layer | Treated as evidence, not truth, in the screening rule |
| Aerial sensing | national aerial survey products | Rounds over the sedimentary shelf, matching the operator's existing method |
| Field truth | GNSS field tablets on inspector visits | Confirmed and refuted visits become the labelled corpus for each season's retraining |
| Pattern: triage | Per-parcel signature time series with traffic-light triage | Only the flagged minority reaches a human inspector |

PART III · CHAPTER 9

## Shadow Rounds Come Before Any Flag Is Trusted

Three phases with sixteen items gate on the register join, the inspector verification pack and the Kingdom-wide shelf rollout, and shadow rounds precede any trusted flag.

Chapter 8 fixed the two models, their Apache-2.0 licenses and the inference node class that holds them inside the operator's facility. This chapter fixes the order in which the system earns the right to raise a flag that carries a penalty: the register join first, the inspector verification pack second, the shelf-wide rollout last.

### 9.1  Three Phases, Sixteen Items, Three Gates

Figure 8 shows the rollout as three phases carrying sixteen items in total, each phase closing on a gate that can stop the work cheaply, and no phase carrying a duration. Phase 1 carries six items across three workstreams, imagery and detection, register and license data, and sovereignty and governance, including the sedimentary shelf ontology build, the register and license join, and the imagery baseline and STAC catalog. Its exit gate is the register and license join itself, because no detection can be checked against a license until holdings, pivots and licenses resolve to one key. Phase 2 carries seven items across field verification and cases, imagery and detection, and reporting and delivery, including the cloud, haze and artifact screening, the detection-to-case workflow, and the inspector field verification pack, which is its exit gate. Phase 3 carries three items, the fuel and electricity linkage extracts, the Kingdom rollout across the shelf regions, and the contract end handover and exit pack, and its gate is the Kingdom rollout itself. Requirement coverage closes at two requirements covered, none partial and none open, so every requirement the notice states traces to named items and gates in Figure 8.

![Figure 8. The three phases and their gates, and coverage of the 2 requirements across them.](figures/figure_08.png)

Figure 8. The three phases and their gates, and coverage of the 2 requirements across them.

### 9.2  What the Rollout Measures

The rollout measures detection quality as two numbers published separately, producer's accuracy and user's accuracy, and user's accuracy against an independent reference sample gates each phase transition, because a flag is an accusation against a named farm and the operator's published penalty is SAR 4,000 per hectare per year, doubling on repeat. It measures area as error-adjusted hectares rather than raw pixel counts, corroboration as the share of flags supported by two consecutive screened observations or a second sensor, and visit integrity as the share of arrival coordinates that fall inside the flagged polygon's buffer, with the rest filed as not reached. It measures triage discipline as the distribution of flags across the eight status values from raised to unresolved, and model health as per-region validation against inspector ground truth each season, with rollback rehearsed in phase 1 before any version serves.

### 9.3  Failure Modes

Table 5 lists what fails and what the design does about it; each row is a recorded risk in this domain, not a hypothetical.

Table 5 · Failure Modes

| What fails | What the design does |
| --- | --- |
| Imagery supply is unresolved: the notice is silent on whether the service consumes the operator's and national imagery products or brings its own imagery | One abstracted imagery source behind a single adapter, archive mirror, national imagery delivery or supplier tasking, settled in the phase 1 imagery commissioning before the prototype trains |
| A false positive is a SAR 4,000 per hectare accusation, and about a quarter of individually mapped parcels were wrong in the closest published precedent even when the regional total looked right | Producer's and user's accuracy published separately, user's accuracy gating the rollout, every reported area error adjusted, and two consecutive screened observations or a second sensor required before a flag leaves the pipeline |
| Field boundary geometry is wrong or missing, yet geometry is the legal source of the area a penalty is computed on | Boundary capture treated as a funded project item reconciled against register geometry, register geometry kept authoritative, each boundary's source and capture date recorded |
| Dust and haze, not cloud, are the optical channel's real attacker over the shelf, and a masked pixel is not a clean absence | Sentinel-1 radar as the cloud-proof complement, the scene classification layer treated as evidence rather than truth, and the two-observation corroboration rule |
| Revisit cadence and coverage are not stated in the notice, which changes tasking budget, storage sizing and how fast a violation becomes a case | A revisit and coverage schedule per region agreed with the operator in phase 2, with commercial tasking quotas metered where confirmation imagery is bought |
| A classifier trained on one region's pivots and seasons fails on another's, and drifts as the roster of satellites and seasons changes | Per-region validation against inspector ground truth each season, versioned models with rollback rehearsed in phase 1, and a named retraining cadence owned by the operator after handover |

### 9.4  Lessons

**Shadow the flags before anyone trusts them.** Every flag runs the full pipeline and the case workflow in shadow, triaged and dispatched but carrying no weight, until the inspector verification pack passes its gate; the first trusted flag is earned, never switched on. Publish accuracy as two numbers, never one. Producer's accuracy flatters a system that finds most violations but accuses the wrong farms, so user's accuracy, the share of flags that survive a visit, is the number that gates the rollout. A masked pixel is not a clean absence. Dust and haze remove evidence rather than create it, which is why the radar channel and the corroboration rule exist before the first flag is raised. Ground truth comes from visits, and visits are the hard part. Earth observation for agriculture is bottlenecked by field data because on-site observations remain difficult to obtain and reuse (ESA 2026), which is why the GNSS arrival check and the not-reached filing are first-class items, not afterthoughts.

### 9.5  What Is Still Open

Three questions remain open. The imagery sourcing question, whether the service consumes the operator's and national imagery products or procures its own, changes the adapter configuration and the tasking budget, and settling it in the phase 1 commissioning locks both. The revisit and coverage question per region changes storage sizing and how fast a violation becomes a case. The work surface question, whether the operator takes the agent-building surface, changes whether a language model enters the register and a serving tier is sized; until then the design keeps that tier open and ships nothing that depends on it.

PART III · CHAPTER 10

## The Ontology and the Weights Stay with the Operator

The object model, the fine-tuned weights, the decision record and the boundary stay with the operator that produced the evidence.

Chapter 9 set the gates the system passes before any flag is trusted. This chapter states who holds what the design builds once those gates are behind it: the answer is the operator, on every layer that matters.

### 10.1  What the Operator Owns

The object model is the operator's: the fourteen objects, from farm holding through crop license and detection flag to violation case file, with their typed links, stay with the operator as its own model of holdings, licenses and cases, anchored in the register and the geospatial databases and extended only through the single write path. The weights are the operator's: the fine-tuned RF-DETR checkpoints carry Apache-2.0 terms with no field-of-use restriction on the Nano-to-Large detection checkpoints, so the per-region fine-tunes and their rollback targets are held outright, alongside the Chronos-2 weights used for the per-parcel index series, all inside the Kingdom. The decision record is the operator's: every flag's status from raised through confirmed, refuted or artifact, and every case file with its evidence pack reference, hectares measured and referred date, is kept as a record the next season's triage reads. The boundary is the operator's: everything runs inside the operator's own facility, the register and the license records are read through scheduled read-only extracts, imagery is mirrored rather than processed abroad, and identity is held on site in Keycloak.

### 10.2  The Offer Behind the Design

This design is produced on Praxis, CodeNinja's platform for designing physical AI systems, and it maps to CodeNinja's offer where the matching element exists. The satellite, aerial and GNSS sensing with detection and forecasting of physical behavior across the shelf regions is Adaptive Operations; the triage that ranks the flagged minority for a named inspector to decide is Decision Systems; the fourteen-object model of holdings, licenses, flags and cases is Hyper Ontology; the kept record of decisions and outcomes, the flag lifecycle and the verified case files, that the next season's triage reads is Hyper Engram, an agentic memory that informs the next decision without touching model weights; and the open-weight Apache-2.0 licenses held on the operator's own hardware inside the Kingdom are Sovereign Infrastructure.

PART IV · CONCLUSION

## The Same Shape Watches Any Regulated Ground

Fodder Watch is a sovereign monitoring service that joins a register and license records to mirrored Sentinel and Landsat imagery through one ontology of fourteen objects, screens every parcel with per-parcel index series and a detector fine-tune, escalates only the flagged minority to a human inspector, and ends in verified case files the operator enforces under its own published policy of SAR 4,000 per hectare per year, doubling on repeat, all inside the Kingdom.

Any regulator that holds a register, a license rule and revisitable imagery over its ground can run the same shape: the work is the join, the per-parcel time series and the accuracy gate that separates a real change from a cloud, a dust event or an artefact, not the satellites themselves.

PART IV · CHAPTER 11

## Every Choice Traces Back to a Recorded Reading

Praxis recorded the ask, the eight lenses, the patterns adopted and set aside, and the equipment classes behind every choice in this design.

Chapter 10 placed the ontology, the weights, the decision record and the boundary in the operator's hands. This closing chapter shows how the design itself was reasoned, so that any choice in the preceding chapters traces back to what justified it. Every design in this series is produced on Praxis, the design team platform for designing physical AI systems, and this chapter is the audit trail: the ask as recorded, the lenses consulted, the patterns adopted and set aside, and the equipment classes the reasoning landed on. Figure 9 shows how Praxis reasoned this design end to end.

### 11.1  Contextualizing the Ask

The ask, in the operator's own published words, is monitoring services for restricted crops, to reduce liquid fuel consumption by unlicensed agricultural activities. Praxis assigned it to the regulatory monitoring family in the agriculture and earth observation industry, a problem class where the evidence a penalty rests on must survive appeal. In the room were the verbatim public notice fields as recorded on the government procurement portal, and the issuer's own published policy facts that define the monitoring problem: the green fodder ban and the council resolutions behind it, the resolution that fixes crop licenses by region, coordinates, area and crop type, the published penalty basis of SAR 4,000 per hectare per year doubling on repeat, and the obligations that tie fuel and electricity services for agricultural activity to a valid register and license. Each record was read in full and is available on request; the priced booklet sits behind supplier registration, so the design was built to survive the open questions only it answers.

![Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.](figures/figure_09.png)

Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.

### 11.2  The Lenses

Table 6 lists the eight lenses Praxis read the ask through, what each could see, what it cited, and what it contributed; the history lens returned nothing usable in the recorded room and is shown as a gap.

Table 6 · The Lenses and What They Contributed

| Lens | Could see | Cited | What it contributed |
| --- | --- | --- | --- |
| First principles | The minimum evidence a penalty-grade accusation needs: a license to check against, a measured area, a change corroborated in time or in sensor | Not cited externally | The license-check join, the two-observation corroboration rule and the error-adjusted area |
| Case studies | How agro-geoinformatics integrates earth observation into agricultural management at scale, and why it matters for resource control | (ScienceDirect n.d.) | The per-parcel time series framing and the detection-to-case workflow |
| Tooling and recency | Current choices for streaming, the ontology store, registries, identity and observability | Not cited externally | Kafka with KRaft, the Hyper Ontology v0.9 store, Harbor, Keycloak and the Prometheus, Grafana and Loki stack |
| Hardware and equipment | What compute the pipeline needs and, as importantly, what it does not | Not cited externally | The 48 GB PCIe inference node class, and the ruling out of every field and edge hardware class |
| Rules and regulations | The resolutions and license regime that define the three violator classes | Not cited externally | The green fodder ban control and crop license objects, and the penalty basis the case files carry |
| Approach | Why field data, not satellites, bottlenecks agricultural earth observation | (ESA 2026) | The inspector verification pack and the GNSS arrival check as first-class items |
| History | Prior monitoring rounds and their records | Gap | Flagged as a gap: whether prior rounds' records exist to seed the baseline is carried as an open item |
| Domain fusion | Where remote sensing meets enforcement practice on one working surface | (ScienceDirect n.d.) | Fusing imagery signals with register, license and visit evidence into one ontology rather than an image catalog |

### 11.3  Patterns Adopted and Set Aside

The design adopted per-parcel signature time series with traffic-light triage, so only the flagged minority reaches a human, over a photo-interpretation desk reviewing scenes farm by farm: the closest published precedent measured that automated screening moves inspection from a sample to the whole population while flagging only a small minority of parcels, which is an operating cost a human desk cannot match. It adopted a free Sentinel-2, Sentinel-1 and Landsat baseline mirrored in-Kingdom, with commercial tasking bought per confirmation need, over commercial tasking as the backbone. It set aside farm-side hardware, edge serving and pivot control entirely, because the estate is watched from orbit and by aerial survey. It set aside a frontier language model serving tier, because the work surface is offered rather than committed and no language model is in this run's register; the tier opens only if the unlock question is answered.

### 11.4  Where the Reasoning Lands

The reasoning lands on equipment classes, not part numbers: the 48 GB PCIe inference GPU class, air-cooled in the operator's facility, holding the detector fine-tune and the forecaster side by side with real KV headroom; the GNSS positioning class for inspector tablets at field grade, with an optional base station; the lightweight Kubernetes-class container orchestration; the columnar time-series store class for per-pivot index series; and the open labelling-tool class that turns inspector-confirmed and refuted visits into the corpus that retrains the detector each season. Everything shown in this chapter was recorded reading: the ask, the room, the lenses, the patterns and the classes were noted as they were read, and nothing is inferred.

Appendix A

## What Ownership Costs Over Three Years

The design runs both of its models, the RF-DETR detector and the Chronos-2 forecaster, on one 48 GB L40S-class inference node in the operator's own facility inside the Kingdom. This appendix prices that node against renting the same card from a cloud region. Every input is a public price, dated and cited, and the arithmetic is shown so any reader can rerun it with a written quote. A closed model priced by the token is not compared, because neither model is a language model and no hosted service offers this detector and forecaster pair.

### A.1 The Answer

Owning the inference node costs about **15,200 US dollars over three years**, inside a range of 14,600 to 15,800. Renting one L40S card around the clock costs **22,600 to 60,000 dollars** over the same period. Against the deepest three-year commitment listed (AWS, three-year EC2 Instance Savings Plan, all upfront, in the UAE region), ownership is **about two thirds** the cost. No rented option can sit inside the Kingdom today: AWS's Saudi region opens in December 2026 (Channel Insider 2026), and every option below would move imagery, register data and detections across the border, which the design's sovereignty constraint rules out.

### A.2 What Owning Costs

| Line | Basis | Three-year cost (USD) |
| --- | --- | --- |
| Inference node | One L40S-class card with its share of host, memory and power supply, priced as one eighth of an eight-card L40S server at 85,271 dollars (Newegg 2026); the card alone lists at 7,709 dollars (esaitech 2026) | 10,700 |
| Support | 8 to 12 percent of hardware value a year (Introl 2026) | 2,600 to 3,800 |
| Power | 0.6 kW average draw for the card and its host share (an assumption: the L40S is rated at 350 W) at a power usage effectiveness of 1.6 (Uptime Institute 2025), 25,229 kWh at the industrial tariff of 0.20 riyals per kWh (ECRA 2025) at 3.75 riyals to the dollar | 1,300 |
| **Total** |  | **14,600 to 15,800, typical 15,200** |

One card is enough because the two models together hold about 0.55 GB of weights (Table 4); the 48 GB class leaves room for batching every parcel in a screening round.

### A.3 What Renting Costs

The same card, rented without a break for three years, because screening rounds follow the imagery and the season, not office hours.

| Option | Basis | Three-year cost (USD) |
| --- | --- | --- |
| AWS, UAE region, on demand | g6e.xlarge, one L40S, at 2.283 dollars an hour in me-central-1 (AWS 2026a); outside the Kingdom | 60,000 |
| AWS, UAE region, three-year EC2 Instance Savings Plan, all upfront | g6e.xlarge at 0.858 dollars an hour, the deepest three-year plan in the region (AWS 2026b); outside the Kingdom | 22,600 |
| Specialist GPU cloud, on demand | 18.00 dollars an hour for eight L40S cards, 2.25 per card (CoreWeave 2026); outside the Kingdom | 59,100 |

Egress, storage of the mirrored archive and the network link to the region are excluded, so every rented figure is a floor.

### A.4 What the Price Does Not Include

- **An export licence.** The L40S is an advanced computing item under ECCN 3A090, and its export to Saudi Arabia needs a licence from the Bureau of Industry and Security (NVIDIA 2023; eCFR 2026), granted case by case. The order date for the node is therefore a phase one checkpoint on the licence timeline.
- **The imagery itself**: Sentinel-2, Sentinel-1 and Landsat are free; commercial confirmation tasking is bought per need and priced by the supplier.
- **Field tablets and GNSS equipment** for inspectors, which the operator already issues.
- **Customs duty and 15 percent VAT** on the hardware, which a written quote delivered to the Kingdom settles.
- **People, facilities and implementation**, which both sides carry.

### A.5 Sources for This Appendix

- AWS. 2026a. Amazon EC2 on-demand prices, Middle East (UAE), Linux, g6e.xlarge. <https://aws.amazon.com/ec2/pricing/on-demand/>
- AWS. 2026b. EC2 Instance Savings Plans price file, me-central-1, version 20261005200132. <https://pricing.us-east-1.amazonaws.com/savingsPlan/v1.0/aws/AWSComputeSavingsPlan/current/region_index.json>
- Channel Insider. 2026. AWS cloud region launch, Saudi Arabia. <https://www.channelinsider.com/infrastructure/news-aws-cloud-region-launch-emea-saudi-arabia/>
- CoreWeave. 2026. Pricing. <https://www.coreweave.com/pricing>
- eCFR. 2026. 15 CFR Part 740, Supplement No. 1, Country Groups. <https://www.ecfr.gov/current/title-15/part-740/appendix-Supplement%20No.%201%20to%20Part%20740>
- ECRA. 2025. Electricity tariff, effective 28 May 2025, as reported. <https://clenergize.com/ksa-electricity-tariff-changes-in-2025-is-your-business-ready/>
- esaitech. 2026. PNY NVIDIA L40S 48 GB GDDR6 PCIe. <https://esaitech.com/products/pny-technologies-nvl40stcgpu-kit-nvidia-l40s-4-port-48gb-gddr6-graphic-card>
- Introl. 2026. GPU infrastructure TCO model. <https://introl.com/blog/gpu-infrastructure-tco-model-5-year-enterprise-ai-deployment>
- Newegg. 2026. Supermicro SYS-421GE-TNRT-02-G1. <https://www.newegg.com/p/N82E16859152404>
- NVIDIA. 2023. Form 8-K, 17 October 2023. <https://www.sec.gov/Archives/edgar/data/1045810/000104581023000217/nvda-20231017.htm>
- Uptime Institute. 2025. Global Data Center Survey 2025. <https://uptimeinstitute.com>

SOURCES

## Source Register

ESA. 2026. Earth observation for agriculture requires more than. <https://sciencehub.esa.int/2026/06/04/earth-observation-for-agriculture%F0%9F%8C%B1-requires-more-than-satellites>

ScienceDirect. n.d.. Empowering agro-geoinformatics with earth observation. <https://www.sciencedirect.com/science/article/pii/S0168169925014541>

---

### About CodeNinja

CodeNinja is a Middle Eastern-American artificial intelligence lab focused on building self-improving systems. We are reinventing knowledge work to close the loop between vertical AI use cases and the generalized intelligence that fuels it, accelerating the path toward organizational superintelligence.


---

# Physical AI for agriculture and earth observation: questions answered

Canonical: https://codeatoms.ai/sectors/agriculture-and-earth-observation/
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai)

Farms, irrigation and land use are watched by sensors, satellites and aircraft, but the readings, the licences and the field records usually sit in separate systems.

## What does a physical AI system for agriculture and earth observation look like?

A complete physical AI design for agriculture and earth observation names what to sense, which existing systems to join, the object model that joins them, the models and hardware, the three-year cost and the person who approves every action. CodeNinja Atoms has published 3 such reference architectures for agriculture and earth observation, each free to reuse under CC BY 4.0. Field Ledger (Pakistan): one dashboard that joins a farm's live sensor feeds, its historical datasets and a big data and analytics repository into one object model, so any farm, crop cycle or season can be drilled into, exported and reported on under role-based access. Baseline (United States): one summer flight of 3-inch 4-band orthoimagery and USGS Quality Level 1 LiDAR, with every tile, point cloud and elevation model bound into a site ontology, so the next season starts from a comparison instead of rediscovery. Fodder Watch (Saudi Arabia): an 18-month earth observation service that screens every parcel for restricted green fodder and cultivation beyond the licensed area, checks each detection against the holding's licence, and turns the confirmed ones into case files an inspector can act on.

## Which AI models can an agriculture and earth observation operator run on its own hardware?

Each published agriculture and earth observation design names its models and why, and every model is open-weight or no model is used at all, so the operator can run it on hardware it owns. Field Ledger: None: the analytics are deterministic aggregations, drill-down and reporting. Baseline: None: vegetation analysis stays with the operator's own analysts. Fodder Watch: RF-DETR fine-tuned per region and Chronos-2 zero-shot, both Apache-2.0, about 0.55 GB of weights together.

## How much compute and hardware does AI in agriculture and earth observation need?

The compute follows from the models: the published agriculture and earth observation designs size it as follows, from no new hardware to a full GPU node. Field Ledger, stack: Open-source PostgreSQL with PostGIS on the operator's own servers; source code and full intellectual property handed over. Baseline, ground: The operator's ArcGIS Enterprise; nothing runs in a cloud the operator does not control. Baseline, acquisition: One manned flight within a week either side of 1 July; 3-inch 4-band (red, green, blue, near infrared) orthoimagery and Quality Level 1 LiDAR at a minimum of 8 pulses per square meter. Fodder Watch, compute: One 48 GB L40S-class inference node inside the Kingdom; the card class needs a US export licence.

## Is it cheaper to own AI hardware or rent cloud GPUs in agriculture and earth observation?

Each agriculture and earth observation design prices three years of ownership in its Appendix A, with every price cited, against renting the same capacity from a cloud region at its deepest three-year commitment where hardware is bought. Field Ledger: three-year cost, No hardware line to price: the cost is the integration and software work (Appendix A). Baseline: three-year cost, No compute to price; the acquisition is priced by the survey firm against the operator's own task table (Appendix A). Fodder Watch: three-year cost, About 15,200 dollars to own the node, about two thirds the deepest three-year AWS commitment, and renting would move the data outside the Kingdom (Appendix A).

## What ontology or object model does an agriculture and earth observation AI system need?

The object model is the part that makes the system an ontology rather than a pipeline: typed objects for the things in the agriculture and earth observation operation, with properties, status values and typed links. Every published design ships its object model as hyper-ontology/1 JSON that loads into Hyper Ontology. Field Ledger: The site, The field, Crop Cycle, Sensor Device, Sensor Reading, Historical Dataset, Publication, Dashboard User, Access Role, Alert, Report, Data Source Connection. Baseline: The site, The unit, Watercourse, Dam, Flight Mission, 4-Band Aerial Camera System, QL1 LiDAR Sensor System, GNSS/IMU Georeferencing Chain, Multispectral Orthoimagery Product, Classified LAS Point Cloud, Bare-Earth and Highest-Hit DEMs, QA/QC Accuracy Report, Professional Services Agreement, Monthly Itemized Invoice, Contractor Project Manager, Operator Project Manager. Fodder Watch: Farm holding, Centre pivot / cultivated field, Farm enterprise / large farmer, Crop licence (wheat / seasonal fodder), Water source (well) use licence, Green fodder ban control, Agricultural fuel / electricity service condition record, Imagery tasking order, Satellite image capture, Processed imagery product, Restricted-crop detection flag, Violation case file, Field inspector, Restricted-crop classifier.

## Who approves the decisions an AI system makes in agriculture and earth observation?

In every published agriculture and earth observation design a named person makes the decision that changes the physical world; the system prepares it. Field Ledger: Every alert is acknowledged by a named user under a role the operator assigns. Baseline: The operator's project manager accepts each deliverable against the QA/QC accuracy report. Fodder Watch: Every flag is verified on the ground by a named field inspector before a case file opens.

## Sources

- [Field Ledger: An Open Source Agriculture Data Dashboard the Operator Fully Owns](https://codeatoms.ai/farm-data-dashboard-pakistan/) (Pakistan), DOI https://doi.org/10.5281/zenodo.23186671
- [Baseline: One Flight of 4 Band Orthoimagery and LiDAR for Vegetation Mapping](https://codeatoms.ai/vegetation-mapping-lidar-us/) (United States), DOI https://doi.org/10.5281/zenodo.23186673
- [Fodder Watch: Earth Observation That Turns Restricted-Crop Detections Into Enforceable Case Files](https://codeatoms.ai/restricted-crop-monitoring-saudi-arabia/) (Saudi Arabia), DOI https://doi.org/10.5281/zenodo.23186675


---

# Physical AI for energy and utilities: questions answered

Canonical: https://codeatoms.ai/sectors/energy-and-utilities/
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai)

Grids and plants run on control systems, maintenance records and field crews that were never designed to share one picture of risk.

## What does a physical AI system for energy and utilities look like?

A complete physical AI design for energy and utilities names what to sense, which existing systems to join, the object model that joins them, the models and hardware, the three-year cost and the person who approves every action. CodeNinja Atoms has published 3 such reference architectures for energy and utilities, each free to reuse under CC BY 4.0. Grid Context Watch (United States): one system of context that sees every device on a utility's control networks, flags abnormal behaviour and assembles the evidence a NERC CIP audit asks for, on the operator's own hardware. Reliability Atlas (Saudi Arabia): a records-based reliability and availability assessment that joins each plant's work orders, trip history and design documents into one reliability object model the operator owns, so every availability figure, criticality rank and root cause finding traces to its source. Feeder Firewatch (United States): a live ignition and outage risk score for every distribution feeder segment, built on the cooperative's own hardware, with every de-energisation and fast-trip change approved by a named operator.

## Which AI models can an energy and utilities operator run on its own hardware?

Each published energy and utilities design names its models and why, and every model is open-weight or no model is used at all, so the operator can run it on hardware it owns. Grid Context Watch: GLM 5.2 (MIT) for reasoning and Qwen3-Embedding-0.6B (Apache-2.0) for retrieval; detection stays in the procured sensors. Reliability Atlas: None: the register is empty by design because no inference workload is contracted. Feeder Firewatch: Self-hosted open-weight models: GLM 5.2 under MIT (reasoning) on site, RF-DETR (vision) at the edge.

## How much compute and hardware does AI in energy and utilities need?

The compute follows from the models: the published energy and utilities designs size it as follows, from no new hardware to a full GPU node. Grid Context Watch, compute: One node of eight 141 GB HBM-class GPUs: 753 GB of FP8 weights, 904 GB with the 1.2 planning factor, against 1,128 GB. Grid Context Watch, boundary: Read only and one way out of the control networks; nothing writes into an electronic security perimeter, and no data leaves the operator. Reliability Atlas, compute: No hardware bought; the study runs on the operator's own in-country servers. Feeder Firewatch, frontier compute: One node of eight 141 GB HBM-class GPUs holds GLM 5.2 at FP8 (753 GB of weights, 904 GB with headroom). Feeder Firewatch, edge: Sealed industrial boxes at substations and on patrol trucks detect smoke and damaged equipment when cellular coverage drops.

## Is it cheaper to own AI hardware or rent cloud GPUs in energy and utilities?

Each energy and utilities design prices three years of ownership in its Appendix A, with every price cited, against renting the same capacity from a cloud region at its deepest three-year commitment where hardware is bought. Grid Context Watch: three-year cost, About 510,000 dollars to own the reasoning node, about four fifths the deepest three-year AWS commitment (Appendix A). Reliability Atlas: three-year cost, No hardware line to price: the cost is the assessment work itself (Appendix A). Feeder Firewatch: three-year cost, owned, About 841,000 US dollars with support and power at the Texas industrial power price; three-year cost, rented, 0.88 million to 1.92 million US dollars for the same GPUs around the clock; ownership costs about the same as the deepest three-year commitment (version 2); closed model break-even, The cheapest closed model matches the owned stack at about 41 users; above that, ownership is cheaper and the gap grows with every user.

## What ontology or object model does an energy and utilities AI system need?

The object model is the part that makes the system an ontology rather than a pipeline: typed objects for the things in the energy and utilities operation, with properties, status values and typed links. Every published design ships its object model as hyper-ontology/1 JSON that loads into Hyper Ontology. Grid Context Watch: Substation, OT Asset, Network Sensor, Anomaly Alert, Investigation Case, Vulnerability Finding, Detection Rule, Threat Intelligence Item, Pcap Evidence Record, CIP Evidence Artefact, OT Security Analyst, SIEM, Energy management system, Substation data platform. Reliability Atlas: Plant, Production train, Equipment, Failure mode, Work order, Downtime event, Availability prediction, Availability target, Criticality index, RCA report, Major event, Spare part, Reliability program. Feeder Firewatch: Substation, Feeder, Feeder segment, Pole, Recloser, Meter, Pole inspection record, Outage event, Feeder segment ignition risk score, Red flag warning, Wildfire camera station, Field crew, Work order, PSPS decision record.

## Who approves the decisions an AI system makes in energy and utilities?

In every published energy and utilities design a named person makes the decision that changes the physical world; the system prepares it. Grid Context Watch: Every triage, case and risk acceptance carries a named OT security analyst; agents draft, the analyst decides. Reliability Atlas: Predictions are accepted only by a named reviewer and RCA reports validated only by a named engineer. Feeder Firewatch: Every public safety power shutoff (PSPS) recommendation becomes a decision record a named operator approves or declines; the design never opens or closes a recloser.

## Sources

- [Grid Context Watch: One system of context for OT Security and NERC CIP Evidence](https://codeatoms.ai/ot-security-cip-evidence-us/) (United States), DOI https://doi.org/10.5281/zenodo.23157957
- [Reliability Atlas: A Plant Reliability Assessment Study the Operator Can Audit](https://codeatoms.ai/plant-reliability-assessment-saudi-arabia/) (Saudi Arabia), DOI https://doi.org/10.5281/zenodo.23157965
- [Feeder Firewatch: Live Ignition and Outage Risk for Every Distribution Feeder](https://codeatoms.ai/wildfire-risk-distribution-us/) (United States), DOI https://doi.org/10.5281/zenodo.23159328


---

# Physical AI for heavy industry and construction: questions answered

Canonical: https://codeatoms.ai/sectors/heavy-industry-and-construction/
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai)

Mills, factories and building sites produce counts, alarms and progress data in many systems, and each one sees only part of the operation.

## What does a physical AI system for heavy industry and construction look like?

A complete physical AI design for heavy industry and construction names what to sense, which existing systems to join, the object model that joins them, the models and hardware, the three-year cost and the person who approves every action. CodeNinja Atoms has published 3 such reference architectures for heavy industry and construction, each free to reuse under CC BY 4.0. Structure Phase Watch (Saudi Arabia): one live model of a construction site's structure phase that forecasts schedule slips three days out and shows safety breaches as they happen, on the contractor's own hardware inside the Kingdom. Steel Count Ledger (Pakistan): cameras and a GPU industrial PC at every casting strand and cooling bed count billets, ingots, rebars and girders as they are made, publish the counts through a one-way link into one record the authority owns, and let revenue officers reconcile counted against declared production. Factory Fire Watch (Saudi Arabia): live, read-only visibility of fire alarm panels, fire pumps, fire water tanks and energy meters across an operator's highest-risk factories, read through contacts, PLC inputs and LoRaWAN into an IoT platform hosted in Saudi Arabia, with never a write path into certified life-safety equipment.

## Which AI models can a heavy industry and construction operator run on its own hardware?

Each published heavy industry and construction design names its models and why, and every model is open-weight or no model is used at all, so the operator can run it on hardware it owns. Structure Phase Watch: 5 self-hosted open models: GLM 5.3 (reasoning), Chronos-2 (forecasting), BGE-M3 (multilingual retrieval), RF-DETR (vision), Roboflow trackers. Steel Count Ledger: 3 self-hosted open models: RF-DETR (detection, fine-tuned per product type and mill), Roboflow trackers (identity across camera fields), GLM 5.3 (compliance work surface). Factory Fire Watch: One: IBM Granite Tiny Time Mixers (TTM-R2), about 0.85 million parameters, Apache-2.0, on CPU inside the platform; threshold evaluation on the safety path is rule logic.

## How much compute and hardware does AI in heavy industry and construction need?

The compute follows from the models: the published heavy industry and construction designs size it as follows, from no new hardware to a full GPU node. Structure Phase Watch, frontier compute: One node of eight 141 GB HBM-class GPUs holds GLM 5.3 at FP8 (753 GB of weights, 904 GB with headroom). Structure Phase Watch, edge: Five Jetson Orin class nodes in solar powered enclosures at the gate, laydown, crane slew zone, batch plant and haul road. Steel Count Ledger, frontier compute: One node of eight 141 GB HBM-class GPUs holds GLM 5.3 at FP8 (753 GB of weights, 904 GB with headroom), in a dedicated data center behind an export licence checkpoint. Steel Count Ledger, edge: One sealed GPU industrial PC and IP66 HDR cameras per installation point; counting survives a slow wide-area link. Steel Count Ledger, the hard dependency: 141 GB-class accelerators need a US export licence for Pakistan (Country Group D:4); the node is ordered only once a licence naming the end user holds. Factory Fire Watch, compute: None bought: the requirement asks for no server or GPU, and the field gateways carry no model runtime. Factory Fire Watch, equipment, per factory: About 2,600 to 3,200 US dollars in list prices: a LoRaWAN gateway, two tank transmitters, two CT meters, four contact nodes, a switch, an enclosure and a UPS.

## Is it cheaper to own AI hardware or rent cloud GPUs in heavy industry and construction?

Each heavy industry and construction design prices three years of ownership in its Appendix A, with every price cited, against renting the same capacity from a cloud region at its deepest three-year commitment where hardware is bought. Structure Phase Watch: three-year cost, owned, About 642,000 US dollars with support and power at the Saudi industrial tariff; three-year cost, rented, 1.41 million to 2.81 million US dollars for the same GPUs around the clock; ownership is about one half the cheapest three-year commitment; closed model break-even, The cheapest closed model matches the owned stack at about 31 users; above that, ownership is cheaper and the gap grows with every user. Steel Count Ledger: three-year cost, owned, About 4,445,000 US dollars for 300 installation points, of which the counting kits are 2,832,000 and cannot be rented; owning the frontier node costs about 686,000 against 751,000 on AWS's deepest three-year plan; closed model break-even, The cheapest closed model matches the owned node at about 33 users; above that, ownership is cheaper. Factory Fire Watch: three-year cost, 100 factories, About 328,000 to 439,000 US dollars with support and power; the eight-factory pilot is about 21,000 to 26,000 of equipment.

## What ontology or object model does a heavy industry and construction AI system need?

The object model is the part that makes the system an ontology rather than a pipeline: typed objects for the things in the heavy industry and construction operation, with properties, status values and typed links. Every published design ships its object model as hyper-ontology/1 JSON that loads into Hyper Ontology. Structure Phase Watch: Tower crane (TC-01 to TC-14), Crawler crane (6 units), Casting bed, Precast unit, Flatbed or mixer truck, Batch ticket, P6 activity (owner baseline or fragnet), Permit to work, Incident or observation form, Gate movement, Delivery window, Lift schedule entry, Pour, Worker, Work zone (Zone A to D). Steel Count Ledger: Steel melting and re-rolling unit, Installation point, Industrial PC, Production count event, Product type (Billets, Ingots, Rebars, Girders), Declared production, Discrepancy case, Revenue field officer, Audit team, Steel mill staff, Tamper or offline alert, Daily uptime record, Product calibration record, Weighbridge record. Factory Fire Watch: High-risk factory, Fire alarm control panel, Fire pump, Fire water tank, Tank level transmitter, Energy meter (CT set), LoRaWAN gateway, Monitored point, Safety-critical alert, Audit log record, Periodic monitoring round, Preventive maintenance visit, Technical personnel, Monitoring officer.

## Who approves the decisions an AI system makes in heavy industry and construction?

In every published heavy industry and construction design a named person makes the decision that changes the physical world; the system prepares it. Structure Phase Watch: Every re-sequencing is a recommendation a named planner approves; every breach alert is confirmed, dismissed or escalated by the HSE officer. Steel Count Ledger: Every discrepancy case is judged by a named revenue field officer; the system counts and reconciles, it never assesses, and the mill never edits a count. Factory Fire Watch: A monitoring officer acknowledges or escalates every safety-critical alert; the design monitors and never controls a panel, pump or valve.

## Sources

- [Structure Phase Watch: Live Production, Crane and Delivery Evidence for Every Pour on a Construction Site](https://codeatoms.ai/structure-phase-construction-saudi-arabia/) (Saudi Arabia), DOI https://doi.org/10.5281/zenodo.23126448
- [Steel Count Ledger: Independently Counted Production for Every Steel Mill in Pakistan](https://codeatoms.ai/steel-production-count-pakistan/) (Pakistan), DOI https://doi.org/10.5281/zenodo.23126563
- [Factory Fire Watch: Read-Only Smart Fire Protection Monitoring for Every High-Risk Factory](https://codeatoms.ai/factory-fire-monitoring-saudi-arabia/) (Saudi Arabia), DOI https://doi.org/10.5281/zenodo.23126565


---

# Physical AI for maritime and ports: questions answered

Canonical: https://codeatoms.ai/sectors/maritime-and-ports/
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai)

Terminals and port authorities run gates, cranes, yards and finance on separate systems, so nobody sees the whole flow of a box or a truck.

## What does a physical AI system for maritime and ports look like?

A complete physical AI design for maritime and ports names what to sense, which existing systems to join, the object model that joins them, the models and hardware, the three-year cost and the person who approves every action. CodeNinja Atoms has published 2 such reference architectures for maritime and ports, each free to reuse under CC BY 4.0. Port Twin (United States): one authoritative digital twin that binds a port's operational systems, live sensor feeds and finance backbone into a thirteen-object ontology, self-hosted on the port's own virtual machines inside the continental United States. Terminal Pulse (United States): truck turn time predicted two hours out and yard congestion seen live, at a container terminal, on the operator's own hardware with no outbound connection.

## Which AI models can a maritime and ports operator run on its own hardware?

Each published maritime and ports design names its models and why, and every model is open-weight or no model is used at all, so the operator can run it on hardware it owns. Port Twin: One self-hosted open model, BGE-M3, for document retrieval; no generative model and no token stream. Terminal Pulse: 5 self-hosted open models: GLM 5.3 (reasoning), Chronos-2 (forecasting), Qwen3-Embedding-0.6B (retrieval), RF-DETR (vision), Roboflow trackers.

## How much compute and hardware does AI in maritime and ports need?

The compute follows from the models: the published maritime and ports designs size it as follows, from no new hardware to a full GPU node. Port Twin, compute: No equipment bought: about 1.1 GB of fp16 weights on the port's existing enterprise virtual machines. Port Twin, boundary: Everything runs inside the continental United States on infrastructure the port already operates; no hosted document AI service in the path. Terminal Pulse, frontier compute: One node of eight 141 GB HBM-class GPUs holds GLM 5.3 at FP8 (753 GB of weights, 904 GB with headroom), at about 10 kW. Terminal Pulse, edge: Fanless IP-rated enclosures at the yard blocks, gate and quay; no safety reflex crosses a network hop.

## Is it cheaper to own AI hardware or rent cloud GPUs in maritime and ports?

Each maritime and ports design prices three years of ownership in its Appendix A, with every price cited, against renting the same capacity from a cloud region at its deepest three-year commitment where hardware is bought. Port Twin: three-year cost, No hardware line to price: the design adds software and integration work to servers the port already runs. Terminal Pulse: three-year cost, owned, About 722,000 US dollars with support and power at the US industrial power price; three-year cost, rented, 0.99 million to 2.52 million US dollars for the same GPUs around the clock; ownership is about four fifths the deepest three-year commitment (version 2); closed model break-even, The cheapest closed model matches the owned stack at about 35 users; above that, ownership is cheaper and the gap grows with every user.

## What ontology or object model does a maritime and ports AI system need?

The object model is the part that makes the system an ontology rather than a pipeline: typed objects for the things in the maritime and ports operation, with properties, status values and typed links. Every published design ships its object model as hyper-ontology/1 JSON that loads into Hyper Ontology. Port Twin: Berth, Navigation channel, Subsurface utility layer, Environmental sensor feed, Parcel / facility, Bathymetric survey surface, Utility gap record, Capital project, Inspection record, Vessel movement record, Truck movement record, PCS message, Engineering document. Terminal Pulse: Vessel Call, Container, Yard Block, RTG, Ship to Shore Crane, Truck Visit, Gate Lane, Rail Cut, Reefer Plug, Yard Person, Transfer Zone, Safety Event.

## Who approves the decisions an AI system makes in maritime and ports?

In every published maritime and ports design a named person makes the decision that changes the physical world; the system prepares it. Port Twin: The twin shows; pilots, berth planners, engineers and finance staff decide in their own systems, and nothing writes back into a system of record. Terminal Pulse: Surfaces warn and propose; the named planner acts in the terminal operating system and the named safety supervisor acknowledges every safety event.

## Sources

- [Port Twin: One Governed Digital Twin for Every Asset, Feed and Dollar](https://codeatoms.ai/port-digital-twin-us/) (United States), DOI https://doi.org/10.5281/zenodo.23126431
- [Terminal Pulse: Predicted Truck Turn Time and Live Yard Sight for a Container Terminal](https://codeatoms.ai/truck-turn-container-terminal-us/) (United States), DOI https://doi.org/10.5281/zenodo.23159331


---

# Physical AI for oil and gas: questions answered

Canonical: https://codeatoms.ai/sectors/oil-and-gas/
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai)

Wells, terminals and plants hold safety, inventory and process data in systems that were never joined, often on sites where the data may not leave the country.

## What does a physical AI system for oil and gas look like?

A complete physical AI design for oil and gas names what to sense, which existing systems to join, the object model that joins them, the models and hardware, the three-year cost and the person who approves every action. CodeNinja Atoms has published 2 such reference architectures for oil and gas, each free to reuse under CC BY 4.0. Sovereign HSE Watch (Pakistan): An open reference architecture for predicting HSE incidents at an oil and gas operator in Pakistan, on the operator's own hardware, with no data leaving the country and no third-party AI service in the serving path. Loop Integrity Watch (Pakistan): field hardware that rebuilds the signal path on three Modbus loops, and a governed inventory ontology that catches a flatlined or swapped radar gauge reading before the central inventory picture misleads anyone.

## Which AI models can an oil and gas operator run on its own hardware?

Each published oil and gas design names its models and why, and every model is open-weight or no model is used at all, so the operator can run it on hardware it owns. Sovereign HSE Watch: 6 self-hosted open-weight models, including GLM 5.3 (reasoning), Chronos-2 (forecasting), RF-DETR (vision), BGE-M3 (retrieval in English and Urdu) and PaddleOCR-VL 1.6 (scans). Loop Integrity Watch: None: every integrity check (stuck value, swap, distortion) is deterministic.

## How much compute and hardware does AI in oil and gas need?

The compute follows from the models: the published oil and gas designs size it as follows, from no new hardware to a full GPU node. Sovereign HSE Watch, frontier compute: One node of eight 141 GB HBM-class GPUs holds GLM 5.3 at FP8 (753 GB of weights, 904 GB with headroom). Sovereign HSE Watch, the hard dependency: 141 GB-class accelerators need a US export licence for Pakistan (Country Group D:4); the rollout's first gate confirms installed hardware first. Loop Integrity Watch, compute: Two containers on the operator's own site application server, inside its OT boundary. Loop Integrity Watch, field scope: 13 fuel tanks on 3 Modbus RTU loops; 3 booster installations engineered from a measured signal survey inside explosion proof junction boxes.

## Is it cheaper to own AI hardware or rent cloud GPUs in oil and gas?

Each oil and gas design prices three years of ownership in its Appendix A, with every price cited, against renting the same capacity from a cloud region at its deepest three-year commitment where hardware is bought. Sovereign HSE Watch: three-year cost, owned, About 670,000 US dollars with support and power at Pakistan's industrial tariff; three-year cost, rented, 1.1 to 2.8 million US dollars for the same GPUs in the nearest cloud region; no hyperscaler runs a region in Pakistan. Loop Integrity Watch: three-year cost, No compute to price; the field equipment is priced by OEM quotation against the survey (Appendix A).

## What ontology or object model does an oil and gas AI system need?

The object model is the part that makes the system an ontology rather than a pipeline: typed objects for the things in the oil and gas operation, with properties, status values and typed links. Every published design ships its object model as hyper-ontology/1 JSON that loads into Hyper Ontology. Sovereign HSE Watch: Operating Facility / Site, HSE Equipment, HSE Incident, Near Miss Report, Corrective Action, Inspection / Audit Record, HSE Document, Sensor Reading, Anomaly Event, Agent Recommendation, HSE Person, HSE Role. Loop Integrity Watch: Fuel Tank, Radar Tank Gauge (RTG), RTG Communication Loop, Modbus Booster (Repeater), Explosion Proof Junction Box, Gauge Reading, Data Quality Event, Central Inventory Picture, Loop Wiring As-Built, Service Order, Warranty and Support Record, OEM Authorization Letter, HSE Work Permit, Instrumentation Technician, Location Engineer.

## Who approves the decisions an AI system makes in oil and gas?

In every published oil and gas design a named person makes the decision that changes the physical world; the system prepares it. Sovereign HSE Watch: Every recommendation is approved or rejected by a named person; nothing executes on equipment. Loop Integrity Watch: Every data quality event is acknowledged and resolved by a named person; the location engineer signs acceptance.

## Sources

- [Sovereign HSE Watch: A Reference Architecture for Predictive Health, Safety and Environment Intelligence in Pakistan's Oil and Gas Operations](https://codeatoms.ai/sovereign-hse-pakistan/) (Pakistan), DOI https://doi.org/10.5281/zenodo.23119714
- [Loop Integrity Watch: Ending Distorted Radar Level Readings and Tank-to-Tank Swapping Across the Tank Farm](https://codeatoms.ai/tank-gauge-integrity-pakistan/) (Pakistan), DOI https://doi.org/10.5281/zenodo.23157967


---

# Sovereign HSE Watch: A Reference Architecture for Predictive Health, Safety and Environment Intelligence in Pakistan's Oil and Gas Operations

Canonical: https://codeatoms.ai/sovereign-hse-pakistan/
DOI: https://doi.org/10.5281/zenodo.23119714
PDF: https://codeatoms.ai/sovereign-hse-pakistan/paper/sovereign-hse-platform-pakistan-oil-and-gas.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

VERTICAL-DRIVEN ARCHITECTURES · OIL & GAS · DESIGNED WITH PRAXIS · OCTOBER 2026

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

A sovereign, on-premises HSE control and command platform that unifies an oil and gas operator's fragmented safety data across Pakistan into one living ontology, turning incidents, sensors, cameras and documents into predictive early warnings, cited guidance and human-approved action.

CodeNinja Engineering Team

For the HSE director, department leads and site superintendents, and the data, platform, OT and machine learning engineers who would build and run it.

---

Vertical-Driven Architectures is a CodeNinja series of system designs. Every design in the series is driven by a real-world problem and scenario in a single industry, and every one is designed on Praxis, CodeNinja's platform for designing physical AI systems. Operations are described by class, never by name.

At a glance

## A sovereign health, safety and environment (HSE) platform for oil and gas in Pakistan

**What this is.** An open reference architecture for predicting HSE incidents at an oil and gas operator in Pakistan, on the operator's own hardware, with no data leaving the country and no third-party AI service in the serving path. It is written for HSE heads and for the engineers who would build it.

**The answer in numbers.**

| Part | The design |
| --- | --- |
| Sources joined | 8 systems: SAP EHS, PM and QM; SCADA; fire and gas; Vision AI cameras; SQL databases; scanned files; the identity provider |
| Object model | 12 typed objects and their links, published as JSON for reuse |
| Models | 6 self-hosted open-weight models, including GLM 5.3 (reasoning), Chronos-2 (forecasting), RF-DETR (vision), BGE-M3 (retrieval in English and Urdu) and PaddleOCR-VL 1.6 (scans) |
| Frontier compute | One node of eight 141 GB HBM-class GPUs holds GLM 5.3 at FP8 (753 GB of weights, 904 GB with headroom) |
| Three-year cost, owned | About 670,000 US dollars with support and power at Pakistan's industrial tariff |
| Three-year cost, rented | 1.1 to 2.8 million US dollars for the same GPUs in the nearest cloud region; no hyperscaler runs a region in Pakistan |
| Human control | Every recommendation is approved or rejected by a named person; nothing executes on equipment |
| The hard dependency | 141 GB-class accelerators need a US export licence for Pakistan (Country Group D:4); the rollout's first gate confirms installed hardware first |

**Reuse it.** The object model, the model register and the figures are free to reuse under CC BY 4.0. Cite as DOI <https://doi.org/10.5281/zenodo.23119714.>

**Made with.** Reasoned on [Praxis](<https://codeatoms.ai/praxis/>), CodeNinja's platform for designing physical AI systems. The object model imports into [Hyper Ontology](<https://codeatoms.ai/hyper-ontology/>), which turns it into a living system. Both are in beta; access by request.

ABSTRACT

## HSE Risk Should Be Predicted Daily, Not Reconstructed After the Incident

The question the HSE department needs answered every day is which emerging risks are forming across its facilities and where the next incident is most likely, so that prevention happens before the event rather than investigation after it. Today it cannot be answered: HSE information sits fragmented across enterprise systems, relational databases, real-time control streams and manual files, so emerging risks surface slowly, incidents cannot be predicted from precursor signals, and lessons from past events are hard to retrieve at the moment a similar condition reappears.

The design is a sovereign HSE control and command platform built entirely on the operator's own infrastructure as a system of context: eight named sources, including the ERP suite of environment, health and safety, maintenance and quality modules, the SCADA historian, the fire and gas system, the existing Vision AI camera estate, SQL databases, flat files and scanned records, and the operator's identity provider, enter only through four adapter families into one HSE ontology of twelve typed objects, above which run five services and four surfaces: anomaly detection and forecasting on site GPUs beside the cameras and historian, a cited retrieval assistant grounded in the operator's own policies and recognized standards, a control room dashboard, and an agentic work surface whose frontier reasoning model runs on one eight-GPU node inside the same Pakistani boundary, so weights, footage, embeddings and audit logs never leave it.

The paper opens with the industry problem and the join failure across existing systems, then presents the design in six chapters: constraints, the layered stack, the object model, ingestion through adapters, inference placement and the latency budget, and the models and licenses that decide what the operator can own; Part III covers the three-phase rollout with its seventeen items and exit gates, and ownership of everything the design builds; it closes with the conclusion and Chapter 11, which explains how Praxis contextualized and reasoned the design.

---

![Figure 1. Sovereign HSE Watch on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.](figures/figure_01.png)

Figure 1. Sovereign HSE Watch on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.

## Contents

Each chapter is tagged for the reader it serves most directly: Executive, Team Lead, FDE, Reference.

|  |  |  |
| --- | --- | --- |
|  | Abstract · HSE Risk Should Be Predicted Daily, Not Reconstructed After the Incident | Executive |
| PART I · THE PROBLEM | | |
| 1 | [HSE Risk Emerges Before Any System Sees It](#ch1) | Executive |
| 2 | [Every Enterprise System Sees One Slice of Safety](#ch2) | ExecutiveTeam Lead |
| PART II · THE DESIGN | | |
| 3 | [Four Constraints Shape a Sovereign HSE Design](#ch3) | Team Lead |
| 4 | [One Stack Runs From Systems of Record to Control Room](#ch4) | Team LeadFDE |
| 5 | [Twelve Objects Turn Fragmented HSE Data Into One Argument](#ch5) | FDE |
| 6 | [Every Source Enters Through an Adapter, Never Directly](#ch6) | FDE |
| 7 | [Detection Belongs on Site and Reasoning In-Country](#ch7) | FDE |
| 8 | [Licenses Decide What the Operator Can Own](#ch8) | FDEExecutive |
| PART III · THE ROLLOUT | | |
| 9 | [Shadow Mode Comes Before Any Alert Is Trusted](#ch9) | Team LeadExecutive |
| 10 | [The Intelligence Should Stay with the Operator That Produced It](#ch10) | Executive |
| PART IV · HOW IT WAS DESIGNED | | |
|  | Conclusion · Sovereignty Is an Architecture, Not an Address | Executive |
| 11 | [How Praxis Contextualized and Reasoned This Design](#ch11) | Team LeadFDE |
|  | [Sources](#sources) | Reference |

PART I · CHAPTER 1

## 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.

PART I · CHAPTER 2

## 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.

![Figure 2. Seven systems, each seeing one part of the answer. the question needs all of them in one place at once.](figures/figure_02.png)

Figure 2. Seven systems, each seeing one part of the answer. the question needs all of them in one place at once.

PART II · CHAPTER 3

## 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.

Table 1 · Scoping Decisions

| Decision | What it buys | What it costs |
| --- | --- | --- |
| Reuse the operator's existing Vision AI camera estate, with gaps priced as new class purchases | Coverage of every camera location class in scope without a new camera program, with reuse gated on measured density, angle and stream evidence | Some zones may fail the reuse gate, and a mixed estate means two detection paths to maintain |
| State the frontier tier as one node class, a single 8 x 141 GB HBM node, verified in the phase-one survey | The agentic work surface is sized honestly before procurement, with the export-license approval path named as the fallback | Capacity stays unverified until the survey, and the fallback path adds approval lead time |
| Abstract every SAP connection behind a connector layer until the exact landscape is confirmed | Connector build can start before the ECC or S/4HANA question settles after award | One abstraction tier must be tested against both access patterns before it finalizes |

### 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.

Table 2 · What the Design Chose Against

| Where | What was picked | Instead of, and why |
| --- | --- | --- |
| Frontier language model | GLM 5.3 open weights at FP8, self-hosted on the operator's infrastructure | A hosted AI API, which breaks residency, or a quiet downsize to a mid-size dense model, which would not carry the agentic work surface the department committed to |
| Vision detector | RF-DETR Apache-2.0 checkpoints, nano through large | Ultralytics YOLO26: its AGPL-3.0 license would force source release of the whole serving stack, which a closed sovereign platform cannot accept |
| MLOps platform | Red Hat OpenShift AI in a disconnected install | Hand-rolled scripts on a bare cluster: the disconnected install ships model serving, a registry and pipelines with a documented air-gapped procedure |
| People and vehicle positioning | Out of scope for this design | A fleet telematics or positioning layer: no positioning source is named in the requirement, and zone logic over the existing camera estate covers the safety rules in scope |
| One-way data transfer | Reserved for a future phase | A hardware data diode now: the whole platform lives inside one boundary, so a read-only conduit through a demilitarized zone enforces the operational technology separation, and a diode waits for any phase where that policy demands one |
| Vendor qualification material | Out of scope for this design | Corporate profiles, prior-work references and commercial commitments: these are procurement matters outside a system design, which carries the weekly in-country review cadence as a plan fact instead |

PART II · CHAPTER 4

## 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.

![Figure 3. The layered stack: 8 sources, 4 adapter families, 12 objects, 5 services and 4 surfaces.](figures/figure_03.png)

Figure 3. The layered stack: 8 sources, 4 adapter families, 12 objects, 5 services and 4 surfaces.

### 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.

Table 3 · The Stack, Stage by Stage

| Stage | What it is responsible for | How |
| --- | --- | --- |
| Sources | Holds HSE truth where it already lives, unchanged and authoritative | SAP EHS, PM and QM; SCADA historian; fire and gas system; Vision AI camera estate; SQL databases; flat files and scanned records; the identity provider; the HSE governance document corpus |
| Sensing | Converts physical site state into time-aligned signals | Existing IP cameras; fire and gas detectors; SCADA process tags; ambient environmental readings; a GNSS grandmaster clock synchronizing every signal |
| Adapters | Move every source into typed events without modifying the source | ERP adapter for SAP; telemetry adapter for SCADA, fire and gas and Vision AI streams; integration adapter for SQL change data capture and APIs; file and document adapter with OCR |
| Object model | Holds one living HSE ontology as the single joined view of operations | Twelve typed objects with typed links and status vocabularies, fed by the event backbone and replayable end to end |
| Inference | Detects, forecasts, retrieves, parses and reasons | RF-DETR detection and Roboflow trackers at the edge; Chronos-2 forecasting; BGE-M3 embeddings; PaddleOCR-VL parsing; GLM 5.3 served through vLLM on the central tier |
| Services | Turn ontology state into governed capabilities with named owners | Unified HSE Data Foundation; Sovereign Delivery and Assurance; AI Detection and Prediction; Control Room Visibility and Reporting; Agentic Layer and Assistant |
| Surfaces | Put each decision in front of the named person who owns it | Executive summary view; investigation and decision-support view; real-time alert and task guidance view; real-time site situational awareness view |

PART II · CHAPTER 5

## 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).

![Figure 4. The twelve objects of the model and the typed links that let a query reach across them.](figures/figure_04.png)

Figure 4. The twelve objects of the model and the typed links that let a query reach across them.

### 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"
    }
  ]
}
```

PART II · CHAPTER 6

## 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.

![Figure 5. The 8 named systems, the adapter path each one takes, and the object model they all map into.](figures/figure_05.png)

Figure 5. The 8 named systems, the adapter path each one takes, and the object model they all map into.

### 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.

PART II · CHAPTER 7

## 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.

![Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.](figures/figure_06.png)

Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.

### 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.

PART II · CHAPTER 8

## 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.

![Figure 7. The six models, their placement, and the work each one does.](figures/figure_07.png)

Figure 7. The six models, their placement, and the work each one does.

### 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.

Table 4 · Model and Equipment Register

| The choice | What was picked | Why here |
| --- | --- | --- |
| Frontier reasoning model | GLM 5.3 open weights at FP8, self-hosted | Strongest open agentic model; the bespoke license exempts purely internal use from the model-as-a-service security-review trigger |
| Detector | RF-DETR, Apache-2.0 Nano to Large checkpoints, BF16 | The practical sovereign answer to the AGPL gate; Plus XL and 2XL excluded from the serving path |
| Forecaster | Chronos-2, Apache-2.0, about 0.48 GB at 32 bit | Zero-shot multivariate forecasting with no field-of-use restriction; weights may be held, fine tuned and redistributed |
| Embeddings | BGE-M3, MIT, FP16 | Dense plus sparse plus multi-vector retrieval in one pass with an 8,192-token window |
| Document parsing | PaddleOCR-VL 1.6, Apache-2.0, about 0.9B parameters, BF16 | Strong on degraded multilingual scans; no user or revenue threshold; fine tuning permitted |
| Tracking | Roboflow trackers, Apache-2.0 | Stable identity across frames without reintroducing copyleft after an Apache detector |
| Frontier node class | One node of 8 x 141 GB HBM GPUs (H200 class) | 1,128 GB holds the 904 GB FP8 footprint with KV cache headroom |
| Edge compute class | The operator's NPU/GPU accelerators, sized from measured stream and decode load | Sizing is stated as a requirement and verified at the phase-one survey |
| Cameras | The existing Vision AI IP camera estate, reused subject to ONVIF reuse gates | Reuse on measured density, angle and stream evidence, with gaps priced as new class purchases |
| Time synchronization | OCP Time Card GNSS grandmaster with holdover, driving linuxptp and chrony | One defensible chronology across detectors, cameras and process tags |
| Edge orchestration | Red Hat OpenShift AI self-managed, disconnected install | Documented disconnected procedure for model serving, registry, pipelines and workbenches |
| Serving runtimes | KServe at the edge, vLLM on the central node | Model serving matched to each tier's load |

PART III · CHAPTER 9

## 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.

![Figure 8. The three phases and their gates, and coverage of the 12 requirements across them.](figures/figure_08.png)

Figure 8. The three phases and their gates, and coverage of the 12 requirements across them.

### 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.

Table 5 · Failure Modes

| What fails | What the design does |
| --- | --- |
| Frontier GPU capacity is unverified before award | The phase-one sizing survey states the requirement as one node of eight 141 GB HBM class GPUs; if the site cannot hold it, the frontier model proceeds through the export-license approval path or a dedicated in-country facility, never a silent swap to a smaller model. |
| The SAP generation and OData availability are unknown | The connector layer abstracts the extraction mechanism; the landscape is confirmed before connector build finalises. |
| OCR quality on degraded scans cannot ground retrieval | The reconstructed week measures capture cost and illegibility as real numbers before digitisation is priced; low-confidence documents carry a needs-review state instead of silent ingestion. |
| Alerts exceed what supervisors can treat seriously | The alert budget is negotiated before any threshold is set; overflow enters a ranked queue, and ignore and action rates are reported from week one. |
| Integration discovery collides with the milestone plan | The reconstructed week surfaces where truth actually lives; weekly reviews re-baseline, and user acceptance, not the calendar, is the binding gate. |

### 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.

PART III · CHAPTER 10

## 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.

PART IV · CONCLUSION

## 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.

PART IV · CHAPTER 11

## 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.

![Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.](figures/figure_09.png)

Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.

### 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.

Table 6 · The Lenses and What They Contributed

| Lens | Could see | Cited | What it contributed |
| --- | --- | --- | --- |
| First principles | The pinned brief and the doctrine shelf | 4 | The write-layer doctrine, time synchronisation discipline and the historian-as-source rule; the alert contract and verifier-first rules where their preconditions hold |
| Case studies | 9 sector case records, none comparable | 0 | Gap: no recorded build of this shape in this sector, so nothing here stands on a prior operation |
| Tooling and recency | 347 records | 5 | Every model and product checked live: the streaming backbone, the disconnected-install orchestration, the Apache-licensed detector sizes and the open forecaster |
| Hardware and equipment | The equipment register | several | The 141 GB HBM node class and its sizing arithmetic, edge compute sized from measured streams, camera reuse gates, the time card and the enclosure classes |
| Rules and regulations | The regulatory and standards corpus | several | The data residency posture, the zones-and-conduits read path and alignment of the indicator set with recommended process safety practice |
| Approach | The method records | a narrow set | Shadow-before-live sequencing and milestone gates that carry proofs rather than dates |
| History | The recorded accident record | several | Industry disasters traced to signals that reached no decision maker in time, which fixed early warning as the design's first duty |
| Domain fusion | Cross-sector records | a narrow set | Joining vision detections, detector alarms and process telemetry on one chronology under one object model |

### 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.

Appendix A

## What Ownership Costs Over Three Years

*Version 2, 3 October 2026. Version 1 compared ownership with AWS's Compute Savings Plan (26 percent off) and printed "about one third"; AWS's deepest three-year plan makes it about three fifths. Every other number is unchanged.*

The design runs on the operator's own hardware. This appendix prices that choice against the two ways an operator in Pakistan could otherwise get the same capability: renting the same accelerators from the nearest hyperscaler region, or buying a closed frontier model by the token. Every input is a public price, dated and cited. The arithmetic is shown so any reader can rerun it with a written quote.

### A.1 The Answer

Owning the stack this design specifies costs about **670,000 US dollars over three years**, inside a range of 580,000 to 770,000. Renting the same capacity around the clock from the nearest hyperscaler region costs **1.1 to 2.8 million dollars** over the same period. Ownership is therefore between about one quarter and three fifths of the cost of renting, and **about three fifths** against the deepest three-year commitment, an AWS EC2 Instance Savings Plan paid up front. None of the rented options keeps the data in Pakistan, because no hyperscaler operates a region inside the country (Alskyline 2026).

### A.2 What Owning Costs

Table A1 prices the hardware the design names and three years of running it.

| Line | Basis | Three-year cost (USD) |
| --- | --- | --- |
| Frontier tier | One server of eight 141 GB HBM-class cards, 320,000 to 420,000 dollars, typical 370,000 (Mercatus 2026) | 320,000 to 420,000 |
| Site tier | One PCIe inference server, priced at the upper bound of eight 48 GB cards, 85,271 dollars (Newegg 2026); its three models weigh under 4 GB | 85,271 |
| Edge | An allowance of six fanless industrial nodes at 4,000 dollars each (Eurotech 2026); the design reuses the operator's NPU compute where it exists | 24,000 |
| Support | 8 to 12 percent of hardware value a year (Introl 2026) | 103,000 to 191,000 |
| Power | 10.9 kW average IT load at a power usage effectiveness of 1.6 (Uptime Institute 2025), 456,641 kWh at the industrial B3 average of 27 rupees per kWh plus the fixed kW charge (Dawn 2026), at 277.38 rupees to the dollar (SBP 2026) | 47,269 |
| **Total** |  | **580,000 to 767,000, typical 670,000** |

The average load assumes the frontier server draws 7 kW of its 10.2 kW maximum (NVIDIA 2026), the site server 3.5 kW and each edge node 60 W. The frontier tier fits one node because the design's reasoning model, GLM 5.3, is 753 GB at FP8 and needs 904 GB with headroom, against 1,128 GB on eight 141 GB cards.

### A.3 What Renting Costs

The same frontier server and site server, rented without a break for three years, because HSE monitoring does not stop at night. The edge nodes stay on site in every option.

| Option | Basis | Three-year cost (USD) |
| --- | --- | --- |
| AWS, UAE region, on demand | p5en.48xlarge at 75.96 dollars an hour in me-central-1, g6e.48xlarge at 30.13 (Vantage 2026) | 2.82 million |
| AWS, three-year EC2 Instance Savings Plan | all upfront in me-central-1: 28.56 dollars an hour for p5en.48xlarge, 13.90 for g6e.48xlarge (AWS 2026) | 1.14 million |
| Specialist GPU cloud, on demand | 50.44 dollars an hour for eight H200 cards, 18.00 for eight L40S (CoreWeave 2026) | 1.83 million |
| Oracle, three-year commitment | 40 dollars an hour for eight H200 cards (Economize 2026), site tier as AWS reserved | 1.42 million |

Egress, storage, and the network link from Pakistan to the region are excluded, so every rented figure is a floor.

### A.4 What Closed Models Cost by the Token

A closed frontier model replaces the frontier tier rather than the whole stack, and it is priced by use. At 50 HSE users, each running the equivalent of five agents at 2.4 billion tokens a year, with four input tokens to every output token and half the input served from cache, three years is 360 billion tokens.

| Model | List price per million tokens, input and output | Three-year cost (USD) |
| --- | --- | --- |
| Claude Sonnet 5.5 | 2 and 10 (Anthropic 2026) | 1.04 million |
| Gemini 3.1 Pro | 2 and 12 (Google 2026) | 1.18 million |
| Claude Opus 5.5 | 4 and 20 (Anthropic 2026) | 2.07 million |
| GPT-5.5 | 5 and 30 (OpenAI 2026) | 2.95 million |

At this volume even the cheapest closed model costs about one and a half times the whole owned stack, and the largest cost three to four and a half times as much. Token volume is the assumption that moves this comparison most: it scales linearly with users, and ownership does not. Every one of these options also sends HSE records, which carry personal data and investigation findings, to a third-party AI service outside the boundary, which the design's first constraint rules out.

### A.5 What the Price Does Not Include

- **Import duty, sales tax, freight and insurance** on the hardware, which a written quote delivered to Pakistan settles.
- **An export license.** Pakistan sits in US Country Group D:4, so 141 GB HBM-class accelerators need a license from the Bureau of Industry and Security (eCFR 2026). Approved channels have delivered more than 3,000 accelerators to a Pakistani operator (The News 2026). The design's Phase 0 checkpoint confirms the operator's actual inventory before anything is bought, and holds a downgrade path to a mid-size model on accelerators already installed.
- **People, facilities and implementation**, which both sides carry.
- **Price movement.** Cloud prices rose as well as fell in 2026; AWS raised its H200 capacity block price about 15 percent in January (Gigazine 2026).

### A.6 Sources for This Appendix

- Alskyline. 2026. Cloud regions in Saudi Arabia, 2026 guide. <https://alskyline.com/kb/cloud-regions-saudi-arabia-2026-guide>
- Anthropic. 2026. Pricing. <https://claude.com/pricing>
- AWS. 2026. Compute and EC2 Instance Savings Plans price file, me-central-1, 3 October 2026. <https://pricing.us-east-1.amazonaws.com/savingsPlan/v1.0/aws/AWSComputeSavingsPlan/current/region_index.json>
- CoreWeave. 2026. Pricing. <https://www.coreweave.com/pricing>
- Dawn. 2026. NEPRA notifies new industrial tariffs. <https://www.dawn.com/news/1973828>
- eCFR. 2026. 15 CFR Part 740, Supplement No. 1, Country Groups. <https://www.ecfr.gov/current/title-15/subtitle-B/chapter-VII/subchapter-C/part-740>
- Economize. 2026. OCI BM.GPU.H200.8 pricing. <https://www.economize.cloud>
- Eurotech. 2026. ReliaCOR 33-11. <https://buy.eurotech.com/products/reliacor-33-11>
- Gigazine. 2026. AWS raises EC2 Capacity Blocks prices. <https://gigazine.net>
- Google. 2026. Gemini API pricing. <https://ai.google.dev/gemini-api/docs/pricing>
- Introl. 2026. GPU infrastructure TCO model. <https://introl.com/blog/gpu-infrastructure-tco-model-5-year-enterprise-ai-deployment>
- Mercatus. 2026. H200 server price. <https://mercatus-ai.com/blog/h200-server-price>
- Newegg. 2026. Supermicro SYS-421GE-TNRT-02-G1. <https://www.newegg.com/p/N82E16859152404>
- NVIDIA. 2026. DGX H200. <https://www.nvidia.com/en-us/data-center/dgx-h200/>
- OpenAI. 2026. API pricing. <https://developers.openai.com/api/docs/pricing>
- SBP. 2026. Conversion rates, 4 September 2026. <https://www.sbp.org.pk>
- The News. 2026. Data Vault Pakistan GPUs. <https://www.thenews.com.pk>
- Uptime Institute. 2025. Global Data Center Survey 2025. <https://uptimeinstitute.com>
- Vantage. 2026. EC2 instance prices. <https://instances.vantage.sh>

SOURCES

## Source Register

CSB. 2010. INVESTIGATION REPORT. <https://www.csb.gov/assets/1/20/macondo_vol3_final_20160527.pdf>

CSB. 2005. INVESTIGATION REPORT. <https://www.csb.gov/assets/1/20/csbfinalreportbp.pdf>

CSB. 2010. Tesoro Anacortes 2014-May-1. <https://www.csb.gov/assets/1/7/tesoro%5Fanacortes%5F2014-may-01.pdf>

HSE. 2015. The Control of Major Accident Hazards Regulations 2015. Guidance on Regulations L111. <https://www.hse.gov.uk/PUBNS/priced/l111.pdf>

Veiligheidvoorop. 2018. Safety Performance Indicators. <https://www.veiligheidvoorop.nu/wp-content/uploads/2023/07/IOGP-PSE-2022pe.pdf>

---

### About CodeNinja

CodeNinja is a Middle Eastern-American artificial intelligence lab focused on building self-improving systems. We are reinventing knowledge work to close the loop between vertical AI use cases and the generalized intelligence that fuels it, accelerating the path toward organizational superintelligence.


---

# Steel Count Ledger: Independently Counted Production for Every Steel Mill in Pakistan

Canonical: https://codeatoms.ai/steel-production-count-pakistan/
DOI: https://doi.org/10.5281/zenodo.23126563
PDF: https://codeatoms.ai/steel-production-count-pakistan/paper/steel-count-ledger-production-monitoring-steel-mills-pakistan.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

VERTICAL-DRIVEN ARCHITECTURES · HEAVY INDUSTRY & CONSTRUCTION · DESIGNED WITH PRAXIS · OCTOBER 2026

# Steel Count Ledger: Independently Counted Production for Every Steel Mill in Pakistan

An ontology-anchored production monitoring system that counts billets, ingots, rebars and girders at the point they are made, publishes the counts into one operator-owned record, and lets revenue officers reconcile counted against declared production for a heavy industry and construction operator in Pakistan.

CodeNinja Engineering Team

For the director of the operator's audit unit, the revenue field officers and audit leads who decide discrepancies, and the edge, vision and platform engineers who would build and run it.

---

Vertical-Driven Architectures is a CodeNinja series of system designs. Every design in the series is driven by a real-world problem and scenario in a single industry, and every one is designed on Praxis, CodeNinja's platform for designing physical AI systems. Operations are described by class, never by name.

At a glance

## Independently counted production for every steel mill in Pakistan

**What this is.** An open reference architecture for system design in physical AI: cameras and a GPU industrial PC at every casting strand and cooling bed count billets, ingots, rebars and girders as they are made, publish the counts through a one-way link into one record the authority owns, and let revenue officers reconcile counted against declared production. It is written for the director accountable for production monitoring and for the edge, vision and platform engineers who would build it. The operator is described by class, never by name.

**The answer in numbers.**

| Part | The design |
| --- | --- |
| Sources joined | The counting estate itself, the weighbridge, declared production filings and the authority's case system, through one adapter family |
| Object model | 14 typed objects and 12 links, with the production count event as the focal object, published as JSON for reuse |
| Models | 3 self-hosted open models: RF-DETR (detection, fine-tuned per product type and mill), Roboflow trackers (identity across camera fields), GLM 5.3 (compliance work surface) |
| Edge | One sealed GPU industrial PC and IP66 HDR cameras per installation point; counting survives a slow wide-area link |
| Frontier compute | One node of eight 141 GB HBM-class GPUs holds GLM 5.3 at FP8 (753 GB of weights, 904 GB with headroom), in a dedicated data center behind an export licence checkpoint |
| Three-year cost, owned | About 4,445,000 US dollars for 300 installation points, of which the counting kits are 2,832,000 and cannot be rented; owning the frontier node costs about 686,000 against 751,000 on AWS's deepest three-year plan |
| Closed model break-even | The cheapest closed model matches the owned node at about 33 users; above that, ownership is cheaper |
| Human control | Every discrepancy case is judged by a named revenue field officer; the system counts and reconciles, it never assesses, and the mill never edits a count |
| The hard dependency | 141 GB-class accelerators need a US export licence for Pakistan (Country Group D:4); the node is ordered only once a licence naming the end user holds |

**Reuse it.** The object model, the model register and the figures are free to reuse under CC BY 4.0. Cite as DOI <https://doi.org/10.5281/zenodo.23126563.>

**Made with.** Reasoned on [Praxis](<https://codeatoms.ai/praxis/>), CodeNinja's platform for designing physical AI systems. The object model imports into [Hyper Ontology](<https://codeatoms.ai/hyper-ontology/>), which turns it into a living system. Both are in beta; access by request.

ABSTRACT

## A Production Count Should Be Observed at the Point of Making, Not Taken on Trust

How much steel did each melting and re-rolling unit in Pakistan actually produce this shift, this week, this filing period? The bid behind this design exists because the question cannot be answered today: production figures reach the authority as declarations from the mills themselves, the sector's structural gaps in tax compliance and revenue leakage are documented in the requirement's own background, and no independent instrumentation stands between the caster and the tax return. Once a bundle of rebars leaves the cooling bed, the only count that exists is the one the producer volunteers.

The design is an ontology-anchored production monitoring system built around three sources, one adapter family, fourteen objects, seven services, three surfaces and three models. IP66 cameras and GPU industrial PCs at every installation point count product on edge detection models the operator owns, with tracker models keeping one billet from counting twice; counts publish near-real-time over VPN through a hardware data diode into a single operator-owned production model; laser counting heads and the weighbridge feed serve as alternative sensing and acceptance ground truth; and revenue officers and audit teams reconcile counted against declared production on a workbench and an agentic work surface, the latter served by a frontier open-weight model in a dedicated data center because the GPU class it needs is export controlled for Pakistan.

The paper opens with the industry problem and the join failure across mill-side systems, states the constraints the bid and the mill floor impose, then walks the layered stack, the fourteen-object model, ingestion through adapters and the event backbone, inference placement from the installation point to the data center, and the models and licenses that decide what the operator can own. Part three sets out the rollout in three phases with item counts and exit gates, ownership of what the design builds, and the paper closes with the chapter on how Praxis contextualized and reasoned the design.

---

![Figure 1. Steel Count Ledger on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.](figures/figure_01.png)

Figure 1. Steel Count Ledger on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.

## Contents

Each chapter is tagged for the reader it serves most directly: Executive, Team Lead, FDE, Reference.

|  |  |  |
| --- | --- | --- |
|  | Abstract · A Production Count Should Be Observed at the Point of Making, Not Taken on Trust | Executive |
| PART I · THE PROBLEM | | |
| 1 | [Production That Nobody Counts Is Revenue That Leaks](#ch1) | Executive |
| 2 | [Every Mill System Sees One Slice of Production](#ch2) | ExecutiveTeam Lead |
| PART II · THE DESIGN | | |
| 3 | [The Bid's Own Gates Set the Design's Discipline](#ch3) | Team Lead |
| 4 | [One Stack Runs From the Mill Floor to the Workbench](#ch4) | Team LeadFDE |
| 5 | [Fourteen Objects Turn Mill Counts Into One Argument](#ch5) | FDE |
| 6 | [Every Count Enters Through an Adapter, Never Directly](#ch6) | FDE |
| 7 | [Counting Runs at the Point and Reasoning Runs Central](#ch7) | FDE |
| 8 | [Licenses Decide Whether the Operator Owns the Counter](#ch8) | FDEExecutive |
| PART III · THE ROLLOUT | | |
| 9 | [Shadow the Counts Before Anyone Trusts Them](#ch9) | Team LeadExecutive |
| 10 | [The Count Should Belong to the Authority, Not the Vendor](#ch10) | Executive |
| PART IV · HOW IT WAS DESIGNED | | |
|  | Conclusion · One Count Ledger Serves Any Output the State Must Measure | Executive |
| 11 | [How Praxis Contextualized and Reasoned This Design](#ch11) | Team LeadFDE |
|  | [Sources](#sources) | Reference |

PART I · CHAPTER 1

## Production That Nobody Counts Is Revenue That Leaks

Pakistan's iron and steel sector produces through melting and re-rolling units whose output reaches the tax system only as self-declared figures, so the authority's digitalization program begins with the need for an independent count at every mill.

The abstract set out the shape of the design: a counting system that runs at the mill, publishes through a one-way path into one operator-owned record, and reconciles counted against declared production on a work surface where named people decide. This chapter establishes the problem that shape answers, what the operation is, and what it already costs the country when production goes uncounted.

### 1.1  The Question, the Data and the Regulatory Ground

The question the operator needs answered is narrow and unforgiving: how much steel did each melting and re-rolling unit actually produce, counted independently of the mill itself, near enough to real time that a discrepancy can be raised while the shift that produced it is still identifiable. Self-declaration cannot answer it, because the party holding the number is the party whose tax depends on it. The design brief for the program states the aim directly: real-time visibility into total production at every iron and steel facility, ensuring accurate reporting, transparent audits and correct tax payments on billets, ingots, rebars and girders. Answering the question needs three classes of data, and the bid names all three. First, an independent physical count at the point where product leaves the process: units on the caster strand, the cooling bed or the ejection path, captured by video analytics, laser counting heads or equivalent sensing. Second, the production the mill declares, whether through the operator's tax filing channels or manual entry, so the two can be placed side by side per period and per product type. Third, a ground truth for accepting that the counter itself is honest: the mill's weighbridge record, read at commissioning and at acceptance, since tonnage and unit count can be checked against each other within known tolerances. The regulatory ground is layered. The tax regime is the point of the program: production counts feed compliance and audit under the authority's revenue function, with its audit teams handling discrepancy cases. The procurement regime governs how the system is bought: public competitive bidding with staged evaluation, electronic submission, and staged coverage milestones written into the contract itself. Finally, the system must satisfy integrity conditions the bid makes explicit, notably a proof-of-concept stage whose counting accuracy is tested against the weighbridge before any wider coverage is authorized.

### 1.2  The Documented Cost of Unverified Counts

When the quantity of physical material leaving a site is never independently counted, the loss is not hypothetical, and public record shows the pattern at scale. On a major highway program in the United States, a materials supplier admitted systematically understating the quantity and quality of aggregate handed over, and agreed to plead guilty and pay 50 million dollars in cash with up to 75 million dollars more in insurance coverage; the scheme worked because deliveries were accepted on the supplier's own paperwork (Justice 2007). The mechanism is identical to the one this program targets: whoever controls the count controls the payment, and no downstream record can expose a number that was never measured. Procurement authorities treat this as a structural risk rather than a one-off. The Organization for Economic Co-operation and Development has issued a formal legal recommendation on enhancing integrity in public procurement, setting out what governments must do to keep buying decisions honest across the contract lifecycle (OECD n.d.), and dedicated counter-fraud guidance treats the pre-contract stage, before a contract is signed, as a recognized point where fraud enters public programs (NHS 2025). A monitoring system whose every sensor the supplier owns and whose every figure the taxpayer declares sits exactly on that boundary.

### 1.3  The Operation as a Scenario

The scenario runs across the whole steel sector of the country. The facilities are melting and re-rolling units: electric furnaces cast billets or ingots, and re-rolling stands convert them into rebars and girders. The scale is banded, never itemized: hundreds of mills nationwide, covered in cumulative bands of about a fifth by the end of August 2026, half by the end of October 2026, and the full estate by 31 December 2026, with coverage measured in lines, meaning individual casting strands and cooling beds rather than whole sites. The people in the loop fall into four roles. Revenue field officers own assigned mills, judge declared production against the counted record and raise discrepancy cases. Audit teams carry jurisdiction-wide case loads and handle escalations. Mill staff run continuous shifts, support calibration at their installation points and dispute counts they believe are wrong. Vendor field engineers install, commission and maintain the equipment, operating under the bid's maintenance and support obligations. The physical environment is a mill at temperature: caster strands and cooling beds wrapped in dust, scale and radiant heat, ejection paths where moving bundles pass at production speed, electrical cabinets exposed to vibration and electromagnetic interference from furnace and rolling-stand drives. Cameras and enclosures are specified sealed and wide-temperature for exactly this reason, and workers, scrap carts and crane loads cross the frame constantly and must be excluded as noise rather than counted. The regulatory ground within the operation itself has three layers: the tax compliance regime that consumes the counts, the public procurement rules that govern staged acceptance, and the proof-of-concept clauses that make weighbridge-verified counting accuracy a condition of wider rollout. The design must hold three named source systems in one view: the operator's central record, the mill's weighbridge or manual count, and the declared production source, with one adapter family, one object model and three surfaces serving the roles above. That the operator's own systems cannot already provide this view is the subject of the next chapter.

PART I · CHAPTER 2

## Every Mill System Sees One Slice of Production

The weighbridge sees tonnage, mill records see declarations, and the operator's central systems see filings, but no existing system holds the counted physical production that would let any of them be checked against the others.

Chapter 1 defined the question, the three data classes it needs and the layered regulatory ground the counting system must satisfy. This chapter examines what the existing systems on each side of that ground actually see, and shows why the answer has never been available to any of them.

### 2.1  What Each System Sees, and What It Misses

The mill's weighbridge and manual counts see mass leaving the site: every truck passes over a calibrated bridge, and the record carries a batch, a tonnage and a timestamp. What the weighbridge misses is production that never becomes a shipment. Billets that go from caster to re-rolling mill and rebars that are bundled and staged for later dispatch never cross the bridge, so the weighbridge record can verify outbound tonnage without ever seeing what was made, and a manual count taken by mill staff inherits the same interest as the declaration it is meant to support. The declared production source, whatever form it takes, sees what the mill chooses to state: a period, a product type, a quantity and the identity of the declarer. It is administratively clean and legally load-bearing, which is precisely its weakness. It sees nothing physical at all. A declaration can be internally consistent, filed on time and matched to prior periods, and still be wrong by any margin, because no number in it was measured by anything outside the mill. The operator's central systems see the tax life of that declaration: filings, payments, audit history and the compliance state of each registered unit. They can flag statistical anomalies across hundreds of mills, but an anomaly in a filing is not evidence of underproduction. Without an independent count, every discrepancy the central system could raise dissolves into an argument between a declaration and a suspicion, and the field officer has nothing in hand to resolve it. Figure 2 sets the three systems side by side, each with its slice and its blind edge: tonnage without production, statements without measurement, filings without physics.

![Figure 2. Three systems, each seeing one part of the answer. the question needs all of them in one place at once.](figures/figure_02.png)

Figure 2. Three systems, each seeing one part of the answer. the question needs all of them in one place at once.

### 2.2  What None of Them See Together, and What That Costs

No existing system holds the counted physical production that would let the other three be checked against each other, and the join failure is precisely that: three records, each defensible alone, that cannot be placed in one argument. The weighbridge cannot be joined to a declaration because it measures a different quantity at a different point; the declaration cannot be joined to a count because no count exists; the central system cannot join anything because its inputs are the other two. The cost in practice is the cost Chapter 1 documented running quietly at every mill: unreported production passes through the gap between tonnage seen and production declared, discrepancies are unresolvable, and audit becomes negotiation. The documented pattern on public programs is that when deliveries are accepted on the supplier's own paperwork, the fraud is discovered only at scale and after years, with penalties measured in tens of millions of dollars (Justice 2007), and that procurement authorities now treat unverified reporting as a structural integrity risk to be designed against rather than audited after the fact (OECD n.d.). Closing the gap needs one new record: a count event, measured at the installation point, timestamped, typed by product and published by the operator rather than the mill. What it takes to build that record honestly is the subject of Chapter 3.

PART II · CHAPTER 3

## The Bid's Own Gates Set the Design's Discipline

Harsh mill environments, read-only discipline around operational technology, a vendor panel that must aggregate into one record, and the bid's staged coverage milestones and proof-of-concept tests shape every downstream choice.

Chapter 2 showed that the missing record is the count event, measured at the mill and owned by the operator, and that every existing system defers to the mill's own paper for it. This chapter sets the four constraints the bid and the mill floor place on building that record, the scoping decisions they force, and what the design deliberately chose against.

### 3.1  Count at the Harshest Point

The count must be taken where product is produced: the caster strand, the cooling bed, the ejection path. This is the hardest electronics environment in the scenario. Dust and mill scale foul lenses on a schedule nobody controls, radiant heat from hot billets blinds visible-light cameras, furnace and rolling-stand drives put electromagnetic interference on every signal, and vibration works mounts loose. The constraint is hard because the bid's own acceptance clauses make it unforgiving: counting accuracy is verified against the weighbridge at proof of concept, and again at acceptance, before any wider coverage is authorized. A system that counts cleanly in a lab and drifts on a dusty strand fails its own gates, so sealed wide-temperature equipment, cleaned-air enclosures and drift telemetry are not upgrades but entry conditions.

### 3.2  Observe the Mill, Never Operate It

The system must be read-only against mill operations. Furnaces, casters and rolling-stand control sit on operational technology networks where availability is a safety property and a stalled write can stop production. The constraint is hard because the easiest engineering path, integrating with mill systems for line speed and batch context, crosses exactly the boundary the industry treats as inviolable. The design holds the discipline of observing and counting only: camera and laser sensing on a segmented zone, a one-way publish path out, and no write path back into mill control under any failure mode.

### 3.3  One Record From a Panel of Vendors

The bid authorizes a panel of multiple vendors installing video analytics, laser counting or equivalent systems across the sector, while the operator requires one central record. The constraint is that panel members ship different hardware, different firmware and different native data formats, so every vendor feed into its own dashboard would fragment the record the program exists to create. Integrity guidance for public procurement treats keeping the buying and reporting chain coherent as a design obligation, not an aspiration (OECD n.d.), and the only mechanism that satisfies it here is one published count-event schema over a standard interface, conformance-tested before a vendor is authorized, so any panel member's counts aggregate without rework.

### 3.4  Prove on One Line Before Staging Nationwide

The bid's staged milestones, about a fifth of lines by the end of August 2026, half by the end of October and the full estate by 31 December 2026, leave no room for a rollout that discovers its counting model does not generalize across product types, mills and lighting conditions mid-program. The constraint is that steel mills differ in layout, product mix and ambient conditions, so a detector calibrated on one strand is not automatically valid on the next. The design therefore proves the whole loop, sensing through counting through publishing through acceptance, on one strand against the bid's proof-of-concept tests first, and stages coverage only behind gates the bid itself defines.

### 3.5  Scoping Decisions

Table 1 records the three decisions that shape everything downstream, each with what it buys and what it costs.

Table 1 · Scoping Decisions

| Decision | What it buys | What it costs |
| --- | --- | --- |
| Counting runs on operator-owned edge compute at each installation point | Counts survive link drops, no mill system is trusted, models are adaptable per product type | GPU-class hardware and a retraining loop at every covered line |
| One published count-event schema for the whole vendor panel | Any authorized vendor's counts aggregate into one operator record without rework | Conformance testing becomes a condition of panel authorization |
| Hardware data diode on the publish path to the operator's ingest edge | The record cannot be written back into, and mill networks stay isolated from the tax side | No remote write path to mill-side equipment, so configuration pushes need a separately managed channel |

### 3.6  What the Design Chose Against

Each rejection below is a place where a plausible shortcut was declined and why. Table 2 sets them out, ending with the work the design leaves out of scope entirely.

Table 2 · What the Design Chose Against

| Where | What was picked | Instead of, and why |
| --- | --- | --- |
| Detection and counting | Fine-tuned open-weight detectors the operator owns, one per product class | A packaged video analytics appliance |
| Panel integration | One REST count-event schema on every vendor's equipment | Each vendor's native feed into its own dashboard |
| Mill systems | Read-only sensing from a segmented camera zone per IEC 62443 zoning | Integration with furnace, caster or mill control systems for line context |
| Declared-production source | Build the adapter only once the operator confirms the source at kickoff | Assume tax filings and build reconciliation against them now |
| Out of scope | Weighbridge automation, worker surveillance features, mill process control, historic data migration and estate-wide end user training | Any of these as part of this program |

PART II · CHAPTER 4

## One Stack Runs From the Mill Floor to the Workbench

The design keeps systems of record below, one production model in the middle, and perception services and officer surfaces above, so a count made at a cooling bed arrives unchanged at a reconciliation case.

Chapter 3 fixed the constraints: the counts belong to the operator, the mills' own control systems stay read-only, and the build has to survive heat, dust and a panel of competing vendors. This chapter turns those constraints into one stack that runs from the mill floor to the officer's workbench.

### 4.1  The Pattern and Why It Fits

The design follows a layered pattern: systems of record at the bottom, one production model in the middle, services and officer-facing surfaces above. A heavy industry and construction operator in Pakistan holds the central count record; each mill holds its weighbridge; the declared production source holds the tax-side figure. The design reads all three and rewrites none. In the middle, a graph store holds fourteen typed objects from steel mill to discrepancy case, and it is the only place where a count, a calibration and a declared figure meet. Above it, seven services turn the model into running capability and three surfaces put it in front of the people who decide. Figure 3 shows the layers with their counts: three sources, one adapter family, fourteen objects, three models, seven services and three surfaces.

The pattern fits because the bid authorizes a vendor panel rather than a single vendor. If each vendor published into its own dashboard, the operator would hold as many versions of production as it has vendors; with one model in the middle, every count event carries the same schema, the same provenance and the same status vocabulary, so a discrepancy case can cite any mill on identical terms. The layering also enforces the read-only discipline: nothing above the object model writes to a furnace, a caster or mill control, and the only write path into the operator's record is the published count event itself.

![Figure 3. The layered stack: 3 sources, 1 adapter family, 14 objects, 7 services and 3 surfaces.](figures/figure_03.png)

Figure 3. The layered stack: 3 sources, 1 adapter family, 14 objects, 7 services and 3 surfaces.

### 4.2  The Stack Stage by Stage

Table 3 walks the stack from sources to surfaces and names the components at each stage. Two placement choices deserve emphasis before the table: inference is split by tier, with detection and tracking on each industrial PC at the installation point so counting survives a slow wide-area link, and language reasoning on one frontier node in a dedicated data center, because the export-controlled GPU class that holds the frontier weights cannot ship to Pakistan without a license.

Table 3 · The Stack, Stage by Stage

| Stage | What it is responsible for | How |
| --- | --- | --- |
| Sources | Holding the records the design reads and never rewrites | The operator's central count record, each mill's weighbridge or manual count, and the declared production source, all read-only |
| Sensing | Turning motion on the mill floor into machine-readable signals | IP66/67 HDR cameras on the caster strand, cooling bed and ejection path, laser counting heads where hot billets blind visible cameras, the weighbridge feed, UPS and cabinet temperature telemetry, and PTP time from a grandmaster with GNSS holdover |
| Adapters | Moving counts into the operator boundary and nothing back out | One integration adapter family publishing one REST-over-VPN count-event schema through a hardware data diode |
| Object model | Holding the fourteen typed objects as the single production model | A graph store inside the operator's boundary carrying every link from steel mill to discrepancy case |
| Inference | Counting product and reasoning over the model | RF-DETR detectors and OC-SORT/ByteTrack class trackers served on Triton at each IPC, Frigate and MediaMTX for video ingest, and GLM 5.3 served by vLLM in a dedicated data center |
| Services | Running the capability as seven named services | Production context, Field engineering, Edge perception, Integration, Central platform, Surfaces and Operations |
| Surfaces | Putting the record where named people decide | The declared-production reconciliation workbench, the agentic compliance work surface over the same model, and the mill-side calibration and alarm panel |

PART II · CHAPTER 5

## Fourteen Objects Turn Mill Counts Into One Argument

From steel mill to count event to discrepancy case, fourteen typed objects hold the whole chain of evidence, and the human loop lives where declared production meets the counted record.

Chapter 4 placed one production model in the middle of the stack. This chapter opens that model: the fourteen objects, the typed links between them, the point where people act, and one object as it is actually recorded.

### 5.1  Fourteen Objects and Their Typed Links

The model groups its fourteen objects into four families. Sites and assets: steel mill, installation point and industrial PC, the physical chain from district to camera mount. The counting chain: count event, product type, calibration and weighbridge record, which together make one billet or rebar bundle into evidence that can survive an audit. The declared side: declared production and discrepancy case, the two objects where tax filings meet the counted record. Actors and health: revenue field officer, audit team and mill staff, plus tamper alert and daily uptime record, which say whether the counting estate itself was honest and awake. Figure 4 draws every object and its typed links, with count event as the focal object.

The typed links are what make the model more than a document store. Starting at a single count event, one traversal reaches the product type it classifies, the calibration record that validates the detector version that counted it, the weighbridge record that measured that calibration's accuracy, the installation point and mill it came from, the declared production for the same period, and the field officer who owns any discrepancy it raised. A document store would need a hand-built join for every such question and would silently drift when one document omitted a field; here the links are typed and the traversal is the query, so the chain of evidence from hot strand to reconciliation case is one argument the graph can walk on demand.

![Figure 4. The fourteen objects of the model and the typed links that let a query reach across them.](figures/figure_04.png)

Figure 4. The fourteen objects of the model and the typed links that let a query reach across them.

### 5.2  Where the Human Loop Lives

The human loop lives at the discrepancy case. A field officer judges declared production against the counted record and writes findings and resolution; the audit team escalates cases beyond a station's jurisdiction; mill staff see calibration and tamper alarms on the mill-side panel and keep the cameras clean. Every judgment is made by a named person and recorded against the case object, so the model holds both the machine's count and the officer's decision.

The hosting posture keeps that loop inside the operator's boundary. The object model and the platform services run in-country; identity is handled by Keycloak with named accounts per officer and team; the only external links are the read-only declared-production adapter and the VPN publishing path from the mills. The only write path into the operator's record is the count event through the data diode, and the only writes people make are decisions on the work surface against the model. Nothing in the design writes to furnace, caster or mill control.

### 5.3  One Object in Its Recorded Form

The count event is the object every other object either produces, consumes or judges, and the platform prints it in its recorded form below: identifier, label, kind, properties from timestamp to dedup decision, and its status vocabulary from counted to disputed.

```
{
  "id": "steel_mill",
  "label": "Steel melting and re-rolling unit",
  "kind": "site",
  "anchored_in": "",
  "properties": [
    "Mill registration number",
    "Furnace count",
    "Product types",
    "District"
  ],
  "status_vocabulary": [
    "Onboarded",
    "Installation pending",
    "Live",
    "Suspended"
  ],
  "links": [
    {
      "to": "installation_point",
      "label": "hosts"
    }
  ]
}
```

PART II · CHAPTER 6

## Every Count Enters Through an Adapter, Never Directly

One integration adapter family, one published count-event schema and an event backbone with ordered, buffered delivery are what let a panel of vendors feed a single authoritative record.

Chapter 5 showed the objects that hold the chain of evidence. This chapter shows how a count made on the mill floor enters those objects without ever bypassing the adapter tier, and what keeps the flow ordered when a link drops.

### 6.1  Three Sources and Their Provenance Classes

Figure 5 maps the three named source systems and the path each takes into the model. The operator's central system is the destination record: counts publish near-real-time from every industrial PC into one record the operator owns, and the design reads it back for reconciliation. Each mill's weighbridge or manual count is the acceptance ground truth: POC test one and operational acceptance measure counting accuracy against it, so it enters as weighbridge records linked to calibrations. The declared production source, whether the operator's tax filing or manual entry, carries the declared side of every reconciliation; the bid does not name the source system, so it is confirmed at kickoff and the adapter is built then, as an open question carried forward deliberately. Each source carries a provenance class: operator-held for the central record and the weighbridge, meaning the record originates inside the operator's boundary, and domain-typical for declared production, meaning the class of source is known from the sector but the named system is confirmed at kickoff.

![Figure 5. The 3 named systems, the adapter path each one takes, and the object model they all map into.](figures/figure_05.png)

Figure 5. The 3 named systems, the adapter path each one takes, and the object model they all map into.

### 6.2  What the Adapter Tier Guarantees

The adapter tier is one family with one job: no source reaches the object model directly. Its guarantees follow from the vendor panel the bid authorizes. Every count event conforms to one published schema, mill, line, product type, quantity, timestamp, confidence and dedup decision, and conformance against that schema is tested at the POC as a condition of panel authorization, so a second vendor cannot silently fork the record. Each event carries an idempotency key, so a replayed event counts once; each carries its provenance stamp, so the model can always say which system produced a figure. The flow is one-way: events cross a hardware data diode into the operator boundary, and no adapter writes anything toward the mill, which keeps the read-only discipline from Chapter 3 intact at the wire level.

### 6.3  The Event Backbone

The backbone is Apache Kafka 4.3 in KRaft mode with three controllers, chosen so the count stream has ordered, replicated delivery without a separate coordination layer. Events are partitioned by mill and installation point, so every event for one strand arrives in the order it was counted, which is what lets dedup verdicts stay stable. Delivery is at-least-once with idempotent consumers, and replication across brokers means a broker loss loses nothing already acknowledged. Upstream of the backbone, each IPC holds a store-and-forward buffer sized to a survival window: when a mill's connectivity drops, counts accumulate locally and replay preserves both order and dedup verdicts, so the record loses coverage, not correctness. Telemetry such as uptime and latency flows to QuestDB on the same path, and PTP synchronization from the site grandmaster keeps camera, IPC and weighbridge timestamps comparable to the millisecond, so a counted billet can be matched against a weighbridge batch without argument about clocks.

PART II · CHAPTER 7

## Counting Runs at the Point and Reasoning Runs Central

Detection and tracking inference lives on each industrial PC because counting must survive link loss and mill conditions, while frontier language inference runs in a dedicated data center behind an export licensing checkpoint.

Chapter 6 carried every source through its adapter onto the event backbone, with ordering, buffering and replication guarantees stated per hop. This chapter places the inference itself: what runs on each industrial PC at the installation point, what runs centrally, and what the network between them is allowed to carry. The placement follows one rule: counting must survive link loss, dust and power cuts at the mill, while the reasoning that reconciles counts against declared production runs where its hardware and license permit it to run.

### 7.1  Two Inference Tiers and the Memory That Fixes Them

Figure 6 shows the two tiers. The edge tier is one GPU-accelerated industrial PC per installation point, sealed and wide-temperature rated, running detection and tracking inside containers orchestrated by MicroShift and served through NVIDIA Triton Inference Server. The detection model is RF-DETR fine-tuned per product type and per mill; the tracker is the Roboflow trackers implementation of the OC-SORT and ByteTrack class, which holds identity across frames so that one billet crossing two camera fields counts once, not twice. The footprints are small against the IPC's NVMe: the Apache-licensed Nano to Large detection checkpoints occupy about 61 to 68 MB at 16 bit, and the 2XL checkpoint about 254 MB. The design buys no mid-tier site inference server, because all perception runs per-IPC at the point where the camera sees the strand.

The central tier serves GLM 5.3 for the agentic work surface, and its placement is fixed by memory arithmetic rather than preference. The model is a 753B parameter mixture of experts as filed in the register; at FP8, one byte per parameter, the weights alone are 753 GB. A factor of 1.2 over weights for the KV cache and activations lifts the requirement to 904 GB. One node of eight GPUs at 141 GB of HBM each holds 1,128 GB, so the node carries the weights, the cache ceiling and activations with headroom, served through vLLM. That GPU class is export controlled for Pakistan, so the node runs in a dedicated data center behind a licensing checkpoint rather than on operator premises, and the design does not silently swap it for a smaller model that would change what the work surface can reason over.

![Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.](figures/figure_06.png)

Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.

### 7.2  The Latency Budget

The budget splits along the two paths in Figure 6. The count-event path runs camera decode, detection, tracking, the deduplication decision and publish entirely on the IPC, because a count that waits on a wide-area link is a count a mill outage can lose; the budget for that path is therefore spent locally and verified per installation point. The reconciliation path, where declared production meets the counted record on the workbench, tolerates seconds rather than frames, so the frontier model's central position does not tax counting. The design treats dashboard latency as a recorded measurement: each daily uptime record carries availability and the latency to dashboard as typed properties, so the budget is a number the system holds per installation point rather than an assumption. The budget is set against the proof-of-concept acceptance test on one strand, where counted quantities are judged against the mill's weighbridge or manual count, because an accurate count handed over late fails the same gate as a fast wrong count.

### 7.3  What Crosses the Boundary and What Fails When It Does

What crosses the network boundary is deliberately small: count events as typed records, tamper and offline alerts, UPS and cabinet temperature telemetry, and daily uptime records, published over the VPN tunnel through a hardware data diode at the ingest edge so the flow is one-way. Raw video stays on the IPC, mill control traffic never leaves the IEC 62443 camera zone, and nothing writes into mill systems. When the link fails, the IPC-side store-and-forward buffer holds count events for a survival window sized per site, and replay preserves both ordering and deduplication verdicts, so the central record stays one record. When power fails, the UPS carries the IPC through a clean shutdown, monitored by NUT so a failing cooler or battery is caught before the enclosure cooks the machine. When the update path fails, each IPC keeps running its last-known-good containers, and new models and artifacts reach it only from the air-gapped Harbor and MLflow registry; time resynchronizes from the PTP grandmaster once the link returns.

PART II · CHAPTER 8

## Licenses Decide Whether the Operator Owns the Counter

Apache-licensed detection and tracking models let the operator hold, fine-tune and retrain the counting stack itself, while the work surface's frontier model runs where its license and export rules permit.

Chapter 7 fixed where inference runs and what the memory arithmetic allows. This chapter names the models that inference runs, the licenses that govern them, and the reason the license question decides the design: a packaged counting appliance would rent the operator its own evidence, while open weights let the operator hold, fine-tune and retrain the counter itself.

![Figure 7. The three models, their placement, and the work each one does.](figures/figure_07.png)

Figure 7. The three models, their placement, and the work each one does.

### 8.1  Three Models and the Terms That Govern Them

Figure 7 shows the model stack: two Apache-licensed vision models at the edge and one frontier language model centrally. RF-DETR is the detection and counting model, run from the Nano to Large checkpoints at about 61 to 68 MB at 16 bit, with the 2XL checkpoint at about 254 MB where a crowded cooling bed needs it. It is real-time on edge GPUs and fine-tuned per product type and per mill, which is the property that matters here: billets, ingots, rebars and girders each get their own calibrated detector, adapted by the operator's own people. Its license is Apache-2.0 on both the package and the checkpoints, so the operator holds the weights outright. The YOLO family was set aside on exactly this ground, because AGPL exposure on a served model is a compliance risk a tax-evidence system should not carry. Roboflow trackers, the OC-SORT and ByteTrack class implementation, supplies tracking continuity and is likewise Apache-2.0, keeping the edge serving container one clean license surface.

GLM 5.3 is the work surface model: a 753B parameter mixture of experts as filed, at FP8 about 756 GB of weights as published, roughly 1.5 TB at BF16. Its bespoke license permits commercial use, fine-tuning and redistribution, which is what makes the operator's compliance agents genuinely its own. The 141 GB HBM class needs a US export licence for Pakistan, with no large scale licence pathway, so the frontier node is ordered only once a licence naming the end user is granted.

### 8.2  The Model and Equipment Register

Table 4 registers every choice the design stands on, from models to the ground they run on.

Table 4 · Model and Equipment Register

| The choice | What was picked | Why here |
| --- | --- | --- |
| Detection model | RF-DETR, Nano to Large checkpoints, BF16, Apache-2.0 | Real-time on edge GPUs and fine-tuned per product type and per mill; open weights the operator owns, where YOLO members carry AGPL exposure and were set aside |
| Tracking model | Roboflow trackers, OC-SORT and ByteTrack class, Apache-2.0 | Track continuity stops one billet counting twice; one clean license surface on the serving container |
| Work surface model | GLM 5.3, 753B parameter mixture of experts, FP8 | Frontier open weights for the operator's compliance agents; 904 GB against one node of 1,128 GB; bespoke license allows commercial use, fine-tuning and redistribution |
| Edge compute | GPU-accelerated industrial PC class, sealed, wide temperature, cooled enclosure | Sized from stream decode plus inference with headroom, hardened for mill heat, dust and electromagnetic interference |
| Frontier node | One node of eight 141 GB HBM GPUs, H200 class, in a dedicated data center | The class is export controlled for Pakistan, so the node runs where an export license naming the end user holds, checked at the phase one licensing checkpoint |
| Cameras | IP66/67 HDR industrial camera class, chosen from the pixel-density table per installation point; thermal, ECCN 6A003, only where hot billets blind visible cameras | Survives the mill environment while meeting country legality per model |
| Enclosures and power | Closed-loop cooled enclosures, vibration-damping mounts, surge protection, UPS with clean shutdown under NUT monitoring | A failing cooler is caught before the industrial PC cooks |
| Site networking | Hardened PoE industrial switches, VPN tunnel, IEC 62443 zoning | The camera zone stays segmented from mill control |
| Time synchronization | PTP grandmaster with GNSS and OCXO holdover, linuxptp per site | Count events reconcile across systems only on one clock |
| One-way transfer | Hardware data diode at the ingest edge | Counts cross in one direction only |
| Sensing | Caster strand, cooling bed, ejection path and enclosure cameras; laser counting heads as the alternative; weighbridge feed for acceptance; UPS and cabinet telemetry; furnace surge monitor | Matches the bid's allowance of video analytics, laser counting or equivalent technologies |
| Pattern | System of Context | The ontology is the foundational layer; edge aggregation, store-and-forward and read-only discipline map to it |

PART III · CHAPTER 9

## Shadow the Counts Before Anyone Trusts Them

Three phases, from a one-strand proof of concept against the bid's own accuracy tests to staged nationwide coverage, each gated on measurements rather than dates, keep the authority's trust ahead of the estate.

Chapter 8 fixed the models, their licenses and the hardware classes beneath them, including the export-controlled node that carries the agentic work surface. This chapter sets out the order in which that estate gets built and proven: three phases, each closed by a gate that is a measurement, never a date.

### 9.1  Three Phases, Each Closed by a Measurement

Rollout runs in three phases, shown in Figure 8, each with a fixed item count, named workstreams and exit gates written as acceptance tests rather than calendar promises. Phase 1, the proof of concept, carries 5 items across three workstreams: production context (the production ontology and its 14 objects), edge perception (per-product detection and counting models), and field installation (survey, camera positions and IPC mount on one casting strand or cooling bed at one mill). Its gate is the bid's own accuracy test: counted quantity must match the mill's weighbridge record per product type, workers and scrap carts must be excluded as noise rather than counted, and every published count must conform to the single count-event schema. Phase 2 carries 7 items across four workstreams: the operator's surfaces, the central platform, integration and operations. It builds the count-event API over the VPN, the Kafka event backbone and telemetry store, the live production dashboard, and the daily uptime and tamper discipline. Its gate is end to end: a count raised at an installation point must appear on the operator's dashboard ordered and deduplicated, and a simulated link failure must replay buffered events without loss or duplicate. Phase 3 carries 3 items: the agentic compliance work surface, the staged nationwide rollout against the bid's cumulative coverage milestones running to 31 December 2026, and the operator-adapted retraining loop. Its gate is operational: discrepancy cases must close through a named officer's decision with a complete record, and retraining must be run by operator staff rather than the vendor. Requirement coverage stands at 15 of 15 covered, none partial and none in gap, asserted at each gate rather than once at the end.

![Figure 8. The three phases and their gates, and coverage of the 15 requirements across them.](figures/figure_08.png)

Figure 8. The three phases and their gates, and coverage of the 15 requirements across them.

### 9.2  What the Rollout Measures

The rollout measures five things, and each maps to an object the design already carries. Counting accuracy per product type is measured against the mill's weighbridge record at acceptance and re-measured on a schedule thereafter, because accuracy is the bid's primary test and the figure any dispute will turn on. Drift telemetry per camera and input measures how dust, heat and lens fouling pull accuracy away from that acceptance floor. Availability percent and latency to the dashboard are recorded daily in the uptime record, so a mill can see whether a missing count is a detection problem or a network problem. The store-and-forward survival window is measured by deliberately cutting the link at the proof-of-concept mill and verifying replay. Reconciliation itself is measured as the rate of counted-versus-declared discrepancies and the time a field officer needs to close a case.

### 9.3  Failure Modes and What the Design Does About Them

Each failure mode below was carried as a risk through the design and answered inside it; Table 5 lists the five that shape the rollout most.

Table 5 · Failure Modes

| What fails | What the design does |
| --- | --- |
| Counting accuracy degrades as dust, heat and lens fouling accumulate after acceptance | Acceptance is treated as a floor: drift telemetry per camera and input, cleaning interval as a design parameter, and an operator-run retraining loop on labeled frames |
| Panel vendors publish inconsistent counts that break the single operator record | One published count-event schema, conformance-tested at the proof of concept, is a condition of panel authorization |
| Connectivity drops at remote mills lose count events | IPC-side store-and-forward buffer sized to a survival window; replay preserves order and dedup verdicts |
| The frontier GPU node is blocked by export licensing timelines | A licensing checkpoint sits in phase 1 at the dedicated data center; the work surface phases after the edge system is proven, so the program does not stall |
| The declared-production source stays undefined, blocking reconciliation | The open question is carried to kickoff; the workbench builds against the ontology so the adapter lands late without rework |

### 9.4  Lessons

**A gate that cannot be measured is a date in disguise.** The bid's milestones are dates, and a vendor under date pressure has every incentive to declare success early. The design converts each milestone into a test with a number attached, which is also the posture public procurement integrity guidance recommends for keeping buying decisions honest and documented (OECD n.d.).

**The bidding stage is where trust is cheapest to test.** Procurement fraud guidance treats the pre-contract stage as a recognized point where fraud concentrates (NHS 2025), so the design conformance-tests the count-event schema from every panel vendor before authorization rather than after.

**Shadow the counts before anyone trusts them.** During phase 2 the dashboard runs alongside the operator's declared figures with no enforcement attached; discrepancies are observed, not actioned, until the proof-of-concept accuracy has held long enough for the field officers themselves to treat the count as evidence.

### 9.5  What Is Still Open

Three questions remain open. The declared-production source is undefined in the bid; settling it fixes the adapter class and the reconciliation semantics, and until then the workbench builds against the ontology so the adapter lands without rework. The export license for the 141 GB GPU class sets the work surface's home; settling it decides whether the frontier model runs in the dedicated data center from phase 3 or waits on the unrestricted class. The per-point need for thermal cameras, warranted only where hot billets blind visible optics, is settled mill by mill at survey; settling it changes the bill of materials, not the architecture.

PART III · CHAPTER 10

## The Count Should Belong to the Authority, Not the Vendor

The object model, the fine-tuned weights, the count-event schema and the boundary are built so the operator owns them, and this chapter maps that ownership to CodeNinja's offer.

Chapter 9 ended with gates that hand the running system to the operator's own people. This chapter states who owns each layer the design builds, because ownership, not capability, is what separates monitoring from dependence.

### 10.1  Who Owns What the Design Builds

Four layers, four owners, and the owner is the operator in every case. The object model, 14 objects and their typed links held in the operator's own ontology store, is the operator's production context; the vendor maintains it on the operator's terms during the contract and hands it over in its recorded form. The weights and fine-tunes are the operator's property by license: the RF-DETR detection checkpoints carry Apache-2.0, so the per-product and per-mill fine-tunes trained on the operator's own frames belong to the operator outright, and the Apache-licensed tracking components keep the serving containers one clean license surface. The decision record, count events, calibration records, tamper alerts and reconciliation cases with their findings and resolutions, is kept as the operator's evidence, so the next audit reads the last decision rather than re-arguing it. The boundary, the hardware data diode at the ingest edge, the VPN tunnels and the segmented camera zone, is specified, owned and administered by the operator; counts cross it one way, and nothing from the operator's estate ever reaches mill control.

### 10.2  The Offer Behind the Design

CodeNinja designed this system on Praxis, the platform that produced this paper and every choice recorded in it, as a sovereign system by construction: Adaptive Operations is the sensing, detection and drift forecasting at the installation points; Hyper Ontology is the 14-object production model the whole estate hangs from; Decision Systems is the reconciliation and attribution that ends in a named field officer's decision; Hyper Pragma is the agentic work surface where revenue and audit staff build their own reconciliation agents against that model; and Sovereign Infrastructure is the posture that makes ownership real: open-weight licenses the operator holds, edge hardware the operator owns, and a one-way boundary under the operator's administration.

PART IV · CONCLUSION

## One Count Ledger Serves Any Output the State Must Measure

The design is one shape: sense the physical event where it happens, count it on models the operator owns, push the count through a one-way boundary into a single ontology-anchored record, and leave every judgment about discrepancies to a named officer on a surface built for that judgment. Nothing replaces a system of record, nothing leaves the boundary uncontrolled, and the first gate, a proof of concept on one casting strand against the bid's own acceptance tests, can stop the work cheaply.

Running the same shape elsewhere takes three commitments: harsh-environment discipline at the sensing layer, because dust, heat and fouling degrade every counter that is not maintained as a design parameter; one published event schema, because a panel of vendors without a shared contract aggregates into rework; and licensing clarity before hardware is ordered, because the frontier model that powers the work surface is export controlled and the placement decision follows the license, not the other way round. Any sector where a state must measure physical output it cannot observe directly, from minerals to timber to finished goods, can carry the same ledger.

PART IV · CHAPTER 11

## How Praxis Contextualized and Reasoned This Design

Every design in the series is produced on Praxis, and this closing chapter lets a reader trace each choice in the counting system back to the records and lenses that justified it.

Chapter 10 mapped the design's ownership onto the offer that stands behind it. This closing chapter turns to the design process itself, so a reader can trace any choice in the counting system back to the records and lenses that justified it. Every design in the series is produced on Praxis, and Figure 9 shows how this one was reasoned: the ask as pinned, the family and industry assigned, the records that were in the room, the eight lenses and the patterns they settled. Nothing in the chapters above is asserted without an entry on that figure.

### 11.1  The Ask, the Family and the Room

The ask arrived as a requirement document from a heavy industry and construction operator in Pakistan: a production monitoring and counting system, based on video analytics, laser counting or equivalent technologies, covering every steel melting and re-rolling unit in Pakistan against staged milestones, with accuracy tests and acceptance clauses written into the scope. Praxis assigned the design to the Physical AI family and the heavy industry and construction industry, and the assignment held: the hard parts of this problem are physical, dust and heat and optics and power, before any of them are computational. The room held 1,043 records, of which 133 were read in full and 910 were available on demand; the bid document itself, read in full, contributed the accuracy tests, the acceptance clauses and the staged milestones that became the gates in Chapter 9.

![Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.](figures/figure_09.png)

Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.

### 11.2  The Eight Lenses

Table 6 lists all eight lenses with what each could see, how many records it cited and what it contributed. Three lenses returned nothing that bore on the problem and are recorded as gaps rather than padded: no case study in the corpus covers a steel production-counting build, no regulation entry covers production monitoring in this sector, and no history note bears on counting at mills.

Table 6 · The Lenses and What They Contributed

| Lens | Could see | Cited | What it contributed |
| --- | --- | --- | --- |
| First principles | The pinned design brief | 1 | Dust, heat and vibration degrade cameras before people notice; harsh-environment store-and-forward; read-only discipline on mill control |
| Case studies | 39 case records | 0 | Gap: no steel production-counting build in the corpus; Everguard and Sight Machine read as associative guidance only |
| Tooling and recency | 438 tooling records | 5 | RF-DETR and GLM 5.3 checked live; serving, video ingest, tracking, labeling, registry, observability, identity and time sync rows from the shelf with verified versions |
| Hardware and equipment | 62 equipment records | 6 | Camera legality, enclosures and UPS, the data diode, the PTP grandmaster, the edge accelerator ladder, pixel-density rules and export controls on the frontier class |
| Rules and regulations | 406 regulation records | 0 | Gap: no corpus entry covers production monitoring in this sector; the bid's own accuracy, proof-of-concept and acceptance clauses bind instead |
| Approach | 61 approach records | 3 | Earned phases, smallest physical unit first and go/no-go gates: one strand, then staged coverage |
| History | 37 history records | 0 | Gap: no history note bears directly on counting at mills; the brief's precedents on one foundation and edge aggregation were read instead |
| Domain fusion | The pinned design brief | 2 | Every capability fused to a brief principle: edge aggregation, store-and-forward, read-only operational technology, ontology-first build order |

### 11.3  Patterns Adopted and Set Aside

System of Context was pinned as the primary pattern, with the ontology as the foundational layer and the sensing, kinetic-loop and reconciliation parts selected around it. Three practices were adopted with it: edge aggregation, so counts are reduced at the IPC before they cross the boundary; store-and-forward, so a lost link costs nothing counted; and read-only discipline on operational technology, so the system observes mill control and never touches it. An equal number were set aside: packaged video analytics appliances, because a boxed product rents its counting model and cannot be adapted per product type by operator staff; per-vendor native feeds, because a vendor panel needs one schema to aggregate; people and vehicle positioning, because workers in frame are a noise class to exclude, not subjects to track; a mid-tier site GPU server, because every inference has a home at the installation point or in the data center; and YOLO-class detectors, because their AGPL terms contaminate a serving estate the operator must own.

### 11.4  Where the Reasoning Lands

The reasoning lands on equipment classes, not part numbers: a sealed wide-temperature GPU IPC class sized from stream decode plus inference with headroom; an IP66/67 HDR camera class chosen from pixel-density tables per installation point, with thermal units stated with their export control classification only where hot billets blind visible optics; a hardware data diode; a PTP grandmaster with satellite timing and holdover; and one node of eight 141 GB accelerators in a dedicated data center for the frontier model. Every one of these is a recorded reading from the lens tables and the room's records, checked against the bid's clauses; nothing shown in this paper is inferred, and where a question could not be settled from the record, it was carried forward as an open question rather than answered quietly.

Appendix A

## What Ownership Costs Over Three Years

The design runs on hardware the authority owns: a counting kit at every installation point, and one frontier node in a dedicated data center where an export licence holds. This appendix prices that choice against renting the frontier node from a cloud region and against buying a closed frontier model by the token. Every input is a public price, dated and cited. The arithmetic is shown so any reader can rerun it with a written quote. The paper names the scale only in bands, hundreds of mills covered line by line, so the installation point count below is an assumption, stated where it is used.

### A.1 The Answer

Owning the stack this design specifies costs about **4,445,000 US dollars over three years** for 300 installation points, inside a range of 4,191,000 to 4,705,000. The counting kits are 2,832,000 of that and cannot be rented: cameras and industrial PCs sit at the mill in every option. The one line a cloud can replace is the frontier node, and owning it costs about **686,000 dollars** over three years against **0.75 million** on AWS's deepest three-year commitment, so ownership of the node is about the same as the cheapest rental. Renting that node also moves the counted record of every mill in the country outside Pakistan, which the design's first constraint rules out; no hyperscaler runs a region inside the country.

### A.2 What Owning Costs

| Line | Basis | Three-year cost (USD) |
| --- | --- | --- |
| Counting kit, per installation point | Advantech MIC-733-AO5A1, a fanless Jetson AGX Orin 32 GB industrial PC (Advantech 2026), 4,646; two Basler ace 2 IP67 5 MP GigE cameras at 699 dollars (Basler 2026); two Basler IP67 housings at 216.49 dollars (Basler 2026); one Advantech EKI-7708G-4FPI managed PoE industrial switch at list (Avendor 2026); one APC Smart-UPS SRT1500XLA double-conversion UPS (APC Guard 2026) | 9,441 each |
| Counting kits, 300 points | 300 installation points, one per casting strand or cooling bed: the paper's "hundreds of mills" covered line by line, taken here as an assumption | 2,832,000 |
| Frontier node | One server of eight 141 GB HBM-class cards, 320,000 to 420,000 dollars, typical 370,000 (Mercatus 2026) | 320,000 to 420,000 |
| Dedicated data center | One rack at a Gulf colocation guide rate of 18,000 dirhams a month, about 4,901 dollars (UAE Free Zone Finder 2026); Pakistani operators publish no rate, a quote settles it | 176,000 |
| Support | 8 to 12 percent of hardware value a year (Introl 2026) | 757,000 to 1,171,000 |
| Power | 30 kW across the kits at the mills plus 7 kW at the node at a power usage effectiveness of 1.6 (Uptime Institute 2025), 1,082,736 kWh at the industrial B3 average of 27 rupees per kWh (Dawn 2026), at 277.38 rupees to the dollar (SBP 2026) | 105,000 |
| **Total** |  | **4,191,000 to 4,705,000, typical 4,445,000** |

The frontier tier fits one node because GLM 5.3 is 753 GB at FP8 and needs 904 GB with headroom, against 1,128 GB on eight 141 GB cards. Each kit is sized at 100 W: an Orin class industrial PC at 60 W, two cameras and a switch.

### A.3 What Renting the Frontier Node Costs

The node, rented without a break for three years, because counts reconcile every filing period and the work surface answers through the day. The counting kits stay at the mills in every option and are included in each total at 3,759,000 with their support and power.

| Option | Basis | Node alone | Three-year cost with the kits (USD) |
| --- | --- | --- | --- |
| AWS, UAE region, on demand | p5en.48xlarge at 75.96 dollars an hour in me-central-1 (Vantage 2026) | 2.00 million | 5.76 million |
| AWS, UAE region, three-year EC2 Instance Savings Plan | all upfront, 28.56 dollars an hour (AWS 2026) | 0.75 million | 4.51 million |
| Specialist GPU cloud, on demand | 50.44 dollars an hour for eight H200 cards (CoreWeave 2026) | 1.33 million | 5.08 million |
| Oracle, three-year commitment | 40 dollars an hour for eight H200 cards (Economize 2026) | 1.05 million | 4.81 million |

Egress, storage and the network link from Pakistan to the region are excluded, so every rented figure is a floor.

### A.4 What Closed Models Cost by the Token

A closed frontier model replaces the frontier node rather than the kits, and it is priced by use. At 60 users (an assumed count across the revenue field officers and audit staff the paper names; it scales with the mills each officer owns), each running the equivalent of five agents at 2.4 billion tokens a year, with four input tokens to every output token and half the input served from cache, three years is 432 billion tokens.

| Model | List price per million tokens, input and output | Three-year cost (USD) |
| --- | --- | --- |
| Claude Sonnet 5.5 | 2 and 10 (Anthropic 2026) | 1.24 million |
| Gemini 3.1 Pro | 2 and 12 (Google 2026) | 1.42 million |
| Claude Opus 5.5 | 4 and 20 (Anthropic 2026) | 2.49 million |
| GPT-5.5 | 5 and 30 (OpenAI 2026) | 3.54 million |

The cheapest closed model costs about 21,000 dollars per user over three years, so it matches the owned node at about **33 users**; above that, ownership is cheaper and the gap grows with every user. Every closed option also sends the counted and declared production of every mill to a third-party AI service outside the boundary, which the design rules out.

### A.5 What the Price Does Not Include

- **Enclosure cooling, mounts, cabling and installation** at each point. No vendor publishes a list price for an actively cooled IP67 camera enclosure, so the kit prices the passive housings only; a written quote settles the rest.
- **An export licence.** Pakistan sits in US Country Group D:4, so the 141 GB HBM-class accelerators need a licence from the Bureau of Industry and Security (eCFR 2026); the design's licensing checkpoint confirms it before the node is ordered.
- **Import duty, sales tax, freight and insurance** on the hardware.
- **People, facilities and implementation**, which both sides carry.

### A.6 Sources for This Appendix

- Advantech. 2026. MIC-733-AO5A1. <https://buy.advantech.com/>
- Anthropic. 2026. Pricing. <https://claude.com/pricing>
- APC Guard. 2026. APC Smart-UPS SRT1500XLA. <https://apcguard.com/srt1500xla.asp>
- Avendor. 2026. Advantech EKI-7708G-4FPI-AE. <https://avendor.com/products/4g-4sfp-with-poe-wide-temp>
- AWS. 2026. EC2 Instance Savings Plans price file, me-central-1, 3 October 2026. <https://pricing.us-east-1.amazonaws.com/savingsPlan/v1.0/aws/AWSComputeSavingsPlan/current/region_index.json>
- Basler. 2026. ace 2 a2A2448-23gcIP67 and the ace 2 GigE camera housing. <https://www.baslerweb.com/>
- CoreWeave. 2026. Pricing. <https://www.coreweave.com/pricing>
- Dawn. 2026. NEPRA notifies new industrial tariffs. <https://www.dawn.com/news/1973828>
- eCFR. 2026. 15 CFR Part 740, Supplement No. 1, Country Groups. <https://www.ecfr.gov/current/title-15/part-740/appendix-Supplement%20No.%201%20to%20Part%20740>
- Economize. 2026. OCI BM.GPU.H200.8 pricing. <https://www.economize.cloud>
- Google. 2026. Gemini API pricing. <https://ai.google.dev/gemini-api/docs/pricing>
- Introl. 2026. GPU infrastructure TCO model. <https://introl.com/blog/gpu-infrastructure-tco-model-5-year-enterprise-ai-deployment>
- Mercatus. 2026. H200 server price. <https://mercatus-ai.com/blog/h200-server-price>
- OpenAI. 2026. API pricing. <https://developers.openai.com/api/docs/pricing>
- SBP. 2026. Conversion rates, 4 September 2026. <https://www.sbp.org.pk>
- UAE Free Zone Finder. 2026. UAE cloud computing and data center guide. <https://uaefreezonefinder.com/uae-cloud-computing-data-center-guide-2026>
- Uptime Institute. 2025. Global Data Center Survey 2025. <https://uptimeinstitute.com>
- Vantage. 2026. EC2 instance prices. <https://instances.vantage.sh>

SOURCES

## Source Register

Justice. 2007. USDOJ: US Attorney's Office , District of Massachusetts. <https://www.justice.gov/archive/usao/ma/news/BigDig/AggregatePleaPR.html>

OECD. n.d.. Recommendation of the Council on. <https://legalinstruments.oecd.org/public/doc/131/131.en.pdf>

NHS. 2025. Pre-contract procurement fraud and corruption. <https://cfa.nhs.uk/resources/downloads/guidance/fraud-awareness/quick-reference-guides/NHSCFA_Pre-contract_procurement_fraud_guidance.pdf>

---

### About CodeNinja

CodeNinja is a Middle Eastern-American artificial intelligence lab focused on building self-improving systems. We are reinventing knowledge work to close the loop between vertical AI use cases and the generalized intelligence that fuels it, accelerating the path toward organizational superintelligence.


---

# Structure Phase Watch: Live Production, Crane and Delivery Evidence for Every Pour on a Construction Site

Canonical: https://codeatoms.ai/structure-phase-construction-saudi-arabia/
DOI: https://doi.org/10.5281/zenodo.23126448
PDF: https://codeatoms.ai/structure-phase-construction-saudi-arabia/paper/structure-phase-watch-construction-saudi-arabia.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

VERTICAL-DRIVEN ARCHITECTURES · HEAVY INDUSTRY & CONSTRUCTION · DESIGNED WITH PRAXIS · OCTOBER 2026

# Structure Phase Watch: Live Production, Crane and Delivery Evidence for Every Pour on a Construction Site

One live model of the structure phase that joins precast production, crane utilisation and truck flow into a single picture, forecasts schedule slips three days out and shows safety breaches as they happen, for a heavy industry and construction operator in Saudi Arabia.

CodeNinja Engineering Team

For the construction director accountable for the structure phase, the planning, crane coordination and HSE leads beside them, and the platform, data integration and computer vision engineers who would build and run it.

---

Vertical-Driven Architectures is a CodeNinja series of system designs. Every design in the series is driven by a real-world problem and scenario in a single industry, and every one is designed on Praxis, CodeNinja's platform for designing physical AI systems. Operations are described by class, never by name.

At a glance

## Three-day schedule slip forecasts for a construction site in Saudi Arabia

**What this is.** An open reference architecture for system design in physical AI: one live model of a construction site's structure phase that forecasts schedule slips three days out and shows safety breaches as they happen, on the contractor's own hardware inside the Kingdom. It is written for construction directors and for the engineers who would build it. The operator is an illustrative scenario, not a CodeNinja customer.

**The answer in numbers.**

| Part | The design |
| --- | --- |
| Sources joined | 12 systems, including Primavera P6, batch plant SCADA, the casting bed register, the lift schedule, crane anti-collision logs, haulage GPS, gate logs and biometric turnstiles |
| Object model | 15 typed objects and 12 links, published as JSON for reuse |
| Models | 5 self-hosted open models: GLM 5.3 (reasoning), Chronos-2 (forecasting), BGE-M3 (multilingual retrieval), RF-DETR (vision), Roboflow trackers |
| Frontier compute | One node of eight 141 GB HBM-class GPUs holds GLM 5.3 at FP8 (753 GB of weights, 904 GB with headroom) |
| Edge | Five Jetson Orin class nodes in solar powered enclosures at the gate, laydown, crane slew zone, batch plant and haul road |
| Three-year cost, owned | About 642,000 US dollars with support and power at the Saudi industrial tariff |
| Three-year cost, rented | 1.41 million to 2.81 million US dollars for the same GPUs around the clock; ownership is about one half the cheapest three-year commitment |
| Closed model break-even | The cheapest closed model matches the owned stack at about 31 users; above that, ownership is cheaper and the gap grows with every user |
| Human control | Every re-sequencing is a recommendation a named planner approves; every breach alert is confirmed, dismissed or escalated by the HSE officer |

**Reuse it.** The object model, the model register and the figures are free to reuse under CC BY 4.0. Cite as DOI <https://doi.org/10.5281/zenodo.23126448.>

**Made with.** Reasoned on [Praxis](<https://codeatoms.ai/praxis/>), CodeNinja's platform for designing physical AI systems. The object model imports into [Hyper Ontology](<https://codeatoms.ai/hyper-ontology/>), which turns it into a living system. Both are in beta; access by request.

ABSTRACT

## A Slip Should Be Forecast Three Days Out, Not Found at the Thursday Meeting

Why is the structure phase slipping, and where is the struck by and dropped load exposure that causes both delay and injury? Today the joint venture cannot answer either question while it can still act: precast curing state lives in a casting bed spreadsheet, planned lifts live in a separate Excel schedule, truck movements live on paper gate logs, and the owner's Primavera P6 baseline lives with the planning team, so a slip is discovered at the weekly look ahead meeting a week after it begins, and near misses reach HSE on incident forms filed the next day.

The design joins twelve source systems through three adapter families into fifteen objects the joint venture owns: the precast register, the lift schedule, the gate flow, the crane logs and the owner's baseline become one live model of the structure phase, watched by edge cameras at the gate, laydown areas and crane zones. Eight services and six surfaces run on joint venture servers in the site data room, with detection at solar powered edge nodes and reasoning in country, so a slip is forecast three days early, a breach is seen while it happens, five models carry the load, and every re-sequencing output stays a recommendation a named person approves.

The paper opens with the problem and the join failure that keeps four systems blind together, then lays out the constraints, the stack, the object model, ingestion, inference placement and the model and equipment register, before turning to rollout in three phases with gates, ownership of everything the design builds, and the closing chapter on how Praxis contextualized and reasoned the design.

---

![Figure 1. Structure Phase Watch on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.](figures/figure_01.png)

Figure 1. Structure Phase Watch on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.

## Contents

Each chapter is tagged for the reader it serves most directly: Executive, Team Lead, FDE, Reference.

|  |  |  |
| --- | --- | --- |
|  | Abstract · A Slip Should Be Forecast Three Days Out, Not Found at the Thursday Meeting | Executive |
| PART I · THE PROBLEM | | |
| 1 | [A Slip Shows a Week After It Begins](#ch1) | Executive |
| 2 | [Every Site System Sees One Slice of the Phase](#ch2) | ExecutiveTeam Lead |
| PART II · THE DESIGN | | |
| 3 | [Four Constraints Shape the Live Structure Phase Model](#ch3) | Team Lead |
| 4 | [One Stack Runs From Gate Log to Look Ahead](#ch4) | Team LeadFDE |
| 5 | [Fifteen Objects Turn Site Data Into One Argument](#ch5) | FDE |
| 6 | [Each Source Enters Through an Adapter](#ch6) | FDE |
| 7 | [Detection Runs at the Edge and Reasoning Stays in Country](#ch7) | FDE |
| 8 | [The License Decides What the Operator Can Own](#ch8) | FDEExecutive |
| PART III · THE ROLLOUT | | |
| 9 | [Shadow Mode Comes Before Any Flag Is Trusted](#ch9) | Team LeadExecutive |
| 10 | [The Record Stays with the Fleet That Produced It](#ch10) | Executive |
| PART IV · HOW IT WAS DESIGNED | | |
|  | Conclusion · One Live Picture, Built From Records the Site Already Holds | Executive |
| 11 | [Every Choice Traces Back to a Recorded Reading](#ch11) | Team LeadFDE |
|  | [Sources](#sources) | Reference |

PART I · CHAPTER 1

## A Slip Shows a Week After It Begins

The joint venture discovers schedule loss and safety exposure after they have already cost the program, because the evidence of both is captured but never joined.

The abstract states the design in one paragraph and Figure 1 sets the whole shape on one page. This chapter opens the problem that shape answers: the question the joint venture needs answered continuously, the documented cost of answering it a week late, and the operation, described by class, that holds the evidence.

### 1.1  The Question, the Data and the Regulatory Ground

The operation needs one question answered every morning: is the structure phase about to slip, and where is the exposure that will cause the next injury? Answering it requires joining four streams that today never meet: precast production against the pour sequence, which means cast dates, curing state and quality release for every unit; crane utilisation against the lift plan, which means planned lifts per crane set against the loads, radii, wind stops and alarms the cranes actually logged; truck flow, which means gate movements, queue depth at each gate, and tracker position against each assigned delivery window; and the people and equipment conflicts, which means permits, workforce presence by zone, and entry into a crane slew radius or an exclusion zone under a suspended load. Beneath all four sits the schedule of record: planned dates, float and pour and lift codes in the owner's baseline and the joint venture's own fragments of it. The regulatory ground is layered. Work must satisfy the Saudi Building Code, the occupational safety regulations of the ministry responsible for labor and social development, and the project owner's HSE standard, which the joint venture works to contractually. The summer midday work ban, from noon to mid afternoon between mid June and mid September, removes three working hours from every outdoor crew, which tightens every delivery window the sequencing logic will touch and makes morning surges unavoidable. Data discipline itself is becoming a formal regime on projects of this class: industry guidance now expects a written data management plan before project data is collected and shared (AGS 2024), and major public owners treat data management for investigation and monitoring data as an explicit contractual requirement (ARMY 2025). A design that leaves the record fragmented inherits those obligations without the controls that satisfy them.

### 1.2  The Documented Cost

The cost of fragmented site data is documented, and it lands twice. First as schedule loss that compounds quietly: a slip that begins on a Monday and surfaces at the Thursday look ahead has already consumed its curing time, its idle crane hours and its queue delay, and the evidence of why it began has been cleared away with the queue. Second as legal and regulatory exposure over data the firm already held. A court in the United States sanctioned a civil construction contractor with an adverse inference for failing to preserve electronic data from five custodians, converting an operational dispute into a case outcome the contractor could not defend (Minerva26 2023). A privacy watchdog in South Korea fined a construction equipment firm over an employee data leak, a penalty that attaches to the handling of workforce records rather than to any physical failure (YNA 2026). Both failures are of the kind this design is built to prevent: evidence captured but never joined, kept or controlled.

### 1.3  The Operation as a Scenario

The scenario is a precast and site logistics joint venture on a giga project in the Riyadh region: a mixed use district of roughly two square kilometers in its heavy civil and structure phase. The joint venture runs one precast yard casting hollow core slabs, facade panels and stair units; one batching plant; more than a dozen tower cranes and half a dozen crawler cranes spread across four work zones; a fleet of flatbed and mixer trucks in the tens on a single internal haul road a few kilometers long; and a workforce in the thousands across its own crews and about a dozen subcontractors. Six role groups live inside this evidence every day: a planning manager with a small planning team owning the look ahead; a crane coordinator with lift supervisors; a yard manager with a quality lead; an HSE manager with officers; a logistics controller working the gates; and the subcontractor supervisors whose crews occupy the zones. The physical environments are demanding: open air zones with dust, glare and summer ambient heat that degrades lenses and electronics; gates and laydown areas where mains power is scarce, so sensing runs from solar powered enclosures; and tower crane slew zones whose suspended loads cross the same ground the workforce occupies. The counts that size the design are twelve named source systems, six role groups, and a place set of four work zones, one precast yard, one batching plant, the main gates, the laydown areas and the haul road.

PART I · CHAPTER 2

## Every Site System Sees One Slice of the Phase

Each existing system holds a true fragment of the structure phase, and the answer to the slip and exposure question lives in the fragments none of them share.

Chapter 1 defined the question and the operation that holds the evidence. This chapter shows why the operation cannot answer the question today: every system holds a true fragment of the structure phase, and the answer lives in the fragments none of them share. Figure 2 sets each system's sees and misses side by side.

### 2.1  What Each System Sees, and What It Misses

The schedule of record, Primavera P6, sees planned dates, float and pour and lift codes for the owner's baseline and the joint venture's fragnets; it misses everything that happens between exports, so a slip exists there only after someone edits the plan to match reality. The precast register spreadsheet sees cast dates, curing state and quality release for every bed and unit; it misses the pour and the crane waiting on the unit, so a curing delay looks like a yard number with no downstream consequence. The batch plant SCADA sees every ticket, with mix design, batch time, temperature and quantity against a target pour; it misses erection, so a slow pour cycle leaves no trace of the delivery chain that caused it. The Excel lift schedule sees planned lifts per crane; it misses what the cranes actually did, which lives in the anti-collision systems' logs of load, radius, wind state and alarms. The haulage contractor's GPS portal sees where the tracked trucks are against their windows; it misses the gate queue and the untracked mixers. The paper gate logs see one line per movement; they miss anything until a hand transcribes them, and no process joins them to a window or a crane. Crawler crane telematics sees hours, location and fault codes but has no planned-lift denominator. The HSE document system sees yesterday's forms, never a live breach. The biometric turnstiles see presence at the main gates but not which zone, permit or load path each worker was exposed to. The weather station sees wind and temperature but not which lift each reading stopped. The paper permits see who may work in a zone but not the conflicts between overlapping permits and crane operations.

![Figure 2. Twelve systems, each seeing one part of the answer. the question needs all of them in one place at once.](figures/figure_02.png)

Figure 2. Twelve systems, each seeing one part of the answer. the question needs all of them in one place at once.

### 2.2  What None of Them See Together

What none of them see is the same event three times: panel curing running behind at the yard, a tower crane idle through a large fraction of its shift waiting for deliveries, and the haul road gate backed up with a queue of trucks because two zones called the same delivery window. Those are three records of one failure in delivery sequencing, and no existing system can hold them together. The cost in practice is precise: the slip is discovered at the Thursday look ahead a week after it began, and HSE learns of a crane or truck near miss from a form filed the next day, when the laydown area that produced it has already reset for the next morning's surge.

PART II · CHAPTER 3

## Four Constraints Shape the Live Structure Phase Model

Sovereignty over the record, no replacement of systems of record, decisions reserved to named people, and a cheap first gate define what the design may do before any architecture is chosen.

Chapter 2 showed the fragments and the cost of never joining them. This chapter fixes the four constraints the join must respect before any architecture is chosen, because each one is hard in this industry for a specific reason.

### 3.1  The Record Stays Sovereign

Every weight, every detection and every decision record stays on joint venture hardware in the site data room, inside the Kingdom, beside the record it reasons over. This is hard because the convenient path runs the other way: hosted model services and off-site analytics are one contract signature away, and the temptation grows with every capability the design adds. It is also hard because the record is personal: biometric turnstile data identifies individual workers across about a dozen subcontractors, and workforce data handling now carries regulatory penalty exposure in this industry, as a recent fine over an employee data leak at a construction equipment firm shows (YNA 2026). Contracts on projects of this class increasingly carry explicit data safeguarding duties, which makes the boundary a contractual fact as much as a technical one (Acquisition n.d.).

### 3.2  No System of Record Is Replaced

The design reads every source and writes back to none of them. Primavera P6 stays the planning team's tool with the owner's baseline untouched; the casting register stays the yard's spreadsheet until the joint venture itself decides otherwise; the paper permit keeps its legal force. This is hard because a read-only posture must still earn daily use from people whose own tools keep working, and because data management guidance treats source systems as governed records whose custody and quality are owned, not bypassed (AGS 2024). The only write path in the whole design is the object model the joint venture owns, which accumulates the joined record without editing a single source.

### 3.3  Every Decision Stays with a Named Person

Re-sequencing deliveries, accepting a slip forecast and closing a breach all end at a named person: the crane coordinator, the planning manager, the HSE manager. This is hard because the moment of value is the 06:00 delivery surge, exactly when a human approval loop is most tempting to automate away, and because a recommendation that arrives without a clear owner tends to be either ignored or obeyed blindly, and neither is accountability.

### 3.4  The First Gate Must Be Cheap to Stop

Phase one proves the joint venture's own hypothesis, that recoverable loss is crane idle time caused by delivery sequencing rather than crane count, on one zone, across nine items, behind one exit gate. This is hard because construction pilots habitually scale before they prove, and a design that cannot be stopped cheaply at its first gate has not been scoped honestly.

### 3.5  Scoping Decisions

Three decisions set the boundaries within which the rest of the design follows. Table 1 states what each buys and what each costs.

Table 1 · Scoping Decisions

| Decision | What it buys | What it costs |
| --- | --- | --- |
| Everything runs on joint venture servers in the site data room | The weights, the detections and the decision record stay inside the Kingdom beside the record | The joint venture buys, powers and cools its own GPUs, including the frontier node |
| Read-only integration with all twelve source systems | No change orders against the schedule, the plant or the yard, and no risk to any system of record | The picture is as fresh as the exports, daily for the schedule of record |
| Phase one proves the hypothesis on one zone | A cheap first gate: the work can stop after nine items if the evidence contradicts the hypothesis | The other three zones and any automation of gate windows wait behind the gate |

### 3.6  What the Design Chose Against

Each rejection below was made for a stated reason, not by omission, and the last row records what is out of scope entirely. Table 2 sets them out.

Table 2 · What the Design Chose Against

| Where | What was picked | Instead of, and why |
| --- | --- | --- |
| Camera detection | Fine tuned open vision model on site footage, served on joint venture edge nodes | Packaged site safety vision product: the joint venture must own the weights and keep detections inside the site data room, and a packaged product rents exactly that part |
| Schedule integration | Daily XER or XML file exports from the planning team | Direct Primavera P6 API access: owner consent is not confirmed, so files carry the design and the API stays an upgrade behind a consent checkpoint |
| Language model serving | One self hosted node in the site data room holding the frontier weights | Hosted model services or early migration to the owner's sovereign cloud region: the weights must sit beside the record they reason over, and migration stays a later option the joint venture may take |
| Gate automation at go live | Re-sequencing outputs as recommendations a named person approves | Direct gate booking and subcontractor notification: automation waits for the one zone trial, under rules the crane coordinator sets |
| Out of scope | No procurement of new cranes or trucks, no physiological wearables, no network build | The design works the existing crane and truck fleets as they are, uses the existing private LTE and fibre with buffered edge uplinks, and keeps field facing output as schedule constraints and translated alerts |

PART II · CHAPTER 4

## One Stack Runs From Gate Log to Look Ahead

Systems of record sit below, one object model holds the middle, and the services and surfaces the planners and HSE officers use sit above, so a single pattern carries the whole design.

Chapter 3 fixed the four constraints the design must honor: the twelve systems of record stay in place untouched, every byte stays inside the joint venture's own perimeter, every re-sequencing output remains a recommendation a named person approves, and the first gate can stop the work cheaply on one zone. This chapter shows the single architectural pattern that satisfies all four at once, and names the components at every stage of the stack.

### 4.1  Records Below, One Model in the Middle, Decisions Above

The design is a three-layer pattern. Below sit the systems of record: the owner's Primavera P6 baseline, the batch plant SCADA, the casting bed register, the lift schedule, the gate logs and the rest, all left exactly where they are and all read only. In the middle sits one object model that holds the fifteen typed objects of the structure phase and the links between them. Above sit the eight services that read that model and the six surfaces where the planning team, the crane coordinator, the yard manager and the HSE officers make their calls. Figure 3 shows the layered stack with the component counts per layer: twelve sources, three adapter families, fifteen objects, eight services and six surfaces, on JV hardware in the site data room. The pattern fits because the problem defined in Chapter 2 is a join failure, not a missing feature in any one system. Point-to-point integrations would multiply the join problem by pairing systems two at a time; a shared object model pairs every system once, against the model. The same pattern also serves the sovereignty constraint: because the middle layer is the only place systems meet, the perimeter needs only one defended interior rather than a mesh of connections, and because no adapter ever writes back to a source, the systems of record carry no new risk.

![Figure 3. The layered stack: 12 sources, 3 adapter families, 15 objects, 8 services and 6 surfaces.](figures/figure_03.png)

Figure 3. The layered stack: 12 sources, 3 adapter families, 15 objects, 8 services and 6 surfaces.

### 4.2  The Stack Stage by Stage

Each stage of the stack owns one job and hands a defined artifact to the stage above it, from raw records at the bottom to the six decision surfaces at the top. Table 3 names the components at every stage and states what each is responsible for and how it does it.

Table 3 · The Stack, Stage by Stage

| Stage | What it is responsible for | How |
| --- | --- | --- |
| Sources | Holding the records every judgement is checked against: the owner's Primavera P6 baseline and fragnets, batch plant SCADA, the casting bed register and QC release spreadsheet, the Excel lift schedule, the haulage contractor GPS portal, paper gate logs, crane anti-collision logs, crawler crane telematics, the HSE document system, biometric turnstiles, the site weather station and paper permits to work | Read only; no component in the stack ever writes back to a source |
| Sensing | Capturing the physical reality the records miss: truck queues at the gate, exclusion zone entry, workers inside a slew radius, laydown dwell | Five camera streams on solar powered Jetson Orin edge nodes running Frigate NVR and ONNX Runtime, with RF-DETR detections tracked by the Roboflow trackers library of the ByteTrack class; plus anti-collision logs, telematics, GPS, weather and turnstile feeds |
| Adapters | Turning twelve heterogeneous inputs into one ordered event stream, tagged with provenance and aligned to one clock | Three adapter families, telemetry, integration and file and doc, publishing to Apache Kafka 4.3.x in KRaft mode with three dedicated controllers, time aligned by Linuxptp and chrony against an OCP Time Card GNSS grandmaster |
| Object model | Holding the fifteen typed objects and their links as the one live model of the structure phase | The graph store of the object model beside InfluxDB 3 Core for telemetry history, both inside the JV perimeter |
| Inference | Detecting breaches at the edge, forecasting slips, embedding records and reasoning over the model | RF-DETR on the edge nodes; Chronos-2 and BGE-M3 on an eight by L40S class server; the frontier work surface model on one node of eight 141 GB HBM GPUs served by vLLM; versions held in Harbor and MLflow, labels in CVAT |
| Services | Running the eight named services: structure phase model, records and permits, camera and edge detection, HSE live breach detection, sovereign platform, forecasting, logistics re-sequencing and the agentic work surface | Containers on K3s inside the JV perimeter, observed through Prometheus, Grafana and Loki, with identity and access through Keycloak |
| Surfaces | Presenting the six decision surfaces where planners, the crane coordinator, the yard manager and HSE officers decide | Look-ahead and slip cause surface, lift and delivery re-sequencing console, yard production and QC panel, live breach and daily HSE summary view, gate queue and delivery window console, weekly structure phase view |

PART II · CHAPTER 5

## Fifteen Objects Turn Site Data Into One Argument

Cranes, units, tickets, trucks, permits, workers, zones and pours become typed objects whose links let one query reach the story behind any slip, with every write passing through a person.

Chapter 4 placed one object model in the middle of the stack. This chapter opens that model: the fifteen objects it holds, the typed links that let a query cross from a delayed pour to the crane that waited for it, the place a person sits in every write, and the hosting posture that keeps the whole thing inside the joint venture's boundary.

### 5.1  Fifteen Objects and the Typed Links Between Them

The model holds fifteen objects in five kinds. Four are assets that do the work: tower\_crane for the 14 tower cranes and crawler\_crane for the 6 crawler cranes, casting\_bed and precast\_unit for the yard's output, and truck for the 60 vehicle fleet. Four are records: batch\_ticket from the plant SCADA, p6\_activity from the owner's baseline and the joint venture's fragnets, permit from the paper permit to work system, and hse\_observation from the incident and observation forms. Four are events: gate\_movement, delivery\_window, lift\_plan\_entry and pour. One is a person, worker, anchored in the biometric turnstiles, and one is a place, zone, covering the four work zones. Figure 4 draws every object and every typed link between them, with the pour as the focal object because the pour is where schedule and safety meet. The links are what make the model an argument rather than an archive. Start at a pour showing status Delayed and the query reaches the batch tickets behind it, the precast units and their casting beds and curing state, the p6\_activity that carries the float, the delivery\_window objects and the trucks and gate\_movements that explain whether the delay arrived by road, and the tower cranes and lift\_plan\_entries that show what idled while it waited. The same query continues into the zone, the permits active there and the workers present, which is the exposure picture an HSE officer needs. A document store can hold each of these records but cannot traverse between them, so each answer would be a separate search in a separate system; here one query reaches the whole story, which is exactly what the Thursday look-ahead meeting cannot do today.

![Figure 4. The fifteen objects of the model and the typed links that let a query reach across them.](figures/figure_04.png)

Figure 4. The fifteen objects of the model and the typed links that let a query reach across them.

### 5.2  Where the Human Loop Lives and How the Model Is Hosted

The human loop sits at the only write path into the model that changes an operational plan. Every re-sequencing output, every proposed delivery window and every recommended look-ahead draft is a recommendation; the planner or the crane coordinator approves it, and the approval, the approver and the reasoning are recorded with the decision. Breach detections behave the same way: the system raises the alarm while it happens, and the HSE officer confirms, dismisses or escalates it, so the model never closes a gate or stops a lift on its own. The hosting posture follows the constraint set in Chapter 3. All fifteen objects live on the joint venture's own servers in the site data room, with the Riyadh office as the second site and the owner's sovereign cloud region held as a later alternative, so no object, clip or embedder output leaves the Kingdom. Identity runs through Keycloak with a role per surface, and the employee data the model holds is exactly the class of record whose leakage draws regulator fines elsewhere in the industry (YNA 2026), which is why the perimeter, the roles and the retention rules are design constraints rather than settings. External links are bounded: camera clips are referenced by identifier and stored inside the perimeter, and the only outbound integration is the read of the owner's P6 export. The data management discipline the model enforces, one schema, one clock, one provenance tag per record, follows the same structured plan-first practice published for engineered projects (AGS 2024).

### 5.3  One Object in Its Recorded Form

The tower crane object shows the recorded form the other fourteen follow: an identifier, a label, a kind, typed properties, a closed status vocabulary of five states from Planned lift to Out of service, and links to the lift schedule entries and anti-collision events that feed its utilisation figure.

```
{
  "id": "tower_crane",
  "label": "Tower crane (TC-01 to TC-14)",
  "kind": "asset",
  "anchored_in": "Excel lift schedule",
  "properties": [
    "Crane ID (TC-07)",
    "Load and radius from the anti-collision system",
    "Wind interlock state",
    "Alarm events",
    "Shift utilisation"
  ],
  "status_vocabulary": [
    "Planned lift",
    "Lifting",
    "Idle waiting for delivery",
    "Wind stopped",
    "Out of service"
  ],
  "links": [
    {
      "to": "lift_plan_entry",
      "label": "executes"
    }
  ]
}
```

PART II · CHAPTER 6

## Each Source Enters Through an Adapter

Twelve systems of record enter through three adapter families onto one event backbone, so a paper gate log and a batch ticket arrive with the same guarantees.

Chapter 5 defined what the object model holds and who may write to it. This chapter describes how data reaches it: which twelve systems enter, what the three adapter families guarantee on the way in, and what the event backbone does with every event once an adapter has published it.

### 6.1  Twelve Sources, One Integration Map

Twelve named systems feed the model, and Figure 5 maps each one to its adapter path. The owner's Primavera P6 baseline and the joint venture's fragnets arrive as daily XER or XML exports from the planning team, with the REST API held as an upgrade behind an owner consent checkpoint. The batch plant SCADA of the Command Alkon style is integrated as a read-only historian mirror on the joint venture's own network, so no OT zone is crossed. The casting bed register and QC release spreadsheet, the Excel lift schedule and the paper gate logs enter through the file and doc adapter family, the gate logs after the one zone's paper digitisation in phase one. The haulage contractor GPS portal and the 20 proposed trackers for the untracked mixers enter through the telemetry family, as do the crane anti-collision systems of the SMIE and AMCS style, the crawler crane telematics, the site weather station and the biometric turnstiles. The HSE document system and the paper permits to work enter through the integration and file and doc families respectively. Every source carries the same provenance class, an operator system of record, and every integration is read only, so the design changes no system it depends on.

![Figure 5. The 12 named systems, the adapter path each one takes, and the object model they all map into.](figures/figure_05.png)

Figure 5. The 12 named systems, the adapter path each one takes, and the object model they all map into.

### 6.2  What the Adapter Tier Guarantees

Each adapter family makes the same five guarantees regardless of what it reads. It normalizes its source into the one schema of the target object, so a paper gate log line and a GPS ping both become events a single query language can join. It stamps every event with a source timestamp resynchronized against the site grandmaster clock, because a join between crane alarms and gate times is worthless if the two clocks disagree by minutes. It carries provenance on every event: source system, adapter family and the record identifier in the origin system, so any figure on any surface can be traced back to the record it came from, the traceability that formal data management guidance for monitored works demands (ARMY 2025). It replays idempotently, so re-reading a day of P6 exports or a resubmitted spreadsheet produces no duplicate objects. And it handles schema drift in the spreadsheets explicitly, quarantining a malformed register rather than silently mis-typing a curing date.

### 6.3  The Event Backbone

Everything an adapter publishes lands on Apache Kafka 4.3.x running in KRaft mode with three dedicated controllers inside the site data room. Ordering is by event key, so all events for one crane, one truck unit or one gate arrive in sequence and the utilisation and queue calculations never see time run backwards. Delivery is at least once with idempotent consumers, which pairs with the adapters' replay guarantee to make the backbone safe to restart. Buffering follows the failure mode the project itself named: the edge nodes buffer hours of private LTE disconnection before forwarding, sized generously, so a patchy link under a crane zone delays a stream rather than losing it. Replication keeps three copies of every topic across the data room cluster with retention long enough that the Thursday look-ahead can replay the full week, and because the whole estate sits inside one joint venture perimeter, no event crosses a boundary on its way from a gate log to a planner's screen.

PART II · CHAPTER 7

## Detection Runs at the Edge and Reasoning Stays in Country

Camera detection and counting run on solar powered edge nodes where the connection is weakest, forecasting and the work surface run on the operator's own servers, and only compact events cross the boundary.

Chapter 6 closed the path from source to backbone: every system enters through an adapter and lands as ordered events on the streaming layer. This chapter places the compute that watches those events, because where a model runs decides whether a breach alert survives a dropped link.

### 7.1  Three Tiers, Each Placed Where Its Work Is Cheapest

Figure 6 shows the three inference tiers. The lowest tier is the edge: Jetson Orin industrial edge class compute in solar powered IP66 enclosures with NUT managed UPS and sunshields, placed at the main gate truck queue, laydown area east, the crane TC-07 slew zone, the batch plant loading bay and the haul road junction. Each node runs detection and tracking locally under K3s: RF-DETR served through ONNX Runtime finds flatbeds, mixer trucks, workers, precast panels, suspended loads and tower cranes, and the ByteTrack class tracker holds identity across frames for queue counts, dwell and slew radius entry. Frigate NVR records beside it. The edge exists because private LTE coverage at laydown areas and under crane zones is patchy: detection at the point of risk must not depend on a stream that drops. The middle tier is the site inference server in the site data room, eight L40S class PCIe GPUs of 48 GB class each. It runs Chronos-2 forecasting over the series held in InfluxDB 3 Core, BGE-M3 embeddings for retrieval across permits, forms and work surface queries, and the cross zone aggregation behind live breach detection. The top tier is one node of eight 141 GB HBM GPUs (H200 class) serving GLM 5.3 for the agentic work surface. The arithmetic is the register's: 753 billion parameters at FP8, one byte per parameter, give 753 GB of weights; multiplied by 1.2 for KV cache and activations, the node must hold 904 GB; its 1,128 GB holds that, leaving about 224 GB of headroom that covers concurrent planner sessions rather than weights. The frontier weights sit on JV hardware inside the Kingdom beside the record they reason over, and the 141 GB HBM class ships to Saudi Arabia only under a US export licence, so the frontier node's order date is a phase one checkpoint on the licence timeline.

![Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.](figures/figure_06.png)

Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.

### 7.2  The Latency Budget

Three clocks govern the design, and each is set where its work runs. The breach clock is an edge clock: camera frame cadence at the node, alarm raised locally, the uplink notified afterwards, so no network condition delays an alert about a worker inside a slew radius. The forecast clock is a site clock: Chronos-2 refreshes the slip picture daily against the P6 export and continuously against the streaming telemetry, and a three day horizon only has to beat the Thursday look ahead, not the second hand. The reasoning clock is a local area network clock: work surface prompts round trip to the H200 node in the same building as the object model, with no public internet hop, which is what makes an interactive session over a 753 billion parameter model practical on JV hardware.

### 7.3  What Crosses the Boundary and What Fails

What crosses from edge to data room is compact: detections, counts, tracker identities, alarm states and buffered telemetry samples, not continuous video. Video stays on the node, and a clip leaves only as a referenced artifact on an HSE form. When the link fails, the buffered uplink is sized for hours of disconnection and then doubled; local inference continues, so the gate keeps counting a queue it cannot yet report. When power or heat fails, the NUT managed UPS rides through interruptions, the enclosure thermal budget including solar gain is engineered before installation, and internal enclosure temperature is monitored as a first class signal, because dust, glare and 50 C summer ambient present as accuracy loss before they present as outages. When the update path fails, nothing breaks: Harbor holds container images and MLflow holds model versions in the air gapped registry, nodes run the last promoted version, and a new model reaches the edge only through that registry, never through the internet.

PART II · CHAPTER 8

## The License Decides What the Operator Can Own

Five models carry the design, and each is chosen so the joint venture can hold its weights, fine tune them and keep every output inside the site data room.

Chapter 7 placed the compute: detection at the edge, forecasting and aggregation in the data room, one frontier node for reasoning. This chapter names the models that run there and the licenses that make owning them possible.

![Figure 7. The five models, their placement, and the work each one does.](figures/figure_07.png)

Figure 7. The five models, their placement, and the work each one does.

### 8.1  The Frontier Language Model and Its License

Figure 7 shows the model stack. GLM 5.3 open weights is the register's one frontier class model, at 753 billion parameters filed, run at FP8 on the single H200 class node in the site data room. Its role is the agentic work surface and ontology maintenance: the planning manager and four planners, the crane coordinator and lift supervisors, the yard manager and QC lead, and the HSE manager and officers build and run their own checks and daily agents on the live structure phase model, for example a daily agent naming every crane under 50 percent utilization and its cause. The license is a bespoke GLM-5.3 license that permits commercial use, fine tuning and redistribution, which is what lets the JV hold and improve its own copy. Its one trigger, a security review for a model as a service business above USD 10 billion group revenue in twelve months, does not apply to internal JV use; the corporate group position is confirmed at contracting and the attribution notice is recorded.

### 8.2  Vision, Tracking, Forecasting and Retrieval

Four open models carry the rest. RF-DETR is the detection and segmentation model, Apache-2.0 licensed across the rfdetr package and its Nano to Large detection checkpoints, fine tuned on site footage and served on the edge nodes through ONNX Runtime and at the site tier: it finds the flatbeds, mixer trucks, workers, precast panels, suspended loads, tower cranes and truck queues the design watches. It was chosen against a packaged site safety vision product because the packaged product rents the exact weights the sovereignty clause requires the JV to own and harden. The Roboflow trackers library, a ByteTrack class tracker under Apache-2.0, supplies motion only identity for queue counts, laydown dwell and slew radius entry, chosen over the BoxMOT collection to avoid AGPL exposure. Chronos-2 is the universal forecasting model, Apache-2.0 with no field of use restriction, so weights may be held, fine tuned and redistributed; it turns the InfluxDB series into the three day pour slip forecast, gate queue projections and utilization trajectories. BGE-M3 is the hybrid multilingual embedder under MIT, running from the device tier to the site tier: a workforce whose records carry language tags across the JV and its 11 subcontractors needs retrieval that spans permits, HSE forms and work surface questions in more than one language. Holding worker records inside the boundary is more than a preference; a privacy regulator fined a construction equipment maker 73.5 million won over an employee data leak (YNA 2026).

### 8.3  The Model and Equipment Register

Table 4 collects the register: each model, each hardware class and sizing rule, the sensing the design stands on, the patterns it follows, and the ground it runs on. The discipline the register records is the one public guidance asks of engineered projects: state what data exists, who holds it and under what terms (AGS 2024).

Table 4 · Model and Equipment Register

| The choice | What was picked | Why here |
| --- | --- | --- |
| Language model | GLM 5.3 open weights, 753B parameters filed, FP8, bespoke license | The only frontier class model in the register; commercial use, fine tuning and redistribution are permitted, so the JV holds its weights on its own node |
| Detection and segmentation | RF-DETR fine tuned on site footage | Apache-2.0 from package to checkpoints; the JV owns and hardens weights a packaged safety product would rent |
| Tracking | Roboflow trackers, ByteTrack class | Apache-2.0 motion only identity without the AGPL exposure of the BoxMOT collection |
| Forecasting | Chronos-2 universal forecasting | Apache-2.0 with no field of use restriction; weights may be held, fine tuned and redistributed on site |
| Embedding | BGE-M3 hybrid multilingual embedder | MIT with no field of use restriction; multilingual retrieval across a workforce tagged by language |
| Frontier hardware | One node of eight 141 GB HBM GPUs (H200 class) | 1,128 GB holds the 904 GB of FP8 weights, KV cache and activations with headroom for sessions |
| Edge compute | Jetson Orin industrial edge class in solar powered enclosures | Detection survives patchy private LTE coverage at gates and laydown areas |
| Site inference server | Eight L40S class PCIe GPUs, 48 GB class | Forecasting, embedding and breach aggregation on JV hardware in the site data room |
| Camera class | Fixed visible cameras, Frigate ready ONVIF Profile S/T; thermal at 9 Hz or less | The existing 38 fixed cameras serve where a reuse survey holds; the 9 Hz ceiling keeps US origin thermal units outside the 6A003.b.4.b export license to Saudi Arabia |
| Sizing rules | Enclosure thermal budget including solar gain, with a cleaning interval as a design parameter | Dust, glare and 50 C summer ambient fail as accuracy problems unless the thermal budget is engineered first |
| Sensing | Crane anti-collision logs, crawler telematics, haulage GPS for 40 tracked trucks plus proposed trackers for 20 mixers, weather station, biometric turnstiles, batch plant SCADA | Ground truth of what cranes, trucks and crews actually did, joined through the adapters |
| Pattern | Adapter tier, one object model, recommendation with a named approver | Every source enters through an adapter, never directly, and every re-sequencing output stays a recommendation a person approves |

PART III · CHAPTER 9

## Shadow Mode Comes Before Any Flag Is Trusted

Three phases with counted items and hard gates prove the slip forecast and the breach detection against the record before anyone acts on a flag.

Chapter 8 fixed the models, their licenses and the hardware classes they run on. This chapter sets out how the design earns the right to be trusted: three phases with counted items, workstreams and hard exit gates, so the slip forecast and the breach detection are proven against the record before anyone acts on a flag, and the work can be stopped cheaply if a gate does not hold.

### 9.1  Three Phases, Counted and Gated

Figure 8 shows the rollout as three phases with item counts, workstreams and exit gates. No phase carries a duration; each phase ends when its gate is met, not when a calendar page turns. Phase 1 is a one zone pilot carrying nine items across five workstreams: camera and edge detection, HSE live breach detection, records and permits, the sovereign platform and the structure phase model. The items integrate Primavera P6, the yard register and the batch plant feeds, digitise one zone's paper records, mount the first edge nodes and stand up the ontology. The exit gate is the built structure phase ontology: every object from Chapter 5 instantiated for one zone, with its sources joined and its provenance classes recorded. Phase 2 carries six items across five workstreams: the agentic work surface, camera and edge detection, forecasting, logistics re-sequencing and records and permits. Its exit gate is the forecast: pour slips predicted three days out against the P6 record, shadowed so planners see the forecast but the schedule of record is untouched. The delivery re-sequencing console and the work surface launch inside this phase, both in recommendation-only mode. Phase 3 carries three items across three workstreams: the agentic work surface, logistics re-sequencing and the sovereign platform. Its exit gate is the drafted weekly look ahead: the Thursday meeting reads its first draft from the record rather than assembling it from four systems by hand. Model governance and retraining become standing operations here. Requirement coverage is counted, not asserted: of the seven recorded requirements, two are covered by the gates above, none is partial, and five sit outside this baseline as later scope the JV may take up.

![Figure 8. The three phases and their gates, and coverage of the 7 requirements across them.](figures/figure_08.png)

Figure 8. The three phases and their gates, and coverage of the 7 requirements across them.

### 9.2  What the Rollout Measures

The rollout measures five things against the record. First, slip forecast quality: every three day forecast is scored against what P6 shows happened, by pour and by zone. Second, crane idle time and its attributed cause: the share of a shift each tower crane spends idle waiting for delivery, and how much of it the re-sequencing console removes when its recommendations are accepted. Third, gate flow: queue depth counted by camera against the paper log baseline, so the digitised record can be audited against what the gate actually did. Fourth, breach detection: every live flag is reviewed by an HSE officer, giving precision per detection class and the time from breach to alert. Fifth, exposure during the delivery surge: worker and suspended load co-presence in laydown areas between 06:00 and 08:00, counted before and after re-sequencing goes live.

### 9.3  What Fails and What the Design Does

Table 5 lists the failure modes the design carries and its answer to each.

Table 5 · Failure Modes

| What fails | What the design does |
| --- | --- |
| Private LTE coverage at laydown areas and under crane zones cannot stream video back to the data room | Solar powered edge nodes run detection locally and buffer to an uplink sized for hours of disconnection, then doubled |
| Owner consent for direct Primavera P6 API access is not confirmed | The design runs on daily XER or XML file exports; the API sits behind a consent checkpoint as an upgrade |
| The haulage contractor's GPS feed format is unconfirmed | Format confirmed in phase 1; gate camera queue counting is the fallback for affected trucks |
| The existing 38 fixed cameras were mounted for human review and lack detection density at zone edges | A six gate reuse survey runs per camera; purpose-placed fixed cameras are added only where pixels on target fail |
| The GLM 5.3 license carries a security review trigger for a model as a service business above USD 10 billion group revenue in twelve months | Internal JV use does not trigger it; the corporate group position is confirmed at contracting and the attribution notice recorded |
| Dust, glare and summer ambient degrade lenses and edge compute, presenting as an accuracy problem | Every enclosure carries a thermal budget including solar gain, filtered or sealed cooling, a cleaning interval as a design parameter and monitored internal temperature |

### 9.4  Lessons

**Shadow the flags before anyone trusts them.** Every flag in phase 2 is advisory: the forecast is scored against P6, the breach detection is scored by HSE review, and the re-sequencing console proposes while the crane coordinator decides. Trust is earned per detection class, and a class that cannot hold its precision stays shadowed. Data management discipline from adjacent engineering practice supports this: plan the record before the analysis, so every flag can be traced to the data that produced it (AGS 2024). The gate camera is the fallback, not the other way round. The GPS feed is richer than pixels, but its format is unconfirmed, so the design treats camera queue counting as the guaranteed floor and the feed as the upgrade. A design that needs an unconfirmed feed on the critical path is a design that stops on the first integration surprise. A license trigger is a contracting question, not an engineering one. The GLM 5.3 review trigger turns on a business model the JV does not run, but the corporate group position still has to be confirmed and recorded at contracting, with the attribution notice filed beside the model registry.

### 9.5  What Is Still Open

Five questions remain open. Whether the owner consents to direct P6 API access: settled, it would raise the schedule join from daily files to near live and let the fragnet read flow both ways. Whether the GPS feed arrives in a usable format: settled, it would remove the camera fallback for 40 tracked trucks and tighten delivery window attribution. Whether the reuse survey passes at zone edges: settled, it would cut new camera count and phase 1 cost. Whether the corporate group position triggers the GLM 5.3 review clause: settled, it would either confirm self hosting as designed or force a substitute frontier model into the register. Each is a checkpoint, not a blocker: the design holds its shape either way, and the cost of settling each is a meeting, not a rebuild.

PART III · CHAPTER 10

## The Record Stays with the Fleet That Produced It

The object model, the weights, the decision record and the boundary all belong to the joint venture, so the intelligence compounds for the operation that generated it.

Chapter 9 showed how the design proves itself through counted phases and gates. This chapter states who owns what those phases build, because a live model of the structure phase is only worth building if the joint venture keeps it.

### 10.1  What the Joint Venture Owns

The object model is the JV's: the 15 objects, their typed links and their status vocabularies live in the JV's own instance, on JV servers in the site data room, and they outlive any single project system. The weights and fine tunes are the JV's: the RF-DETR checkpoints fine tuned on site footage, the Chronos-2 forecasts tuned on the yard's own pour history and the BGE-M3 embeddings over its own records all carry Apache 2.0 or MIT terms, so the operator holds them outright, and the GLM 5.3 bespoke license permits commercial use, fine tuning and redistribution for internal work. The decision record is the JV's: every re-sequencing recommendation, the person who approved or rejected it and the outcome that followed are kept as objects the next decision reads, a record whose preservation matters precisely because unmanaged data has cost other contractors dearly in litigation (Minerva26 2023). The boundary is the JV's: every stream, weight and decision stays inside the Kingdom on hardware the JV controls, and worker data is stewarded under the operator's own accountability, a duty regulators elsewhere have enforced with real penalties (YNA 2026).

### 10.2  The Offer Behind the Design

CodeNinja designed this system on Praxis, its platform for designing physical AI systems, and the design maps directly onto its offer: Adaptive Operations is the sensing, detection and forecasting of physical behavior, from edge cameras and crane logs to the three day slip forecast; Decision Systems is the ranking, attribution and re-sequencing that a named planner or crane coordinator approves; Hyper Ontology is the object model at the center of Chapter 5; Hyper Pragma is the agentic work surface where planners, the crane coordinator and HSE officers build their own daily agents; Hyper Engram is the kept record of decisions and outcomes that each re-sequencing recommendation reads before it is made; and Sovereign Infrastructure is the posture the JV chose, its own hardware, open-weight licenses and operation inside the Kingdom.

PART IV · CONCLUSION

## One Live Picture, Built From Records the Site Already Holds

Structure Phase Watch is a single live model of a construction structure phase: fifteen objects spanning cranes, units, trucks, permits, workers, zones and pours, fed by twelve systems through three adapter families, hardened at the edge for dust and heat, sized for sovereign operation on the operator's own servers, and arranged so that a forecast slip and a live breach both arrive as evidence a named planner, crane coordinator or HSE officer decides on.

The same shape runs wherever an operation keeps a schedule of record, a production register and a gate or flow log that no one has joined: swap the objects for that industry's assets, place detection where the connection is weakest, place reasoning in the jurisdiction that must hold the record, and keep every recommendation at the desk of a person whose name the record carries.

PART IV · CHAPTER 11

## Every Choice Traces Back to a Recorded Reading

Produced on Praxis, the design keeps its reasoning on the record: the ask, the room, eight lenses and the patterns they surfaced, so any choice can be traced to what justified it.

Chapter 10 established that the record of decisions belongs to the joint venture. This chapter applies the same discipline to the design itself: produced on Praxis, every choice in this paper keeps its reasoning on the record, so a reader can trace any decision back to what justified it. Figure 9 shows that path from the ask to the equipment classes.

### 11.1  Contextualizing the Ask

Every design in the series is produced on Praxis, and this chapter is the audit trail. The ask, in the operator's words, was one live picture of the structure phase: precast production against the pour sequence, crane utilisation and lift plan compliance, truck flow through gates and laydown areas, and the people and equipment conflicts that cause both delay and injury, with warnings before a slip reaches the look ahead and breach detection while it happens. Praxis assigned the design to the physical operations family in heavy industry and construction. What was in the room and read in full, listed here and available on request: the operator's written requirement and its hypothesis about crane idle time and laydown exposure; the inventory of 12 named systems and their data; the object and link plan; the stack cards with their tooling and hardware readings; the model catalog entries; the risk register; and the phase plan with its gates. Nothing in this paper rests on a conversation that was not written down.

![Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.](figures/figure_09.png)

Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.

### 11.2  The Eight Lenses

Table 6 records what each lens could see, what it cited and what it contributed. Seven lenses returned readings; one returned nothing and is shown as a gap.

Table 6 · The Lenses and What They Contributed

| Lens | Could see | Cited | What it contributed |
| --- | --- | --- | --- |
| First principles | The physical chain from a delivery window to crane idle to a slipped pour | None | The recoverable-loss hypothesis: delivery sequencing, not crane count |
| Case studies | How contractors have fared when electronic records were not managed | Minerva26 2023 | Keep the decision record defensibly; sanctions follow unmanaged data |
| Tooling and recency | The current state of streaming, graph, video, tracking, forecasting and serving tools | Apache Kafka 4.3.x, Frigate NVR, ONNX Runtime, vLLM, RF-DETR, Chronos-2, BGE-M3, Roboflow trackers, K3s, Harbor and MLflow, CVAT, Keycloak, InfluxDB 3 Core, P6 EPPM export | The entire software stack and the five model choices |
| Hardware and equipment | Compute rated for a dusty, hot, solar powered site and the memory arithmetic behind it | Jetson Orin industrial edge class, eight by L40S class GPUs, one node of eight 141 GB HBM GPUs, OCP Time Card grandmaster | Edge nodes at gates and laydown areas, the site inference server, the frontier node sizing and time synchronisation |
| Rules and regulations | The midday work ban, building code duties, camera export control and privacy enforcement | 6A003.b.4.b at 9 Hz or less for thermal units, YNA 2026 | Camera class specification, in-country operation, worker data stewardship |
| Approach | Data management disciplines from adjacent engineering practice | AGS 2024, ARMY 2025 | Adapter and provenance discipline, plan the record before the analysis, shadow mode before action |
| History | Precedent designs for joining construction schedule and safety data | None | Gap: no recorded precedent joined these four streams; the design argues from first principles instead |
| Domain fusion | What happens when schedule, logistics, safety and workforce data share one object model | None | The pour, lift, gate, permit and worker joins that no single system can make |

### 11.3  Patterns Adopted and Set Aside

The lenses surfaced patterns the design adopted and patterns it refused. Adopted: an adapter tier with provenance classes so every object carries its origin; file based schedule integration over an API whose consent was unconfirmed; open weights self hosted so the JV owns its own detections; shadow mode before any flag is acted on; Apache licensed tracking to avoid the copyleft exposure of the alternative collection. Set aside: packaged site safety vision products, because they rent the exact weights the sovereignty requirement obliges the JV to own; direct P6 API access as the baseline, for the consent reason above; a hardware data diode, because the whole estate sits inside one JV perimeter and the batch plant historian is mirrored read-only on the same network; and sovereign cloud migration, which the owner's policy permits but the engineer placed behind the JV's own servers as a later option.

### 11.4  Where the Reasoning Lands

The reasoning lands on four equipment classes and their sizing rules: the 141 GB HBM GPU class that holds the frontier weights of the work surface, 753 GB at FP8 with headroom for KV cache and activations inside one node; the fixed thermal camera class, specified at 9 Hz or less to stay outside the export license to Saudi Arabia; the enclosure thermal budget, sized for dust, solar gain and summer ambient with cleaning as a design parameter; and the reuse-or-not camera decision, settled by a six gate pixels-on-target survey per existing unit. Each class traces back through Table 6 to the lens that cited it and the room where it was read. That is the point of this chapter: everything shown in this paper was recorded reading, and nothing is inferred.

Appendix A

## What Ownership Costs Over Three Years

The design runs on the operator's own hardware. This appendix prices that choice against the two ways an operator in Saudi Arabia could otherwise get the same capability: renting the same accelerators from a cloud region, or buying a closed frontier model by the token. Every input is a public price, dated and cited. The arithmetic is shown so any reader can rerun it with a written quote. The operator in this design is an illustrative scenario, so the user count and the edge allowance below are assumptions, stated where they are used.

### A.1 The Answer

Owning the stack this design specifies costs about **642,000 US dollars over three years**, inside a range of 552,000 to 739,000. Renting the same capacity around the clock costs **1.41 million to 2.81 million dollars** over the same period. Against the cheapest three-year commitment listed (Oracle, three-year commitment), ownership is **about one half** the cost. Only one of the rented options can sit inside the Kingdom today: no hyperscaler GPU region with H200-class machines is live there, and AWS's Saudi region opens in December 2026 (Channel Insider 2026).

### A.2 What Owning Costs

| Line | Basis | Three-year cost (USD) |
| --- | --- | --- |
| Frontier tier | One server of eight 141 GB HBM-class cards, 320,000 to 420,000 dollars, typical 370,000 (Mercatus 2026) | 320,000 to 420,000 |
| Site tier | One PCIe inference server of eight 48 GB L40S-class cards, as the paper specifies, 85,271 dollars (Newegg 2026) | 85,000 |
| Edge | Five Jetson Orin industrial edge nodes in solar powered enclosures, one at each camera location the paper names at 4,000 dollars each (Eurotech 2026) | 20,000 |
| Support | 8 to 12 percent of hardware value a year (Introl 2026) | 102,000 to 189,000 |
| Power | 10.8 kW average IT load at a power usage effectiveness of 1.6 (Uptime Institute 2025), 454,118 kWh at the industrial tariff of 0.20 riyals per kWh (ECRA 2025) at 3.75 riyals to the dollar | 24,000 |
| **Total** |  | **552,000 to 739,000, typical 642,000** |

The average load assumes the frontier server draws 7 kW of its 10.2 kW maximum (NVIDIA 2026), the site server 3.5 kW and each edge node 60 W. The frontier tier fits one node because GLM 5.3 is 753 GB at FP8 and needs 904 GB with headroom, against 1,128 GB on eight 141 GB cards.

### A.3 What Renting Costs

The same frontier server and site server, rented without a break for three years, because breach detection runs while crews work and forecasts refresh through the night. The edge nodes stay on site in every option and are included in each total.

| Option | Basis | Three-year cost (USD) |
| --- | --- | --- |
| AWS, UAE region, on demand | p5en.48xlarge at 75.96 dollars an hour in me-central-1, g6e.48xlarge at 30.13 (Vantage 2026); outside the Kingdom | 2.81 million |
| Specialist GPU cloud, on demand | 50.44 dollars an hour for eight H200 cards, 18.00 for eight L40S (CoreWeave 2026); outside the Kingdom | 1.82 million |
| Oracle, three-year commitment | 40 dollars an hour for eight H200 cards at Oracle's single global price (Oracle 2026), listed for Riyadh and Jeddah by a third party (Northflank 2026); site tier at AWS reserved 13.02 | 1.41 million |

Egress, storage and the network link to the region are excluded, so every rented figure is a floor.

### A.4 What Closed Models Cost by the Token

A closed frontier model replaces the frontier tier rather than the whole stack, and it is priced by use. At 30 users (an assumed count across the planning, crane coordination and HSE leads the paper writes for), each running the equivalent of five agents at 2.4 billion tokens a year, with four input tokens to every output token and half the input served from cache, three years is 216 billion tokens.

| Model | List price per million tokens, input and output | Three-year cost (USD) |
| --- | --- | --- |
| Claude Sonnet 5.5 | 2 and 10 (Anthropic 2026) | 0.62 million |
| Gemini 3.1 Pro | 2 and 12 (Google 2026) | 0.71 million |
| Claude Opus 5.5 | 4 and 20 (Anthropic 2026) | 1.24 million |
| GPT-5.5 | 5 and 30 (OpenAI 2026) | 1.77 million |

The cheapest closed model costs about 21,000 dollars per user over three years, so it matches the whole owned stack at about **31 users**. Below that, renting a closed model by the token is cheaper; above it, ownership is, and the gap widens linearly with users while the owned cost stays flat. Every closed option also sends worker biometric data, site footage and the owner's schedule to a third-party AI service outside the boundary, which the design's constraints rule out.

### A.5 What the Price Does Not Include

- **Solar enclosures, batteries, sunshields and private LTE**; the edge line prices the compute only.
- **The project's own data room and its fit-out**, which the joint venture already runs.
- **An export licence.** Saudi Arabia sits in US Country Groups D:3 and D:4 (eCFR 2026), so 141 GB HBM-class accelerators need a licence from the Bureau of Industry and Security, granted case by case; BIS guidance of May 2026 confirms no blanket exemption (Holland & Knight 2026).
- **Customs duty and 15 percent VAT** on the hardware, which a written quote delivered to the Kingdom settles.
- **People, facilities and implementation**, which both sides carry.

### A.6 Sources for This Appendix

- Anthropic. 2026. Pricing. <https://claude.com/pricing>
- Channel Insider. 2026. AWS cloud region launch, Saudi Arabia. <https://www.channelinsider.com/infrastructure/news-aws-cloud-region-launch-emea-saudi-arabia/>
- CoreWeave. 2026. Pricing. <https://www.coreweave.com/pricing>
- ECRA. 2025. Electricity tariff, effective 28 May 2025, as reported. <https://clenergize.com/ksa-electricity-tariff-changes-in-2025-is-your-business-ready/>
- Eurotech. 2026. ReliaCOR 33-11. <https://buy.eurotech.com/products/reliacor-33-11>
- Google. 2026. Gemini API pricing. <https://ai.google.dev/gemini-api/docs/pricing>
- Holland & Knight. 2026. BIS guidance on licence requirements for advanced computing items. <https://www.hklaw.com/en/insights/publications/2026/06/bis-publishes-guidance-license-requirements-advanced-computing-items>
- Introl. 2026. GPU infrastructure TCO model. <https://introl.com/blog/gpu-infrastructure-tco-model-5-year-enterprise-ai-deployment>
- Mercatus. 2026. H200 server price. <https://mercatus-ai.com/blog/h200-server-price>
- NVIDIA. 2026. DGX H200. <https://www.nvidia.com/en-us/data-center/dgx-h200/>
- Newegg. 2026. Supermicro SYS-421GE-TNRT-02-G1. <https://www.newegg.com/p/N82E16859152404>
- Northflank. 2026. OCI BM.GPU.H200.8 regions. <https://northflank.com/cloud/oci/instances/BM.GPU.H200.8>
- OpenAI. 2026. API pricing. <https://developers.openai.com/api/docs/pricing>
- Oracle. 2026. Cloud pricing. <https://www.oracle.com/cloud/pricing/>
- Uptime Institute. 2025. Global Data Center Survey 2025. <https://uptimeinstitute.com>
- Vantage. 2026. EC2 instance prices. <https://instances.vantage.sh>
- eCFR. 2026. 15 CFR Part 740, Supplement No. 1, Country Groups. <https://www.ecfr.gov/current/title-15/part-740/appendix-Supplement%20No.%201%20to%20Part%20740>

SOURCES

## Source Register

AGS. 2024. DRAFT. <https://www.ags.org.uk/content/uploads/2024/03/AGS_Data-Management-Plan-Guidance-Edition-1_202403.pdf>

ARMY. 2025. . <https://publibrary.sec.usace.army.mil/api/download?filename=ER+1110-1-8178_Data+Management+for+Subsurface+Investigations+and+Performance+Monitoring_2025+07+30+-+Final.pdf&id=9d455919-ee3f-4ec0-ef26-b4bbe0ddc8cc&preview=true&token=>

Acquisition. n.d.. Subpart 1239.70, Information Security and Incident Response Reporting Acquisition.GOV. <https://www.acquisition.gov/tar/subpart-1239.70%E2%80%94information-security-and-incident-response-reporting>

YNA. 2026. HD Construction Equipment fined 73.5 mln won for employee data leak Yonhap News Agency. <https://en.yna.co.kr/view/AEN20260827002900315>

---

### About CodeNinja

CodeNinja is a Middle Eastern-American artificial intelligence lab focused on building self-improving systems. We are reinventing knowledge work to close the loop between vertical AI use cases and the generalized intelligence that fuels it, accelerating the path toward organizational superintelligence.


---

# Loop Integrity Watch: Ending Distorted Radar Level Readings and Tank-to-Tank Swapping Across the Tank Farm

Canonical: https://codeatoms.ai/tank-gauge-integrity-pakistan/
DOI: https://doi.org/10.5281/zenodo.23157967
PDF: https://codeatoms.ai/tank-gauge-integrity-pakistan/paper/loop-integrity-watch-radar-tank-gauge-integrity-fuel-terminal-pakistan.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

VERTICAL-DRIVEN ARCHITECTURES · OIL & GAS · DESIGNED WITH PRAXIS · OCTOBER 2026

# Loop Integrity Watch: Ending Distorted Radar Level Readings and Tank-to-Tank Swapping Across the Tank Farm

A system design that restores continuous, undistorted radar level readings from thirteen fuel tanks in Pakistan: three booster installations engineered from a signal survey on three Modbus loops, plus a governed inventory ontology over the centralized gauging host that detects distortion and swapping before the central picture misleads anyone.

CodeNinja Engineering Team

For the instrumentation and control lead accountable for tank gauging, the location engineer and HSE supervisor beside them, and the instrumentation, integration and platform engineers who would build and run it.

---

Vertical-Driven Architectures is a CodeNinja series of system designs. Every design in the series is driven by a real-world problem and scenario in a single industry, and every one is designed on Praxis, CodeNinja's platform for designing physical AI systems. Operations are described by class, never by name.

At a glance

## Radar tank gauge integrity for a fuel terminal in Pakistan

**What this is.** An open reference architecture for system design in physical AI: field hardware that rebuilds the signal path on three Modbus loops, and a governed inventory ontology that catches a flatlined or swapped radar gauge reading before the central inventory picture misleads anyone. It is written for the instrumentation and control lead, the location engineer and HSE supervisor, and the engineers who would build it. The operator is described by class, never by name.

**The answer in numbers.**

| Part | The design |
| --- | --- |
| Field scope | 13 fuel tanks on 3 Modbus RTU loops; 3 booster installations engineered from a measured signal survey inside explosion proof junction boxes |
| Sources joined | 2 named source systems, the centralized gauging host and the radar tank gauges, through 1 integration adapter family |
| Object model | 15 typed objects, with the fuel tank as the focal object, published as JSON for reuse |
| Models | None: every integrity check (stuck value, swap, distortion) is deterministic |
| Compute | Two containers on the operator's own site application server, inside its OT boundary |
| Three-year cost | No compute to price; the field equipment is priced by OEM quotation against the survey (Appendix A) |
| Human control | Every data quality event is acknowledged and resolved by a named person; the location engineer signs acceptance |

**Reuse it.** The object model, the model register and the figures are free to reuse under CC BY 4.0. Cite as DOI <https://doi.org/10.5281/zenodo.23157967.>

**Made with.** Reasoned on [Praxis](<https://codeatoms.ai/praxis/>), CodeNinja's platform for designing physical AI systems. The object model imports into [Hyper Ontology](<https://codeatoms.ai/hyper-ontology/>), which turns it into a living system. Both are in beta; access by request.

ABSTRACT

## Distorted Radar Level Readings Should Fail Loudly, Not Silently

The question the operation needs answered every hour is whether the radar tank gauge readings arriving in the central gauging host are continuous, undistorted and attributed to the right tank. Today it cannot be answered: the gauges sit on serial Modbus loops whose signal health is invisible, a flatlined gauge reads as a plausible low level, and a swapped gauge makes two tanks trade identities, so distortion and swapping surface only when the central inventory picture disagrees with physical stock, long after the field signal failed.

The design pairs field hardware with a governed ontology. Two named source systems, the centralized gauging host and the radar tank gauges, enter through one integration adapter family into an object model of fifteen objects, served by seven services and one operating surface, with zero learned models because every integrity check is deterministic. Three booster installations, engineered from a measured signal survey inside explosion proof junction boxes, rebuild the signal path on three loops; the ontology service and integrity monitor run as two containers on the operator's own site application server, inside the operator's own OT boundary, projecting a central inventory picture over the gauging host without replacing it.

The paper proceeds from the problem and the join failure across existing systems, through the constraints the requirement itself imposes, the stack, the fifteen-object model, ingestion through the adapter, inference placement on the operator's server, an honestly empty model register, the rollout phases with their gates, and ownership of what is built, closing with the chapter on how the design was reasoned on Praxis.

---

![Figure 1. Loop Integrity Watch on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.](figures/figure_01.png)

Figure 1. Loop Integrity Watch on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.

## Contents

Each chapter is tagged for the reader it serves most directly: Executive, Team Lead, FDE, Reference.

|  |  |  |
| --- | --- | --- |
|  | Abstract · Distorted Radar Level Readings Should Fail Loudly, Not Silently | Executive |
| PART I · THE PROBLEM | | |
| 1 | [Distorted Radar Level Readings Undermine the Inventory Picture](#ch1) | Executive |
| 2 | [Every Gauge and Host Sees One Slice](#ch2) | ExecutiveTeam Lead |
| PART II · THE DESIGN | | |
| 3 | [Four Contractual and Physical Constraints Shape the Design](#ch3) | Team Lead |
| 4 | [One Stack Runs From Field Cable to Central Picture](#ch4) | Team LeadFDE |
| 5 | [Fifteen Objects Turn Gauge Signals Into One Argument](#ch5) | FDE |
| 6 | [Every Reading Enters Through One Integration Adapter](#ch6) | FDE |
| 7 | [Integrity Checking Belongs on the Operator's Server](#ch7) | FDE |
| 8 | [An Empty Model Register Is the Honest Answer](#ch8) | FDEExecutive |
| PART III · THE ROLLOUT | | |
| 9 | [Signal Survey Before Supply, Verification Before Acceptance](#ch9) | Team LeadExecutive |
| 10 | [The Inventory Intelligence Should Stay with the Operator](#ch10) | Executive |
| PART IV · HOW IT WAS DESIGNED | | |
|  | Conclusion · The Same Shape Runs on Any Tank Farm | Executive |
| 11 | [How Praxis Contextualized and Reasoned This Design](#ch11) | Team LeadFDE |
|  | [Sources](#sources) | Reference |

PART I · CHAPTER 1

## Distorted Radar Level Readings Undermine the Inventory Picture

The operation needs to know, tank by tank and hour by hour, whether its thirteen radar gauges are reporting true levels, and today nothing in the signal path can tell it.

The abstract states the question this paper answers and the shape of the design that answers it. This chapter grounds that question in the operation itself: what the tank farm runs, what data a trustworthy answer requires, what the failure costs when it goes wrong, and the regulatory ground the whole job stands on.

### 1.1  The Question the Operation Needs Answered

An oil and gas operator in Pakistan needs to know, tank by tank and hour by hour, whether each of its thirteen radar tank gauges is reporting the true level of the product beneath it. The question sounds simple; answering it requires data that no single component in the path holds today. It requires every reading stamped with the time it was taken, the identity of the gauge and of the serial loop that carried it, a quality flag saying whether the value arrived undistorted, and the electrical condition of the loop itself. The gauges are radar tank gauges, or RTGs, which measure level and temperature by radar and answer polls sent to a Modbus slave address over Modbus RTU, a serial master-slave protocol carried on twisted-pair RS-485 cabling. Thirteen tanks sit on three such communication loops, all feeding one centralized gauging host. The readings arrive when they arrive, and nothing in the path can say whether a flat line on a display is a tank at rest or a dead signal. The regulatory ground raises the stakes. Under the Oil and Gas Regulatory Authority Ordinance 2002, oil storage at this scale is a licensed and regulated activity, and the equipment standards attached to that license are mandatory. The Sindh Occupational Safety and Health Act 2017 carries the workplace, hazard-register and permit duties that govern any work performed on live plant. The procurement itself runs under the national public procurement regime and was published through the public procurement authority's electronic system. The hardware lives in a classified hazardous area, where the zone at each installation position dictates the enclosure class.

### 1.2  The Documented Cost of the Problem

The industry's investigation record prices this class of failure. An explosion and fire at a Texas City refinery in 2005 killed fifteen workers and injured one hundred eighty, and the investigation board's report examined the operator's safety culture and the regulatory regime surrounding the site (CSB 2005); the regulator later issued a record fine for failing to correct the hazards behind that event (NBC News 2009). A tank explosion at a refinery in Wales in 2011 killed four people and seriously injured a fifth (HSE 2011). Explosion, fire or burns is reported as the leading cause of worker fatalities in the oil and gas industry in North America, ahead of every other cause (HSE Review 2025). A distorted gauge reading is a small defect with a large tail: an inventory picture built on stuck or swapped signals misdirects receipts, issues and reconciliation, and it removes the earliest warning a tank farm has.

### 1.3  The Operation as a Scenario

The operation runs a fuel storage installation with thirteen storage tanks, each fitted with an RTG, wired in three Modbus RTU communication loops into one centralized gauging host. Two named systems therefore anchor the scenario: the gauges in the field and the host in the server room. The people in the loop are a location engineer who holds approval and acceptance authority, instrumentation technicians who carry the competence to work on explosion-protected equipment, a location incharge who approves outage windows, and the issuer of hot and cold work permits. The physical environments are three: the classified hazardous area around the tanks where every junction box, repeater and gland must carry a certificate valid for its zone, the cabling routes between field and control building, and the safe-area server room hosting the centralization host and the design's own software. The counts that size the job are two named systems, three loops, thirteen tanks, three booster installations, one service order raised under a public reference, and one centralized host that must never go blind. The work is bounded by a ninety-day completion window and followed by a year of warranty and support.

PART I · CHAPTER 2

## Every Gauge and Host Sees One Slice

The radar gauges see their own level, the serial loops carry it blind, and the centralized gauging host displays whatever arrives, so no component can see the distortion or the swap that joins them.

Chapter 1 framed the question and the ground it stands on. This chapter shows why nothing installed today can answer that question, system by system, and what the gap costs in practice.

### 2.1  What Each System Sees and What It Misses

Each RTG sees its own tank well. It measures level and temperature by radar and answers any poll addressed to its Modbus slave address. What it cannot see is everything downstream of itself: it does not know whether its replies arrive, whether the electrical signal carrying them has degraded along the loop, or whether another gauge on the same loop has been wired or addressed so that two devices answer as one. The gauge is honest about its tank and blind about its own report. The three Modbus RTU loops carry the readings blind. RS-485 transports bytes between addresses; it has no notion of what the bytes mean. If an address mapping is wrong, the loop faithfully delivers one tank's level to another tank's slot in the host, and every component downstream accepts it. The loop sees traffic and misses meaning, which is exactly the failure mode the operator has named: readings swapping between tanks. The 24VDC field power supplies see voltage and current, not data. They can report that a repeater is energized while the data behind that repeater is distorted or duplicated, so healthy power and healthy readings are two different facts that no component joins. The centralized gauging software sees whatever the polls return, and it stores and displays it as tank levels. It can notice silence, a gauge that stops responding altogether, but a stuck value and a swapped pair both arrive looking like valid data. The host has no independent knowledge of what the true level should be, so it cannot flag the distortion that joins it to the field. Figure 2 sets these views side by side.

![Figure 2. Four systems, each seeing one part of the answer. the question needs all of them in one place at once.](figures/figure_02.png)

Figure 2. Four systems, each seeing one part of the answer. the question needs all of them in one place at once.

### 2.2  What None of Them See Together

What none of the components see together is continuity of identity: the unbroken chain from physical tank, to gauge, to loop segment, to booster, to the number on the display, with the signal quality of every hop attached. No component can assert that the level shown for a tank at a given hour came from that tank's gauge, over a healthy loop, undistorted. The cost in practice is that the operator discovers the fault from the outside: stock discrepancies surface late, reconciliation falls back on walking the farm and cross-checking receipts, and a swap that persists undetected corrupts every decision that read the picture in the meantime. The measurement this design commits to, RTG data availability on the central host, exists precisely because today no number answers it.

PART II · CHAPTER 3

## Four Contractual and Physical Constraints Shape the Design

A ninety-day service order window, an explosion proof hardware discipline, OEM-authorized equipment and a system of record that must never be replaced bound every choice downstream.

Chapter 2 showed the blind spot that joins the gauges, the loops and the host. This chapter fixes the constraints that shape the design: four of them, two contractual and two physical, each hard in this industry in its own way, and each one a decision that every later chapter inherits.

### 3.1  A Ninety-Day Completion Window

The service order sets a ninety-day completion deadline, with liquidated damages accruing daily against the order's value up to a capped share. The window is hard in this industry because the critical hardware is OEM-specific and its lead time sits outside the installing contractor's control; because work inside a classified area requires permits whose availability is not guaranteed; and because commissioning must never leave the operator's stock accounting blind across the whole farm. The design answers the window by ordering equipment in the first phase against survey-confirmed quantities and sequencing the field work loop by loop, so the exposure at any moment is one loop, not three.

### 3.2  Explosion Proof Hardware Discipline

The boosters, junction boxes, glands and power supplies live inside a classified hazardous area, and the discipline there is unforgiving: area classification is the gating document. The enclosure class named in the requirement, Ex n, a restricted-breathing class associated with Zone 2, is only correct if the zone at each exact installation position says so; a Zone 1 position forces a heavier and more expensive class. The design therefore reads the zone, gas group and temperature class at each position from the operator's current classification drawing before any hardware is specified, and it specifies equipment by certificate marking rather than by part number. Every component entering the classified area carries a certificate valid for the zone it lands in.

### 3.3  OEM-Authorized Equipment and Configuration

The repeaters must be OEM equipment from the host's manufacturer supplied under a written authorization letter, and the end-to-end configuration of the centralized host is performed under the same authorization. This matters because authorization determines warranty validity and because the gauges themselves are off limits: the design improves the signal path to the gauges and never modifies the devices. One complication sits inside this constraint: the compliance sheet referenced in the requirement documents was not attached, so the repeater and power supply specifications are fixed through pre-bid clarification and carried as OEM-only, which removes substitution risk at the cost of narrowing the supply base to a single authorized manufacturer.

### 3.4  The System of Record Must Never Be Replaced

The centralized gauging software is the historian of record for gauge readings, and the design binds it in place: the central inventory picture is an ontology projection over the host, never a parallel tank inventory database. The constraint is hard in this industry because tank inventory data is custody data, and a second store of readings creates a reconciliation burden and a second place for truth that drifts from the first. The integrity monitor buffers recent readings inside the ontology service only, long enough to detect stuck values and swaps, and writes nothing that competes with the host.

### 3.5  Scoping Decisions

Three scoping decisions carry most of the design's weight, and each buys something real at a price worth stating. Table 1 sets them out.

Table 1 · Scoping Decisions

| Decision | What it buys | What it costs |
| --- | --- | --- |
| Ontology projection over the centralized gauging software | One central inventory picture with no second store of truth | No independent historian; the monitor buffers recent readings only inside the ontology service |
| Two software containers on one operator application server | The whole intelligence inside the operator's own boundary on hardware it already owns | No redundancy beyond what the operator's platform standard provides |
| Loop-by-loop commissioning | One loop affected at a time, so stock accounting is never blind across the farm | More permit cycles and a longer commissioning sequence inside the same window |

### 3.6  What the Design Chose Against

Every rejection below was made for a reason the operator can audit, and the list ends with the scope the design refuses to invent. Table 2 records them.

Table 2 · What the Design Chose Against

| Where | What was picked | Instead of, and why |
| --- | --- | --- |
| Booster topology | One booster serving the first two loops where the signal survey proves it viable | Two boosters, one per loop, which would put more certified equipment inside the classified area and raise the lifetime inspection and maintenance burden |
| Inventory truth | An ontology projection over the gauging host | A parallel tank inventory database, which would create a reconciliation burden and a second place for truth |
| Signal integrity logic | Deterministic stuck-value and swap detection with read-back and alarm visibility | Learned models, which cannot be audited against the data integrity acceptance clauses and would fill a model register this design keeps empty by design |
| Data path | The gauging host as the sole collector polling the three loops | A new event streaming backbone, which at thirteen tanks would only add a second collector to maintain |
| Whole design | Out of scope: camera analytics, gauge modification, agentic surfaces, historic data migration, infrastructure and license fees | Capability the requirement never asked for, which would put unpriced equipment and unowned risk into a bounded job |

PART II · CHAPTER 4

## One Stack Runs From Field Cable to Central Picture

The architectural pattern places the systems of record below, one object model in the middle, and the services and operating surface above, so the gauging host stays the single place where readings are true.

Chapter 3 fixed four constraints: the gauging host stays in place as the system of record, nothing leaves the operator's boundary, every acceptance is signed by a named person, and the model register stays empty because the physics is deterministic. This chapter shows the stack those constraints produce, layer by layer, from the field cable to the central picture.

### 4.1  The Architectural Pattern and Why It Fits

The pattern is three layers in a fixed order. Below sit the systems of record: the radar tank gauges as field devices and the centralized gauging system as the historian of record for every reading. These are never replaced, never modified and never loaded; the adapter tier reads them and writes nothing back. In the middle sits one object model, fifteen objects with typed links, projected over the host so that tanks, gauges, loops, boosters, quality events and people become one connected argument. Above sit the services and the operating surface: seven named services that do the work the requirement describes, and one surface, the central inventory picture, where the operator's people see availability, open quality events and last sync. The pattern fits because the requirement's own failure is a join failure. A distorted or swapped level at one tank is invisible in any single system: the gauges see only their own signal, the host sees only what arrives, and the wiring, the boosters and the permits live in documents and records no gauge can read. The object model is a projection over the systems of record, never a shadow copy of them, so crossing mappings answer the questions no single system can. Figure 3 shows the layering with its counts: two sources, one adapter family, fifteen objects, seven services, one surface, and zero learned models. The empty model register is a decision, not an omission. Stuck values and swapped addresses are caught by deterministic checks on freshness, flatline and address binding, so no inference tier exists and no learned component is served anywhere in the design. The kinetic loop still closes: the stack senses, decides, acts and learns, because every quality event raised becomes a record the next survey and the next loop maintenance read. The services and the surface sit above the model, and the operator's people act inside the tools they already use, so no agent tier and no second work surface are built.

![Figure 3. The layered stack: 2 sources, 1 adapter family, 15 objects, 7 services and 1 surfaces.](figures/figure_03.png)

Figure 3. The layered stack: 2 sources, 1 adapter family, 15 objects, 7 services and 1 surfaces.

### 4.2  The Stack Stage by Stage

Table 3 walks the stack from bottom to top, naming the components at each stage. The stages that a larger design would fill with event streaming, a parallel historian, video ingest or model serving are deliberately thin here: the host is the sole collector for thirteen tanks on three loops, and adding parallel infrastructure would create a second place where readings could disagree.

Table 3 · The Stack, Stage by Stage

| Stage | What it is responsible for | How |
| --- | --- | --- |
| Sources | Holding the readings the operator already owns | radar tank gauges on all thirteen tanks, polled on three Modbus RTU communication loops, with the centralized gauging system as the historian of record |
| Sensing | Watching the physical signal path without adding new instruments | The RTG gauges themselves, the 24VDC field power supplies, the three-core screened loop cabling and the Modbus RTU polling pattern, read as a signal-quality feed rather than a vision feed |
| Adapters | Bringing both source systems into the object model through one governed path | A single integration adapter family performing read-only polling, point mapping and provenance tagging; no direct writes in either direction |
| Object model | Turning tanks, gauges, loops, boosters and events into one typed graph | Fifteen objects with typed links, projected over the gauging host so the host remains the single place where readings are true |
| Inference | Detecting distortion and swapping before the operator feels it | Deterministic integrity checks only: stuck-value detection, swap detection and freshness checks; the model register is empty by design |
| Services | Doing the work the requirement names | Seven services: Signal Integrity, Ex Installation, Cabling and Marshalling, HSE and Compliance, Central Gauging Host, Central Inventory Picture, Documentation and Support |
| Surfaces | Giving the operator's people one place to see and decide | One operating surface, the central inventory picture, projecting data availability, open quality events and last sync over the gauging host |

PART II · CHAPTER 5

## Fifteen Objects Turn Gauge Signals Into One Argument

Tanks, gauges, loops, boosters, junction boxes, readings, quality events, permits and people become one typed graph in which any query can reach from a suspect level back to the loop, the booster and the technician who last touched it.

Chapter 4 placed one object model at the center of the stack. This chapter opens that model: every object by name, the typed links between them, where the human loop lives, and one object in its recorded form.

### 5.1  Every Object and Its Typed Links

Figure 4 shows the fifteen objects and their typed links. The assets are the fuel tank, the radar tank gauge, the communication loop, the Modbus booster and the explosion proof junction box; each carries the properties its own domain demands, from Modbus slave address on the gauge to protection concept and certificate reference on the junction box. The measure and the event are the gauge reading and the data quality event, the latter carrying the status vocabulary of open, acknowledged and resolved. The projection is the central inventory picture, which aggregates coverage and quality across all thirteen tanks. The records and documents are the loop wiring as-built, the service order, the warranty and support record, the authorization letter and the HSE work permit. The people are the instrumentation technician and the location engineer who holds acceptance authority. The typed links are what make the model an argument. A gauge measures a tank; a reading arrives over a loop; a booster repeats that loop; a quality event names the loop it degraded; a permit governs the junction box a technician will open. From a distorted level at one tank, a single query reaches the loop, the booster that serves it, the as-built that documents it, the technician assigned to it and the permit that covers the work. A document store cannot make these joins, because its documents live on different sides of the boundary: the loop exists only in wiring records, the booster only in procurement records, the permit only in the HSE system, and no document holds the crossing mappings between them.

![Figure 4. The fifteen objects of the model and the typed links that let a query reach across them.](figures/figure_04.png)

Figure 4. The fifteen objects of the model and the typed links that let a query reach across them.

### 5.2  Where the Human Loop Lives and Where the Model Runs

The human loop lives in two objects and one status vocabulary. The technician object carries Ex competence and the assigned loop, so work is always attributed to a named person; the location engineer object carries approval authority and acceptance sign-off, so no phase closes without a signature. The data quality event is the hinge: every event moves from open to acknowledged to resolved, and each transition names the person who made it. The hosting posture keeps everything inside the operator's boundary. The ontology service and the integrity monitor run as two containers on one operator application server in the safe-area server room, on the operator's own hardware in Pakistan. Identity and access are provisioned through the operator's existing directory and site security regime, not a parallel account store. There are no external links: nothing crosses the OT boundary, and no data leaves the country. The only write path is narrow and explicit: the integrity monitor writes events and status changes into the object model, and the gauging host configuration changes under the authorization letter and the operator's change control. Readings themselves are never written by the design; the host is read-only to it.

### 5.3  One Object in Its Recorded Form

The booster object below is the heart of the requirement, because it is the piece of equipment the whole service order exists to install, and its recorded form shows how an asset, its loops, its supply and its commissioning date bind into one node of the graph.

```
{
  "id": "tank",
  "label": "Fuel Tank",
  "kind": "asset",
  "anchored_in": "centralized gauging software",
  "properties": [
    "Tank number (TK-xxx)",
    "Section (gasoline or kerosene)",
    "Loop assignment",
    "Product stored",
    "Capacity",
    "Current level",
    "Current temperature"
  ],
  "status_vocabulary": [
    "Reading",
    "Distorted",
    "Swapped",
    "Offline"
  ],
  "links": []
}
```

PART II · CHAPTER 6

## Every Reading Enters Through One Integration Adapter

Both named source systems enter through a single integration adapter family that guarantees point mapping, provenance and ordering, with no parallel historian and no second place for truth.

Chapter 5 gave the object model its fifteen objects and typed links. This chapter describes how data reaches them: every reading from both named source systems enters through one integration adapter family, with no parallel historian and no second place where readings could disagree.

### 6.1  The Named Sources and Their Provenance

Figure 5 shows the integration map. There are exactly two named source systems, and both are operator-held systems of record read in the read direction only. The first is the centralized gauging system, the host the whole requirement exists to feed and the historian of record for every gauge reading; it is also the system on which the end-to-end configuration is performed under the authorization letter. The second is the radar tank gauge fleet on all thirteen tanks, the field devices whose signal path the boosters improve without the gauges themselves being touched. Both enter through the single integration adapter family; neither is ever written to by the design, and no third source, feed or file enters the object model by another path. The adapter tags provenance at the moment of capture. Every reading carries its source loop, its Modbus slave address and its host timestamp into the object model, so any object in the graph can be traced back to the system and the loop that produced it. Provenance is what makes the swap detection possible: a reading is only swapped if its declared tank and its declared loop disagree, and both facts survive into the graph because the adapter records them together.

![Figure 5. The 2 named systems, the adapter path each one takes, and the object model they all map into.](figures/figure_05.png)

Figure 5. The 2 named systems, the adapter path each one takes, and the object model they all map into.

### 6.2  What the Adapter Tier Guarantees

The adapter tier guarantees four things. First, point mapping: each gauge's slave address is bound to exactly one tank object, so a repeated or moved address surfaces as a data quality event instead of propagating silently into the central picture. Second, direction: the integration is read-only against both sources; the only configuration write in the design is the host's point mapping itself, performed under the authorization letter and the operator's change control. Third, fidelity: quality flags pass through unsmoothed, so a distorted reading arrives in the graph as distorted rather than being averaged into plausibility. Fourth, ordering: every event is sequenced on timestamps from clocks synchronized by chrony across the host and the application server, so a stuck value and a swap are distinguishable in time.

### 6.3  The Event Backbone, and Why There Is Not One

There is deliberately no event backbone in this design. The centralized gauging system is the sole collector polling the three Modbus RTU loops through the boosters; for thirteen tanks on three loops, a parallel streaming layer would create a second place for truth without buying any capability the acceptance criteria need. Ordering comes from the synchronized host clock; delivery comes from the polling cycle itself, with the adapter consuming the host's polled reads and raising quality events into the ontology as they are detected. Buffering is bounded and local: the integrity monitor holds recent readings inside the ontology service, so a short host outage or a loop taken down for commissioning does not blank the central picture, and nothing else is stored outside the host. Replication is absent for the same reason the historian is absent: the host already is the record, and the observability stack, Prometheus with Grafana views, carries system status and never carries readings, so no duplicate of a tank level exists anywhere in the design.

PART II · CHAPTER 7

## Integrity Checking Belongs on the Operator's Server

All reasoning in this design is deterministic and runs as two containers on the operator's own site application server inside the OT boundary, so nothing about tank truth depends on a link leaving the site.

Chapter 6 followed every reading from a radar gauge through its booster and into the centralized gauging system, and left one question open: what watches those readings for distortion and swapping, and where does that watching run. This chapter answers the where. The design carries no learned inference anywhere in the field, so the placement question collapses to a single, deliberate choice: two small containers on one application server the operator already owns, inside the same operational technology boundary that the gauges poll into.

### 7.1  One Tier, Two Containers, No Weights

The design has exactly one inference tier, and Figure 6 shows it: the operator's own site application server in the safe-area server room, inside the operational technology boundary. Two containers run there. The first is the ontology service, built on the object model, which holds the fifteen-object inventory model and projects the central inventory picture over the gauging host. The second is the integrity monitor, which applies the deterministic checks that turn raw gauge readings into tank status: stuck-value detection against a flatlined reading, swap detection against a level that appears on the wrong tank, distortion detection against readings outside the shape a filling or emptying tank can produce, and availability accounting per tank and per loop.

This is the whole of the placement story, and it is worth being precise about why it is this small. The failure modes the operator is buying against are physical and deterministic: a degrading RS-485 segment distorts a Modbus signal in ways a threshold catches, and a wiring fault swaps two slave addresses in ways a consistency rule catches. No learned model is needed to catch them, so none is served. The memory arithmetic that a model-bearing design carries, weights against usable memory against the KV cache ceiling, has nothing to compute here: there are no weights, no accelerator, and no context window to budget, and the only resident footprint on the server is the two containers themselves. The platform's tooling lens recorded every heavier tier, from edge model serving to on-site language model serving to a frontier GPU cluster, as explicitly not needed, because staff act on outputs inside the tools they already use and no agentic work surface was asked for.

The choice of the operator's own hardware is also a sovereignty choice. The Pakistani Cloud First posture recorded in the design's reasoning confirms on-premises compute on the operator's own equipment, and the two containers are bought by class against the operator's own IT platform standard for orchestration rather than as named appliances.

![Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.](figures/figure_06.png)

Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.

### 7.2  The Latency Budget

With one tier, the latency budget is a chain of four hops, and each hop is sized by the signal survey rather than by assumption. The first hop is the gauge itself: a radar tank gauge updates its holding register on its own measurement cycle, independent of the network. The second hop is the RS-485 segment from gauge to booster, whose propagation behavior at the measured signal levels is exactly what the Phase 1 survey records and what the booster installation improves. The third hop is the Modbus RTU polling cycle: the centralized gauging system is the sole collector polling the three loops through the boosters, so the poll interval is the pace at which truth reaches the central picture. The fourth hop is the integrity monitor, which runs its checks inside the ontology service on each fresh reading the host exposes, so a stuck value, a swap or a distortion is caught on the poll cycle that carries it, not on a batch cycle afterward.

The budget therefore carries no invented millisecond figure: it is expressed as a rule, that detection latency equals one polling cycle plus container processing, and as a gate, that the signal survey's recorded levels must clear the margins the booster design assumes before any hardware is ordered.

### 7.3  What Crosses the Boundary, and What Fails

The honest inventory of boundary crossings is short: nothing crosses outward. No reading, event, status or decision record leaves the operator's operational technology boundary, because no external service, cloud tier or vendor endpoint exists in the design. The only ingress is the Modbus polling traffic the gauging host already generates, now extended through the boosters, and the existing LAN path from the host to the application server. The governing approach in the design's reasoning draws the operational technology boundary before installation, and Figure 6 marks it explicitly.

Failure behavior is defined per failure class, before go live, following the override-and-degradation approach. If the link fails, meaning a loop stops answering, the affected gauges read no response, the tanks flip to offline status, and the integrity monitor raises a data quality event on the loop rather than letting a stale level masquerade as a live one. If the power fails, meaning a 24VDC field supply or a booster drops, the loop degrades to failed status and the same event path fires, so the central picture shows the gap instead of hiding it. If the update path fails, there is little to fail: no models means no weight updates, and the only versioned artifacts are the OEM configuration packages and the as-built documentation, which carry written rollback rights confirmed with the operator's IT and instrumentation lead at mobilization. In every case the degraded mode is the same principle: a tank the system cannot see is shown as a tank the system cannot see, never as a tank holding a plausible number.

PART II · CHAPTER 8

## An Empty Model Register Is the Honest Answer

Stuck values, distorted readings and tank-to-tank swapping are caught by explicit thresholds and rules, so the model register holds zero entries and no license question arises.

Chapter 7 placed all of the design's reasoning in two deterministic containers on the operator's own server and left the model question hanging. This chapter closes it. The failure modes this operator is buying against, stuck values, distorted readings and tank-to-tank signal swapping, are caught by explicit thresholds and consistency rules over polled Modbus data, so the model register holds zero entries, no weights are licensed or held, and no license question arises at all. Figure 7 shows the model stack as it honestly is: a register with no rows.

![Figure 7. The zero models, their placement, and the work each one does.](figures/figure_07.png)

Figure 7. The zero models, their placement, and the work each one does.

### 8.1  Why Zero Models Is a Design Decision, Not an Omission

An empty model register is usually a red flag in a design of this shape, so it is worth stating why it is correct here. Each check the integrity monitor runs is fully specified by physics and protocol. Stuck-value detection compares successive readings of one gauge against the movement a tank can produce; a radar gauge that returns the same level across consecutive polls while the tank is being worked is stuck, and the Buncefield lesson recorded in the design's reasoning is precisely that a flatlined gauge reads as a normal low level, so the check is explicit scope rather than an extra. Swap detection compares the loop and slave address a reading claims with the tank it lands on in the ontology, catching the crossed-signal fault the boosters exist to fix. Distortion detection checks each reading against the quality shape of its loop. Availability accounting aggregates the quality flags into the one measure the rollout tracks: gauge data availability on the central picture, with a fault recorded when readings swap between tanks on the operator's infrastructure.

Each of these is a rule with named inputs, named thresholds set from the signal survey, and a named person who acknowledges the resulting data quality event. None of them generalizes better with a learned component, and none would survive the operator's acceptance clauses, which are data integrity clauses, not accuracy benchmarks. The platform's tooling lens confirmed the same conclusion from the other direction: with no learned components there are no labels, no retraining loop, no model artifacts and no registry, and the versioned deliverables that would have lived in a registry live instead in the documentation pack as OEM configuration packages and as-builts.

The license chapter of a design normally answers one question: what permits the operator to hold the weights it runs. Here the answer is structural. There are no weights, so there is no license trigger, no usage clause and no terms to honor. The only licensing instruments in the design are commercial, not model licenses: the OEM authorization letter that names the service provider and scopes the OEM work, and the twelve-month warranty and support record on the supplied equipment.

### 8.2  The Model and Equipment Register

What the design lacks in models it carries in hardware discipline, and Table 4 records both: the empty model register on the first row, then the hardware classes and sizing rules, the sensing on which every check depends, the pattern the design stands on, and the ground it runs on.

Table 4 · Model and Equipment Register

| The choice | What was picked | Why here |
| --- | --- | --- |
| Model register | Zero entries; all integrity logic is deterministic thresholds and rules | The failure modes are physical and protocol-level, so no learned model is needed, no weights are held and no license question arises |
| Hardware class | Flameproof enclosure discipline | The junction boxes sit in the classified area, so the enclosure class is chosen against the zone at each exact position, not by part number |
| Hardware class | Area classification as the gating document | The zone, gas group and temperature class are read from the operator's current classification drawing before any hardware is specified, and the position list is countersigned |
| Hardware class | Reading an Ex certification marking | The Eex'n' marking is a Zone 2 restricted-breathing class, so a Zone 1 position would force a different, heavier enclosure and must be caught before ordering |
| Hardware class | Equipment protection levels drive the purchase | Protection levels, not catalog convenience, decide the explosion proof junction boxes, 24VDC power supplies, breakers and M20 Exd glands |
| Sensing | radar tank gauges on all 13 tanks | These are the field devices whose readings must arrive continuous, undistorted and unswapped; the design improves their signal path without modifying them |
| Sensing | 24VDC field power supplies | They power the boosters and the loop electronics, and their health is a named failure mode with its own degraded status |
| Sensing | 3-core 2.5 sq.mm CU/PVC/SWA/PVC loop cabling | The loop cabling is the medium the distortion travels in, so its schedule is recorded in the as-built against each loop |
| Sensing | Modbus RTU loop polling via the boosters | The polling cycle is the pace of truth for every check, and the boosters are what make the three loops readable end to end |
| Pattern | System of Context, primary | The central inventory picture is an ontology projection over the gauging host, never a shadow copy, so there is one place where tank truth lives |
| Ground | The operator's own site application server, on-premises | The two containers run inside the operational technology boundary on the operator's own hardware, consistent with the Pakistani Cloud First posture, so nothing about tank truth depends on a link leaving the site |

PART III · CHAPTER 9

## Signal Survey Before Supply, Verification Before Acceptance

Four phases move from survey and topology decision through installation and commissioning to a year of warranty support, each phase carrying named items and an exit gate before the next begins.

Chapter 8 closed the design's registers: a model register empty by design, because every integrity check in this build is deterministic, and a hardware register of four equipment classes that decide what may enter the classified area. This chapter turns that design into ordered work: four phases, fourteen named items, and a gate at the end of each phase that the next phase cannot pass until it is met.

### 9.1  Four Phases, Fourteen Items and Four Gates

Figure 8 lays the sequence out. Phase 1, Survey and Design, carries three items on the Signal Integrity workstream: the RTG loop signal survey across all thirteen tanks and three loops, the booster topology decision for loops 01 and 02, and procurement of the OEM repeaters against the OEM authorization letter. Its exit gate is the location engineer's approval of the written topology recommendation and the confirmed order quantities; no hardware is ordered before that signature.

Phase 2, Installation, carries five items across three workstreams: the HSE work permits for each affected loop, explosion proof junction box supply and installation, the 24VDC power supply and breaker installation, cable laying, termination and conduiting, and marshalling with loop continuity checks. Its exit gate is acceptance of the explosion proof junction box supply and installation against the countersigned position list.

Phase 3, Commissioning and Acceptance, carries five items across four workstreams: end-to-end configuration of the centralized gauging system, signal integrity verification across all thirteen tanks, the tank inventory ontology build, the central inventory picture, and the documentation pack. Its exit gate is a verification run with zero open data quality events and the operator's acceptance signature. Phase 4, Warranty Support, carries one item, the twelve-month warranty and free support arrangement, and closes at the gate where the warranty and support record is marked complete. Across the four phases, requirement coverage stands at five requirements covered, none partial and none in gap.

![Figure 8. The four phases and their gates, and coverage of the 5 requirements across them.](figures/figure_08.png)

Figure 8. The four phases and their gates, and coverage of the 5 requirements across them.

### 9.2  What the Rollout Measures

The rollout measures one number: RTG data availability on the central gauging host, expressed as a percentage against a nominal of 100% and breaching whenever it falls below. The fault condition behind the measure is the one the whole requirement exists to kill: RTG data swapping between tanks on the operator's infrastructure. Beneath the headline number sit the deterministic integrity checks: stuck-value detection, so a flatlined gauge never reads as a calm tank; swap detection, so a level never attaches to the wrong tank; and read-back of loop state, so a degraded booster is visible before it fails outright.

### 9.3  Failure Modes

Six things can go wrong between award and acceptance, and each has a designed answer. Table 5 lists them.

Table 5 · Failure Modes

| What fails | What the design does |
| --- | --- |
| The compliance sheet referenced in the requirement was not published, leaving repeater and power supply specifications undefined at bid time | Fix the OEM models and compliance mapping in a pre-bid clarification, and carry OEM-only equipment as the recorded clarification answer directs |
| Whether RTG loops and 24VDC supplies may be briefly taken out of service under permits during commissioning is unknown | Sequence the work loop by loop so only one loop is affected at a time, and confirm outage windows at the pre-start meeting with the location incharge |
| The hazardous area classification at the junction box positions is unverified; a Zone 1 position would force a heavier enclosure class than the Eex'n' units assume | Read the zone, gas group and temperature class at each exact position from the current classification drawing before ordering, with the position list countersigned |
| A single booster serving loops 01 and 02 may prove not viable, moving the design from two boosters to three and changing cost and cabling | Issue the written topology recommendation in Phase 1 before any hardware is committed, so the change is a decision rather than a rework |
| The service order's 90-day completion window carries liquidated damages of 0.1% per day up to 10% while OEM lead times sit outside the contractor's control | Place the OEM order in Phase 1 against the survey's confirmed quantities, and agree delivery-lead-time relief language in the service order |
| Vendor access to the gauging host is not settled although the end-to-end configuration duty assumes it | Confirm credentials, change control and rollback rights with operator IT and the instrumentation lead at mobilization, before Phase 3 begins |

### 9.4  Lessons From the Shape of the Work

**Survey the signal before ordering anything.** The whole build hinges on one field measurement that decides whether loops 01 and 02 share a booster or carry one each; ordering hardware first would turn a survey finding into a site rework.

**Read the zone at every exact position.** The Eex'n' enclosure class is correct only where the classification drawing says Zone 2; a single uncounted Zone 1 position invalidates the specification, so the position list is countersigned before any purchase order moves.

**A flatlined gauge looks like a calm tank.** Stuck-value detection is explicit acceptance scope, not an extra, because degraded gauging hides the losses this industry reports worst: explosion and fire remain the leading reported cause of oil and gas fatalities (HSE Review 2025). Tank-side incidents such as the Pembroke amine unit explosion show how long degradation can run before anyone sees it (HSE 2011).

**Sequence the outage loop by loop.** Commissioning touches live gauges feeding a central inventory picture; taking one loop at a time keeps the picture degraded rather than dark, and keeps the permit conversation small.

### 9.5  What Is Still Open

Three questions remain open at award, and settling each changes a different part of the plan. The missing compliance sheet is the widest: a pre-bid clarification that fixes the repeater and power supply models closes it and lets procurement move without qualification. Whether loops may be briefly taken out of service under permits changes the commissioning sequence; if outages are refused, the design falls back on single-loop isolation windows agreed at the pre-start meeting. Whether one booster can serve loops 01 and 02 changes the bill of quantities from two certified repeaters to three; the survey answers it before any hardware is committed. A fourth question, vendor access to the gauging host, changes nothing in the design but gates Phase 3 entirely: without credentials, change control and rollback rights agreed at mobilization, the end-to-end configuration duty cannot start.

PART III · CHAPTER 10

## The Inventory Intelligence Should Stay with the Operator

The object model, the as-built documentation, the quality event record and the site boundary all remain the operator's property, so the central inventory picture outlives the service order that built it.

Chapter 9 ended at the last gate, the warranty record marked complete. What matters after that gate is who keeps what, and this chapter states it plainly: everything the design builds stays with the operator.

### 10.1  Ownership of the Model, the Record and the Boundary

The object model is the operator's: fifteen objects, from tank, rtg and loop through reading, dq\_event and picture to service\_order, warranty and the two person records, held as a projection over the centralized gauging system on the operator's own in-country server. No weights or fine-tunes exist to own, because the model register is empty by design; the integrity checks are deterministic logic whose source sits with the operator rather than behind a vendor's service. The decision record is the data quality event object, with its open, acknowledged and resolved vocabulary, joined to the location engineer's acceptance sign-offs; it is the kept record the next decision reads, and it accumulates in the operator's estate for as long as the loops run. The boundary is the operator's too: no reading, no event and no document leaves the site's OT boundary, and the as-built loop documentation, the warranty and support record and the OEM authorization letter all hand over as operator documents, so the central inventory picture outlives the service order that built it.

### 10.2  The Offer Behind the Design

CodeNinja produced this design on Praxis, its platform for designing physical AI systems, and each element of the design maps to one part of that offer: Hyper Ontology is the fifteen-object model projecting over the gauging host; Adaptive Operations is the sensing and detection of physical behavior in the radar gauges and the deterministic checks that catch a distorted or swapped reading; Decision Systems is the quality event record that a named person, the location engineer, ranks, acknowledges and resolves; and Sovereign Infrastructure is the in-country posture, running on the operator's own hardware inside its own OT boundary with no external dependency.

PART IV · CONCLUSION

## The Same Shape Runs on Any Tank Farm

In one view the design is a field repair and a projection at once: a signal survey that decides the booster topology before any hardware is committed, three booster installations in explosion proof enclosures placed by the zone read at each exact position, and a fifteen-object ontology over the centralized gauging host that turns raw radar level readings into a central inventory picture with stuck-value and swap detection, so a failing gauge announces itself instead of quietly reporting a plausible tank.

Running the same shape elsewhere takes four habits rather than new technology: survey the signal before supplying the fix, read the hazardous area classification at each exact position before ordering any enclosure, bind the system of record in place and project meaning over it instead of building a second store, and exhaust deterministic checks before reaching for a learned model. On any tank farm with serial gauging loops, that sequence turns a hardware procurement into an accountable, evidence-carrying system.

PART IV · CHAPTER 11

## How Praxis Contextualized and Reasoned This Design

Every choice in this paper traces back to recorded reading: the ask, the pinned patterns, the eight lenses, the precedent that shaped the acceptance test and the equipment classes that gated the hardware.

Chapter 10 showed that the design's intelligence stays with the operator. This closing chapter shows how the design itself was produced, and lets a reader trace any choice in this paper back to what justified it. Every design in this series is produced on Praxis, and the trace is deliberately open: Figure 9 shows it end to end, from the ask through the family and industry assigned, the records in the room, the eight lenses, the patterns adopted and the equipment classes that gated the hardware.

### 11.1  Contextualizing the Ask

The ask arrived as a published requirement: supply and installation of Modbus boosters for signal improvement of radar tank gauge readings on the centralized gauging software at the operator's storage site, issued with a service order reference, a defined scope across three loops and thirteen tanks, and a completion deadline. Praxis assigned the design to the Physical AI family and the oil and gas industry; the pin was the engineer's own decision rather than a reasoned match, and the brief was still read as a reasoning input. What was in the room: 1,272 records listed, 119 of them read in full and the remaining 1,153 available on demand, among them the requirement documents, the hazardous-area hardware corpus and the Pakistani regulatory instruments.

![Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.](figures/figure_09.png)

Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.

### 11.2  The Lenses

Table 6 gives all eight lenses, what each could see, how many entries it cited and what it contributed. Case studies is the honest gap: nineteen oil-and-gas cases were in the room, but none describes a tank-gauging signal-integrity build at a Pakistani storage site, so no case study is cited as design input. Every other lens contributed.

Table 6 · The Lenses and What They Contributed

| Lens | Could see | Cited | What it contributed |
| --- | --- | --- | --- |
| First principles | The plant ontology discipline: loops and hazardous areas as first class objects, and the split between field hardware and the site server | 2 | Loops, tanks and boosters became first class objects; the field-versus-server split followed the digital-twin and edge-compute tags |
| Case studies | A Pakistani tank-gauging signal-integrity build to copy | 0 | Gap: no case matched, so no case study is cited as design input |
| Tooling and recency | Current versions for every named software product | 2 | the object model v0.9 and the observability and time stack were read from the shelf; the model register stayed empty because the checks are deterministic |
| Hardware and equipment | Hazardous-area hardware practice for enclosures, glands and power | 4 | The Eex'n' junction box class, M20 Exd glands, and the rule that the zone at each exact position is read before hardware is specified |
| Rules and regulations | The Pakistani instruments governing licensed oil storage and works | 2 | The OGRA Ordinance 2002 makes the storage a licensed regulated activity; the Sindh OSH Act 2017 carries the hazard-register and permit duties |
| Approach | A commissioning shape and a degraded mode | 3 | The OT boundary drawn before installation; the degraded mode when a booster fails defined before go live; on-premises compute confirmed |
| History | Tank-gauging failures to learn from | 1 | The recorded Buncefield lesson: a flatlined gauge reads as a normal low level, so stuck-value detection, read-back and alarm visibility became explicit scope |
| Domain fusion | A fusion of the pinned pattern with the sector's discipline | 2 | The central inventory picture as an ontology projection over the gauging host, every object carrying hazardous-area and data-integrity discipline |

### 11.3  Patterns Adopted and Set Aside

One pattern was adopted, system of context as the primary pattern, and it was earned by the requirement's own words, which ask for radar gauge readings from thirteen fuel tanks to land in one central inventory picture across three loops and the gauging host. The pattern carries four commitments in fixed order: systems of record below, never replaced, never modified, never loaded; the ontology as a projection over them, never a shadow copy; one small grammar turning nouns into objects, facts into properties and relationships into typed links; and a kinetic loop that closes sense, decide, act and learn. No patterns were set aside: no reference architecture beyond the pin was needed, because the hardware and protocol layers are classes rather than architectures. One precedent shaped the build: in the recorded Supermajor case, analysts lost months hand-mapping historian tags, which is why the thirteen tanks, three loops and gauges are contextualized once in the ontology rather than re-mapped by every consumer.

### 11.4  Where the Reasoning Lands

The reasoning lands on four equipment classes: Flameproof Enclosure Discipline, which governs what may be installed in the classified area; Area Classification Is The Gating Document, which makes the zone drawing the first thing read and the last thing trusted; Reading An Ex Certification Marking, which turns certificate text into a purchase decision; and Equipment Protection Levels Drive The Purchase, which replaces part numbers with the protection level each exact position demands. Beyond the hardware, the reasoning ends where the acceptance test begins: the flatline lesson that shaped stuck-value and swap detection, and the two Pakistani instruments that make the storage a licensed, regulated activity. Everything shown in this paper was recorded reading: the requirement text, the lens citations, the case precedent, the equipment rules. Nothing is inferred.

Appendix A

## What It Costs

The design buys no compute and serves no model. The integrity checks are deterministic rules that run on the operator's existing gauging host and server, and the model register is empty by design, so there is no owned-versus-rented comparison to print. The equipment the design does buy is field hardware inside the requirement's own supply scope: OEM-authorized Modbus boosters (repeaters), hazardous-area junction boxes, field power supplies and loop cabling. Those lines are priced by the OEM's quotation against the signal survey, not by any public list price, so this appendix prints none.

### A.1 What Would Change the Answer

| Line | When it appears | How to price it |
| --- | --- | --- |
| Booster count | If the signal survey finds a loop needs a second booster, or one loop needs none | One OEM quotation per installation; the survey sets the count, not the paper |
| A learned anomaly model | If deterministic checks stop catching a new failure pattern | A small time series model on CPU at the operator's server; no GPU class is required at this scale |
| A generative work surface | If the operator later asks questions of the inventory model in natural language | A frontier open-weight model on one node of eight 141 GB HBM-class GPUs, 320,000 to 420,000 dollars (Mercatus 2026), which needs a US export licence for Pakistan |

### A.2 Sources for This Appendix

- Mercatus. 2026. H200 server price. <https://mercatus-ai.com/blog/h200-server-price>

SOURCES

## Source Register

HSE Review. 2025. 'Explosion, fire or burns' leading cause of oil & gas fatalities. <https://hsereview.com/regional-coverage/north-america/explosion-fire-or-burns-leading-cause-of-oil-gas-fatalities>

CSB. 2005. INVESTIGATION REPORT. <https://www.csb.gov/assets/1/20/csbfinalreportbp.pdf>

HSE. 2011. Chevron Pembroke Amine regeneration unit explosion 2 June 2011: An overview of the incident and underlying causes. <https://www.hse.gov.uk/comah/assets/docs/chevron-pembroke-report-2020.pdf>

NBC News. 2009. BP fined record $87 million for refinery blast. <https://www.nbcnews.com/id/wbna33549487>

---

### About CodeNinja

CodeNinja is a Middle Eastern-American artificial intelligence lab focused on building self-improving systems. We are reinventing knowledge work to close the loop between vertical AI use cases and the generalized intelligence that fuels it, accelerating the path toward organizational superintelligence.


---

# Terminal Pulse: Predicted Truck Turn Time and Live Yard Sight for a Container Terminal

Canonical: https://codeatoms.ai/truck-turn-container-terminal-us/
DOI: https://doi.org/10.5281/zenodo.23159331
PDF: https://codeatoms.ai/truck-turn-container-terminal-us/paper/terminal-pulse-truck-turn-time-container-terminal-us.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

VERTICAL-DRIVEN ARCHITECTURES · MARITIME & PORTS · DESIGNED WITH PRAXIS · OCTOBER 2026

# Terminal Pulse: Predicted Truck Turn Time and Live Yard Sight for a Container Terminal

A live object model of vessel, yard, gate, crane, reefer and rail data that predicts truck turn time two hours out, names the cause and watches for conflicts as they happen, for a container terminal operator in the United States.

CodeNinja Engineering Team

For the terminal operations director, the yard, vessel and rail planners, and the platform, data and vision engineers who would build and run it.

---

Vertical-Driven Architectures is a CodeNinja series of system designs. Every design in the series is driven by a real-world problem and scenario in a single industry, and every one is designed on Praxis, CodeNinja's platform for designing physical AI systems. Operations are described by class, never by name.

At a glance

## Predicted truck turn time for a container terminal in the United States

**What this is.** An open reference architecture for system design in physical AI: truck turn time predicted two hours out and yard congestion seen live, at a container terminal, on the operator's own hardware with no outbound connection. It is written for terminal operations leaders and for the engineers who would build it. The operator is an illustrative scenario, not a CodeNinja customer.

**The answer in numbers.**

| Part | The design |
| --- | --- |
| Sources joined | 11 systems, including the terminal operating system, the gate system, two crane management systems, reefer monitoring, railroad switch lists, cameras and weather and tide feeds |
| Object model | 12 typed objects and 11 links, published as JSON for reuse |
| Models | 5 self-hosted open models: GLM 5.3 (reasoning), Chronos-2 (forecasting), Qwen3-Embedding-0.6B (retrieval), RF-DETR (vision), Roboflow trackers |
| Frontier compute | One node of eight 141 GB HBM-class GPUs holds GLM 5.3 at FP8 (753 GB of weights, 904 GB with headroom), at about 10 kW |
| Edge | Fanless IP-rated enclosures at the yard blocks, gate and quay; no safety reflex crosses a network hop |
| Three-year cost, owned | About 722,000 US dollars with support and power at the US industrial power price |
| Three-year cost, rented | 0.99 million to 2.52 million US dollars for the same GPUs around the clock; ownership is about four fifths the deepest three-year commitment (version 2) |
| Closed model break-even | The cheapest closed model matches the owned stack at about 35 users; above that, ownership is cheaper and the gap grows with every user |
| Human control | Surfaces warn and propose; the named planner acts in the terminal operating system and the named safety supervisor acknowledges every safety event |

**Reuse it.** The object model, the model register and the figures are free to reuse under CC BY 4.0.

**Made with.** Reasoned on [Praxis](<https://codeatoms.ai/praxis/>), CodeNinja's platform for designing physical AI systems. The object model imports into [Hyper Ontology](<https://codeatoms.ai/hyper-ontology/>), which turns it into a living system. Both are in beta; access by request.

ABSTRACT

## A Congestion Spike Should Be Named While It Is Still Forming

Truck turn time is the number the trucking community feels and the number a container terminal cannot currently explain while it is happening. Turn time at this operator averages 54 minutes and spikes above 90 minutes on resin export peaks, and the interacting causes live in separate systems: the terminal operating system knows the moves, the gate system knows the trucks, the crane controllers know the cycles, the cameras see the queues, and rail dwell arrives weekly after the fact. Planners stitch these slices together in their heads at the 06:00 and 14:00 operations meetings, so a spike is explained hours after the trucks have felt it, and safety conflicts in the transfer zones are found in incident reports rather than seen.

The design builds one live model of the terminal. Eleven source systems, from the terminal operating system and gate OCR to two crane makers' controllers, the reefer monitors, railroad feeds and the existing 220-camera estate, enter through three adapter families into a model of twelve objects with typed links, served by seven services and four decision surfaces. Five models carry the intelligence: detectors and trackers on edge compute at the yard blocks and gate, time series forecasting and retrieval embeddings on a site inference node, and frontier open weights on an eight-GPU node inside the operator's own data center within its facility security boundary, so no data leaves the site and every reassignment remains a planner's decision made inside the terminal operating system.

The paper opens with the problem and the join failure across the terminal's systems, then sets the constraints, the layered stack, the twelve-object model, ingestion through the adapter tier, and the placement of inference from the yard edge to the operator's own hardware, before registering the five models and their licenses. Part III covers the phased rollout, whose first gate proves or redirects the yard-side hypothesis using gate OCR data the operator already holds, and the ownership of everything built. It closes with the Praxis chapter, which traces every design choice back to what was recorded.

---

![Figure 1. Terminal Pulse on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.](figures/figure_01.png)

Figure 1. Terminal Pulse on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.

## Contents

Each chapter is tagged for the reader it serves most directly: Executive, Team Lead, FDE, Reference.

|  |  |  |
| --- | --- | --- |
|  | Abstract · A Congestion Spike Should Be Named While It Is Still Forming | Executive |
| PART I · THE PROBLEM | | |
| 1 | [Turn Time Spikes Before Any Planner Can See Why](#ch1) | Executive |
| 2 | [Every Terminal System Sees One Slice of the Operation](#ch2) | ExecutiveTeam Lead |
| PART II · THE DESIGN | | |
| 3 | [Four Constraints Shape the Design Before Any Component](#ch3) | Team Lead |
| 4 | [One Stack Runs From Systems of Record to Surfaces](#ch4) | Team LeadFDE |
| 5 | [Twelve Objects Turn Terminal Data Into One Argument](#ch5) | FDE |
| 6 | [Every Source Enters Through an Adapter, Never Directly](#ch6) | FDE |
| 7 | [Detection Belongs at the Edge and Reasoning In-Country](#ch7) | FDE |
| 8 | [The License Decides What the Operator Can Own](#ch8) | FDEExecutive |
| PART III · THE ROLLOUT | | |
| 9 | [Shadow Mode Comes Before Any Flag Is Trusted](#ch9) | Team LeadExecutive |
| 10 | [The Intelligence Should Stay with the Terminal That Produced It](#ch10) | Executive |
| PART IV · HOW IT WAS DESIGNED | | |
|  | Conclusion · A Terminal Seen Whole Can Be Run Whole | Executive |
| 11 | [How Praxis Contextualized and Reasoned This Design](#ch11) | Team LeadFDE |
|  | [Sources](#sources) | Reference |

PART I · CHAPTER 1

## Turn Time Spikes Before Any Planner Can See Why

The causes of a turn time spike interact across five systems, so no one at the terminal sees the spike forming until the trucks are already waiting.

The abstract named the design in one paragraph: one live model of the terminal, built beside the systems that already hold its data. This chapter establishes the ground under that design, describing the question the operation cannot answer today, the documented cost of answering it too late, and the operation itself as the scenario the system must serve.

### 1.1  The Question, the Data and the Regulatory Ground

The question the operation needs answered is narrow and constant: why is truck turn time climbing right now, which interaction among yard congestion, gate exceptions, rubber tyred gantry availability and vessel discharge order is driving it, and what should be reassigned before the queue outside the gate grows. Turn time is the interval from gate in to gate out for a visiting truck, and the operator's average sits at 54 minutes, spiking above 90 minutes on resin export peaks. Answering the question while it is happening requires data the terminal already holds: vessel, yard and gate transactions in the terminal operating system, appointments, optical character recognition reads and radio frequency identification tags at the gate, cycle times, faults and fuel from two crane manufacturers' management systems, the camera estate over the yard, rail switch lists from two railroads, and weather and tide. The failure is not a missing sensor; it is that the data never meets.

The regime around the answer is fixed. Customs and Border Protection governs the container transactions themselves; the United States Coast Guard administers facility security under the Maritime Transportation Security Act, which bounds where terminal data may live; the Occupational Safety and Health Administration's marine terminal rules at 29 CFR 1917 govern yard safety; and the state environmental permit over the diesel fleet makes idling evidence reportable. The terminal sits on a flow that matters: about 80 percent of world trade volume moves by sea (Defesa n.d.), and a container terminal that cannot explain its own queue pushes delay outward to every trucking company and shipping line it serves.

### 1.2  The Documented Cost of Seeing Late

The industry record does not publish a per-terminal figure for turn time variance, and this design does not invent one. What the public record does document is the price of situational awareness that arrives late or incomplete. Maritime regulators already treat an awareness gap as a formal safety concern rather than a soft failing, analysing it as part of the competence required of anyone responsible for a moving maritime operation (MDPI 2020). The consequence of not seeing a developing hazard is on the record: a bulk carrier and a towing vessel collided on a busy United States shipping channel in July 2024 (Maritimecyprus 2024), and an operator was fined 6 million dollars over a 2024 runaway ship incident in which a required report was never made (Allaboutshipping 2024). Inside the terminal the cost is quieter but continuous: a variance discovered at the 06:00 operations meeting is already hours old, the trucks have waited, and the cause is reconstructed rather than observed.

### 1.3  The Operation as a Scenario

The operation is a container terminal on a major United States shipping channel, running two berths served by eight ship to shore cranes, twenty six rubber tyred gantry cranes across fourteen yard blocks, eleven truck gate lanes with optical character recognition portals, and an on dock rail ramp served by two Class I railroads. Throughput is more than a million twenty foot equivalent units a year, growing with Gulf resin exports and nearshoring imports, and eleven hundred reefer plugs carry refrigerated cargo. About sixty percent of visiting trucks carry radio frequency identification tags. Labour is International Longshoremen's Association labour under the master contract, worked across three shifts.

The people in the loop are eight roles: yard planners, vessel planners and rail coordinators who make the judgement calls; gate, safety and maintenance supervisors who act on alerts; the longshore crews and equipment operators whose work the cameras observe; and port authority staff who receive the monthly performance report. The physical environments are the quay and apron, the transfer zones where trucks meet gantry cranes, the yard blocks, and the gate plaza and rail ramp. The scenario holds nine named source systems, eight roles and four distinct working environments, and the design that follows must serve all of them without replacing any system they already run.

PART I · CHAPTER 2

## Every Terminal System Sees One Slice of the Operation

The terminal operating system, the gate system, the crane controllers and the cameras each hold one true slice of the terminal, and none of them together can answer what the planners ask at 06:00.

Chapter 1 showed a terminal whose data exists but never meets, and a cost recorded in the industry's investigation history. This chapter shows why the data never meets: each existing system holds one true slice of the operation, and the join between the slices exists only in the planners' heads.

### 2.1  What Each System Sees and What It Misses

The terminal operating system sees every vessel, yard and gate transaction: the move counts, the discharge order, the block assignments, the container's declared position. It misses the physical yard. A crane cycle that ran long, a queue forming at a lane, a pedestrian in a transfer zone are invisible to it, and a yard record can disagree with what the cameras and cranes actually see. The gate operating system sees the trucks: appointments, optical character recognition reads, radio frequency identification tags, lane queues and exceptions such as chassis mismatches. It misses everything after the kiosk; once the truck passes the gate it disappears into the yard with no observable state until it returns.

The crane management systems, one per manufacturer, see the machines: cycle times, fault codes, fuel and running hours for both ship to shore and rubber tyred gantry cranes. They miss the transaction context, so a slow cycle cannot by itself be attributed to congestion, a fault cascade or a discharge order change. The reefer monitoring system sees eleven hundred plugs' temperature and power, and nothing else. The rail feeds see the ramp unevenly: one railroad supplies near real time switch lists, the other reports weekly and after the fact, so the true state of a rail cut rests on whichever railroad owns it. The camera estate, two hundred and twenty fixed cameras on a video management system with thirty day retention, sees the queues, the transfer zones and the conflicts, but it sees them as video alone, without identity, transaction or equipment context. Weather and tide feeds see the conditions the pilots work under and nothing of how the terminal responds to them. Access control and Transportation Worker Identification Credential readers see who entered which zone; the safety incident document system sees only what was written down after the fact.

### 2.2  What None of Them See Together

Figure 2 sets these slices side by side, and the gap between them is the problem. No system can attribute a turn time spike to yard congestion rather than gate exceptions, because attribution needs the gate slice, the yard slice, the crane slice and the vessel slice joined on the same clock. No system can warn two hours ahead, because prediction needs the join too. The planners therefore stitch the picture by hand at the 06:00 and 14:00 operations meetings; rail dwell arrives weekly from the railroads, after the fact; and safety events surface in incident reports rather than being seen. The operator's own working hypothesis, that most turn time variance is yard side rather than gate side, is untestable while the slices never meet. That untestable hypothesis is the cost in practice: the terminal pays for the join in planner attention every shift and still cannot answer the question once.

![Figure 2. Nine systems, each seeing one part of the answer. the question needs all of them in one place at once.](figures/figure_02.png)

Figure 2. Nine systems, each seeing one part of the answer. the question needs all of them in one place at once.

PART II · CHAPTER 3

## Four Constraints Shape the Design Before Any Component

Sitting beside the systems of record, keeping safety reflexes at the edge, holding data inside the security boundary and leaving every decision to a named person shape everything downstream.

Chapter 2 left the join unbuilt: nine true slices, no model to hold them. This chapter fixes the four constraints the design accepts before any component is chosen, because each one is hard to honour in this industry and each one shapes what follows.

### 3.1  Sit Beside the Systems of Record, Never in Front of Them

The terminal operating system is the audited record of every vessel, yard and gate transaction, and shipping lines, Customs and Border Protection and the operator's own governance all read it as truth. A design that writes back into it during the first phase would put an unproven model inside that chain of trust, and would need International Longshoremen's Association local and internal information technology sign off before a single reassignment flowed. The design therefore projects the systems of record into one object model and stays read only, with planners acting inside the terminal operating system exactly as they do today. This is hard in this industry because the temptation runs the other way: the fastest demo writes back, and the fastest demo is the one that breaks the audit.

### 3.2  Keep Safety Reflexes at the Edge

A pedestrian in a transfer zone next to a moving rubber tyred gantry cannot wait for a round trip to a server room, across a yard network that salt air, steel stacking and hurricanes degrade. The design keeps detection, tracking and conflict geometry on edge compute at the yard blocks, the gate and the ramp, so the safety reflex never crosses a network hop. This is hard here because the yard is the hostile case for edge compute: fanless enclosures, dirty and sunstruck camera optics, and a power supply that must survive generator transfer. The degradation contract follows from the same constraint: when the link drops, the edge reports stale state loudly rather than failing silently.

### 3.3  Hold the Data Inside the Security Boundary

The Maritime Transportation Security Act facility security plan governs the terminal, and camera footage of longshore labour is exactly the data that must never leave. The design runs every model, every weight and every record inside the operator's own data center within that plan, with in country colocation reserved for hurricane disaster recovery, and federates identity to the Transportation Worker Identification Credential backed access model. This is hard because the boundary is bureaucratic as well as technical: a facility security plan amendment has lead time, so it sits on the critical path of the build rather than in a risk register.

### 3.4  Leave Every Decision to a Named Person

Union labour rules and plain accountability both forbid a model that reassigns cranes or closes a lane on its own. The design names the decider for every output: the yard planner accepts or rejects a reassignment inside the terminal operating system, the safety supervisor acknowledges every seen event, and the model proposes only. This is hard because the operation runs three shifts under pressure, and an advisory system that planners override without a record would quietly become decoration; the design therefore keeps the decision, the outcome and the reasoning together so the next decision reads them.

### 3.5  Scoping Decisions and Their Price

Three scoping decisions follow from the four constraints, and each buys something at a price the operator accepts knowingly. Table 1 states them.

Table 1 · Scoping Decisions

| Decision | What it buys | What it costs |
| --- | --- | --- |
| Read only projection beside Navis N4, planners acting in N4 | No change to the system of record, no write path to audit, faster security approval | Every reassignment remains a human keystroke, so the model advises and never acts |
| Agent building surface for planners, vessel planners and rail coordinators only | The three judgement roles get the frontier weights on the operator's own hardware | Gate, safety and maintenance supervisors receive alerts and dashboards but build no agents |
| Reuse the existing 220 camera estate, judged camera by camera against six reuse gates | Sensing without new capital, new cable runs or new gate hardware | Some angles fail the gates and stay unsensed until a camera is moved or added |

### 3.6  What the Design Chose Against

Each choice was made against a named alternative, and the reasons are part of the design because a future maintainer will meet them again. Table 2 records them, closing with what sits outside scope entirely.

Table 2 · What the Design Chose Against

| Where | What was picked | Instead of, and why |
| --- | --- | --- |
| First gate | Gate OCR proof inside the eight week demonstrator | Instead of a separate one month study before any build: the proof gates the demonstrator's direction, and a gate side result redirects the build to lanes and appointments rather than stopping it |
| Terminal operating system integration | Read only against N4 in the first phase | Instead of writing approved reassignments back into the record: write back returns as a second phase option gated on ILA local and internal information technology sign off |
| Agent surfaces | Committed agent building surfaces for the three judgement roles | Instead of surfaces for every named role: supervisors act on alerts and the port authority receives the monthly performance report only |
| Scope boundary | No new cranes, RTGs or gate hardware, and no individual worker productivity analytics | Instead of broadening scope: the requirement excludes new handling hardware, and labour rules forbid camera analytics that measure individual productivity, so the design carries safety and equipment monitoring only |

PART II · CHAPTER 4

## One Stack Runs From Systems of Record to Surfaces

A layered stack carries terminal data from the systems of record through one object model to the surfaces where planners, coordinators and safety supervisors act.

Chapter 3 fixed the constraints: the model sits beside the systems of record and never in front of them, sensing stays at the edge, every decision stays with a named person, and the first gate can redirect the build cheaply. This chapter shows the stack that carries those constraints down to named components.

### 4.1  Records Below, One Model in the Middle, Agents Above

Sea transport carries about 80 percent of world trade volume, and a container terminal is one of the points where that volume compresses into truck minutes and rail cutoffs (Defesa n.d.). The terminal's difficulty is not a shortage of data; it is that each system holds one slice and the planners stitch the slices in their heads at two meetings a day. The same shared-picture logic that vessel traffic services guidance addresses to port authorities (Service n.d.) applies one layer down, inside the gate.

The architectural pattern is therefore three bands. Below sit the systems of record: the terminal operating system, the gate operating system, the two crane management systems, the reefer monitoring system, the railroad feeds, the camera estate and video management system, the access control readers and the incident document system. In the middle sits one object model, rebuilt continuously from an event backbone, holding twelve objects that project the terminal's live state. Above sit seven services that turn the model into predictions, detections and reports, and four surfaces that put each output in front of the person who decides. The pattern fits because it never asks a system of record to stop being authoritative: the terminal operating system remains the system of record for every move, and the model is a projection of it, never a rival. Planners act inside the system they already trust. Figure 3 shows the layered stack with its counts per layer: eleven sources, three adapter families, twelve objects, five models, seven services and four surfaces.

![Figure 3. The layered stack: 11 sources, 3 adapter families, 12 objects, 7 services and 4 surfaces.](figures/figure_03.png)

Figure 3. The layered stack: 11 sources, 3 adapter families, 12 objects, 7 services and 4 surfaces.

### 4.2  The Stack Stage by Stage

Table 3 walks the stack from the bottom band to the top, naming the component or family that carries each stage's responsibility.

Table 3 · The Stack, Stage by Stage

| Stage | What it is responsible for | How |
| --- | --- | --- |
| Sources | Hold the authoritative transactions and records the terminal already runs on | Navis N4, the gate operating system, two OEM crane management systems, the reefer monitoring system, railroad EDI and switch lists, the camera estate and its video management system, NOAA weather and tide feeds, access control and TWIC readers, and the safety incident document system |
| Sensing | Turn physical yard, gate, quay and ramp activity into machine-readable events | 220 fixed cameras on the existing video management system, gate OCR portals and RFID tags, STS and RTG PLC and CMS cycle, fault and fuel feeds, temperature and power on 1,100 reefer plugs, and NOAA weather and tide |
| Adapters | Move every event from source to backbone without ever writing back | Three adapter families: integration adapters for APIs and databases, EDI adapters for BAPLIE, COPRAR and switch lists, and file and document adapters for reports and incident records |
| Object model | Hold one live, queryable projection of the terminal | Twelve objects with typed links, rebuilt continuously from the event backbone inside the operator's own boundary |
| Inference | See, track and forecast on the model's streams | Edge detectors and trackers on the camera streams, Chronos-2 forecasting turn time and queues two hours out, an embedding model for retrieval, and GLM 5.3 serving the work-surface agents on the operator's own GPU node |
| Services | Turn predictions and detections into named operational outputs | Operations design, live terminal model, turn time prediction, safety and yard vision, platform build, work surface, and compliance reporting |
| Surfaces | Put each output in front of the person who decides | The yard congestion and reassignment surface, the vessel call and discharge order surface, the rail cut risk surface, and the safety event review surface |

PART II · CHAPTER 5

## Twelve Objects Turn Terminal Data Into One Argument

Twelve objects with typed links turn transactions, telemetry and video into one queryable model of the terminal's live state.

Chapter 4 placed one object model in the middle of the stack. This chapter opens that model object by object and shows what its links let a single query reach.

### 5.1  Twelve Objects and the Links Between Them

The twelve objects are Vessel Call and Truck Visit (events), Container (material), Yard Block and Transfer Zone (sites), RTG and Ship to Shore Crane (assets), Reefer Plug (asset), Gate Lane (asset), Rail Cut and Safety Event (records), and Yard Person (person). Each is anchored in the system of record that owns it: Vessel Call, Container and Yard Block in the terminal operating system; Truck Visit and Gate Lane in the gate operating system; RTG and Ship to Shore Crane in their OEM crane management systems; Rail Cut in the railroad switch lists; Safety Event in the incident document system; Yard Person in the access control and TWIC readers. Figure 4 draws every object and its typed links, with the links carrying verbs rather than bare references: a yard block assigns an RTG, a truck visit enters through a gate lane, a vessel call discharges containers, a reefer plug powers a container, a safety event occurs in a transfer zone.

The links are what make the model an argument rather than a store. Start from one truck visit whose turn time ran long: follow its gate lane to the exception that held it, follow the container it carried to its yard block, follow the block to its assigned RTG and that unit's fault codes, follow the container to its vessel call, discharge order and crane split, and follow it onward to the rail cut whose cutoff it may miss. A document store can hold every one of these records and still answer none of that, because it cannot traverse the relationships; the typed links make the whole traversal one query, which is exactly what turn time attribution and congestion warning require.

![Figure 4. The twelve objects of the model and the typed links that let a query reach across them.](figures/figure_04.png)

Figure 4. The twelve objects of the model and the typed links that let a query reach across them.

### 5.2  Where the Human Loop and the Boundary Sit

The human loop lives at the surfaces and at one record. Every surface warns and proposes; the named planner acts inside the terminal operating system, the named safety supervisor acknowledges a safety event, and the disposition lands on the record with the person's identity attached. The model advises; it never moves a crane or closes a lane on its own.

The hosting posture keeps the model inside the boundary. All twelve objects live in the operator's own data center inside the facility security plan, on generator-backed power, with in-country colocation reserved for hurricane disaster recovery. Identity federates from the operator's directory under a TWIC-backed access model that separates planner, supervisor and auditor roles. There are no external links: the model holds no outbound connection and reads every source. The only write path is into the model's own records, chiefly the safety event disposition and acknowledgment, and write-back into the terminal operating system is a second-phase option gated on labour and IT sign-off.

### 5.3  One Object in Its Recorded Form

Truck Visit is the object the hypothesis proof reads, and its recorded form appears below.

```
{
  "id": "vessel-call",
  "label": "Vessel Call",
  "kind": "event",
  "anchored_in": "Navis N4",
  "properties": [
    "Berth window",
    "Discharge order",
    "Crane split",
    "ETA",
    "Move count"
  ],
  "status_vocabulary": [
    "Planned",
    "Alongside",
    "Working",
    "Complete"
  ],
  "links": [
    {
      "to": "container",
      "label": "discharges to"
    }
  ]
}
```

PART II · CHAPTER 6

## Every Source Enters Through an Adapter, Never Directly

Eleven source systems enter only through three adapter families onto an event backbone, so the live model never touches a system of record directly and the read-only posture holds.

Chapter 5 described what the model holds. This chapter describes how data gets into it, and what the adapter tier promises on the way.

### 6.1  Eleven Sources, One Map

Eleven source systems feed the model, and Figure 5 maps each one to its adapter path. Navis N4 carries the vessel, yard and gate transactions, together with the EDI exchange with shipping lines that moves BAPLIE stowage plans and COPRAR discharge orders. The gate operating system holds the appointments, the OCR reads and the RFID tags on about 60 percent of visiting trucks. The two OEM crane management systems carry STS and RTG cycle times, faults and fuel. The reefer monitoring system carries temperature and power for 1,100 plugs. The rail path is asymmetric: one railroad supplies near-real-time switch lists over EDI while the other reports weekly after the fact, so ramp cameras count cuts where the data arrives late. The 220-camera estate rides its video management system. NOAA weather and tide feeds join so predictions carry the conditions pilots work under, a real concern where a single collision can close a shared channel and stop a terminal's vessel work without warning (Maritimecyprus 2024). Access control and TWIC readers anchor the Yard Person object, and the safety incident document system holds the paper history that camera detections join. Every source carries the same provenance class: operator-held, read through its adapter, never written.

![Figure 5. The 11 named systems, the adapter path each one takes, and the object model they all map into.](figures/figure_05.png)

Figure 5. The 11 named systems, the adapter path each one takes, and the object model they all map into.

### 6.2  What the Adapter Tier Guarantees

The adapter tier makes five promises. First, read-only: no adapter holds a write credential against any source, so the posture holds by construction rather than by policy. Second, schema mapping happens at the adapter, so a source's fields become object properties once and no source system ever changes for the model's sake. Third, idempotent replay: every event carries its source identity and source timestamp, so redelivery after a restart changes nothing. Fourth, late and partial data are typed as such rather than dropped, which is why the weekly railroad feed still enters the model, flagged for its age. Fifth, backpressure: an adapter buffers upstream when the backbone slows, so a burst of gate OCR reads never pushes overload into the stores. The video path keeps the same discipline: analytics ride the existing streams and the video management system keeps its 30-day retention untouched.

### 6.3  The Event Backbone

The backbone is Apache Kafka 4.3 on KRaft, running inside the operator's boundary. Ordering is per entity key, so one truck visit, one yard block or one rail cut always replays in sequence even when events arrive out of order across sources. Delivery is at-least-once with idempotent consumers, which pairs with the adapters' replay guarantee. Brokers replicate across the data center so a single node loss loses nothing, and buffering is sized for the outage window that matters here: a hurricane shutdown and generator transfer. Network UPS tools force clean shutdown, the time grandmaster holds its clock across the transfer, and on recovery consumers resume from their last committed offsets. When a link or a feed degrades, the model's contract is stale-marked reporting rather than silence, because an awareness gap during degraded operation is a formal safety concern in maritime human factors work (MDPI 2020).

PART II · CHAPTER 7

## Detection Belongs at the Edge and Reasoning In-Country

Pedestrian and conflict detection must run at the yard block within a camera frame's time, while forecasting and language reasoning stay on the operator's own hardware in-country.

Chapter 6 closed the path into the model: eleven named sources, three adapter families, one ordered event backbone. This chapter decides where the compute sits that turns those events into warnings, and it fixes a rule the whole design leans on: detection happens at the yard block, forecasting happens in the server room, and language reasoning happens on the operator's own hardware in-country. Figure 6 shows all three tiers and what crosses between them.

### 7.1  Three Tiers, One Arithmetic Each

The edge tier is fanless, IP-rated compute enclosures at the yard blocks, the gate and the quay. Each enclosure runs an RF-DETR detector for pedestrians, trucks, RTGs, chassis and queues, and a Roboflow tracker on CPU beside it that gives each detection an identity across frames. The checkpoints are small: about 61 to 68 MB at 16 bit for the Nano to Large sizes, about 254 MB at 16 bit for 2XL, so several camera streams share one accelerator. The serving runtime, drawn from a shelf that includes ONNX Runtime, OpenVINO and Triton, is pinned per accelerator after the bench measurement on actual streams and models that the sizing rule requires, because a detector sized from a datasheet rather than from the yard's own footage is the first way a vision system disappoints. Detection lives here and nowhere else for a physical reason: no safety reflex crosses a network hop, and work on autonomous and remote shipping treats an awareness gap introduced by a remote link as a formal safety concern rather than a nuisance (MDPI 2020). The site tier is one GPU server room node, H100-class 80 GB or L40S-class 48 GB, running Chronos-2 and Qwen3-Embedding-0.6B. The arithmetic is modest: Chronos-2 carries about 0.48 GB of weights at FP32, about 0.24 GB at 16 bit, and the embedding model about 1.2 GB at bf16, about 0.6 GB at 8 bit, plus activation memory that grows with its 32K window. Both fit on one card with room for those activations. The site tier exists because forecasting needs terminal-wide state: turn time is predicted two hours out against vessel discharge order, appointments and weather joined with each block's queue, and only the site tier sees all of those at once. The central tier is the frontier node: one 8-GPU machine of the 141 GB HBM class serving GLM 5.3 for the planner work surface and ontology maintenance. The memory arithmetic runs like this: 753 billion parameters at FP8, one byte per parameter, give 753 GB of weights; multiply by 1.2 for the KV cache and activations and the GPUs must hold 904 GB; eight GPUs of 141 GB give 1,128 GB, so the KV cache ceiling sits about 224 GB below usable memory. That is one node at about 10 kW, inside the power envelope of the operator's own generator-backed data center within the MTSA facility security plan, with in-country sovereign colocation reserved for hurricane disaster recovery. VLLM or SGLang serve the weights, the version pinned at install against the node's startup log line.

![Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.](figures/figure_06.png)

Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.

### 7.2  The Latency Budget

The budget is three clocks, each owned by a tier. The first is the camera frame: detection, tracking and the transfer-zone conflict verdict complete at the edge, so the strobe decision and the safety event never wait on a network. The second is the operational clock: the turn time and congestion forecast is recomputed as the event backbone delivers new crane cycles, gate reads and appointment changes, and residual thresholds against the forecast name the cause while a planner can still reassign an RTG, which is the whole point of a two-hour horizon. The third is the human clock: a planner's question at the work surface is an interactive session against the frontier node, while shift reconciliations and ontology maintenance run as asynchronous jobs behind it, so one planner's query never queues behind another's batch work.

### 7.3  What Crosses, and What Fails

Crossing outward from the edge are only detections, tracks, counts, queue lengths and cycle telemetry; camera frames stay inside the yard network and the video management system keeps its 30-day retention. Crossing inward are model weights and container images, moving one way over Lidi on a hardware data diode, so nothing outside the boundary can open a path back into yard compute. Three failures are designed for rather than feared. If the yard link drops, the edge cluster, chosen as the lightest that survives a yard network loss, keeps detecting and buffers its events, and the degraded-mode contract is stale reporting, never silent failure. If power fails or a hurricane forces a generator transfer, Network UPS Tools shuts the enclosures down cleanly and the OCP Time Card grandmaster holds time across the transfer window, so camera frames, PLC cycles and gate reads stay on one clock. If the update path fails, the Harbor registry inside the boundary holds the last mirrored images and detector weights, MLflow keeps model versions with rollback, and every edge box runs its last good weights until the diode carries the next one.

PART II · CHAPTER 8

## The License Decides What the Operator Can Own

Every weight in the design carries a license that lets the operator hold it on its own hardware inside the security boundary, and that fact decides the model register.

Chapter 7 fixed the three inference tiers and the arithmetic each must satisfy. This chapter fills them: five models, the license each carries, and why each license permits the operator to hold its weights on its own hardware inside the security boundary. Figure 7 shows the stack, from the edge detectors at the bottom to the frontier work-surface weights at the top.

![Figure 7. The five models, their placement, and the work each one does.](figures/figure_07.png)

Figure 7. The five models, their placement, and the work each one does.

### 8.1  Five Models and Their Licenses

GLM 5.3 is the work-surface model: the agentic surface where yard planners, vessel planners and rail coordinators question the live terminal model, build and run their own agents, and maintain the ontology. It is frontier class, with 753 billion parameters filed and FP8 and BF16 weights published openly on 28 August 2026. It runs on the central tier, one 8-GPU node of the 141 GB HBM class, where the FP8 weights plus KV headroom fit per the arithmetic in Chapter 7. Its license is bespoke: commercial use and redistribution are permitted with attribution, and it carries no revenue or model-as-a-service trigger, which is the fact that lets the weights live on the operator's own node rather than behind someone else's interface. It was chosen because this run's checks confirm it as the strongest open agentic model available to the design. RF-DETR is the edge detector: a real-time detection transformer family that finds pedestrians, trucks, RTGs, chassis and queues on the existing fixed cameras. Its footprint runs from about 61 to 68 MB at 16 bit for the Nano to Large checkpoints to about 254 MB at 16 bit for 2XL. The Apache-2.0 license covers the package and the detection checkpoints with no field restriction, so the operator may hold, fine tune and run them indefinitely. It was chosen because it is real-time on edge GPUs and built for fine tuning on site footage, which makes the operator-owned adaptation path real work; YOLO26 was set aside for its AGPL exposure and DEIMv2 for its non-commercial license, and open-vocabulary detectors were set aside because the terminal's classes are fixed and its counts must be auditable. Chronos-2 is the site forecaster: a time series foundation model, about 0.48 GB at FP32 as published, that predicts turn time, block queues and reefer temperature two hours out, with residual thresholds naming the cause. It is Apache-2.0 with no field of use restriction, and it is zero-shot across multivariate and covariate-informed series, so it forecasts against discharge order, appointments and weather with no per-block training set. The runner-up, TTM-R2, was weighed and set aside as univariate only. Qwen3-Embedding-0.6B is the site retrieval model, about 1.2 GB at bf16, embedding gate transactions, appointments, EDI messages and handover records for the planner surfaces. Its 32K window holds a whole shift's gate and appointment record as one passage. It is Apache-2.0, and BGE-M3 was set aside as older with a shorter window for record-level joins. The Roboflow trackers library does the edge tracking: Apache-2.0 clean-room implementations of SORT, ByteTrack and OC-SORT behind one interface, with an eval command to pick the tracker on the operator's own labelled clips. It carries no model memory and runs on CPU beside the detector; BoxMOT was set aside as AGPL.

### 8.2  The Model and Equipment Register

Table 4 gathers every choice in one register: the five models, the hardware classes and sizing rules, the sensing, the patterns the design stands on and the ground it runs on, each with the reason it is here.

Table 4 · Model and Equipment Register

| The choice | What was picked | Why here |
| --- | --- | --- |
| Work surface model | GLM 5.3, 753 billion parameters filed, FP8, on one 8-GPU node of the 141 GB HBM class | Bespoke license permits internal commercial use with attribution and no revenue trigger; one node holds the weights with KV headroom. |
| Edge detector | RF-DETR, Apache-2.0, Nano to 2XL checkpoints from about 61 to 254 MB at 16 bit | Real-time on edge GPUs, fine tunable on the operator's own footage, fixed auditable classes. |
| Site forecaster | Chronos-2, Apache-2.0, about 0.48 GB at FP32 | Zero-shot multivariate forecasting with covariates for the two-hour turn time, queue and reefer predictions. |
| Site embedding model | Qwen3-Embedding-0.6B, Apache-2.0, about 1.2 GB at bf16 | The 32K window holds a whole shift's gate and appointment record in one passage. |
| Edge tracker | Roboflow trackers, Apache-2.0 clean-room SORT, ByteTrack and OC-SORT | Per-object counts and conflict geometry at no model memory cost, on CPU beside the detector. |
| Edge compute class | Fanless IP-rated enclosures with accelerator at the yard blocks, gate and quay | Sized from actual streams and models by bench measurement, never from a datasheet. |
| Site inference server | One GPU node, H100-class 80 GB or L40S-class 48 GB | Holds forecaster and embedding model with room for 32K-window activation memory. |
| Frontier node | One 8-GPU node of the 141 GB HBM class, about 10 kW | 904 GB required against 1,128 GB usable, inside the room's power envelope. |
| Camera estate | Reuse of the 220 existing fixed cameras, decided per camera by six gates | Reuse existing CCTV or not is the first sizing rule; new buys carry no domestic US license restriction. |
| Positioning | RTKLIB with a site-owned GNSS base station | Grounds RTG and truck positions without an external positioning service. |
| Time synchronization | OCP Time Card grandmaster with holdover OCXO, linuxptp and chrony | Keeps camera frames, PLC cycles and gate reads on one clock through power transfer. |
| One-way transfer | Lidi over a hardware data diode | Weights and images move inward; nothing queries back across the boundary. |

PART III · CHAPTER 9

## Shadow Mode Comes Before Any Flag Is Trusted

The first gate proves or redirects the yard-side turn time hypothesis before the build grows, and no prediction or safety flag reaches a planner until it has run in shadow.

Chapter 8 fixed the models, their licenses and the hardware that holds their weights. This chapter sets the order in which those models earn the right to speak to a planner, what the rollout measures along the way, and what happens when a piece of it fails.

### 9.1  Phases, Workstreams and Gates

The build runs in three phases, shown in Figure 8, each closed by an exit gate that can stop the work cheaply. Phase 0, Foundations, carries two items under the operations design workstream: engagement with the ILA local on a data use covenant, and the facility security plan amendment with the camera reuse survey. Its gate is the amended security plan and a completed survey of which of the 220 cameras can carry analytics. Phase 1, the demonstrator, carries seven items across five workstreams: live terminal model, operations design, platform build, safety and yard vision, and turn time prediction. The items include the terminal object model and its ontology projection, read-only integrations against Navis N4 and the existing estate, and the gate-OCR hypothesis proof. Its gate is an accepted terminal object model and ontology projection, with the hypothesis proof settled inside the phase so the build either continues on the yard side or redirects to lanes and appointments. Phase 2, the terminal-wide live model, carries five items across compliance reporting, live terminal model, platform build, turn time prediction and the work surface. The items include two-hour turn time and congestion prediction running in shadow, rail cut risk and reefer trend flagging, and the planner and coordinator agent work surface. Its gate is that work surface, live in shadow, with every prediction and safety flag reviewed against the record before any flag reaches a planner directly. Requirement coverage closes all five requirements with none partial and none open.

![Figure 8. The three phases and their gates, and coverage of the 5 requirements across them.](figures/figure_08.png)

Figure 8. The three phases and their gates, and coverage of the 5 requirements across them.

### 9.2  What the Rollout Measures

The rollout measures turn time against the TOS's own gate-in and gate-out clock, never against a separate stopwatch, so the planner's number and the model's number are the same number. It measures prediction error at the two-hour horizon, the attribution share of variance assigned to yard versus gate, and the precision of safety detections against reviewed camera clips. It also measures reefer out-of-range trend lead, the rail cut miss rate against each railroad's switch list, and idling minutes assembled from crane fuel data for the air permit evidence file.

### 9.3  Failure Modes

Table 5 lists what fails and what the design does about it.

Table 5 · Failure Modes

| What fails | What the design does |
| --- | --- |
| The turn time variance turns out gate side, contradicting the working hypothesis at the first gate | The demonstrator redirects to gate lanes and appointments rather than stopping, and the yard plan consumes the gate data either way |
| The ILA local reads the camera estate as productivity surveillance | Phase-zero engagement with a data use covenant enforced by schema, so no route leads from a safety record to discipline, before any analytic ships |
| Yard inventory in the TOS disagrees with what the cameras and cranes see | Positions are verified independently by camera and crane sensors, and the system degrades to stale reporting rather than trusting the record blindly |
| Security plan amendment lead time delays camera and network installation | The facility security officer joins in the first phase and the amendment sits on the critical path, not in the risk register alone |
| A hurricane shutdown or generator transfer corrupts event ordering or drops edge inference silently | Clean shutdown through the UPS integration, grandmaster clock holdover sized to the transfer window, and a degraded-mode contract of stale reporting, never silence |
| Vision accuracy measured at acceptance drifts through seasons on a dirty, salted, sunstruck yard | The acceptance number is treated as a floor, and an operator-owned in-place adaptation path with on-site labelling ships with the system |

### 9.4  Lessons

**Shadow the flags before anyone trusts them.** Every prediction and safety detection runs against the record before a planner sees it, because a flag that a planner acts on once and then discards is harder to recover than a flag that earns its place quietly. Situation-awareness gap analysis from maritime autonomy work supports treating any unseen conflict as a formal defect, not a nuisance (MDPI 2020). Let a failed hypothesis redirect the build, not stop it. The gate-OCR proof exists to settle the yard-versus-gate question at the cheapest possible point. A gate-side finding changes what the demonstrator optimizes; it does not end it, because the appointment and lane data feeds either answer. Write the labor covenant into the schema. A policy document can be reinterpreted; a schema with no path from a safety record to an individual's discipline record cannot. The Yard Person object holds TWIC status, zone authority and employer, and nothing that measures a person's output. Treat acceptance accuracy as a floor, not a promise. A yard environment of salt, sun and soot degrades any detector. The design ships labelling tooling and retraining on the operator's own footage so the operator holds the adaptation, not a vendor service call.

### 9.5  What Is Still Open

Three questions remain open. Whether approved reassignments should be written back into the TOS is deferred to a later phase gated on ILA local and IT sign-off; settling it would turn the surfaces from advisory to actuating and change the safety review around them. Whether the second railroad can supply switch lists near-real-time over EDI is unanswered; settling it would retire the ramp camera's cut counting and shrink the vision estate. How detector accuracy moves across Gulf summer and winter is unknown; settling it sets the retraining cadence the operator-owned adaptation path must meet.

PART III · CHAPTER 10

## The Intelligence Should Stay with the Terminal That Produced It

The object model, the weights and fine-tunes, the decision record and the data boundary belong to the operator, so the intelligence stays with the terminal that produced it.

Chapter 9 set the gates that let each part of the system earn trust. This chapter states who owns each part once it has, and why the design leaves the intelligence with the terminal that produced it.

### 10.1  What the Operator Owns

The object model belongs to the operator. Its objects are anchored in the operator's own systems of record, and schema changes are made through the work surface's ontology maintenance, so the model grows with the terminal rather than with a vendor's release calendar. The weights and fine-tunes belong to the operator as well: the Apache-2.0 detectors, forecaster, embedding model and trackers may be held, fine-tuned and run without restriction, and the work-surface model's license permits internal commercial use with no revenue trigger. Fine-tuned detector weights, trained on the operator's own footage, sit in the on-site registry with rollback under the operator's own governance rule. The decision record belongs to the operator: every proposed reassignment, the planner's decision and the outcome are kept so the next decision reads the last one, which is how the system compounds judgment instead of replacing it. The boundary belongs to the operator too: the data diode, the amended facility security plan, the ILA data use covenant and the in-country disaster recovery arrangement are all held inside the operator's own plan.

### 10.2  The Offer Behind the Design

CodeNinja designed this system on Praxis, the platform that produced every choice in this paper, and the design maps to its offer end to end. Adaptive Operations is the sensing, detection and forecasting of physical behavior across the quay, yard, gate and rail. Decision Systems is the ranking, attribution and recommendation that a named planner or safety supervisor decides. Hyper Ontology is the twelve-object model that turns eleven sources into one argument. Hyper Pragma is the work surface where planners, vessel planners and rail coordinators build and run their own agents. Sovereign Infrastructure is the operator's own hardware, open-weight licenses and in-country operation inside the security plan. The offer is a terminal that keeps its intelligence the way it keeps its cargo: on its own ground.

PART IV · CONCLUSION

## A Terminal Seen Whole Can Be Run Whole

Terminal Pulse is one live model of the terminal: eleven sources entering through three adapter families, twelve objects with typed links covering the vessel call, container, yard block, both crane classes, truck visit, gate lane, rail cut, reefer plug, yard person, transfer zone and safety event, and seven services that predict turn time two hours out, name the cause and propose the reassignment while the planner acts inside the terminal operating system. Pedestrian and truck conflicts surface at the edge as they happen; forecasting and language reasoning run on the operator's own hardware inside its security boundary.

The shape travels. Any terminal with a system of record for moves, an estate of cameras and machine telemetry, and a planning team that meets twice a shift can run the same pattern, and running it takes the discipline of the design rather than new machines: adapters instead of direct connections, an object model the operator owns, inference placed by reflex time rather than convenience, licenses that permit holding weights on site, and a first gate cheap enough to stop or redirect the work early.

PART IV · CHAPTER 11

## How Praxis Contextualized and Reasoned This Design

Every choice in this design is traceable to what was in the room and to what the eight reasoning lenses returned.

Chapter 10 established that the operator owns the object model, the weights, the decision record and the boundary. This chapter shows how the design was reasoned, so any reader can trace a choice back to what justified it. Every design in the series is produced on Praxis, the design team platform for designing physical AI systems, and Figure 9 lays out this run: the ask, the family and industry assigned, what was in the room, the eight lenses and the patterns each one moved.

### 11.1  Contextualizing the Ask

Praxis read the ask as a live-model problem in the physical operations family, industry Maritime and Ports, scenario class container terminal on a constrained channel waterway. What was in the room, each record read in full and available on request: the operator's statement of requirement; TOS transaction and move records; gate OCR, appointment and RFID records; crane cycle and fault logs from both OEMs; reefer monitoring exports; railroad switch lists and ramp inventories; the safety incident history; the camera estate inventory; references from the master labor contract, the facility security plan and the air permit conditions. The ask fixed the working hypothesis, the yard-side attribution of turn time variance, and the first gate that would prove or redirect it.

![Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.](figures/figure_09.png)

Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.

### 11.2  The Lenses

Table 6 records what each of the eight lenses could see, how many sources it cited and what it contributed. No lens returned empty.

Table 6 · The Lenses and What They Contributed

| Lens | Could see | Cited | What it contributed |
| --- | --- | --- | --- |
| First principles | Why the model must sit beside the systems of record, never in front of them | 3 | Fixed the core decisions: read-only beside the TOS, no safety reflex across a network hop, measurement on the TOS's own clock |
| Case studies | How comparable terminals handled appointments, inventory truth and incident causation | 4 | Set the appointment-consumption lesson, independent position verification and the degradation contract, drawing on (Service 2021), (Maritimecyprus 2024), (MDPI 2020) and (Allaboutshipping 2024) |
| Tooling and recency | Which streaming, serving, tracking and registry products are current and correctly licensed | 14 | Pinned the event backbone, the ontology store, video ingest, the tracking library and the registries, and left the time-series store, edge runtime and cluster as classes to settle at bench |
| Hardware and equipment | What compute, cameras, timing and networking the yard environment permits | 10 | Sized edge boxes by class from stream counts, placed the site node and the single 8-GPU node, and added the timing card, data diode and private wireless path |
| Rules and regulations | What security, safety, customs and air rules demand of the design | 4 | Forced the security plan amendment onto the critical path, the idling evidence feed and the person-object anchoring, with VTS guidance informing the weather join (Service n.d.) |
| Approach | Whether a hypothesis-first gate or a full build comes first | 2 | Made the gate-OCR proof the first gate, with a redirect path instead of a stop |
| History | How planning knowledge has lived in heads, paper and weekly reports | 2 | Explained the meeting rhythm the surfaces must serve, and the after-the-fact rail reporting the design replaces, against the backdrop of sea-carried trade (Defesa n.d.) |
| Domain fusion | Where adjacent domains already formalize awareness gaps | 2 | Imported situation-awareness gap analysis from maritime autonomy as the acceptance frame for safety detections (MDPI 2020) |

### 11.3  Patterns Adopted and Set Aside

The lenses adopted four patterns: sit beside the systems of record rather than in front of them; keep telemetry and video at the edge and reasoning in-country; degrade to stale reporting rather than silent failure; and make labelling and adaptation operator-owned work on the operator's own footage. They set aside four: open-vocabulary detectors, because the terminal's classes are fixed and its counts must be auditable; a univariate-only forecaster, because turn time prediction needs vessel, appointment and weather covariates; copyleft-licensed tracking libraries, because the license terms would constrain how the operator holds its own estate; and a vendor-operated labelling service, because adaptation the operator does not own is adaptation that stops the first time a contract lapses.

### 11.4  Where the Reasoning Lands

The reasoning lands on equipment classes, not part numbers chosen in advance. Edge compute is sized from actual stream counts and actual models at bench, in fanless IP-rated enclosures at the yard blocks, gate and rail ramp. Site reasoning runs on one inference-server class node for the forecaster and embeddings, and the work surface on a single 8-GPU node of the 141 GB memory class, sized by the footprint arithmetic in Chapter 8. Timing comes from a GNSS grandmaster with holdover, crossing to the analytics side over a hardware data diode, with private wireless as the path to the ramp. Everything shown in this paper was recorded reading: systems named by the operator, counts taken from its estate, licenses read from their terms. Nothing is inferred.

Appendix A

## What Ownership Costs Over Three Years

*Version 2, 5 October 2026. Version 1 compared ownership with AWS's three-year EC2 Instance Savings Plan at the no upfront rates (27.34 and 13.02 dollars an hour) and printed "about two thirds"; the deepest three-year plan in the region, all upfront at 23.80 and 11.33, makes it about four fifths. Every other number is unchanged.*

The design runs on the operator's own hardware. This appendix prices that choice against the two ways an operator in the United States could otherwise get the same capability: renting the same accelerators from a cloud region, or buying a closed frontier model by the token. Every input is a public price, dated and cited. The arithmetic is shown so any reader can rerun it with a written quote. The operator in this design is an illustrative scenario, so the user count and the edge allowance below are assumptions, stated where they are used.

### A.1 The Answer

Owning the stack this design specifies costs about **722,000 US dollars over three years**, inside a range of 629,000 to 821,000. Renting the same capacity around the clock costs **0.99 million to 2.52 million dollars** over the same period. Against the cheapest three-year commitment listed (AWS, three-year EC2 Instance Savings Plan, all upfront), ownership is **about four fifths** the cost. Every rented option here can stay inside the United States, so for a US operator the case for ownership is cost, control and a site that keeps working when the link drops, not residency.

### A.2 What Owning Costs

| Line | Basis | Three-year cost (USD) |
| --- | --- | --- |
| Frontier tier | One server of eight 141 GB HBM-class cards, 320,000 to 420,000 dollars, typical 370,000 (Mercatus 2026) | 320,000 to 420,000 |
| Site tier | One GPU server, priced at the upper bound of eight 48 GB L40S-class cards although the paper's forecaster and embedder fit on one card, 85,271 dollars (Newegg 2026) | 85,000 |
| Edge | An allowance of 16 fanless IP-rated edge nodes, one at each of the 14 yard blocks, one at the gate and one at the quay at 4,000 dollars each (Eurotech 2026) | 64,000 |
| Support | 8 to 12 percent of hardware value a year (Introl 2026) | 113,000 to 205,000 |
| Power | 11.5 kW average IT load at a power usage effectiveness of 1.6 (Uptime Institute 2025), 481,870 kWh at the US industrial average of 9.77 cents per kWh in July 2026 (EIA 2026) | 47,000 |
| **Total** |  | **629,000 to 821,000, typical 722,000** |

The average load assumes the frontier server draws 7 kW of its 10.2 kW maximum (NVIDIA 2026), the site server 3.5 kW and each edge node 60 W. The frontier tier fits one node because GLM 5.3 is 753 GB at FP8 and needs 904 GB with headroom, against 1,128 GB on eight 141 GB cards.

### A.3 What Renting Costs

The same frontier server and site server, rented without a break for three years, because a terminal works three shifts and turn time is predicted around the clock. The edge nodes stay on site in every option and are included in each total.

| Option | Basis | Three-year cost (USD) |
| --- | --- | --- |
| AWS, us-east-1, on demand | p5en.48xlarge at 63.296 dollars an hour, g6e.48xlarge at 30.13 (Vantage 2026) | 2.52 million |
| AWS, three-year EC2 Instance Savings Plan, all upfront | the deepest three-year plan in us-east-1: 23.80 dollars an hour for p5en.48xlarge, 11.33 for g6e.48xlarge (AWS 2026) | 0.99 million |
| Azure, three-year reservation | ND96isr H200 v5 at 1,109,592 dollars for three years in East US 2, about 42.22 an hour (Azure 2026); site tier as AWS | 1.52 million |
| Specialist GPU cloud, on demand | 50.44 dollars an hour for eight H200 cards, 18.00 for eight L40S (CoreWeave 2026) | 1.86 million |
| Oracle, three-year commitment | 40 dollars an hour for eight H200 cards (Economize 2026); site tier as AWS | 1.46 million |

Egress, storage and support plans are excluded, so every rented figure is a floor. Spot capacity is excluded because a service that must run through a storm or a shift cannot be evicted.

### A.4 What Closed Models Cost by the Token

A closed frontier model replaces the frontier tier rather than the whole stack, and it is priced by use. At 40 users (an assumed count across the eight roles the paper names, over three shifts), each running the equivalent of five agents at 2.4 billion tokens a year, with four input tokens to every output token and half the input served from cache, three years is 288 billion tokens.

| Model | List price per million tokens, input and output | Three-year cost (USD) |
| --- | --- | --- |
| Claude Sonnet 5.5 | 2 and 10 (Anthropic 2026) | 0.83 million |
| Gemini 3.1 Pro | 2 and 12 (Google 2026) | 0.94 million |
| Claude Opus 5.5 | 4 and 20 (Anthropic 2026) | 1.66 million |
| GPT-5.5 | 5 and 30 (OpenAI 2026) | 2.36 million |

The cheapest closed model costs about 21,000 dollars per user over three years, so it matches the whole owned stack at about **35 users**. Below that, renting a closed model by the token is cheaper; above it, ownership is, and the gap widens linearly with users while the owned cost stays flat. Every closed option also sends terminal transactions and camera footage of longshore labour to a third-party AI service outside the boundary, which the design's constraints rule out.

### A.5 What the Price Does Not Include

- **Cameras and installation**; the design reuses the existing camera estate.
- **The site tier is priced high on purpose.** The paper allows one H100-class or L40S-class node, and its two site models fit on one card, so a written quote will come in lower.
- **Sales tax, freight and installation** on the hardware, which a written quote settles.
- **An export licence** does not apply: the hardware stays inside the United States.
- **People, facilities and implementation**, which both sides carry.
- **Price movement.** Cloud prices rose as well as fell in 2026; AWS raised its H200 capacity block price about 15 percent in January (Gigazine 2026).

### A.6 Sources for This Appendix

- AWS. 2026. Compute and EC2 Instance Savings Plans price file, us-east-1, 3 October 2026. <https://pricing.us-east-1.amazonaws.com/savingsPlan/v1.0/aws/AWSComputeSavingsPlan/current/region_index.json>
- Anthropic. 2026. Pricing. <https://claude.com/pricing>
- Azure. 2026. Retail prices, Standard\_ND96isr\_H200\_v5. <https://prices.azure.com/api/retail/prices>
- CoreWeave. 2026. Pricing. <https://www.coreweave.com/pricing>
- EIA. 2026. Electric Power Monthly, Table 5.6.A, July 2026. <https://www.eia.gov/electricity/monthly/epm_table_grapher.php?t=epmt_5_6_a>
- Economize. 2026. OCI BM.GPU.H200.8 pricing. <https://www.economize.cloud>
- Eurotech. 2026. ReliaCOR 33-11. <https://buy.eurotech.com/products/reliacor-33-11>
- Gigazine. 2026. AWS raises EC2 Capacity Blocks prices. <https://gigazine.net>
- Google. 2026. Gemini API pricing. <https://ai.google.dev/gemini-api/docs/pricing>
- Introl. 2026. GPU infrastructure TCO model. <https://introl.com/blog/gpu-infrastructure-tco-model-5-year-enterprise-ai-deployment>
- Mercatus. 2026. H200 server price. <https://mercatus-ai.com/blog/h200-server-price>
- NVIDIA. 2026. DGX H200. <https://www.nvidia.com/en-us/data-center/dgx-h200/>
- Newegg. 2026. Supermicro SYS-421GE-TNRT-02-G1. <https://www.newegg.com/p/N82E16859152404>
- OpenAI. 2026. API pricing. <https://developers.openai.com/api/docs/pricing>
- Uptime Institute. 2025. Global Data Center Survey 2025. <https://uptimeinstitute.com>
- Vantage. 2026. EC2 instance prices. <https://instances.vantage.sh>

SOURCES

## Source Register

Defesa. n.d.. Maritime Situational Awareness , the Portuguese Navy dual-use approach. <https://www.defesa.gov.pt/pt/pdefesa/ac/pub/acpubs/Documents/Atlantic-Centre_PB_06.pdf>

Service. 2021. MAIBInvReport 18/2024 , Mona Manx , Very Serious Marine Casualty. <https://assets.publishing.service.gov.uk/media/673c705af2eda558e9494e7c/2024-18-MonaManx.pdf>

Maritimecyprus. 2024. Collision Between Bulk Carrier Yangze 7 and Towing Vessel Miss Peggy. <https://maritimecyprus.com/wp-content/uploads/2026/09/NTSB-MIR2624-2026_08_c.pdf>

Service. n.d.. MGN 401 (M+F) , Navigation: Vessel Traffic Services (VTS) and Local Port Services (LPS) in the United Kingdom , as amended. <https://assets.publishing.service.gov.uk/media/5fbe14e9e90e077ee6d17a33/MGN401_R02.pdf>

MDPI. 2020. Regulatory Requirements on the Competence of Remote Operator in Maritime Autonomous Surface Ship: Situation Awareness, Ship Sense and Goal-Based Gap Analysis. <https://www.mdpi.com/2076-3417/10/23/8751>

Allaboutshipping. 2024. Ship Operator Fined $6 Million for Non-Report in 2024 Charleston Runaway Ship Incident , All About Shipping. <https://allaboutshipping.co.uk/2026/08/18/ship-operator-fined-6-million-for-non-report-in-2024-charleston-runaway-ship-incident/>

---

### About CodeNinja

CodeNinja is a Middle Eastern-American artificial intelligence lab focused on building self-improving systems. We are reinventing knowledge work to close the loop between vertical AI use cases and the generalized intelligence that fuels it, accelerating the path toward organizational superintelligence.


---

# Baseline: One Flight of 4 Band Orthoimagery and LiDAR for Vegetation Mapping

Canonical: https://codeatoms.ai/vegetation-mapping-lidar-us/
DOI: https://doi.org/10.5281/zenodo.23186673
PDF: https://codeatoms.ai/vegetation-mapping-lidar-us/paper/baseline-orthoimagery-lidar-vegetation-mapping-us.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

VERTICAL-DRIVEN ARCHITECTURES · AGRICULTURE & EARTH OBSERVATION · DESIGNED WITH PRAXIS · OCTOBER 2026

# Baseline: One Flight of 4 Band Orthoimagery and LiDAR for Vegetation Mapping

A one-flight acquisition of 3-inch 4 band orthoimagery and USGS QL1 LiDAR over the site of an agriculture and earth observation operator in United States, bound into a living ontology the operator's staff analyze in the GIS tools they already run.

CodeNinja Engineering Team

For the operator's project manager, its GIS and stewardship leads, and the data, geospatial and platform engineers who would build and run it.

---

Vertical-Driven Architectures is a CodeNinja series of system designs. Every design in the series is driven by a real-world problem and scenario in a single industry, and every one is designed on Praxis, CodeNinja's platform for designing physical AI systems. Operations are described by class, never by name.

At a glance

## One flight of imagery and LiDAR for vegetation mapping in the United States

**What this is.** An open reference architecture for system design in physical AI: one summer flight of 3-inch 4-band orthoimagery and USGS Quality Level 1 LiDAR, with every tile, point cloud and elevation model bound into a site ontology, so the next season starts from a comparison instead of rediscovery. It is written for the operator's project manager, its GIS and stewardship leads, and the geospatial and data engineers who would build it. The operator is described by class, never by name.

**The answer in numbers.**

| Part | The design |
| --- | --- |
| Acquisition | One manned flight within a week either side of 1 July; 3-inch 4-band (red, green, blue, near infrared) orthoimagery and Quality Level 1 LiDAR at a minimum of 8 pulses per square meter |
| Sources joined | 4 named sources through 2 adapter families |
| Object model | 16 typed objects, with the flight mission as the focal object, published as JSON for reuse |
| Models | None: vegetation analysis stays with the operator's own analysts |
| Ground | The operator's ArcGIS Enterprise; nothing runs in a cloud the operator does not control |
| Three-year cost | No compute to price; the acquisition is priced by the survey firm against the operator's own task table (Appendix A) |
| Human control | The operator's project manager accepts each deliverable against the QA/QC accuracy report |

**Reuse it.** The object model, the model register and the figures are free to reuse under CC BY 4.0. Cite as DOI <https://doi.org/10.5281/zenodo.23186673.>

**Made with.** Reasoned on [Praxis](<https://codeatoms.ai/praxis/>), CodeNinja's platform for designing physical AI systems. The object model imports into [Hyper Ontology](<https://codeatoms.ai/hyper-ontology/>), which turns it into a living system. Both are in beta; access by request.

ABSTRACT

## A Flight Should Leave Behind More Than Files

The question this operation needs answered is what vegetation and terrain conditions exist across its site during the narrow summer window around 1 July, and whether every acre inside the mapping boundary was flown, processed, verified and accepted to specification. Today it cannot answer that from its own records: past aerial deliveries arrive as tile archives, point clouds and invoices that no staff member can join to units, flight missions, sensor systems or seasons, so each flight season starts with rediscovery instead of comparison, and the record of what was flown, on which day, with which sensor and at what accuracy lives in scattered documents rather than in one queryable model.

The design is a one-year, one-flight acquisition of 3-inch 4-band orthoimagery and USGS QL1 LiDAR inside the July 2025 window, handed over as publish-ready files under the agreement's terms, with every deliverable bound into a living 16-object site ontology the operator owns outright. Four named sources enter through 2 adapter families into the object model, 5 services carry the work from boundary confirmation to handover, and 1 operating surface gives staff the joined view; 0 models are served because vegetation analysis stays with the operator's own analysts. The acquisition runs on a manned aircraft flown by the survey firm, processing runs in the survey firm's own pipeline, the object model is anchored in the operator's ArcGIS Enterprise, and nothing runs in a cloud the operator does not control.

The paper proceeds in order: the industry problem and the fixed flight window; the join failure across past deliverables; the four constraints and the scoping decisions; the stack from aircraft to archive; the 16-object model and where the human loop sits; ingestion through the 2 adapter families; inference placement, which is deliberately empty of compute; models and licenses, where the register holds zero models by choice; the 4-phase rollout with its gates and 31-requirement coverage; ownership of the record; and the Praxis chapter that traces every choice back to what justified it.

---

![Figure 1. Baseline on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.](figures/figure_01.png)

Figure 1. Baseline on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.

## Contents

Each chapter is tagged for the reader it serves most directly: Executive, Team Lead, FDE, Reference.

|  |  |  |
| --- | --- | --- |
|  | Abstract · A Flight Should Leave Behind More Than Files | Executive |
| PART I · THE PROBLEM | | |
| 1 | [One Week in July Decides a Year of Vegetation Mapping](#ch1) | Executive |
| 2 | [Every Deliverable Arrives as Files No Record Joins](#ch2) | ExecutiveTeam Lead |
| PART II · THE DESIGN | | |
| 3 | [Four Constraints Shape the Acquisition and Its Record](#ch3) | Team Lead |
| 4 | [One Stack Runs From Aircraft to the Operator's Archive](#ch4) | Team LeadFDE |
| 5 | [Sixteen Objects Turn One Flight Into an Argument](#ch5) | FDE |
| 6 | [Every Source Enters Through an Adapter, Never Directly](#ch6) | FDE |
| 7 | [No Inference Runs, and That Is the Design](#ch7) | FDE |
| 8 | [Zero Models Means the License Question Disappears](#ch8) | FDEExecutive |
| PART III · THE ROLLOUT | | |
| 9 | [Readiness Gates Come Before the Flight Window Opens](#ch9) | Team LeadExecutive |
| 10 | [The Operator Owns the Record, Not Just the Files](#ch10) | Executive |
| PART IV · HOW IT WAS DESIGNED | | |
|  | Conclusion · A Flight Becomes Knowledge When the Record Survives | Executive |
| 11 | [How Praxis Contextualized and Reasoned This Design](#ch11) | Team LeadFDE |
|  | [Sources](#sources) | Reference |

PART I · CHAPTER 1

## One Week in July Decides a Year of Vegetation Mapping

The operation needs a seasonal 4 band orthoimagery and LiDAR baseline over its site, and a flight window of one week either side of 1 July means preparation, not the flight itself, decides whether the year's mapping succeeds.

The abstract framed this design as one seasonal flight bound into a record the operator owns outright. This chapter states the problem behind that design: the question the operation needs answered each year, the documented cost of answering it badly in this industry, and the scenario as it actually runs.

### 1.1  The Question, the Data and the Regulatory Ground

The question the operation needs answered is direct: what is the vegetation and land-cover state of the site this season, at a resolution fine enough to support stewardship decisions, with accuracy evidence strong enough to defend every figure derived from it. Answering it requires four kinds of data captured in a single coordinated effort. The first is orthoimagery, aerial imagery geometrically corrected so that every pixel sits at its true map position, acquired as 3-inch 4-band imagery, meaning each ground point is imaged in red, green, blue and near-infrared at a ground sample distance of 3 inches, the size of the ground each pixel covers. The second is a LiDAR point cloud at quality level 1, the top accuracy tier of the United States Geological Survey's classification ladder, in which laser returns from an aircraft are classified into ground and non-ground points. The third is the derived surface pair: a bare-earth digital elevation model and a highest-hit digital elevation model, rasters that describe the ground surface and the top of the canopy respectively. The fourth is a QA/QC accuracy report recording the checkpoints used, the root mean square error by axis, and the error matrix that separates the accuracy of the mapmaker from the accuracy a user of the map can expect. The regulatory ground is layered. The operator is a special district formed by the Legislature in 1933 to manage groundwater, so public-agency procurement rules govern how the work is awarded, and the United States Geological Survey's quality level 1 specification sets the accuracy bar the point cloud must meet. State prevailing wage law may apply to the flight and processing crew depending on classification, equal employment opportunity requirements apply to the awarded agreement, the agreement carries an insurance schedule with named endorsements, and records must be retained for three years. National aviation rules govern the manned survey flight itself, and because the requirement excludes unmanned aircraft, the rules that apply are those for manned survey aviation rather than the small-drone rule most imagery buyers know.

### 1.2  What the Industry Documents About Acting Without Good Evidence

The cost of the problem is documented at the industry level, and it is a cost of deciding without systematic evidence. Researchers who study agricultural injuries argue that hazards in production agriculture are hard to address without systematic surveillance, because the people accountable need ongoing data on workplace risks before they can improve anything (ResearchGate n.d.). The same industry carries a heavy documented burden when that evidence is absent: farm accidents and deaths were found to cost the agricultural sector more than one billion dollars per year (ABC 2010). Agriculture ranks among the most hazardous industries in the world, and figures from Great Britain showed a spike in fatalities in the industry in 2021 (IOSH Magazine 2021). In the United States, the National Ag Safety Database puts the toll at between 60 and 70 farmers killed per 100,000 every year (Watch Us Grow n.d.), and federal investigation reports record individual cases in detail, including one farmer who died in 2001 from injuries sustained when thrown from the tractor she was operating (CDC 2001). The lesson this design takes from that record is about evidence discipline: decisions on agricultural land are only as good as the systematic, dated, georeferenced observation behind them, and a seasonal observation missed is a season of decisions made from stale evidence. The flight window in this scenario is therefore not a scheduling detail; it is the year's only chance to capture the baseline.

### 1.3  The Operation as a Scenario

The operation runs a small estate of systems against a large physical responsibility. Its named systems number two: a GIS boundary shapefile holding the mapping boundary geometry and its 50-meter buffer, which defines the acquisition extent and every area figure, and ArcGIS Enterprise, the serving environment into which the operator's own staff publish and analyze imagery. The scale is banded simply: one site, one flight, one window of one week either side of 1 July 2025, and one seasonal baseline. No area figure is asserted in this paper because every area figure derives from the confirmed boundary, and storage, transfer and processing effort are all sized from that boundary before mobilization. The people in the loop number three named roles: the district project manager, who holds the direct reporting line and approval authority over personnel changes; the contractor project manager, who reports to that line and carries team assignments; and the operator's GIS staff, who publish the files into ArcGIS Enterprise and analyze vegetation in the tools they already use. The physical environments are varied and demanding: recharge basins and wetted areas, open land cover, and vegetation along the, where dense canopy forms the hardest LiDAR environment on site. The regulatory ground is the one described in section 1.1. The count that closes the scenario: the design binds two named systems, two adapter families, sixteen objects, five services, one surface and zero models into a single record, against thirty-one tracked requirements in the baseline.

PART I · CHAPTER 2

## Every Deliverable Arrives as Files No Record Joins

Past acquisitions produce tiles, accuracy reports and invoices that sit side by side without joining to units, flight missions, sensor systems or seasons, and that separation is where area figures, coverage claims and accuracy evidence get lost.

Chapter 1 showed a scenario in which one flight decides a year of vegetation mapping. This chapter shows why the records left behind by past acquisitions cannot answer the questions the next season asks, system by system, and what that separation costs in practice.

### 2.1  What Each System Sees Alone

Each system the operator holds sees one slice of the acquisition. ArcGIS Enterprise sees the published layer: the map service its own staff clicked into existence, with its projection, its symbology and its attribute table. It does not see which flight mission captured the source frames, which camera and calibration produced them, or under what sun angle and weather the frames were taken, so two layers from different seasons look like siblings when they are not. The GIS boundary shapefile sees the extent: the mapping boundary geometry, its 50-meter buffer and the acreage that follows from them. It does not see whether any particular tile set actually conforms to that extent, so coverage claims are asserted rather than reconciled. The file archives from past acquisitions, folders of ortho tiles and point clouds on flash drives, see the pixels and the points themselves. They do not see the conditions of capture, the flight lines flown or the sensor settings, so a suspicious tile cannot be traced back to the mission that produced it. The accuracy reports see the evidence: checkpoints, root mean square error by axis, error matrices and standard errors. They do not see the tiles they certify as named, versioned objects, so accuracy evidence floats free of the imagery it describes. The contract and invoice records see the money: the task fee table, hours by person and rate, percent complete per task. They do not see any technical conformance, so a payment can be fully documented and the underlying product still unverifiable. Figure 2 sets these slices side by side.

![Figure 2. Five systems, each seeing one part of the answer. the question needs all of them in one place at once.](figures/figure_02.png)

Figure 2. Five systems, each seeing one part of the answer. the question needs all of them in one place at once.

### 2.2  What None of Them See Together

What none of them see is the join: the chain that runs from a unit of land, through the flight mission and the sensor systems that observed it, to the imagery and point cloud products, to the accuracy report that certifies them, to the agreement and the invoices that paid for them. That chain is where area figures, coverage claims and accuracy evidence live or die. When the boundary register and the imagery are not joined, an area figure can be questioned and there is no single place to reconcile it. When coverage is not reconciled to geometry, a gap in the tiles is discovered by whoever analyzes the layer, months after the window to refly has closed. When accuracy evidence is orphaned from the products it certifies, a challenge to a figure means reconstructing the certification by hand from documents. And when a fourteen-day termination right can end the agreement, records scattered across these slices leave the operator holding fragments rather than a model. The cost in practice is that every one of these questions is answerable in principle from data the operator already holds, and answerable in practice only through manual effort that starts over each season. Figure 2 summarizes the gap each system carries.

PART II · CHAPTER 3

## Four Constraints Shape the Acquisition and Its Record

The fixed flight window, the excluded UAV path, publish-ready-files-only delivery and the one-year term each close a door, and the scoping decisions in this chapter state what each closed door buys and what it costs.

Chapter 2 showed that the join, not any single system, is what past acquisitions never produced. The design answers that with a record built around the acquisition, and the shape of that record is fixed by four constraints that each close a door.

### 3.1  Hold the Fixed Seasonal Window

The imagery must be flown within one week either side of 1 July 2025. This is hard in this industry because the window exists for a biological reason: the baseline must catch vegetation at the same phenological point each season, so a flight two weeks late compares against nothing. The failure mode is concrete, since coastal stratus or cloud can close the entire week, and a missed window is a missed season. The design therefore treats window readiness as a work product in its own right: multiple ready days are planned across the window, cloud-free-day forecasting is part of acquisition planning, and the district project manager is notified the moment a ready day opens.

### 3.2  Fix the Acquisition Class Before the Aircraft Flies

The requirement states that data from unmanned aircraft will not be considered, so the acquisition class is fixed: a manned aircraft carrying a 4-band large-format camera and a quality level 1 LiDAR sensor. This is hard because quality level 1 vertical accuracy is not decided by the sensor alone but by the whole positioning chain: the aircraft's GNSS/IMU georeferencing, meaning satellite positioning fused with inertial measurement, plus the correction source, either network corrections or an owned base station. The design specifies that chain as a class, with baselines, correction source and test evidence to standard procedures, rather than by part number, because no shelf entry covers aerial survey cameras or LiDAR sensors and the survey firm's turnkey rates already price the equipment.

### 3.3  Keep Publication with the Operator

The survey firm hands over publish-ready files and loads nothing into the operator's environment. This is hard because publish-ready is a conformance claim, not a courtesy: the tile scheme, 3-inch ground sample distance, band set and projection must match the operator's ArcGIS Enterprise exactly, and format translation to those shapes is committed as a class built on open GDAL utilities, the open-source geospatial format library. The design buys with this constraint a clean boundary: the operator's system of record is never touched by an outsider, and provenance metadata binds every file to the mission, sensor and processing steps behind it.

### 3.4  Make Every Phase Boundary an Exit Point

The agreement runs a minimum one-year term, and the operator holds a fourteen-day termination right. This is hard because a terminated acquisition normally strands the buyer with partial files and no way to say what they are. The design makes every phase boundary an exit point: each of the four phases leaves the operator holding complete, labeled records, and the export of the living ontology is rehearsed in the final phase so the model survives any exit. Sixteen objects, from the site and its units through flight missions, sensor systems and products to the agreement and invoices, carry the record.

### 3.5  Scoping Decisions and Their Prices

Three scoping decisions turn these constraints into a buildable plan, each with a price. Table 1 states them.

Table 1 · Scoping Decisions

| Decision | What it buys | What it costs |
| --- | --- | --- |
| Hand over publish-ready files only, with publication owned by the operator's GIS staff | The operator's system of record is never loaded by an outsider and its staff own every layer they serve | No automated publication, so format, projection and tile-scheme conformance must be proven before handover |
| Baseline the LiDAR at the quality level 1 minimum of 8 pulses per square meter, with the higher-density task priced separately | A baseline whose price the operator's own task table fixes, with the denser option exercisable later at the operator's option | Fewer returns in dense canopy, the hardest environment on site, so classification QA must gate on canopy and margin checkpoints |
| Build sixteen objects and no models: the ontology is the only living layer | Zero inference operations, no weights to license and no serving hardware to run | Analysis stays with the operator's staff in the tools they already use rather than moving into agents |

### 3.6  What the Design Chose Against

Each choice against a named alternative states where the design could have gone otherwise and why it did not. Table 2 records them, closing with what sits outside scope.

Table 2 · What the Design Chose Against

| Where | What was picked | Instead of, and why |
| --- | --- | --- |
| Acquisition platform | Manned aircraft with 4-band camera and quality level 1 LiDAR | Instead of a UAV or drone fleet: the requirement states UAV and drone data will not be considered, so the class is fixed by the operator's own terms |
| Data handover | Publish-ready files with provenance metadata | Instead of loading directly into the operator's ArcGIS Enterprise: publication stays with the operator's own GIS staff, keeping the boundary of section 3.3 |
| LiDAR task | Task 3a quality level 1 at a minimum of 8 pulses per square meter | Instead of the Task 3b high pulse count at 16 pulses per square meter: the operator's own task table prices both, so the baseline is 3a and 3b remains the operator's option |
| Record scope | A system of context over the operator's own records, as the sole primary pattern | Instead of agentic layers or a work surface where staff build agents: no agent or model layer was wanted for this acquisition, so every serving layer that would carry one reads not needed |
| Out of scope | The 2025 seasonal baseline and its record | Repeated flights beyond the baseline, downstream vegetation analysis by the operator's staff, and the requirement's proposal-submittal mechanics, which govern the award process rather than the system |

PART II · CHAPTER 4

## One Stack Runs From Aircraft to the Operator's Archive

The architectural pattern places systems of record below, a 16-object model in the middle, and 5 services with 1 operating surface above, with no streaming, no serving and no running system to monitor because the engagement is batch by nature.

Chapter 3 fixed the constraints: a single flight inside a fixed summer window, publish-ready files rather than a loaded environment, an ontology the operator owns outright, and no cloud layer of any kind. This chapter places those constraints into a stack that runs from the aircraft to the operator's own archive.

### 4.1  Records Below, One Model in the Middle, People Above

The design follows a system of context pattern in three layers of fixed order. Systems of record sit below and are never replaced, never modified and never loaded into a shadow copy: ArcGIS Enterprise and the operator's own file holdings remain the truth, and the survey firm's processing pipeline stays outside the boundary. The object model sits in the middle as a projection over those records, so crossing mappings answer questions that no single file can. Applications and people sit above, and the top of the stack is deliberately thin: this is a batch acquisition with a fixed seasonal window, so there is no streaming workload, no serving runtime and no running system to monitor. Figure 3 shows the layered stack with the counts per layer: 4 sources, 2 adapter families, 16 objects, 5 services, 1 operating surface and 0 models. The pattern fits for three reasons. A one-flight acquisition produces files and records whose value is provenance, and a projection over records carries that provenance without owning the bytes. The operator's own staff analyze vegetation in the tools they already use, so no serving layer is needed between the files and the analysis. And a projection can be rebuilt: if the fourteen-day termination right ends the engagement at any phase boundary, the operator still holds complete, labeled records and the model can be re-derived from them.

![Figure 3. The layered stack: 4 sources, 2 adapter families, 16 objects, 5 services and 1 surfaces.](figures/figure_03.png)

Figure 3. The layered stack: 4 sources, 2 adapter families, 16 objects, 5 services and 1 surfaces.

### 4.2  The Stack Stage by Stage

Table 3 walks the stack from sources to surfaces and names the components that fill each stage. The Inference stage looks empty, and the emptiness is the scoping decision from Chapter 3: no learned model serves anywhere in this design, so vegetation classification stays with the operator's analysts rather than with a model.

Table 3 · The Stack, Stage by Stage

| Stage | What it is responsible for | How |
| --- | --- | --- |
| Sources | Holds the four inputs the design reads: the operator's GIS boundary shapefile, ArcGIS Enterprise, the survey firm's acquisition records and the deliverable file set | Read in place; nothing is modified and nothing is loaded into a new store |
| Sensing | The manned aircraft with its 4-band R/G/B/NIR camera, QL1 LiDAR sensor and GNSS/IMU georeferencing chain | Owned and flown by the survey firm; the design specifies the equipment class, not a part number |
| Adapters | The file & doc adapter and the integration adapter; every byte enters through one of these two families | Provenance stamping, conformance checks against the confirmed boundary, and checksum verification at transfer |
| Object model | The 16-object site ontology anchored in ArcGIS Enterprise | Nouns become objects, facts become properties, relationships become typed links; versioned and operator owned |
| Inference | Nothing in this design | No learned model serves anywhere; classification and analysis stay with the operator's people in their own tools |
| Services | Flight Acquisition, Context Layer, Program & Compliance, Data Processing & QA, Delivery & Handover | Five named services coordinate the phases from mobilization to retention |
| Surfaces | One operating surface where the operator's people work | Publish-ready files and the ontology, read through the tools the operator already runs |

PART II · CHAPTER 5

## Sixteen Objects Turn One Flight Into an Argument

The object model carries the site, units, assets, flight missions, sensor systems, products and records as typed, versioned objects anchored in ArcGIS Enterprise, so an analyst can from a vegetation class to the mission that captured it.

Chapter 4 put a 16-object model in the middle of the stack. This chapter names all sixteen objects, wires them together with typed links, and fixes where the human loop, the hosting boundary and the only write path sit.

### 5.1  Sixteen Objects and Their Typed Links

The sixteen objects group into four families. The place objects describe the ground: the site carries the mapping boundary geometry, its 50-meter buffer, the area in acres and the acquisition purpose, and walks a status vocabulary from acquisition pending to accepted; the unit carries each unit's boundary, class, area and stewardship owner; the watercourse carries its alignment, bank vegetation class and identifier; and dam carries the structure footprint, the operating agency and the reservoir pool extent. The acquisition family records how the data was captured: flight-mission holds the acquisition date, flight window compliance, sun angle, weather conditions and flight lines flown, with statuses planned, flown, reflown and aborted; 4-band-aerial-camera-system and ql1-lidar-sensor-system hold band set, ground sample distance or pulse density setting, scan angle and calibration dates; and gnss-imu-georeferencing-chain holds base station placement, correction source and test evidence. The product family holds what the flight produced: multispectral-orthoimagery-product with tile scheme, 3-inch ground sample distance, bands and projection; classified-las-point-cloud with LAS 1.4 version, achieved pulse density, classification schema and vertical accuracy; bare-earth-and-highest-hit-dems with raster type, cell size and source mission; and qa-qc-accuracy-report with checkpoints, RMSE by axis, error matrix and standard errors. The governance family holds the engagement itself: professional-services-agreement, monthly-itemized-invoice, contractor-project-manager and the operator's project manager. Figure 4 shows every object and its typed links. The is the point: an analyst can start at a bank vegetation class, walk to the unit that contains it, to the flight mission that captured the imagery over it, to the sensors and georeferencing chain that positioned it, to the accuracy report that attests to it, and to the invoice line that paid for it. A document store can hold all of these as files; it cannot answer any question that crosses between them, because nothing in it links a tile to a mission, a sensor and a payment in one traversal.

![Figure 4. The sixteen objects of the model and the typed links that let a query reach across them.](figures/figure_04.png)

Figure 4. The sixteen objects of the model and the typed links that let a query reach across them.

### 5.2  The Human Loop and the Hosting Posture

The human loop sits at two places: the contractor project manager reports through a direct line to the operator's project manager, who holds approval authority over personnel changes and signs each phase gate. Hosting follows the operator's own requirement: the model is anchored in ArcGIS Enterprise, the files stay inside the United States, and the publish-ready products fall under the operator's existing access controls and confidentiality obligations. There are no external links out of the model. The only write path is the Context Layer service binding records into the ontology at handover; no other service, and no contractor process, writes to it.

### 5.3  One Object in Its Recorded Form

The site object below shows the grammar in a single record: geometry, buffer and area as properties, purpose as context, and a status vocabulary that walks from acquisition pending to accepted.

```
{
  "id": "the-site",
  "label": "The site",
  "kind": "site",
  "anchored_in": "ArcGIS Enterprise",
  "properties": [
    "Mapping boundary geometry",
    "50-meter buffer",
    "Area in acres",
    "purpose"
  ],
  "status_vocabulary": [
    "Acquisition pending",
    "Flown",
    "Processed",
    "Delivered",
    "Accepted"
  ],
  "links": [
    {
      "to": "the-unit",
      "label": "contains"
    },
    {
      "to": "dam",
      "label": "contains"
    }
  ]
}
```

PART II · CHAPTER 6

## Every Source Enters Through an Adapter, Never Directly

Four named sources, from the boundary shapefile to ArcGIS Enterprise, enter through 2 adapter families that guarantee provenance classes, conformance to the confirmed boundary and file integrity before anything becomes an object.

Chapter 5 fixed what the ontology holds and who may write to it. This chapter fixes how bytes become objects: four sources, two adapter families, and a batch event backbone instead of a stream.

### 6.1  Four Sources and Their Provenance Classes

Figure 5 maps the integration. Two sources are operator-held: the GIS boundary shapefile, whose mapping boundary and 50-meter buffer define the acquisition extent and every area figure, and ArcGIS Enterprise, the target serving environment against which the products must be publish-ready without the survey firm loading anything. Two sources are contractor-produced: the acquisition records, which include flight logs, sensor calibration certificates and georeferencing test evidence, and the deliverable file set of ortho tiles, LAS point clouds, DEMs and the QA/QC accuracy report. The operator-held pair enter through the integration adapter, which reads in place; the contractor-produced pair enter through the file & doc adapter, which takes custody of files at transfer. Both families stamp a provenance class on every object they emit.

![Figure 5. The 4 named systems, the adapter path each one takes, and the object model they all map into.](figures/figure_05.png)

Figure 5. The 4 named systems, the adapter path each one takes, and the object model they all map into.

### 6.2  What the Adapter Tier Guarantees

The adapter tier guarantees four things before anything becomes an object. Provenance: every object carries the class of the source it came from, so an analyst can always tell operator records from contractor products. Conformance: geometry is verified against the confirmed boundary before flight, and post-flight coverage is reconciled to the same boundary, because a wrong or incomplete shapefile silently changes the extent and every area figure. Integrity: every file is checksummed at transfer and again at binding, so a corrupt tile or a truncated point cloud is caught before it is modeled. Idempotence: rebinding the same file yields the same object at the same version, never a duplicate. Adapters read and bind; they never write back to the systems of record.

### 6.3  A Batch Backbone Instead of a Stream

The event backbone is deliberately a batch manifest rather than a streaming broker, because this engagement has no continuous workload to order. Ordering comes from the handover manifest, which fixes one sequence over the tiles, point clouds, DEMs and reports so that binding is reproducible. Delivery runs on the two channels the requirement allows, flash drive and secure transfer. Buffering is a staging area where incoming files wait for the conformance and integrity checks of section 6.2 before they touch the model. Replication is the operator's own archive: each accepted object exists as the anchored record in ArcGIS Enterprise, the source file, and a retained copy under the three-year retention schedule. A stream would add a running system to monitor for no workload to carry, so the design carries none.

PART II · CHAPTER 7

## No Inference Runs, and That Is the Design

The inference tiers are empty by decision rather than omission: classification, orthorectification and georeferencing run in the survey firm's pipeline, the operator acts on deliverables in its own tools, and the design states what that placement costs.

Chapter 6 closed the ingestion story: every named source enters through one of two adapter families, and the event backbone is absent because this is a batch acquisition, not a stream. That absence raises the obvious next question about the layers above ingestion. This chapter answers it: where inference runs, what the latency budget is, and what crosses the network boundary when the design places no inference at all.

### 7.1  Every Tier Sits Empty by Decision

The standard stack for this series places inference at three tiers: model serving at the edge, language model serving on site, and a frontier inference cluster for large open-weight models. Figure 6 shows all three tiers for this design, and each is marked empty on purpose. No inference runs at any edge because nothing moves that this design tracks; the deliverables are static imagery tiles and point clouds, and the aerial frames belong to the survey firm, arriving only as orthorectified products. No language model runs on site because no work surface was committed and no language workload exists in the requirement. No frontier cluster is sized because the work surface was declined, so there is no open-weight model to serve and no key-value cache to budget; the KV cache, the memory a language model spends while attending to context, is a concept this design never reaches. What runs instead runs inside the survey firm's own pipeline. Orthorectification, which warps each aerial frame to the ground geometry, radiometric correction and point-cloud classification are the firm's processing steps, priced into its turnkey rates. Georeferencing runs in the aircraft's GNSS/IMU chain at the moment of capture, under the positioning class specified in Chapter 8. The operator's staff then act on the deliverables in the tools they already use, and the ontology makes those analyzes joinable to units, missions and seasons without a model in the loop. Because the register holds no weights, no fine-tunes and no serving runtime, the memory arithmetic that normally governs this chapter, model weights against usable memory with a KV cache ceiling above it, has nothing to compute. The design's quality argument moves to evidence instead: accuracy is published as an error matrix with standard errors, separating producer's from user's accuracy, because surveillance arguments in agricultural safety show that hazards cannot be addressed without ongoing, systematic data rather than a single point estimate (ResearchGate n.d.).

![Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.](figures/figure_06.png)

Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.

### 7.2  The Latency Budget Runs on a Season

There is no session latency to budget, because nothing is served interactively. The binding latency is seasonal: the imagery must be flown within one week either side of 1 July 2025, so the design plans multiple ready days across that window and treats a missed window as a missed season. Inside that constraint the budget has three parts: planning latency, measured in ready days and the moment a notification goes to the operator's project manager; processing latency, which lives inside the survey firm's pipeline and ends at conformance verification; and handover latency, the time for publish-ready files and metadata to move on media. The one measured figure the rollout tracks is orthoimagery ground sample distance against a 3-inch nominal, and the fault it watches for is a missed flight window.

### 7.3  Media Crosses the Boundary, and Nothing Else Does

What crosses the network boundary is delivery media and secure file transfer, not telemetry. No standing link exists, so there is no link to drop and no power path to fail at an edge node; no update path exists because no model is updated. Identity on the operator's side falls under its existing access controls and its confidentiality obligations. The real failure surface is elsewhere: stratus or cloud closing the flight window, a mapping boundary shapefile that proves wrong, media transfer failing, and the 14-day termination right in the agreement stranding partial work. The design answers each in kind: multiple ready days, boundary capture treated as a verified phase item, storage and transfer sized from the confirmed boundary before mobilization, and every phase boundary leaving the operator holding complete, labeled records with an ontology export rehearsed in the final phase.

PART II · CHAPTER 8

## Zero Models Means the License Question Disappears

The model register is empty on purpose, the hardware register holds one named class, the GNSS guidance and correction chain that actually decides QL1 accuracy, and the equipment is otherwise specified by class because the survey firm's turnkey rates price it in.

Chapter 7 emptied the inference tiers by decision and moved the quality argument onto evidence. That decision reaches further than placement: it removes the model register, and with it the license question that usually decides what an operator can own. This chapter states the empty register as a position, names the one hardware class that carries the accuracy argument, and records every choice in the register table.

![Figure 7. The zero models, their placement, and the work each one does.](figures/figure_07.png)

Figure 7. The zero models, their placement, and the work each one does.

### 8.1  An Empty Register Is a License Position

Figure 7 shows the model stack, and it shows no model layers: no learned model, no fine-tune, no serving runtime and no registry workload. The register is empty because the design decision was confirmed with the operator's engineer that no agent or model layer is wanted; vegetation analysis is performed by the operator's own staff downstream, in its own tools, and no model is trained in this engagement. Because there are zero models, there is no license to hold, no license terms to honor and no license trigger to monitor. The usual argument of this chapter, that a given license permits the operator to hold its weights, has no weights to argue about. Ownership instead runs through the professional services agreement and through the ontology, which the operator owns outright: the contract, insurance, invoicing and intellectual property clauses of the requirement became compliance and phasing items, and the agreement carries the task fee table, insurance certificates and prevailing wage determination. The license question does not shrink here; it disappears, and the contract takes its place.

### 8.2  One Hardware Class Carries the Accuracy Argument

The hardware register holds one named class: the GNSS guidance and correction service. United States Geological Survey Quality Level 1, the accuracy tier the LiDAR must meet, is decided by the aircraft's GNSS/IMU direct georeferencing chain plus its correction source, network RTK or an owned base station, so the class is specified with baselines, correction source and test evidence following ISO 12188-style procedures rather than by part number. The acquisition equipment is otherwise named by class only: a manned aircraft, a large-format 4-band camera covering red, green, blue and near-infrared, and a Quality Level 1 LiDAR sensor, because the survey firm's turnkey rates price that equipment in and no shelf class exists for aerial survey cameras or LiDAR sensors. The baseline LiDAR option is a minimum of 8 pulses per square meter; the high-count option at 16 pulses per square meter is priced separately and exercisable at the operator's option. No fixed or thermal cameras exist in this design, no site-installed equipment is placed, and imagery is acquired from a manned aircraft because unmanned data will not be considered.

### 8.3  The Model and Equipment Register

Table 4 records every choice this chapter makes: the models, which are none; the hardware classes and sizing rules; the sensing; the pattern the design stands on; and the ground it runs on.

Table 4 · Model and Equipment Register

| The choice | What was picked | Why here |
| --- | --- | --- |
| Learned model | None; the model register is empty by decision | No agent or model layer was wanted; vegetation analysis stays with the operator's own staff in its own tools |
| License position | No model license exists to hold or trigger | With zero weights, ownership runs through the professional services agreement, not through a license |
| Positioning class | GNSS guidance and correction service, with network RTK or an owned base station | Quality Level 1 accuracy is decided by this chain, so it is specified by baselines, correction source and test evidence |
| Acquisition platform | Manned aircraft with a 4-band red, green, blue and near-infrared large-format camera | Unmanned data will not be considered, so the acquisition class is fixed by the requirement |
| LiDAR sensing | Quality Level 1 sensor at a minimum 8 pulses per square meter | The 16 pulses per square meter option is priced separately and exercisable at the operator's option |
| Pattern the design stands on | System of Context, with the ontology as a projection over the systems of record | Deliverables carry flight mission, sensor and processing provenance, so analysis joins to units, missions and seasons rather than to tiles |
| Ground it runs on | The operator's ArcGIS Enterprise environment in the United States | Files are publish-ready, and publication stays with the operator's own GIS staff inside its own boundary |

PART III · CHAPTER 9

## Readiness Gates Come Before the Flight Window Opens

Four phases carrying 13 items move from mobilization through acquisition and processing to handover, each gate earned on stated evidence rather than calendar dates, with 8 requirements covered and 23 held as open or excluded by the baseline.

Chapter 8 closed the design with the model and equipment register and the ground the acquisition runs on. This chapter turns that design into a sequence a program manager can run: four phases carrying 13 items, gates earned on stated evidence rather than calendar dates, the measures that decide conformance, the failure modes the design already plans for, and the questions the baseline leaves open.

### 9.1  Four Phases and Thirteen Items

The rollout runs as four phases carrying 13 items in total, where an item is a named piece of work and a gate is a statement of evidence that must exist before the next phase begins. Workstreams draw on the five services of the design: Flight Acquisition, Context Layer, Program & Compliance, Data Processing & QA, and Delivery & Handover. Figure 8 shows the phases, their item counts, their workstreams and the requirement coverage of the baseline. Phase 0, mobilization, carries 4 items across the Context Layer, Flight Acquisition and Program & Compliance workstreams. Among them are three named in the plan: confirm the boundary, formats and projections; model the objects before flight, so the 16-object ontology stands before any aircraft moves; and file the insurance certificates and endorsements the agreement requires. The phase exits when the boundary geometry is verified against the register and the object model is in place, because a wrong or incomplete boundary silently changes the acquisition extent and every area figure downstream. Phase 1, acquisition, carries 2 items in Flight Acquisition: plan the July flight window, and fly the manned multispectral and LiDAR acquisition. The collection condition is fixed by the requirement: imagery flown within one week either side of 1 July 2025. The gate is a Flight Mission object recorded as flown inside that window, with sun angle, weather conditions and flight lines captured as provenance. Phase 2, processing and QA, carries 3 items in Data Processing & QA: run aerial triangulation and sensor calibration; produce the ortho tiles, the classified point cloud and the DEMs; and verify QL1 and imagery conformance. The exit gate is stated evidence of conformance: checkpoints used, RMSE by axis and the error matrix recorded on the QA/QC Accuracy Report object, reviewed and issued. Phase 3, delivery and handover, carries 4 items across Context Layer, Delivery & Handover and Program & Compliance. Its named gate is deliver publish-ready files and metadata. The remaining items bind the deliverables into the ontology, rehearse the ontology export so the living model survives any exit, and hand over records under the three-year retention the agreement requires. Requirement coverage stands at 8 requirements covered and 23 held open or excluded by the baseline. The excluded items are the administrative machinery of the requirement itself: proposal submittal mechanics, addendum acknowledgments, references and the pre-proposal meeting, which a build plan does not carry. The open items concentrate where applicability turns on facts not stated, taken up in 9.5.

![Figure 8. The four phases and their gates, and coverage of the 31 requirements across them.](figures/figure_08.png)

Figure 8. The four phases and their gates, and coverage of the 31 requirements across them.

### 9.2  What the Rollout Measures

The rollout measures orthoimagery ground sample distance, recorded in inches against a nominal figure of 3 inches. A reading below the nominal value breaches the measure, and the fault the measure is designed to catch is a missed flight window: off-window or reflight imagery changes the seasonal signal the acquisition exists to record, so the geometric measure doubles as the window's alarm. Conformance on the LiDAR side is verified in Phase 2 through checkpoint testing, with vertical accuracy published as an error matrix with standard errors rather than a single point estimate, and classification QA gated on canopy and margin checkpoints, the hardest environment on site.

### 9.3  Failure Modes

The plan names six failure modes and pairs each with the mechanism that contains it, summarized in Table 5.

Table 5 · Failure Modes

| What fails | What the design does |
| --- | --- |
| Coastal stratus or cloud closes the one-week flight window around 1 July 2025 | Plan multiple ready days across the window with cloud-free-day forecasting and notify the operator's project manager the moment a ready day opens; a missed window is a missed season |
| The mapping boundary shapefile proves wrong or incomplete, silently changing the acquisition extent and every area figure | Treat boundary capture as a phase, not an assumption; verify geometry against the register before flight and reconcile post-flight coverage to it |
| Tile and point-cloud data volume is unknown because the boundary area is not stated, so storage, transfer and effort may be mispriced | Size storage and transfer from the confirmed boundary before mobilization and re-price the pipeline once the area is known |
| QL1 classification degrades over dense canopy | Gate classification QA on canopy and margin checkpoints and publish accuracy with an error matrix and standard errors rather than a point estimate |
| Prevailing wage applicability to the flight and processing crew is unstated and lands as unbudgeted cost after award | Settle the classification with the operator during Phase 0 and load any wage delta into the fully loaded hourly rates |
| The 14-day termination right strands the operator with partial deliverables and no ontology | End every phase with complete, labeled records held by the operator and rehearse the ontology export in Phase 3 so the living model survives any exit |

### 9.4  Lessons

**Treat the boundary as a phase, not an assumption.** The boundary shapefile defines the acquisition extent and every area figure, and it arrives as a file with no accuracy statement attached. The plan spends one of its four mobilization items verifying it against the register before flight and reconciling post-flight coverage to it afterwards, because the cheapest place to find a boundary error is before the aircraft leaves the ground. A missed window is a missed season. The requirement fixes collection to one week either side of 1 July 2025 because the vegetation signal the imagery records exists only at that moment. The plan answers with multiple ready days across the window and immediate notification when one opens, accepting that weather, not effort, is the binding constraint. Accuracy is a distribution, not a point estimate. A single vertical accuracy number hides where classification fails, and dense canopy is exactly where it fails here. Publishing the error matrix with standard errors, and gating classification QA on canopy and margin checkpoints, makes the weak spots visible in the deliverable itself. End every phase holding a complete record. The agreement carries a 14-day termination right, so the operator can be left holding partial deliverables at short notice. The phasing answers it structurally: each phase boundary leaves the operator with complete, labeled records in the ontology, and the export is rehearsed in Phase 3 so the living model survives any exit.

### 9.5  What Is Still Open

Three questions remain open in the baseline. First, prevailing wage applicability to the flight and processing crew is unstated; settling the classification with the operator during Phase 0 would convert an unbudgeted-cost risk into a known wage delta inside the hourly rates, changing the fee table and nothing else. Second, the boundary area is not stated, so storage, transfer and processing effort are sized against a confirmed geometry rather than a figure; settling it would firm the pricing of the pipeline and the delivery media. Third, the rules reading found no entry covering surveying licensure or manned survey aviation, the nearest entry governing only the small unmanned aircraft the requirement itself excludes; settling it would move the compliance items carried as flags into the covered column of the requirement tally, turning 8 covered and 23 open or excluded into a fuller account without altering the design.

PART III · CHAPTER 10

## The Operator Owns the Record, Not Just the Files

Ownership of the object model, the provenance metadata and the decision record stays with the operator through every phase boundary, so termination, short payment or a missed window never strands it with partial, unlabeled deliverables.

Chapter 9 arranged the rollout so that every phase boundary leaves the operator holding complete, labeled records. This chapter states who owns what the design builds, and why that ownership holds through termination, short payment or a missed window.

### 10.1  What the Design Builds and Who Holds It

The object model is owned by the operator outright. The 16 objects and their typed links form a projection over the operator's own systems of record, never a shadow copy held on the survey firm's side, and each phase boundary binds more of the record into it: the flight mission, the products, the QA reports, the invoices. No weights or fine-tunes exist in this design, because the design registers no model; there is no licensed weight to own and no fine-tune to lose, and vegetation analysis runs in the operator's own tools against the handed over products. The decision record lives in the same ontology: the status vocabularies on each object, from flight mission statuses through product QA statuses to invoice and acceptance statuses, are the trail of named decisions, and the operator's project manager holds the direct reporting line and the approval authority recorded on the person object. The boundary holds throughout: delivery is inbound media by flash drive and secure transfer, handed over files fall under the operator's existing access controls and its confidentiality obligations, and the survey firm retains only what the agreement's retention terms require. A 14-day termination, a short-paid invoice or a missed window can strand the operator with fewer deliverables, but never with unlabeled ones.

### 10.2  The Offer Behind the Design

The design is a CodeNinja design, produced on Praxis, the platform that produced this paper and every choice recorded in Chapter 11. Its living record is Hyper Ontology, the object model that turns tiles and point clouds into a site the operator's staff can reason about across units, missions and seasons. Its posture is Sovereign Infrastructure: the operator holds its own hardware and its own environment, nothing leaves the boundary, and the deliverables stay under the operator's access controls in-country. The offer is therefore narrow and deliberate: a system of record the operator owns outright, built on a platform the operator can audit, with no model, no cloud and no dependency that survives a terminated agreement.

PART IV · CONCLUSION

## A Flight Becomes Knowledge When the Record Survives

In one view, the design is a survey procurement turned inside out: the flown imagery and point clouds matter, but the durable product is the 16-object ontology that binds every tile, cloud, DEM, report and invoice to the flight mission, sensor systems and season that produced it, so the one week of July 2025 becomes a versioned baseline that the next season can be compared against rather than a folder that must be rediscovered.

Running the same shape elsewhere takes three things: a survey engagement scoped so that boundary geometry is captured and verified as a phase item rather than assumed; a delivery path that leaves publish-ready files in the operator's own environment with provenance metadata rather than loading anything on its behalf; and an object model owned by the operator from Phase 0, so that even a 14-day termination right leaves it holding complete, labeled records instead of partial files.

PART IV · CHAPTER 11

## How Praxis Contextualized and Reasoned This Design

Every design in the series is produced on Praxis, and this chapter lets a reader trace the 737 records in the room, the eight lenses and the adopted system of context pattern back to what justified each choice.

Chapter 10 assigned ownership of everything the design builds to the operator. This closing chapter shows how the design itself was produced: what Praxis was given, which lenses it read over that material, which patterns it adopted and set aside, and where the reasoning lands. Every design in this series is produced on Praxis, the design team platform for designing physical AI systems, and this chapter exists so that a reader can trace any choice in the paper back to what justified it. Figure 9 shows the ask, the family and industry assigned, what was in the room, the eight lenses, the patterns and the equipment classes in one view.

### 11.1  Contextualizing the Ask

The ask, in the operator's own terms, is a one-year engagement to acquire 3-inch 4-band orthoimagery and USGS QL1 LiDAR over the site inside the July 2025 window and to deliver publish-ready files against the operator's own serving environment, with no loading performed by the survey firm. Praxis assigned the family Physical AI and the Agriculture & Earth Observation industry. What was in the room: 737 records listed, of which 139 were read in full and 598 are available on demand. The records read in full include the requirement itself, its evaluation criteria exhibit, the services agreement, the task fee table and the submittal checklist, so the constraints in Chapter 3 and the compliance items in Chapter 9 trace to specific clauses rather than summaries.

![Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.](figures/figure_09.png)

Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.

### 11.2  The Lenses

Eight lenses were read over the room, and Table 6 records what each could see, how many of its readings are cited in this design and what each contributed. Seven lenses contributed; one returned nothing for this shape and is shown as a gap rather than filled.

Table 6 · The Lenses and What They Contributed

| Lens | Could see | Cited | What it contributed |
| --- | --- | --- | --- |
| First principles | The ingestion workflow, the boundary-capture pitfall and the rule that the ontology must never become an image catalog | 1 | Set the shape of the plan: model the site first, imagery second |
| Case studies | Earth-observation accuracy reporting and automated screening of agricultural parcels | 2 | Shaped the QA gate: publish accuracy as an error matrix with standard errors, and treat the boundary register, not the imagery, as the truth for area |
| Tooling and recency | The current on-site product shelf | 1 | Carried one current product, the ontology, and registered no learned model because the engineer confirmed no model layer is wanted |
| Hardware and equipment | Aerial survey cameras, LiDAR sensors and positioning chains | 1 | Named the acquisition hardware by class only, with the GNSS guidance and correction class entry as the nearest anchor |
| Rules and regulations | Surveying licensure and manned survey aviation rules | 0 | A gap: the nearest entry governs small unmanned aircraft the requirement excludes, so prevailing wage, equal opportunity and insurance items are flagged as open questions |
| Approach | Phasing rules for validation-first builds | 2 | Set the phase order: readiness confirmed before flight, later phases earned on stated evidence gates |
| History | Earlier crop-monitoring precedents | 1 | Taught that baseline imagery must be captured and kept, because any later treatment or repeat flight destroys the signal, so the flight is archived as a versioned baseline |
| Domain fusion | The pinned projection-over-records architecture fused with the domain brief's ingestion workflow | 2 | Fused projection over records with the ingestion workflow so product objects carry flight mission, sensor and processing provenance |

### 11.3  Patterns Adopted and Set Aside

One pattern was adopted. System of Context was pinned as the sole primary pattern, and it contributes exactly its ontology layer: objects and versioned product provenance laid over the operator's own records, which are never replaced, never modified and never loaded. Its agentic layers were excluded because the engineer confirmed that no work surface and no model layer is wanted; the operator analyzes vegetation in its own tools, and the ontology makes those analyzes joinable to units, missions and seasons. No other reference architecture was taken, and none was set aside: none of the published vendor architectures answers a one-time manned aerial acquisition, so none was added as supporting. The proven shelf held nothing for this shape and is carried empty, said plainly; the contract, insurance, invoicing and intellectual property clauses became compliance and phasing items instead of architecture.

### 11.4  Where the Reasoning Lands

The reasoning lands on equipment classes. The acquisition hardware is named by class only: a manned aircraft, a 4-band R/G/B/NIR large-format camera, a USGS QL1 LiDAR sensor, and a GNSS/IMU direct georeferencing chain with network corrections or an owned base station. Classes rather than part numbers, because the corpus holds a GNSS guidance and correction class entry and no aerial survey camera or LiDAR sensor class, and the requirement prices that equipment into the survey firm's turnkey rates, so the design specifies the positioning chain with baselines, correction source and test evidence rather than hardware. The pattern is the same everywhere in this paper: the boundary was read from the requirement, the accuracy gate from cited precedent, the phasing from a validation-first rule, and every figure from a record. Everything shown was recorded reading and nothing is inferred.

Appendix A

## What It Costs

The design buys no compute and serves no model. The acquisition is flown on a manned aircraft by the survey firm, processing runs in the survey firm's own pipeline, and the object model is anchored in the operator's existing ArcGIS Enterprise, so there is no owned-versus-rented comparison to print. The cost of this design is the acquisition itself, priced by the survey firm against the operator's own task table: the flight, the 4-band orthoimagery, the Quality Level 1 LiDAR at the baseline pulse density, and the processing, QA and delivery that bind every product into the site ontology.

### A.1 What Would Change the Answer

| Line | When it appears | How to price it |
| --- | --- | --- |
| The higher pulse density option | If the operator exercises the 16 pulses per square meter task | The operator's own task table prices it separately; the survey firm's quotation settles the delta |
| A reflight | If weather or sun angle closes the July window before the site is flown to specification | One further mobilization at the survey firm's quoted rate; the season is lost if no ready day opens |
| A vegetation model | If the operator later asks for automated classification instead of analyst review | One open-weight segmentation model on a single 48 GB card; one L40S-class card lists at 7,709 dollars (esaitech 2026) |

### A.2 Sources for This Appendix

- esaitech. 2026. PNY NVIDIA L40S 48 GB GDDR6 PCIe. <https://esaitech.com/products/pny-technologies-nvl40stcgpu-kit-nvidia-l40s-4-port-48gb-gddr6-graphic-card>

SOURCES

## Source Register

Watch Us Grow. n.d.. The Reality of Farm Accidents. <https://watchusgrow.org>

CDC. 2001. FACE Report No. 01OK061, Farmer died when she was. <https://stacks.cdc.gov>

ABC. 2010. Farm accidents cost $1b per year: research. <https://www.abc.net.au>

IOSH Magazine. 2021. Fatalities spike in agricultural industry. <https://www.ioshmagazine.com>

ResearchGate. n.d.. Data Extracted from AgInjuryNews.org 7.. <https://www.researchgate.net>

---

### About CodeNinja

CodeNinja is a Middle Eastern-American artificial intelligence lab focused on building self-improving systems. We are reinventing knowledge work to close the loop between vertical AI use cases and the generalized intelligence that fuels it, accelerating the path toward organizational superintelligence.


---

# Feeder Firewatch: Live Ignition and Outage Risk for Every Distribution Feeder

Canonical: https://codeatoms.ai/wildfire-risk-distribution-us/
DOI: https://doi.org/10.5281/zenodo.23159328
PDF: https://codeatoms.ai/wildfire-risk-distribution-us/paper/feeder-firewatch-wildfire-risk-distribution-cooperative-us.pdf
License: CC BY 4.0
Publisher: CodeNinja Atoms (https://codeatoms.ai), a fully owned subsidiary of CodeNinja

VERTICAL-DRIVEN ARCHITECTURES · ENERGY & UTILITIES · DESIGNED WITH PRAXIS · OCTOBER 2026

# Feeder Firewatch: Live Ignition and Outage Risk for Every Distribution Feeder

One live distribution risk model joins reclosers, meters, poles, vegetation, weather, cameras and crews into a 48-hour ignition and outage picture for a member-owned distribution cooperative in the United States, with every de-energisation and fast-trip decision left to a named person.

CodeNinja Engineering Team

For the operations and wildfire mitigation lead, the dispatch supervisor and vegetation management coordinator, and the grid, vision, data and platform engineers who would build and run it.

---

Vertical-Driven Architectures is a CodeNinja series of system designs. Every design in the series is driven by a real-world problem and scenario in a single industry, and every one is designed on Praxis, CodeNinja's platform for designing physical AI systems. Operations are described by class, never by name.

At a glance

## Live wildfire ignition risk for an electric distribution cooperative in the United States

**What this is.** An open reference architecture for system design in physical AI: a live ignition and outage risk score for every distribution feeder segment, built on the cooperative's own hardware, with every de-energisation and fast-trip change approved by a named operator. It is written for operations and engineering leaders at distribution utilities and for the engineers who would build it. The operator is an illustrative scenario, not a CodeNinja customer.

**The answer in numbers.**

| Part | The design |
| --- | --- |
| Sources joined | 12 systems, including SCADA, GIS, the AMI head end, the outage management system, work management, wildfire camera and weather feeds |
| Object model | 14 typed objects and 12 links, published as JSON for reuse |
| Models | Self-hosted open-weight models: GLM 5.2 under MIT (reasoning) on site, RF-DETR (vision) at the edge |
| Frontier compute | One node of eight 141 GB HBM-class GPUs holds GLM 5.2 at FP8 (753 GB of weights, 904 GB with headroom) |
| Edge | Sealed industrial boxes at substations and on patrol trucks detect smoke and damaged equipment when cellular coverage drops |
| Three-year cost, owned | About 841,000 US dollars with support and power at the Texas industrial power price |
| Three-year cost, rented | 0.88 million to 1.92 million US dollars for the same GPUs around the clock; ownership costs about the same as the deepest three-year commitment (version 2) |
| Closed model break-even | The cheapest closed model matches the owned stack at about 41 users; above that, ownership is cheaper and the gap grows with every user |
| Human control | Every public safety power shutoff (PSPS) recommendation becomes a decision record a named operator approves or declines; the design never opens or closes a recloser |

**Reuse it.** The object model, the model register and the figures are free to reuse under CC BY 4.0.

**Made with.** Reasoned on [Praxis](<https://codeatoms.ai/praxis/>), CodeNinja's platform for designing physical AI systems. The object model imports into [Hyper Ontology](<https://codeatoms.ai/hyper-ontology/>), which turns it into a living system. Both are in beta; access by request.

ABSTRACT

## An Ignition Risk Should Be Scored Days Ahead, Not Discovered in Smoke

The operator needs to know which feeder segments will fail or ignite next, and what to de-energise before a red flag wind arrives. It cannot answer that today because the signals that would answer it sit apart: recloser fault counts live in SCADA, last gasp messages live in the AMI head end, pole crossarm conditions live in inspection photos in folders, vegetation records sit with the trimming contractor, and public safety power shutoff decisions are made from two websites and a phone call. The systems that know a line is dead and the systems that know the wind is coming never meet before an event.

The design is one live distribution risk model built as a system of context: twelve named source systems enter through two adapter families into an ontology of fourteen objects that binds feeders, segments, poles, reclosers, meters, inspections, outages, weather, cameras, crews, work orders and PSPS decision records into a single feeder-and-pole picture. Seven services run on it, served through eight surfaces: edge vision boxes at substations and on patrol trucks detect smoke and damaged equipment where the cameras are, ruggedised servers at the operations center hold the risk store and the storm picture, and an agentic work surface on one FP8 node of the 141 GB HBM class lets four distribution engineers, six system operators and the dispatch supervisor ask what changed on a feeder and build their own agents. Two models carry the load, RF-DETR at the edge under Apache-2.0 and GLM 5.2 at the center under MIT, both held on the cooperative's own hardware, with read-only paths from every system of record and no SCADA control writes.

The paper opens with the problem and the join failure across the operator's existing systems, then the design: constraints and scoping, the stack from sources to surfaces, the object model and its hosting posture, ingestion through the adapter tier and event backbone, inference placement and the latency budget, and the models and licenses that decide what the cooperative owns. Part III covers the two-phase rollout with its item counts and exit gates, requirement coverage, failure modes and ownership. Part IV closes with the Praxis chapter, tracing every choice back to what justified it.

---

![Figure 1. Feeder Firewatch on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.](figures/figure_01.png)

Figure 1. Feeder Firewatch on one page: the sources the operation already runs, one object model, what it computes, and the person who decides.

## Contents

Each chapter is tagged for the reader it serves most directly: Executive, Team Lead, FDE, Reference.

|  |  |  |
| --- | --- | --- |
|  | Abstract · An Ignition Risk Should Be Scored Days Ahead, Not Discovered in Smoke | Executive |
| PART I · THE PROBLEM | | |
| 1 | [The Ignition Risk Hides Between Patrols](#ch1) | Executive |
| 2 | [Every System Sees One Slice of the Line](#ch2) | ExecutiveTeam Lead |
| PART II · THE DESIGN | | |
| 3 | [Four Constraints Bound the Whole Design](#ch3) | Team Lead |
| 4 | [One Stack Runs From Record to Surface](#ch4) | Team LeadFDE |
| 5 | [Fourteen Objects Turn the Grid Into One Argument](#ch5) | FDE |
| 6 | [Every Source Enters Through an Adapter](#ch6) | FDE |
| 7 | [Vision Belongs at the Edge and Reasoning On-Premises](#ch7) | FDE |
| 8 | [The License Decides What the Cooperative Owns](#ch8) | FDEExecutive |
| PART III · THE ROLLOUT | | |
| 9 | [Shadow Mode Comes Before Any Flag Is Trusted](#ch9) | Team LeadExecutive |
| 10 | [The Intelligence Should Stay with the Cooperative That Produced It](#ch10) | Executive |
| PART IV · HOW IT WAS DESIGNED | | |
|  | Conclusion · The Risk Picture Should Be Owned Where the Risk Lives | Executive |
| 11 | [How Praxis Contextualized and Reasoned This Design](#ch11) | Team LeadFDE |
|  | [Sources](#sources) | Reference |

PART I · CHAPTER 1

## The Ignition Risk Hides Between Patrols

A distribution cooperative's leading ignition risks build up continuously on its feeders, but its patrol cycle, folder-bound inspection photos and website-driven shutoff decisions let them accumulate unseen until fire weather arrives.

The abstract gave the shape of the answer: one live distribution risk model built as a system of context, with every de-energisation decision left to a named person. This chapter establishes the problem that answer has to solve, the data the operation already holds, and the ground it stands on.

### 1.1  The Question and the Data Behind It

The question the operation needs answered is concrete: which feeder segments combine aged crossarms, dense vegetation and prevailing wind exposure in a way that makes ignition risk actionable this season, and which of those segments will be exposed to fire weather within the next 48 hours. Answering it requires joining data the operation already holds but never assembles in one place: recloser fault counters and trip indications from the supervisory control and data acquisition layer, last gasp messages and 15 minute interval reads from the meter fleet, pole locations and conductor geometry from the geographic information system, pole inspection records and their photographs, right of way and vegetation status, wind gust and relative humidity forecasts with red flag warnings, wildfire and substation camera feeds, and the positions of field crews. The regulatory ground adds its own demands: state public utility commission rules govern distribution practice, the regional grid operator's wildfire mitigation guidance issued after the 2024 fire season shapes expectations for risk documentation, outages are reported through the outage management system, and any public safety power shutoff recommendation carries a notification duty the approving operator must be able to evidence after the fact.

### 1.2  The Documented Cost of Finding Out Late

The cost of fragmented information during grid emergencies in Texas is a matter of public record. Reporting on the 2021 Texas blackouts found that paperwork failures worsened the crisis and forced a scramble in the middle of the storm to restore the critical fuel supply, because the records needed to act were scattered across systems and holders (TPR 2021). The pattern is older and broader: the joint federal investigation of the 2003 blackout in the United States and Canada traced the escalation in part to operators who did not grasp the state of the system as it degraded, a situation awareness failure rather than a equipment failure (Energy 2003). For a distribution cooperative, the same mechanism appears at smaller scale every storm: dispatchers rebuild the operating picture by hand from the outage management system, the supervisory alarms, member calls and crew radios, while the signals that could have warned them sit unjoined in folders and vendor portals.

### 1.3  The Operation as a Scenario

The operation is a member owned distribution cooperative serving more than 60,000 meters across more than ten counties in the Panhandle region of Texas. It runs more than 9,000 miles of overhead line, more than 40 substations fed from two regional grids, substantial oil field and irrigation load, and two wind farms interconnected on its own system. Its service territory has burned twice in the recent Panhandle wildfire seasons, so the risk in question is lived experience rather than a compliance abstraction. The people in the loop are four distribution engineers, six system operators under a dispatch supervisor staffing a 24 hour desk at the operations center, a vegetation management coordinator, a reliability engineer, an emergency management coordinator, and line crews working from a fleet of about 20 patrol trucks. The physical environments are open rangeland and farmland under high wind, dust, hail and temperatures from well below freezing to extreme heat, with intermittent cellular coverage at substations and patrol areas. The design scope counts nine named source systems, two adapter families, fourteen objects in the model, seven services, eight surfaces and two models, laid out in Figure 1.

PART I · CHAPTER 2

## Every System Sees One Slice of the Line

SCADA knows a recloser tripped, the AMI head end knows a line went dead, GIS knows where the pole stands, and none of them join to the vegetation, weather and inspection record before the fault becomes a fire.

Chapter 1 defined the question and showed that the data to answer it already exists inside the cooperative. This chapter examines why that data never becomes an answer: each system holds one slice of the line, and no system sees the slices together.

### 2.1  What Each System Sees

The supervisory control and data acquisition system sees the electrical state of the network: recloser positions, alarm streams and fault indications across the substations and more than 300 reclosers. It misses everything that explains why a fault fired, because vegetation condition, crossarm age and wind exposure live in other systems entirely. The meter head end sees consumption and silence: 15 minute interval reads and last gasp messages from more than 60,000 meters tell it exactly where and when a line went dead. It misses the asset above the meter; a last gasp cluster resolves to meters, not to the span of conductor or the pole that caused it. The geographic information system sees the static anatomy of the network, every pole, conductor, transformer and right of way polygon, but nothing that changes between inspection cycles, so it cannot say which of its own poles is deteriorating this year. The outage management system sees events and their causes as coded after the fact, along with member call clusters, which makes it a record of outages rather than a warning of the next one. The work management system sees the crews and the paperwork: who is assigned, what is approved, what closed. It sees nothing about risk, so it cannot prioritize the trim or the pole replacement before the fire weather arrives. The weather subscription sees the atmosphere, gusts, humidity and red flag warnings, but knows no feeders, so it cannot say which of the cooperative's segments a red flag warning actually endangers. The vegetation records see the trimming cycle and the purchased imagery; the wildfire camera portal sees the sky above a dozen stations; the crew automatic vehicle location feed sees the trucks. Each is blind to the others.

### 2.2  What None of Them See Together

What none of them sees is the joined statement the operation actually needs: this feeder segment has aged crossarms on record, vegetation encroaching in the imagery, a recloser fault history that has climbed over two seasons, a red flag warning arriving within 48 hours, and a crew close enough to act. Figure 2 sets the nine systems side by side, each with its slice and its blind spot converging on that one question. The cost in practice is that the cooperative's own signals identify its highest risk feeders only after an event joins them by hand: a dispatcher correlating dead meters against alarms and calls while the wind blows, exactly the manual picture building that research into control room situation assessment identifies as the slowest and most error prone path to awareness (OSTI 2007). The ignition risk hides in the gaps between the slices, and it is precisely the gaps the object model in Part II exists to close.

![Figure 2. Nine systems, each seeing one part of the answer. the question needs all of them in one place at once.](figures/figure_02.png)

Figure 2. Nine systems, each seeing one part of the answer. the question needs all of them in one place at once.

PART II · CHAPTER 3

## Four Constraints Bound the Whole Design

Read-only access to every system of record, no new field devices, human ownership of every de-energisation and fast-trip decision, and operation through storm-grade connectivity loss shape every choice downstream.

Chapter 2 showed that the ignition risk lives in the gaps between nine systems that each see one slice of the line. This chapter fixes the four constraints that determine how those gaps may be closed, and records what the design scoped in, scoped out and chose against.

### 3.1  Read Only Access to Every System of Record

Every connection in the design reads; none writes. The geographic information system is never edited, the outage management system is never driven, and the supervisory layer is mirrored through a one way path rather than queried in both directions. This is hard in this industry because operational technology is rightly guarded: a distribution cooperative's compliance function must determine what falls inside reliability cybersecurity scope, and that determination is a decision to make with them, not an assumption to design on. The design therefore reads only through a hardware enforced one way path and lets the cooperative's own categorisation decide what touches what.

### 3.2  No New Field Devices

The constraint states that no new reclosers or meters are in scope; the design reads the more than 300 existing reclosers and more than 60,000 existing meters and nothing else. This is hard because the instinctive answer to blind spots is more hardware, and a device procurement program would add years of capital cycles before the first score was produced. The hypothesis behind the design is that the existing signals already identify the highest risk feeders once joined with the inspection photographs, so sensing effort goes to cameras and analysis at the edge rather than to new grid devices.

### 3.3  Human Ownership of Every De-energisation and Fast-Trip Decision

Every recommendation the system produces, whether a public safety power shutoff, a fast trip enablement or a de-energisation, is decided by a named person in the control room under the cooperative's procedure and the state commission's expectations. The design never writes to protection equipment. This is hard because the whole value of the system is speed under fire weather, and an operator will only decide fast on a recommendation whose provenance they can read: contributing signals, model version and rationale, kept as a decision record the next decision reads.

### 3.4  Operation Through Storm Grade Connectivity Loss

The system must work when cellular coverage at substations and patrol areas drops, because that is exactly when it matters. This is hard because the failure mode is silent: intermittent links drop detection evidence without announcing it. The design answers with store and forward buffers sized to the worst measured outage, edge inference that survives link loss, and degraded mode reporting that states plainly that its picture is stale.

### 3.5  What the Scoping Decisions Buy and Cost

Three scoping decisions set the shape of everything downstream, and Table 1 records what each buys and what it costs.

Table 1 · Scoping Decisions

| Decision | What it buys | What it costs |
| --- | --- | --- |
| Purpose built risk store keyed to GIS ids, synchronised from the geographic information system | Every score points at an authoritative pole, span or feeder segment id that field crews recognize | A synchronisation path to keep the store current, and a second store to run beside the system of record |
| Edge analysis with buffered synchronisation at substations, trucks and the yard | Detection that survives intermittent cellular and keeps evidence flowing during storms | Compute at each edge site and a buffer sizing discipline against the worst measured outage |
| GLM 5.2 under an MIT license on the cooperative's own hardware for the work surface | The cooperative owns the weights outright, with no revenue trigger and one node holding the model | The operator runs and updates the frontier node itself rather than consuming a hosted service |

### 3.6  What the Design Chose Against

Table 2 records the alternatives the design rejected and the scope it declined, with the reason in each case.

Table 2 · What the Design Chose Against

| Where | What was picked | Instead of, and why |
| --- | --- | --- |
| Risk storage | Purpose built risk store keyed to GIS ids, synchronised from ESRI GIS | Extending ESRI GIS as the risk store, because GIS stays authoritative and is never edited, and every score must point at a GIS id |
| Work surface model | GLM 5.2 under its plain MIT grant | GLM 5.3 under its bespoke vendor license, because that license would keep the weights out of the cooperative's hands |
| Video analysis | Edge analysis with buffered synchronisation | Streaming video centrally, because intermittent cellular at substations and patrol areas makes central streaming silently unreliable |
| Control actions | Human decisions recorded in the PSPS decision record | Any SCADA control write from the platform, because fast trip and de-energisation stay human actions in the control room |
| Historic records | Live feeds plus agreed opening balances | Bulk migration and cleansing of historic data, which stays with the cooperative's own records program |
| Scope boundary | Detection, scoring, evidence and a work surface | Vegetation trimming execution, regulatory approvals, new field devices and replacement of any system of record, all of which remain outside the design |

PART II · CHAPTER 4

## One Stack Runs From Record to Surface

A single layered architecture carries telemetry, imagery and records from nine named systems through two adapter families into one ontology, and serves seven services through eight surfaces without touching a control path.

Chapter 3 fixed the constraints: the design reads every system of record and writes back almost nothing, keeps every byte on the cooperative's own hardware, and leaves each de-energisation and fast-trip decision to a named person. This chapter describes the single stack that carries those constraints from the grid's source systems to the surfaces its people work in.

### 4.1  The Pattern: Records Below, One Model in the Middle, Agents Above

The architectural pattern is a system of context layered over systems of record. At the bottom, the cooperative's existing systems stay authoritative: Survalent SCADA and ADMS still run the grid, the Landis+Gyr head end still owns meter data, ESRI GIS still owns asset geometry and ids, the outage management system still owns outage state, and NISC iVUE still owns work. The design edits none of them and retires none of them. In the middle sits one object model of fourteen objects joined by typed links, which is the only place in the estate where a pole, its inspection photos, the recloser above it, the meters below it and the red flag warning over it exist together. Above the model run seven services and the agents the cooperative's engineers build themselves, which read the joined picture and write only recommendations, decision records and approval-gated work orders.

This shape fits a distribution cooperative for a specific reason: the operation's problem is not a missing system but nine adequate systems that cannot see one another, and research on grid control rooms shows that situation assessment degrades exactly when operators must assemble their picture by hand from fragments (OSTI 2007). The layered split also matches the physics of the data: high-rate telemetry and video are heavy and belong near where they are produced, on edge nodes and at the operations center, while records such as inspections and work orders change slowly and tolerate central storage.

Two alternatives were set aside. A point-to-point integration mesh would multiply interfaces with every new question, because each connection encodes one relationship; a document store keyed by asset id cannot hold the reach the risk question needs, because joining a meter to a weather event across an asset hierarchy is a traversal, not a lookup. The middle object model buys both: one interface per source and one edge per relationship. Figure 3 shows the layered stack with the component count at each layer: twelve sources, two adapter families, fourteen objects, seven services and eight surfaces.

![Figure 3. The layered stack: 12 sources, 2 adapter families, 14 objects, 7 services and 8 surfaces.](figures/figure_03.png)

Figure 3. The layered stack: 12 sources, 2 adapter families, 14 objects, 7 services and 8 surfaces.

### 4.2  The Stack Stage by Stage

Table 3 walks the stack stage by stage, naming the components at each stage and the mechanism each uses. Read from the top down, it is the path of a single fact, a recloser operation for example, from the point list where it originates to the storm picture where a dispatcher acts on it. Three properties run through every stage: sources are read-only, the object model is the only join point, and no stage touches a control path.

Table 3 · The Stack, Stage by Stage

| Stage | What it is responsible for | How |
| --- | --- | --- |
| Sources | Hold the records the estate already owns: SCADA points, alarms and fault indications, AMI intervals and last gasp messages, GIS assets and right of way, outage events, iVUE crews and work orders, inspection records, weather and red flag feeds, vegetation and satellite imagery, wildfire camera feeds, crew AVL | Read in place through each system's own vendor interface, with MultiSpeak and CIM where supported; nothing is migrated and no source is edited |
| Sensing | Turn the physical territory into signals: 42 substation PTZ cameras, 12 wildfire cameras, patrol truck forward cameras, a drone thermal camera, mesonet wind and humidity stations, 310 recloser fault indicators, last gasp messages from 61,000 meters and 20 truck AVL units | Existing cameras are reused through defined gates; new fixed thermal only where a gap is proven; every stream is time-synchronised against one grandmaster |
| Adapters | Two families move everything in: the telemetry adapter for high-rate points, intervals and events, and the integration adapter for records, files and imagery | Normalise to typed events, stamp source and provenance, buffer with store-and-forward, pass events in order over the backbone |
| Object model | Hold one live feeder-and-pole picture of fourteen objects with typed links, anchored to GIS ids so every score and every photo points at a real asset | An ontology and graph store in the operations center; the risk store hangs scores off the same ids |
| Inference | Detect at the edge and reason at the center: RF-DETR for smoke, pole and vegetation detections on edge nodes; 48-hour ignition and outage scoring in the risk service; GLM 5.2 on the work surface, served by vLLM on one eight-GPU node at FP8 | Detection runs beside the cameras and survives link loss; central scoring and language serving run on cooperative servers |
| Services | Seven services: live distribution model, ignition and outage risk, storm operations, compliance and records, vision and thermal detection, field and edge infrastructure, and the engineer work surface and agents | Each service reads and writes only the object model; no service touches a control path |
| Surfaces | Eight surfaces people act from: the live storm picture, the engineer work surface and its views, the PSPS event surface, truck tablet alerts and the monthly risk view | Served from the services over the same ontology, so every view and every recommendation names the asset, the evidence and the person who decides |

PART II · CHAPTER 5

## Fourteen Objects Turn the Grid Into One Argument

The ontology binds substations, feeders, segments, poles, reclosers, meters, inspections, outages, risk scores, weather, cameras, crews, work orders and PSPS decisions with typed links, so a question about one pole reaches the weather and the recloser that matters to it.

Chapter 4 placed one object model in the middle of the stack, fed by two adapter families and read by seven services. This chapter describes what that model holds: fourteen objects, the typed links between them, where the human loop lives, and what one object looks like in its recorded form.

### 5.1  Fourteen Objects and Their Typed Links

The fourteen objects are substation, feeder, feeder segment, pole, recloser, meter, pole inspection record, outage event, feeder segment ignition risk score, red flag warning, wildfire camera station, field crew, work order and PSPS decision record. Each is anchored in the system that authoritatively holds it: substation and recloser in Survalent SCADA; feeder, feeder segment and pole in ESRI GIS; meter in the Landis+Gyr head end; outage event in the OMS; inspection record in the pole inspection spreadsheet; field crew and work order in NISC iVUE; camera station in the wildfire camera vendor portal; red flag warning in the weather and mesonet subscription; and the ignition risk score in the risk model store. The PSPS decision record is the one object with no upstream system, because it originates in this design and carries the approving operator, the rationale and the state regulator notification reference. Figure 4 draws every object and its typed links, with the ignition risk score as the focal measure that substation, feeder, feeder segment, recloser and meter each point into.

The links are typed and directional, and the reach they give a query is what a document store keyed by asset id cannot reproduce. Starting from one pole with a defect found, the traversal reaches its inspection record and photo references, the feeder segment that carries it, that segment's ignition risk score with its contributing signals and model version, the recloser protecting the segment and its fast-trip profile state, the meters on the segment and their last gasp history, the red flag warning active over the counties, the camera stations with bearing coverage over the area, and the approved work order with its crew. None of that reach is precomputed; it is the edges. A document store would need a hand-built join for every one of those hops, and each new question would need a new pipeline. The ontology needs one typed edge per relationship, so a new question is a new traversal over structure that already exists.

![Figure 4. The fourteen objects of the model and the typed links that let a query reach across them.](figures/figure_04.png)

Figure 4. The fourteen objects of the model and the typed links that let a query reach across them.

### 5.2  Where the Human Loop Lives and Where the Model Runs

The human loop lives in two objects. Every de-energisation and every fast-trip change is recorded as a PSPS decision record with a recommendation, a rationale, an approving operator and a state regulator notification reference, and it moves through the states recommended, approved, declined, de-energised and re-energised under a named person's hand; the design never opens or closes a recloser. Work orders follow the same discipline: a recommendation becomes a draft, enters iVUE as pending approval, and only an approved order reaches a crew, so field work is always issued from the system crews already live in.

The hosting posture keeps the model with the cooperative. All fourteen objects live on cooperative servers in its own operations center, with overflow and disaster recovery in a sovereign United States cloud; no object leaves the country. Every surface sits behind the operator's on-site identity provider with role-based access, so a dispatcher, a distribution engineer and a vegetation coordinator see the same picture under different rights. External links are inbound and read-only: weather feeds and the camera vendor portal are pulled, never pushed to, and no operational data flows out. The only write path back into the estate is the approval-gated one, into decision records here and into iVUE under approval; GIS is never edited, and scores live in a purpose-built risk store synchronised from GIS ids.

### 5.3  One Object in Its Recorded Form

The platform prints the pole object below in its recorded form; it is the object the ignition hypothesis turns on, and it shows the shape all fourteen share: an id, a label, a kind, typed properties including crossarm condition and installation year, a status vocabulary running from inspected to replacement scheduled, and links out to its inspection record, its segment and its scores.

```
{
  "id": "substation",
  "label": "Substation",
  "kind": "site",
  "anchored_in": "Survalent SCADA",
  "properties": [
    "Substation ID",
    "Feeder count",
    "PTZ camera",
    "Cellular coverage state"
  ],
  "status_vocabulary": [],
  "links": [
    {
      "to": "feeder",
      "label": "supplies"
    }
  ]
}
```

PART II · CHAPTER 6

## Every Source Enters Through an Adapter

Twelve source systems feed two adapter families into a Kafka backbone with ordered delivery, store-and-forward buffering and a one-way path from SCADA, so the model stays current without ever writing back to a system of record.

Chapter 5 described the fourteen objects the ontology holds and the typed links that join them. This chapter describes how their data gets in: which twelve sources, through which two adapter families, under what guarantees and over which event backbone.

### 6.1  Twelve Sources, One Provenance Class

Twelve source feeds enter the design, and every one carries the same provenance class: operator-procured, operator-controlled and read-only. Nine are the operational systems the cooperative runs today: Survalent SCADA and ADMS for recloser status, alarms and fault indications across 42 substations and 310 reclosers; the Landis+Gyr AMI head end for 15-minute intervals and last gasp messages from 61,000 meters; ESRI GIS for poles, conductors, transformers and right of way polygons; the outage management system for outage events and member call clusters; NISC iVUE for crews and work orders; the weather services subscription for wind gusts, relative humidity and red flag warnings; the vegetation records of the contractor trimming cycle; the wildfire camera vendor portal for the 12 camera feeds already reaching the operations center; and crew AVL from the 20 patrol trucks. Three more complete the count: the pole inspection spreadsheet with its photos, the mesonet station network behind the wind and humidity readings, and the purchased satellite imagery that complements the trimming records. Figure 5 draws the integration map: each named system, its provenance class and the adapter path it takes into the backbone.

![Figure 5. The 12 named systems, the adapter path each one takes, and the object model they all map into.](figures/figure_05.png)

Figure 5. The 12 named systems, the adapter path each one takes, and the object model they all map into.

### 6.2  What the Adapter Tier Guarantees

The adapter tier makes one promise first: it never writes back. Every interface is read-only, so no adapter can alter a point list, a GIS feature or a work order. On top of that, the two families guarantee five things. They normalise each source's output to the typed vocabulary of the object model, so a fault indication from Survalent and a last gasp from Landis+Gyr arrive as events the ontology can join. They stamp provenance onto every record: source system, interface, direction and time, so an auditor can trace any score back to its inputs. They preserve ordering per asset, so a recloser's open, lockout and close sequence is never reordered. They pass at-least-once with idempotent keys, so replay after a fault duplicates nothing. And they buffer with store-and-forward, so an outage of this platform never back-pressures a system of record. The SCADA path is one-way through a hardware-enforced data diode, so nothing on the platform side can reach the control network, and operational systems are joined through their own vendor interfaces with MultiSpeak and CIM where supported rather than through a parallel queue.

### 6.3  The Event Backbone

The backbone is Apache Kafka 4.3 in KRaft mode, with three dedicated controllers on a dynamic quorum. Partitions are keyed on the GIS asset id, so every event for one pole or one recloser is ordered on one partition and consumed in sequence. Delivery is at-least-once with idempotent consumers; buffering is sized to the worst measured storm and to AMI catch-up after a head-end interruption; and the cluster replicates across three brokers in the operations center, with the sovereign cloud copy held for disaster recovery only. Each service reads in its own consumer group, so storm operations, risk scoring and compliance keep their own pace against the same stream. Time synchronisation holds the stream together: an OCP Time Card GNSS grandmaster speaks PTP to the edge nodes, and chrony serves NTP-only hosts, so a recloser operation, a last gasp message and a camera frame land in the right order on one timeline. The value of that completeness is documented in event investigations: the 2003 blackout report traces the collapse of the operators' situational awareness to an alarm system that failed while events raced ahead of them, and later investigations list alarm floods among the abnormal situations crews cannot manage (Energy 2003; CSB 2022). One ordered, buffered stream is what keeps this design's picture whole when the weather is at its worst.

PART II · CHAPTER 7

## Vision Belongs at the Edge and Reasoning On-Premises

Smoke and equipment detection run on industrial edge boxes where the cameras are, the risk store and language model run on ruggedised servers at the operations center, and the latency budget is written down for what crosses each boundary and what happens when a link drops.

Chapter 6 closed the ingestion path: every source enters through an adapter, lands on the event backbone, and reaches the object model without a direct connection anywhere. This chapter places the compute that turns those events into detections, risk scores and answers, states the memory arithmetic that fixes the central hardware, and writes down the latency budget and the failure behavior for every link, power feed and update path in the design.

### 7.1  Two Tiers and Their Arithmetic

The design runs inference in two tiers, shown together in Figure 6. The edge tier sits where the cameras are: fanless, sealed industrial edge boxes rated for minus 20 to 45 degrees Celsius, dust and hail, mounted in NEMA 3R and 4 enclosures at substations, on patrol trucks and at the yard. Each box runs the detection model against the camera streams through a serving runtime pinned at design from a bench measurement of the actual feeds, orchestrated by K3s, with video ingest and local recording handled by the NVR stack. Smoke plumes, downed or leaning poles, vegetation encroachment and equipment hot spots are detected on the box, because the cellular coverage at substations and patrol areas is intermittent and a storm is exactly when the link drops. Streaming raw video centrally was weighed and set aside for that reason: the storm picture would sit on the wrong side of the weakest link in the system. The central tier sits on ruggedised servers at the operations center. It carries the live distribution model, the risk store and the language model node. The memory arithmetic fixes this hardware. The language model is filed at 753 billion parameters, a mixture-of-experts architecture in which the GPUs hold every weight. At FP8 precision, one byte per parameter, the weights occupy 753 gigabytes; multiplied by 1.2 for the KV cache and activations, the node must hold 904 gigabytes. One server with 8 GPUs of the 141 GB HBM class holds 1,128 gigabytes, which fits the requirement with roughly 224 gigabytes of headroom. Serving the published BF16 weights, about 1.5 terabytes, would need sixteen GPUs of the class; FP8 halves that to eight. The model is served on site by vLLM, and the time series store beside it is sized for 15-minute AMI intervals from 61,000 meters and 310 reclosers with store-and-forward buffering.

![Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.](figures/figure_06.png)

Figure 6. Where each tier runs, what runs there, and the narrow set of outputs that cross the boundary.

### 7.2  The Latency Budget

The budget is written as four tiers, not as a single number, because each tier answers a different question at a different pace. The first tier is outside the system: recloser fast trips execute in protection hardware the platform does not own, and fast decisions stay in that layer by constraint. The second tier is the detection loop, from camera frame to ontology event on the edge box, measured against the real streams before the runtime is pinned, with smoke confirmed temporally across frames rather than on a single image. The third tier is the storm picture: SCADA alarms, AMI last gasp messages and crew AVL positions joined into one live view within the event backbone's ordering guarantees. Grid operators build and maintain their picture of the system under load, and an incomplete or hand-rebuilt picture during an event is a documented cause of worsened outcomes (Energy 2003), so the design keeps that join continuous instead of leaving dispatchers to reconstruct it from separate screens and a phone call (OSTI 2007). The fourth tier is reasoning at human pace: 48-hour ignition and outage scores refreshed on the AMI interval and on weather updates, and work surface answers served from the FP8 node in conversation time. Every tier reports its own measure through the observability stack, so a budget breach is a visible alarm, not a slow drift.

### 7.3  What Crosses the Boundary, and What Fails

What crosses each boundary is small by design. Detection events, risk scores, alarms, AVL positions and last gasp messages move as compact event records; raw video does not cross, because it is analyzed and recorded locally. SCADA reaches the platform as a read-only mirror through a hardware-enforced one-way data diode, so no fault, misconfiguration or compromise on the platform side can write toward control. The only approved write path runs the other direction: a person-approved decision becomes a work order in work management, never a grid command. Each failure mode has a stated behavior. If the link drops, edge inference continues on the box, store-and-forward buffers sized to the worst measured outage hold the evidence, and degraded-mode reporting states plainly that its view is stale rather than presenting old data as current, which keeps alarm load honest in the control room in the way abnormal-situation guidance demands (CSB 2022). If power fails, one UPS covers the edge node and its switch with Network UPS Tools ordering clean shutdowns, and the central tier rides on the operations center's power with sovereign cloud capacity reserved for overflow and recovery only. If the update path fails, nothing breaks open: artifacts and model weights move through the air-gapped registry, signed and scheduled by the operator, and time discipline from the GNSS grandmaster keeps event ordering correct when hosts resynchronize. The design supports the emergency operating plans and public safety power shutoff procedure the operator must already maintain; it does not replace them (NERC n.d.).

PART II · CHAPTER 8

## The License Decides What the Cooperative Owns

GLM 5.2 under MIT and RF-DETR under Apache-2.0 let the cooperative hold its own weights on one FP8 node, which is exactly why the bespoke-licensed alternative and cloud-hosted options were set aside.

Chapter 7 fixed where inference runs and how much memory it needs. This chapter names the two models that run there, states their sizes, architectures, licenses and terms, and explains why the license, more than any benchmark, decided which language model the work surface carries.

![Figure 7. The two models, their placement, and the work each one does.](figures/figure_07.png)

Figure 7. The two models, their placement, and the work each one does.

### 8.1  The Model Stack and Why MIT Won

Figure 7 shows the model stack: one central language model, one edge detection model, and the runtime and hardware classes beneath them. The central model is GLM 5.2, a frontier mixture-of-experts language model filed at 753 billion parameters and published at BF16 at about 1.5 terabytes of weights. Its role is the agentic work surface and ontology maintenance: the four distribution engineers, the six system operators and the dispatch supervisor, the vegetation management coordinator, the reliability engineer and the emergency management coordinator ask what changed on a feeder, build and run their own agents, and write approved decisions back to work management through it. It runs on the single 8-GPU node of the 141 GB HBM class at the operations center, served at FP8 by vLLM, as the arithmetic in Chapter 7 shows. Its license is MIT, with no field-of-use restriction, no revenue trigger and no regional limit, so the cooperative holds its own weights outright. The newer GLM 5.3 was weighed and set aside for one reason: its bespoke managed-service license does not give the operator that ownership, and ownership of the weights is the point of running the model on the cooperative's own hardware.

### 8.2  Detection at the Edge

The edge model is RF-DETR, a real-time detection transformer released under Apache-2.0 for both the code and the Nano to Large checkpoints, with no field-of-use restriction. The checkpoints run from about 61 to 68 megabytes at 16-bit precision, with the 2XL variant at about 254 megabytes, which is what makes the model practical on the industrial edge box class. It detects smoke plumes, downed or leaning poles, vegetation encroachment, equipment hot spots, crew trucks and recloser cabinets across the 42 existing substation PTZ cameras, the 12 wildfire camera feeds, the patrol truck forward cameras and the drone thermal camera. It is placed on the edge boxes through the serving runtime pinned at design, and it is fine-tuned on the cooperative's own fire-season frames, with labeling in CVAT and Label Studio so the fine-tune improves as the seasons accumulate. Both models were chosen on the same test: the license must permit the operator to hold and fine-tune the weights on hardware it owns, inside its own boundary, with no cloud dependency in a storm.

### 8.3  The Model and Equipment Register

Table 4 gathers the models, the hardware classes and sizing rules, the sensing, the patterns and the ground into one register, so every choice in the stack points at the reason it was made.

Table 4 · Model and Equipment Register

| The choice | What was picked | Why here |
| --- | --- | --- |
| Language model | GLM 5.2, mixture-of-experts, 753 billion parameters filed, FP8, MIT license | Agentic reasoning over the ontology with weights the cooperative owns; one 8-GPU FP8 node holds it |
| Detection model | RF-DETR, Nano to Large checkpoints at 61 to 68 MB and 2XL at about 254 MB, BF16, Apache-2.0 | Smoke, pole, vegetation and equipment detection on the edge box class, fine-tuned on the cooperative's own fire-season frames |
| Edge compute class | Industrial edge accelerator modules, fanless and sealed, NEMA 3R/4 enclosures | Sized decode-first from the actual camera streams, rated for dust, heat, hail and cold |
| Site inference server | Ruggedised server class at the operations center, one node of 8 GPUs of the 141 GB HBM class | 1,128 GB against a 904 GB requirement, sized from filed parameters at FP8 |
| Serving runtimes | vLLM on site; Triton Inference Server, ONNX Runtime or OpenVINO class at the edge | The edge runtime is pinned at design against a bench measurement of the real streams |
| Sizing rules | Size edge compute from streams; when thermal beats visible; reuse existing cameras or not; size GPUs from filed parameters | Every hardware choice derives from a measured duty rather than a vendor default |
| Sensing | 42 substation PTZ cameras, 12 wildfire camera feeds, truck and drone cameras, mesonet wind and humidity, 310 recloser fault indicators, AMI last gasp from 61,000 meters, crew AVL on 20 trucks | Reused through the reuse gates; new fixed thermal only where a coverage gap is proven |
| Patterns | System of context; adapters-only ingestion; read-only systems of record; human-approved write-back; one-way diode for SCADA | Keeps the grid protected and the systems of record authoritative while the platform joins them |
| Ground | Cooperative servers at the operations center as primary; sovereign cloud for overflow and recovery only | The model must survive an internet outage during a storm, and the risk picture cannot live outside the boundary |

PART III · CHAPTER 9

## Shadow Mode Comes Before Any Flag Is Trusted

Two phases, seven items and an eight-week proof gate put the ten highest-risk feeders into the ontology and shadow every risk flag against the outage record before anyone acts on it.

Chapter 8 fixed the models, the licenses and the hardware classes the design stands on. This chapter fixes the order the work lands in, the gates that can stop it cheaply, and what the rollout measures before any risk flag is allowed to influence a decision.

### 9.1  Two Phases, Seven Items, One Proof Gate

The rollout runs in two phases, tracked with their workstreams and requirement coverage in Figure 8. Phase 1, the eight-week proof, carries seven items across four workstreams: compliance and records, ignition and outage risk, live distribution model, and storm operations. Its exit gate is the binding of the ten highest-risk feeders' GIS backbone into the ontology, with Survalent SCADA mirrored through the one-way path, Landis+Gyr AMI intervals and last gasp messages landed in the risk store, and the first feeder-level ignition and outage scores running in shadow against the outage record. Phase 2, scale and write-back, carries eight items across five workstreams: engineer work surface and agents, field and edge infrastructure, ignition and outage risk, storm operations, and vision and thermal detection. It exits when the first fast trip and de-energization candidates reach a named operator for approval, substation and wildfire camera feeds are watched at the edge, and drone and truck footage is analyzed at the yard, with every flag still shadowed until its agreement with the outage record is demonstrated. Requirement coverage stands at five requirements covered, none partial and none uncovered, and Figure 8 carries the mapping per requirement so the executive sponsor can see which item closes which requirement. No phase carries a duration beyond the named proof clock; each closes on its gate or it does not close.

![Figure 8. The two phases and their gates, and coverage of the 5 requirements across them.](figures/figure_08.png)

Figure 8. The two phases and their gates, and coverage of the 5 requirements across them.

### 9.2  What the Rollout Measures

The shadow period measures five things. First, agreement: the share of feeder segments flagged at a given score that later appear in the outage record as events, which is the only honest test of a risk flag. Second, calibration: whether the scored intervals cover the observed event rate, reported as calibrated intervals rather than point scores. Third, latency: the time from a last gasp message to its appearance on the storm picture, and from a recloser fault indication to dispatcher awareness. Fourth, detection precision on the cooperative's own held-out frames, because vendor benchmark numbers do not transfer to Panhandle dust, haze and hail-damaged imagery. Fifth, staleness in degraded mode: every view states how old its evidence is when the link is down, so an operator never mistakes a buffered picture for a live one. The extreme-event regime is evaluated separately from the seasonal baseline, because the errors that matter during a red flag warning are not the errors of an average day.

### 9.3  Failure Modes

Table 5 sets each failure mode against what the design does about it.

Table 5 · Failure Modes

| What fails | What the design does |
| --- | --- |
| Access delays consume the proof clock, since the eight-week period starts at signature and includes building the SCADA, AMI, GIS and inspection connections | Data access granted on day one; point list and export owners named in week one; risk store sequenced before the vision tier |
| Old inspection photos are sparse and low quality, with only 18 percent of poles carrying recent imagery, so defect detection may not reach usable accuracy | Accuracy probe on a few hundred real frames before scope is committed; annotation effort priced as its own line item |
| Intermittent cellular coverage silently drops detection evidence at the moments that matter | Store-and-forward buffers sized to the worst measured outage; edge inference survives link loss; degraded-mode reporting states its own staleness |
| Outage prediction error is dominated by weather forecast uncertainty at 48 hours | Error budget decomposed between forecast and model; calibrated intervals reported instead of point scores; extreme-event regime evaluated separately |
| A detection program is scoped as if it were a mitigation program and overpromises against the regulatory record | Detection and mitigation kept separate in scope and in the wildfire plan evidence; cameras sited in overlapping pairs where triangulation is wanted |
| The North American reliability boundary is assumed instead of determined | Zone and conduit diagram drawn in week one; read-only access through the one-way path; the compliance function's categorization decides what touches what |

### 9.4  Lessons

**Shadow the flags before anyone trusts them.** A risk flag that has never been scored against the outage record is an opinion with a number attached. The shadow period converts it into evidence, and it costs nothing but patience: the same scores run, nobody acts on them, and the disagreement between flag and event becomes the calibration dataset for phase 2. Rank the alarms; never flood them. Documented investigations of industrial disasters show that alarm floods degrade operator response exactly when response matters most (CSB 2022), and grid control room studies show that operators maintain their picture by actively sampling a few trusted signals, not by reading everything (OSTI 2007). The storm picture therefore ranks and joins rather than streams every alarm, and the dispatch desk sees the ten feeders that changed, not the 310 reclosers that did not. Write the record at the moment of decision. Reporting on the Texas grid failure found that paperwork failures forced a mid-storm scramble to restore critical fuel supply, because the record did not match the event (TPR 2021). The PSPS decision record and the work order approval trail are written as the decision happens, by the person making it, so the next storm reads a current picture.

### 9.5  What Is Still Open

Four questions remain open. The edge serving runtime is pinned only after a bench measurement of the actual camera streams, and the zero-shot probabilistic baseline for the 48-hour ignition and outage scores is still to be chosen; settling both fixes the edge box class and removes the last sizing contingency. The placement of any new fixed thermal cameras waits on the six reuse gates over the existing 42 PTZ, 12 wildfire, truck and drone feeds; settling it determines whether the thermal tier is bought at all. The North American reliability scope determination sits with the cooperative's compliance function; settling it decides which components inherit hardening requirements. And the deliverable precision at the 48-hour lead time waits on the shadow calibration; settling it determines whether the forecast horizon is stated as scored intervals or shortened.

PART III · CHAPTER 10

## The Intelligence Should Stay with the Cooperative That Produced It

The object model, the weights, the decision records and the boundary itself belong to the cooperative, because a risk picture paid for by its members should not live in someone else's cloud.

Chapter 9 showed that the rollout can stop cheaply at its first gate. This chapter settles who holds what the design builds once the gates pass, because ownership decides whether the risk picture outlives any single vendor relationship.

### 10.1  What the Cooperative Owns

The object model belongs to the cooperative. The fourteen objects, their typed links and the instance running on its own servers are its schema and its data, and the design never edits the ESRI GIS that anchors them: every score points at a GIS identifier, and the systems of record stay authoritative. The weights belong to the cooperative as well. GLM 5.2 carries a plain MIT license with no field-of-use restriction, no revenue trigger and no regional limit, so the cooperative holds the weights outright; the RF-DETR checkpoints are Apache-2.0, and the fine-tunes trained on the cooperative's own fire-season frames are its property. The decision record is kept by the cooperative: every PSPS decision with its recommendation, approving operator, rationale and notification reference, every work order approval trail, and the audit record behind the monthly risk view, so the next decision reads the last one. The boundary itself is the cooperative's: the one-way data diode path, the zone and conduit diagram, and identity under its own control, with the sovereign US cloud carrying overflow and disaster recovery only and no system of record.

### 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: the cameras, recloser fault indicators, AMI last gasp messages and the 48-hour ignition and outage scores. Decision Systems is the ranking and recommendation layer where a named operator approves every fast trip and de-energization. Hyper Ontology is the fourteen-object model that binds the twelve source systems into one picture. Hyper Pragma is the work surface where the distribution engineers, system operators, dispatch supervisor, vegetation management coordinator, reliability engineer and emergency management coordinator build and run their own agents. Hyper Engram is the kept record of PSPS decisions and outcomes that the next decision reads. Sovereign Infrastructure is the posture underneath: open-weight licenses and the cooperative's own hardware at its operations center. Praxis is the platform on which every choice in this paper was recorded as it was made.

PART IV · CONCLUSION

## The Risk Picture Should Be Owned Where the Risk Lives

In one view, the design is an ontology layered over the systems of record the cooperative already runs, fed read-only by twelve sources, scored 48 hours ahead by services the cooperative owns, watched at the edge by cameras and detectors it already had, and argued with daily by the engineers and dispatchers who hold the de-energisation pen. Nothing is retired, nothing leaves the boundary except through a one-way path, and every fast trip and shutdown stays a human decision with a recorded rationale.

Running the same shape elsewhere takes four things the cooperative already has in some form: an authoritative GIS backbone to anchor every score, telemetry from protective devices and meters to say where the grid is stressed, a visual tier that can be reused rather than replaced, and a person whose decision the record exists to serve. Change the feeders for feeders, the wind for the wind, and the pattern holds: bind the records into one object model, keep detection where the cameras are, keep reasoning where the operator is, and let the license keep the weights at home.

PART IV · CHAPTER 11

## How Praxis Contextualized and Reasoned This Design

Every choice in this design was recorded on Praxis as it was made, and this chapter lets any reader trace a decision back to the records in the room and the eight lenses that tested it.

Chapter 10 established that the cooperative holds the model, the weights and the record. This last chapter turns inward and shows how the design itself was reasoned, so any reader can trace a choice back to what justified it. Every design in this series is produced on Praxis, and this chapter is the trace: the ask as it was understood, the records that were in the room, the eight lenses that tested the reasoning, and the patterns adopted or set aside. Figure 9 shows the path from ask to equipment in one view.

### 11.1  Contextualizing the Ask

The ask, in the operator's own terms, was one live distribution risk model joining feeders, poles, reclosers, substations, vegetation, weather and crews; cameras feeding it; early warnings by feeder; and a work surface where engineers and dispatchers ask their own questions instead of waiting for a report. Praxis assigned it to the energy and utilities industry and to the operations-intelligence family of physical AI designs: a situation picture and a risk forecast over assets the operator already owns. What was in the room, listed as records read in full and available on request: the SCADA point and alarm lists for the 42 substations and 310 reclosers, the AMI head end export specification covering 61,000 meters, the GIS layer catalog with poles, conductors, transformers and right-of-way polygons, the pole inspection spreadsheet, the vegetation contractor cycle records, the wildfire camera feed inventory, the OMS cause-code history, the work order and crew structure in iVUE, and the weather and mesonet subscription terms.

![Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.](figures/figure_09.png)

Figure 9. From the ask to the design: the family and industry Praxis assigned, the eight lenses and what each cited, the patterns adopted and set aside, and the equipment the design lands on.

### 11.2  The Eight Lenses

Table 6 records each lens, what it could see, what it cited and what it contributed. A lens that returned nothing would be shown as a gap; none did.

Table 6 · The Lenses and What They Contributed

| Lens | Could see | Cited | What it contributed |
| --- | --- | --- | --- |
| First principles | The grid's own chain from asset to alert to work order | 1 | The ontology pattern, the SCADA safety-segregation and audit-trail pitfalls, and the rule that fast decisions stay in the protection layer the design does not own |
| Case studies | Prior camera, inspection and outage prediction programs at other utilities | 3 | The annotation pricing and accuracy probe on old imagery from the Dominion precedent and the overlapping-pair camera siting from the Xcel precedent, with nine records in the room |
| Tooling and recency | The current state of streaming, serving, registry and edge tooling | The stack record | Apache Kafka 4.3 KRaft, the object model v0.9, Frigate NVR with MediaMTX, vLLM, K3s, Harbor with MLflow, CVAT with Label Studio, Keycloak, and Prometheus with Grafana and Loki |
| Hardware and equipment | Edge and site compute classes, cameras, enclosures, timing | The equipment register | The industrial edge box class sized from measured streams, the ruggedized site server class, NEMA 3R/4 enclosures, the GNSS grandmaster and the hardware data diode |
| Rules and regulations | PUCT rules, post-2024 wildfire mitigation guidance, thermal export rules | (NERC n.d.) | De-energization kept human under the PSPS procedure, detection kept separate from mitigation in the evidence, and the confirmation that fixed thermal on the cooperative's own premises needs no federal license |
| Approach | How to structure the build itself | The scoping record | The adapter-only ingestion rule, the shadow-first rollout and the two-phase gate structure with requirement coverage |
| History | How grid failures have run through paperwork and lost pictures before | 2 | The live storm picture and the at-decision-time record, grounded in the documented cost of stale paperwork and lost situation assessment (Energy 2003; TPR 2021) |
| Domain fusion | What wildfire detection and control-room human factors each contribute | 1 | The join of the fire-season detection tier to the dispatch picture, where alarm floods and degraded awareness are documented failure modes (CSB 2022; OSTI 2007) |

### 11.3  Patterns Adopted and Set Aside

Praxis recorded four patterns as adopted: the asset-to-alert-to-work-order ontology as the spine of the object model; read-only SCADA mirroring through the one-way path; edge analysis with buffered synchronization, matching the intermittent cellular reality; and a purpose-built risk store keyed to GIS identifiers. Three were set aside with reasons on the record: streaming video centrally, because the links cannot be trusted during the events that matter; the object tracking and trajectory forecasting layer, because detections are static assets and temporally confirmed smoke and crew positions already arrive from AVL; and the newer GLM 5.3 under its bespoke license, because its terms would put the work surface's weights outside the cooperative's ownership where GLM 5.2 under MIT keeps them inside.

### 11.4  Where the Reasoning Lands

The reasoning lands on equipment classes, not part numbers: Edge Accelerator Classes for the sealed edge boxes, Size Edge Compute From Streams as the sizing rule, When Thermal Beats Visible for the camera gap analysis, and Reuse Existing CCTV Or Not governing the six reuse gates over the existing feeds. At the center the arithmetic closes: 753 billion filed parameters at FP8 give 753 GB of weights, 904 GB with KV cache and activations at a factor of 1.2, and one node of eight GPUs at 141 GB each holds it with 1,128 GB. Every figure in this paper was recorded on Praxis as it was read or decided. Nothing is inferred; anything not in the record is marked open.

Appendix A

## What Ownership Costs Over Three Years

*Version 2, 5 October 2026. Version 1 compared ownership with AWS's three-year EC2 Instance Savings Plan at the no upfront rate (27.34 dollars an hour) and printed "about four fifths"; the deepest three-year plan in the region, all upfront at 23.80, makes ownership about the same cost as renting. Every other number is unchanged.*

The design runs on the operator's own hardware. This appendix prices that choice against the two ways an operator in the United States could otherwise get the same capability: renting the same accelerators from a cloud region, or buying a closed frontier model by the token. Every input is a public price, dated and cited. The arithmetic is shown so any reader can rerun it with a written quote. The operator in this design is an illustrative scenario, so the user count and the edge allowance below are assumptions, stated where they are used.

### A.1 The Answer

Owning the stack this design specifies costs about **841,000 US dollars over three years**, inside a range of 741,000 to 946,000. Renting the same capacity around the clock costs **0.88 million to 1.92 million dollars** over the same period. Against the cheapest three-year commitment listed (AWS, three-year EC2 Instance Savings Plan, all upfront), ownership costs **about the same**. Every rented option here can stay inside the United States, so for a US operator the case for ownership is cost, control and a site that keeps working when the link drops, not residency.

### A.2 What Owning Costs

| Line | Basis | Three-year cost (USD) |
| --- | --- | --- |
| Frontier tier | One server of eight 141 GB HBM-class cards, 320,000 to 420,000 dollars, typical 370,000 (Mercatus 2026) | 320,000 to 420,000 |
| Edge | An allowance of 63 fanless industrial edge nodes, one at each of the paper's more than 40 substations, one on each of its about 20 patrol trucks and one at the yard at 4,000 dollars each (Eurotech 2026) | 252,000 |
| Support | 8 to 12 percent of hardware value a year (Introl 2026) | 137,000 to 242,000 |
| Power | 10.8 kW average IT load at a power usage effectiveness of 1.6 (Uptime Institute 2025), 453,277 kWh at the Texas industrial average of 7.07 cents per kWh in July 2026 (EIA 2026) | 32,000 |
| **Total** |  | **741,000 to 946,000, typical 841,000** |

The average load assumes the frontier server draws 7 kW of its 10.2 kW maximum (NVIDIA 2026) and each edge node 60 W. The frontier tier fits one node because GLM 5.2 is 753 GB at FP8 and needs 904 GB with headroom, against 1,128 GB on eight 141 GB cards.

### A.3 What Renting Costs

The same frontier server, rented without a break for three years, because wildfire risk does not stop at night and a storm is when the picture matters most. The edge nodes stay on site in every option and are included in each total.

| Option | Basis | Three-year cost (USD) |
| --- | --- | --- |
| AWS, us-east-1, on demand | p5en.48xlarge at 63.296 dollars an hour (Vantage 2026) | 1.92 million |
| AWS, three-year EC2 Instance Savings Plan, all upfront | p5en.48xlarge at 23.80 dollars an hour, all upfront, the deepest three-year plan in us-east-1 (AWS 2026) | 0.88 million |
| Azure, three-year reservation | ND96isr H200 v5 at 1,109,592 dollars for three years in East US 2, about 42.22 an hour (Azure 2026) | 1.36 million |
| Specialist GPU cloud, on demand | 50.44 dollars an hour for eight H200 cards (CoreWeave 2026) | 1.58 million |
| Oracle, three-year commitment | 40 dollars an hour for eight H200 cards (Economize 2026) | 1.30 million |

Egress, storage and support plans are excluded, so every rented figure is a floor. Spot capacity is excluded because a service that must run through a storm or a shift cannot be evicted.

### A.4 What Closed Models Cost by the Token

A closed frontier model replaces the frontier tier rather than the whole stack, and it is priced by use. At 30 users (an assumed count across the dispatchers, distribution engineers and vegetation coordinators the paper names), each running the equivalent of five agents at 2.4 billion tokens a year, with four input tokens to every output token and half the input served from cache, three years is 216 billion tokens.

| Model | List price per million tokens, input and output | Three-year cost (USD) |
| --- | --- | --- |
| Claude Sonnet 5.5 | 2 and 10 (Anthropic 2026) | 0.62 million |
| Gemini 3.1 Pro | 2 and 12 (Google 2026) | 0.71 million |
| Claude Opus 5.5 | 4 and 20 (Anthropic 2026) | 1.24 million |
| GPT-5.5 | 5 and 30 (OpenAI 2026) | 1.77 million |

The cheapest closed model costs about 21,000 dollars per user over three years, so it matches the whole owned stack at about **41 users**. Below that, renting a closed model by the token is cheaper; above it, ownership is, and the gap widens linearly with users while the owned cost stays flat. Every closed option also sends grid telemetry, member meter data and de-energisation decisions to a third-party AI service outside the boundary, which the design's constraints rule out.

### A.5 What the Price Does Not Include

- **Cameras, enclosures and installation** at substations and on trucks; the edge line prices the compute only.
- **The edge count.** It is the largest cost line this design controls: 63 nodes is one per place the paper puts a box, and a bench measurement on the real camera streams may let several sites share one node.
- **Sales tax, freight and installation** on the hardware, which a written quote settles.
- **An export licence** does not apply: the hardware stays inside the United States.
- **People, facilities and implementation**, which both sides carry.
- **Price movement.** Cloud prices rose as well as fell in 2026; AWS raised its H200 capacity block price about 15 percent in January (Gigazine 2026).

### A.6 Sources for This Appendix

- AWS. 2026. Compute and EC2 Instance Savings Plans price file, us-east-1, 3 October 2026. <https://pricing.us-east-1.amazonaws.com/savingsPlan/v1.0/aws/AWSComputeSavingsPlan/current/region_index.json>
- Anthropic. 2026. Pricing. <https://claude.com/pricing>
- Azure. 2026. Retail prices, Standard\_ND96isr\_H200\_v5. <https://prices.azure.com/api/retail/prices>
- CoreWeave. 2026. Pricing. <https://www.coreweave.com/pricing>
- EIA. 2026. Electric Power Monthly, Table 5.6.A, July 2026. <https://www.eia.gov/electricity/monthly/epm_table_grapher.php?t=epmt_5_6_a>
- Economize. 2026. OCI BM.GPU.H200.8 pricing. <https://www.economize.cloud>
- Eurotech. 2026. ReliaCOR 33-11. <https://buy.eurotech.com/products/reliacor-33-11>
- Gigazine. 2026. AWS raises EC2 Capacity Blocks prices. <https://gigazine.net>
- Google. 2026. Gemini API pricing. <https://ai.google.dev/gemini-api/docs/pricing>
- Introl. 2026. GPU infrastructure TCO model. <https://introl.com/blog/gpu-infrastructure-tco-model-5-year-enterprise-ai-deployment>
- Mercatus. 2026. H200 server price. <https://mercatus-ai.com/blog/h200-server-price>
- NVIDIA. 2026. DGX H200. <https://www.nvidia.com/en-us/data-center/dgx-h200/>
- OpenAI. 2026. API pricing. <https://developers.openai.com/api/docs/pricing>
- Uptime Institute. 2025. Global Data Center Survey 2025. <https://uptimeinstitute.com>
- Vantage. 2026. EC2 instance prices. <https://instances.vantage.sh>

SOURCES

## Source Register

Energy. 2003. PDF Final Report on the August 14, 2003 Blackout in the United .... <https://www.energy.gov/sites/prod/files/oeprod/DocumentsandMedia/BlackoutFinal-Web.pdf>

OSTI. 2007. . <https://www.osti.gov/servlets/purl/935904>

CSB. 2022. Investigation Report. <https://www.csb.gov/assets/1/6/final%5Freport%5F-%5F20241.pdf>

TPR. 2021. Paperwork Failures Worsened Texas Blackouts, Sparking Mid-storm Scramble To Restore Critical Fuel Supply TPR. <https://www.tpr.org/texas/2021-03-21/paperwork-failures-worsened-texas-blackouts-sparking-mid-storm-scramble-to-restore-critical-fuel-supply>

NERC. n.d.. EOP-011 to 4. <https://www.nerc.com/globalassets/standards/reliability-standards/eop/eop-011-4.pdf>

---

### About CodeNinja

CodeNinja is a Middle Eastern-American artificial intelligence lab focused on building self-improving systems. We are reinventing knowledge work to close the loop between vertical AI use cases and the generalized intelligence that fuels it, accelerating the path toward organizational superintelligence.