Verification language in this field is loose, and the looseness hides real gaps. "Verifiable," "trustless," and "proof" get attached to systems that establish far less than the words imply. We build verification into our datapath, so we owe a precise account of what it establishes. This note draws two lines we hold to.
What a receipt does prove
A receipt is a canonical, content-addressed record: it pins the input and output artifact digests, the transformation and its parameters, the code identity, and the evaluation inputs, and it is checked by recomputing declared digests and declared evaluations. If a byte in an output changes, a parameter changes, or a parent digest changes, verification fails at the correct edge. That is genuine reproducibility evidence, and chained across transformations it gives a traceable history from one model version to the next.
What a receipt does not prove
A receipt is not hardware attestation. It does not prove that a specific model and code ran on hardware no one could silently swap. It does not prove that no undeclared step occurred between two records. Recomputing a declared digest confirms the declared history is consistent; it cannot confirm the history is complete.
Where deterministic replay sits, and where it stops
Deterministic replay is a related, stronger-sounding check that also has a hard limit. By fixing seeds, decoding settings, and caching, a generation run can be made byte-reproducible, and a verifier can re-run one forward pass to confirm that a claimed output sequence is consistent with the model. This detects a worker that fabricated tokens. It does not, on its own, prove to an external party that a particular model ran in a trustworthy environment, because it still trusts whoever ran the verifier. Remote attestation, a trusted execution environment, or a zero-knowledge proof of computation are different guarantees, and we do not conflate them with replay.
Between trust-me and zero-knowledge
The two established answers to "did you really run this computation" are unsatisfying: trust the claimant and check nothing, or demand a zero-knowledge proof and pay orders of magnitude more than the computation cost. We are building the middle ground: the claimant commits to the outputs of its work, and a verifier re-executes a sparse, tunable sample of the committed coordinates against the commitment. No zero-knowledge machinery, no trusted-hardware anchor. Measured against synthetic corruption, sampling more coordinates raises detection at a measured verifier cost; the same protocol against a real recomputing adversary is the run still owed, and that bound is stated wherever the result is. One design principle rides above all of this: verification evidence never silently becomes credit. Checking that work happened and deciding who is credited for it are separate decisions, and keeping them separate is what makes either one auditable.
Why the line is the point
Stating the bound is not a hedge. It is what makes the guarantee usable. A system that claims verifiable inference and delivers deterministic replay will fail exactly when someone relies on the missing property. We would rather ship reproducibility and admission checks that hold, name the guarantees they are not, and build the stronger primitives deliberately, than sell one word that covers three different things.