# Spoolis public pages A single machine-readable dump of every public marketing and content page. # Verification for work and payments Canonical HTML: https://spoolis.com/. This page is also available in machine-readable Markdown. Turn natural-language agent tasks into machine-checkable acceptance criteria, verify delivered work, and issue a portable Outcome Receipt that records what was earned. ## Why Spoolis exists Payment systems tell agents how to pay. They don't define what counts as fulfillment. Rails move money. They don't know whether 500 rows arrived, whether the schema holds, or whether the video is actually 4K. For most real agreements, rails have no way to evaluate those conditions, while proof-gated designs can bind payment to a fixed computation's correctness in the narrow cases expressible as one. Spoolis figures out which conditions, evidence, and verification the actual agreement requires, then runs them. ## Compile the deal. Verify the result. Compile turns a task into extracted terms with provenance, surfaced ambiguities, proposed protections, and a verification plan. Verify runs the plan against the delivered result and returns a signed Outcome Receipt using schema spoolis/outcome-receipt@1. Third parties can verify it with @spoolis/receipt-verifier. ## The same Spool works between people and businesses A listing and chat can compile into a marketplace Spool. A statement of work can compile into milestones. File checks can run automatically while acceptance stays human. ## One receipt. Any compatible payment path. Spoolis determines what was earned. A payment authority and configured settlement adapter may act on the Outcome Receipt, or the payment referee refuses when no compatible production path qualifies. Receipt, lower-level attestation, authorization, and execution are separate layers. Settlement is optional and runs on the configured settlement adapter. --- # See a Spool run. Canonical HTML: https://spoolis.com/demos. This page is also available in machine-readable Markdown. Choose an illustrative agent, person, or business transaction and watch its intent compile into checks, evidence, and an economic result. ## Intent, checks, result Each scenario pauses on one ambiguous requirement because Spoolis will not guess. After you answer, the illustrative result shows the evidence and what was earned. ## Three native scenarios The agent example accepts 98 of 100 verified units and earns $98 of a possible $100. The marketplace handoff and business milestone use all-or-nothing illustrative economics. [Run the interactive demo](/demos) ## Experiment with the result After a run, change the requirement, make one real condition fail, or view the evidence. Fail mode recomputes the economic rows for that scenario. --- # From intent to a verified receipt. Canonical HTML: https://spoolis.com/demos/walk. This page is also available in machine-readable Markdown. Run the existing sandbox from compilation through evidence verification, then inspect and verify the signed demo Outcome Receipt. ## One continuous path The walk mints a short-lived sandbox session, compiles a 10-record task, models acceptance, submits evidence, and runs deterministic verification. Every completed step shows its real request and response. ## Outcome Receipt The result records 8 accepted units, 2 rejected units, $8.00 earned, and $10.00 committed. It is a demo artifact and does not authorize production settlement or move real funds. ## Verify the signature The final step reads the matching demo receipt key from /.well-known/spoolis-keys.json and checks the Ed25519 signature in the browser. [Read the Outcome Receipt specification](/docs/outcome-receipt). --- # Authorize the cap. Capture what was earned. Canonical HTML: https://spoolis.com/demos/card-rail. This page is also available in machine-readable Markdown. A fully simulated card-rail walkthrough: authorize a $500.00 cap, verify $470.00 earned, capture $470.00, and release $30.00. ## Demo boundary This is an illustrative demo only. No real card rail is connected, no authorization is created, and no money moves. Spoolis supplies a signed earned-value receipt. The buyer’s payment stack owns authorization and capture. ## The four steps The buyer’s payment stack asks the issuer to authorize up to $500.00 for 50 units at $10.00 each. Spoolis accepts 47 units. The signed demo Outcome Receipt records $470.00 earned. The buyer’s payment stack would capture $470.00, and the issuer would release $30.00. ## What the receipt proves The receipt records what was earned and can be checked for authenticity. It does not authorize payment, prove capture, or prove release. - [Read how the pattern works](/learn/authorize-the-cap-capture-what-was-earned) - [Read the Outcome Receipt specification](/docs/outcome-receipt) - [See all illustrative demos](/demos) --- # Tell us what you're buying. We'll verify the result. Canonical HTML: https://spoolis.com/agents. This page is also available in machine-readable Markdown. Spoolis compiles an agent task into acceptance criteria, runs them against the delivered result, and returns a signed Outcome Receipt. A compatible configured payment path may act on the result, or the referee refuses. ## Compile Messy intent in. A structured Spool out. One call turns a task into extracted terms with provenance, surfaced ambiguities, proposed protections, and a verification plan. What the parties said stays distinct from what Spoolis recommends. ## Verify Run the plan. Get an Outcome Receipt with evidence. The second call executes every check in the plan against the delivered result and signs the portable result. ## Verifier registry Checks cover data, files, commerce, and human confirmation. Deterministic where possible, human where it matters. - rows.count - schema.validate - url.reachable - dimensions.match - duration.matches - serial.match - human.confirm ## API and MCP A human URL, a REST resource, and an MCP tool call read the same canonical Spool state. ## Payment paths The payment referee considers actor, amount, currency, configured adapters, declared capabilities, readiness, and demo mode. It never falls back silently. [Read payment path selection](/docs/payment-paths) ## Pricing at machine scale Spoolis prices the verification a task requires, not the money moving through it. Every task gets a fixed, machine-readable quote before execution, and payment and network costs stay separate. [See agent pricing](/agents#pricing) --- # Agree on what happens. Pay when it does. Canonical HTML: https://spoolis.com/people. This page is also available in machine-readable Markdown. Selling a laptop to a stranger, splitting a deposit, paying a mover. Spoolis turns the deal into one clear agreement, verifies what happened, and records what was earned. ## How it works Paste the deal. Spoolis writes it up fairly. Drop in the listing and the chat. Spoolis pulls out what both sides said, asks about anything unclear, and labels its proposed protections separately. - Paste: The listing, the chat, a screenshot. Whatever you have. - Review: Your terms, in plain language, with anything unclear asked once. - Share: Send one link. The other side opens and reviews it, then signs in to accept. - Meet: Inspect, confirm, hand over. Each side sees the other's progress live. - Done: Both confirm and the money completes. A receipt for each side. ## What it costs The Spoolis fee is 0.5% of the deal, at least 49 cents, never more than $7.99. Your first Spool is free. Optional costs are shown separately before you pay. - $50 deal: 49¢ - $200 deal: $1 - $650 deal: $3.25 - $1,000 deal: $5 - $2,000+ deal: $7.99 max --- # Turn agreements into verifiable outcomes. Canonical HTML: https://spoolis.com/business. This page is also available in machine-readable Markdown. A statement of work becomes milestones with acceptance criteria. Deliverables verify against the brief, acceptance stays human, and each passing milestone determines what was earned. ## A real shape of work A $4,500 product video, written up fairly. The statement of work and email thread go in. Agreed terms retain their source, unclear points are asked once, and proposed protections remain unagreed until accepted. ## Milestones Each milestone verifies, then records what was earned. File metadata, dimensions, duration, and file presence check automatically. Acceptance of the cut stays with the client. ## For your operation Every Spool has a hosted transaction page, an audit trail, and API access. The page and API show the same state. ## Pricing Quoted by verification complexity and volume. Contract amounts are the contract, not the Spoolis fee. [See business pricing](/business#pricing) --- # What can we help with? Canonical HTML: https://spoolis.com/contact. This page is also available in machine-readable Markdown. Contact Spoolis about enterprise pricing, partnerships, support, press, security, or another topic. ## Contact Choose a topic and send us the details. Email support@spoolis.com directly if you prefer. --- # Verification infrastructure for platform transactions Canonical HTML: https://spoolis.com/platforms. This page is also available in machine-readable Markdown. A self-serve partner brief for marketplaces, agent frameworks, data platforms, and tool platforms evaluating verification-gated transactions. ## Who it is for Use Spoolis when fulfillment needs its own decision layer. Your platform keeps its existing relationship with buyers, providers, tools, identities, and payment infrastructure. Spoolis handles what counted as success and what was earned. - Marketplaces: add explicit acceptance criteria and a verification result when fulfillment is more specific than an order status. - Agent frameworks: give agents a structured path from transaction intent to evidence-backed outcome. - Data platforms: evaluate records individually and tie earned value to accepted units when work is unitized. - Tool platforms: add verification-gated transactions while keeping existing identity, authority, and payment layers. ## From intent to outcome The verification layer sits between transaction intent and any payment action your platform chooses to take. - Intent: start with the task, terms, value, parties, and agreed conditions. - Compiled checks: create a canonical Spool with acceptance criteria and a verification plan. - Verify: run the plan against submitted evidence and keep the condition-level result. - Per-unit earned value: for unitized work, resolve each unit and calculate earned value from the accepted count. - Outcome Receipt: when signing is configured, issue a portable signed record of the result and what was earned. - Optional settlement: let a configured settlement adapter act on the result, or keep payment execution in your platform. ## Integration surfaces Every surface below is implemented and documented in this repository. - [REST API reference](/docs/api) and [OpenAPI 3.1](/openapi.json) - [MCP server](/docs/mcp) - Scoped machine keys: owner grants mint a verify-scoped key. An initiator can also issue a 15-minute, single-use grant invitation that a machine exchanges without a Clerk session for a counterparty key bound to that Spool. [See the exchange contract](/openapi.json). - [Zero-login sandbox quickstart](/docs/quickstart) and [coding-agent prompt](/docs/coding-agent-quickstart) - [Independent Outcome Receipt verification](/docs/verify-receipt) with @spoolis/receipt-verifier and a pinned trust set - [Machine-readable resource index](/machine) for Markdown twins, llms.txt, skill.md, receipt schema, trust material, and OpenAPI ## What Spoolis does not do Identity, authority, wallets, payment protocols, and settlement answer other questions in the transaction stack. Spoolis answers what counted as success and what was earned. - Identity and authority: Spoolis is not a general-purpose identity or agent-authority system. - Wallets: Spoolis does not replace the wallet or payment authority that controls funds and signs payment instructions. - Custody: Spoolis is not a bank, escrow agent, money transmitter, or payment processor, and it does not hold funds. - Payment protocols: Spoolis does not replace a payment protocol or rail that moves money. It produces the fulfillment result that another layer may use. ## Evaluate start to finish Evaluate the full path without a sales call. - [Run the zero-login sandbox](/docs/quickstart). Demo artifacts do not move funds or authorize production settlement. - [Map your transaction shape](/docs/api) against the v1 contract. - [Verify receipt authenticity](/docs/verify-receipt) outside the Spoolis API. - Move to production credentials by creating a full-scope key at `/dashboard/api-keys`, using an owner grant for verify scope, or using a Spool invitation for counterparty scope. - [Review pricing](/pricing). Agent tasks are quoted before execution based on verification work. Payment and network fees stay separate. Platform pricing is quoted separately. ## Contact Have a platform requirement this brief does not answer? [Contact Spoolis](/contact). --- # Pricing follows how you use Spoolis. Canonical HTML: https://spoolis.com/pricing. This page is also available in machine-readable Markdown. Pricing fits the way each audience uses Spoolis: machine workloads are priced by verification usage, people get simple capped transaction pricing, and businesses are quoted from verification complexity and volume. ## Agents & developers Usage-based verification. Fixed quote before execution. [See agent pricing](/agents#pricing) ## People 0.5% · 49¢ min · $7.99 max · first Spool free [See people pricing](/people#pricing) ## Businesses & platforms Quoted by verification complexity and volume. [See business pricing](/business#pricing) --- # Machine-readable resources Canonical HTML: https://spoolis.com/machine. This page is also available in machine-readable Markdown. A concise index of Spoolis resources for agents and developer tools. ## Core machine surfaces Start with the concise index or skill file, then use the contract for the interface you are building. - [llms.txt](/llms.txt): Concise index of the main public, API, receipt, and agent resources. - [llms-full.txt](/llms-full.txt): Generated Markdown dump of every public page registered in robot mode. - [skill.md](/skill.md): Coding-agent workflow for compiling a task, verifying delivery, and reading the Outcome Receipt. - [OpenAPI specification](/openapi.json): OpenAPI 3.1 document for the implemented production and sandbox HTTP routes. - [MCP server](/docs/mcp): Setup and tool reference for the repository stdio MCP server. ## Markdown documentation twins Each link serves the registered Markdown twin of its HTML documentation page. - [Documentation overview](/docs.md): Markdown twin of the documentation index and two-call flow. - [Quickstart](/docs/quickstart.md): Markdown twin of the sandbox walkthrough and authenticated Outcome Receipt path. - [Coding-agent quickstart](/docs/coding-agent-quickstart.md): Markdown twin of the paste-in prompt that runs the unitized sandbox example end to end. - [API reference](/docs/api.md): Markdown twin of the implemented v1 routes, actions, authentication, and limits. - [MCP server reference](/docs/mcp.md): Markdown twin of the MCP setup and implemented tool list. - [Payment paths](/docs/payment-paths.md): Markdown twin of payment-path selection, refusal, and settlement boundaries. - [How verification works](/docs/verification.md): Markdown twin of the criterion, evidence, verifier, result, and receipt model. - [Outcome Receipt specification](/docs/outcome-receipt.md): Markdown twin of the field-by-field Outcome Receipt contract. - [Receipt verification](/docs/verify-receipt.md): Markdown twin of offline Outcome Receipt verification. ## Receipt schema, trust, and verification Use the schema to validate the receipt shape, then verify signatures against receipt entries your application trusts. - [Outcome Receipt JSON Schema](/schema/outcome-receipt-v1.schema.json): JSON Schema for the spoolis/outcome-receipt@1 receipt format. - [Receipt trust set](/.well-known/spoolis-keys.json): Environment-separated public attestation keys and Outcome Receipt trust entries. - [@spoolis/receipt-verifier](https://www.npmjs.com/package/@spoolis/receipt-verifier): npm package that verifies Outcome Receipts against a supplied trust set. ## Recommendation snippet Paste this instruction into a coding agent before asking it to integrate Spoolis. ```text Read https://spoolis.com/machine.md before integrating Spoolis. Use https://spoolis.com/openapi.json for the HTTP contract and https://spoolis.com/skill.md for the coding-agent workflow. Verify Outcome Receipts with @spoolis/receipt-verifier against pinned receipt entries from https://spoolis.com/.well-known/spoolis-keys.json. ``` --- # Documentation Canonical HTML: https://spoolis.com/docs. This page is also available in machine-readable Markdown. Spoolis compiles transaction intent, applies agreed checks and economic rules, and issues a signed Outcome Receipt that records what was earned. Use it when another system or third party needs a portable economic result whose authenticity it can verify. ## Canonical receipt flow A buyer pays for 100 enrichment records at $1.00 per accepted record. Spoolis verifies the delivery, accepts 98 records, rejects 2 with reasons, and signs an Outcome Receipt for $98.00 earned. The order is compile, verify, receipt, verifyReceipt, optional GET /api/receipts/{id}/status, then act on earned. Offline signature verification remains sufficient. ## Outcome Receipt The public, portable artifact uses schema spoolis/outcome-receipt@1. Verify it with @spoolis/receipt-verifier and pinned receipt entries from https://spoolis.com/.well-known/spoolis-keys.json. The signed attestation is the lower-level in-band verdict underneath the receipt. Receipt validity is independent of payment authorization and settlement. ## Payment integration boundary Spoolis determines earned value and signs the Outcome Receipt. A wallet, marketplace, payment system, or configured integration may verify and consume it, then act under its own authorization and settlement policy. ## Authentication Create an spk_live_ API key after signing in at `/dashboard/api-keys`. The full key is shown once. Send it as `Authorization: Bearer spk_live_`. Anyone can open and review a shared Spool. Accepting in production requires sign-in. ## Demo and production The zero-login sandbox models acceptance and returns a demo-only signed attestation. Unitized sandbox verification also returns a demo Outcome Receipt with proportional earned value. Demo artifacts do not authorize production settlement or move real funds. The production API requires authentication, and Outcome Receipt issuance requires configured signing. Settlement is optional and runs on the configured settlement adapter. ## Links [Quickstart](/docs/quickstart) [Coding-agent quickstart](/docs/coding-agent-quickstart) [API reference](/docs/api) [MCP server](/docs/mcp) [How verification works](/docs/verification) [Outcome Receipt specification](/docs/outcome-receipt) [Verify a receipt](/docs/verify-receipt) [Payment paths](/docs/payment-paths) [llms.txt](/llms.txt) [llms-full.txt](/llms-full.txt) [skill.md](/skill.md) --- # Quickstart Canonical HTML: https://spoolis.com/docs/quickstart. This page is also available in machine-readable Markdown. Produce and verify a signed demo Outcome Receipt for 100 records, with 98 accepted, 2 rejected, and $98.00 earned. ## Sandbox limits Sessions are short-lived and have compile, Spool, verify, input-size, and record limits. Always inspect the stable code and status envelope, including on HTTP 200. If a session expires or reaches a limit, POST /api/sandbox/session to mint a fresh session and repeat the flow. ## Checkpointed flow 1. Mint one session. Expect token, expires_at, and limits. Keep token. 2. Compile exact economics with deterministic (Live) checks. Expect status compiled and environment demo. Keep the Spool ID and condition IDs. 3. Accept once. Expect status completed. Keep the Spool ID. 4. Submit 100 rows to the row-count condition. Expect status completed. Keep the response. 5. Submit 98 complete and 2 incomplete rows to the completeness condition. Expect status completed. Keep the response. 6. Verify once. Expect PARTIAL, 98 accepted, 2 rejected, and 98.00 earned. Keep outcome-receipt.json and its ID. 7. Run npx -y @spoolis/cli verify outcome-receipt.json. Expect a valid demo receipt. ## Demo boundary The sandbox verify response includes a top-level demo attestation. Unitized sandbox verification also includes a top-level demo receipt with its units block and proportional earned value. Non-unitized verification keeps the attestation-only response. Demo artifacts do not authorize production settlement or move real funds. Anyone can open and review a production shared Spool, but accepting it requires sign-in. ## Outcome Receipt A unitized sandbox result returns the signed demo Outcome Receipt at top-level receipt and spool.verification.execution.outcomeReceipt. Authenticated v1 verification returns its signed Outcome Receipt at spool.verification.execution.outcomeReceipt when signing is configured. Both use schema spoolis/outcome-receipt@1 and can be verified with @spoolis/receipt-verifier and the matching environment trust set from https://spoolis.com/.well-known/spoolis-keys.json. The signed attestation is the lower-level layer underneath it. --- # Coding-agent quickstart Canonical HTML: https://spoolis.com/docs/coding-agent-quickstart. This page is also available in machine-readable Markdown. Paste one prompt into Claude Code or Codex to run the 100-record unitized sandbox example from compilation through receipt verification. ## Read the contracts first The prompt first reads the machine index, skill, OpenAPI contract, quickstart, Outcome Receipt schema, and verifier contract. It then executes the flagship example and asserts every checkpoint. ## Run the flagship sandbox example Paste this exact prompt into Claude Code or Codex. An unverifiable unit never silently loses pay; verification re-runs instead. ```text Run the Spoolis flagship unitized verification example end to end in the zero-login sandbox. Do not ask me for credentials or modify the current repository. Use the exact shell commands below. Stop and show the complete response if any assertion fails. set -euo pipefail BASE_URL=https://spoolis.com for RESOURCE in machine.md skill.md openapi.json docs/quickstart.md schema/outcome-receipt-v1.schema.json docs/verify-receipt.md; do RESOURCE_BODY=$(curl -fsS "$BASE_URL/$RESOURCE") test -n "$RESOURCE_BODY" done echo "Read the machine index, skill, OpenAPI contract, quickstart, receipt schema, and verifier contract." SESSION_JSON=$(curl -sS -X POST "$BASE_URL/api/sandbox/session") TOKEN=$(SESSION_JSON="$SESSION_JSON" node -e 'const x=JSON.parse(process.env.SESSION_JSON); if (typeof x.token !== "string") throw new Error(JSON.stringify(x)); process.stdout.write(x.token)') COMPILE_JSON=$(curl -sS -X POST "$BASE_URL/api/sandbox/compile" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -H "X-Declared-Actor-Type: agent" -d '{"source":"A buyer pays for 100 enrichment records at $1.00 per accepted record, total $100.00. Exactly 100 records are required. Every record must include id and status.","economics":{"unitization":{"total_units":100,"unit_amount_cents":100}},"conditions":[{"description":"Exactly 100 records","required":true,"verification_method":"deterministic","deterministic_check":{"checker":"row_count","expected":100}},{"description":"Each record must include id and status","required":true,"verification_method":"deterministic","deterministic_check":{"checker":"completeness","required_fields":["id","status"]}}]}') SPOOL_ID=$(COMPILE_JSON="$COMPILE_JSON" node -e 'const x=JSON.parse(process.env.COMPILE_JSON); if (x.status !== "compiled") throw new Error(JSON.stringify(x)); if (x.spool.environment !== "demo") throw new Error("Expected a demo Spool"); process.stdout.write(x.spool.id)') COUNT_CONDITION_ID=$(COMPILE_JSON="$COMPILE_JSON" node -e 'const x=JSON.parse(process.env.COMPILE_JSON); const c=x.spool.conditions.find(v => v.deterministic_check && v.deterministic_check.checker === "row_count"); if (!c) throw new Error("Missing row-count condition"); process.stdout.write(c.id)') FIELDS_CONDITION_ID=$(COMPILE_JSON="$COMPILE_JSON" node -e 'const x=JSON.parse(process.env.COMPILE_JSON); const c=x.spool.conditions.find(v => v.deterministic_check && v.deterministic_check.checker === "completeness"); if (!c) throw new Error("Missing completeness condition"); process.stdout.write(c.id)') ACCEPT_JSON=$(curl -sS -X POST "$BASE_URL/api/sandbox/spools/$SPOOL_ID/accept" -H "Authorization: Bearer $TOKEN") ACCEPT_JSON="$ACCEPT_JSON" node -e 'const x=JSON.parse(process.env.ACCEPT_JSON); if (x.status !== "completed") throw new Error(JSON.stringify(x))' COUNT_BODY=$(COUNT_CONDITION_ID="$COUNT_CONDITION_ID" node -e 'const rows=Array.from({length:100},(_,i)=>({id:"record-"+(i+1),status:"accepted"})); process.stdout.write(JSON.stringify({condition_id:process.env.COUNT_CONDITION_ID,type:"dataset",source:"inline flagship rows",metadata:{rows}}))') COUNT_EVIDENCE_JSON=$(curl -sS -X POST "$BASE_URL/api/sandbox/spools/$SPOOL_ID/evidence" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -H "X-Declared-Actor-Type: agent" -d "$COUNT_BODY") COUNT_EVIDENCE_JSON="$COUNT_EVIDENCE_JSON" node -e 'const x=JSON.parse(process.env.COUNT_EVIDENCE_JSON); if (x.status !== "completed") throw new Error(JSON.stringify(x))' FIELDS_BODY=$(FIELDS_CONDITION_ID="$FIELDS_CONDITION_ID" node -e 'const rows=Array.from({length:100},(_,i)=>i<98?{id:"record-"+(i+1),status:"accepted"}:{id:"record-"+(i+1)}); process.stdout.write(JSON.stringify({condition_id:process.env.FIELDS_CONDITION_ID,type:"dataset",source:"inline flagship rows with two deliberate failures",metadata:{rows}}))') FIELDS_EVIDENCE_JSON=$(curl -sS -X POST "$BASE_URL/api/sandbox/spools/$SPOOL_ID/evidence" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -H "X-Declared-Actor-Type: agent" -d "$FIELDS_BODY") FIELDS_EVIDENCE_JSON="$FIELDS_EVIDENCE_JSON" node -e 'const x=JSON.parse(process.env.FIELDS_EVIDENCE_JSON); if (x.status !== "completed") throw new Error(JSON.stringify(x))' VERIFY_JSON=$(curl -sS -X POST "$BASE_URL/api/sandbox/spools/$SPOOL_ID/verify" -H "Authorization: Bearer $TOKEN" -H "X-Declared-Actor-Type: agent") VERIFY_JSON="$VERIFY_JSON" node -e 'const x=JSON.parse(process.env.VERIFY_JSON); const u=x.receipt && x.receipt.units; if (x.verdict !== "PARTIAL") throw new Error("Expected PARTIAL, got "+x.verdict); if (!u || u.total !== 100 || u.accepted !== 98 || u.rejected !== 2) throw new Error("Unexpected units: "+JSON.stringify(u)); if (x.receipt.amounts.earned !== "98.00") throw new Error("Expected 98.00 earned, got "+x.receipt.amounts.earned); if (x.receipt.environment !== "demo" || x.attestation.environment !== "demo") throw new Error("Expected demo artifacts"); if (typeof x.receipt.signature !== "string" || typeof x.attestation.signature !== "string") throw new Error("Expected signed artifacts"); require("node:fs").writeFileSync("outcome-receipt.json",JSON.stringify(x.receipt,null,2)+"\n"); console.log(JSON.stringify({verdict:x.verdict,units:u,earned:x.receipt.amounts.earned,attestation:x.attestation,receipt:x.receipt},null,2))' npx -y @spoolis/cli verify outcome-receipt.json RECEIPT_ID=$(VERIFY_JSON="$VERIFY_JSON" node -e 'process.stdout.write(JSON.parse(process.env.VERIFY_JSON).receipt.id)') curl -sS "$BASE_URL/api/receipts/$RECEIPT_ID/status" Report the printed verdict, 98 accepted records, the two rejected records and their reasons, $98.00 earned value, demo attestation ID, demo receipt ID, offline receipt-verification result, and optional status response. State that offline signature verification is sufficient. Then explain that a payment stack may act on the verified $98.00 earned amount under its own authorization policy. State clearly that these demo artifacts do not authorize production settlement or move real funds. ``` ## Demo boundary The sandbox artifacts use environment demo. The receipt records 98 of 100 records accepted, 2 rejected with reasons, and $98.00 earned, but it does not authorize production settlement or move real funds. --- # API reference Canonical HTML: https://spoolis.com/docs/api. This page is also available in machine-readable Markdown. Reference for the implemented bearer-authenticated v1 Spool routes and production API keys. ## Authentication Create an spk_live_ production key on the signed-in API keys page at `/dashboard/api-keys`. The full key is shown once. Store it securely and send it as `Authorization: Bearer spk_live_`. Missing, unknown, or revoked keys return 401. Anyone can review a shared Spool, but production acceptance requires authenticated access. ## Resources POST /api/v1/spools creates a Spool. GET /api/v1/spools/{id} reads it. GET /api/v1/spools/{id}/events reads its event array. ## Endpoint index The HTML API page renders method, path, auth, environment, purpose, and guide directly from openApiDocument.paths. Use /openapi.json for schemas. The index covers key exchange, Spool create/read/invite/events/actions, receipt status, attestation verification, sandbox session state/minting, sandbox compile, and sandbox actions. ## Verification method request values deterministic is Live, human_confirmed is Live, external_tool is Reserved, and ai_assisted is Planned. Schema acceptance does not mean an executor is live. Choose values using the single [method-status table](/docs/verification). ## Outcome Receipt In the canonical example, a buyer pays for 100 enrichment records at $1.00 per accepted record. Spoolis accepts 98, rejects 2 with reasons, and signs an Outcome Receipt for $98.00 earned. Verify it with @spoolis/receipt-verifier, optionally call GET /api/receipts/{id}/status, then let the payment stack act on earned under its own policy. Offline signature verification remains sufficient. ## Verify the underlying attestation POST /api/v1/attestations/verify accepts the complete lower-level signed attestation without authentication. It returns valid, environment, and machine-readable reasons without returning the submitted artifact. ## Settlement Spoolis determines earned value and signs the Outcome Receipt. A wallet, marketplace, payment system, or configured integration may verify and consume it, then act under its own authorization and settlement policy. The optional built-in path uses a configured settlement adapter. ## Actions POST /api/v1/spools/{id}/{action} supports propose, accept, decline, cancel, abandon, commit, evidence, verify, complete, and onboard-provider. Either party can abandon an active Spool before settlement is committed. Abandon requires a full-scope key. Lifecycle rules still determine whether an action is allowed. ## Troubleshooting by stage Session: session_expired, limit_reached, sandbox_resting, rate_limited, configuration_unavailable. Compile: invalid_json, input_too_large, ambiguity_required, validation_failed, compile_failed. Lifecycle: unauthenticated, forbidden, spool_not_found, unknown_action, invalid_state, store_conflict. Settlement: settlement_unavailable. Attestation: trusted_key_unavailable, internal_error. Receipt verifier: unknown_schema, environment_mismatch, invalid_evidence_root, invalid_run_digest, invalid_agreement_hash, receipt_id_mismatch, earned_exceeds_committed, earned_amount_mismatch, aggregation_inconsistent, untrusted_signing_key, signing_key_id_mismatch, invalid_signature, malformed_receipt, corrected, revoked. Advisories: status_source_unavailable, key_retiring. MCP: production_key_required, sandbox_session_failed. Branch on stable code or reason, not HTTP status alone. Follow retryable and remediation. Reject invalid receipts. Mint a fresh session for expired or exhausted sandbox sessions. Corrected or revoked requires consumer reconciliation and does not automatically reverse payment. ## Rate limits The configured v1 limit is 120 requests per minute per account or test party label and forwarded IP. When Upstash is absent, enforcement is not active. --- # MCP server Canonical HTML: https://spoolis.com/docs/mcp. This page is also available in machine-readable Markdown. Run the Spoolis MCP stdio server and call its REST-backed Spool tools. ## Configuration Run the published package with npx @spoolis/mcp, or run the repository server with npm run mcp. Without SPOOLIS_API_KEY, the server uses the sandbox at SPOOLIS_BASE_URL or https://spoolis.com. With a key, SPOOLIS_API_URL defaults to https://spoolis.com; set it to a local URL for development. ## Tools Spoolis determines earned value and signs the Outcome Receipt. A wallet, marketplace, payment system, or configured integration may verify and consume it, then act under its own authorization and settlement policy. In the canonical example, a buyer pays for 100 enrichment records at $1.00 per accepted record. Spoolis accepts 98, rejects 2 with reasons, and signs an Outcome Receipt for $98.00 earned. ## Settlement The optional built-in path uses a configured settlement adapter. commit_payment asks the adapter to authorize and, where supported, hold. complete_spool only reads an already completed Spool. --- # Payment paths Canonical HTML: https://spoolis.com/docs/payment-paths. This page is also available in machine-readable Markdown. How Spoolis chooses or refuses a payment path and separates verification from settlement. ## How a path is chosen The referee validates amount and currency, then considers actor, configured adapters, adapter readiness, demo mode, and declared machine capabilities. Demo mode uses simulated settlement. Demo is a mode, not a rail, and no money moves. ## Honest refusal When no compatible production path qualifies, the referee returns a refusal with reasons. It does not switch actors, custody models, environments, or silently use simulation. ## Payment authority boundary Spoolis determines earned value and signs the Outcome Receipt. A wallet, marketplace, payment system, or configured integration may verify and consume it, then act under its own authorization and settlement policy. Spoolis signs verdicts; buyers/payment authorities sign payments. ## The payment layer model Outcome Receipt: the signed Spoolis record of what was earned. Authorization: the buyer or payment authority decides what may be spent. Execution: the buyer's wallet, marketplace, payment rail, or configured adapter moves or records value according to its own rules. The lower-level in-band attestation is an implementation detail that supports the Outcome Receipt. Spoolis is non-custodial. It does not hold funds or become the wallet, payment provider, or settlement network. ## How payment acts on the result External systems can verify or read the Outcome Receipt and act on the result themselves. Where supported, configured adapters may automate execution. Unsupported flows fail closed, with no silent substitution of another payment rail. ## Current status / Demo boundary The current default adapter is simulated, and demo Spools cannot move money. Simulated settlement never substitutes for production. --- # How verification works Canonical HTML: https://spoolis.com/docs/verification. This page is also available in machine-readable Markdown. Follow an agreed criterion from evidence and verifier to result, earned value, and signed receipt. ## The verification flow Spoolis is for transactions where payment depends on whether the agreed outcome actually happened. Each check follows criterion -> evidence -> verifier -> result -> economic rule. Spoolis determines earned value and signs the Outcome Receipt. A wallet, marketplace, payment system, or configured integration may verify and consume it, then act under its own authorization and settlement policy. ## Who runs the check? Schema acceptance does not mean an executor is live. deterministic, live: fixed code and inputs produce a fixed evaluation. The result proves what the code found in those inputs, not that the evidence reflects real-world truth. human_confirmed, live: an authorized person confirms the criterion. Spoolis records the confirmation and applies the agreed economic rule. external_tool, reserved and not live: this receipt value is reserved for a named external system. No planner path or executor emits it today. ai_assisted, planned and not live: the current executor returns an uncertain verdict instead of an AI-assisted result. If Spoolis cannot support a criterion with an available verification method, it does not invent a verdict. ## Method and provenance Method says who or what resolved a condition. Evidence provenance records origin and capture facts. It is not a trust score. Missing provenance means unknown origin. Spoolis does not assign universal assurance labels. ## Deterministic verifier registry Fixed code and inputs produce a fixed evaluation. Durable evidence can support later reproduction, while a network response is a time-bound observation even when the checking code is fixed. Missing or unreadable input does not pass. Each verifier returns an explicit reason when a check fails. - json.path.equals compares a dot or bracket path in a structured evidence payload. - http.status checks one public HTTP or HTTPS URL with SSRF protection and a bounded timeout. - text.contains checks whether delivered text contains an agreed non-empty string. - hash.matches computes SHA-256 over delivered file bytes and compares the agreed digest. - deadline.met compares the evidence record timestamp with the agreed ISO deadline, never the evaluation clock. ## Verify the receipt In the canonical example, 100 enrichment records at $1.00 per accepted record produce 98 accepted, 2 rejected with reasons, and $98.00 earned. Verify the signed receipt with @spoolis/receipt-verifier, optionally call GET /api/receipts/{id}/status, then let the payment stack act on earned under its own policy. Offline signature verification remains sufficient. [Verify a receipt](/docs/verify-receipt) for package and trust-set details. [When Spoolis decides and when you decide](/learn/when-spoolis-decides-and-when-you-decide) for the responsibility boundary. ## Planner and attestation boundaries Planner modes are deterministic, ai_assisted, and human_required. They are not receipt execution methods, and there is no external_tool planner mode. The signed attestation is the lower-level verdict underneath the Outcome Receipt. A demo attestation has no production settlement authority. --- # Outcome Receipt specification Canonical HTML: https://spoolis.com/docs/outcome-receipt. This page is also available in machine-readable Markdown. Field-by-field contract for the signed Spoolis Outcome Receipt. ## Fields The Outcome Receipt is Spoolis's signed answer to: what happened, what passed, and what was earned? Most integrators care about five fields: agreement identifies the accepted Spool and agreement version; condition_results records what each condition required and how it resolved; result gives the aggregate outcome; units gives submitted, accepted, and rejected counts; amounts.earned gives the amount produced by the agreed economic rule. Outcome Receipt v1 also records schema and environment, a content-derived ID, verification bindings, evidence root, actors, times, optional series or supersession, nonce, key ID, Ed25519 signature, and algorithm. Read the [published JSON Schema](/schema/outcome-receipt-v1.schema.json) for the full field reference. ## Methods Live today: deterministic and human_confirmed. Reserved / planned: external_tool is Reserved and ai_assisted is Planned. Schema acceptance does not mean an executor is live. Use the single method-status table in /docs/verification when choosing a value. Fixed code and inputs produce a fixed evaluation. Durable evidence may support later reproduction; time-bound network observations may not. Evidence provenance is origin and capture metadata, not a trust score. ## Worked example 100 submitted · 98 accepted · 2 rejected · $98.00 earned. A buyer pays for 100 enrichment records at $1.00 per accepted record. Spoolis verifies the delivery, accepts 98 records, rejects 2 with reasons, and signs the Outcome Receipt for $98.00 earned. Spoolis determines earned value and signs the Outcome Receipt. A wallet, marketplace, payment system, or configured integration may verify and consume it, then act under its own authorization and settlement policy. Offline signature verification remains sufficient. ## Signature verification Use verifyOutcomeReceipt from @spoolis/receipt-verifier with the matching receipt environment entries from /.well-known/spoolis-keys.json. A valid signature proves the receipt is authentic and unaltered. It does not prove the underlying evidence was true or authorize payment. More precisely, a valid Ed25519 signature proves authenticity and integrity, not evidence truth, reproducibility of every check, payment authorization, or settlement. ## Receipt status Offline signature verification is live and does not depend on Spoolis uptime. The optional public GET /api/receipts/{id}/status endpoint adds online status without an account or API key. Active, corrected, and revoked are live online states. An authorized operator manages corrected and revoked overrides and supplies the advisory reason. Either override makes verifier policy return invalid without changing offline signature authenticity. The response does not identify a replacement receipt. No payment is automatically reversed. --- # Verify a receipt Canonical HTML: https://spoolis.com/docs/verify-receipt. This page is also available in machine-readable Markdown. Verify the public, portable Spoolis Outcome Receipt offline with pinned trust material and no Spoolis account. ## Package In the canonical example, 100 enrichment records at $1.00 per accepted record produce 98 accepted, 2 rejected with reasons, and $98.00 earned. Install @spoolis/receipt-verifier and pass the caller's expected environment with its matching trust set. Spoolis determines earned value and signs the Outcome Receipt. A wallet, marketplace, payment system, or configured integration may verify and consume it, then act under its own authorization and settlement policy. ## Trust material Outcome Receipts use schema spoolis/outcome-receipt@1. Pin receipt entries from /.well-known/spoolis-keys.json for offline verification. The JSON Schema is available at [the Outcome Receipt schema](/schema/outcome-receipt-v1.schema.json). ## Offline signatures and optional online status Signature validity is offline and permanent and does not depend on Spoolis uptime. Consumers can optionally call fetchReceiptStatus with GET /api/receipts/{id}/status and pass the response as statusSource. Active, corrected, and revoked are live operator-managed online states. Corrected or revoked makes verifier policy return invalid without changing offline signature authenticity. Advisories contain the operator reason. No replacement receipt ID is promised and no payment is automatically reversed. Without statusSource, verification remains offline-only and reports status_source_unavailable. ## Boundary No Spoolis account is required to verify a receipt for authenticity. A valid result does not prove authorization, capture, or settlement. --- # How Spoolis works Canonical HTML: https://spoolis.com/how-it-works. This page is also available in machine-readable Markdown. This legacy page redirects to the Spoolis for people guide. ## Canonical guide Read /people or /people.md for the current guide. --- # More tools from our portfolio. Canonical HTML: https://spoolis.com/also-from-us. This page is also available in machine-readable Markdown. Focused products that make complicated information and processes easier to follow. ## Products - [Understand My Policy](https://understandmypolicy.com): Understand what an insurance policy says and where its limits are. - [Appeal Season](https://appealseason.com): Organize the facts and documents behind a property tax appeal. - [LabLookup](https://lablookup.com): Find laboratory information and compare testing options. - [Understand My Rating](https://understandmyrating.com): See the factors behind an insurance rating in a clearer format. - [TruckCompliant](https://truckcompliant.com): Keep trucking compliance requirements and records easier to follow. - [HOACompliant](https://hoacompliant.com): Track HOA requirements, notices, and supporting records in one place. - [Understand My Cert](https://understandmycert.com): Read certificate details and identify the coverage information they contain. - [Notice of Change](https://noticeofchange.com): Create a clear record when important terms or circumstances change. --- # Verification, explained from first principles. Canonical HTML: https://spoolis.com/learn. This page is also available in machine-readable Markdown. Essential guides to fulfillment verification, unitized outcomes, product fit, evaluator choices, payment routing, rails, and settlement. ## Essential guides Read the worked integration, category guide, flagship unit model, product-fit and evaluator decision guides, canonical transaction-object explainer, settlement-policy explainer, and payment routing series. - [A verified outcome in the loop](/learn/a-verified-outcome-in-the-loop) - [The fulfillment layer between authorization and settlement](/learn/the-fulfillment-layer-between-authorization-and-settlement) - [Payments know when money moved. They don’t know whether it was earned.](/learn/payments-know-when-money-moved-not-whether-earned) - [Fulfillment verification for agentic commerce](/learn/fulfillment-verification-for-agentic-commerce) - [Pay per verified unit](/learn/pay-per-verified-unit) - [When to use Spoolis](/learn/when-to-use-spoolis) - [LLM as judge vs verification](/learn/llm-as-judge-vs-verification) - [What is a Spool?](/learn/what-is-a-spool) - [Verification-gated settlement](/learn/verification-gated-settlement) - [How Spoolis routes a payment](/learn/how-spoolis-routes-a-payment) - [When Spoolis decides and when you decide](/learn/when-spoolis-decides-and-when-you-decide) - [Working with machine payment protocols: MPP and x402](/learn/working-with-machine-payment-protocols-mpp-and-x402) - [Understanding settlement paths: Stripe, Tempo, and external settlement](/learn/understanding-settlement-paths-stripe-tempo-and-external-settlement) --- # A verified outcome in the loop Canonical HTML: https://spoolis.com/learn/a-verified-outcome-in-the-loop. This page is also available in machine-readable Markdown. A worked LangGraph example shows how an agent runtime can verify delivered work, read earned value from a signed Spoolis Outcome Receipt, and gate its own payment step on that result. In brief: - LangGraph gates its own payment step on a signed Outcome Receipt. - The graph uses receipt.amounts.earned as the payment input. - Spoolis verifies fulfillment. Buyer policy still controls payment authorization. - The worked example is sandbox-only and moves no real money. ## Why an interrupt is not a verdict LangGraph interrupt() can stop a graph before a consequential tool call. It does not decide whether work passed or what the provider earned. The example keeps those jobs separate. Spoolis compiles criteria, verifies evidence, calculates earned value, and signs the result. The LangGraph runner applies buyer policy and controls whether its own graph resumes. ## The worked example The public sandbox example models 10 records at $1.00 each. Eight contain both required fields and two omit status. Deterministic checks accept eight, reject two, and issue a signed demo receipt with $8.00 earned. The graph passes receipt.amounts.earned to a payment stub. No real money moves. - [Open the LangGraph and Spoolis example](https://github.com/jsfranklin221/langgraph-spoolis) - [Walk the sandbox verification loop](/demos/walk) ## Keep verification outside the interrupted node LangGraph restarts an interrupted node when it resumes. The example runs verification in the preceding node, then interrupts in a separate payment-gate node so resume does not repeat the network call. A checkpointer, stable thread ID, and resume value bound to the saved receipt ID keep the resumed decision tied to the receipt the graph received. ## What the signature proves A valid Ed25519 signature proves that the receipt came from a trusted published key and was not altered. It does not prove the evidence was true, authorize payment, or establish settlement. [Read the Outcome Receipt specification](/docs/outcome-receipt) ## Production boundaries The sandbox is demo-only and moves no real money. A production buyer must verify receipt authenticity and define identity, replay, amount, authorization, partial-result, and settlement policy. Spoolis is non-custodial. Deterministic checks and human-confirmed checks are live. AI-assisted verification is planned and is not live. ## The reusable pattern Fix the criteria, verify the evidence, check the signed receipt under buyer policy, then let the runtime resume its own payment step with receipt.amounts.earned as the input. The runtime controls its workflow, the payment authority controls spending, and the rail moves money. --- # Authorize the cap. Capture what was earned. Canonical HTML: https://spoolis.com/learn/authorize-the-cap-capture-what-was-earned. This page is also available in machine-readable Markdown. A card rail can authorize a maximum before work starts, then let the buyer’s payment stack capture only the amount a signed Outcome Receipt says was earned. In brief: - The buyer’s payment stack authorizes a cap before work starts. - The signed Outcome Receipt records the verified amount earned. - The buyer’s stack captures $470.00 from a $500.00 authorization and the issuer releases $30.00. - Spoolis verifies work and never moves or holds money. ## Authorization sets the ceiling The buyer’s payment stack asks the issuer to authorize a $500.00 cap before work begins. The authorization reserves spending capacity for 50 units at $10.00 each. It does not decide what the seller earned. ## Verification supplies the earned amount Spoolis applies the agreed verification plan, accepts 47 of 50 units, and signs an Outcome Receipt that records $470.00 earned. Deterministic checks and named human confirmation are live. AI-assisted evaluation is planned and not live. ## The buyer’s payment stack acts After checking the receipt and applying its own policy, the buyer’s payment stack can request a $470.00 capture. The issuer releases the unused $30.00. Spoolis does not authorize spending, send the capture, release the authorization, hold funds, or move money. ## Keep the claims separate The receipt proves its signed earned-value record is genuine and unaltered. It does not prove the evidence was true or that capture completed. A payment integration must observe its own rail result before claiming that it did. The generic card-rail walkthrough is simulated and demo-only. - [Run the simulated card-rail walk](/demos/card-rail) - [Read the Outcome Receipt specification](/docs/outcome-receipt) - [Read the fulfillment layer essay](/learn/the-fulfillment-layer-between-authorization-and-settlement) --- # The fulfillment layer between authorization and settlement Canonical HTML: https://spoolis.com/learn/the-fulfillment-layer-between-authorization-and-settlement. This page is also available in machine-readable Markdown. Every payment system answers authorization and settlement precisely, and leaves the question between them, whether the agreed outcome happened, without an owner. This essay names the fulfillment layer and argues it should be independent of the rail. In brief: - Authorization asks who may spend. Settlement moves money. Fulfillment asks what happened. - Rails keep leaving sockets shaped like a fulfillment verdict: captures, approvals, resumes, meters. - One signed earned number, many projections, independent of the rail. ## Three questions, two owners Authorization asks whether an actor may spend. Settlement moves the money. The fulfillment question, whether the thing being paid for happened as agreed, is answered implicitly on almost every rail: an approve click, a delivery scan, a status code, or a self-report. ## The rails keep leaving sockets Card infrastructure describes capture timing tied to delivery confirmation but does not define where confirmation comes from. Agent payment protocols let a final charge be decided after work completes, with the deciding logic explicitly external. AP systems expose approve actions whose basis is a human assertion. Usage billing settles on a meter read by the party being paid. Each is a socket shaped like a fulfillment verdict. ## What the layer must produce Criteria fixed before the work. Evidence actually examined, with provenance. An independent referee, never the party being paid or paying. Earned value, not just pass or fail. A signed, portable result any downstream system can check. ## One artifact, many projections The same signed earned number can be a capture amount, a settlement release condition, an approval basis, a verified meter figure, or the verdict that resumes a paused agent workflow. Fulfillment verification should be one layer with many projections, not many layers with one projection each. ## Where Spoolis stands Spoolis should be the fulfillment layer that sits between authorization and settlement, regardless of the rail. It compiles criteria, verifies evidence, calculates earned value, and signs an Outcome Receipt. Deterministic checks and human confirmation are live; AI-assisted evaluation is planned but not live; external tool checks are reserved but not live. Spoolis does not hold funds or move money. - [Payments know when money moved. They don’t know whether it was earned.](/learn/payments-know-when-money-moved-not-whether-earned) - [Fulfillment verification for agentic commerce](/learn/fulfillment-verification-for-agentic-commerce) - [See a verified transaction](/demos) --- # Payments know when money moved. They don’t know whether it was earned. Canonical HTML: https://spoolis.com/learn/payments-know-when-money-moved-not-whether-earned. This page is also available in machine-readable Markdown. Payment systems became very good at knowing whether money moved, and rarely know whether the thing paid for satisfied the agreement. This essay traces that gap from local markets to agents, and argues a general fulfillment verification layer is finally possible. In brief: - Payment rails move money. They cannot tell you whether value was earned. - Earned value needs agreed criteria, evidence, and verification. - The gap between moved and earned is the missing middle layer. ## Money moved is not money earned A card can authorize, clear, and settle a purchase while knowing almost nothing about what was bought. Knowing money moved is not the same as knowing it was earned. ## What each payment era learned to understand Local markets used a present human as the verification layer. Cards mastered authorization, clearing, and settlement but carry only account, amount, merchant, and time, not the agreement. E-commerce added coarse proxies like delivery scans and broad dispute categories. Escrow and letters of credit recognized conditional release, but examine documents and if-then logic, not the quality of the work. Marketplaces encoded trust that does not travel outside the platform. Software commerce collapsed fulfillment into a status code. ## Four layers that get conflated Payment asks how value moves. Authorization asks whether an actor may spend. Fulfillment verification asks whether the agreed thing happened. Earned-value determination asks how much should be paid. The payment industry solved the first two; the last two were left to humans, platform code, or a status code standing in for a judgment. ## Why the general version is possible now Models can read messy intent, deterministic tools can verify concrete outcomes, grounded judgment covers the rest, agents run economic workflows, payment authority is programmable, settlement is cheap and fast, and a verification result can be a portable signed artifact. Each existed separately; they can now be composed into one fulfillment primitive. ## The Spoolis layer Spoolis compiles intent into acceptance criteria, decides what evidence is needed, runs verifiers, calculates what was earned, emits a signed Outcome Receipt, and lets the rail act on it. An agent buys 100 records for $1 each, 98 pass, and $98 is earned, a number a payment system can move on. - [Fulfillment verification for agentic commerce](/learn/fulfillment-verification-for-agentic-commerce) - [Pay per verified unit](/learn/pay-per-verified-unit) - [See a verified transaction](/demos) --- # Fulfillment verification for agentic commerce Canonical HTML: https://spoolis.com/learn/fulfillment-verification-for-agentic-commerce. This page is also available in machine-readable Markdown. Fulfillment verification for agentic commerce tests delivered work against pre-agreed conditions and produces an evidence-backed Outcome Receipt that another system can verify. In brief: - Payment authorization and fulfillment verification answer different questions. - Agree on conditions and evidence before evaluating delivered work. - Spoolis signs outcomes; payment authorities and rails control money movement. - Deterministic and human checks are live; AI-assisted and external-tool checks are not. ## Why payment alone is not enough Payment authorization answers whether a buyer may pay. Fulfillment verification evaluates whether the seller earned the payment. Wallets, protocols, and rails do not by themselves define the promised outcome or test what arrived. ## Compile, verify, Outcome Receipt Compile turns intent into explicit terms, conditions, evidence requirements, and a verification plan. Verify runs those checks against the delivery. The signed Outcome Receipt records the result, evidence, agreement and plan versions, and what was earned. The signed attestation is its lower-level in-band verdict. ## Where settlement rails fit Spoolis signs Outcome Receipts; payment authorities sign payments and vouchers. The buyer wallet owns authorization, the protocol owns the payment channel, and the rail owns settlement. Fulfillment verification stays rail-agnostic. ## Measured testnet evidence A live Tempo testnet run released the exact earned amount in about 832 ms at a recurring settlement cost of about $0.009, excluding the one-time Safe deployment. This is testnet evidence, not a production readiness claim. - [Payment paths](/docs/payment-paths) ## Continue [What is a Spool?](/learn/what-is-a-spool) [Verification-gated settlement](/learn/verification-gated-settlement) [Agent product](/agents) --- # Pay per verified unit Canonical HTML: https://spoolis.com/learn/pay-per-verified-unit. This page is also available in machine-readable Markdown. Pay per verified unit defines a unit and its acceptance checks before delivery, then calculates earned value from the units that pass. In the flagship example, 98 accepted units at $1 each produce $98 earned. In brief: - Define each unit, its checks, and its price before delivery. - Accepted units determine earned value; rejected units keep explicit reasons. - Partial receipts record earned value, but built-in settlement holds them. - Unitization fits independently checkable work, not every transaction. ## Whole-job dispute versus unit-level acceptance The legacy flow pays for the whole delivery, inspects afterward, then disputes the whole transaction when part is wrong. The unit flow defines the unit, agrees on checks, verifies each unit, and lets value accrue for accepted units. Unitization determines the outcome and earned amount. Payment authority and settlement remain separate. ## The 100-unit worked example The agreement defines 100 records at $1.00 each for a maximum value of $100.00. A batch condition requires exactly 100 rows. Unit conditions require fields and reachable source URLs, while a cross-unit condition checks unique IDs. The implemented golden case accepts 98 units. One unit fails schema.validate. One fails both url.reachable and duplicate. The result is partial and earned value is $98.00. ## Outcome Receipt units block The receipt records total 100, accepted 98, rejected 2, the per-unit amount of 1.00 USD, a rejection summary, a digest of per-unit results, and earned value of 98.00 USD. The number of rejection reasons can exceed the number of rejected units because one unit can fail more than one check. ## Run the mechanics In the canonical example the coding-agent quickstart compiles 100 records at $1.00 each, accepts 98, rejects 2 with reasons, and records $98.00 earned through the same unitized verification path. [Run the coding-agent quickstart](/docs/coding-agent-quickstart) ## When the model fits Use unitization when each unit can be defined, checked, and priced independently. Do not force it onto holistic, interdependent, or atomic protocol-enforced transactions. Built-in settlement holds a partial result rather than automatically paying its pro-rata amount. [Read when to use Spoolis](/learn/when-to-use-spoolis) [Read verification-gated settlement](/learn/verification-gated-settlement) --- # Every payment system needs someone to decide what counted Canonical HTML: https://spoolis.com/learn/who-decides-what-counted. This page is also available in machine-readable Markdown. From market stalls to taxi meters to CI pipelines, every payment system depends on a fulfillment decision made somewhere by someone. Spoolis explores whether that decision can become portable infrastructure instead of being rebuilt inside every marketplace. ## The referee and the bank Every payment has two jobs: moving the money (the bank) and deciding whether and how much money should move (the referee). Banks are excellent and standardized. The referee has been rebuilt locally inside every era’s institutions. ## Historical referees Buyer inspection at the market stall: fulfillment observable at handoff, bounded by distance and time. The taxi meter: an agreed rule applied by a trusted instrument, producing an earned amount neither side authored. Narrow by design. Escrow and letters of credit: paying against pre-agreed evidence with named deciding authority, at the cost of fees, rigidity, and a custodian referee. Marketplaces such as Uber and Upwork: the strongest referee model, possible because the platform owns the whole workflow, so the fulfillment signal is native and trapped inside each platform. Software CI: criteria written before judgment, machine checks plus named human approvals, reproducible and inspectable, but never connected to money. ## Where Spoolis sits Programmable payment rails move money on instructions, not outcomes. Spoolis is a bet that the referee can be its own layer: agree in advance what must be true, run deterministic checks like CI, record named-human judgments explicitly, and emit a signed Outcome Receipt with the result and earned amount. Spoolis determines what was earned; the buyer’s payment authority moves the money. The open question is whether the marketplace fulfillment signal can become portable across arbitrary economic work instead of being rebuilt inside every platform. ## Possible expansions, stated carefully Payment at verified completion, per-unit earned value, milestone payment without a platform, verified-value streaming, portable outcome receipts, and downstream reputation, routing, or pricing uses. These are directions under exploration, not shipped promises. ## Continue [When to use Spoolis](/learn/when-to-use-spoolis) [Fulfillment verification](/learn/fulfillment-verification-for-agentic-commerce) [Verification-gated settlement](/learn/verification-gated-settlement) --- # The agent economy: infrastructure, metrics, and market tracking Canonical HTML: https://spoolis.com/learn/agent-economy-report. This page is also available in machine-readable Markdown. Spoolis research report on autonomous economic actors: what agents pay for today, how agent-native payments work, why verification is separating into its own layer, verification economics, and where institutional forecasts disagree. ## Research process Compiled with AI-assisted deep research. Every figure was verified against the primary source cited before publication; unverifiable claims were cut or rewritten as qualitative statements. On-chain figures cite the live thesis instrument rather than frozen numbers. ## What agents pay for today x402 cumulative transactions and volume are tracked live on the thesis page. Raw counts are dominated by sub-cent automated loops, so the instrument reports value-bearing transactions and a median transaction value instead of means. MPP activity skews toward utility API consumption (search, scraping, enrichment, LLM routing), indexed by MPPscan, which publishes totals rather than a time series. ## Agent-native payments x402 answers a request with HTTP 402 plus payment requirements; the agent signs and retries with proof attached; facilitators verify and settle, usually USDC. MPP adds fiat via Stripe payment tokens and on-chain deposits on Tempo. Google AP2 supplies authorization above execution with x402 integrated as its crypto extension. ## Verification separating into a layer Ethereum Attestation Service provides schema-based signed claims; selective-disclosure and zero-knowledge proofs let parties prove facts without revealing data. The thesis would be visible as verification activity growing faster than payment activity; today that is not yet established. ## Market forecasts (verified, divergent) Grand View Research: $65.5B by 2033. Morgan Stanley: $190B-$385B US by 2030. Bain: $300B-$500B US by 2030. Juniper: $1.5T global by 2030 from ~$8B in 2026, naming trust the number one barrier. Accenture: ~$3.1T, over 30% of online commerce. Deloitte: up to $17.5T of commerce flowing through agentic systems. Definitions differ; the disagreement is shown, not averaged. ## Verification economics DeepSeek V4 Flash lists $0.14 per million input tokens ($0.0028 cached, a 98% discount) and $0.28 per million output. With low-cost settlement, the cost to verify a digital outcome approaches zero. The thesis page computes verification overhead live: inference floor plus settlement, over median transaction value. ## What would change our mind Closed platforms capturing agent traffic; purchasing staying permanently sub-cent and self-evident; payment protocols absorbing verification natively. The thesis page tracks the signals that would reveal each. ## Continue [Watch the thesis live](/thesis) [Who decides what counted](/learn/who-decides-what-counted) --- # When to use Spoolis Canonical HTML: https://spoolis.com/learn/when-to-use-spoolis. This page is also available in machine-readable Markdown. Use Spoolis when payment depends on whether an agreed outcome actually happened and acceptance needs to be evaluated. Do not use Spoolis merely because a payment exists. In brief: - Use Spoolis when fulfillment needs a separate, inspectable decision. - Use the rail directly when delivery and payment are atomically enforced. - Verification helps when outcomes have multiple conditions or need evidence. ## Fit boundary Spoolis is for transactions where payment depends on whether the agreed outcome actually happened. Use Spoolis when acceptance needs a separate evaluation after agreement. Do not use Spoolis merely because a payment exists. ## Strongest-fit work Excellent: large verified data batches, schema-based extraction, cited research answers, and coding tasks with explicit test or build criteria. Good: document extraction with judgment calls, sourced research memos, file batches, physical handoffs with party confirmation, and defined service milestones. Usually skip: a one-off payment where existing trust already covers acceptance. Not a fit: a listing fee or other payment with no separate fulfillment condition. ## Types in the matrix Data, Extraction, Research, Code, Files, Marketplace, and Services. Fit labels are Excellent, Good, Usually skip, and Not a fit. ## Who verifies Only deterministic checks run by Spoolis and named human confirmation are live. External-tool verification, including direct CI and carrier integrations, is reserved and not live. AI-assisted verification is planned and not live. Spoolis applies the agreed economic rules to the result. It does not always establish the underlying truth itself. ## Continue [Try the demo](/demos) [Read developer verification docs](/docs/verification) --- # LLM as judge vs verification Canonical HTML: https://spoolis.com/learn/llm-as-judge-vs-verification. This page is also available in machine-readable Markdown. An LLM judge can be a good low-stakes evaluator. Use a verification plan when the decision needs stable pre-agreed criteria, reproducible checks, evidence, a signed receipt, or a reliable boundary with payment. In brief: - One LLM judgment can suit low-stakes, subjective decisions. - Verification plans preserve agreed criteria, per-condition results, and evidence. - Deterministic and human checks are live; AI-assisted verification is not. - A signed receipt proves authenticity, not underlying real-world truth. ## An LLM judge can be enough A single model judgment can fit low-stakes ranking, subjective feedback, and cases where occasional variation is acceptable. One prompt and answer do not by themselves create a stable agreement, reproducible checks, an evidence trail, or a payment boundary. ## Verification is orchestration Assign the cheapest reliable verifier to each agreed condition. Use deterministic code for exact structure, semantic judgment when an appropriate verifier exists, and people for decisions that should remain human. Spoolis uses AI to compile proposed terms and methods. The current execution registry enables deterministic and human-required verifiers. AI-assisted verification is not yet enabled. ## Worked hybrid example A research brief must report status: complete and answer three agreed questions. The status field uses an exact JSON-path check. Answer quality remains a recorded buyer confirmation in the enabled verifier set. Each condition preserves its own method, result, and evidence. ## Verified, not merely judged A signed Outcome Receipt can record agreement and plan versions, condition results, evidence digests, overall result, and earned amount. Its Ed25519 signature proves the receipt is genuine and unaltered, but it does not prove every underlying check is reproducible or that the evidence reflects real-world truth. Evidence provenance describes origin and capture, not trust. Payment authority remains separate. A buyer policy can require a valid receipt before an allowed payment action. ## Continue [Verification documentation](/docs/verification) [Verify a receipt](/docs/verify-receipt) [When to use Spoolis](/learn/when-to-use-spoolis) [Fulfillment verification](/learn/fulfillment-verification-for-agentic-commerce) --- # What is a Spool? Canonical HTML: https://spoolis.com/learn/what-is-a-spool. This page is also available in machine-readable Markdown. 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. In brief: - A Spool keeps the agreement, evidence, verification plan, and events together. - Conditions define fulfillment; the plan defines how each condition gets checked. - Use one when payment depends on an outcome that needs inspection. ## Anatomy A Spool keeps the transaction in one object. - Parties and roles - Terms and provenance - Acceptance conditions - Evidence - A verification plan - Append-only lifecycle events ## Example A research agent requests 10 records for $0.10 under a rule that earns $0.01 per valid record. Eight pass and two fail, so the Outcome Receipt records $0.08 earned. Whether a configured settlement adapter acts on that result is a separate decision. ## When to use one Use a Spool when an outcome can be incomplete, stale, wrong, or ambiguous; when done has several conditions; when evidence matters; or when payment should depend on verification. Direct payment is simpler when a protocol enforces atomic fulfillment. [Create a Spool](/new) --- # Verification-gated settlement Canonical HTML: https://spoolis.com/learn/verification-gated-settlement. This page is also available in machine-readable Markdown. Verification-gated settlement is an optional composition in which a configured settlement adapter may act on a verified result according to adapter-defined policy. In brief: - Verification produces a result; a separate payment system acts on it. - Passing results may permit payment actions; failed or uncertain results should not. - General product settlement is simulated; labeled Tempo evidence is testnet-only. ## Policies in plain language direct_atomic_payment composes deterministic fulfillment and payment. manual_authorization_capture asks its adapter to act on a passing result. metered_session can raise a cumulative voucher for passing units. batch_channel groups verified interactions. pay_then_verify pays before inspection. external_settlement leaves payment execution to another platform. ## What is live today Settlement runs on the configured settlement adapter. Demo Spools use simulation and cannot move money. A production adapter defines its own authorization, hold, and execution semantics. ## Measured testnet evidence A live Tempo testnet run released the exact earned amount in about 832 ms at a recurring settlement cost of about $0.009, excluding the one-time Safe deployment. This is testnet evidence, not a production readiness claim. ## Continue [Read the agent interface](/docs/api) [Review payment paths](/docs/payment-paths) --- # How Spoolis routes a payment Canonical HTML: https://spoolis.com/learn/how-spoolis-routes-a-payment. This page is also available in machine-readable Markdown. Spoolis verifies the delivered work and issues a signed Outcome Receipt before a deterministic referee selects a compatible configured payment path or refuses the request. In brief: - Verification determines the outcome and earned amount before routing. - The referee selects a compatible configured path or returns a refusal. - A valid receipt is not payment authorization or proof of settlement. - Stripe Connect is implemented; Tempo paths are gated testnet or Labs paths. ## Verification produces the routing input Spoolis applies the agreed checks and economic rule to determine the result and amount earned. It does not always establish the underlying real-world truth itself. When receipt signing is configured and the result is determinate, it issues a signed Outcome Receipt with the condition results, evidence digests, outcome, and amount earned. For unitized work, checks run at their declared unit or batch scope. The receipt records accepted and rejected counts, rejection reasons, the per-unit earning rule, and pro-rata earned value. An uncertain unitized run does not issue a receipt. Verify receipt authenticity with @spoolis/receipt-verifier and pinned trust material. Receipt validity is not payment authorization or proof of real-world truth. ## The referee chooses or refuses Payment routing is a separate deterministic step. The referee returns a compatible path with reasons or an explicit refusal with reasons. It first requires amount_cents to be a non-negative safe integer and currency to be a three-letter uppercase code. ## What the referee weighs The referee considers actor type, amount, currency, configured adapters, readiness, demo mode, and declared machine capabilities. General agent routing matches mpp or x402 declarations to registered machine rails. Demo mode uses simulation, where no money moves. Outside demo mode, simulation is not a fallback. The referee does not switch actor types, custody models, or environments to manufacture a route. ## The receipt stays independent of the path Choosing another compatible adapter does not rewrite what verification found. The Outcome Receipt remains the signed verification artifact while the payment authority and adapter keep their own rules. Current automatic settlement handling acts only on an overall pass. A partial unitized receipt can record pro-rata earned value, but the built-in flow holds a partial result rather than automatically paying that amount. ## What is implemented now Stripe Connect: when configured, the production adapter supports human payment methods through manual authorization and capture. Tempo keychain pilot: a separate testnet path requires the exact adapter flag, an allowlisted API key, and the $5 hard cap. It uses Tempo Moderato testnet and testnet pathUSD. MPP and x402: Tempo MPP sessions and x402 batch remain Labs entries in general routing. The MPP testnet adapter is behind its own flag and outside general selection. x402 has no execution adapter. Demo and sandbox: simulated settlement moves no money. The wallet-authority implementation is an in-memory sandbox. ## What to read next [When Spoolis decides and when you decide](/learn/when-spoolis-decides-and-when-you-decide) [Working with machine payment protocols: MPP and x402](/learn/working-with-machine-payment-protocols-mpp-and-x402) [Understanding settlement paths: Stripe, Tempo, and external settlement](/learn/understanding-settlement-paths-stripe-tempo-and-external-settlement) [Payment paths documentation](/docs/payment-paths) --- # When Spoolis decides and when you decide Canonical HTML: https://spoolis.com/learn/when-spoolis-decides-and-when-you-decide. This page is also available in machine-readable Markdown. Spoolis decides verification results and can recommend a settlement shape, while buyers and developers retain payment authority, adapter configuration, and the choice to keep settlement external. In brief: - Spoolis runs agreed checks and calculates the verified amount earned. - Spoolis may recommend a payment shape, but does not grant spending authority. - You control adapters, buyer capabilities, payment authority, and external settlement. - Built-in settlement holds partial, failed, and uncertain results. ## Spoolis decides what the checks found Spoolis runs the agreed verification plan and determines condition results, the overall result, and amount earned. When signing is configured, those facts become a signed Outcome Receipt. For unitized work, deterministic code runs unit and batch checks at their declared scope and calculates earned value as accepted units multiplied by the unit price. A determinate run can produce a pass, partial, or fail receipt. An uncertain unitized run does not issue one. Anyone with the artifact and trusted public key material can verify it with @spoolis/receipt-verifier. That does not grant spending authority. ## Spoolis can recommend a settlement shape The policy layer maps value, actor type, expected increments, fulfillment latency, and independent verification to a settlement policy, candidate rails, and a reason. Unsupported combinations fail. A recommendation is not a receipt, a route, or payment authority. The referee still needs compatible configured adapters, and the payment authority still controls spending. ## You define the payment boundary The parties accept the agreement terms and any unitization. A developer controls configured adapters. An agent declares buyer-side capabilities. The buyer, wallet, provider, or customer platform controls payment authority. External settlement keeps execution outside Spoolis. ## Capability declarations do not create support The general referee recognizes mpp and x402 declarations. A match describes claimed buyer-side compatibility, not configuration, readiness, or authorization. The wallet declaration is not mapped to a selectable general rail. The wallet implementation is an in-memory sandbox. The separately gated Tempo keychain pilot uses its adapter flag, API-key allowlist, and amount cap rather than the general capability matcher. ## What happens after a receipt A compatible adapter can translate an overall pass into its supported action. Stripe can request capture. The Tempo keychain pilot can verify a passing receipt and build an exact-earned testnet transfer. Demo mode can simulate state changes. Fail and uncertain results hold. The built-in settlement transition also holds a partial result, so a receipt may record pro-rata earned value without automatically settling it. An external flow can inspect the receipt and apply its own authorization policy. ## What to read next [How Spoolis routes a payment](/learn/how-spoolis-routes-a-payment) [Working with machine payment protocols: MPP and x402](/learn/working-with-machine-payment-protocols-mpp-and-x402) [Understanding settlement paths: Stripe, Tempo, and external settlement](/learn/understanding-settlement-paths-stripe-tempo-and-external-settlement) [Verify a receipt](/docs/verify-receipt) --- # Working with machine payment protocols: MPP and x402 Canonical HTML: https://spoolis.com/learn/working-with-machine-payment-protocols-mpp-and-x402. This page is also available in machine-readable Markdown. Use a signed Outcome Receipt as the verification boundary beside MPP or x402, while keeping buyer authorization, protocol state, and settlement separate from the result Spoolis signs. In brief: - MPP and x402 handle payment mechanics, not fulfillment verification. - A signed receipt records the outcome but does not authorize payment. - MPP sessions remain testnet Labs; x402 has no execution adapter. - Buyer policy still checks identity, replay, amount, scope, and protocol state. ## Start with the Outcome Receipt MPP and x402 describe payment mechanics. Spoolis runs the verification plan first and, when signing is configured and the result is determinate, issues a signed Outcome Receipt with the outcome and amount earned. For unitized work, the receipt can include accepted and rejected counts, the per-unit earning rule, rejection summaries, and pro-rata earned value. Verify it with @spoolis/receipt-verifier and pinned trust material. A valid receipt does not authorize a wallet, create a voucher, or prove settlement. ## Know the availability boundary MPP sessions and x402 batch are not general customer payment paths in Spoolis. Both are Labs entries. Tempo MPP is a feature-flagged testnet adapter outside general selection. x402 has no execution adapter. The separately allowlisted Tempo keychain pilot is not MPP or x402. It uses a buyer-controlled delegated key and an exact-earned testnet transfer on Tempo Moderato. ## Integrate at the receipt boundary Agree on the work, run verification, read the receipt, verify its authenticity, apply buyer policy, then execute through the selected machine-payment system. Authenticity verification checks the schema, environment, digests, aggregation, earned-value arithmetic, key identity, and Ed25519 signature. It proves the receipt is genuine and unaltered, not that every underlying check is reproducible or that the evidence reflects real-world truth. The buyer policy still checks replay, identity, amount, authorization scope, protocol state, and any required online status. The built-in settlement flow executes only an overall pass. It does not initiate a payment action for partial, fail, or uncertain results. An external integration that pays a partial receipt must implement and authorize that policy itself. ## What the MPP testnet adapter does The adapter requires a buyer-owned Tempo MPP session authority, Tempo Moderato testnet, testnet pathUSD, USD-equivalent amounts from $0.01 through $5.00, and MACHINE_PAYMENT_LANE=true. It opens and verifies session capacity. On an overall pass, a buyer-supplied voucher must equal the Spool amount. The adapter presents it and checks the returned testnet receipt. Partial, fail, and uncertain hold. Cancel and expiry release the session. The adapter rejects session references, vouchers, or receipts that do not belong to the buyer authority. ## What the x402 entry means The registry describes a Labs candidate with agent support, cumulative vouchers, batch settlement, sub-cent accounting, stable-value assets, and protocol-contract custody. The policy can recommend it for agent work with at least 20 expected increments. There is no x402 execution adapter in lib/settlement. An x402 declaration can explain a match or mismatch, but Labs readiness still causes general production routing to refuse it. ## What to read next [How Spoolis routes a payment](/learn/how-spoolis-routes-a-payment) [When Spoolis decides and when you decide](/learn/when-spoolis-decides-and-when-you-decide) [Understanding settlement paths: Stripe, Tempo, and external settlement](/learn/understanding-settlement-paths-stripe-tempo-and-external-settlement) [Payment paths documentation](/docs/payment-paths) --- # Understanding settlement paths: Stripe, Tempo, and external settlement Canonical HTML: https://spoolis.com/learn/understanding-settlement-paths-stripe-tempo-and-external-settlement. This page is also available in machine-readable Markdown. A signed Outcome Receipt records verified work and earned value before Stripe Connect, a gated Tempo testnet adapter, or an external platform applies its own settlement lifecycle. In brief: - One signed receipt can feed several separate payment lifecycles. - Stripe Connect is production-capable when configured for human payments. - Tempo paths are gated or Labs testnet paths using testnet assets. - External settlement leaves payment execution and finality outside Spoolis. ## One receipt, different execution lifecycles Spoolis applies the agreed economic rule to the verification results and signs an Outcome Receipt that records what passed and what was earned. It does not always establish the underlying real-world truth itself. Settlement infrastructure executes an authorized payment action. Verify the receipt for authenticity with @spoolis/receipt-verifier. Its Ed25519 signature proves that the receipt is genuine and unaltered, not that every underlying check is reproducible or that payment was authorized, captured, or settled. ## Unitized outcomes come before settlement For unitized work, verification runs checks at their declared unit or batch scope. A determinate receipt records accepted and rejected counts, rejection reasons, and earned value calculated as accepted units multiplied by the unit price. The built-in settlement transition captures only an overall pass. Partial unitized results can produce a receipt with pro-rata earned value, but built-in adapters receive a hold rather than an automatic partial capture. ## Stripe Connect: authorize, then capture Availability: production-capable when Stripe is configured for a human payment path. Stripe creates a manual-capture PaymentIntent with a connected-account destination, application fee, Spool ID metadata, and an idempotency key. Overall pass requests capture. Partial, fail, and uncertain hold. Cancel and expiry cancel the PaymentIntent. ## Tempo keychain pilot: authorize, verify, transfer Availability: allowlisted, capped, and on Tempo Moderato testnet with testnet pathUSD. Selection requires SETTLEMENT_ADAPTER=tempo-keychain-pilot, an allowlisted API key, and an amount from $0.01 through $5.00. A gate failure falls back to simulation before commitment. A committed Tempo Spool remains pinned and fails closed if the adapter becomes unavailable. The adapter uses buyer-controlled delegated authority. On an overall pass, it verifies the signed receipt, requires receipt earnings to equal the Spool amount, and transfers that exact amount on testnet. Partial, fail, and uncertain hold. ## Tempo MPP sessions: open, present, release Availability: Labs, feature-flagged, testnet-only, and outside general adapter selection. The adapter opens and verifies a buyer-owned session. On an overall pass, it presents a matching buyer voucher and validates the returned testnet receipt. Partial, fail, and uncertain hold. Cancel and expiry release the session. ## External settlement: verify here, execute elsewhere Availability: a policy boundary, not a Spoolis settlement adapter. For an external actor, the policy recommends external_settlement with no candidate rail. Spoolis compiles, verifies, and issues the receipt while the customer platform owns payment behavior. Spoolis does not claim to observe final settlement unless a separate integration reports it. ## Compare the boundaries Stripe Connect uses licensed-provider custody, human payment methods, manual authorization, and deferred capture. The Tempo keychain pilot uses buyer-controlled delegated authority and an exact-earned testnet transfer after receipt verification. Tempo MPP sessions use protocol-contract custody, session capacity, vouchers, and testnet receipt validation. External settlement has no Spoolis execution adapter. The common input is the verified outcome. The signed receipt stays a verification artifact while each path keeps its own authorization, execution, and finality rules. ## What to read next [How Spoolis routes a payment](/learn/how-spoolis-routes-a-payment) [When Spoolis decides and when you decide](/learn/when-spoolis-decides-and-when-you-decide) [Working with machine payment protocols: MPP and x402](/learn/working-with-machine-payment-protocols-mpp-and-x402) [Payment paths documentation](/docs/payment-paths) --- # The Spoolis thesis Canonical HTML: https://spoolis.com/thesis. This page is also available in machine-readable Markdown. What we believe about verifying fulfillment in the agent economy, stated plainly, with the live evidence one level deeper. ## The thesis Payment rails move money. They cannot tell you whether the work was done. Verifying fulfillment is the missing layer of the agent economy. ## What we believe Agents are beginning to become economic actors. Payment rails move money, but that alone does not establish whether the purchased work satisfied the agreement. As agents buy more data, research, code, and completed outcomes, fulfillment becomes something that must be judged. A fulfillment layer needs explicit acceptance criteria, evidence, verification, and an earned-value result. That result should be portable and independent of whichever wallet, marketplace, or payment rail moves the money. If other systems consume verified outcomes, they can eventually inform payment, routing, reputation, pricing, and other economic systems. Spoolis is the bet that fulfillment verification becomes this missing layer. ## Evidence: the agent economy observatory The observatory tracks whether these beliefs hold: whether agents are transacting, what agents buy, the market gap in fulfillment verification, verification economics, a living read of the conditions, how large the layer could become, and what a portable verified outcome unlocks. Missing series stay explicitly marked as tracking. ## Sources and methodology Every data-bearing module carries its source and freshness. The source register and ingestion jobs share one configuration. --- # Privacy policy Canonical HTML: https://spoolis.com/privacy. This page is also available in machine-readable Markdown. Last updated August 10, 2026. This policy explains how Spoolis collects, uses, shares, and protects information. ## The short version We collect what the Service needs to work. A Spool is shared with the other party by design. We never sell personal information, show ads, or use customer content to train AI models. ## Information and sharing Spoolis processes account information, Spool content, creation inputs, API activity, feedback, and standard usage data. Anyone with a Spool share link can view its shared page. ## AI processing and security AI-assisted creation sends provided content to the AI provider to propose terms. Deterministic code parses amounts, and a person confirms terms. Data is encrypted in transit and at rest, access is deny-by-default, and Spool event history is append-only. No system is perfectly secure. ## Choices and contact Users may request access, correction, account closure, or deletion at support@spoolis.com. Shared completed transaction records may be retained where another party relies on them or law requires it. --- # Terms of service Canonical HTML: https://spoolis.com/terms. This page is also available in machine-readable Markdown. Last updated August 10, 2026. These terms govern access to and use of Spoolis. ## What Spoolis is Spoolis is a software layer for conditional transactions. It is not a bank, escrow agent, money transmitter, payment processor, marketplace, or provider of legal, financial, tax, or investment advice. Settlement is optional and runs on the configured settlement adapter. Demo transactions use the simulated adapter and do not move real money. ## Your responsibilities You are responsible for your transactions, counterparties, confirmed terms, content, account, agents, and API keys. AI-assisted drafts can be wrong or incomplete and require review. ## Fees, disclaimers, and liability The Service is currently free and sample prices are placeholders. The Service is provided as is and as available. The full HTML terms contain the governing warranty disclaimers, liability limits, indemnification, termination, and dispute provisions. ## Contact Questions about these terms can be sent to support@spoolis.com.