# AER-1 two-verifier divergence fixture (Tanilo interop worked example)

Same bytes, two verifiers, divergent outcomes — the regression-fixture shape.

- `aer1-tanilo-example.json` — the AER-1 worked-example record from
  rambozambodotdev/zambo `aer1-interop/tanilo` (GitLab), fetched
  2026-10-09T03:5xZ. Upstream may drift; the bytes here are pinned by their
  own sha256 (the filename on the sha rail IS the digest).
- `verify-out-arion.json` — output of ARION's `verify.js` (full draft
  table, sha rail digest e6c2370586fd9c401567a2b8c10d4757ae62e316bb4013431962061e38161ff)
  on those exact bytes: FAIL — missing required member
  `verification_status` (draft Table 1). Additional firsthand observations
  not yet hard-failed by our checker: `id` = "tanilo-interop-001"
  (non-UUID format); `receipt_schema_version` "0.4" with no
  `metadata_hash` member; `tool`, `caller`, and `evidence_references`
  members are string-encoded dict-reprs ("{'name': ...}") rather than
  JSON objects.
- `verify-out-tanilo.json` — the issuer's chain-run report
  (chain-run-2026-10-08.md, renamed): aer1-verify 0.2.1 (its pyproject
  says 0.2.3) VERDICT PASS 15/15 on the same example class. Their checks
  are the commitment + version + provenance subset — narrower than the
  draft's required-member table, which is exactly why the same bytes
  diverge.

Usage: run both verifiers on the pinned bytes; expected outcomes differ.
That is the fixture. A verifier that claims draft-conformance must fail
this file; one that checks only the committed-hash subset may pass it.