An auditor we sat with had a folder of model documentation thirty pages deep — data sheets, eval summaries, a governance attestation, a tidy bar chart of benchmark scores. She flipped to the chart, tapped the tallest bar, and asked the question every one of these decks is built to deflect: how do I know this number is real? The honest answer, for almost every model card ever produced, is that you do not. You trust the lab that drew the bar. The chart is a claim about a computation you were not present for and cannot repeat.
That is the whole problem with how AI trust is packaged today. A screenshot of a dashboard is not evidence. It is a picture of someone else's conclusion.
The thesis: provenance that you have to take on faith is not provenance. A trust claim is only worth the weight a regulated buyer puts on it if the buyer can reproduce it independently — offline, without the lab, and get the same answer the lab got. Everything else is reputation wearing the costume of proof.
What a signature buys that a screenshot does not
Every LeanLogix release carries a passport: an Ed25519 signature over the verbatim bytes of what produced the model — the data lineage, the training method, the eval probe set and seed, the per-probe trace, and the approver record. The signature is not decoration. It binds those exact bytes to a key. Change one character of the lineage and the fingerprint no longer matches; the tamper is arithmetic, not a matter of opinion.
The part that matters is what the holder can do with it. Anyone with the passport and the public key can recompute the fingerprint and re-run the checker on their own machine — an air-gapped box with nothing but curl and the key is enough. They do not verify that we are trustworthy. They verify the result. The difference between those two verbs is the entire argument. One asks for faith in the author. The other asks for nothing, because the buyer does the computation themselves and watches it come out the same.
Separation of duties, made into a fact
A signature proves the bytes are intact. It does not, by itself, prove the process behind them was sound — and the process failure that wrecks a regulated release is mundane: the person who trained the model also approved it. One identity, both roles, no second set of eyes. Plenty of governance programs assert they separate these duties. Asserting it in a policy document and enforcing it at the moment of release are different things.
So the passport carries a separation-of-duties record in which the approver is a distinct identity from the trainer, and the release gate is fail-closed: no passport seals without it. The control is not a sentence in a PDF that an auditor has to take our word for. It is a field in a signed artifact that fails verification if it is missing or if the two identities collapse into one. We turned a policy claim into something the holder can check the same way they check the fingerprint — by recomputing it, not by believing it.
The obvious objection
The pushback is fair: most buyers will never run the checker. They will glance at a green badge and move on, and the elaborate re-verifiability will sit unused. If almost nobody exercises the proof, why build it?
Because the value of re-verifiability is not in how often it is exercised. It is in what becomes true the moment it exists. A claim that can be independently re-run is a claim the author cannot quietly fudge, because the one time it matters — the audit, the incident, the dispute, the regulator who does know how to run a checker — the math is either there or it is not. Verifiability disciplines the producer whether or not the consumer ever uses it. A screenshot disciplines no one. That is why the few who do run it are the only ones whose opinion of the number should count, and why building for them raises the floor for everyone else.
Why the proof is the product
It is tempting to treat the passport as a compliance feature — a thing you bolt on so the deck has a slide about governance. That gets the order backwards. For a regulated builder, the artifact they hand the auditor is not documentation of the work. It is the deliverable. The model is the means; the re-verifiable record of how it was made, evaluated, and approved is the thing that lets it be deployed at all.
Which reframes what we are even selling. Not a model that is trustworthy because we say so — a model whose trust you do not have to take from us, because it travels with everything you need to establish it yourself. The frontier ships capability and asks for your faith in the eval. We ship the eval in a form you can re-run, and ask for nothing. In a regulated boundary, that is not a nicer way to package the same product. It is the only version of the product that an auditor can actually accept.
See it verify
The signing, the held-out training boundary, and the offline check are real — the same verification runs on an air-gapped box with nothing but the public key. Watch a release verify in ten seconds.
Verify a model live