Designing a Lineage Coverage Dashboard

Part of: Lineage Visualization and Reporting

Coverage is the meta-question: not what the lineage says, but how much of the estate it says anything about. A dashboard answering it is the artefact that tells a data manager whether the lineage programme is working, and it is the one most often built as a wall of gauges that measures activity instead. This how-to designs a coverage dashboard around a small number of quantities that actually move, and states plainly which popular metrics are worse than useless.

The distinction that organises the whole thing: coverage is not completeness of records, it is completeness of answers. A store with a lineage row for every dataset and no derivation edges has one hundred percent record coverage and answers no question at all.

Prerequisites

  • An inventory of datasets that is independent of the lineage store, per Lineage Visualization and Reporting.
  • The ability to run each canonical query against every dataset.
  • Historical snapshots, or the willingness to start collecting them.
  • An agreed definition of what “covered” means, written down.

Measure Answerability, Not Record Counts

The metric worth putting at the top is the proportion of datasets for which the canonical questions can actually be answered.

Coverage measured as a funnel of answerability Having a record is nearly universal; having an ancestry that resolves all the way to a declared source is far rarer, and that is the metric worth reporting. has any lineage record — 98% has at least one derivation edge — 76% ancestry resolves to a declared source — 44% quality evidence too — 21% The top bar is the number that gets reported upward. The third is the one that means something.

The caption names the failure this dashboard exists to prevent. Ninety-eight percent coverage is a true statement about record existence and a false impression about capability, and it is the number that gets into a board pack unless the funnel is shown.

Define “resolves to a declared source” precisely and put the definition on the dashboard. It usually means every path from the dataset terminates at an entity marked as an origin, with no unexplained dead ends. Ambiguity here means the number changes when somebody reimplements the check.

Report the funnel, not just its narrowest bar. The gaps between the bars are where the work is: a large drop between edges and resolution means chains are truncated, while a large drop between resolution and quality means the pipeline is not attaching metrics.

Three Metrics That Look Good and Measure Nothing

Naming these explicitly saves an argument later, because each one gets proposed at every review.

Total lineage records. It goes up forever and it goes up fastest when something is emitting duplicates. A rising count is compatible with declining coverage.

Events per day. It measures pipeline volume, which is a property of the workload rather than of the lineage programme. A quiet week looks like a regression.

Average chain depth. Deeper is neither better nor worse, and the average moves when someone adds an intermediate step for unrelated reasons. It sounds meaningful and directs no action.

Put them on a secondary page if their absence causes friction, clearly separated from the metrics that drive decisions. Deleting them outright usually costs more political capital than parking them.

Break Coverage Down by Something Actionable

An aggregate percentage tells you the size of the problem and nothing about where to start.

Coverage by owning team points at the work The same overall figure decomposed by team, revealing that one large group accounts for most of the gap. TEAM DATASETS RESOLVED GAP Cadastral 64 91% 6 Transport 38 85% 6 Environment 210 25% 158 Imagery 44 79% 9 One team holds 158 of the 179 uncovered datasets. That is a conversation with one group, not an organisation-wide programme.

Sort by absolute gap rather than by percentage. A team at twenty-five percent with two hundred datasets matters more than one at forty percent with five, and a percentage-sorted table hides that inversion completely.

Break down by owning team where the goal is to assign work, and by pipeline where the goal is to fix instrumentation. Those are different dashboards for different meetings and squeezing both into one produces a table nobody can read.

Avoid breaking down by more than one dimension at a time. A team-by-pipeline matrix has a hundred cells, most of them empty, and it stops being a summary.

Trend Beats Level

A coverage figure on its own supports no decision, because nobody knows whether it is good.

Show the last twelve months on every headline metric. Forty-four percent is discouraging in isolation and excellent if it was eleven percent in January, and the direction is the only part anybody can act on.

Annotate the line with what happened. A step change is always caused by something — a pipeline instrumented, a bulk import, a definition change — and an unannotated step will be attributed to whatever the reader already believed.

Distinguish a rise from a denominator change. Coverage that improved because two hundred uninstrumented datasets were retired is a different fact from coverage that improved because they were instrumented, and both look identical on the line.

Set a target and draw it. A trend without a target is a chart; with one it is a plan, and the gap between the line and the target is what gets discussed.

Show Where the Chains Break

Coverage percentages say how much is missing; a breakdown of why says what to build next.

Why chains fail to resolve Four distinct causes of an unresolved chain, each needing a different remedy, with the count attributable to each. WHY IT DOES NOT RESOLVE COUNT REMEDY no derivation edges at all 92 instrument the pipeline chain ends at an undeclared entity 44 declare it, or extend the chain manual step with no record 29 a process fix, not a code fix external source, no agreement 14 accept and declare the boundary

The bottom row is a legitimate terminal state rather than a defect, and separating it out prevents a permanently unreachable target. A source outside your organisation with no lineage agreement is a declared trust boundary, and chains ending there should be counted as resolved once that declaration exists.

The manual-step row is the one that never gets fixed by engineering effort, and reporting it separately is what routes it to the person who can change the process instead.

Order the remedies by the count they would move. Ninety-two datasets fixed by instrumenting one pipeline is a better first quarter than twenty-nine addressed one conversation at a time.

Re-derive these counts on every snapshot rather than maintaining them, so the categories cannot drift out of agreement with the coverage figure they decompose.

Verification

Assert the denominator against the independent inventory. A dashboard that counts only datasets the lineage store knows about reports one hundred percent coverage by construction, and this is the single most common way these dashboards lie.

Assert the resolution check with a fixture chain that dead-ends, confirming it is counted as unresolved. A check that has never returned unresolved is not checking.

Assert historical snapshots are immutable. A trend recomputed from current data under a changed definition rewrites history and hides the step change the annotation was explaining.

Assert the breakdown sums to the total. Datasets with no owner commonly vanish from a team breakdown, and they are exactly the population most likely to be uncovered.

Gotchas & edge cases

  • Coverage is not quality. A dataset with a complete, resolvable, fully instrumented chain that records three bad transformations counts as covered, and should. Conflating the two produces a dashboard that goes red for reasons it cannot explain and gives its owner no lever to move.
  • Retired datasets distort everything. Decide whether they count and apply it consistently in both numerator and denominator; a mixed treatment makes coverage improve every time something is deleted.
  • Definition changes need a version marker. Tightening what “resolved” means causes a drop that looks like a regression. Stamp the definition version on every snapshot.
  • Sampling beats a partial census. Where running the resolution check across the whole estate is too expensive, a random sample of two hundred datasets gives a defensible figure with a stated confidence interval, and it gives it weekly rather than quarterly. A census of the easy half gives a number that is precisely wrong.
  • A dashboard is not a report. It shows state to whoever comes looking; it does not tell anyone something has changed. Pair it with a push notification on threshold crossings.
  • Coverage of the trivial cases inflates the figure. Datasets that are terminal sources trivially resolve, and an estate full of them looks well covered. Report derived datasets separately.
  • The dashboard measures the measurer. Every figure on it comes from the lineage store, so an outage or a schema change moves the numbers without anything changing in the estate. Show the collection timestamp and the record count the snapshot was built from, so an anomalous reading can be attributed before it is investigated.
  • Targets need an owner as well as a value. A coverage target with no named accountable person is a wish, and it will still be on the dashboard, unmet, a year later.
  • Nobody checks a dashboard that is always green. If everything is above target, either the targets are too low or the dashboard has stopped measuring something that can fail.