Compute
Sandbox fixture catalog
The eight synthetic outcomes the sandbox can show you, from success and refusal through abstention and disagreement to delivery failure, and what each teaches you to recognize.
The eight fixtures
Every fixture below is synthetic. None of them runs live work, moves money, or writes to anything you own. Which ones appear depends on the scenario you open.
| Fixture | What the sandbox shows | What it teaches you to recognize live |
|---|---|---|
| Success (synthetic) | All items accepted, one complete bundle | A clean terminal run, and where the manifest confirms it |
| Refusal (synthetic) | The request stops before admission, with a typed reason | A request that never became a job, so nothing was charged or started |
| Partial (synthetic) | Some items accepted, some not, in one run | The normal shape of a large run, and how to resume from a cursor |
| Cancellation (synthetic) | A run stopped in flight, with untouched items skipped | What your own cancel request does, and what it cannot undo |
| Abstention (synthetic) | An item with no answer and a stated reason | A grader declining rather than guessing under your quality preset |
| Disagreement (synthetic) | Independent checks that did not agree, both preserved | Where verification evidence is kept instead of being averaged away |
| Delivery failure (synthetic) | A finished result that did not reach a destination | The split between producing a result and writing it somewhere |
| Payment pending (synthetic) | An invoice that exists but is not settled | Why an invoice label is never proof of payment |
States each fixture writes
Item statuses come from the fixed status set. Every non-success carries a safe reason and a non-empty next action.
| Fixture | Job state | Item status |
|---|---|---|
| Success | SUCCEEDED | SUCCEEDED |
| Refusal | no job admitted | BLOCKED |
| Partial | PARTIAL | mixed SUCCEEDED and SAFE_FAILED |
| Cancellation | CANCELLING, then CANCELLED | CANCELLED for started items, SKIPPED for the rest |
| Abstention | PARTIAL | SAFE_FAILED on the abstained unit |
| Disagreement | AWAITING_REVIEW, then SUCCEEDED | SUCCEEDED with disagreement evidence attached |
| Delivery failure | SUCCEEDED | SUCCEEDED |
| Payment pending | SUCCEEDED | SUCCEEDED |
A quote that has drifted since it was signed is a separate case. Admission returns REPLAN_REQUIRED, and the next action is to request a new quote.
Where each fixture lands in the bundle
| Fixture | Bundle location |
|---|---|
| Success | data/part-* |
| Partial | data/part-* and failures/part-* |
| Abstention | abstentions/part-* |
| Disagreement | disagreements/part-* and verification.json |
| Cancellation | metrics.json counts, plus whatever data/part-* already held |
| Refusal | no bundle is produced |
| Delivery failure | the bundle is complete and downloadable by you |
| Payment pending | receipt.json, with the invoice tracked outside the bundle |
result-manifest.json is written last in every fixture that produces a bundle. It is the only marker that a bundle is complete. Part files on their own never mean a run reached a terminal state.
Reading the row-level columns
Accepted and non-accepted rows both carry namespaced columns beside your own:
lithi_status— the item's status from the fixed set above.lithi_result— the produced value, empty on an abstention.lithi_error_code— the typed reason on a failure or refusal.lithi_confidence— the grader's confidence, where the workflow reports one.lithi_evidence— what the answer was based on.lithi_verification— independent-check evidence, including preserved disagreement.lithi_usage— what the item consumed.
The two fixtures that sit outside the job
Delivery failure and payment pending both come after a job succeeds, and both are worth practicing on.
A delivery failure means the result exists and the write to your destination did not complete. The sandbox shows the write states an attempt passes through, including WRITE_FAILED, VERIFY_FAILED and COMMIT_CONFLICT. Live, the recovery is to retry the delivery, never to rerun the job.
Payment pending shows an invoice reaching INVOICE_FINALIZED while the payment projection stays short of settled. In the sandbox, the hosted payment action reads unavailable, because no real payment can be opened. Live, only a current bank read-back advances the projection to paid. A label in your own finance system is an annotation, not settlement.
What no fixture ever does
- No fixture runs live work or consumes capacity.
- No fixture writes to a registered destination, calls a webhook, or fires a schedule.
- No fixture creates, rotates or reveals a credential.
- No fixture produces a charge, an invoice you owe, or a usage line on a statement.
- No fixture emits a signed receipt. Sandbox receipts are labeled samples and prove nothing about live work.