FlyThink x AER-1: Physical Completion Meets Execution Receipts

An independent builder verified AER-1 receipts against physical completion evidence. Four claim-scope cases, every one replayable, every one passing. The invariant under test: binding without claim inheritance. A valid receipt proves the record was not changed. It never proves the physical thing happened.

Replay it yourself: fixture and verifier at hippoley/FlyThink-Anatomy-Demo, stable commit 01297c1d.

What was tested

FlyThink builds execution evidence for physical systems. The interop fixture binds AER-1 execution receipts to physical completion claims and checks that the two claim scopes never leak into each other. The fixture is aligned to the published draft-zambo-aer1-14 core: observed execution record, canonical bytes and output commitment, tool metadata, and provenance. The current revision of the draft is draft-zambo-aer1-23; this fixture remains aligned to the -14 core it was built and verified against.

node interop/aer1-physical-completion/verify_fixture.cjs

The four cases

CaseAER receiptPhysical completionResult
1ValidProvenPASS
2ValidIndeterminate (stale readback)PASS
3Invalid (canonical bytes no longer match output hash)Still provenPASS
4ValidEvidence invalid (criterion not authorization-bound)PASS

Every case replayed independently with zero errors. The cases were designed as negative tests: they probe exactly where a naive reading would let one claim inherit the other.

Why case 4 matters most

Case 4 is a valid AER receipt paired with invalid physical evidence. The receipt checks out completely: the bytes match, the hash verifies, the provenance is clean. The physical completion claim still fails, because its own criterion was not authorization-bound.

This is the whole standard in one case. A verifiable receipt proves the saved execution record was not changed. It does not prove the model was right, the decision was fair, or the physical thing happened. Any system that reads a valid receipt as proof of the outcome is doing claim laundering, and this fixture is the test that catches it.

Binding without claim inheritance: the receipt binds to the referenced evidence, but the receipt's validity never transfers to the referenced claim. Each claim stands or falls on its own verification.

What this means for the standard

An independent party read the draft text, built a fixture against it, and found no gap: the -13 core handles the claim-scope separation correctly. That is what a standard looks like in practice. Not an announcement, but a stranger verifying your work and finding it sound.

This is the second live independent interop validation of AER-1, alongside the Tanilo receipt interop, which verified a full two-party receipt chain end to end.

Build on the standard: mint a verifiable receipt in 30 seconds, verify it at zambo.dev/verify, no signup.

Browse the public registry of AER-1 implementations.

See it on a real call: the live demo runs one real Zambo call and hands you its verifiable receipt, no signup. To put a receipt under every call your agent makes, a Zambo Day Pass unlocks everything for 24 hours for $0.99.