Spoolis docs
Workflow and billing consumers
Use generic Outcome exports in workflow, billing, finance, and payment systems without moving their responsibilities into Spoolis.
Verify the signed Outcome first, then derive the smallest export the next system needs. The same receipt can feed independent consumers without making their schemas part of the Outcome.
Generic consumer exports
acceptedUnitsExport: accepted unit identities and the receipt reference for work cleared to continue.retryList: rejected units and their reasons for a retry worker or parent agent.holdList: uncertain units and their reasons for evidence collection, review, or escalation.continuationPayload: the continue, retry, and hold sets plus the Outcome reference for a durable workflow handoff.settlementInstruction: the earned amount and Outcome reference for a payment or finance consumer to apply under its own authorization and policy.
billingSummary() is arriving in the JavaScript and Python verifier SDKs alongside these helpers. Its exact shape is not documented yet.
Where the exports fit
Temporal-shaped and Town-shaped orchestrators can use continuationPayload at a durable step boundary. Parent agents can continue accepted work and delegate the retry list. Retry workers can process rejected units while review queues keep uncertain units on hold.
Finance and billing systems such as Flexprice, Orb, Metronome, Paid, and Stripe Billing can consume accepted units and earned value as verified inputs to their own meters, invoices, credits, and plans. Spoolis creates none of those billing objects.
Payment systems can consume settlementInstruction or use a configured settlement adapter. The acceptance result remains independent of whether and how money moves.
Consumer responsibility
Verify the receipt signature and expected environment before acting. Apply your own idempotency, authorization, correction-status, and partial-result policy. Spoolis returns continue, retry, and hold sets. It never executes the workflow.