Narrowing — added 11 August 2026. Two sentences above claim more than the mechanism delivers.

They are left as published, and narrowed here. The distinction they fail is between two different questions, which this page had been treating as one.

Evidence integrity — can you prove this evidence belongs to this decision, was created with it, and has not since been altered? Evidence sufficiency — even if the record is completely authentic, does it give an examiner enough to determine whether the underlying decision was properly made? An authentic record can still document a decision made from incorrect information, under the wrong rule, without proper authority, or without a required exception or review.

“— and check it without trusting us.” True of the first question and not the second. You can confirm, without trusting us, that the envelope hashes to the attested input_hash and that an independent party signed it. You cannot confirm from the receipt that the decision was properly made — that still rests on our account of the inputs, the rule and the authority. Confirming the signature confirms that the system is telling the truth about its own beliefs.

“the policy state in force.” What is sealed is the policy state the system held. That it was the state which governed is a different claim, and not one a receipt can carry. A receipt can perfectly establish that Rule X was applied; if an examiner cannot establish that Rule X was the applicable and authorised rule at that point in time, integrity does not resolve sufficiency.

This is not fixed, and no mechanism for it exists here. The applicable rule, the valid issuance of an authority, its currency at the moment of reliance, and a verified referent for the actor’s identity are each terms the calling chain cannot produce. Establishing them needs a source outside both the vendor and the operator. All four are carried open in our disagreement register — items 13, 21, 29 and 33 — and were recorded on 11 August 2026 as one category rather than four.

The distinction was drawn by an external reviewer — a banking and operations professional whose experience spans fraud prevention and investigation, BSA/AML, compliance and operational risk — in a first exchange, and is recorded in the register with their consent. They have inspected no implementation and this is not an endorsement of one. It is the third claim on this page narrowed this week and the first found by a counterparty rather than by us.

Correction to the table above — added 9 August 2026

The June snapshot is left as published rather than edited, because a dated figure that is quietly changed stops being a dated figure. This note supersedes three of its rows. It was written after recounting the store, which happened because the attester's holdings could not be reconciled against this page.

182,040 was a subtraction, not a query. It is exactly 225,574 − 43,534. No field in the store returns it. Records actually carrying a tbn_valid flag total 10,234 — the row above it — of which 10,030 are simulation agents. Non-simulation records with that flag number 204, and every one is a tombstone event. The row said "test-API attested" against a number that no attestation field supports.

43,534 does not reconcile either. Simulation records total 206,892 and non-simulation 23,377. Neither is 43,534.

The vault total is a May-2026 figure. Recounted on 9 August against the store as last written on 25 July 2026: 230,269 parseable records, plus one unparseable line. 225,574 of them were logged in May. It is an append-only local hash-chained trail, overwhelmingly a simulation corpus from a load exercise. It is not evidence of production governance and should not have been positioned as though it were.

The counter-signed corpus is separate, smaller, and the one that checks out. Thirteen dated runs totalling 5,794 receipts carry an independent signature; the four rows at the top of this table are four of the thirteen. 3,799 sit on a chain shared with the attester spanning indices 220–4184 of a declared 0–4184, reconciled from both sides on 1 August 2026 with nothing unaccounted. The remaining 1,995 use an earlier construction, are not on that chain, and are verified individually.

What this page does not prove — added 30 July 2026

Every receipt here proves the decision was made against a stated, provable basis, and that an independent party signed it. None of them proves that basis was soundly established in the first place. Two people found the same gap on the same day and it is worth stating here rather than leaving on a comment thread.

Issuance is not gated on terms the chain cannot produce. The authorising principal, scope, approver and credential all arrive on the request. There is no external authority source to ask. A well-formed grant that was never issued would pass every check we run — fidelity holds, the binding holds, the record is contemporaneous, nothing has expired, and there is no signal at all. Found by Ahmad Abby (MTCP / ARCS) on 30 July 2026, measured across 32 models and 13 providers.

The same failure sits one level up. Where a control is not reached by a request it is recorded not applicable rather than failed — which in audit terms is a scope exclusion, not a soft failure: it leaves the tested population entirely. And what determines whether a control is reached is the shape of the request. Found by Brad Wolfe on 30 July 2026.

Attribution correction, 11 August 2026 — this credited one person with two findings, and one of them is ours. Brad Wolfe named the audit treatment: that not applicable is a scope exclusion rather than a soft failure — a failed control enters the exception population and gets remediated, an excluded one leaves the population entirely — and that if the system decides what is in scope, scope is chain-producible too. The sentence about the shape of the request is ours, not his. It is the mechanism we found when we checked his point against our own code, and the paragraph above compressed the two into one sentence and attributed the whole of it to him. Our internal record had the split right; the published summary lost it. Raised by Mr Wolfe on reading a draft that repeated the same compression. His name appears here at that level and no other: no title, no firm, no credential, and he is not a reviewer, adviser or examiner of this work. He has inspected no implementation of ours, and this is not an examination, endorsement or validation of one.

Three smaller consequences of the same root: the approver's credential is fingerprinted but never verified; a failed separation-of-duties check is recorded without blocking the write; and omission produces a cleaner record than a bad claim.

None of it is fixed. The direction is known and is not ours: an auditor does not ask the company for its cash balance, they ask the bank — so the issued grant set has to live with a party we cannot write to, and the check has to be a request we make rather than a computation we perform. We already have that relationship, for the receipt. We never applied it to the grant. Same pattern, wrong object.