Receipts Without Forever

“Cannot be silently changed” does not mean “keep every private byte forever.” I will separate two things. The first is a small write-once receipt: what happened, when, who approved it, and the fingerprints of its inputs and outputs. The second is the encrypted private content, which follows retention and deletion rules.

When data is deleted, we save a deletion receipt and remove every allowed copy we can trace. A legal hold can pause that removal for an approved reason. We record visible facts such as inputs, outputs, permissions, approvals, and tool results. We do not claim that hidden model reasoning is a reliable audit record.

Applications and agents send receipts. Human approvers, customer admins, security responders, privacy officers, legal custodians, auditors, and reliability engineers use them. Version one receives receipts durably, joins the events for one action, searches and exports a timeline, proves whether stored records changed, applies retention and legal holds, and follows a deletion request through prompts, caches, indexes, exports, and backups.

For this mock, we record 50 million actions a day with 12 events each. The service should acknowledge 99 out of 100 writes within 200 milliseconds and make records searchable within 60 seconds. A normal deletion finishes within 30 days, and one action exports within two minutes. We do not store private model reasoning, prove that a model answer is true, or promise deletion from a third-party model we cannot control.

Fifty million actions times 12 events gives 600 million events a day, or about 6,944 a second on average. A ten-times burst is about 69,000 a second. At 2 KB per event, the uncompressed stream is 1.2 TB a day. With four-to-one compression and three copies, storage is about 900 GB a day, 328.5 TB a year, or 2.3 petabytes over seven years.

That size means we cannot keep every field in the fast search database. Recent records and a few safe search fields stay hot; older records move to cheaper locked storage and take longer to query. Large prompts and tool results live as separate encrypted objects identified by file fingerprint. Compliance receipts cannot be sampled, although ordinary performance logs can be.

An Action groups everything that happened during one AI task. Each ReceiptEvent records its event type, actor, trusted arrival time, permission decision, model and tool versions, fingerprints of inputs and outputs, approvals, outside-system receipt, and a sequence number that only increases. It also stores the previous event’s fingerprint, so later edits break the chain.

Large private payloads are separate objects with data class, person or item IDs, region, encryption key, retention rule, and links to the copies created from them. An export is tied to one approved query and returns the events, permitted payloads, proof files, and a small verifier. Stable retry keys prevent duplicate receipts. Deletion and legal hold run as approved background jobs because they may touch many stores.

I would draw four parts: receipt intake, the locked event log, encrypted payload storage, and search/export. The application saves its business change and an event-to-send in one database transaction. A relay sends that event to intake. Intake checks the caller and sequence, writes several durable copies, then replies. Background workers classify private payloads, store them separately, build search, and report missing sequence numbers.

For one payment action, we record the context versions, model response fingerprint, proposed tool call, permission check, human approval, send attempt, and the payment system’s receipt. If the payment call times out, its state is “outcome unknown”; we look it up using the same business key instead of blindly paying again. The audit log cannot share one transaction with the payment service, so saved events and gap alarms make missing records visible.

Each event stores the fingerprint of the event before it. Changing a $100 payment to $1,000 changes that fingerprint and breaks the chain. For faster checks, we combine many fingerprints into a tree-shaped summary called a Merkle root. We regularly sign that root with a protected key and copy it to a separately controlled store. One log administrator therefore cannot rewrite the records and the checkpoint together.

This proves that the exported bytes were present in a particular saved log and have not been changed. It does not prove the original application told the truth or sent every event. For completeness, producers use sequence numbers, and we compare the audit stream with model, tool, and payment logs. That limit is important: cryptography detects tampering; it does not create truth.

First we verify the person and find the source records that belong to them. Then we follow saved links from those records to search chunks, prompts, model outputs, indexes, caches, evaluation sets, exports, and backups. The deletion plan says what to do at each stop: remove bytes, destroy a person-specific encryption key, rebuild a shared document without that person, wait for a backup to expire, or preserve a restricted copy under legal hold.

For example, if one email appears in three search chunks and a shared report, we delete the chunks and rebuild the report without the email; we do not destroy other people’s lawful data. Stable job keys make retries safe. Search and caches are cleared quickly and then scanned for missed copies. After a backup restore, deletion markers run before users can search. We never claim that a third-party model forgot data when we cannot verify that.

The anchored tree-shaped summary fingerprint (Merkle root) no longer matches the recomputed segment, and object hashes referenced by receipt events fail retrieval/integrity verification. The export returns an explicit incomplete status, proof of ledger inclusion, missing-object IDs/classifications, and incident reference—it never fabricates success. We preserve affected storage and access logs for forensics, revoke credentials, rotate keys, and compare replicas/object-lock histories.

To reduce the size of the impact, no single operator controls storage deletion, signing keys, and anchors. Payload deletion requires the policy workflow. Locked write-once storage/object lock protects retained classes. Signed roots are frequent enough to bound the rewrite window. Completeness dashboards continuously sample full proof construction, not only during an audit.

Each person or item has one ordered policy record with a version number that only increases. A legal hold created before the final delete step changes the item to PRESERVE_RESTRICTED. A hold that arrives later cannot restore bytes already deleted lawfully. The worker reads the newest policy immediately before deletion and saves a permanent result showing which command won.

A restored backup starts in an isolated area. It loads the newest signed deletion-and-hold journal and applies those commands before search or application reads are allowed. Every rebuilt store reports which deletion version it has applied; a stale store cannot become ready. Held bytes use separate keys and purpose-limited access, then are deleted when the hold ends if no other legal reason remains.

Ingress partitions by customer and time with quotas plus reserved compliance capacity. Large payloads go directly to object storage so events stay bounded. We preserve minimal receipts before optional enrichments, shed search/index freshness rather than durable capture, and isolate bulk exports/deletion scans from live ingest. Finite retries and failed-job queue retain sequence visibility. Producers spool locally with encrypted bounds when the gateway is unavailable and alert before overflow.

Customer and region separation is enforced in identity, storage accounts or partitions, encryption contexts, queues, indexes, caches, data history, and export workers. Access policy binds case/purpose. Export needs dual approval and field-level redaction. Download URLs expire. Observe ingest gaps, sequence lag, event/object mismatch, Merkle checkpoint/anchor age, proof failures, search lag, deletion node states/SLA, backup expiry, hold access, cross-tenant denial, export completeness, cost/TB, and key health. DR replicates write-once segments/objects and anchors. Restore is gated by integrity verification plus tombstone replay.

First define the receipt schema and threat model with auditors/privacy/legal. Instrument one low-risk workflow using database-backed event queue and sequence checks. Run dual capture against existing logs. Verify proof/export tooling independently. Add payload classification and data history. Pilot deletion end to end including cache/index/backup restore. Enable holds. Then expand to tool/payment actions and more tenants. Keep completeness error budgets and periodic third-party verification.

The trade-off is audit fidelity versus data minimization. Storing full prompts forever makes replay easy but raises privacy, breach, and cost risk. I retain write-once minimal receipts and hashes under policy, encrypt payloads separately with precise data history/retention, and make deletion itself an auditable event. Some regulated replay may be impossible after lawful deletion. The export must say that honestly.

I’ll summarize observable receipts, tamper evidence, completeness limits, and policy-driven data history deletion.