Verified marketplace goods

A verification record per item, scored under a judge pinned by hash. Buyers check without trusting the seller.

Who this is for

Marketplaces for datasets, reports, prompts and models.

The problem

Buyers have to trust the seller's own quality claims. A verification record states which claims were checked, under which judge, and the outcome, and it outlives the store.

How it works

• The marketplace verifies each item's claims against their sources with a judge model and prompt pinned by hash.
• It publishes a verification record per item, labeled VERIFIED.
• If the judge turns out to have a blind spot, its hash names every affected record for re-verification.

Routes it uses

• POST /v1/records: append a signed record; the answer carries its digest and inclusion proof.
• POST /v1/verify-batch: signature, inclusion proof, errata count and judge for up to 1000 digests in one call.
• GET /v1/judges/{hash}: a judge version, its cohort of records, and its published prompt once retired.

Set it up

Step 1. Get the verification scope

Verification publishers are reviewed before the publish:verification scope is granted. Start with provenance records while you wait.

Check: Your token's scope includes publish:verification.

Step 2. Publish per item

Post a verification record with the artifact, pipeline, claims, summary and the judge fields (judge_model, judge_prompt_version, judge_prompt_hash).

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 item page links its record.

Step 3. Let buyers check

Show the digest on the listing. Buyers check it with verify-batch before paying.

curl -s -X POST 'https://aisourceoftruth.com/v1/verify-batch' \
  -H 'Content-Type: application/json' \
  --data '{"digests":["{digest}"]}'

Check: A buyer's check returns the judge version.

Step 4. Handle a recalled judge

If a judge version is found wanting, list its cohort, re-verify, and issue errata where results change.

curl -s -H 'Accept: application/json' 'https://aisourceoftruth.com/v1/judges/{hash}'

Check: The cohort count matches the records you published under that judge.

Publishing needs a publisher key and a token. The one-time setup is on /agents and in the plan's design.md.

Wire it into your agent

Publish from the step that approves a listing. Keep the judge prompt versioned and hashed in your repo.

MCP: add https://aisourceoftruth.com/mcp to the agent's MCP servers. Tools used: publish_record, verify_batch. Read tools need no token.

With the PromptReports products, or alone

• PromptReports: PromptReports research can be listed with its verification records when it is sold.
• Alone: every step above uses only AI Source of Truth.

Expected outcomes

• Each listing carries a VERIFIED record a buyer can check alone.
• A judge recall becomes a public, counted correction.

What it does not prove

• The registry stores what your judge decided. It never re-runs the judge or rescores.

The OpenSpec plan for your agent

Your coding agent fetches the plan and writes it into your repo as openspec/changes/integrate-aisot-verified-listings/:

curl -H 'Accept: application/json' 'https://aisourceoftruth.com/use-cases/verified-marketplace/openspec?lang=python&with=promptreports'

• 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/verified-listings/spec.md: the requirements and scenarios.

Read it here: OpenSpec plan. Back to all use cases or the documentation library.