Compute
Delivery states and acknowledgements
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.
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 — create-new and versioned writes, and conflicting replays.