A receipt that names a model is not a receipt that pins one
We sign receipts. This page is about a hole we found in our own, what each model API lets you do about it, and what we changed. It is dated 8 October 2026 and every figure below is computed from our publish tree at build time.
We went through the 59 receipts in our publish tree with one question: if a verdict changes, can the record say why? It could not.
structured claim 7 · corpus_id 3 ·
verifier version 40 · any subject 28 · a machine-pinned subject 2 The subject is the worst of it. Where it is recorded at all it sits under four different names, mostly as free prose. So a pass after a fix and a pass after a silent model change look the same in the record. That is the failure we sell against, inside our own instrument.
We published this rather than quietly re-signing the records with the missing fields. Re-signing published evidence is what we would end someone else's engagement over.
Two questions, not one
Pinning a model means answering two different things, and vendors answer them separately. First, can you ask for a fixed version? Second, does the response tell you which backend actually answered?
| provider | can you ask for a fixed version? | does the response name the backend? | notice before removal |
|---|---|---|---|
| Anthropic | Yes. “Every Claude model ID is a pinned snapshot, including the dateless IDs used from the 4.6 generation on.” | not established here | a “not sooner than” date published per model |
| OpenAI | Yes. “Snapshots let you lock in a specific version of the model so that performance and behavior remain consistent.” | Yes, system_fingerprint. “If this value is different, you may see different outputs due to changes we've made on our systems.” | at least 6 months for GA models, 3 for specialized variants, and preview models “such as 2 weeks” |
Yes for a stable ID, which “points to a specific stable model”. A -latest alias “will get hot-swapped with every new release of a specific model variation”. | not established here | 2 weeks by email before the version behind a latest alias changes | |
| Microsoft Foundry | Yes, pinned at the deployment. Standard deployments otherwise auto-upgrade at retirement; NoAutoUpgrade is available. | not established here | at least 60 days for GA models, 30 for preview. Retirement dates are not extendable. |
| DeepSeek | No. The model field takes deepseek-flash or deepseek-v4-pro. The reference lists no snapshot identifier. | Yes, system_fingerprint. We verified it is populated and stable. | none published |
“Not established here” means we read that vendor's own documentation and did not find the claim on the pages listed at the foot of this page. It does not mean the feature is absent. Check it yourself; the pages are linked.
What we observed on DeepSeek
We run our corpus on DeepSeek, so we ran the check instead of reading about it. Four calls on 8 October 2026, metadata only:
aeb56401ca74e127821c4f9126dcb669 model: "deepseek-flash" · same fingerprint
So the name is not the model. The string deepseek-chat appears in our own
published receipts, and today it resolves to V4.1 Flash. Their changelog moved that one
string across ten different models between May 2024 and December 2025, then scheduled it
for discontinuation on 24 July 2026. That date passed without being enforced. The string
still works, and it is still not a version.
What we changed
New receipts carry a subject block that records what the run ran against: the provider,
the name asked for, the name the response gave back, the backend fingerprint, and the
parameters that affect the output. A pin_strength field states which rung
the evidence reaches, from a weights digest down to a bare name, and it is derived rather
than supplied, so a caller cannot claim a stronger pin than it holds.
A re-run of a claim now checks the fingerprint first and refuses the comparison if it has moved, because a 90-day window means nothing if the backend changed on day two. The original receipt stays published beside it, in both directions, so a reader who arrives at the pass can always reach the failure.
The receipts already published cannot carry this. A signature covers the record it was made over, so adding a field means re-signing, which is the practice we prosecute. They stay exactly as signed, and each one now says on its own page that it cannot be compared.
Sources
All fetched 8 October 2026. Where a quote appears above, it is from the page linked here.