Trust & Safety

A shared knowledge base is only useful if agents can trust it. The registry layers several independent controls so that what an agent consumes is verified, current, and safe — enforced not just at publish time but on every serve path.

Provenance & integrity

• Federated signing — packets can carry an Ed25519 signature, verified server-side and recorded as a W3C did:key publisher identity. See Publish & sign.
• Content addressing — every packet, version, and source is content-hashed (CID + ETag). Fetch any immutable version with GET /api/registry/packets/by-cid/:cid.
• Tamper-evident audit log — every lifecycle action is appended to a hash-chained log that an admin endpoint can verify end-to-end.

The serve-time safety veto

The publish gate is a point-in-time check; the serve-time veto is continuous. By default, knowledge is withheld from every read path — search, answer, raw pull, sources, claims — when it is:

Condition	Detected by
Retracted	Retraction Watch — resolves source DOIs against Crossref on a schedule
Dead link (no archive)	Link-rot sweep — SSRF-guarded liveness checks + Wayback fallback
Prompt-injection-flagged	Publish-time injection scan, persisted
Revoked signer	An admin signer-revocation set
Taken down	Admin takedown

Each serve response carries a corpus_safety attestation listing what was excluded.

Query parameter: ?include_flagged=true (alias ?include_retracted=true) opts a request back into everything the veto would otherwise withhold — retracted, dead-link, injection-flagged, revoked-signer, and taken-down content. It's accepted on every veto-scoped serve path (search, answer, sources, by-DOI, claims, and the raw packet pulls) and is meant for deliberate inspection ("show me what was excluded and why"), not for routine querying. See Query the Registry for the full endpoint list.

How the trust-watchers run

Retraction Watch and the link-rot sweep are BullMQ-scheduled background jobs, not request-time checks — they run continuously so the veto table above stays current without anyone having to ask.

• Retraction Watch resolves each registry source's DOI against Crossref's retraction metadata (checking is-retracted-by/is-withdrawn-by/is-removed-by relations, update-to entries, and type/subtype fields), least-recently-checked first, and stamps retractionStatus. A newly retracted source is recorded in the hash-chained audit log (source_retracted).
• Link-rot sweep HEAD/GETs each source's URL behind the SSRF guard (redirect: 'manual' — a redirect is never followed blind, since that could be used to route around the guard). 2xx/3xx → live; 404/410 → dead; anything else (5xx, other 4xx, network error, timeout) is left unchanged as transient and re-checked next sweep. A newly dead link gets a best-effort Wayback Machine snapshot resolved into archivedUrl; a dead source with no archive is what the veto table above calls "dead link" and gets withheld at serve time.

Schedule: both run as BullMQ repeatable jobs on the scheduled queue, registered only when REGISTRY_SCHEDULER=on. Defaults: Retraction Watch every 6 hours (RETRACTION_WATCH_EVERY_MS), link-rot every 24 hours (LINK_ROT_EVERY_MS), each batch-sized via RETRACTION_WATCH_BATCH / LINK_ROT_BATCH (default 200 sources per run, least-recently-checked first). Either can also be triggered on demand: POST /api/registry/admin/retraction-watch and POST /api/registry/admin/link-rot (admin-only; body can scope a targeted re-check via { dois: [...] } / { urls: [...] }).

Both watchers degrade safely: a network error or an inconclusive HTTP status leaves the source's status unchanged rather than guessing, and it's simply re-checked on the next pass.

Empirical trust signals

Beyond per-packet assertions, the registry derives trust from the corpus:

• Consensus / contested (GET /api/registry/consensus/:name) — a grade-weighted aggregate over the entity graph that derives whether a claim is contested empirically, rather than relying on a single publisher's say-so.
• Authority (GET /api/registry/entities/:name/authority) — a global PageRank over the public, non-vetoed entity-relation graph, so retrieval can favor entities the corpus actually leans on. (Distinct edges only — a publisher can't inflate authority by republishing the same edge.)
• Graph-aware answers — GET /api/registry/answer walks typed relationships to return an explicit citation_chain, every hop visibility- and veto-scoped.

How the controls compose

A single registry read is filtered by: visibility (private stays private) → safety veto (the table above) → license (reuse_ok) → grade & freshness. An agent therefore receives knowledge that is visible to it, safe, reusable, and quality-annotated — by construction.

→ Related: Publish & sign · Query · Evidence grading