When someone asks where a number comes from and nobody can answer on the spot, the problem is not the dashboard: it is that the organisation has never recorded the path the data took. A catalogue says what exists; lineage says where it came from and what depends on it.
What follows: what each one solves, what automates, what still requires judgement, and how to build them without stopping the operation.
The scene repeats in every steering meeting. A figure appears, someone questions it, and the meeting stalls while the technical team tries to reconstruct how it was calculated.
The expensive part is not the minute of doubt. It is that from then on the figure sits under suspicion, and the rest of the dashboard with it.
What a catalogue solves
A data catalogue answers what exists and what it means. It is the inventory of tables, fields and indicators with their business definition, their owner and their sensitivity level.
Its value appears before any analysis: it stops three areas building three versions of the same indicator because none of them knew another already had it.
It is also where the agreed definition lives. When “active customer” means different things in sales and in finance, the catalogue is where that difference is made explicit instead of being argued every quarter.
What lineage solves
Lineage answers where a piece of data came from and what breaks if it changes. It traces the path from the source system, through each transformation, to the indicator somebody reads.
It serves two very concrete purposes. The first is answering the steering-meeting question in seconds rather than days.
The second is assessing impact before a change: knowing which dashboards depend on a field before modifying it avoids the familiar pattern of breaking three reports to fix one.
What automates well
Technical capture of lineage. Modern data platforms record the transformations they execute, so much of the path can be built by reading the processes’ own code rather than documenting it by hand.
Detecting structural change. Warning when a field appears or disappears in the source is a repetitive check, and it is the one that prevents silent failures downstream.
Profiling. Periodically calculating how many nulls, how many distinct values and what range each field holds produces an X-ray that maintains itself.
Detecting duplicate indicators. Finding near-identical calculations under different names is a good first finding, because it shows the cost of having no catalogue.
What requires judgement
The business definition does not automate. Whether “sale” includes returns, and with what cut-off, is an agreement between areas that someone has to convene and sustain.
Nor does assigning owners. A catalogue with no owner per domain becomes an inventory that ages — technically correct and without authority.
And there is an uncomfortable decision worth taking early: what gets catalogued first. Cataloguing everything is a project that never ends; cataloguing what supports the steering committee’s decisions delivers value in weeks.
How to build it without stopping the operation
Start with the indicators already being argued about. They are few, they matter, and their ambiguity has a visible cost, so agreement on their definition comes quickly.
Build the lineage of those indicators backwards, not from the sources forwards. The reverse route reaches the useful result sooner and discards everything nobody consumes along the way.
Publish what you build where people already work. A catalogue that requires opening another tool gets consulted for the first few weeks and then does not.
What has to exist first
An owner per data domain and a minimum agreement about which indicators are in common use. With those, catalogue and lineage are an exercise in incremental construction.
It is also worth treating sensitivity as part of the catalogue from the start: marking which fields hold personal data, with the obligations of Habeas Data (Ley 1581) in Colombia and of the LFPDPPP in Mexico, avoids having to walk the inventory twice.
Which questions it must be able to answer
The test of whether catalogue and lineage are working is not their completeness, it is whether they answer quickly the questions that currently stop a meeting.
Where does this number come from? It must be traceable from the indicator back to the source system, naming each transformation along the way.
Who is accountable for this definition? Every indicator in common use needs a person who can explain why it is calculated that way and authorise a change.
What breaks if I modify this field? The question that prevents the incident. Without lineage it is answered by deploying and waiting; with lineage it is answered beforehand.
Is this data sensitive? Marking which fields hold personal data changes who may query them and how they must be handled, and it is cheaper to record while cataloguing than to discover later.
If those four are answered in minutes, the catalogue is doing its job even if it covers only part of the data estate.
Are a catalogue and lineage the same thing?
No. The catalogue says what exists and what it means; lineage says where it came from and what depends on it. They complement each other and are usually built together.
Does everything have to be catalogued?
It is not advisable. Cataloguing everything is a project without an end. Cataloguing the indicators already argued about in committee delivers value in weeks and defines the scope by itself.
Can lineage be built automatically?
Much of it, yes, by reading the transformations the data platforms themselves execute. What does not automate is the business definition or the assignment of owners.
Which signal indicates one is needed?
A meeting stopping to work out how a figure was calculated, or several versions of the same indicator coexisting under different names.
