Compute
Result bundle layout
Every path in a Compute result bundle, the namespaced columns appended to tabular output, and why the manifest written last is the only marker that the bundle is complete.
Bundle paths
| Path | What it holds |
|---|---|
data/part-* | Accepted tabular or media outputs |
failures/part-* | Typed failures and refusals |
abstentions/part-* | Units that abstained instead of answering |
disagreements/part-* | Preserved disagreements between independent checks |
metrics.json | Aggregate and slice metrics for the run |
verification.json | Rubric, grader and independent-check-count evidence |
provenance.json | Input, workflow, model, schema and envelope digests |
receipt.json | Signed receipt projection |
result-manifest.json | Written last; binds every file, count, schema, release and retention rule |
The completion marker
result-manifest.json is written last and is the only complete-bundle marker.
The presence of a part file never means terminal success. Part files appear while a run is still working, and they remain in place behind runs that end PARTIAL or FAILED.
Read the manifest first, every time. Until it is present and binds the files you are about to read, you do not have a finished bundle — you have bytes.
Namespaced result columns
These columns are appended to tabular output. They sit beside your own columns and never replace them.
| Column | What it carries |
|---|---|
lithi_status | The per-item outcome for that row |
lithi_result | The workflow's answer for that item |
lithi_error_code | The typed code when the item did not succeed |
lithi_confidence | How sure the answer is |
lithi_evidence | What the answer cited |
lithi_verification | What checking that item received |
lithi_usage | The usage recorded against that item |
How the four output paths differ
data/holds items the workflow answered and the run accepted.failures/holds items that could not be processed, each with a typed code and a next action.abstentions/holds items the workflow declined to answer, usually for want of sufficient evidence.disagreements/holds items where independent checks reached different answers, preserved rather than resolved.
An item appears in exactly one of these. A run's totals only reconcile when you count all four, which is one reason the manifest carries the counts.
Item identity
Every row is addressed by the item identifier your input declared through item_id_field. That identifier is what lets you join a result row back to your source row.
Ordering is not identity. Part files are not ordered relative to each other, and a missing row number is never evidence that work was skipped.
What the layout does not tell you
The layout is fixed; the contents are not self-describing. Which fields appear inside lithi_result comes from the workflow's declared output schema, not from this page.
The bundle also says nothing about delivery. A complete bundle is a completed compute result — writing it to a destination of yours is a separate event with its own states.
Next, read the exceptions
Open the exception paths before you sample the accepted rows. They tell you what the run could not decide.
- Read the exceptions first — the order to review the four output paths in.