Verification-gated settlement

The verdict controls the next payment action

The verification layer does not move money. It produces a signed result and an approved amount. A buyer runtime or payment system checks that result and performs the action allowed by its own authority and rail.

On a pass, that action may capture an authorization, increase a cumulative voucher, or add an accepted unit to a later batch. On a fail, the authorization can remain uncaptured, the voucher can stay at its prior amount, or the unit can be excluded. An uncertain verdict should not silently become a pass.

Each settlement policy names a different payment shape

• direct_atomic_payment: payment and deterministic fulfillment happen together. No separate verification gate is needed.
• manual_authorization_capture: a licensed payment provider authorizes an amount first, then a passing verdict allows capture later.
• metered_session: a bounded session accumulates value as verified units pass, usually through cumulative vouchers.
• batch_channel: many verified interactions accumulate before one later claim or settlement.
• pay_then_verify: payment intentionally happens first. Verification supports records, quality control, or a later remedy rather than blocking payment.
• external_settlement: another platform owns payment execution, while Spoolis supplies the verification result it may use.

Release can happen by capture, voucher, or batch

Manual authorization and capture

The buyer authorizes a bounded amount through a payment provider. After fulfillment passes, the provider captures the approved amount. This fits asynchronous work with one or a few release points, subject to the provider's authorization windows and account requirements.

Cumulative vouchers

The buyer signs a voucher for the total earned so far. Each passing unit raises the cumulative amount; a failed unit leaves it unchanged. The provider later settles the latest valid voucher. This can reduce the number of final settlement operations for incremental work.

Batch settlement

Multiple verified interactions are accumulated and claimed together. This can lower per-interaction overhead, but it introduces batching rules, provider exposure, replay handling, and recovery requirements that must be tested.

General settlement is simulated today

The repository models these policies and rail capabilities. Manual capture and x402 batch paths are architectural candidates, not published production integrations. Payment path documentation records the implemented adapters and their availability boundaries. No page here should be read as a claim that Spoolis holds customer funds or can move money with its verdict-signing key.