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

# Review result exceptions

## Start with a mixed result

Suppose a synthetic classification run returns these four items:

| Input ID and text | Review disposition |
| --- | --- |
| A: “Where is the guide?” | Accepted candidate label `question`, supported by the question text. |
| B: Empty input | Input failure; no invented label. |
| C: “It sometimes does that.” | Abstention because the referent is missing. |
| D: “It works, except when it does not.” | Preserve differing interpretations for review; do not manufacture agreement. |

The labels in this example belong to its rubric. They are not Compute item outcomes or validation decisions. The table shows why you read each outcome before summarizing a mixed result: accepted work can coexist with failed, abstained and unresolved items.

Your agent keeps the task brief and checks each returned item against its declared evidence and acceptance rule. Lithi records the result identity, outcome and evidence needed to reconcile the run; those records do not make an unresolved or semantically wrong item accepted.

## Read outcomes before relying on answers

Open the workflow's output description alongside its results. Identify the field that records each item's outcome and the evidence required for it. Do not assume every workflow uses the same status names or directory layout.

Keep the prepared task brief beside the output: frozen instructions and rubric, input snapshot, stable IDs, declared schema and acceptance rule. Use it to interpret the returned evidence while preserving the workflow's exact outcome and validation vocabularies.

The result bundle's item outcome uses four contract values. They describe coverage of the prepared items; they are not additional values to insert into an API enum.

| Item outcome | Meaning | Useful next action |
| --- | --- | --- |
| `accepted` | The declared acceptance rules passed for the item. | Check relevant evidence before downstream use. |
| `failed` | Required processing or validation did not complete successfully. | Inspect the reason and recover the affected step. |
| `abstained` | The task declined to provide a requested answer. | Review missing evidence or ambiguous instructions. |
| `missing` | No outcome has been accounted for yet. | Reconcile identity, pagination and job state. |

Validation is a separate decision layer. Its contract values are `accepted`, `failed`, `abstained`, `low_confidence` and `disagreement`. A workflow may send a low-confidence or disagreement decision for human review; neither value becomes a new item outcome, and neither is automatically a failed item.

## Reconcile without hiding exceptions

Join each outcome to the original stable input ID. For a one-output-per-input contract, check that every expected ID is accounted for once. For one-to-many output, use the declared parent and child identities.

Do not add accepted, failed, abstained and missing counts unless the contract makes those populations disjoint. Keep missing IDs visible. An empty result file is not evidence that there were no exceptions.

Read all high-impact exceptions and disagreements first. Then sample accepted outputs using a declared selection rule. A sample can reveal defects; it cannot certify every uninspected item.

Check returned coverage, uncertainty, abstentions and schema before synthesis. A receipt or digest
can support identity and integrity checks, but it cannot turn an unreviewed or semantically wrong
answer into an accepted conclusion.

## Choose the correct recovery

Missing context calls for source clarification. A rejected format calls for a corrected permitted input. A delivery failure calls for recovery of the existing accepted artifact. These actions solve different problems.

Changed instructions, evidence or rubric create a new task meaning and may require a new quote and approval. Preserve the original result and its review history. Do not silently relabel rejected output as accepted.

An `abstained` item can be an expected outcome under a particular workflow policy. Its label alone establishes neither a charge nor a refund. Read the applicable usage and receipt records.

Use [verification evidence](/docs/compute/workflows/verification) to decide which conclusions the recorded checks actually support.