Verify before an agent pays
Call verify-batch inside ACP, UCP or x402 flows, after the item is known and before money moves.
Who this is for
Buying agents, agent wallets and checkout services.
The problem
An agent about to pay for a dataset, model or report has no cheap way to confirm the seller's claims of origin or verification. One anonymous call before payment answers that, without revealing what the agent is about to buy.
How it works
- The seller puts the record digest in its product data, or the agent hashes what it received.
- After the checkout lists the items and before payment is authorized, the agent checks every digest in one call.
- The agent refuses sealed items, reviews corrected ones, and can record the mandate and the receipt by hash.
Routes it uses
POST /v1/verify-batch: signature, inclusion proof, errata count and judge for up to 1000 digests in one call.GET /v1/model/assess/{digest}: rely, check or do_not_rely for one record, with the reasons.POST /v1/records: append a signed record; the answer carries its digest and inclusion proof.
Set it up
Step 1. Collect the digests
Read record digests from the seller's product data, or hash the delivered bytes and look them up as assets.
Check: Every item in the cart has a digest or is marked unattested.
Step 2. Check before paying
In ACP, before completing the checkout session. In UCP, before authorizing payment. In x402, before signing the payment payload. One call covers the whole cart.
curl -s -X POST 'https://aisourceoftruth.com/v1/verify-batch' \
-H 'Content-Type: application/json' \
--data '{"digests":["{digest}"]}'
Check: A cart with a sealed test item stops before payment.
Step 3. Decide
present: false: treat the provenance claim as unsupported. sealed: true: do not buy. errata_count above zero: read the errata first. Use assess when you want the reasons in words.
curl -s -H 'Accept: application/json' 'https://aisourceoftruth.com/v1/model/assess/{digest}'
Check: Each outcome maps to a logged decision.
Step 4. Optionally witness the payment
A publisher can post a mandate record when the mandate is signed and a settlement record when it settles, both hashes only. See /guides/agent-payments for the exact fields.
BODY='{ ...record }'
SIG=$(printf %s "$BODY" | ./sign-ed25519) # base64url signature over these exact bytes
curl -s -X POST 'https://aisourceoftruth.com/v1/records' \
-H "Authorization: Bearer $AISOT_TOKEN" \
-H "X-AISOT-Key-Id: $AISOT_KEY_ID" \
-H "X-AISOT-Signature: $SIG" \
-H "Idempotency-Key: $(uuidgen)" \
-H 'Content-Type: application/vnd.aisot.record+json' \
--data-binary "$BODY"
Check: The settlement's log index is greater than its mandate's.
Wire it into your agent
Place the check in the payment tool, between cart confirmation and payment authorization. Fail closed on sealed; fail open with a warning on present: false only if your policy allows unattested goods.
MCP: add https://aisourceoftruth.com/mcp to the agent's MCP servers. Tools used: verify_batch, assess, publish_record. Read tools need no token.
With the PromptReports products, or alone
- CommitOps: If the purchase fulfills a promise to a customer, record the purchase record's digest against that promise in CommitOps.
- Alone: every step above uses only AI Source of Truth.
Expected outcomes
- No payment goes out for a sealed item.
- Every purchase log names the digests checked and the answer.
What it does not prove
- The check shows records and their state. It does not show that the goods are fit for purpose.
- Mandate and settlement records show order in the log. They are not a dispute ruling.
The OpenSpec plan for your agent
Your coding agent fetches the plan and writes it into your repo as openspec/changes/integrate-aisot-verify-before-pay/:
curl -H 'Accept: application/json' 'https://aisourceoftruth.com/use-cases/verify-before-pay/openspec?lang=python&with=commitops'
proposal.md: why, what changes in your product, impact.design.md: where the calls sit in your agent, with code for each call.tasks.md: checkable tasks, each step paired with a check against the live registry.specs/verify-before-pay/spec.md: the requirements and scenarios.
Read it here: OpenSpec plan. Back to all use cases or the documentation library.