Read Compute results

Use this result-reading checklist

Start with the job or batch identity you already have. Then work through the same short order every time:

1. Read the result descriptor and its manifest.
2. Check item coverage, exceptions, uncertainty and schema against the prepared task brief.
3. Verify the existing artifact at the byte and decryption boundaries that apply.
4. Review the returned business rows using stable item IDs and the task's acceptance rule.
5. Deliver, retain or delete the existing result according to the next action you choose.

Reading, downloading, verifying or delivering an existing result does not start another Compute job. Keep the brief with the descriptor: frozen instructions and rubric, input snapshot, declared output schema, required evidence and acceptance rule. A successful read is not task success until you have checked coverage and uncertainty.

Your agent keeps the goal, project context and final decision. The Compute Kit prepares permitted work and connects the approved interface; Lithi records the job, result, artifact and evidence identities. Your agent checks the returned work against the acceptance rule after those records and file checks are available. For coding work, the agent remains responsible for local edits, native builds, tests and final acceptance.

For one job, use getJobResult(id: string) or GET /v1/jobs/{id}/result. For a batch, use listBatchResults(id: string, limit = 100, cursor?) or GET /v1/batches/{id}/results, following each returned cursor until there is no next cursor. These reads return result descriptors; business rows remain inside the encrypted artifact.

The public descriptor identifies accepted work through job_id, encrypted_artifact_id, result_digest, evidence_digest and delivery_state. Read those fields with the workflow's manifest before interpreting files or rows. A digest proves integrity at its declared byte boundary; it does not prove semantic correctness.

Choose the question you need to answer

For billing details, including the accepted billing unit, quote and payment records, use Billing and reporting. Delivery state and usage records answer different questions.

With reporting:read permission, your agent can also interpret an authorized monthly Compute impact report. The report connects accepted work with recorded Mac participation and supported energy or community evidence; reporting is a separate API or file path, not a sixth Work tool. Its accepted_work_macs, physical_activity_macs and provider_accounts populations answer different questions and are not additive totals.

Reconcile coverage before making a decision

The result bundle classifies item coverage as accepted, failed, abstained or missing. A separate validation decision can be accepted, failed, abstained, low_confidence or disagreement. Read the item outcome with its validation decision; a missing item is unresolved, and a low-confidence or disagreement decision is not an accepted conclusion. If your workflow asks for human review, keep that request beside the underlying outcome.

For a small test, compare every submitted item ID with the returned coverage. Review the accepted items against your acceptance rule, then record the next action for each failed, abstained or missing item and each low-confidence or disagreement decision before expanding the work.

Join outputs through stable IDs, not row order or filenames. Keep the requested business columns and nested structure in the declared output, with provenance, item outcomes, verification and financial metadata in their declared sidecars unless the workflow explicitly selected an envelope.

Check returned coverage, abstentions, unresolved items and schema before synthesis. Preserve the original evidence and uncertainty so your agent can decide whether the result is useful and apply the final semantic acceptance rule. A receipt or integrity check cannot stand in for semantic correctness.

If the result contains prepared aliases, restore them only through your own mapping, the result's verified identity and the permitted field and purpose. A syntactically valid alias from another record or run is still out of scope. Joining by an opaque item handle may be enough; restoration remains a separate local choice.

Keep integrity, correctness and authority separate

A matching digest proves integrity at its declared byte boundary. A verification record names the checks it covers. A signed receipt authenticates its statement under the applicable trust policy. None guarantees that every model judgment is correct or authorizes a downstream external action.

Source or local checks, an installed execution record and an authenticated live read-back answer different questions. A source test does not establish which installed Mac ran a particular job or that an independent provider owner verified it. Use the job's own execution and verification evidence for those claims; if that evidence is absent, leave them unverified. A checksum or signature alone cannot establish semantic correctness. Lithi records defined execution and evidence; your agent decides whether the result is fit for your work.

Recover the same accepted work

If accepted output exists, recover that result. A failed download, expired access grant or destination failure does not prove inference failed, and delivery recovery does not require another Compute run. Follow Result delivery for the destination path, or Retention when the question is what copies remain.

Reconcile accepted usage and receipts from the quote and usage records separately from delivery state. Physical attempts are not automatically customer billing units. See Billing and reporting for the commercial records and billing details.