INVAR / For regulated buyers
Reference architectures for self-hosting open-weight models end their provenance section the same way: verify checksums and signatures against the publisher, keep version control, and you can show which artefact produced a decision. The first half is real. The second half does not follow from it — and the gap between them is what this page is about.
A checksum proves
The bytes of the weights file on disk match what the publisher released. A statement about an artifact at rest, made once, before use.
A checksum does not prove
That the answer you were handed came from those weights. Between the verified file and the response sit a loader, a quantiser, a runtime, a driver, an accelerator, a batch shape and a thread count.
A receipt proves
That a specific output came from a specific model under a specific runtime, in a form a third party can re-execute and check. A statement about a computation, made every time, during use.
Ordinary floating-point arithmetic already returns different bits for the same model and input on different hardware, thread counts and batch sizes. So there is no stable value to sign, and nothing to compare a later answer against. This is an arithmetic problem before it is a logging problem: you cannot sign an output that is not reproducible, and signing one anyway produces a number nobody can check.
Outcomes quoted verbatim from the NIST Cybersecurity Framework 2.0 Core. Read the wording closely and a pattern appears: every control touching model integrity is written as a continuing obligation — and use, data-in-use, runtime environments, over the course of the relationship, throughout their life cycles. A publisher checksum is a point-in-time measure.
| CSF 2.0 | Outcome (verbatim) | Publisher checksum | Receipt adds |
|---|---|---|---|
| ID.RA-09 | “The authenticity and integrity of hardware and software are assessed prior to acquisition and use” | Satisfies the "prior to acquisition" clause | Extends the same assurance to use: every inference is evidence, not just the install |
| PR.DS-10 | “The confidentiality, integrity, and availability of data-in-use are protected” | Silent — says nothing about data in use | Integrity of the computation itself: output bound to model, input and runtime, re-executable |
| DE.CM-09 | “Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events” | Silent | Detects an adverse event a log cannot: a wrong answer. Corrupted output fails re-execution |
| PR.PS-04 | “Log records are generated and made available for continuous monitoring” | Logs record what a system said it did | Records what it did, checkable without trusting the recorder |
| GV.SC-07 | “The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship” | One-time, at onboarding | Continuous: every call is a supplier-integrity measurement |
| ID.AM-08 | “Systems, hardware, software, services, and data are managed throughout their life cycles” | An inventory entry | Binds the inventory entry to the outputs it actually produced |
ISO/IEC 27001:2022 Annex A control text is licensed and is not reproduced here. The relevant themes are supplier and cloud-service assurance, monitoring activities, and logging. We will map them against the licensed text with your assessor rather than cite identifiers from memory.
Every figure below is measured on real hardware, not modelled or projected.
One hash across three substrates, two more that check it
The same model and input produce a bit-identical whole-graph hash on x86, an NVIDIA RTX 5090 and an ARM Cortex-A53 board — every traced row of every layer, not just the final answer. A Tenstorrent Blackhole card and a Xilinx U200 FPGA then independently re-executed challenged rows of that same computation and accepted every one. The re-execution is reproduced by separate Python and Go implementations, so the property lives in the specification rather than in one binary.
Silent corruption caught live
Injected faults detected 3 of 3, with zero false positives. A corrupted output fails re-execution; a log of that same inference would look perfectly normal.
Verification without a datacentre
A $250 ARM board re-executes 158,775 challenged rows in 41 seconds. The party checking the work does not need the hardware that did it.
Training too, not just inference
A fine-tuning run's receipt chain verifies end to end, and any segment replays bit-exactly from its checkpoint — so a model's provenance reaches back through how it was made.
Assessable without an NDA
The arithmetic, kernels, three machine-checked formal proofs and the reference implementations are public under Apache-2.0 with a Zenodo DOI.
Stated plainly, because your assessor will ask and the answer should not have to come from them.
The honest position: this closes the output-integrity gap, and only that gap. It happens to be the gap that current reference architectures assert away.