Data lineage:
how to audit the path of every piece of data in the company

Data lineage records origin, transformation and consumption

Data lineage is the record of where a piece of data came from, which transformations it went through and where it is consumed. It describes the path of a value from the source system, through loads, joins, calculations and aggregations, to the report, dashboard or application that displays it.

The record can have two levels of detail. At table level, it shows that the monthly revenue table is fed by the ERP invoices table and the CRM contracts table. At column level, it shows that the net revenue field is calculated from the invoiced amount, the discount and the cancellation, each coming from a specific column. Column level costs more to maintain, and it is what answers questions about a single field.

There are efforts to standardise this record across tools. The OpenLineage open specification, hosted by the LF AI & Data Foundation, describes lineage with three entities: jobs, the runs of each job and the datasets they consume and produce.

Impact, quality and LGPD are the traditional uses of data lineage

Before AI, data lineage already solved four recurring problems:

• Impact analysis: before renaming or removing a column, engineering checks which transformations, dashboards and integrations depend on it. Without that record, the schema change in the orders table is discovered when the revenue dashboard shows up empty at the Monday meeting.
• Quality: when a number looks wrong, the path back shows the step where the error came in, whether a late load or a changed filter.
• Compliance: audits ask for the origin of reported entries and indicators, and the record documents that path without depending on whoever built the spreadsheet.
• LGPD: the law requires knowing which personal data the company processes and for what purpose. Lineage shows which tables, reports and systems a data subject's taxpayer ID (CPF) or email was copied to, which is the basis for handling an access or deletion request.

A model's answer also needs data lineage

An AI-generated answer is one more point where data is consumed. It has an origin and transformations like any report, with two new elements: the interpretation of the question and the choice of context sent to the model.

To be auditable, the data lineage of an answer needs to record:

1. which records were queried, with identifier and date;
2. which definition was applied to each term in the question, such as the recurring revenue criterion;
3. which system each piece of information came from;
4. which permission the query ran under, that is, on whose behalf.

Answers without a source stall approval in finance and legal

In the areas where every number becomes a decision or an obligation, an answer with no path back gets stuck in validation. The controller's office does not close the month with a figure it cannot reconcile with the ERP. Legal does not quote a clause without knowing which version of the contract it came from.

This is one of the reasons AI pilots in these areas stop before production. The answer may even be correct, and nobody can demonstrate it. Checking each answer by hand eats up the time the pilot was supposed to free.

The Company Brain records the origin of every piece of information served over MCP

In the Company Brain, lineage follows the context from the moment the sources are connected. Each entity in the knowledge graph keeps the source records that make it up. Each term resolved by the business ontology points to the definition used. The semantic layer records how the question was translated into a query.

When context is served to the model over MCP, each piece of information carries the reference to the system and the record it came from, and the query runs with the permission inherited from whoever asked. The answer can be reconstructed later with the same question, the same definitions and the same records, as of the date it was given.

The same record serves impact analysis. If the discount column is renamed in the ERP, lineage shows which definitions, recurring questions and agents depend on it before the change reaches production.

Data lineage depends on maintained metadata

Data lineage is only as complete as the metadata that feeds it. Transformations done in local spreadsheets, unversioned scripts or manual processes stay out of the record, and the path shows gaps.

Legacy systems without a change log impose another limit. It is possible to record which table the data was read from and when, and it is not always possible to know who changed the value at the source and why. In those cases, the record goes as far as the system allows and leaves the gap visible to the auditor.

Useful data lineage starts with one critical question

Mapping the lineage of all the company's data before putting it to use tends to stall the project. The practical starting point is a question that needs to be auditable today, such as the quarter's recognised revenue or the contractual deadline of a strategic customer.

That question defines the sources, definitions and transformations that need to be recorded from day one. Each following question reuses the path already mapped, and the team in charge can check the origin of every answer without redoing the query by hand.