Spoolis

Compile economic intent into verifiable acceptance criteria, verify fulfillment, and determine what was earned. Use Spoolis when payment depends on whether work actually passed.

A Spool records parties, terms, conditions, evidence, verification plans, and lifecycle events.

Machine-readable content
- Complete public-page dump: /llms-full.txt
- OpenAPI 3.1 document: /openapi.json
- Verify a Spoolis Outcome Receipt with schema spoolis/outcome-receipt@1: @spoolis/receipt-verifier, /schema/outcome-receipt-v1.schema.json, /.well-known/spoolis-keys.json
- Agent skill and two-call flow: /skill.md
- Every public marketing and content page has a Markdown twin at <path>.md.
- Homepage Markdown: /index.md
- Examples: /agents.md, /pricing.md, /privacy.md

Human entry points
- Interactive compiler demos: /demos
- Simulated card-rail cap and capture demo: /demos/card-rail
- Technical documentation: /docs
- Zero-login quickstart: /docs/quickstart
- Coding-agent unitized sandbox prompt: /docs/coding-agent-quickstart
- v1 REST API reference: /docs/api
- MCP stdio server: /docs/mcp
- Outcome receipt verification: /docs/verify-receipt
- Lower-level attestation verification: /docs/verification
- Payment path selection and configured adapters: /docs/payment-paths
- Production API keys use the spk_live_ prefix and are managed at /dashboard/api-keys
- Anyone can open and review a shared Spool. Accepting in production requires sign-in.
- Spoolis determines earned value but does not hold funds. The payment authority and configured rail or adapter move money according to their own authorization and execution semantics.
- Create a Spool: /new
- Read a shared Spool: /s/{id}
- Learn: /learn
- A verified outcome in the loop: /learn/a-verified-outcome-in-the-loop
- Authorize the cap. Capture what was earned.: /learn/authorize-the-cap-capture-what-was-earned
- Agent economy observatory: /thesis
- 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
- Every payment system needs someone to decide what counted: /learn/who-decides-what-counted
- The agent economy: infrastructure, metrics, and market tracking: /learn/agent-economy-report
- The fulfillment layer between authorization and settlement: /learn/the-fulfillment-layer-between-authorization-and-settlement
- Payments know when money moved, not whether it was earned: /learn/payments-know-when-money-moved-not-whether-earned
- 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.
- 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
- Agent product: /agents
- People: /people
- Businesses: /business
- Contact: /contact
- Also from us: /also-from-us
- Developer and API surface: /docs/api
- Pricing: /pricing
- Pricing for agents: /agents#pricing
- Pricing for people: /people#pricing
- Pricing for businesses: /business#pricing
- Platforms and teams: /platforms
- Privacy policy: /privacy
- Terms of service: /terms

REST entry points
- Check optional online Outcome Receipt status (no account required, offline signature verification is sufficient without it): GET /api/receipts/{id}/status
- Verify the lower-level signed attestation: POST /api/v1/attestations/verify
- Create: POST /api/v1/spools
- Read: GET /api/v1/spools/{id}
- Read events: GET /api/v1/spools/{id}/events
- Act: POST /api/v1/spools/{id}/{action}
- Create a counterparty invitation with the initiator's full-scope key: POST /api/v1/spools/{id}/invite
- Exchange the returned one-time grant without a signed-in session: POST /api/v1/keys/exchange
- A counterparty key can read only its bound Spool and can accept, decline, or submit evidence while its outcome is active. It cannot create, commit, fund, verify, or list events.

MCP entry point
- The repository includes an MCP stdio server with tools for Spool creation, counterparty invitation, retrieval, acceptance, evidence submission, verification, and event reading.

MCP tools
- compile_spool: Compile transaction intent and create a demo or production Spool.
- create_spool: Create a Spool.
- get_spool: Get the canonical Spool, including raw status dimensions and allowed actions.
- create_counterparty_invite: Create a 15-minute, single-use counterparty grant for an active Spool. Requires the initiator's full-scope key.
- propose_spool: Propose a draft Spool.
- accept_spool: Accept a proposed Spool.
- abandon_spool: Abandon an active Spool before settlement is committed.
- decline_spool: Decline a proposed Spool.
- cancel_spool: Cancel a Spool.
- commit_payment: Ask the configured settlement adapter to authorize and, where supported, hold for a Spool.
- submit_evidence: Submit evidence for a Spool condition.
- verify_spool: Run verification; authenticated v1 returns the Outcome Receipt with its lower-level attestation when signing is configured, while sandbox returns a demo attestation and, for unitized verification, a signed demo Outcome Receipt with units and proportional earned value.
- complete_spool: Read a Spool whose outcome is already completed. This tool does not run verification or settlement.
- get_spool_events: Get the canonical event history for a Spool.

Authentication and payment requirements depend on the configured environment and endpoint. Do not assume a sample transaction represents a real payment.