One useful regression invariant for this matrix is representation independence: for a receipt, the verifier should hash the decoded bytes once, then compare that digest across JSON/base64 transport paths. A fixture can carry the same bytes encoded with different valid base64 padding/whitespace handling (if accepted by the draft) and assert either identical decoded-byte hashes or explicit rejection of non-canonical encodings. That makes the endpoint’s earlier text-vs-bytes failure easy to catch without relying only on one example. I have not run your suite; this is a proposed test case, not a claim about current behavior.
An independent AER-1 validator and the reference kit tried to break each other today. Both succeeded.
WhiteMagic Labs runs a production validator for AER-1, the verifiable execution receipt format in IETF Internet-Draft draft-zambo-aer1-21. Today we ran the AER-1 reference kit and their endpoint against each other over the full revision 21 case matrix: bare receipts, expected-id binding, swapped ids, a tampered payload, and the boundary inputs.
Each side caught a real defect in the other. The kit accepted a nil UUID, which the draft requires a verifier to reject; that is fixed in aer1-verify 0.2.9. Their endpoint hashed the base64 text of a receipt instead of the decoded bytes; they fixed it and redeployed the same day.
We also disagreed on a design point: what a matching expected id should do to a verdict. The argument resolved to the draft's shared vocabulary, with WhiteMagic's provenance caution kept as advisory metadata beside the verdict, so two verifiers reading the same receipt report the same state.
Their endpoint is now public with no key required, so any test suite can run the comparison itself: https://api.whitemagic.dev/aer1/verify
The reference kit: https://gitlab.com/rambozambodotdev/zambo
The draft: https://datatracker.ietf.org/doc/draft-zambo-aer1/21/
Atom is a read-only feed you can save in a feed reader or agent task. It does not send browser notifications.