How Spoolis routes a payment

Verification produces the routing input

Spoolis first checks the delivered work against the agreed verification plan. When receipt signing is configured and the result is determinate, it issues a signed Outcome Receipt that records the agreement and plan versions, condition results, evidence digests, overall result, and amount earned.

For unitized work, the checks run at their declared unit or batch scope. The receipt can record accepted and rejected counts, rejection reasons, the per-unit earning rule, and pro-rata earned value. For example, 98 accepted units at $1 each produce $98 earned. An uncertain unitized run does not issue a receipt.

The receipt is the portable verification artifact. A third party can verify it with @spoolis/receipt-verifier and a pinned trust set, without treating it as payment authorization.

The referee returns a compatible path or a refusal

Payment routing is a separate deterministic step. The referee does not ask a model to select a rail or authorize money movement. It returns either a compatible path with reasons or an explicit refusal with reasons.

Before considering a path, it requires amount_cents to be a non-negative safe integer and the currency to be a three-letter uppercase code. Invalid money inputs are refused.

The referee weighs compatibility, authority, and readiness

• Actor type: the referee distinguishes a human from an agent. Human paths must support human payment methods. Agent paths must support agents and match a declared machine capability.
• Amount and currency: the referee validates both before routing. An adapter can impose narrower limits after selection.
• Configured adapters: only adapters supplied as available choices can qualify outside demo mode.
• Readiness: general routing requires a production-ready adapter. A matching Labs adapter is refused rather than presented as available.
• Demo mode: demo mode selects simulation, where no money moves. Simulation is not a fallback for a live request.
• Declared machine capabilities: the general agent referee matches mpp or x402 declarations to registered machine rails.

The referee does not switch actor types, custody models, or environments to manufacture a route. If no path qualifies, refusal is the result.

The receipt stays independent of the path

Choosing another compatible adapter does not rewrite what verification found. The Outcome Receipt remains a signed record of the outcome and amount earned, while the adapter defines authorization, hold, and execution behavior.

Current automatic settlement handling acts only on an overall pass. A partial unitized receipt can record pro-rata earned value, but the built-in settlement flow holds a partial result instead of automatically paying that amount.

Implemented paths still keep strict boundaries

Stripe Connect: when configured, the production adapter supports human payment methods through manual authorization and capture.

Tempo keychain pilot: the rail is marked production-ready in the registry, but adapter selection reaches it only through separate fail-closed gates: the exact adapter flag, an allowlisted API key, and the $5 hard cap. The adapter uses Tempo Moderato testnet and testnet pathUSD, so it is not production money.

MPP and x402: the Tempo MPP sessions rail and x402 batch rail remain Labs entries in general routing. The MPP testnet adapter exists 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

Read when Spoolis decides and when you decide for control boundaries, the MPP and x402 guide for protocol integration, and the settlement-path comparison for adapter lifecycles. For the compact technical reference, use payment paths.