Seshat-BI: Skill for Claude Code

cross-table-lineage

• Roadmap feature: F039 (PROPOSED at plan time; not yet a docs/roadmap/roadmap.md ledger row -- see "See also" below). On-disk spec: specs/099-cross-table-lineage-impact/.
• Authority category: Product Module / artifact-writing (the F024 enumerated declaration -- see docs/architecture/product-modules.md).

Seshat BI can already answer "does this ONE source drift from its own profile" (F014) and "what does this ONE KPI derive from, conceptually, inside the contract layer" (spec 044). Neither answers the question a table owner actually asks the moment a column changes: if this column changes shape or disappears, which migrations, metric contracts, TMDL measures, and dashboard visuals sit downstream of it, and how far does the chain reach before it runs out of committed evidence? Today that question is answered by hand -- docs/demo/net-sales-end-to-end-readiness-trace.md proves it can be done for exactly one KPI, on paper, by a human reading five artifact families in sequence. This skill GENERALIZES that trace's shape (evidence tiers, hop-by-hop citation) into a regeneratable artifact for any column or metric contract. It derives evidence only; it never fabricates a link, never scores impact, and never decides what must be re-reviewed.

Boundary against neighbouring shipped work (read first)

• Spec 044 KPI Derivation-Lineage Contract (specs/044-kpi-derivation- lineage/, ratified, no runtime code) authors a Derives from PROSE section inside a metric contract describing METRIC-TO-METRIC conceptual derivation (e.g. Net Sales derives from Gross Sales and Discount Amount) in the DEFINE/reasoning layer. This skill does not touch contract prose and does not declare or transcribe a metric-to-metric edge; it derives a PHYSICAL, cross-ARTIFACT chain (column -> SQL -> contract -> measure -> visual) from structural references already present in committed YAML/SQL/TMDL/binding files, generated as an artifact, never authored as prose. A 044 Derives from edge is a citable input at the metric-contract hop when a chain happens to pass through a derived KPI; this skill never edits, re-derives, or second-guesses it.
• F014 Source Drift Detector (spec 015, shipped) DETECTS that one source's shape or semantics drifted from its own recorded profile. This skill does not detect drift and runs no comparison against a baseline profile; it is the DOWNSTREAM-SCOPING half of the same idea -- given a column, it shows what sits downstream so a reviewer knows what to re-check after F014 (or a human) flags something. It enables F014's aftermath; it does not re-implement F014's comparison logic.
• F012 Data Quality Control Room (spec 013, shipped) is also a cross-table, read-only aggregator, but it rolls up DATA-QUALITY findings across tables. This skill aggregates LINEAGE EDGES, a different evidence category; it does not read Control Room's findings and Control Room gains no lineage view from this skill.
• The Net-Sales end-to-end readiness trace (docs/demo/net-sales-end-to-end-readiness-trace.md, shipped) is the single hand-authored proof for exactly one KPI. This skill generalizes that trace's SHAPE into a regeneratable template for any column or metric contract; it supersedes nothing and never retro-edits that file.
• OpenLineage was evaluated and DEFERRED (docs/decisions/0013-bi-tool- adapter-shortlist.md: "emitter, not a gated reader; external-service boundary; duplicates F014"). This skill is not a revival: it is a static reader over already-committed repository text (Principle VIII), never a running emitter, never a client of an external lineage backend.