Spoolis docs

Acceptance lifecycle

Follow an Outcome from a frozen agreement through evidence, judgment, provisional acceptance, and final acceptance.

The lifecycle as a state machine

Claimed: a Spool is created, and its criteria, earning rule, and parties are frozen behind agreement_hash.
Evidence complete: required_evidence states roll up into evidence_completeness.
Judged: a verification run produces condition_results with the method, verifier_id, and verifier_version. Under bring your own judge, the customer's judge produces these results.
Result: the Outcome is pass, partial, fail, or uncertain, including per-unit results under units.
Provisionally accepted: receipt status is active and the current time is before review.window_ends_at.
Final: the review window has elapsed and status remains active.

Branches

Rejected: fail, represented for consumers by retryList.
Review request: an rvq_ object routes uncertain work or work inside its review window to a named reviewer.
Dispute: a dsp_ object records the reason and counter-evidence, marks policy-defined value as not currently final or payable, and keeps the outcome disputed while open. It does not restrict money.
Corrected or superseded: a new receipt supersedes the original with verification_defect, appeal_reversal, review_decision, or dispute_resolution. The original is never rewritten.
Human confirmation: the condition records human_confirmed and confirmed_by. A changed verdict produces a successor receipt.

Commercial states

The engine uses these exact state values. payable_under_policy is derived and describes the record under policy, never a balance.

State	Permitted next states
`reported`	`matched` `unmatched` `uncertain`
`matched`	`accepted` `uncertain` `disputed`
`unmatched`	`rejected` `uncertain` `disputed`
`uncertain`	`matched` `unmatched` `rejected` `disputed`
`accepted`	`provisional` `final` `disputed` `corrected` `revoked`
`rejected`	`disputed` `corrected` `revoked`
`provisional`	`final` `disputed` `corrected` `revoked`
`disputed`	`accepted` `rejected` `corrected` `revoked`
`final`	`corrected` `revoked` `payable_under_policy`
`corrected`	`accepted` `rejected` `provisional` `final` `revoked`
`revoked`	None
`payable_under_policy`	`disputed` `corrected` `revoked`

Composed acceptance

A Spool has several mandatory or optional conditions. Each uses a deterministic, AI-assisted, human-confirmed, or external judge, and the published aggregation policy combines them. Today that policy is all_mandatory_pass.

Time-windowed facts such as "not reopened for 72 hours," duplicate detection across Outcomes, and OR branches other than supersession are not shipped as native condition kinds. Today the customer's judge computes those facts and returns pass, fail, or uncertain per condition.

Consumer checklist

Verify the receipt.
Read acceptanceState.
Call requireOutcome with require_final when money or an irreversible step depends on final acceptance.