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://muhammadumar89.github.io/codeninja-research/steel-production-count-pakistan/. The operator is described by class, never by name.
A revenue authority in Pakistan wants to know how much steel every melting and re-rolling mill actually produced in a filing period, not what the mill declared. Today it cannot: counts live in mill paperwork, weighbridge tickets and filings that never meet. The requirement is a counting system at every mill, in cumulative coverage bands, with a proof of concept whose accuracy is tested against the weighbridge before wider rollout.
Here is how that turns into a system the authority owns.
1. Count where the product is made
Each installation point, a casting strand or cooling bed, gets IP66 HDR cameras and one sealed, GPU-accelerated industrial PC. RF-DETR, fine-tuned per product type and per mill, detects billets, ingots, rebars and girders; a ByteTrack-class tracker holds identity across frames so one billet crossing two camera fields counts once. Detection and tracking run on the industrial PC under MicroShift and Triton, so counting survives a slow wide-area link.
Counts leave the mill through a one-way link into one operator-owned production record. The mill never edits a count.
2. Join first, model second
The record holds fourteen typed objects: steel melting and re-rolling unit, installation point, industrial PC, production count event, product type, declared production, discrepancy case, revenue field officer, audit team, steel mill staff, tamper or offline alert, daily uptime record, product calibration record and weighbridge record.
From one count event a traversal reaches the product type it classifies, the calibration record that validates the detector version, the weighbridge record that measured that calibration's accuracy, the installation point and mill, the declared production for the same period, and the officer who owns any discrepancy. That is what makes a count evidence that survives an audit.
The object model ships as JSON (ontology/objects.json, format hyper-ontology/1).
3. Size the frontier node from the weights, and place it where the licence holds
weights = 753B parameters x 1 byte (FP8) = 753 GB
need = 753 GB x 1.2 (KV cache, activations) = 904 GB
node = 8 x 141 GB = 1,128 GB -> one node
GLM 5.3 serves the compliance work surface from one node of eight 141 GB HBM-class GPUs. That GPU class is export controlled for Pakistan, so the node runs in a dedicated data center behind a licensing checkpoint, and the design refuses to silently swap in a smaller model that would change what the work surface can reason over.
4. Pick models by licence
| Role | Model | Licence |
|---|---|---|
| Detection | RF-DETR, Nano to Large checkpoints, fine-tuned per mill | Apache-2.0 |
| Tracking | Roboflow trackers, OC-SORT and ByteTrack class | Apache-2.0 |
| Compliance work surface | GLM 5.3, 753B mixture of experts at FP8 | bespoke; commercial use, fine-tuning and redistribution permitted |
5. Keep a person on every discrepancy
The system counts and reconciles; it never assesses. A discrepancy case is opened against declared production and assigned to a named revenue field officer, with the audit team handling escalations. Tamper and offline alerts and a daily uptime record say whether the counting estate itself was honest and awake.
6. What it costs
Owning the stack for three years comes to about 4,445,000 US dollars for 300 installation points, an assumed count for the paper's "hundreds of mills". The counting kits are 2,832,000 of that and cannot be rented. The one line a cloud can replace is the frontier node: owning it costs about 686,000 dollars against 751,000 on AWS's deepest three-year plan in the nearest region, about the same money, except that renting moves every mill's counted record outside Pakistan. A closed frontier model by the token matches the owned node at about 33 users. Every price is cited in the paper's Appendix A.
Full design, figures, Appendix A with every price cited, and the object model: the paper.
Designed on Praxis, CodeNinja's platform for designing physical AI systems. The object model imports into Hyper Ontology, which turns it into a living system. Load it yourself with the open hyper-ontology loader.
Top comments (0)