Data Platform & Analytics · Chapter 4 of 8
Data quality that is not a dashboard
Most quality programmes produce alerts nobody actions. This is about the small number of tests that earn their place.
The failure mode is familiar: hundreds of tests, thousands of alerts, and a team that has learned to ignore them — which means a real failure is now invisible inside the noise, exactly as with a badly tuned SIEM.
Four checks worth having on everything important
| Check | Catches | Why it earns its place |
|---|---|---|
| Freshness | The pipeline did not run | The single highest-value test. Most incidents are absence, not corruption |
| Volume | Row count outside the expected band | Catches partial loads, which are worse than failures because they look successful |
| Uniqueness on the key | Fan-out from an upstream change | Prevents silent double-counting, the hardest bug to notice |
| Null rate on required fields | A producer change | Usually the first symptom of a broken contract |
Almost everything beyond those four is either a business rule that belongs in the model or a test somebody added after an incident and nobody has revisited since.
The metric to report, and the one to avoid
Report: the proportion of incidents found by a check rather than by a human, and the median time from breakage to detection. Those tell you whether the programme works.
Avoid: number of tests, or test coverage. Both reward adding tests, which is the behaviour that produced the noise. A team with 900 tests and a 40% alert-to-action rate is worse off than one with 60 tests and a 90% rate.
Lineage is what makes an incident survivable
When something breaks at 07:00, the question is not what broke — it is what depends on it, so you know who to tell before they find out themselves. Column-level lineage turns a half-day of investigation into a query, and it is also the thing that lets you delete anything with confidence.