DEV Community

Umar Bilal
Umar Bilal

Posted on Originally published at codeatoms.ai

The Model Register Across Sixteen Designs

Originally published on the CodeNinja Atoms engineering blog.

A model register is the part of a system design that names every learned component the operation will run, with its licence, its size and the reason it was chosen over the alternatives. Sixteen open reference architectures on this site carry one, and every row of every register is in the public dataset as models.jsonl. This note lines them up.

Two things stand out before the table. Four of the sixteen designs have an empty register, and in each case the emptiness is a decision the paper defends rather than a gap. And no design holds a model under a licence with a field of use restriction, a revenue trigger or a copyleft clause that would reach the operator's own code. Weight ownership is the rule the whole corpus runs on.

The reasoning models

Five designs put a frontier class open weight model behind a work surface for the operation's own people and agents. All five chose a GLM model from the same family, self hosted at FP8 on one node of eight 141 GB HBM class GPUs, and the register says why in licence terms.

Model Licence Designs that chose it The reason the register gives
GLM 5.3, 753B mixture of experts, FP8 Bespoke licence permitting internal commercial use with attribution and no revenue trigger Sovereign HSE Watch, Steel Count Ledger, Terminal Pulse Strongest open agentic model; purely internal use is exempt from the model as a service security review trigger; 904 GB of weights against one node of 1,128 GB leaves KV headroom
GLM 5.2, 753B, FP8, 1M context MIT Grid Context Watch, Feeder Firewatch A plain MIT licence with no revenue trigger or security review clause; one node holds it

The split is not an accident. Where the operator wanted the strongest agentic behaviour, the design accepted a bespoke licence whose internal use carve out it had read. Where the operator was a utility or a cooperative with an auditor behind it, the design took the one generation older model under MIT and gave up nothing it needed.

The detectors and trackers

Among the designs that watch with cameras, five chose the same detector.

Model Licence Designs that chose it The reason the register gives
RF-DETR, Nano to Large checkpoints, BF16, about 61 to 68 MB at 16 bit Apache 2.0 Sovereign HSE Watch, Steel Count Ledger, Feeder Firewatch, Terminal Pulse, Fodder Watch The practical sovereign answer to the AGPL gate; fine tuned on the operator's own footage; the operator owns and hardens the weights. Two designs exclude the XL and 2XL checkpoints because they sit under a platform licence whose field of use terms would compromise weight ownership
D-FINE, N to X tiers, BF16 Apache 2.0 Pit Camera Watch An unconditional licence; the N through L tiers fit one 48 GB card; ahead of DEIM on matched compute
Roboflow trackers, ByteTrack and OC-SORT class Apache 2.0 Sovereign HSE Watch, Structure Phase Watch, Steel Count Ledger Stable identity across frames without reintroducing copyleft after an Apache detector; one billet crossing two camera fields counts once
Anomalib 2.7.0, FP32, exported to ONNX Runtime Apache 2.0 Hangar Form Cell Unsupervised fit on the facility's own good panels needs no labelled defect set

The pattern a developer should copy is the pairing: an Apache detector followed by an Apache tracker. The register in three designs says in so many words that the tracker was chosen so that the AGPL exposure of the better known tracking collections never enters the serving path.

The forecasters

Model Licence Designs that chose it The reason the register gives
Chronos-2, about 120M parameters, about 0.48 GB at FP32 Apache 2.0 Sovereign HSE Watch, Terminal Pulse, Fodder Watch Zero shot multivariate forecasting with covariates and no field of use restriction; thousands of independent per parcel series with no fine tuning dependency
Chronos-Bolt Apache 2.0 Hangar Form Cell Learns per arm, per stylus load baselines on the edge box and flags drifting pass signatures
IBM Granite Tiny Time Mixers TTM-R2, about 0.85M parameters, FP32, about 0.003 GB Apache 2.0 Factory Fire Watch A CPU only forecaster inside the operator's existing platform; the requirement asked for no server or GPU, so none was deployed

The Granite row is the one to notice. The design covers a hundred factories and runs its forecaster on the CPU the operator already has, because a model of under a million parameters was enough and the requirement forbade buying compute.

Retrieval and document parsing

Model Licence Designs that chose it The reason the register gives
BGE-M3, 568M parameters, FP16 MIT Sovereign HSE Watch, Port Twin, Structure Phase Watch Dense plus sparse plus multi vector retrieval in one pass with an 8,192 token window; multilingual retrieval across a workforce tagged by language; in the port design it is the only model in the register
Qwen3-Embedding-0.6B, 32K window, about 1.2 GB at BF16 Apache 2.0 Grid Context Watch, Terminal Pulse Whole playbooks, CIP procedures or a whole shift's gate record retrieve as single passages; runs beside the frontier model
PaddleOCR-VL 1.6, about 0.9B parameters, BF16 Apache 2.0 Sovereign HSE Watch, Corridor Guard Strong on degraded multilingual scans; no user or revenue threshold; digitises a scanned package with human reconciliation before any value enters the record

The choice between the two embedders is a window question. BGE-M3 wins where the corpus is drawings, inspections and messages in several languages. Qwen3-Embedding-0.6B wins where a single document, a procedure or a shift log, must retrieve whole, and its 32K window makes that possible.

The four empty registers

Design What the register says Why
Reliability Atlas 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
Loop Integrity Watch 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 licence question arises
Field Ledger Zero models committed; a forecaster over sensor time series stays open work gated on the first milestone's evidence The requirement commits aggregations, drill down and reporting, and no model was verified for this run
Baseline None; the register is empty by decision No agent or model layer was wanted; analysis stays with the operator's own staff in their own tools

A quarter of the designs needed no learned model at all. Each of those papers still carries the register, with its emptiness and the reason written down, because a reader deciding whether to copy the design needs to know that the absence was chosen.

The licence pattern

Across the twelve named models the licences are Apache 2.0 (nine models), MIT (two) and one bespoke licence read for its internal use carve out. Three things never appear: a field of use restriction on a model the operator fine tunes, a revenue or user threshold, and a copyleft licence in the serving path. Where a stronger checkpoint existed under a platform licence, the register excludes it by name and says why.

That is the whole method. Choose the model for the job, read the licence as carefully as the benchmark, and write the reason down where the next engineer will find it.

Use the register

The rows behind this note are the models.jsonl file of the Vertical-Driven Architectures dataset, one row per choice with the design, the choice, what was picked and why. The same file is served live by the codeninja-research MCP server, so a coding agent can ask which designs chose a given model and read the reason. Every design named above was reasoned on CodeNinja Praxis and its object model imports into Hyper Ontology.

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.

Top comments (0)