Fulfillment verification for agentic commerce

Why payment alone is not enough

Payment authorization answers whether a buyer may pay. Fulfillment verification evaluates 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, an autonomous buyer must pay before inspection, rely on a provider's assertion, or embed 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 reserved but not live, and AI-assisted checks are planned but not live.
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, machine-readable record of that verdict, including 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 does not prove the underlying claim is true or make every check reproducible. Evidence provenance records where evidence came from and how it was captured, not 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 does not hold funds. The payment authority and rail determine what actions are actually available and move money.

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.

Verification-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.