Acceptance lifecycle

The lifecycle as a state machine

1. Claimed: a Spool is created, and its criteria, earning rule, and parties are frozen behind agreement_hash.
2. Evidence complete: required_evidence states roll up into evidence_completeness.
3. 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.
4. Result: the Outcome is pass, partial, fail, or uncertain, including per-unit results under units.
5. Provisionally accepted: receipt status is active and the current time is before review.window_ends_at.
6. Final: the review window has elapsed and status remains active.

Branches

• Rejected: fail, represented for consumers by retryList.
• Needs review or exception: uncertain, represented by holdList.
• Disputed: dispute_policy records who may dispute, the window, scope, and what happens to disputed value.
• Corrected or superseded: a new receipt supersedes the original with verification_defect, appeal_reversal, or dispute_resolution. The original is never rewritten. The status endpoint reports corrected or revoked.
• Human override: a superseding receipt uses appeal_reversal, or a human_confirmed condition records confirmed_by.

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

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