Retention: what a deadline deletes, and what a tombstone keeps

Two scopes, set independently

Input retention

Your prompt and the parameters you sent, wherever they live: the job projection, the job.created event, the submit echo, provider error bodies that quote the request back, and any input files Wakemark mirrored so a lineage source could not rot.

Output retention

The generated bytes and their sidecar, plus the output URLs and any inline output payloads carried in raw provider responses. The default keeps outputs indefinitely, because for most customers an output that disappears is the problem, not the policy.

Each scope takes one of: keep nothing, keep only until the job finishes and a short retrieval window closes, keep for a fixed duration, or keep indefinitely. A per-job override can tighten or relax a project's policy for a single job, and the effective policy is frozen onto the job at creation so a later policy change cannot retroactively alter what was promised.

What a purge actually removes

Deleting objects from a bucket is not retention, and a product that pretends otherwise is making a false claim. Content lives in the ledger and the projections too, so a purge reaches all of them: the stored object and its sidecar, the input on the job row, the provider error text that quotes it back, the raw provider payloads that embed output URLs or inline output bytes, and the free-text failure messages that can carry either.

What replaces each one is a redaction marker — the SHA-256 and length of what was removed, plus which policy removed it. The audit trail proves what was purged without keeping it.

What a tombstone is

The row survives; the content does not. An asset whose bytes have been purged keeps its id, its digest, its size, its content type and its place in the lineage graph — marked with the moment it was purged. So the record of what existed, and the ability to check a file you still hold against the digest we recorded, both outlive the bytes.

This is the deliberate opposite of account deletion. Retention keeps the rows as tombstones and appends an evented redaction record: it deepens provenance rather than erasing it. Offboarding deletes the rows and keeps only a content-free receipt.

Account deletion is a different thing

Requesting deletion freezes the account and purges provider credentials immediately. A grace period follows during which the account can generate nothing but can still cancel the deletion or download a full export. At the deadline a hard purge deletes the content stores Wakemark controls.

What survives is content-free and disclosed: an erasure receipt carrying a one-way-hashed account identifier, a timestamp and counts of what was deleted; anonymised usage-metering rows whose account and project references are replaced by the same one-way hash; and a one-way-hashed record that a welcome email was once sent, so re-registering does not send it twice. The current, authoritative list is in the account deletion section of the Privacy Policy.