Key points
- A receipt identifies the recorded request, operation, result hash, usage, and timing without requiring the raw result to be public.
- A hash chain preserves sequence; changing one linked record breaks the following relationship.
- A Merkle proof verifies membership in a batch using a compact path rather than exporting every receipt.
The role of a per-request receipt
The receipt is the unit a customer can retrieve and cite when an outcome is questioned. It should carry stable identifiers and enough normalized fields to recalculate the recorded hash. Sensitive application data should remain outside the receipt or be represented by a digest.
Receipt creation can be optional because not every random byte needs long-term evidence. The policy should be explicit: when receipts are enabled, the service either records the receipt or returns a clear failure. Silently dropping evidence after a limit is reached creates a false sense of coverage.
Hash chains make sequence changes visible
Each receipt can include the digest of the previous receipt in the same integrity scope. Reordering, changing, or removing an earlier record then changes the links that follow. The chain does not prevent every operational failure, but it makes a class of after-the-fact edits detectable during verification.
Scope matters. A chain may be maintained per tenant or another defined boundary so one customer can inspect its records without receiving another customer’s history. The verifier must know the chain identifier and expected sequence rules.
Merkle proofs reduce the cost of batch verification
A Merkle tree combines receipt hashes until one root represents the batch. To prove that one receipt belongs to that batch, the service exports the receipt hash, sibling hashes along the path, and the root. The verifier recomputes the path and compares the resulting root.
The proof establishes membership in the recorded batch. Its value increases when the root is retained separately, signed, or delivered to an independent location. A proof generated from a root that only exists in the same mutable system has a narrower assurance boundary.
Retention, export, and deletion need one policy
Receipt retention should match the customer’s review window and the contract. Expiration jobs must remove receipt data, related indexes, exports, and recoverable backups according to the same policy. Before deletion, customers may need an export containing receipts, chain fields, Merkle proofs, and verifier instructions.
- Test normal verification and tampered-field verification.
- Record export creation and download as auditable actions.
- Publish the hash and signature algorithms with a version identifier.
- Keep a replay procedure for failed receipt processing and dead-letter queues.