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.
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.