# Chain run, 2026-10-08 Both halves of the AER-1 x Tanilo interop example were checked end to end on 2026-10-08 (about 21:45 UTC), on Tanilo's side, with the files and tools named below. Brennan's half is a worked example: an unsigned AER-1 record whose held call is the example's scenario, not a live execution trace. Everything here was run; nothing is taken from either README. ## What was checked, with what, at which commits | Item | Source | Commit or version | |---|---|---| | AER-1 half (README and `aer1-tanilo-example.json`) | https://gitlab.com/rambozambodotdev/zambo/-/tree/main/aer1-interop/tanilo | repository head `b2b1a4eefe25c7f0f4634c43ede0a310e282feb5`; the directory last changed in `1f91d07` | | AER-1 verifier | `aer1-verifier/aer1_verify.py` in the same repository | same head; file SHA-256 `3a5cf8fa2674d560aff05394a10f4ffc8912d265456237978190ce4de88b932f`; prints `aer1-verify 0.2.1` when run as a file (its `pyproject.toml` says 0.2.3) | | Tanilo half | this directory | `e1206d1a54ae23d7e0f6fed55cd85ca7149275e2` (pinned receipt), `c634554` (current README) | | Tanilo verifier | `tanilo-receipt-verify` from PyPI | 0.2.0 | | Tanilo key set | https://tanilo.io/.well-known/jwks.json, fetched live | SHA-256 `296616c95c3fe2e7ec048b5fe7d4a33050f516a5e3eafd43731197d24eef5691`, identical to `jwks-tanilo-io-2026-10-08.json` here | ## Results 1. **AER-1 worked-example record, Brennan's verifier.** `python3 -I aer1_verify.py aer1-tanilo-example.json`: VERDICT PASS, 15 of 15 checks, exit 0. His test suite also passes. What those checks establish: `canonical_bytes` is strict base64 and UTF-8, 807 bytes as declared; the canonical JSON re-encodes byte-exactly; SHA-256 of those bytes equals `output_hash` (`sha256:574926e9…30075`); the timestamp is a real date not in the future; the outer `receipt_schema_version` (0.4) and `provenance_class` match the values committed inside the bytes. The verifier reads no `evidence_references` (the word does not occur in the file), so steps 2 to 5 of the README's "verifier logic" were done by hand, below. 2. **The evidence reference.** The one `tanilo-receipt` entry carries exactly `canonical_sha256` `sha256-ca2fb84597076f9c8fac2d957a05bf21a11bd741e519879ff09ba78fd2305325`, the raw URL pinned to `e1206d1a…`, and `kid` `tanilo-2026-10-ed25519-7d885da9`. Note that `evidence_references` sits outside `canonical_bytes`, so it is not covered by `output_hash`. The committed text inside the bytes does name the hash: `output.text` contains `Evidence: tanilo-receipt sha256-ca2fb845…05325`. That string is what the hash commitment binds; the reference object is uncommitted metadata beside it. 3. **Fetch and recompute.** The pinned URL returned HTTP 200, 5,232 bytes, file SHA-256 `3feb5a4f…ebd8`, byte-identical to `receipt.jws.json` in this directory. A canonicalizer written here from RFC 8785 (no library) gives 3,655 canonical bytes, equal to `payload.canonical.bin`, and `canonical_sha256` `sha256-ca2fb845…05325`, equal to the reference. 4. **Tanilo signature.** `tanilo-receipt-verify` 0.2.0, `verify(receipt, jwks_by_issuer={: }, jwks_is_complete=True)`: status `valid`, signers `['tanilo-2026-10-ed25519-7d885da9']`, no errors. The offline test in this directory (`test_aer1_interop.py`) also passes, 3 of 3. 5. **Scenario.** The Tanilo payload's `check_results[0].state` is `contradicted` (offer USD 2.00 per call against a caller-supplied term of USD 1.00) and `v_gate.verdict` is `halt`. The AER-1 example's `output.text` describes the follow-on call as HELD with no side effects (the example's scenario, not an execution trace), and its `created_at` 2026-10-08T06:55:04Z is 2 h 07 min after the Tanilo `timestamp` 2026-10-08T04:47:35.336Z. 6. **Control.** Changing one hex digit of the Tanilo hash inside `output.text` and re-running Brennan's verifier gives VERDICT FAIL (hash commitment and provenance binding), exit 1. The commitment does cover that string. 7. **Anchor proof.** `GET https://api.tanilo.io/v1/anchor/proof/sha256-ca2fb845…05325` at 2026-10-08T21:45:09Z returned HTTP 404, `status` `no_proof`. The receipt was issued after that day's batch; the next scheduled run is about 00:46 UTC. `verify_anchor` was therefore not run. Anchoring is scheduled once a day and no per-receipt proof is guaranteed. ## What this run does not establish - **Execution.** Nothing here shows that a `contract-executor` call existed, was attempted, or was held. The AER-1 receipt is a record whose bytes have not changed since its hash was computed; it carries no signature, so the record could have been written by anyone with the Tanilo values. - **Causal reliance.** That the hold happened because of the Tanilo result is stated in the committed text, not demonstrated. Linking the two artifacts to the same canonical payload and key shows they refer to the same bytes, nothing about why. - **Issuer authentication beyond the key sets.** The Tanilo signature shows which key in tanilo.io's published key set signed the payload, under whatever trust the verifier places in that key set. The AER-1 receipt has no issuer authentication at all in this version: the provenance binding checks that two labels agree with the committed bytes, not who committed them. - **The premise.** The USD 1.00 term is caller-supplied and recorded as such (`terms_source: caller_supplied`); the receipt does not show the term is real or that the offer was ever made. - **Timing.** Both timestamps are issuer-declared. The order is consistent with the scenario but is not proven by either artifact; an anchor proof, once present, would bound only when the Tanilo payload existed.