When a job finishes partially
How to see which items finished, failed or are still unresolved after a partial result, before you ask for more work.
Separate admitted work from what remains
Start with the jobs and results you already have. Your agent matches them to your saved item identities before deciding what needs another run. A missing response does not tell you that an item failed. Keep accepted output, observed failures and unresolved items separate.
Keep your original input snapshot and item-to-job mapping available. Your agent needs jobs:read
access to read jobs, batches, events, and result metadata.
Keep the rest of the prepared brief with that snapshot: the frozen instructions and rubric, output schema, required evidence and acceptance rule. Use it to judge returned items after coverage is reconciled; do not treat a returned digest or accepted counter as a semantic answer.
Read the batch summary
Call GET /v1/batches/{id} or getBatch(batchId) in the TypeScript client. Its projection contains batch_id, state, total_count, accepted_count, failed_count, digest, and p_next_action.
When accepted plus failed is lower than total, those two counters leave some items unaccounted for. Treat them as unresolved in that observation, not as successful, unattempted or free. The accepted counter alone is not proof that every output is usable or delivered.
The public projection does not add separate abstention or missing counters. It also does not define a
universal PARTIAL state string. Read the exact state and results Lithi supplies. A
single job does not send a partial result; partial completion is a batch policy outcome.
Keep two decisions separate. At most one attempt may be accepted for each logical job, but a batch is successful only when every required item has an accepted outcome under its selected completion policy. One accepted item does not make a batch complete while another required item is failed or unresolved.
Match results by identity and inspect the artifact
Read GET /v1/batches/{id}/results, following next_cursor until it is absent. The TypeScript method is listBatchResults(batchId, limit, cursor), with limit between 1 and 100.
Each result projection carries a job_id, an encrypted artifact ID, result and evidence digests, and
a delivery state. Match job_id to your saved customer-item mapping. Do not join results to input by
array position. Inspect the returned artifact and its verification evidence with Files and
verification before using accepted output.
For each unresolved job, read its current state and events. Preserve observed failures separately from jobs for which no outcome is known. If the workflow's returned evidence includes abstentions or disagreements, review them as evidence rather than relabeling them as accepted answers. A transport retry of a read uses the same batch and cursor; it does not authorize another compute item.
Before synthesis, check that the returned schema is the one named in the brief and that required evidence and coverage are present. Keep abstentions, uncertainty and missing items visible to the your agent that decides what the result means.
Apply the policy you actually selected
A batch binds a completion_policy_digest. Keep the corresponding policy with your request so you know what completion means for that batch. A digest is not a policy description, and the public batch request does not accept an arbitrary policy name in its place.
A complete page of result metadata is not necessarily a completed batch. Check job outcomes and the selected completion policy before treating the available subset as the final result.
Select further work deliberately
First separate a delivery problem from a Compute problem. If an accepted result exists but delivery failed, recover that result rather than recomputing it. Normal platform retries, default verification and finalizer or delivery repair are covered by the approved request; they do not create a second customer charge. A lease or executor failure can receive a bounded sequential attempt under that policy without another customer approval; the original maximum stays fixed and owner exposure still counts.
For items that genuinely need revised work, record the selected identities and their relationship to the original jobs. Obtain the required fresh quote and approval. A new request for the entire input can repeat work you already received. A deliberate revised request needs its own identity, quote and approval, with the retry policy, exposure, capacity, budget and deadline considered for any remaining work.
Use safe retries and unknown-outcome recovery before creating any replacement intent.
Confirm the outcome and charge
Reconciliation is complete when each expected item has an attributable outcome or an explicitly unresolved case. Keep the evidence and any support reference for unresolved cases. Do not fill gaps with assumed successes.
Read the signed quote and recorded usage for commercial treatment. A failed, missing, or partially delivered result is not automatically billable or free merely because of that label. Share job and batch references with support, never a payload dump or signed access URL.
Physical attempts are not themselves customer billing units. The quote's usage policy defines the accepted unit, so reconcile that policy and the corresponding receipt before deciding what the partial outcome means commercially.