What a record does not establish.

Three of these are structural: no amount of signing, hashing or chaining moves them, because they are facts about what a self-signed document can be evidence of. The format states each one at the point where it applies and the verifier prints it rather than leaving it for a reader to work out.

Limit one

Completeness is never established

The rows in a record are the rows its producer chose to write. Nothing inside a self-signed document bounds what its author left out, so the verifier does not report completeness as established under any circumstances. It reports it as not applicable, and gives the reason in the same breath: not claimed and not establishable, because the rows are what the producer wrote and nothing in a self-signed record bounds what it did not write. The exact line, with that record's row count in it, is in the capture further down this page.

One thing moves it, and only in the negative direction. A receipt held by the subject of a decision, naming a decision the record does not contain, refutes the record. Completeness cannot be proved from inside and can be disproved from outside, which is the honest shape of that property rather than a gap waiting to be closed.

Limit two

The inputs are the producer's word

Replay re-decides the retained inputs and establishes that the decisions follow from them. It does not establish that those inputs are the calls the system actually handled. A producer can write a wholly honest record of a question nobody asked, and every property will report established, because none of them is a check on that.

That record exists, in the repository, with the keys that verify it. It is the clearest statement this project can make about its own ceiling, so it is published rather than described.

See that record

Limit three

An outside party has to actually be outside

A witness statement signed with the producer's own key, under a registry that lists that key as an independent auditor.

dr.verify, with a self-witnessed record

python3 -m dr.verify examples/acceptance/out/record \
  --registry examples/keys/registry.json \
  --decider-registry examples/keys/deciders.json \
  --witness examples/acceptance/out/self-witness.json \
  --witness-registry examples/keys/witnesses-with-producer-key.json

What that prints

examples/acceptance/out/record

  OK      document       format_version 2 shape, and payload_hash recomputes from the canonical payload
  OK      signing_trust  key 'example-2026-10' is active in the registry
  OK      signature      the signature verifies over the payload
  OK      chain          20 rows re-derive from GENESIS to the signed terminal hash
  OK      decisions      20 rows written, by outcome {'ALLOW': 10, 'DENY': 10}, one decider, 1 policy; a count of what the producer wrote, not of what happened
  OK      profile        the rows support the declared profile 'production'
  n/a     correctness    the production profile carries no correctness property: the rows have no labels and the record claims none
  OK      retained       3 retained file(s) present with their digests, inputs match the rows, policy matches the rows
  n/a     replay         not requested; pass --replay <decider module> to re-decide the retained inputs
  OK      invocation     every one of the 20 rows carries a decision the decider signed under ['example-decider-2026-10'] at decision time, bound to this record and sequence; the producer could not have written these rows without the decider
  OK      stream         first record of stream 'acceptance'; nothing prior to link to
  n/a     completeness   not claimed and not establishable: the 20 rows are what the producer wrote, and nothing in a self-signed record bounds what it did not write. A receipt (--receipt) for a decision the record lacks refutes it
  n/a     receipts       no receipts supplied
  UNKNOWN witness        witness key 'independent-auditor-2026-10' is also a producer key (as 'example-2026-10' in the producer registry); a producer witnessing itself establishes nothing

VERDICT: NOT ESTABLISHED
Nothing failed. At least one property could not be established, and an unestablished property is not one that holds.

Nothing failed, and nothing was established

Thirteen properties are fine. The signature verifies, twenty rows re-derive, the decider signed every one of them at decision time. The witness line is UNKNOWN, because the key offered as an independent auditor is the producer's own key under a second name, and the verifier compares the key material rather than believing the label.

The verdict is NOT ESTABLISHED at exit 1, which is a different outcome from FAILED at exit 2. Nothing in the record is wrong. Something a reader needs is missing, and the verifier will not round that up.

What the format can check is key material. Whether the party holding a key would in fact dispute the producer's account is organisational, and no document establishes it. That applies to witnesses, to receipt holders and to upstream attesters alike, and the specification says so at each of those three points.

The rule underneath

Four states, and unknown is not a pass

Every property resolves to established, unknown, failed, or not applicable. Unknown means the check could not be performed or could not be computed: a registry entry that is malformed, a row version this verifier does not read, rows that did not re-derive so nothing over them was computed.

Unknown is a statement about the verifier or its inputs, never about the document's honesty, and it is never a pass. A verdict is the worst state present, so one unknown among thirteen established properties produces NOT ESTABLISHED and not a tick. That is the whole design: a property nobody could check is not a property that holds.

See what it refuses