> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Retention, holds and deletion description: >- Result retention, metadata retention, destination retention and key retention are four different clocks. Place a hold, request deletion, and read the deletion back before you record it. route: /docs/compute/results/retention-and-deletion page_id: docs-compute-results-retention-and-deletion page_type: howTo content_layer: guided documentation surface_profile: guided_docs audience: Compute customers and organization administrators managing data lifecycle voice: D reader_question: How long is my result kept, and how do I confirm it was deleted? primary_action: Read the deletion back before you record it source_locale: en-US source_status: APPROVED source_version: docs-compute-results-retention-and-deletion-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## Four clocks, not one Deleting a result does not delete everything connected to it. Four separate retentions apply, and each is governed differently. - **Result retention** — the bundle itself: accepted outputs, exceptions, metrics and verification evidence. `result-manifest.json` binds the retention rule for the run it completes. - **Metadata retention** — receipts, audit records and configuration events. These are content-free projections and are kept to their own schedule. - **Destination retention** — anything written into a store you registered. Those bytes are yours, in your system, under your policy. - **Key retention** — the material behind encryption at rest and your download authority. Its lifetime is independent of the bundle's. Ask which clock you mean before you ask how long. A question about "how long results are kept" usually turns out to be two of these at once. ## Access expiry is not erasure An artifact that reaches `EXPIRED` has lost its download authority. You can no longer read it, and that is all the state says. **Expired access is never confirmed erasure.** The erasure states are separate: an artifact moves `EXPIRED`, then `DELETING`, then `DELETED`. If you need a record that data is gone, `EXPIRED` will not do. Request deletion and read it back. ## Place a hold when you need one A hold suspends deletion for material you must preserve, for a dispute or an obligation of your own. Place it before the retention window closes, not after. While a hold is in place, deletion requests against the held material are refused with a typed reason and a next action. That refusal is the hold working. Release the hold deliberately when the reason ends. A forgotten hold keeps data you meant to remove. ## Request a deletion and read it back Deletion follows the same loop as every other change you make. Plan it, approve it where approval is required, apply it, then read the result back. 1. Confirm which of the four retentions your request actually covers. 2. Confirm no hold applies to the material. 3. Submit the deletion and record the request reference. 4. Read the state back and confirm it reports `DELETED`. 5. Check the events record for the resource so the confirmation is durable. Step four is the one people skip. A submitted request is a request; the read-back is the evidence. ## Destination copies are yours to delete If a result was written to a store you registered, that copy is outside the bundle's retention. Deleting the Lithi-side bundle leaves your copy exactly where it is. Delete it in your own system under your own policy, and record that separately. Revoking a destination stops future writes; it does not remove past ones. Where a workflow wrote to several destinations, each needs its own deletion. Your delivery records tell you which ones received bytes. ## What success looks like Every retention you meant to end reports a terminal deletion state, read back rather than assumed. Your metadata record shows the request, the approval and the confirmation. Nothing is sitting under a hold you no longer need. Any copies in stores you own have been dealt with under your own policy. ## If a deletion is refused Read the typed reason and the next action. The usual causes are a hold, a missing management scope, or a resource version that moved since you planned the change. A refusal is never a reason to retry blindly. Re-plan against the current state, then apply again. To register or revoke the destinations involved, start with [registering a destination](/docs/compute/configure/destinations). Where the request touches an ongoing dispute or an obligation, contact support with the job and request references. Support never needs a payload dump, a key or a signed link.