The data team pulled up their lineage tool. It showed every pipeline that ran during the observation window: clean graphs, recent timestamps, green checkmarks. The reserve calculation wasn't in it. That job runs once a quarter, and the last run predated the monitoring agent's deployment.
The team spent 3 weeks reconstructing the path by hand. The tool had been telling the truth the whole time, just a smaller truth than anyone realized.
Log-based lineage only shows what ran
Most modern lineage tools work by observation. They watch query logs, parse execution metadata, and infer relationships from what the system actually did while someone was watching.
That approach has a structural ceiling. It can only see code paths that executed during the observation window. The quarterly job, the conditional branch that fires on month-end, the exception handler that rewrites a column under specific conditions: all invisible until they run, and by then you're doing forensics.
Observed lineage also inherits every gap in the logs. Stored procedures that don't emit useful metadata, ETL tools that log at the job level rather than the column level, scripts that run outside the monitored environment. The graph looks complete because a graph always looks complete. Completeness by construction is a different property entirely.
Parsed code shows what was designed
MetaKarta computes lineage by parsing the actual code: the SQL, the ETL definitions, the stored procedures, the BI formulas. Every path the code can take is in the source, so every path is in the lineage, whether it ran yesterday or hasn't fired since 2023.
Lineage by design, not by observation.
Parsing is also what makes column-level precision possible across systems. When a Power BI measure references a warehouse view that reads from 3 staging tables, the parser follows the actual expressions through each hop. The result is cross-system, column-level lineage that's complete because the code itself is the source of record.
This is the part of MetaKarta with the longest track record. The parsing technology has spent nearly 30 years embedded via OEM inside Microsoft Purview, Informatica from Salesforce, IBM, Oracle, and Qlik Talend, and it now covers 400+ connectors from legacy ETL to modern cloud stacks.
Data estates are messy, and parsing has to survive the mess
The clean version of lineage assumes an estate that's all dbt models and warehouse views. Complex data estates carry a 2009 Informatica workflow feeding a Snowflake pipeline feeding a Power BI model, with a stored procedure in the middle that 1 person still understands.
Parsing has to read all of it, in each system's own language: DAX and TMDL on the BI side, dialect-specific SQL in the warehouses, the proprietary formats of legacy ETL platforms. That's the reason connector count is a depth claim here rather than a checkbox claim. A connector that ingests log metadata is an afternoon of work. A parser that fully reads Informatica mappings or Tableau calculations is years of it, and 400+ of those parsers exist because they spent decades in production inside other vendors' platforms.
The lineage that comes out crosses vendor boundaries without losing column-level resolution, because every hop was parsed rather than inferred at the boundary.
Design-time lineage also means lineage across time
One more property falls out of parsing that observation can't reproduce: history.
MetaKarta versions the parsed metadata, so lineage exists per version and configuration, over time. When the auditor's question is about a number filed 3 quarters ago, the answer comes from the code as it existed then, with the diff to today available beside it. Observed lineage can only describe the estate it watched; parsed, versioned lineage can describe the estate on any date you ask about.
For data engineers, that's also change management. Compare lineage across versions and you can see exactly which paths a release altered, before the release and after it.
Auditors ask design-time questions
Here's the practical test. The auditor's question is "how is this number produced," and that's a question about design. The answer has to hold for every execution, including the ones that haven't happened yet.
Only parsed, design-time lineage can give that answer, because only the code says what the system will do on every run, including the runs that predate your monitoring.
The same property powers impact analysis before a change ships. When someone proposes altering a source column, parsed lineage shows every downstream dependency across every connected system. Know the blast radius before the first ticket lands.
Design-time lineage is the foundation, and the platform builds on it
Lineage in MetaKarta writes into the same shared metadata repository that the catalog, governance, and Semantic Hub read from. The catalog describes assets the parser actually verified. Governance policies attach to real, traced columns. And when Semantic Hub compiles a governed definition into Snowflake Semantic Views or a Tableau data source, the lineage of that compiled artifact is already known, because the platform wrote it.
A definition you can't trace is a definition you can't trust. Parsing is how MetaKarta makes every definition traceable, from the source system to the dashboard to the compiled artifact. To see how far column-level, design-time lineage actually reaches, get in touch.
