Machine-readable test data
The AER-1 Internet-Draft: Conformance Fixtures
These five JSON files exercise the receipt checks used by the public Python verifier. Each file states its expected verdict and the reason a verifier should report. The valid case contains a captured public receipt projection. The other cases alter one condition at a time so a failure is attributable to a specific check.
Fixture index
| Fixture | Expected result | What it checks |
|---|---|---|
valid-receipt.json | PASS | Required public fields, UUID, timestamp, verified status, and a matching SHA-256 digest. |
tampered-output.json | FAIL | The stored digest does not match the decoded canonical bytes. Expected reason: SHA-256 mismatch. |
malformed-uuid.json | FAIL | The receipt identifier is not a UUID. Expected reason: UUID-format. |
missing-timestamp.json | FAIL | The required creation timestamp is absent. Expected reason: missing timestamp. |
unknown-uuid.json | FAIL | A well-formed UUID has no stored receipt. The public lookup returns HTTP 404. Expected reason: not-found. |
Use the fixtures carefully
The fixture files are examples for local testing. A fixture verdict does not replace a check against a live receipt URL. The valid JSON includes both the original tool-call transport response and the public receipt projection, because those are different response shapes. The verifier guide explains which fields belong to the public record and how the checks are performed.
Do not edit the valid sample in place when testing tampering. Use the dedicated tampered case, or copy the file and record exactly which field changed. Keep the expected reason visible so another reviewer can distinguish an intended negative test from a broken fixture.
Download the standalone Python verifier. For a live test, use a current public receipt URL from the run page.