When a job finishes partially

Before you start

You need a job that reached PARTIAL or AWAITING_REVIEW, and the result bundle it wrote. Reconcile the bundle before you rerun anything, because a rerun of the whole input is new work.

The three completion policies

A workflow states which completion policies it supports on its descriptor, and your quote repeats the one your job used. Read it there rather than assuming.

• All required. Every item must complete. One item that does not finishes the job as PARTIAL or FAILED.
• Threshold. The job succeeds once the stated proportion of items is accepted. The remainder still appears in the bundle.
• Best effort. The job runs to the end of your input and reports what it obtained.

The policy changes the job's terminal state. It never changes what the bundle records about an individual item.

Read the bundle, not the summary counts

Counts tell you the shape of the outcome. The bundle tells you which items, and it is the thing to reconcile against.

Accepted output sits under data/, typed failures under failures/, abstentions under abstentions/, and preserved verifier disagreements under disagreements/. Aggregate and slice figures are in metrics.json, and result-manifest.json is written last as the only complete-bundle marker.

Failed, missing and review-required are three different things

A failed item was attempted and did not succeed. It appears under failures/ with a typed error code in lithi_error_code, a safe reason and a next action. You know exactly what happened to it.

A missing item is one you submitted that appears in none of those partitions. Missing means unreconciled, not unattempted and not free. Compare your submitted item identities against the manifest counts to find them.

A review-required item is waiting on a person. The job sits at AWAITING_REVIEW, the evidence behind the disagreement is preserved, and lithi_verification records what the checks found. Nothing advances until someone decides.

What a partial job means for your charge

What you are charged for is set by the commercial policy stated on your quote, not by the terminal state of the job. Attempted work is not automatically free, and this page will not suggest it is.

The maximum_price you approved remains the ceiling. Your statement and the receipt reference are the record of the actual amount, and metrics.json and lithi_usage let you tie that amount back to items.

Before you rerun

Rerun only the items you can name from the bundle. Resubmitting the whole input under a new identity creates a second full run and a second charge.

Start with how failures, abstentions and disagreements are recorded to classify what you have. If the counts still do not reconcile, follow what to do about partial results.