Build on another publisher's work

Link your record to its source with derived-from, so corrections upstream reach you.

Who this is for

Publishers whose work quotes, summarizes, translates or extends someone else's attested work.

The problem

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.

How it works

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

Routes it uses

• POST /v1/records: append a signed record; the answer carries its digest and inclusion proof.
• GET /v1/model/lineage/{digest}?direction=both: what a record was built from and what was built from it, as of a signed checkpoint.
• GET /v1/model/assess/{digest}: rely, check or do_not_rely for one record, with the reasons.

Set it up

Step 1. Collect upstream digests

For each source you used, keep its record digest (see the cite-sources use case).

Check: Each source has a 64 hex digest or is noted as unattested.

Step 2. Publish with lineage

Add lineage: ["{upstream digest}"] to your provenance record.

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: Your record's lineage shows the upstream records.

Step 3. Read the family

Fetch your record's lineage to confirm the edges, and the source's to see your work listed downstream.

curl -s -H 'Accept: application/json' 'https://aisourceoftruth.com/v1/model/lineage/{digest}?direction=both'

Check: counts.up["derived-from"] matches the number of sources.

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

curl -s -H 'Accept: application/json' 'https://aisourceoftruth.com/v1/model/assess/{digest}'

Check: An erratum on a test source turns your record's verdict to check.

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

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.

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

With the PromptReports products, or alone

• PromptReports: A PromptReports report that cites registry records can carry them in lineage, so its readers inherit the correction signal.
• Alone: every step above uses only AI Source of Truth.

Expected outcomes

• Upstream corrections reach your records within one checkpoint.
• Sources see who built on them, which is the basis for credit and payment.

What it does not prove

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

The OpenSpec plan for your agent

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

curl -H 'Accept: application/json' 'https://aisourceoftruth.com/use-cases/build-on-records/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/record-lineage/spec.md: the requirements and scenarios.

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