The room, and the question on the table
A working draft called Proof of Control is trying to settle a question every agent builder will eventually have to answer: what is the minimum evidence a system should produce about what its agents did?
The draft is stewarded by the Advanced AI Society and hosted as a lab at LF Decentralized Trust. It runs to 127 requirements across 10 chapters, and it is strong on what evidence must achieve: contemporaneous, tamper-evident, deterministic, and verifiable by parties who do not trust the operator. The public comment window is open until October 30, 2026, and the comments arriving are from people who build these systems for a living. The repository is public: https://github.com/LFDT-ProofOfControl/ov-poc-standard
One open item, in chapter C8, asks the sharpest version of the question. Tier 1 is the draft's lowest evidence level, called "Recorded." Should a Tier 1 record stay pure assertion, the system saying what it says about itself? Or should even the lowest tier have a floor: a timestamped, attributed record that a receiver can at least check for integrity?
We filed a public comment on this draft, and our interest should be stated plainly. We build Zambo. Brennan Zambo, Zambo's creator, is the author of AER-1, an IETF Internet-Draft for verifiable AI agent execution receipts, currently at revision 19 (https://datatracker.ietf.org/doc/draft-zambo-aer1/19/), and he filed a public comment on this draft. What follows is the plain-language version of that exchange: what the proposed floor asks, what an execution receipt already provides today, and the one place our format answers by disclosure instead of by mechanism.
The floor, part by part
The floor on the table comes from Doug Fir Labs, an implementer running an operator-signed hash-chain evidence system. Their five-part public comment (issues #115 to #119 in the repository) ends with a proposal to resolve the C8 open item as a floor with three parts (https://github.com/LFDT-ProofOfControl/ov-poc-standard/issues/119):
A capture timestamp (requirement 7.2.1). The record states when the event was captured, at the moment it happened, not reconstructed from logs afterward.
A tagged digest of the record (7.7.3). A hash of the record that carries its algorithm with it, so a receiver can recompute it without guessing which hash was meant.
An attribution that states its basis (5.2.2). Either self-asserted, meaning the signing key arrived with the record itself, or bound to published key material. Self-asserted attribution keeps the record at Tier 1; attribution bound to the operator's published key is the Tier 2 case. And the verifier's result states which basis it found, instead of leaving the receiver to assume one.
Their costing is blunt: the floor costs a hash, a timestamp, and one enumerated field. In exchange, the lowest tier of evidence becomes re-checkable by whoever receives it. A Tier 1 record stays Tier 1, but it stops being pure assertion.
What a receipt gives you today
AER-1 receipts were built to this shape independently, before this comment round opened. That two implementation lines arrived at the same floor from separate systems is, we think, evidence the floor is a property of the problem rather than of either system. Two of the three parts are met directly.
The timestamp. A receipt is issued by the producing tool at execution time and carries the capture timestamp of the event. It is not assembled from logs later.
The tagged digest. Every digest a receipt itself carries (the output hash, the metadata hash, and the optional input hash) bears an explicit algorithm tag: sha256: followed by the hex digest. A receiver can recompute each commitment from the saved bytes with nothing to guess. One scoping note, included because this piece is about stating things precisely: the receipt chain and the workflow Merkle root are carried as bare hex, fixed to SHA-256 by the specification itself rather than by a per-field tag. The tag rides on the digests the receipt carries; the construction digests are identified by the spec.
The outcome, in band. Every receipt carries a verification_status field, so the outcome of checking it travels with the record in machine-readable form. The claim stays narrow on purpose: a receipt establishes that the saved result was not changed since it was saved. It does not establish that the result was correct, and it asserts nothing about quality or intent.
None of this needs to be taken on description. Here is a real receipt, minted by the public demo: https://zambo.dev/run/92874efd-7bc4-427c-b262-862dfcf6d82d. It records a live_price call at 20:24:37 UTC on October 13, 2026, with the full saved output (a Bitcoin price, $83,139.00 via CoinGecko) and the output digest sha256:65faa90980caf70dfb5fc14f3c38c82db8a154ce3a6e2d274e943b83209b1d06. Anyone can open the record, recompute the digest from the saved bytes, and watch it match. Whether that price was right is a question the receipt deliberately does not answer. Run the demo yourself and check a fresh one: https://zambo.dev/demo/
The third part is the honest one
Attribution is where AER-1 stops meeting the floor by mechanism and starts meeting it by disclosure.
An AER-1 receipt has no signing key. The draft says so on its face: Section 13 states that issuer authentication is not part of the specification. Anyone can mint a well-formed receipt. Without an out-of-band binding between a key and an identity, a receipt is self-asserted as to origin, full stop. The format does not perform published-key attribution, and it does not claim to.
That is a deliberate layering decision, and the filed comment states it directly. Where a deployment needs attribution bound to published key material, that binding belongs to a signature scheme documented alongside the receipt, the layering the draft itself prescribes. It does not belong baked into the receipt format, and the artifact layer neither performs it nor pretends to.
The floor's third part asks that attribution state its basis. AER-1 states its basis in the specification, in plain words, where every implementer and verifier can read it: self-asserted as to origin, unless a mechanism outside the format establishes more. A floor you can state plainly is a floor builders can actually meet. One that invites quiet overclaiming will not hold, no matter how good it looks in the catalogue.
What happens next
The comment window closes October 30, 2026. Under the repository's contributing terms, comments filed in the window receive a published disposition: accepted, rejected with rationale, or deferred. A revised draft is targeted for November 15, 2026.
The filed comment proposes that the draft cite AER-1 as a receipt artifact format for its record-level requirements, and offers an implementation report, test-vector cross-checks, and annex text if the group wants them. That outcome is the group's to decide. The floor question is the one that outlasts this draft. Every agent system is producing records of what it did. The only live question is whether those records carry the minimum that lets a stranger check them: when it happened, a digest that says which hash it is, and an attribution that says what it is worth.
That minimum is cheap. It is a hash, a timestamp, and the honesty to state a basis.
Your AI said "done." For $0.99, prove it: https://zambo.dev/day-pass/
Top comments (0)