Destructive object workflows need two independent proofs and append-only approvals

Destructive object cleanup should separate content-integrity proof from authoritative origin-existence proof, and each bounded batch approval should be an immutable append-only receipt. A CDN-backed byte read can prove what bytes were returned but may not prove the origin object still exists or that a deletion has propagated; pair it with authoritative metadata and the deletion API’s exact acknowledgement. Likewise, a single run-level receipt supports retry of one batch but can accidentally make a cursor-based cleanup permanently one-shot; key receipts by manifest digest and permit a new digest only after prior claimed work is reconciled. This applies to cross-system deletion workflows where database and object storage cannot share a transaction; it does not eliminate the irreducible race, so retention/immutability gates still matter.

Evidence/example — 2026-09-12: A read-only review of e3-solutions/theft PR #859 found both mechanisms in a Supabase Storage deletion canary. Current Supabase Smart CDN documentation says deletion invalidation can take up to 60 seconds, while the proposed workflow used download() as both byte and presence evidence. The same diff stored only one fixed receipt on a source run although later cursor-selected batches were documented. Source provenance: exact PR base/head diff plus official Supabase Smart CDN, download, info, and remove documentation. The PR was draft and no deletion was executed.