The lineage graph looks convincing.
The executive revenue dashboard connects to a reporting mart, which connects to three warehouse tables, which connect back to the billing system and the CRM. Boxes, arrows, a clean left-to-right flow. Someone in the room says "so we'd finally be able to answer where our numbers come from," and the answer is yes.
It's a fair demo. The graph is accurate. Nothing about it is misleading.
It also stops one level above where the hard questions live, and the demo is structured so that the gap stays invisible.
Demo questions are table-level questions
Watch what actually gets asked in an evaluation.
Where does this report get its data. What feeds this table. If we deprecate this source, what breaks. Show me upstream of the mart.
Every one of those is answerable at table granularity, and a human asking them has a follow-up available. They see "revenue_reporting" in the graph, recognize the name, and go look at it. The lineage got them to the right neighbourhood and their own knowledge covered the last hundred meters.
That last hundred meters has been invisible in every lineage evaluation for a decade, because the person evaluating always closes it themselves without noticing they did.
An agent has no follow-up
Point a retrieval system at the same graph and the last hundred meters stops being covered.
An AI system asked for net revenue retrieves what the metadata offers. If the metadata says the figure comes from the revenue_reporting table, that's the answer it works with. It has no instinct that the table holds four columns with similar names, no memory of the migration that left one of them stale, and no colleague to ask.
So it picks, and it answers, and the answer arrives with the same confident tone as everything else it produces.
This is the specific mechanism behind most grounding failures that get blamed on the model. The retrieval worked. The metadata it retrieved was accurate at the granularity it was recorded, and that granularity was one level too coarse to answer the question.
Three places table-level runs out
Which column. A reporting table holds revenue, revenue_net, revenue_adj, and revenue_final. Three are historical, one is current, and the difference is documented in a project doc from 2023. Table-level lineage points at all four with equal confidence.
What happened in transit. The number in the report is the source column with a filter applied, or a CASE statement that reclassifies certain transaction types, or a currency conversion at a rate fixed on a particular date. That logic is where the definition actually lives. Table-level lineage records that the two tables are connected and stays silent about what the connection does.
Which path. The same source column is reachable through two different join paths, and they produce different results because one of them excludes canceled orders. Both paths are real, both appear in the graph, and choosing between them requires knowing something the graph doesn't record.
Each of these is the kind of detail an experienced engineer knows about their own estate. That's precisely why it survives a demo, and precisely why it fails the moment a system becomes the consumer.
The same gap shows up in impact analysis
Resolution has a second consequence that has nothing to do with AI.
A schema change is proposed. Table-level impact analysis reports that 40 downstream reports touch the affected table. Column-level impact analysis reports that 3 of them touch the column being changed.
Forty is a number that stops a change or triggers a month of coordination. Three is a number someone acts on this week. The underlying change is identical; the resolution of the metadata determines whether the organization can move.
Teams that have lived with table-level impact analysis for years tend to describe it as noisy and route around it. That's a rational response to a tool that reports forty when the true answer is three.
The cost lands twice. The analysis gets ignored, and the confidence that should have come from running it never arrives.
Why lineage stops at the table
Resolution and derivation are linked, and it explains most of what's in the market.
Lineage inferred from query logs or run history can see which tables were touched, because that's what the execution record contains. Getting to column level requires parsing the code that defines the transformation: the SQL, the stored procedure, the Informatica PowerCenter mapping, the SSIS package. That's a harder engineering problem and it has to be solved separately for every source technology.
Column-level lineage comes from parsing those artifacts across the estate, including the legacy systems that usually fall out of scope. Ask any vendor which source technologies they parse and which they infer. The list is the answer, and it varies more than the demo suggests.
One test
Skip the graph in your next evaluation and bring a metric.
Pick a number that appears in an executive report. Ask which specific column produces it, what transformation logic is applied between the source and the report, and which join path the value travels.
Then ask the same three questions about a system that hasn't run this quarter.
A platform that answers at table granularity will answer the first question with a table name and move quickly to the next slide. That is the test, and it takes about two minutes.
