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

# Read and verify Compute result files

## Follow the verification sequence

Use the existing result identity and work through these questions in order:

1. **Which result is this?** Read the result descriptor and manifest.
2. **May I retrieve it?** Check the unexpired transfer permission and recipient key.
3. **Did the bytes arrive unchanged?** Verify the declared size and digest at the stored-byte boundary.
4. **Can I authenticate and decode them?** Apply decryption and schema checks when the delivery profile requires them.
5. **Does the result cover the task?** Reconcile stable item IDs, outcomes and required evidence.
6. **Can I write it safely?** Commit to the selected destination and read the object back.

The sequence verifies the existing artifact. It does not decide whether the returned work is useful or semantically correct; your agent applies the prepared task brief and acceptance rule after the file checks. For coding work, that agent owns the local edits, native builds, tests and final acceptance. If the read or delivery response is uncertain, [reconcile the existing job and result identity](/docs/compute/jobs/idempotency-and-retries) before trying again.

The [Compute paper's execution and acceptance section](/papers/compute#run-on-shared-macs-and-accept-results) explains why a returned candidate becomes accepted work only after its checks.

## Start with the existing result descriptor

The descriptor identifies the job, output and delivery state. The manifest lists the files, formats, sizes and expected items. Check these records before retrieving files; this step does not check file bytes.

| Record | Fields to check |
| --- | --- |
| Result descriptor | `job_id`, `encrypted_artifact_id`, `result_digest`, `evidence_digest`, `delivery_state` |

Use the job or batch identity that produced the result. Reading or downloading it does not start another Compute run.

Use the manifest to check artifact roles, stable IDs, schemas, coverage and the byte boundary each
digest covers. A folder listing does not identify the accepted result on its own.

## The kit reports named verification levels

Reading a result descriptor does not read or verify the artifact bytes. The TypeScript kit reports the highest level it actually reached, with a separate status for each stage. A later stage never implies that an earlier stage passed.

```text title="The kit reports named verification levels" kind="text"
Identify the accepted result
              ↓
Confirm retrieval permission
              ↓
Check bytes, decode and schema
              ↓
Reconcile every expected item
              ↓
Write and read back the destination
```

The sequence above is the reader's workflow. The TypeScript kit reports these exact levels:

| Level | What it proves |
| --- | --- |
| `descriptor_matched` | The accepted result descriptor names a delivered result for this job; no artifact bytes were read. |
| `transfer_authorised` | The manifest and unexpired access grant match the accepted result and your recipient key. |
| `bytes_verified` | Every transferred part matches its declared size and digest at the stored-byte boundary. |
| `decryption_authenticated` | Encrypted chunks authenticated and their plaintext matched the declared digest. A plaintext profile records this stage as not applicable. |
| `schema_validated` | The decoded output matched the schema supplied to the validator. |
| `coverage_reconciled` | Every expected item has an explicit outcome and none is missing. |
| `destination_committed` | The files were written to the selected local destination without overwriting a conflicting object and were read back identically. This is a local commit and read-back check. |

`quality_evaluated` is outside the kit and remains `not_run`; the kit never passes it. A digest, decryption check, schema check or local commit cannot judge whether a model answer is useful for your task. A stage that did not run is not a pass, and a `not_applicable` stage means only that the selected delivery profile had no such step. Your agent performs the semantic review and records its own acceptance decision in the customer workflow.

## Preserve item identity

Join outputs to your source through stable item IDs. Do not use file order, array position, partition number or a filename as the only business identity.

One input item can produce several output records, and a partition can contain items in a different order from the original source. A file is a delivery container, not an execution shard or a semantic unit; use the declared stable IDs and schema to reconstruct coverage.

## Verify the right bytes

A digest has meaning only at the byte boundary it names.

Check whether the digest covers stored, compressed, encrypted, decoded or aggregate-manifest bytes. Do not compare a digest for one representation with another.

A matching digest proves byte integrity at that boundary. It does not prove that the model answer is correct or that a downstream business decision is valid. A local check does not establish that a job ran, that required checks by independent provider owners passed or that a reported service state is current.

## Resume the same immutable object

If a download stops, resume or renew access to the existing artifact when the current delivery profile supports it. Do not rerun Compute because a signed URL expired or a transfer failed.

Zero account credit does not by itself block access to a retained, authorised result or renewal of its
delivery link; the result must still be retained and the access permission must still be valid.

If the artifact identity, digest or manifest differs from the result you expected, stop and reconcile the result before using the files.

## Keep exceptions visible

Read item outcomes `accepted`, `failed`, `abstained` and `missing` together. Validation decisions can separately be `accepted`, `failed`, `abstained`, `low_confidence` or `disagreement`. A result bundle is not complete merely because some accepted rows are present.

Use [Result exceptions](/docs/compute/results/exceptions) for the exception path and [Partial results](/docs/compute/results/partials) when the API returns a bounded page/cursor view.

## Deliver only after verification

Once you have the accepted artifact and its integrity evidence, use [Result delivery](/docs/compute/results/delivery) for a destination write or customer pull. Delivery does not change the result's acceptance state. Reconcile any accepted usage separately in [Billing and reporting](/docs/compute/billing); a delivery retry does not create a new billing unit.

The TypeScript kit exposes the complete delivery path. Python exposes selected result-bundle readers, format adapters and local-directory helpers; it does not provide full parity with the TypeScript `deliverResult` path. Choose the language helper that matches the boundary you can verify, then use [Use the Kit with your agent](/docs/compute/kit/agent-guide) and the [Kit helper reference](/docs/compute/kit/reference) for the exact integration surface.

`checkResultDescriptor` establishes only `descriptor_matched`. It checks the accepted descriptor and hashes zero artifact bytes. `deliverResult` continues with the transfer channel, your decryption adapter when the profile is encrypted, your schema and coverage validator, and a `local_directory` destination. The caller supplies those boundaries and key custody; the helper does not invent a credential or read one from the result.