Column-Level Lineage

• Column-level lineage is produced by resolving the expression tree of every query a job runs: parse the SQL, bind each output column to the input columns its expression references, and resolve those names through the query's own scopes — aliases, subqueries, common table expressions, joins (Tokens, Parse Tree, AST).
• That resolution is the reason it is hard. Table-level lineage needs only the FROM and the target; column-level needs full name resolution against the real schemas, which means the parser has to know what every referenced table contains at the moment the query ran (How a Query Executes: Planner and Executor).
• SELECT * is the canonical defeat. The set of output columns is not in the text; it is whatever the upstream had that day. A generator can resolve it if it knows the upstream schema at that moment and cannot if it does not, which is exactly why star selects are discouraged in models and why the guide bans "SELECT * is fine in analytics" as a claim.
• Three more classes defeat parsers routinely: dynamically constructed SQL, where the query text does not exist until runtime; user-defined functions and stored procedures, whose bodies are a second parsing problem; and anything computed outside SQL — a Python transformation, a BI-layer calculated field (Two Dashboards, Two Numbers).
• The payoff is that the graph becomes narrow instead of wide. During an incident a table-level walk widens at every hop — each table has many parents — while a column-level walk narrows, because most of a table's parents contribute nothing to the column in question. Narrowing is what makes a walk finish (Debugging a Data Incident).
• The second payoff is impact precision. A column-level graph turns "this change affects forty models" into "this change affects two models and one dashboard tile", which is the difference between a notification people read and one they filter (Impact Analysis).

The dashboard reads `revenue_daily`. `revenue_daily` reads `fct_orders`. `fct_orders` reads `stg_orders`, `dim_customer`, `dim_fx` and `dim_product`. Each of those reads two or three more. The investigator picks a branch on instinct and reads SQL until something looks wrong.

The broken measure is `monthly_revenue`. Its ancestors are seven columns in five datasets, listed with the expression at each hop, and two of them are marked as row-influencing rather than value-influencing. The investigator checks the FX join first because it is the only hop that involves a date-dependent lookup.

monthly_revenue                      (BI measure: SUM over filtered days)
└── revenue_daily.revenue            SUM(fct_orders.revenue) GROUP BY country, day
    └── fct_orders.revenue           b.amount_minor * f.rate
        ├── stg_orders.amount_minor  CAST(raw.amount AS NUMERIC)
        │   └── orders.amount        source column, operational database
        └── dim_fx.rate              joined ON currency, rate_date = order_date
            └── raw_fx_feed.rate     source column, external provider

  row-influencing (not value-influencing):
    fct_orders    WHERE status <> 'cancelled'      <- stg_orders.status
    revenue_daily GROUP BY country                 <- dim_customer.country

• Get it from the engine wherever the engine will give it to you. Some query engines expose the resolved column bindings of a statement, and a binding produced by the engine that ran the query is authoritative in a way a separate parser never is (Query Engines).
• Ban SELECT * in anything a consumer depends on, and enforce it in review. This is usually argued as a stability rule; it is also the single change that most improves lineage coverage (Model Layering).
• Record the expression, not only the endpoints. "Derived from amount_minor and rate by multiplication" is what lets an investigator decide in seconds whether this hop could produce the observed symptom.
• Treat unresolved columns as a first-class, visible state. A generator that reports "could not resolve" for a job is telling you something true; one that silently emits fewer edges is teaching false confidence (Data Lineage).
• Design the interface around narrowing: start at the broken column, show only its parents, and let the user step. A full column-level graph rendered at once is unreadable at any real platform size.
• Wire classification propagation to it. If users.email is tagged, every column derived from it should inherit the tag by default and require an explicit assertion to lose it — that is the mechanism behind derived-data governance (Data Classification).

• A column edge guarantees that the output column's expression referenced those input columns, for the query that produced it. It does not guarantee the value depended on them meaningfully — a column referenced in a CASE branch that never fires still produces an edge.
• Coverage is guaranteed only for statements the resolver understood. Unresolved statements produce silence, and silence is indistinguishable from independence, which is the most dangerous property of this whole subject.
• Nothing guarantees that a column's *meaning* survived the derivation. revenue derived from amount is an edge whether the conversion was correct, wrong, or applied the wrong day's rate (Semantic Changes).
• Edges through a user-defined function are guaranteed only at the function boundary unless the function body is also resolved: you learn that the output depends on the inputs, not which input drives which part.