> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

# Deliver an accepted Compute result

## Start with the accepted artifact

Delivery moves an existing accepted artifact to a permitted destination. It does not create a new Compute result or make an unaccepted output correct.

Keep `job_id`, `encrypted_artifact_id`, `result_digest` and `evidence_digest` together with the delivery state. Choose only a destination or retrieval path the customer has authorized. Keep the prepared task brief with those references: frozen instructions and rubric, input IDs, output schema, required evidence and acceptance rule.

Lithi records the accepted artifact and the delivery attempt. Your agent still checks whether the returned work meets the task's semantic acceptance rule; a successful destination write does not make an unsuitable result acceptable. For coding work, the existing agent owns edits, native builds, tests and the final decision.

## Read delivery state separately

Execution and delivery answer different questions: did the work produce an accepted result, and did that result reach its destination?

| Delivery state | Meaning |
| --- | --- |
| **pending** | The accepted result exists; delivery has not completed. |
| **delivering** | The current transfer/write is in progress. |
| **delivered** | The declared delivery completed; verify the destination/object. |
| **failed** | The transfer/write failed; diagnose delivery without rerunning accepted Compute. |

A delivered state is not proof that a person reviewed the content, that an accounting system accepted it, or that an invoice was paid.

## Check, then commit the destination

Use [Files and verification](/docs/compute/results/files-and-verification) for the canonical verification sequence and named levels. The delivery decision starts after you have the accepted artifact and the integrity evidence you reached.

The TypeScript `deliverResult` helper resumes that same artifact. Its `checkResultDescriptor` step establishes only `descriptor_matched`; the caller supplies the transfer channel, decryptor for an encrypted profile, schema and coverage validator, and a `local_directory` destination. `deliverResult` never quotes, submits or reruns Compute. It returns the highest actual level reached, while failed, not-run and not-applicable stages remain visible. `quality_evaluated` is outside kit scope and remains a task-specific customer check.

## Preserve the result and destination contract

Deliver the files and structure named by the result manifest. Preserve stable item identities across output files.

The manifest names required and optional artifact roles, stable IDs, schema or profile versions, media types, sizes, coverage and digest boundaries. Keep item outcomes `accepted`, `failed`, `abstained` and `missing` visible. A validation decision can separately be `accepted`, `failed`, `abstained`, `low_confidence` or `disagreement`; do not turn that decision vocabulary into extra item outcomes. Do not add universal status, model, cost or `_lithi` columns to a customer dataset unless the selected workflow explicitly defines them.

Before committing a destination, reconcile the returned coverage and uncertainty against the brief,
then apply the task's semantic acceptance rule. Integrity, schema validity and a signed receipt are
separate checks; none is semantic correctness by itself.

Customer-visible file partitioning organizes the output for the receiving system. It does not choose execution shards or provider Macs.

Check file count as well as total bytes. Compression and container format change the bytes being verified, so record whether each integrity value covers stored, compressed, encrypted or decoded bytes. Empty, missing and intentionally excluded partitions have different meanings.

If you want a different destination, format or partitioning scheme, treat that as a deliberate new delivery/projection decision rather than silently mutating the accepted artifact.

## Verify the destination write

For a download or pull, verify the complete artifact against the manifest. For a destination adapter, use the supported create-new or versioned write path, then read back the committed object/version when the integration supports that proof. `destination_committed` means the selected local destination was written without overwriting a conflicting object and read back identically; it does not make the business result semantically correct.

A transport response does not prove semantic correctness.

## Recover delivery without rerunning Compute

If delivery fails after the result is accepted:

~~~text title="Recover the existing result" kind="text"
One accepted artifact
same identity + digest
          ↓
Delivery attempt 1 → failed
          ↓
Delivery attempt 2 → uncertain write
          ↓
Inspect and verify the destination

The computation is not rerun.
~~~

Do **not** submit the original input again merely because delivery failed.

Retrieving, verifying or delivering an accepted result again does not rerun the accepted computation. Physical attempts are not automatically customer billing units; use the quote's usage policy and receipt records to reconcile accepted customer usage. A genuinely new Compute request still needs its own quote and approval.

## Handle an uncertain write

If the destination response disappears, inspect the destination before repeating the write. A matching immutable object or commit is an existing delivery to recognize. If the destination is empty, retry only the delivery operation against the same accepted artifact and identity.

If the destination contains a different object under the same intended identity, preserve the conflict and review it rather than overwriting it.

For a result that cannot be read or delivered, use [Result or file help](/help/compute/result-or-file) or [Delivery help](/help/compute/delivery-failed).

Python provides selected result-bundle readers, format adapters, and local-directory destination helpers. It does not expose the full TypeScript delivery path, so keep the transfer, decryption, schema, and coverage boundaries explicit in a Python integration. See [Use the Kit with your agent](/docs/compute/kit/agent-guide) and the [Kit helper reference](/docs/compute/kit/reference) for the language-specific surface.