> ## 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: Register a destination for results description: >- Pick a destination your account allows, choose an immutable write mode, test commit permission before you rely on it, and record the scope, expiry and recovery steps. route: /docs/compute/configure/destinations page_id: docs-compute-configure-destinations page_type: howTo content_layer: guided documentation surface_profile: guided_docs audience: Administrators deciding where Compute results are written voice: D reader_question: How do I let Compute write results where my team can use them? primary_action: Set spend ceilings and approvals source_locale: en-US source_status: APPROVED source_version: docs-compute-configure-destinations-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" --- ## Before you start You need an administration credential, a stored write credential, and one workflow whose output you want delivered. A work key cannot register a destination. Decide who owns the destination before you register it. Somebody has to renew its authority and answer for what lands there. ## Choose a destination your account allows Describe the destination family first, then list what is already registered. Do not assume a target is permitted because you can reach it yourself. The destination must satisfy two things at once. Your account policy has to allow it, and the workflow's output declaration has to support it. A destination that passes only one of those refuses at admission, not at delivery. Register the smallest scope that works. A prefix or a dataset is a better grant than a whole account. ## Choose an immutable write mode Results are written once, to a new location, and never over an existing one. Choose the write mode that reflects that. Your request's `output` object declares the format, the destination and the result partition. A repeated delivery writes a new partition rather than replacing the previous one, so an earlier result stays readable and explainable. This is why a re-delivery never needs a re-run. The bundle already exists; only the write is repeated. ## Test commit permission before you depend on it A destination write finishes in two stages. Bytes are written, then the write is committed and verified. Many credentials can create an object but cannot commit or finalize one. That gap does not appear until real work is delivered, which is the worst moment to find it. Use the destination family's `test` operation and confirm it reaches a committed state. If it stops short, fix the grant now. ## Record the scope, expiry and recovery Write three things down where your team can find them, next to the destination's own record. - The exact scope you granted, and the credential reference it uses. - The expiry of the delivery authority, and who renews it. - What to do when a delivery fails, including who holds the destination. Delivery authority is deliberately time-bounded. `AUTHORITY_EXPIRED` means the permission lapsed, not that your result is lost. ## Confirm success The destination reads back as `VERIFIED`, its test reaches a committed write, and a job's delivery progresses to `COMMITTED` and then to `CUSTOMER_ACKNOWLEDGED`. Do not treat `WRITTEN_UNVERIFIED` as done. The bytes exist, and nothing has confirmed them yet. ## When a delivery fails Each failure names its own reason and its own next action. Read them together. - `AUTHORITY_EXPIRED` — renew the authority, then retry the delivery. - `WRITE_FAILED` — check the destination is reachable and the grant is intact, then retry. - `VERIFY_FAILED` — the write could not be confirmed, so re-verify before treating it as delivered. - `COMMIT_CONFLICT` — something else holds the target partition, so resolve it and deliver to a new one. - `QUARANTINED` — the delivery is held pending review; follow the stated next action. None of these requires re-running the work. See [what each delivery state means](/docs/compute/delivery/states-and-acknowledgements) before you retry anything. [Set spend ceilings and approvals](/docs/compute/configure/spend-and-approvals)