Anatomy of a Trust Proof: what a certificate has to bind to be worth anything
A certificate that says "this model was assessed" is a press release. A certificate that binds the model hash, the data lineage, the compute attestation and the test results into one signed object is evidence.
Certification schemes fail in a predictable way: the certificate becomes detached from the thing it certifies. The model is retrained, the data changes, the deployment moves, and the badge stays on the website. A Trust Proof is designed so that detachment is detectable by anyone, without contacting us.
Five bindings
Model identity: a hash of the exact weights and configuration that were tested. Data lineage: hashes of the training and evaluation sets, and the provenance record for each. Compute attestation: a hardware-signed statement that the evaluation ran inside a confidential environment in which we could not see plaintext weights and the client could not alter the test. Results: every gate, every metric, every threshold, and the sign-off for any accepted risk. Policy mapping: which obligations — EU AI Act article, ISO/IEC 42001 control, national requirement — each result evidences.
One signature over all of it
The bindings are assembled into a single structure and signed with a post-quantum signature scheme (ML-DSA) using an HSM-held key. Change any element — swap the model, relax a threshold, drop a test — and the signature fails. Verification requires an open command-line tool and the public key. It does not require trusting S.AI.F, which is the point.
The value of a certificate is exactly the difficulty of forging it.
What it does not do
A Trust Proof does not promise the model is good for every purpose. It states what was tested, how, with what result, and for which version. It has an expiry condition — a material change to model, data or context — and the monitoring hooks to notice one. Clarity about scope is what lets a regulator, a customer or a court rely on it.
