> ## 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: State reference description: >- Every public Compute state value — job, stage, artifact, delivery, configuration and commercial — with its terminal rule, the safe next action, and the four refusals you must keep apart. route: /docs/compute/reference/states page_id: docs-compute-reference-states page_type: reference content_layer: technical reference surface_profile: technical_reference audience: 'Integrators writing status handling, retries and operational alerts' voice: D reader_question: 'What does this state value mean, and what should I do next?' primary_action: Follow the next action on the response source_locale: en-US source_status: APPROVED source_version: docs-compute-reference-states-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" --- ## Job states Eight values. Four are terminal. | State | Terminal | Safe next action | | --- | --- | --- | | `ADMITTED` | No | Wait. The job is accepted and priced. | | `RUNNING` | No | Poll status. | | `AWAITING_REVIEW` | No | A person must decide. Open the job in the portal. | | `PARTIAL` | Yes | Download the bundle. Read `failures/`, then resubmit only those items. | | `CANCELLING` | No | Wait for `CANCELLED`. Running stages are stopping. | | `CANCELLED` | Yes | Quote and resubmit if you still need the work. | | `FAILED` | Yes | Read the next action on the response, correct it, quote again. | | `SUCCEEDED` | Yes | Download the bundle and check `result-manifest.json`. | `AWAITING_REVIEW` is the value most often mistaken for terminal. Nothing advances until a person acts. ## Stage states Eleven values: `BLOCKED`, `READY`, `MATERIALIZING`, `RUNNING`, `VERIFYING`, `AGGREGATING`, `SUCCEEDED`, `PARTIAL`, `FAILED`, `SKIPPED`, `CANCELLED`. Stage states explain a job state. They never replace it. A job is not finished because one stage reads `SUCCEEDED`, and a `SKIPPED` stage is a normal outcome, not a fault. ## Artifact and delivery states An artifact moves in one direction: `PLANNED`, `UPLOAD_AUTHORIZED`, `UPLOADING`, `UPLOADED_UNVERIFIED`, `VERIFIED`, then one of `ACCEPTED`, `REJECTED` or `ORPHAN_QUARANTINED`, then `DELIVERABLE`, `EXPIRED`, `DELETING`, `DELETED`. `UPLOADED_UNVERIFIED` means bytes arrived and nothing has checked them yet. Do not treat it as success. On `REJECTED`, fix the file and upload again. On `ORPHAN_QUARANTINED`, the upload has no owning request, so start the request again. On `EXPIRED`, re-authorize an upload rather than retrying the old one. Delivery follows its own sequence. The normal path is `PLANNED`, `AUTHORITY_READY`, `WRITING`, `WRITTEN_UNVERIFIED`, `VERIFIED`, `COMMITTED`, `CUSTOMER_ACKNOWLEDGED`. | Exception | Safe next action | | --- | --- | | `AUTHORITY_EXPIRED` | Re-authorize the destination, then retry the write. | | `WRITE_FAILED` | Retry the write. The job does not rerun. | | `VERIFY_FAILED` | Retry the write. The bytes are not trusted yet. | | `COMMIT_CONFLICT` | Resolve the conflicting object at the destination, then retry. | | `CUSTOMER_REGISTRATION_FAILED` | Register the destination again and test it. | | `QUARANTINED` | Contact support with the request identifier. | | `CANCELLED` | Plan the delivery again if you still need it. | A failed delivery never means a failed job. The result exists; only its write to your destination did not complete. ## Configuration apply states Per resource: `PLANNED`, `WAITING_APPROVAL`, `READY`, `APPLYING`, `APPLIED_UNVERIFIED`, `VERIFIED`, `ALREADY_MATCHED`, `REFUSED`, `CONFLICT`, `RETRYABLE`, `REVOKED`, `ROLLED_BACK`. The aggregate result is `COMPLETE`, `PARTIAL_WITH_NEXT_ACTION`, `REFUSED` or `EXPIRED`. `ALREADY_MATCHED` means the resource was correct before you asked, which is a success. `PARTIAL_WITH_NEXT_ACTION` means some resources applied and the response tells you what is left. Re-applying the same change returns its prior verified result. `ROLLED_BACK` never implies an invitation, an external write or a payment was undone. ## Commercial states Five separate state machines run here, and they are not one pipeline: `lithi_invoice_state`, `erp_sync_state`, `erp_approval_state`, `mercury_payment_state` and `reconciliation_state`. The milestones you can observe across them are `INVOICE_FINALIZED`, `ERP_CREATED`, `ERP_APPROVED`, `PAYMENT_INITIATED` and `MERCURY_FUNDS_CONFIRMED`. A hosted payment action reports `unavailable`, `ready`, `opened`, `expired` or `revoked`. On `expired` or `revoked`, open a fresh action from the invoice rather than reusing the old link. Only a current Mercury read-back advances the Lithi payment projection to paid. A `Paid` label in your ERP is an annotation, never settlement. ## The no-void status law No operation returns an empty verdict. Every response resolves to `SUCCEEDED`, `SAFE_FAILED`, `BLOCKED`, `REPLAN_REQUIRED`, `CANCELLED`, `EXPIRED` or `SKIPPED`. Every non-success carries a safe reason and a non-empty next action. If your handler has a branch for "no status", that branch is unreachable and should raise instead. Four refusal classes must never be collapsed into one rate-limit state. - `EDGE_ABUSE_LIMITED` — perimeter load shedding. - `CANONICAL_ADMISSION_LIMITED` — your key or account's request authority. - `CANONICAL_BUDGET_EXHAUSTED` — spend authority. - `CELL_CAPACITY_UNAVAILABLE` — current capacity. Only the budget class is lifted by an approval. ## Quotes carry no state enum A quote is not a state machine. It carries `non_authorizing = true`, an expiry and a signature. So there is nothing to poll. If the expiry has passed, quote again. If admission answers `REPLAN_REQUIRED`, the priced request drifted from what you submitted, so quote again and resubmit. See [what each work operation returns](/docs/compute/reference/work-api) for where these values appear.