Spoolis Spoolis builds financial guarantees for consequential AI work. Like Coalition in cyber, Spoolis pairs software that prevents mistakes with a guarantee that covers them, so AI vendors can stand behind the work their agents do. Spoolis is in development and working with design partners. Contact: support@spoolis.com. Home: https://spoolis.com/ Guides (public primary sources, not legal or tax advice) - Guides: /guides - Who pays when an AI agent makes a mistake: /guides/who-pays-when-an-ai-agent-makes-a-mistake - Warranty vs guarantee vs insurance: /guides/warranty-vs-guarantee-vs-insurance - AI exclusions in liability insurance: /guides/ai-exclusions-in-liability-insurance - Sales tax penalties by state: /guides/state-sales-tax-late-filing-penalties - Glossary: /glossary Separate from the guarantee work, Spoolis runs a live developer API for verifying delivered work, the Outcome Receipt API. Spoolis issues a signed, durable, portable Outcome Receipt: a verdict artifact, per unit for unitized work, that billing, audit, a counterparty's own systems, or another third party can fetch and independently verify. It makes the receipt by verifying delivered work against explicit acceptance criteria. You define what counts, provide the evidence, and choose the judge you trust. A Spool is the versioned acceptance policy around those inputs. The Outcome records what counted, what failed, what was uncertain, and what was earned. Billing, payment, workflows, finance, or another agent can act on that result. Use Spoolis when a workflow needs a reliable acceptance result before something consequential happens next. Do not use it when delivery alone is enough. The longer-term use case is software hiring software for consequential work, especially where intermediate results become inputs to later automated actions. Use Spoolis when delivered work must be checked against explicit acceptance criteria before another system pays, continues, retries, or acts on it. Related concepts this replaces or assembles: signed attestations of delivered work, signed receipts, acceptance criteria agreed before delivery, escrow-style hold-until-verified flows, and audit trails of what was accepted and earned. Products - Outcome Receipts: Give every downstream system one signed result it can verify offline. /docs/outcome-receipt - Acceptance Reviews: Keep partial work and uncertain results from becoming an all-or-nothing argument. /docs/acceptance-lifecycle - Earned Value: Turn accepted units into an exact amount without asking a model to do the math. /docs/pay-only-what-was-earned - Reviews and Disputes: Put a named human in the acceptance loop and record every objection with its evidence. /docs/reviews-and-disputes - Commercial state: Explain the current accepted commercial state and every unresolved difference. /docs/discrepancies - Correction History: Correct a result without erasing the record people already relied on. /docs/outcome-receipt - Reconciliation Statements: Give finance a stable acceptance record and booking export for every receipt. /docs/invoice-audit - Promise Replay: Replay a vendor promise against historical results before adopting it. /docs/promise-replay - Bring Your Own Judge: Keep the evaluator your workflow already trusts. /docs/guides/bring-your-own-judge - Agent Payments: Put a verified result between an agent purchase and the next spend. /docs/payment-paths - Sandbox: Test an acceptance flow before connecting production credentials or payment paths. /docs/quickstart - Outcome Definition Registry: Compare published outcome rules without hunting through vendor documentation. /outcomes/definitions - Outcome Price Benchmarks: Compare labeled outcome prices beside the rule and authority behind each one. /outcomes/prices - Evidence Fabric: Connect claims to observed facts while preserving where every fact came from. /docs/sources A Spool records parties, terms, conditions, evidence, verification plans, and lifecycle events. Supports: - Customer-defined criteria - External judges / BYOJ - Accepted / rejected / uncertain per unit - Earned value - Corrections / supersession - Signed Outcomes - Offline receipt verification - Downstream consumption - Free sandbox - Self-serve production usage - x402 pay-per-call Capabilities and boundaries Per-unit verdicts are pass, fail, uncertain. Partial acceptance is supported. Uncertain units earn nothing and hold the downstream action until evidence or judgment resolves them. Only accepted units earn value. Per-unit earned value is accepted units multiplied by the agreed unit amount. Deterministic checker IDs: `rows.count`, `schema.validate`, `nulls.absent`, `dedupe.check`, `url.format`, `url.reachable`, `json.path.equals`, `http.status`, `text.contains`, `file.present`, `hash.matches`, `metadata.read`, `dimensions.match`, `duration.matches`, `serial.match`, `deadline.met`. External judge kinds: `external_service`, `zk_verifier`, `marketplace_evaluator`, `buyer_owned`, `ai_evaluator`, `human_arbitration`. External results can be binary, scored with declared quality and consensus thresholds, or per-unit. Proof requirements: `signed`, `hashed_ref`, `declared`. Missing or invalid required proof does not become acceptance. The declared policy returns uncertain or fail. Outcome Receipts use Ed25519, schema `spoolis/outcome-receipt@1`, and content-addressed IDs. Verify offline with `@spoolis/receipt-verifier` for JavaScript or `spoolis-receipt-verifier` for Python. Check corrections at `/api/v1/receipts/{receipt_id}/status` and record use at `/api/v1/receipts/{receipt_id}/consumptions`. Human reviews are requested at `/api/v1/receipts/{receipt_id}/reviews` and decided through the API or one hosted link. Disputes open at `/api/v1/receipts/{receipt_id}/disputes`; their frozen value and resolution remain machine-readable. Use `/api/v1/verify` with an API key bearer token, or `/api/v1/verify/x402` for keyless pay-per-call verification. A no-account sandbox is available at `/api/sandbox/session`. MCP is available hosted at https://spoolis.com/api/mcp and through `@spoolis/mcp`. OpenAPI: https://spoolis.com/openapi.json. Limits: 50 conditions, 100000 units, 8192 serialized evidence-metadata characters, and 5000000 serialized one-call evidence characters. A corrected receipt supersedes an earlier receipt without changing it. Spoolis is not a wallet or escrow service. The acceptance core is rail-neutral: the signed Outcome never depends on how or whether money moves. Some supported settlement adapters can act on an Outcome using delegated, expiring authority. Spoolis does not hold root or threshold keys, does not commingle gross funds, and does not make the payment rail part of the acceptance result. Neutrality: billing-neutral, Emits results billing systems consume. Creates no invoices or plans. Rail-neutral, The signed Outcome never depends on how or whether money moves. Some supported settlement adapters can act on an Outcome using delegated, expiring authority. Orchestration-neutral, Returns continue, retry, and hold sets. Never executes workflows. Bring your own judge is supported. Outcomes are signed. Downstream consumption endpoints: `/api/v1/receipts/{receipt_id}`, `/api/v1/receipts/{receipt_id}/status`, `/api/v1/receipts/{receipt_id}/consumptions`. After a result: accepted, The consumer may act under its own authorization and policy. Rejected, Do not act on rejected units. Correct the work or evidence before verifying again. Uncertain, Hold the action. Supply missing evidence or resolve the unavailable judgment before verifying again. Start with one-call acceptance - Keyless production door: POST /api/v1/verify/x402. Each call is quoted before execution from a $0.010 base component plus the units processed. The base component is not the full price of a call. An unpaid POST is free and returns the exact quote. No account or API key is required for the x402 path. - Unified front door: POST /api/v1/verify. A sandbox bearer token selects isolated demo behavior; a production API key selects production behavior. The /api/sandbox/* tree remains a compatibility alias. - Production front door: POST /api/v1/verify with a full-scope or verify-scoped key. - MCP front door: verify_result, one-call acceptance using criteria plus evidence plus your chosen judge or checks. - Response fields: spool_id, earned_cents, accepted, rejected, uncertain, rejections with unit and reason, unit_results with per-unit verdicts (pass, fail, or uncertain; uncertain units earn nothing and are not failures), receipt, receipt_url, verification_run_id, terminal, settlement_eligible, can_resubmit_evidence, can_rerun, next_step, decision_authority. - The endpoint creates an inspectable unilateral Spool. The external provider is identified but does not accept conditions in Spoolis. The signed receipt records this boundary in agreement.acceptance. - When both parties need to accept inside Spoolis, use the bilateral lifecycle after the one-call path. Common agent jobs - Did this delivered work meet the agreement? - Verify this agent's work before payment. - Check this work before spending more on it. - Which units counted, and what failed? - What was earned for the accepted units? - Verify partial completion of a delivery. - Produce a signed result another system can rely on. - Verify this Outcome Receipt someone handed me. Try it with curl Create a short-lived sandbox session, then verify minimal evidence against one explicit condition. ```bash BASE_URL="https://spoolis.com" TOKEN=$(curl -sS -X POST "$BASE_URL/api/sandbox/session" | sed -n 's/.*"token":"\([^"]*\)".*/\1/p') curl -sS -X POST "$BASE_URL/api/sandbox/verify" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "conditions": [ { "description": "Every row includes status", "deterministic_check": { "checker": "completeness", "required_fields": ["status"] } } ], "evidence": { "type": "dataset", "rows": [ { "id": 1, "status": "complete" } ], "provenance": "api_response" } }' ``` Send feedback from a machine caller: `curl -X POST https://spoolis.com/api/feedback -H "Content-Type: application/json" -d '{"message":"...","source":"my-agent"}'` Machine-readable content - Spoolis Platform overview: /platform and /platform.md. It is the developer platform for outcome-based software. - Outcome Index: /outcome-index and /outcome-index.md, JSON at /api/outcome-index for agents. The canonical Spoolis dataset for public Outcome definitions, prices, authority, finality, correction rules, guarantees, and remedies. - The Outcome lifecycle defines what counts, accepts evidence, applies a chosen judge, produces a durable signed Outcome, handles finality and corrections, and sends the result to billing, finance, workflows, payments, or other agents. Use the outcome API or MCP server to run outcome verification. - 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 (thin alias: @spoolis/outcome, verifyOutcome), /schema/outcome-receipt-v1.schema.json, /.well-known/spoolis-keys.json (Python: spoolis-receipt-verifier on PyPI, same trust-set contract) - Agent skill led by one-call acceptance, then the bilateral lifecycle: /skill.md - One-call recipe: criteria plus evidence -> unilateral Spool -> verify -> Outcome Receipt -> verifyReceipt -> optional status check -> consumer acts on earned. - Every public marketing and content page has a Markdown twin at .md. - Agreements may declare hash-covered evidence requirements. Receipts distinguish present, missing, stale, unavailable, and provenance_unsatisfied evidence; unsatisfied required evidence defaults a criterion to uncertain. - Unitized receipts can expose salted per-unit identities without exposing the private per-Spool salt. - requireOutcome() consumer policy checks ship in @spoolis/receipt-verifier 0.1.3+, and --require in @spoolis/cli 0.1.5+. - Runnable examples (LangGraph, smolagents, x402 buyer, twin receipt verifiers, verify-before-action skill and Cursor rule): https://github.com/jsfranklin221/spoolis-examples - dispute_policy is hash-covered. A party named in who_may_dispute can supersede an issued receipt through POST /api/v1/receipts/{receipt_id}/supersede. There is no review queue or UI. - Homepage Markdown: /index.md - Examples: /index.md, /pricing.md, /privacy.md Billing and included usage - Primary model: free sandbox, then usage-based production acceptance. - Each account includes 10 verification runs and 10 free-text compiles per calendar month. - Included usage is consumed first. Paid compile and verification work uses the prepaid usage balance after the allowance is exhausted. - Every paid compile or verification is quoted before it runs. Transaction fees are separate. Developer resources - API reference: /docs/api - Promise replay guide: /docs/promise-replay - Policy compiler guide: /docs/policy-compiler - Invoice audit guide: /docs/invoice-audit - OpenAPI document: /openapi.json - MCP server manifest: /.well-known/mcp.json - ARD discovery manifest: /.well-known/ard.json (legacy alias /.well-known/ai-catalog.json) - Hosted MCP Streamable HTTP endpoint: /api/mcp - Authentication: /docs/authentication - Webhooks and status polling: /docs/webhooks - API versioning: /docs/versioning - MCP server: /docs/mcp - Connect an AI assistant (Claude, ChatGPT, MCP clients): /docs/connect - About Spoolis: /about - Quickstart: /docs/quickstart - Agent skill: /skill.md Human entry points - Integration directory and demand requests: /integrations - Free Outcome invoice audit: /tools/invoice-audit - Keyed Outcome invoice audit for CSV or base64 PDF input: /api/v1/invoice-audit - Keyed promise replay for deterministic historical analysis with hypothetical remedies: /api/v1/promise-replay - 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 - x402 seller recipe: /docs/x402-seller-recipe - Outcome-priced software guide: /docs/guides/outcome-priced-software - Accept work between two parties: /docs/guides/two-party-lifecycle - Continue only with accepted work: /docs/continue-with-accepted-work - Accept purchased work: /docs/accept-purchased-work - Pay only what was earned: /docs/pay-only-what-was-earned - Outcome Receipt overview: /docs/outcome-receipt - Wallet authority: /docs/wallet-authority - Interactive walk demo: /demos/walk - 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 what was earned. 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 - Economics calculator: /economics - Agentic commerce 101: /learn/agentic-commerce - Introducing Spoolis: /learn/introducing-spoolis - The new payment rails weren't built for old commerce: /learn/agent-payments-arent-just-new-rails - When payments become final, what happens to buyer protection?: /learn/when-payments-become-final - The payment was verifiable. The work wasn't.: /learn/the-payment-was-verifiable - The agent said done. The next system still shouldn’t trust it yet.: /learn/the-agent-said-done - Bring your own judge: /docs/guides/bring-your-own-judge - Judge adapter mapping: /docs/judge-adapter-mapping - Workflow and billing consumers: /docs/workflow-billing-consumers - Acceptance lifecycle: /docs/acceptance-lifecycle - Glossary: /docs/glossary - Who grades the outcome?: /learn/who-grades-the-outcome - What vendors mean by an outcome: /learn/what-vendors-mean-by-an-outcome - How AI support vendors count a resolution: /learn/how-ai-support-vendors-count-a-resolution - Check your AI agent bill against your own tickets: /learn/check-your-ai-agent-bill - A person in the acceptance loop: how reviews and disputes work: /learn/a-person-in-the-acceptance-loop - Reviews and disputes: /docs/reviews-and-disputes - Evidence sources: /docs/sources - Outcome matching: /docs/matching - Verify delegated agent work in smolagents and multi-agent systems: /docs/guides/hugging-face-smolagents - See where acceptance logic lives when one agent says done to another: /learn/when-one-agent-says-done-to-another-agent - The agent said “done.” The system disagreed.: /learn/the-workflow-doesnt-continue - Two services. No accounts. One signed Outcome.: /learn/two-services-no-accounts-one-signed-outcome - The settlement points at the proof: /learn/the-settlement-points-at-the-proof - What happens when an agent checks the work before spending more: /learn/checks-the-work-before-spending-more - Anatomy of a verified transaction: /learn/anatomy-of-a-verified-transaction - My agent paid for work and got garbage back. Now what?: /learn/my-agent-paid-and-got-garbage - A portable Outcome for an ERC-8183 job: /learn/a-portable-outcome-for-an-erc-8183-job - How to stop an agent mistake before it becomes irreversible: /learn/gating-consequential-agent-actions - When does verification actually pay for itself?: /learn/when-verification-pays-for-itself - What comes after usage-based software?: /learn/what-comes-after-usage-based-software - What is an Outcome Receipt?: /learn/what-is-an-outcome-receipt - What required evidence changes: /learn/what-required-evidence-changes - A verified outcome in the loop: /learn/a-verified-outcome-in-the-loop - Required Outcome checks in CI: /learn/required-outcome-checks-in-ci - Unit identity that travels: /learn/unit-identity-that-travels - Authorization is not earned value: /learn/authorization-is-not-earned-value - 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, retry, continuation, deployment, recording, or another agent depends on what actually counted. - Do not use Spoolis merely because a payment exists. - LLM as judge vs acceptance infrastructure: /learn/llm-as-judge-vs-verification - What is acceptance infrastructure?: /learn/what-is-acceptance-infrastructure - Why the first checker is easy: /learn/why-the-first-checker-is-easy - What one agent built in three weeks: /learn/what-one-agent-built-in-three-weeks - What happens when one AI agent has to judge another?: /learn/when-one-agent-judges-another - Routing disposition vs acceptance state: two questions hiding inside "what was the outcome?": /learn/routing-disposition-vs-acceptance-state - What is a Spool?: /learn/what-is-a-spool - Acceptance-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: / - Spoolis Platform: /platform - Outcome Index: /outcome-index - Outcome Pricing: /products/outcome-pricing - Outcome Guarantees: /products/outcome-guarantees - Outcome Acceptance: /products/outcome-acceptance - Outcome Spend: /products/outcome-spend - Sellers: /sellers - Buyers: /buyers - Developers: /developers - Contact: /contact - Also from us: /also-from-us - Developer and API surface: /docs/api - Pricing: /pricing - Pricing for agents: /pricing - Platform overview: /how-it-works - Privacy policy: /privacy - Terms of service: /terms REST entry points - Verify criteria and evidence in one unilateral call: POST /api/v1/verify - Try the same POST /api/v1/verify route in the zero-login sandbox with a sandbox bearer token - Check optional online Outcome Receipt status (no account required, offline signature verification proves authenticity without Spoolis uptime): GET /api/v1/receipts/{receipt_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 points - Connect over hosted Streamable HTTP at /api/mcp. Send a production API key in the Authorization header, or omit it for the sandbox. Discover the server at /.well-known/mcp.json. - Run the published npm package with npx @spoolis/mcp. Registry-aware clients can discover the server on the official MCP Registry as com.spoolis/mcp. - Start with verify_result for one-call acceptance using criteria plus evidence plus your chosen judge or checks. The 14 lifecycle tools follow for Spool creation, counterparty invitation, retrieval, acceptance, evidence submission, verification, and event reading. MCP tools - verify_result: Get a signed, durable, portable Outcome Receipt: a verdict artifact, per unit for unitized work, another system can fetch and independently verify. Spoolis makes it by verifying returned work against explicit acceptance criteria. Use when an agent, vendor, or tool reports work as done and the next action depends on whether the delivery actually met the agreed criteria. This runs in one call using exactly one of inline conditions or a locally registered recipe slug and hash, creating an inspectable unilateral Spool, the versioned acceptance policy. The maximum amount field is optional for verification-only runs. Omit it when nobody is paying; the earned amount is then zero and the receipt omits committed value. The maximum amount field is required when unit is present because unit math needs the cap. Recipe verification uses the hosted conditions exactly as written and fails closed when the hash differs. The external provider does not accept conditions in Spoolis. For a batch delivery where items can pass, fail, or remain uncertain individually, pass unit (its unit count matching the item count) AND evidence type dataset with exactly one row per delivered item, keeping a field present with a null value when it is missing; that returns distinct per-unit verdicts and earned value only for passing units. Text evidence with unit is batch-only and settles all-or-nothing. For a keyless production alternative, use POST /api/v1/verify/x402. Sandbox dataset evidence is limited to 100 records. Works in the no-key sandbox. - run_sandbox_scenario: Evaluate Spoolis without a key or account: run a seeded synthetic scenario through a real demo Spool (the agreement object), verification, and a signed demo Outcome Receipt. Use to observe which units may continue after verification and inspect seeded truth only after the Outcome exists. Scenarios: data_enrichment, external_judge_two_consumers, qualified_meetings, production_migration, review_and_dispute, and sources_and_matching. This persists only run parameters and aggregate results; modeled economics are labeled modeled. commercial_state opens and resolves a blocking discrepancy, proving the Outcome moves from uncertain back to accepted. Works in the no-key sandbox. - compile_spool: Turn purchase intent into a proposed DRAFT Spool (the agreement object) with explicit acceptance criteria and earned-value rules. Use before both parties confirm terms; do not use for one-call unilateral result verification. This creates a persisted draft to inspect, then accept_spool confirms it, amend_spool changes conditions or unitization, and abandon_spool discards it. Works in the no-key sandbox. - create_spool: Create a production Spool (the agreement object) from structured terms and acceptance criteria. Use when both parties will participate in the agreement lifecycle; do not use for one-call unilateral verification. This persists a proposed agreement and may send the counterparty invite reported in the response handoff block. The type field defaults to the person or business service path, while agent selects the agent settlement rail. Conditions may declare verification_method third_party with an external_judge so verification consumes your own evaluator's bound result instead of Spoolis judging those conditions. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - get_spool: Read a Spool (the agreement object), including hash-covered evidence requirements, dispute policy, and salted unit identity configuration. Use for status checks; it has no side effects. A party named in who_may_dispute can supersede an issued receipt through POST /api/v1/receipts/{receipt_id}/supersede. There is no review queue or UI. Works in the no-key sandbox. - get_receipt_status: Check whether an Outcome Receipt is still current or has been superseded, before acting on it. Returns state (current, superseded, unknown) and status (active, corrected, revoked). Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - request_review: Route receipt units from a Spool (the agreement object) or its whole outcome to a named reviewer. Use when a human decision is required; this creates a review request and hosted link but does not decide it. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - get_review: Read the review request for a Spool (the agreement object). Use to poll its state; it has no side effects. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - decide_review: Decide a pending review for a Spool (the agreement object). Use after inspecting its evidence; this records confirmation or creates a dispute and does not settle payment. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - open_dispute: Open a dispute for a Spool (the agreement object). Use inside its declared window; this records counter-evidence and marks policy-defined value as not currently final or payable. It does not restrict money. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - get_dispute: Read a dispute for a Spool (the agreement object). Use to inspect claimed, accepted, disputed, final, and payable figures plus resolution state; it has no side effects. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - list_discrepancies: Read discrepancies for a Spool (the agreement object). Use for inspecting differences; it has no side effects. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - open_discrepancy: Open a discrepancy for a Spool (the agreement object). Use when expected and observed figures do not reconcile; this records the difference and does not assume either source is wrong. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - resolve_discrepancy: Resolve a discrepancy for a Spool (the agreement object). Use after authority determines the outcome; this records the resolution and does not initiate settlement. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - list_sources: Read source connections for a Spool (the agreement object). Use for source health inspection; it has no side effects. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - add_source: Add a source connection for a Spool (the agreement object). Use before ingestion; this creates a connection and does not ingest evidence. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - sync_source: Sync a source for a Spool (the agreement object). Use after configuration; this creates an idempotent checkpointed job. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - list_facts: Read typed facts for a Spool (the agreement object). Use to inspect observed evidence; it has no side effects. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - run_matching: Run matching for a Spool (the agreement object). Use after claims and facts exist; this records explainable results and discrepancies. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - list_matches: Read matches for a Spool (the agreement object). Use to inspect outcomes and explanations; it has no side effects. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - create_counterparty_invite: Create a 15-minute, single-use grant that lets the other party join a Spool (the agreement object). Use when a counterparty needs scoped access without signing in; do not use as payment authority. This creates a credential that expires after use or 15 minutes. Requires the initiator's full-scope key. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - propose_spool: Move a draft Spool (the agreement object) into the proposed state so the counterparty can review it. Use after the acceptance criteria are ready; this changes agreement state and does not accept terms or settle payment. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - accept_spool: Confirm the compiled contract by accepting a proposed Spool (the agreement object). Use only after reviewing its terms and acceptance criteria; this records agreement acceptance but does not verify fulfillment or settle payment. Production agent agreements require the current quote digest. Works in the no-key sandbox. - amend_spool: Change acceptance criteria or unit-based earned-value rules on a proposed Spool (the agreement object). Use before acceptance when the draft does not match the intended purchase; this replaces proposal details and does not accept or verify the work. Works in the no-key sandbox. - abandon_spool: Abandon an active Spool (the agreement object) before payment is committed. Use when the initiator no longer wants to proceed; this ends the agreement and cannot verify work or settle value. Works in the no-key sandbox. - decline_spool: Decline a proposed Spool (the agreement object). Use when the counterparty rejects its terms; this ends the proposal without accepting it, verifying work, or settling payment. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - cancel_spool: Cancel a Spool (the agreement object) that should not continue. Use only when cancellation is an allowed action; this changes lifecycle state and does not verify fulfillment or settle payment. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - commit_payment: Ask the configured settlement adapter to authorize and, where supported, hold the maximum value for a Spool (the agreement object). Use after terms are accepted when the selected payment path requires commitment; this may create a payment authorization or hold, but does not verify work or determine earned value. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - submit_evidence: Attach fulfillment evidence to an acceptance criterion in a Spool (the agreement object). Use after work is delivered and before verification; this persists evidence but does not decide whether it passes or what was earned. Works in the no-key sandbox. - verify_spool: Issue a signed, durable, portable Outcome Receipt from this Spool, the versioned acceptance policy. The receipt is a verdict artifact, per unit for unitized work, another system can fetch and independently verify. Spoolis makes it by evaluating submitted evidence against the acceptance criteria and determining what was earned. Use after evidence is attached; this records the verdict and required evidence as present, missing, stale, unavailable, or provenance unsatisfied. Missing required evidence defaults to uncertain. Conditions with verification_method third_party keep your own judge: verification consumes the declared external evaluator's result, bound to this agreement and evidence per its declared proof requirement, instead of Spoolis judging those conditions itself. Unitized receipts may include salted public unit identities. Sandbox dataset evidence is limited to 100 records. Canonical recipe: compile -> verify -> Outcome Receipt -> verifyReceipt -> optional status check -> consumer acts on earned. Works in the no-key sandbox. - complete_spool: Read a Spool (the agreement object) whose outcome is already completed. Use for compatibility when a completed result is expected; it has no side effects and does not run verification or settlement. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox. - get_spool_events: Read the canonical audit history for a Spool (the agreement object), including agreement, fulfillment, verification, and settlement events. Use to reconstruct what happened; it has no side effects. Works in the no-key sandbox. Authentication and payment requirements depend on the configured environment and endpoint. Do not assume a sample transaction represents a real payment.