Build on another publisher's work

# Proposal: Build on another publisher's work

## Why
When a source is corrected, nothing downstream finds out. A `lineage` link makes your record derived-from the source, so the registry's assess rules flag your record when the source is corrected or sealed, and the source's page shows what was built from it.

## What Changes
- Name each upstream record digest in your record's `lineage` array.
- The registry adds a public derived-from edge.
- Assess on your record now reports `upstream_erratum` or `upstream_sealed` when a source changes.


## Capabilities
### New Capabilities
- `record-lineage`: Link your record to its source with derived-from, so corrections upstream reach you.

## 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`, `GET /v1/model/lineage/{digest}?direction=both`, `GET /v1/model/assess/{digest}`.
- No PromptReports product is required.
- Source of this plan: https://aisourceoftruth.com/use-cases/build-on-records (CC0). Regenerate it with `curl -H 'Accept: application/json' 'https://aisourceoftruth.com/use-cases/build-on-records/openspec?lang=python'`.

# Design: Build on another publisher's work

## Context
Publishers whose work quotes, summarizes, translates or extends someone else's attested work. When a source is corrected, nothing downstream finds out. A `lineage` link makes your record derived-from the source, so the registry's assess rules flag your record when the source is corrected or sealed, and the source's page shows what was built from it.

## Where it sits in your agent
Add the lineage field in the same step that publishes your record. Run the assess check from a nightly job or from the change feed.

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`, `get_lineage`, `assess`.

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

```python
# pip install requests cryptography
import base64, json, os, uuid
import requests
from cryptography.hazmat.primitives.serialization import load_pem_private_key

AISOT = os.environ.get("AISOT_ORIGIN", "https://aisourceoftruth.com")
KEY = load_pem_private_key(open(os.environ["AISOT_KEY_PEM"], "rb").read(), password=None)  # Ed25519

def token():
    r = requests.post(f"{AISOT}/oauth/token", json={
        "grant_type": "client_credentials",
        "client_id": os.environ["AISOT_CLIENT_ID"],
        "client_secret": os.environ["AISOT_CLIENT_SECRET"],
    })
    r.raise_for_status()
    return r.json()["access_token"]  # lasts 60 minutes

def signed_post(path, body, content_type="application/json", token=token):
    raw = json.dumps(body, separators=(",", ":")).encode()
    sig = base64.urlsafe_b64encode(KEY.sign(raw)).rstrip(b"=").decode()
    headers = {"Content-Type": content_type, "X-AISOT-Signature": sig, "Idempotency-Key": str(uuid.uuid4())}
    if token:
        headers["Authorization"] = f"Bearer {token()}"
        headers["X-AISOT-Key-Id"] = os.environ["AISOT_KEY_ID"]
    r = requests.post(f"{AISOT}{path}", data=raw, headers=headers)
    r.raise_for_status()
    return r.json()
```

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

```python
answer = signed_post("/v1/records", record, content_type="application/vnd.aisot.record+json")
```

### GET /v1/model/lineage/{digest}?direction=both
what a record was built from and what was built from it, as of a signed checkpoint.

```python
r = requests.get(f"{AISOT}/v1/model/lineage/{digest}?direction=both", headers={"Accept": "application/json"})
r.raise_for_status()
answer = r.json()
```

### GET /v1/model/assess/{digest}
rely, check or do_not_rely for one record, with the reasons.

```python
r = requests.get(f"{AISOT}/v1/model/assess/{digest}", headers={"Accept": "application/json"})
r.raise_for_status()
answer = r.json()
```

## What this does not prove
- A derived-from link is your statement. It does not prove the source permitted the use; read its terms for that.

# Tasks: Build on another publisher's work

## 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 Collect upstream digests: For each source you used, keep its record digest (see the cite-sources use case).
- [ ] 2.2 Publish with lineage: Add `lineage: ["{upstream digest}"]` to your provenance record. (`POST /v1/records`)
- [ ] 2.3 Read the family: Fetch your record's lineage to confirm the edges, and the source's to see your work listed downstream. (`GET /v1/model/lineage/{digest}?direction=both`)
- [ ] 2.4 React to upstream changes: Assess your record on a schedule. `upstream_erratum` or `upstream_sealed` names the source in `digest`; review and, if needed, correct your own record. (`GET /v1/model/assess/{digest}`)

## 3. Verify against the live registry
- [ ] 3.1 Collect upstream digests: Each source has a 64 hex digest or is noted as unattested.
- [ ] 3.2 Publish with lineage: Your record's lineage shows the upstream records.
- [ ] 3.3 Read the family: `counts.up["derived-from"]` matches the number of sources.
- [ ] 3.4 React to upstream changes: An erratum on a test source turns your record's verdict to `check`.

## 4. Done when
- [ ] 4.1 Upstream corrections reach your records within one checkpoint.
- [ ] 4.2 Sources see who built on them, which is the basis for credit and payment.

# record-lineage Specification

## ADDED Requirements

### Requirement: Derived work names its sources
Every record the product publishes for derived work SHALL list the record digests of its attested sources in `lineage`.

#### Scenario: Summary of two sources
- **WHEN** a piece summarizes two attested sources
- **THEN** its record's lineage holds both digests

### Requirement: Upstream changes are acted on
The product SHALL review its record when assess reports `upstream_erratum` or `upstream_sealed`.

#### Scenario: Source corrected
- **WHEN** a source gets an erratum
- **THEN** the product opens a review for each record derived from it