Concept guide
What is a Spool?
A Spool is a versioned acceptance policy for a piece of work: what counts, what evidence matters, and who has authority to judge. An Outcome records what actually counted once that policy is applied.
A Spool keeps six parts together
- Parties: the buyer or client, the provider or seller, and the roles each one holds.
- Terms: the work, value, currency, timing, and other facts the parties agreed to, with a record of where those facts came from when available.
- Conditions: specific statements that must be true for the delivery to count as accepted.
- Evidence: files, records, confirmations, source references, or other material used to evaluate a condition.
- Verification plan: who or what checks each condition, how the check works, and what happens when a result is uncertain.
- Lifecycle events: a history that can be added to but not rewritten. It covers acceptance, evidence submission, verification, attestations, settlement state, and other changes. Settlement is the step where the payment is completed.
These parts stay together so a page, API response, MCP tool, verifier, and settlement adapter don't invent separate versions of the deal. The adapter is the connector that carries out a payment path.
A small example shows the parts working together
Task: A research agent buys 10 company records for $0.10 from a data provider.
Parties: buyer agent and data provider.
Conditions: each record has the required fields, contains a valid URL, and has no null value in the company-name field.
Evidence: the delivered JSON records and verifier outputs.
Verification plan: schema validation, required-field checks, and URL checks run per record. A passing record approves $0.01.
Lifecycle: terms accepted, records submitted, eight passed, two failed, attestations issued for the passing records, and the settlement instruction approved $0.08.
This is an example shape, not a claim that every data purchase should use per-record settlement. The verification method and settlement policy must fit the work, risk, and rail.
Use a Spool when outcomes need inspection
Use a Spool when you're buying an outcome that can be incomplete, stale, wrong, or ambiguous. Use one when “done” has several conditions, when evidence matters, or when payment should depend on a verified result.
You usually don't need a Spool for an atomic purchase where the protocol enforces delivery and there's no meaningful condition to inspect afterward. Direct payment is simpler when fulfillment and payment happen as one deterministic operation.