We track where data came from and what was done to it at the level of the business concept it represents, not only at the level of the table and column that happened to hold it.
Lineage that stops at the column
Most lineage tools answer the question “which columns fed this column”. That is necessary and it is not sufficient. A regulator, an auditor or an analyst asks a different question: where did this figure for revenue come from, and what did each step assume. The column answer has to be translated by a person who knows what the columns mean.
Lineage that carries meaning
When every source is mapped to a shared model, the mapping itself is lineage. A concept in the model knows which sources instantiate it and by which transformation. We record those transformations as first-class objects, so the path from a reported figure back to its inputs is a path through concepts, readable without knowing the names of the underlying tables.
Federated querying without copying
Because the model describes sources rather than replacing them, queries can be federated: a single query against the model is decomposed into queries against the systems that hold the data, and the results are assembled under the concepts that were asked for. Data stays where it is governed, and the lineage of the answer is the lineage of its parts.
Governance at the same level
Semantic governance follows. A retention rule, a classification or an access policy is stated about a concept, and the lineage tells you every source, transformation and consumer it reaches. Your governance is then enforced where the data actually flows, not where a diagram said it did.
