When compliance teams evaluate tools for improving their audit trail, they frequently encounter the term "data lineage" from the data engineering and analytics space. Lineage tools from that world are mature, well-documented, and genuinely useful for the problems they were designed to solve. They are not, however, designed for audit and compliance use cases, and conflating lineage with provenance leads teams to invest in tools that address a different problem than the one they have.
The distinction matters enough that I want to be precise about it, because we built Pramaana specifically around provenance, not lineage, and that choice has downstream consequences for what the tool can and cannot do.
What data lineage tracks
Data lineage is concerned with the movement of data through systems and pipelines. A lineage graph answers questions like: where did this dataset come from? Which ETL jobs transformed it? Which downstream reports depend on it? If a source table is updated, which dashboards are affected?
These are valuable questions for data engineers and analytics teams. Lineage tools like Apache Atlas, OpenLineage, and similar products map the technical infrastructure: tables, transformations, pipelines, dependencies. The unit of analysis is a dataset or a field within a dataset, and the lineage describes how that field's value was computed from upstream fields.
Lineage answers the question "how did this data get here?" in the sense of "through what technical steps did it pass?"
What data provenance tracks instead
Data provenance is concerned with the origin of a claim. It answers a different question: what document, decision, or event produced this figure in the first place?
For audit purposes, the distinction is critical. A financial figure reported in a working paper did not originate inside a database or a pipeline. It originated in a board decision documented in meeting minutes, a legal agreement captured in a PDF, a management estimate recorded in a memo, or an operational system export that reflects real-world transactions. The working paper cell may have been populated by an ETL process that pulled from a financial system, but the financial system's value traces back to a human decision or an external document.
Lineage tracks the technical chain from the financial system to the working paper. Provenance tracks the evidential chain from the source document to the financial system value (and then to the working paper). These are different chains, and for audit purposes, the provenance chain is the one that the external auditor or regulator needs to see.
A concrete example
A revenue recognition adjustment of $1.8M appears in Q3 working papers. An examiner asks for the evidence supporting this figure.
A lineage tool would tell you: this value was populated by a nightly batch job that pulled from the revenue adjustments table in the ERP system, which was last modified by the accounting team's close process on October 3rd. That is accurate and potentially useful for debugging. It is not what the examiner wants.
The examiner wants to know: what business event produced this $1.8M adjustment? The answer is a credit memo issued to a specific counterparty, authorized by the VP of Finance, documented in an email approval dated September 28th, which references a contract amendment attached to that email. The chain runs from the working paper cell back through the ERP record to the credit memo to the authorization email to the contract amendment.
None of that chain is visible to a lineage tool, because the originating documents (the email, the contract amendment) are not part of the data infrastructure. They are unstructured documents that produced a value that was then entered into the structured system. The provenance chain spans both the structured system and the unstructured source documents. Lineage only covers the structured portion.
Where the conflation causes practical problems
Compliance teams who invest in lineage tools expecting to solve their audit evidence problem typically discover the gap during their first regulatory examination or external audit after the tool is deployed. They can demonstrate where their data came from in a technical sense. They cannot demonstrate what business event or external document justified the value.
This is not a failure of the lineage tool. Lineage tools do exactly what they are designed to do. The problem is that compliance audit requirements operate at a layer below technical lineage: they reach back to the original source record, before the data entered any system.
A second practical problem is that many of the figures auditors care most about do not have unambiguous lineage at all. Estimates, reserves, fair values, and adjustments are entered by people based on judgment calls supported by external documents. They may not have passed through any transformation pipeline. Their "lineage" is a manual data entry from a spreadsheet or email. Lineage tools have nothing to say about these figures. Provenance tools are specifically designed for them.
The provenance chain as an audit-native concept
Audit documentation has always implicitly required provenance in the sense I am describing. When an auditor annotates a working paper cell with a tick mark and a cross-reference to a source document, they are recording a provenance link. The practice is old. What is new is the ability to maintain those links systematically, automatically, and at a scale that makes them useful across an entire audit cycle rather than spot-verifiable by the auditor who created them.
The Pramaana trace engine is built around this model. The objects it reasons about are source documents (PDFs, emails, spreadsheet exports) and the claims within those documents. It links each claim to the working paper figures that depend on it, building the chain that runs from the board package or management memo all the way to the reported figure. That chain is what regulators and auditors need. It is not the same as the data infrastructure chain that lineage tools map.
When lineage tools are still useful alongside provenance
We are not arguing that lineage has no role in compliance. For organizations with complex data infrastructures and multiple systems feeding into their financial close, lineage tools provide real value: they help identify which systems need to be included in the evidence base, they document the transformation steps that produced consolidated figures, and they support data quality monitoring that reduces the risk of errors reaching the financial statements.
The relationship between the two is additive, not competitive. Lineage maps the technical infrastructure. Provenance maps the evidential foundation. Together, they cover the full chain from source document to reported figure. Organizations that have invested in lineage and are still struggling with audit evidence gaps almost always have a provenance gap, not a lineage gap: they know how their data moves, but they cannot trace each figure back to the original document that authorized it.
For compliance teams evaluating tooling for regulatory examination readiness, the diagnostic question is simple: can you trace a specific figure in your last compliance attestation to the source document that supports it, and can you do that in under an hour? If the answer is no, or not reliably, the gap is in provenance. Lineage tooling may already be working exactly as designed. The missing layer is the one that starts where the data infrastructure ends, back at the original record.