Implementation report: a Go verifier for v0.2, written from the spec (26 findings)

Start with spec/registry-anchor-v1.md and the findings about Anchor Format v1 and the published anchoring flow; compare those claims with the registry anchors cited in the issue. The report spans 26 separate findings and does not specify one change to make, so first identify a single finding and agree on its scope. Done should be a focused follow-up issue or change with an explicit expected rule and, where relevant, a vector that tests it.

Your anchor document says "A conforming verifier can be written from this document alone." I wanted to find out whether that holds for v0.2 as a whole, so I built one in Go, the language I work in, with coding agents, from the spec, the schemas and the vectors, without reading the reference library or any of the project's Python: https://github.com/plimsollmark/trace-verify-go

I also build plimsoll, a Go sandbox for agent-written code whose runs return records a client can check and sign, and I wanted to see how that kind of evidence sits under a TRACE record.

Against trace-spec 63f4d15 and trace-tests v0.6.1, 262 of 262 judged cases (from 216 vector files) agree: 225 against the vectors' own expected results, and 37 against expectations I derived from a file name, a set's README or the suite's documented rules, because those vectors state none a v0.2 verifier can use. The exact claim is in docs/conformance-statement.md, and what it does and doesn't verify is in REPORT.md (steps 3 and 4 of 3.3 aren't implemented, neither are the JWS/COSE envelopes, and the suite's level check is assessed against the vectors at level 0 only, since no vector has an expected result above it).

For a worked case, examples/refund-dispute verifies a Trust Record and two chained Acta decision receipts end to end (a refund a policy gate denied, then the escalation it allowed), with three tampered copies that fail.

Writing it turned up 26 findings. The ones I'd look at first:

• 21. Level 2 can't be reached with the published anchoring flow. TR-ANC-001 wants transparency inside the signed record, but the anchor covers the signed record, so the record has to name its entry before the entry exists. None of the three anchored claims in trace-registry has transparency.
• 19. Anchor Format v1 section 1 is really defined by the Python call. The prose doesn't pin the short escapes, lowercase hex, escaping U+007F, or -0 becoming 0.
• 18. The enveloping forms in 3.2.2 aren't specified enough to implement: payload bytes, which key verifies, algorithm mapping for JWS and COSE_Sign1.
• 8. The vectors can tell apart only 4 of the suite's 25 named checks. Ten of the others are level 1 and 2 checks, and no vector has an expected result above level 0, though the suite's own records carry some of their defects.
• 7. valid_openshell_import.json fails TR-APR-002 by the suite's own docs. Its appraisal.verifier is the exact negative example in tr-apr.md.
• 22. No anchoring vectors anywhere, and the registry's real anchors are all single-leaf and ASCII-only, so they miss both the audit path and the section 0 trap.

All 26, one line each

Spec text silent or not enough:

• 1. Embedded ES256/ES384 signature encoding (raw r || s or DER) isn't stated.
• 6. cMCP's RuntimeClaim can't be verified from the spec; valid_cmcp_runtime.json's signature is 20 characters.
• 13. CHAP chain link: prev_hash as its ASCII form or raw bytes, and the audit/<seq> id convention, are decided by the data.
• 14. Action receipts: the decision vocabulary, controller outcome from terminal_state, issuer_independence values, and the age boundary are decided by the vectors; no vector pairs an unknown key with a failed binding check, which 3.3.2 does decide.
• 15. A GapDisclosure's digest pre-image isn't stated (the vectors use JCS of the whole element, signature included).
• 18. JWS/COSE_Sign1 envelopes are named, not specified.
• 19. Anchor Format v1 section 1 depends on the Python expression.
• 21. Level 2 isn't reachable with the published anchoring flow.
• 25. Nothing says whether an ECDSA high-S signature is accepted. A third party can make a second valid record with a different digest; links and anchors reject it, as 3.1.3 intends, but nothing says whether a digest may identify the claim rather than the artifact.
• 26. It's unclear whether 3.2.2's integer rule reaches objects defined elsewhere and cited by digest (Acta and CHAP envelopes).

Supporting artifacts disagree with the spec or themselves:

• 2. trace-tests' copy of the schema lacks canonicalizableValue.
• 3. The verifier-compatibility README says no normative text exists; 3.3 has it now.
• 5. TR-SCA-002 and TR-TXN-001 docs say sha256 only; the schema allows sha384.
• 7. valid_openshell_import.json is invalid under TR-APR-002.
• 12. Two citation-resolution evidence values are Python-specific (KeyError, an issue link).
• 16. The Acta README and crosswalk still link trace-v0.1.md section 3.3.2.
• 20. Registry entries carry canonicalization_id and mmr_checkpoint; section 4 says "exactly these fields".
• 23. levels.md calls an all-zero measurement invalid at level 1; tr-rte.md says it passes TR-RTE-002.
• 24. tr-apr.md lists "a float" as a TR-APR-004 negative case, but 1784999900.0 has the same RFC 8785 bytes as 1784999900.

Vectors that can't show a rule is performed:

• 4. verifier-compatibility 06, 07 and 11 are refused by the membership check alone.
• 8. 21 of the suite's 25 named checks can't be told apart by any vector (10 of them because no vector has an expected result above level 0).
• 10. No revocation vector has a validly EC-signed bundle.
• 11. Three build-provenance rules are caught by one vector each.
• 17. Nothing tests the GapDisclosure policy bound (proven completeness never accepts a disclosed gap).
• 22. No TR-ANC-002 vectors.

Confirmed from a second implementation:

• 9. The delegation corpus's two-vectors-per-rule claim holds.

Happy to turn any of these into separate issues or PRs (with DCO), and 8, 17 and 22 are vectors I could write. Your AAIF proposal lists a non-Python verifier written from the spec by an external contributor; if this helps with that, feel free to cite it. SOURCES.md logs every file I read.