The release registry

This is a litter detector. It is easy to read what follows as numerical housekeeping, so here is what each number costs somebody.

None of these three is served by "the file is 30% smaller." They are served by knowing whether the smaller file makes the same decisions, by knowing what the difference costs when it does not, and by both answers being attached to the artifact instead of filed somewhere else. Here the difference turned out to be instability rather than damage — which is a reason to route a flip count to a person, not a reason to stop counting it.

Five records, one model, three runtime targets. Three ONNX graphs measured under ONNX Runtime, and two TensorRT engines built from an ONNX export of the same checkpoint on an RTX 4070. The two engines differ only in whether the TF32 builder flag was set, which is not a target property and not something a filename can hold — they share a target exactly and are still two releases. § 04 is why the registry can now say that.

Read the int8 row twice. 202 → 202 is not agreement; it is 112 disagreements that cancel exactly. A registry that stored a detection count would have recorded this conversion as identical to the one it replaces. Those 112 were later scored against blind human labels and cost no accuracy in either direction — which is what this column is for. The record holds the disagreement; a person decides what it means. Detail in the 2026-09-08 update.

Then read the TF32-on engine's row the same way: 183 → 183 with two queries disagreeing, one in each direction, on one image. Same trap, different hardware, third occurrence. The two engine rows carry no image count because the record does not hold one: the TensorRT parity report has the field, but the two harnesses name their outputs differently and the automatic transcription helper is ONNX-Runtime-shaped, so these two records' parity blocks were assembled by hand and dropped it. This column renders what the record holds rather than filling the gap from a file beside it — which is the whole point of putting evidence on the record.

record_id = sha256(canonical_json(identity)). The identity block holds the artifact hash and byte count, architecture and precision, the conversion (exporter, mechanism, opset, source hashes), the full IO signature including dtype per tensor, the class-list hash, both recommended thresholds, and the target.

The version string is deliberately outside the digest. A version is a label, and labels get re-pointed at new bytes — which is the exact failure this exists to catch. It is recorded and constrained instead: one (model, version) may name exactly one artifact hash for a given recipe and destination, and a second set of bytes under the same recipe and destination is refused. § 04 is why that qualifier had to be added, and then widened.

Two things are inside the tuple that people often leave out. Thresholds, because the same bytes recommended at a different operating point make different decisions and are a different release. And the target — runtime, version, execution provider, host, and for a GPU the compute capability, CUDA runtime and driver — because a measurement does not transfer across them. The target being in the tuple and not in the uniqueness rule is what § 04 is about.

The target has always been inside identity(). The uniqueness rule was keyed on less: Registry.register refused any second record whose (model_name, version) already existed, whatever target it named. Those two statements cannot both be right, and the gap between them is not academic.

An ONNX artifact and the TensorRT engine built from it are two releases by identity — different bytes, different runtime, different execution provider, two different record ids — and were a VersionCollisionError by the uniqueness rule. So were two engines built from one ONNX under different builder configurations, which differ by nothing a filename can hold. That is precisely the one-source-many-targets case the target matrix produces, and precisely the case a release registry exists to hold. This one could not hold it.

It was found by trying it — building the engines on a GPU host and attempting to register one alongside the fp32 ONNX record already there — rather than by reading the module. The registry refused a release it was built to record.

Three narrower repairs came out of the same exercise.

• Accelerator identity is fields, not a packed string. Target gained computeCapability, cudaVersion and driverVersion. A GPU target that packed those into hostClass would put them in the digest by string concatenation instead of as comparable fields. The two engine records carry all three — 8.9, CUDA 13.1, driver 591.86. They are omitted when absent rather than written as null, which is why the three ONNX record ids above still hash to exactly what they hashed to before.
• "Cannot be inspected" is no longer stored as "nobody looked." § 05 reads precision off the graph's own weights. A TensorRT plan has no ONNX initializers to read — attempting it fails outright with a protobuf decode error — so PrecisionEvidence.opaque(reason) records why the evidence is missing. Both engine records carry "tensorrt plan: weights are not inspectable". Unobtainable evidence and absent evidence are different claims and now serialise differently. The consequence is stated rather than hidden: for those two records the "checked, not declared" guarantee does not apply, and their precision is back to being an unchecked assertion.
• A parity report from another runtime is refused, not relabelled. Transcribing a report with no environment.onnxruntime used to stamp runtime: "onnxruntime" onto a measurement made under something else. It now raises instead of writing a false claim into an immutable record.

294 tests pass, 3 skip. .github/workflows/ci.yml re-hashes every record in the registry from its identity block on every push, so a hand-edited record turns CI red rather than waiting for whoever next reads the file.

A record does not take the word fp16 from a filename. It reads the graph and counts weight bytes by tensor dtype, then infers a precision by majority. Which is how it can contradict a label rather than trust one.

It applies to 3 of the 5 records. The 2 TensorRT engines are serialized plans with no ONNX initializers to count, so they are not in the figure below — and their records say so in the field where the evidence would be, rather than leaving a null that also means "an ONNX nobody inspected." A guarantee that quietly stops applying is worse than one that visibly does not.

fp16 comes back exactly half of fp32's weight bytes — 56,965,984 against 113,931,968 — meaning every weight converted and none were skipped. int8 does not: it is 92.5% INT8 with 7.5% of its weight bytes still fp32, tensors the dynamic quantizer declined to touch. So int8 is a majority, not a description, and the mechanism has to be in the identity tuple because the word alone does not identify what was built.

A check that never fires in a test is a comment. Each of these is asserted against the real artifacts, not a fixture.

• Precision that disagrees with the graph. Registering the int8 bytes under v2.0.1-fp32 raises PrecisionMismatchError: declares 'fp32' but the graph's own weights are 'int8'. This is the case the serving contract cannot catch today.
• One version naming two sets of bytes from one recipe. The second fp16 recipe under the existing v2.0.1-fp16, same target, raises VersionCollisionError. Under a different target, or from a different builder config on the same target, the same version is a second release and registers — that is § 04, and all three halves are asserted. The six TensorRT determinism builds are the case that still collides, and correctly: same recipe, same target, different bytes.
• A release with no parity evidence. Parity is a required argument, and it is checked rather than trusted: the report must name this artifact's hash on the side it claims, must have been run at the operating point the record recommends, and for a conversion must have compared against the recorded source.
• A hand-edited record. Rejected on read — the digest no longer matches the identity it covers. CI re-computes every record's digest from its identity block on every push, so this one fires in the repository and not only in a test.
• A deleted assertion. Each refusal named here is grepped for in CI by the exception it raises. Removing the test that proves a refusal fires turns the build red, which is the only way "these checks are asserted" stays true a year from now.

A registry earns nothing by recording only the flattering fields.

These records describe 5 artifacts of one model, measured across a macOS workstation and a Windows desktop GPU. They license nothing about another architecture, another accelerator, an embedded board, or the arm64 host the model actually serves on.