When Spoolis decides and when you decide

Spoolis decides what the checks found

The agreement defines the acceptance conditions and verification plan. Spoolis runs that plan against the submitted evidence and determines the condition results, overall result, and amount earned. When signing is configured, those facts become a signed Outcome Receipt.

For unitized work, deterministic code applies unit-scope checks to each unit and batch-scope checks to the full set. It calculates earned value as accepted units multiplied by the unit price. A determinate run can produce a pass, partial, or fail receipt with a units block. An uncertain unitized run does not issue a receipt.

Anyone with the artifact and trusted public key material can verify its authenticity and internal consistency with @spoolis/receipt-verifier. A valid Ed25519 signature proves the receipt is genuine and unaltered. It does not prove every underlying check is reproducible, establish real-world truth, or 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.

Repeated agent work can map to a metered session or batch channel. Higher-value asynchronous human work can map to manual authorization and capture. Work whose payment stays with another platform maps to external settlement. Unsupported combinations throw an error instead of receiving a guessed recommendation.

A recommendation is not a receipt, a route, or payment authority. It describes a candidate shape. The routing referee still needs compatible configured adapters, and the payment authority still controls spending.

You retain control of the payment boundary

• Agreement terms: the parties accept the work, conditions, price, and any unitization before verification.
• Configured adapters: a developer controls which adapters are available to the referee. Configuration can narrow the field, but it cannot make an incompatible or Labs adapter qualify.
• Buyer capabilities: an agent declares only the machine payment protocols its buyer-side client supports.
• Payment authority: the buyer, wallet, payment provider, or customer platform decides what may be spent and signs the payment action.
• External settlement: a customer can keep payment execution outside Spoolis and use the receipt as an input to its own policy.

Capability declarations do not create support

The general referee recognizes mpp and x402 declarations when matching agent requests to registered machine rails. A matching declaration means only that the buyer-side client claims compatibility with that protocol shape. It does not prove configuration, production readiness, or authorization to spend.

The input also contains a wallet declaration, but the general referee does not map it to a selectable rail. The repository's wallet implementation is an in-memory sandbox. The separately gated Tempo keychain pilot is selected through its adapter flag, API-key allowlist, and amount cap, not through the general capability matcher.

A receipt informs payment action but does not authorize it

A compatible adapter can translate an overall pass into its supported execution action. Stripe can request capture. The allowlisted Tempo keychain pilot can independently verify a passing receipt and build an exact-earned testnet transfer within the buyer's authorization scope. Demo mode can simulate the state change.

Fail and uncertain results hold. A partial unitized result settles automatically for the exact pro-rata earned amount through the built-in adapters. A customer-controlled external flow can inspect that receipt and apply its own authorization policy.

What to read next

Read how Spoolis routes a payment for selection mechanics, the MPP and x402 guide for protocol boundaries, and the settlement-path comparison for lifecycles. See verify a receipt for independent verification.