Concept guide
What is a Spool?
A Spool is a canonical transaction object that records who agreed to what, what counts as fulfillment, how delivery will be verified, and what happened next.
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 provenance where 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: the verifier and method assigned to each condition, including what happens when a result is uncertain.
- Lifecycle events: an append-only history of acceptance, evidence submission, verification, attestations, settlement state, and other changes.
These parts stay together so a page, API response, MCP tool, verifier, and settlement adapter do not invent separate versions of the deal.
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 the transaction buys an outcome that can be incomplete, stale, wrong, or ambiguous; when “done” has multiple conditions; when evidence matters; or when payment should depend on a verified result.
A Spool is usually unnecessary for an atomic purchase where the protocol enforces delivery and there is no meaningful post-delivery condition to inspect. Direct payment is simpler when fulfillment and payment happen as one deterministic operation.