Your lineage coverage metric measures the wrong thing

Why data governance programs fail

Coverage measures effort, not use

Every data governance program reports lineage progress the same way: systems connected, fields mapped, critical data elements covered, and a completion percentage. For the most part, those figures are usually accurate, and they answer a question nobody outside the program is asking. A lineage map covering 40 percent of your enterprise data, or 90 percent, tells you what the team was focused on. Unfortunately, the coverage metric says nothing about whether the organization or an auditor can trace a figure back through your data landscape to its origin.

So, how do you know where you’re at? Take something a person outside the governance team asks regularly, and watch whether they can answer it themselves. If the answer routes back through the specialists who built the lineage model, the program produced documentation rather than infrastructure, and that documentation begins describing a data environment that no longer exists as soon as the systems underneath it change.

Enterprises whose lineage outlived the governance program that paid for it did not map more than everyone else. They built for readers rather than for auditors, designing the record so someone who had never attended a program meeting could still get an answer out of it. Then they made contributing to it safe enough that those same people could be trusted with write access. Both decisions were made early, and neither shows up in a coverage report.

Why lineage models end up readable only by their authors

Data lineage work gets funded to address something specific: a supervisory finding, a BCBS 239 remediation plan, or an audit action with a date attached. That obligation sets the scope, so the map stops where the examiner who raised it stopped caring. The people who build it are specialists hired to trace transformations, which is a different skill from explaining one to a business analyst, and what they produce is written to be defended once to an audience that already speaks its vocabulary.

In most initiatives, what comes out is a record expressed in the language of the systems rather than the language of the questions people bring to it. A risk analyst wanting to know which reports depend on a counterparty rating field first needs that question rendered into table and column names, and the colleagues who can perform the translation are the ones the governance program is about to release. From the regulatory side, the fact that BCBS 239 evidence gets rebuilt every examination cycle leads to the observation that compliance evidence assembled to answer one supervisory question rarely stretches to the next.

Gartner’s framing of the governance operating model points at the operational half of the same problem. Its July 2026 note on governance building blocks argues that governance scales only where it operates at runtime, embedded in the platforms and pipelines where data moves, rather than depending on manual escalation.¹ A lineage model that needs a specialist intermediary for every question is manual escalation with a diagram attached.

What someone outside the program needs before they can use it

Access is the easy part. A business user who opens a lineage map and finds three thousand tables has been handed something they still cannot use, and no amount of additional permission changes that. Two things have to be true first, and neither of them is a setting.

The lineage model has to answer in the language the question was asked in. Someone investigating a customer address field, a counterparty exposure, or a data retention obligation is asking about a business concept, and no system stores a column under that name. The argument for holding business meaning alongside the technical record is usually made on governance grounds, and it is just as much an adoption argument. Where the model holds only physical structure, every question becomes a translation job queued for a specialist. Where it holds business meaning alongside the physical path, the person with the question starts from the concept they already understand and follows it down to the fields that carry it.

People outside the program also have to be able to change the lineage model without breaking it for everyone else. Editing in place makes every change a risk to someone else’s work, and the governance team responds the way any team responds to that risk, by taking write access back. Solidatus handles this the way engineering teams handle shared code: a change is branched from the live model, compared against it, reviewed by whoever owns the affected area, and merged once accepted. Someone can model a proposed change in a sandbox and show its downstream consequences before anyone commits to it. That workflow is what makes a wide user base compatible with a model people can still trust.

HSBC’s wholesale credit and lending build runs at that scale. More than 500 internal users hold self-service access, and the model governs and maintains over 200,000 transitions.² Those two numbers depend on each other. Open editing across 500 people would degrade the record faster than anyone could repair it, and routing all 500 through the modeling team would have capped the user count in the low dozens.

Curation is a standing job

A lineage model that only grows fails in a way no coverage statistic reports. Someone asks which system is authoritative for customer address, receives twelve plausible answers, picks one, and builds a regulatory report on it. Volume without editing produces confident wrong answers, and for a risk function that is worse than receiving no answer at all.

HSBC’s program treats reduction as continuing work rather than a tidy-up before an audit. Alongside the mapping, the team set a target of cutting published data assets across credit lending processes from around 10,000 down to 200.³ That editorial judgment never stops. Someone has to decide what counts as authoritative and retire what duplicates it, so the published set stays small enough for a non-specialist to reach the right answer first.

A global asset management firm pointed the same discipline at a transformation instead of a regulator. Its multiyear program moved investment processes off spreadsheets and brought certain asset types in-house, and the lineage model became the reference for the migration. Time to decision fell from months to minutes, and the firm attributes a 60 percent cost reduction to the manual work it removed.⁴

“Solidatus is the control center from which our entire migration strategy stems – it visualizes our dependencies, reflects build status, eliminates end-to-end failures, and supports change management planning in many areas.”

— Senior Director, global asset management firm

Notice the phrase: control center. Nobody reaches for that language to describe documentation, and the distinction is not cosmetic: a control center is something an operator sits at while the work is happening, which means the model was being read during the migration rather than written up afterward.

The second use case is the real proof

No executive funds a second initiative on a record the first one found unusable, which makes expansion the clearest outside evidence that a lineage model became operational. When an engagement closes, and nothing else is ever built on what it produced, that silence is a verdict.

HSBC started in wholesale credit and lending. The lineage model then extended into environmental, social, and governance reporting, liquidity calculations, and risk-weighted asset optimization.⁵ Those are different owners, different regulators, and different reporting cycles reading one model. None of them commissioned the original work, and none would have adopted something that required the credit and lending team’s help to interpret.

The same pattern appears well outside compliance. A tier 1 global investment bank used Solidatus to consolidate regional daily batches into a single global 24×6 batch, working across several thousand commands and tens of thousands of interdependencies. The same planning had been attempted in spreadsheets first, where estimated effort had already passed six person-months before the bank changed approach.⁶ Batch scheduling answers to no regulator and was never in scope for the governance program, which is what makes it the more useful example. A team with no stake in why the model was built reached for it anyway.

Where to start

Five moves separate a governance program that ends from one that keeps running.

1. Instrument usage rather than coverage: Count the people outside the governance team who queried the lineage model last month. A flat number is the finding, whatever the completion percentage says.
2. Run the unaided test: Take one question a non-specialist asks regularly and watch whether the business-meaning layer carries them from the concept to the fields holding it without a specialist in the middle.
3. Move contribution to propose, review, and merge before widening access: Branching a change, comparing it against the live model, and having the affected owner accept it is what lets a governance team say yes to a larger user base.
4. Name the standing owner while the program still has a budget: Ownership assigned after a team disbands is ownership nobody accepted.
5. Audit decay against a version, not against memory: Compare the model as it stands today with the version from the end of the last program, and read the difference as your maintenance bill.

The number worth watching

The coverage figure is not useless. It answers a fair question about how far the program got, and a steering committee is right to ask for it. It stops being the interesting number the moment the program ends, because from that point what matters is whether the lineage model survives being used by people who never sat in a single program meeting. Count those people. A climbing number means the next regulatory program will cost a fraction of the last one, and a flat number means a rebuild is coming, already sitting on the budget for a year nobody has named yet.

If your lineage is mapped and nobody outside the governance team is using it, that is the conversation to have.   Request a Solidatus demo, and we can walk through what an implementation roadmap looks like for your environment.