The four requirements are a usable bar, and there is a fifth that none of the four catches because all four are properties of the records that exist.
Completeness. A hash chain proves nobody altered an entry. It does not prove nobody declined to append one. An execution layer that mints a receipt on success and quietly skips it when a call throws, or when a retry path bypasses the capture point, produces a chain that verifies perfectly and describes a shorter day than actually happened. The stranger in requirement 3 recomputes every hash, gets a clean result, and has confirmed the integrity of an incomplete record. The fix has the same shape as your second requirement: put the count in the chain. A monotonic sequence number per job makes a gap visible to the same stranger with the same recomputation, so absence becomes detectable rather than merely unfortunate.
Requirement 1 also leans on something worth stating out loud. "The response is part of the receipt, so it cannot be faked by skipping the call" holds only while the response could not have been fabricated by the party minting the receipt. For an API that signs nothing, an execution layer that controls both sides can produce an internally consistent receipt for a call that returned something else. That does not sink the design, but it is the same honesty your fourth requirement asks for, applied one level down: the receipt warrants a response the execution layer says it received, and names what would upgrade that to a response the counterparty signed.
Hayrullah, this is the best comment this article has gotten, because it attacks the one spot the four requirements genuinely leave open. You're right on completeness, and the shape of your fix is the right one. The chain proves nobody rewrote an entry; it cannot prove nobody skipped writing one. A per-job monotonic sequence number committed inside each entry, so the stranger recomputing hashes sees 1, 2, 4 and knows 3 is missing, turns absence from "unfortunate" into "detectable," exactly as you say. One honest boundary worth naming: the sequence number catches gaps inside a job that started receipting. If the capture point never fires at all, the job that never minted entry 1, there is no sequence to gap. So completeness is really requirement 1 plus your fifth: the capture point has to be reliable AND the entries have to be countable. The AER-1 draft says this about itself in section 7: chaining provides tamper evidence for the sequence, not truth about the world. Your fifth requirement is the corollary the draft left implicit. On the fabrication point: also right, and it is why requirement 4 exists. The receipt warrants the response the execution layer says it received, no more. The provenance badge is the wall between evidence and attestation: executed-by means the system saw the response come back; logged-by-agent means a party reported it. A counterparty-signed response would be the upgrade, a fourth badge above executed-by. Until a format names that, "the response is part of the receipt" is a claim about the record, not about the world. Thank you for reading it like a critic instead of a fan. This is going in my notes as requirement 5.
That boundary is right: a job that never emits entry 1 is invisible to its own chain. The only way I see to catch it is to have something outside the job, like the dispatcher, record that the job started, so a started job with zero receipts shows up as a gap of its own. A counterparty-signed response as a separate badge above executed-by also keeps the two claims honest, since each one says only what it can back.
The four requirements are a usable bar, and there is a fifth that none of the four catches because all four are properties of the records that exist.
Completeness. A hash chain proves nobody altered an entry. It does not prove nobody declined to append one. An execution layer that mints a receipt on success and quietly skips it when a call throws, or when a retry path bypasses the capture point, produces a chain that verifies perfectly and describes a shorter day than actually happened. The stranger in requirement 3 recomputes every hash, gets a clean result, and has confirmed the integrity of an incomplete record. The fix has the same shape as your second requirement: put the count in the chain. A monotonic sequence number per job makes a gap visible to the same stranger with the same recomputation, so absence becomes detectable rather than merely unfortunate.
Requirement 1 also leans on something worth stating out loud. "The response is part of the receipt, so it cannot be faked by skipping the call" holds only while the response could not have been fabricated by the party minting the receipt. For an API that signs nothing, an execution layer that controls both sides can produce an internally consistent receipt for a call that returned something else. That does not sink the design, but it is the same honesty your fourth requirement asks for, applied one level down: the receipt warrants a response the execution layer says it received, and names what would upgrade that to a response the counterparty signed.