Lineage
Data lineage
Lineage is the module slice that answers one question about any document, completely and in a single read: where did this come from, what knowledge did it produce, and what breaks if it changes? The other slices leave a trail — Intake records provenance, Atlas records which concepts a document mentions, Warrant records verification, Lens records which answers cited it — and Lineage stitches that scattered evidence into one DocumentLineage object. No LLM, pure SQL aggregates, deterministic ordering, every read tenant-scoped under row-level security.
Two directions from one document
The trail
Read left to right: upstream provenance and governance flow into the document; the document produces derived knowledge; that knowledge — plus the document itself — is what downstream consumers depend on.
The seven sections
A DocumentLineagehas seven parts, each sourced from a different slice's append-only record:
- document — identity and content fingerprint:
path,version(bumped on every save),contentHash, and the created/updated actors. - governance — Warrant's document verification tier (
unverified·verified·certified·deprecated), who verified it and when, the next re-verify date, andreviewOverdue— true when a verified doc is past its SLA. - origin — Intake provenance.
kindisconnector,vault, orupload; connector docs carry the source type (confluence·sharepoint·slack), external id, source version, last sync time, and up to ten recent sync runs. - revisions —
totalplus up to 50 immutable summaries newest first. Each item carries version/change kind, sorted changed-field names, whether a recoverable content snapshot exists, activity, actor, note, and timestamp. Large content blobs never enter the lineage payload. - audit — the append-only
document.*event trail targeting this doc, newest first, capped at 50: create, update, verify, delete — with actor, timestamp, and meta. - derived — Atlas knowledge the document produced: chunk count, the canonical concepts it contributed mentions to (top by mention count, capped at 50, each with authority and lifecycle), and the count of live relations whose evidence cites it.
- downstream — impact. Lens answers that cited it (
citedByAnswers), the semantic-cache entries that depend on it, andimpactedEntities— the live concepts grounded on it that a deprecation would touch.
The DocumentLineage shape
The full response type. Timestamps are ISO-8601 strings; nullable fields are explicitly | null. Arrays are deterministically ordered and capped so the payload is bounded.
Read it over the API
One GET, scoped to the key's workspace. Accepts kb:read (preferred) or the legacy runs:read grant — the same read scopes as the manifest. The document ACL is checked before lineage is assembled, so an inaccessible restricted id is the same 404 as an unknown, cross-tenant, or soft-deleted id.
/api/v1/documents/{id}/lineageBearer · kb:read or runs:readThe unified per-document lineage trail: origin provenance, governance, the document audit trail, derived knowledge, and downstream impact. 404 on an unknown or deleted id.
Also over MCP and the BFF
kb_document_lineage { docId } (scope kb:read or runs:read) — so an agent can trace provenance mid-run. The workspace UI reads it from the BFF at GET /api/w/{workspaceId}/documents/{docId}/lineage and renders the trail on the document page. All three surfaces return the identical DocumentLineage.Why it is trustworthy
- Tenant isolation is total. Every query runs under FORCE row-level security and also filters
workspace_idexplicitly — workspace B can never read workspace A's lineage. - It reads the append-only record. The audit trail and entity revisions are never mutated in place. The response exposes a bounded document-revision summary with the uncapped total, so clients can see both recent change shape and whether older history exists without transferring content snapshots.
- It is deterministic. No model call, stable ordering, bounded caps — the same document yields the same lineage every time, which is what makes it citable in a report or an audit.
- Downstream is live.
citedByAnswersmatches persisted answers whose[Sn]sources include this document via a jsonb containment query, andcachedAnswersreflects current cache dependencies — so impact is measured against what is actually deployed, not a snapshot.
Put it to work