Check it without trusting us.

There is nothing to call and no account to hold. A record is files on disk, and the verifier is a command that reads them and exits 0, 1, 2 or 3. Both halves are published, so a reader runs the check on their own machine against their own copy, holding the directory and a key registry and nothing else.

The procedures it records are deterministic ones: an authorisation check, a tool-call gate, a rate limiter: anything whose answer is a function of its inputs and its policy. Not a model. That restriction is what makes a decision re-derivable by a reader rather than merely attested by its author.

The verifier reports each property separately and in one of four states: established, failed, unknown, or not applicable. The verdict is the worst state present.

Unknown is not a pass. A property nobody could check is not a property that holds, and the format refuses to round it up. That one rule is why the output below is worth reading in full rather than skimming for a green tick.

The seven established lines are integrity: the payload hashes, the signature verifies against a named key, forty rows re-derive from GENESIS to the terminal hash the signature covers, and the retained files match the rows that reference them.

The seven remaining lines are the part worth reading. One of them says that completeness is not claimed and not establishable. The forty rows are what the producer wrote, and nothing inside a self-signed record bounds what it did not write. Another says that the rows are the producer's word on what the decider said, because no decider attestation was retained.

Most evidence formats describe what they prove. This one enumerates what it does not, because a record is not permitted to grade itself: the judgement belongs to the reader, and the record's job is to supply material they can judge. A count of decisions is described as "a count of what the producer wrote, not of what happened" in the verifier's own output, not in a footnote.

Under examples/acceptance/ there are deliberately forged records, the commands that catch each one, and the output each command actually produces, captured rather than written. A record whose rows fail to re-derive reports every property downstream of them as UNKNOWN, giving the reason not computed: the rows were not established rather than guessing.

That directory exists because an evidence format whose author only publishes the cases it survives has published advertising. The acceptance procedure is how a reader refuses a record, written by the party who would rather it were accepted.

Here is the case that matters most, because it is the one the first transcript said it could not rule out. A record with two rows removed, checked against a receipt the producer itself issued for one of them at decision time, to the party that decision was about:

The headline on this page is only honest if a reader can build their own verifier from the specification. So that was measured rather than asserted. A second verifier was written from SPEC.md alone, prevented by construction from importing the reference implementation, and run against a conformance corpus of forty-seven cases.

It disagreed on five of them. Those five disagreements are the result; the agreements bound nothing, because both implementations have one author. Each disagreement named a sentence in the specification that was not specific enough to implement from, and the specification was corrected. The measurement and its limits are published alongside the code, including the sentence that would close each remaining reading.

Nothing inside a record proves that the retained input was the real call. A producer can write a wholly honest record of a question nobody asked: the chain re-derives, the signature verifies, the decider computes the stated answer from the stated input, and every property reports established. A limit nobody has exhibited is a limit nobody believes, so here is that record, committed to the repository with the keys that verify it.

Bounding it requires a party outside the producer: a witness, a receipt held by the decision's subject, or an attester upstream of the decider holding a key the producer does not. The specification says so at each point where it applies, and says what each of those parties does and does not establish.

Here is the same substitution with an attester in front of the gate, signing each input as it arrives under a key held by the customer and numbering it itself: