DECISION: [ADR-015] Lineage as DAG Edges in WorldDAG
DATE: 2026-02-18
TYPE: 1 (irreversible)
STATUS: Accepted
SOLITON SCORE: 0.85

## Context

Data lineage tracking is required for SR 11-7 compliance: "institutions
should be able to trace model inputs back to their sources." Traditional
lineage systems use a separate graph from the causal model.

## Options Considered

### Option A: Separate lineage graph
Pros: Clean separation of concerns. Lineage-specific features.
Cons: Two graphs to maintain. Cannot reason about data provenance
and causal structure together. Duplication of graph infrastructure.

### Option B: Lineage as edges in WorldDAG (selected)
Pros: Unified graph — lineage IS causal ("this column exists BECAUSE
of that source"). Impact analysis uses same traversal as causal
inference. One graph, one audit trail.
Cons: WorldDAG grows larger. Must distinguish lineage edges from
causal edges (solved with edge_type="lineage").

### Option C: Flat lineage table (source, transform, target)
Pros: Simple, queryable.
Cons: Cannot traverse multi-hop lineage. No graph algorithms.

## Decision

Data lineage tracked as edges in the WorldDAG with edge_type="lineage".
Source entities, datasets, and transforms are all WorldDAG nodes.
Lineage traversal uses the same ancestors/descendants methods as
causal reasoning.

## Rationale

Data lineage IS causal structure. "This prediction uses this data
because of this pipeline" is a causal statement. Unifying lineage
and causal reasoning in one graph enables questions like "if this
data source breaks, which causal estimates are affected?"

## Consequences

**Easier:** Unified impact analysis, single audit trail, reuse of
WorldDAG graph algorithms for lineage queries.
**Harder:** WorldDAG must handle heterogeneous edge types. Need
conventions to distinguish lineage from causal edges.
