Where a proof
beats a promise.
A receipt is worth its cost when someone other than you needs to believe a result, and “trust us” is an expensive answer. These are the shapes we are exploring with clients — not deployments we are claiming.
Paying for one model and getting another
You buy inference from a provider at the price of their best model. What arrives is a number. Nothing in that response distinguishes the flagship model from a cheaper one that gives roughly similar answers most of the time — and “roughly similar” is precisely where substitution is profitable and invisible.
With a committed model, the answer arrives bound to a fingerprint. If the served model is not the agreed one, no proof exists. Version strings in an API response are claims; a commitment is a check. The same mechanism settles billing disputes in the other direction, since a provider can demonstrate it served what it charged for.
Needs: the provider willing to commit to weights, and a small enough model to prove economically.
Automated decisions someone will contest
Credit limits, insurance pricing, fraud holds, eligibility screens, ranking that decides who gets seen. Months later someone asks what produced this number. Today the answer is a log entry, and a log entry is only as trustworthy as whoever controls the logs — which is the party being questioned.
A receipt turns that into an artifact the subject, a regulator or an opposing lawyer can check themselves, without being given the model. It does not make the decision fair. It makes the arithmetic behind it non-repudiable, so the argument moves to the model's design rather than to whether the record was edited.
Needs: a decision that reduces to a model whose scoring step can be expressed in a circuit.
Scoring on a model you cannot reveal
Your model is the business. Customers want assurance about how a score was produced; handing over weights is out of the question, and so is letting them re-run the model themselves.
This is where proof does something no cheaper mechanism does. Re-running requires the model. A signature only attests that you say so. A proof lets a customer confirm that a score follows from the committed model and their own input, while the weights never leave your infrastructure.
Needs: a scoring function simple enough to prove, and a commitment your customers accept as identifying your model.
Retraining you would rather not take on trust
A model is updated — on a partner's data, on a customer's device, or by a vendor you cannot inspect. You are handed a new checkpoint and asked to adopt it. The honest description of what you know at that moment is: nothing.
Each update can instead come with a proof that the new weights follow from the previous checkpoint and the committed data under the agreed update rule. Our prototype does exactly this, one step at a time: the controller accepts a new checkpoint only after checking that proof. That covers each step, and it does not amount to a proof of an entire training run.
Needs: a specified update rule. Ordinary large-scale training is out of reach today.
Results crossing an organisational boundary
A result computed by one party and relied on by another — a lab and a hospital, a vendor and an auditor, two institutions in a consortium where neither is willing to be the trusted one, and where a shared trusted third party is politically or legally awkward.
A receipt travels with the result and can be checked by anyone downstream, years later, without contacting the producer or trusting an intermediary. Verification needs only public files.
Needs: agreement on what the commitments refer to before any results are exchanged.
When you should not use this
We would rather say this on the website than in an invoice:
- The model is cheap to re-run and everyone can see it. Just re-run it. Proving costs more than recomputation for small, open models.
- Everyone already trusts the operator. Then a signed response and decent logging is the proportionate answer, at a fraction of the effort.
- The real risk is the data, not the computation. If the fear is fabricated or mis-collected inputs, a proof binds the wrong end of the problem.
- You need this for LLM output. Not economical today with any proving system we would put in front of a client.
- The requirement is regulatory paperwork. Check what your regulator actually accepts as evidence. It may not be a pairing check.
Inferstamp