> ## 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: Delivery states and acknowledgements
description: >-
  Every delivery state, what separates writing from verification, commit and
  your acknowledgement, and the next action for expired authority, a commit
  conflict and a failed registration.
route: /docs/compute/delivery/states-and-acknowledgements
page_id: docs-compute-delivery-states-and-acknowledgements
page_type: reference
content_layer: technical reference
surface_profile: technical_reference
audience: Integrators handling Compute delivery records programmatically
voice: D
reader_question: What does each delivery state mean, and what do I do about it?
primary_action: Follow the next action carried on the delivery state
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-delivery-states-and-acknowledgements-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"
---

## The delivery path

`PLANNED → AUTHORITY_READY → WRITING → WRITTEN_UNVERIFIED → VERIFIED → COMMITTED → CUSTOMER_ACKNOWLEDGED`

| State | What has happened | What has not |
| --- | --- | --- |
| `PLANNED` | A delivery exists for this bundle and destination | No authority has been obtained |
| `AUTHORITY_READY` | A scoped, time-bounded destination authority is current | No bytes have moved |
| `WRITING` | Bytes are going to the destination | Nothing has been checked |
| `WRITTEN_UNVERIFIED` | Bytes are at the destination | Nothing confirms they are correct or complete |
| `VERIFIED` | What landed matches the manifest's files, counts and digests | The provider has not committed them |
| `COMMITTED` | The provider's own commit succeeded and readers can see the data | You have not confirmed receipt |
| `CUSTOMER_ACKNOWLEDGED` | You confirmed you took the delivery | Nothing further; this is terminal |

Four separate acts sit in that path: writing, verification, the provider's commit, and your acknowledgement. Collapsing any two of them hides a failure the other one would have caught.

## Non-success states and next actions

| State | Meaning | Next action |
| --- | --- | --- |
| `AUTHORITY_EXPIRED` | The destination authority lapsed before the write completed | Reauthorize the destination and resume the same accepted bundle |
| `WRITE_FAILED` | Bytes did not reach the destination | Confirm the destination is reachable, then resume the same bundle |
| `VERIFY_FAILED` | What landed does not match the manifest | Discard the partial object, then resume; never commit unverified bytes |
| `COMMIT_CONFLICT` | The target already holds accepted bytes with a different digest | Compare digests, then deliver to a new path or version |
| `CUSTOMER_REGISTRATION_FAILED` | Your side rejected or could not register the delivery | Fix the registration on your side, then re-request the acknowledgement |
| `QUARANTINED` | The delivery was withheld pending review | Read the typed reason, resolve it, then re-plan the delivery |
| `CANCELLED` | The delivery was stopped deliberately | Plan a new delivery if you still need one |

Every one of these carries a safe reason and a non-empty next action in its envelope. Read the envelope's `next_action` rather than inferring one from the state name.

## What none of these states affects

None of them changes the job. A compute run that reached `SUCCEEDED` stays succeeded, and its charge stands.

Delivery is a separate event with separate evidence. A destination outage is never a reason to resubmit paid work you already own.

## Acknowledgement

`CUSTOMER_ACKNOWLEDGED` is yours to set, not something Compute infers. It records that your side took the delivery and accepted responsibility for the bytes.

Send it after your own registration succeeds, not when `COMMITTED` appears. The gap between those two is exactly where `CUSTOMER_REGISTRATION_FAILED` lives.

An unacknowledged `COMMITTED` delivery is complete on the Lithi side and open on yours. Reconcile that gap on a schedule rather than leaving it to chance.

## Reading a delivery record

Each record carries the response envelope fields: `request_id`, the operation, the contract release, the typed state, an evidence class, `observed_at`, `valid_until` and a structured `next_action`.

`observed_at` and `valid_until` bound the reading. A state read after `valid_until` is a stale observation and needs re-reading before you act on it.

Delivery attempts are recorded independently of the job. Several attempts against one accepted bundle is normal, and each keeps its own state and evidence.

## Next, write the commit

Once the authority is ready, the write mode decides what a repeat attempt does.

- [Write immutable commits](/docs/compute/delivery/immutable-commits) — create-new and versioned writes, and conflicting replays.