# System design for physical AI: one ontology from tag to pump to permit limit

> Source: <https://dev.to/umar_bilal_fd6e1f54398cec/system-design-for-physical-ai-one-ontology-from-tag-to-pump-to-permit-limit-1kpm>
> Published: 2026-11-06 02:39:43+00:00

*By Muhammad Umar. This is the engineering summary of an open reference architecture. The paper, its object model as JSON and the model register are free to reuse under CC BY 4.0: [https://codeatoms.ai/water-utility-ontology-us/](https://codeatoms.ai/water-utility-ontology-us/). DOI [10.5281/zenodo.23889772](https://doi.org/10.5281/zenodo.23889772). The operator is described by class, never by name.*

A municipal water utility in the United States is in the middle of a control system migration. When the duty pump at a station trips at two in the morning, the operator on shift needs to know which tag tripped, which physical pump it belongs to, which zone that pump feeds, how long the reservoir covers zone demand, what the last work orders on the pump found, and which permit limits sit on the zone. The historian holds the tag and the alarm, the CMMS holds the asset number and the work order, the GIS holds the pipe and the zone, the LIMS holds the sample and the permit files hold the limit. Today the answer is a phone call to the person who remembers which tag is which, and those people are retiring before the cutover.

The ontology reads the control network and never sends a control command. The historian is read only through a mirror in a demilitarized zone, carried across a hardware enforced data diode by Lidi, so read only is a physical property of the link. A DMZ feed held by firewall rules alone was set aside, because configuration drifts and can be misconfigured into a write. The platform holds no credentials in the control network and no write path toward any system of record. Agents draft only: there is no write back to the CMMS or the permit records in phase one, set against the sector's usual pattern of writing work orders back, so the named approver acts in the system of record and the single write path ends at a confirmation record in memory.

Six sources feed the design: the historian, the CMMS, the GIS, the LIMS, the permit records, and condition sensing (permanent vibration on pump and motor frames and motor current at the starter panels, with reservoir level and discharge pressure from existing instrumentation). Three adapter families carry them, all built on the Open62541 OPC UA stack with read only credentials: the ops systems adapter for the historian mirror, the integration adapter for the CMMS, GIS, LIMS and permit records, and the telemetry adapter for the sensing channels. Every fact enters stamped with its source system, its extraction method and its timestamp. Because the target historian is not yet selected, a dual tag namespace bridge holds the legacy and new namespaces at once, and the connectors are typed extractors re-confirmed against the chosen historian before cutover.

Apache Kafka 4.4, self managed in KRaft mode, keys events by tag and asset identifier and delivers at least once with idempotent upserts into the object model. The mirror buffers without pushing back pressure toward the source, the platform raises a staleness alarm at 15 minutes, and the command center drops into an explicit degraded mode while the raw alarms stand alone. Linuxptp with chrony, fed by an OCP Time Card grandmaster, puts alarm timestamps, lab result dates and work order dates on one clock. The graph lives in Hyper Ontology, time series in InfluxDB 3 Core.

The object model holds sixteen objects with fourteen typed links: treatment plant, well, distribution reservoir, pump station, lift station and pressure zone; pump, pipe segment, PLC and RTU; tag and alarm; work order, sampling point, lab result and permit limit. One query walks the night trip: the alarm is raised on a tag, the tag maps to a pump, the pump runs at a station, the station feeds a zone, the zone draws on a reservoir whose time to drain says how long the operator has, and the pump carries an open work order. A tag moves from Unmapped through Proposed to Confirmed only by the engineer, which is what lets a migration cut over on mappings someone has checked.

All reasoning runs in one tier, a single node in the utility's own server room; nothing computes at a station or a well, and the anomaly work on vibration and current is CPU class on the same server. gpt-oss-120b files 117 billion parameters. At half a byte per parameter that is 58.4 GB of weights, and the 1.2 planning factor brings the requirement to 70.1 GB. Two cards of the 48 GB PCIe class give 96 GB, about 88 GB usable, leaving roughly 38 GB beside the weights against the 12 GB the factor reserves, and the class air cools in a standard rack. vLLM serves it under RKE2, with an offline Harbor install for updates and Keycloak for identity. gpt-oss-120b was chosen over the GLM 5.3 class because the buyer is US state and local critical infrastructure and the maker of GLM sits on the US Entity List. Nomic Embed Text v2 MoE (475 million parameters, about 0.95 GB at fp16) handles retrieval for cited answers, chosen over BGE-M3 for origin. Both are Apache-2.0.

The tag mapping agent proposes a mapping for the engineer to confirm, the alarm context agent assembles a pack for the operator on shift, and the compliance agent drafts monthly permit report data for the compliance manager to approve before any figure leaves the room. Nothing is trained; every confirmed mapping and resolved alarm is kept and read before the next proposal. A monthly sampled audit of confirmed mappings logs the error rate, so the queue cannot become a rubber stamp, and no seal claim is made for the vibration channel, because discharge pressure carries that failure mode.

Appendix A prices the server at about 59,000 US dollars to own over three years (57,000 to 61,000), with power at the United States average commercial tariff. Renting the same card class on the deepest three year commitment in AWS US East is about 104,000, so ownership costs a little under three fifths of it, though that instance carries four cards where the design sizes two. The lowest priced rented instance that holds the model, one 96 GB card of a different class, is about 33,000, against which ownership costs about 1.8 times as much. The choice rests on the room, not the rent: every rented option would carry tag values, alarms, work orders and permit records outside the utility's boundary.

The rollout is three gated phases and 16 scope items (5, 7, then 4) on one treatment plant and its distribution zone during the migration, held to the utility's own four baselines before the estate follows. The first gate is the tag mapping agent producing proposals with evidence the engineer can check against the source systems.

Made with CodeNinja Praxis, the CodeNinja Atoms platform for designing physical AI systems. The object model imports into Hyper Ontology. Paper, ontology and register: [https://codeatoms.ai/water-utility-ontology-us/](https://codeatoms.ai/water-utility-ontology-us/)

One of the CodeNinja Atoms worked examples of [physical AI system design](https://codeatoms.ai/physical-ai-system-design/): systems that sense an operation, reason over typed objects and act through a named person, published with their object models as hyper-ontology/1 JSON under CC BY 4.0.
