Fulfillment verification for agentic commerce

Why payment alone is not enough

Payment authorization answers whether you may pay. Fulfillment verification answers whether the seller earned the payment.

An agent can hold a wallet, follow a spending policy, and send a payment without knowing whether a purchased dataset is complete, a report cites its claims, or a generated file matches the requested format. Identity, authority, payment protocols, and settlement rails solve important parts of the transaction. They do not, by themselves, define the promised outcome or test what arrived.

Without that layer, your agent has to pay before inspection, rely on the provider's word, or carry one-off checking logic for every purchase. Each choice becomes fragile when "done" has several conditions or the evidence is ambiguous.

Verification follows a three-step loop

1. Compile the intent. Turn the requested work into explicit terms, acceptance conditions, evidence requirements, and a verification plan. Preserve what the parties stated separately from safeguards the system proposes.
2. Evaluate the delivery. Run the planned checks against the returned work and its evidence. Deterministic checks and human confirmation are live. External-tool checks are live when the agreement declares its judge, and AI-assisted checks are live for claim_cited only.
3. Issue a signed verdict. Record which conditions passed, failed, or remained uncertain, with evidence references and the amount approved by the result.

The loop makes acceptance inspectable before money moves. It also lets the same criteria govern a human review, an API response, and an agent action.

A signed verdict records the result, not absolute truth

A verdict is the result of executing the agreed verification plan. It states the overall outcome and the result of each condition.

A verification attestation is a signed record software can read. It includes the agreement and plan versions, evidence references or digests, condition results, and approved amount. The signature proves the signed artifact is genuine and unaltered. It doesn't prove the underlying claim is true or make every check reproducible. Evidence provenance, the record of where evidence came from and how it was captured, isn't a trust score.

Settlement rails act after verification

Fulfillment verification is rail-agnostic. It produces the result that a buyer-side payment flow can require, while the chosen rail handles authorization, movement, and settlement.

A passing attestation might support manual capture, increase a cumulative voucher, authorize a batch claim, or tell an external system that the agreed economic rule was satisfied. A failing or uncertain result can prevent a payment action, leave a voucher unchanged, or route the transaction to review. Spoolis determines what was earned. The payment authority and configured rail or adapter move money according to their own authorization and execution semantics.

One Spool keeps the agreement and plan together

Spoolis represents the agreement as a Spool: parties, terms, conditions, evidence requirements, a verification plan, and lifecycle events in one canonical object. This gives the compiler, verifiers, people, agents, and payment integrations the same transaction state.

Acceptance-gated settlement explains the release policies. A live Tempo testnet run released the exact earned amount in about 832 ms at a recurring settlement cost of about $0.009, excluding the one-time Safe deployment. This is testnet evidence, not a production readiness claim. See payment paths for adapter boundaries and Spoolis for agent transactions for integration surfaces.