Verified marketplace goods

# Proposal: Verified marketplace goods

## Why
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.

## What Changes
- 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.


## Capabilities
### New Capabilities
- `verified-listings`: A verification record per item, scored under a judge pinned by hash. Buyers check without trusting the seller.

## Impact
- External service: AI Source of Truth at https://aisourceoftruth.com. Reads are anonymous. Writes need a publisher key pair you generate, a client id and secret from registration, and a token from `/oauth/token`.
- Routes used: `POST /v1/records`, `POST /v1/verify-batch`, `GET /v1/judges/{hash}`.
- No PromptReports product is required.
- Source of this plan: https://aisourceoftruth.com/use-cases/verified-marketplace (CC0). Regenerate it with `curl -H 'Accept: application/json' 'https://aisourceoftruth.com/use-cases/verified-marketplace/openspec?lang=http'`.

# Design: Verified marketplace goods

## Context
Marketplaces for datasets, reports, prompts and models. 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.

## Where it sits in your agent
Publish from the step that approves a listing. Keep the judge prompt versioned and hashed in your repo.

Over MCP, point the agent at `https://aisourceoftruth.com/mcp` (Streamable HTTP, JSON-RPC 2.0; read tools need no token). The tools this change uses: `publish_record`, `verify_batch`.

## Decisions
- Treat the registry as a source of facts about records, never about the world. Show what it says, with the digest, and do not turn a verdict into a quality score.
- If the registry cannot be reached, treat the answer as unknown (the same as `check`), never as `rely`, and retry later.
- Keep content private: send hashes. Never put personal data in a record; it is public and permanent.
- Keep the private key and client secret in your secret store. Rotate keys at `POST /v1/keys`; a revoked key cannot sign.

## Setup and signing helper

```sh
# Publisher setup, once. Make an Ed25519 key pair yourself; the registry never sees the private key.
# 1. Register: POST https://aisourceoftruth.com/v1/publishers with {"id","name","public_jwk"}, signed by that key
#    (X-AISOT-Signature over the exact body bytes, base64url) and an Idempotency-Key.
#    The answer carries client_id, client_secret and your key_id.
# 2. Token (60 minutes; mint another the same way):
curl -s -X POST 'https://aisourceoftruth.com/oauth/token' -H 'Content-Type: application/json' \
  --data '{"grant_type":"client_credentials","client_id":"'"$AISOT_CLIENT_ID"'","client_secret":"'"$AISOT_CLIENT_SECRET"'"}'
# ./sign-ed25519 reads bytes on stdin and prints the base64url Ed25519 signature.
```

## Calls
### POST /v1/records
append a signed record; the answer carries its digest and inclusion proof.

```sh
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"
```

### POST /v1/verify-batch
signature, inclusion proof, errata count and judge for up to 1000 digests in one call.

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

### GET /v1/judges/{hash}
a judge version, its cohort of records, and its published prompt once retired.

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

## What this does not prove
- The registry stores what your judge decided. It never re-runs the judge or rescores.

# Tasks: Verified marketplace goods

## 1. Configure
- [ ] 1.1 Set `AISOT_ORIGIN=https://aisourceoftruth.com` in the agent's environment.
- [ ] 1.2 Generate an Ed25519 key pair, register the publisher (`POST /v1/publishers`), and store `AISOT_CLIENT_ID`, `AISOT_CLIENT_SECRET`, `AISOT_KEY_ID` and the private key as secrets.
- [ ] 1.3 Mint a token at `/oauth/token` and confirm `GET /v1/me` answers with your publisher id.
- [ ] 1.4 Optional: add the MCP server `https://aisourceoftruth.com/mcp` to the agent's MCP config.

## 2. Build
- [ ] 2.1 Get the verification scope: Verification publishers are reviewed before the `publish:verification` scope is granted. Start with provenance records while you wait.
- [ ] 2.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`). (`POST /v1/records`)
- [ ] 2.3 Let buyers check: Show the digest on the listing. Buyers check it with verify-batch before paying. (`POST /v1/verify-batch`)
- [ ] 2.4 Handle a recalled judge: If a judge version is found wanting, list its cohort, re-verify, and issue errata where results change. (`GET /v1/judges/{hash}`)

## 3. Verify against the live registry
- [ ] 3.1 Get the verification scope: Your token's scope includes `publish:verification`.
- [ ] 3.2 Publish per item: The item page links its record.
- [ ] 3.3 Let buyers check: A buyer's check returns the judge version.
- [ ] 3.4 Handle a recalled judge: The cohort count matches the records you published under that judge.

## 4. Done when
- [ ] 4.1 Each listing carries a VERIFIED record a buyer can check alone.
- [ ] 4.2 A judge recall becomes a public, counted correction.

# verified-listings Specification

## ADDED Requirements

### Requirement: Verified listings
The marketplace SHALL publish a verification record, with the judge pinned by hash, for every listing it labels verified.

#### Scenario: Listing approved
- **WHEN** a listing passes verification
- **THEN** its verification record is published and its digest shown on the listing