The minimum viable data quality suite is four checks

The data quality market sells ceilings: anomaly detection, ML-driven monitoring, lineage-aware root cause analysis. Fine products, some of them. But most teams shopping for a ceiling do not yet have a floor, and the floor is four checks that fit in a lunch break.

Freshness: did the data arrive, and is the newest timestamp recent? Volume: is today's row count within a sane band of the trailing average? Nulls: are the key columns still populated? Uniqueness: did the primary key stay a primary key? Every one is a scheduled query with a threshold and an alert. Together they catch the large majority of what actually pages a data team: the silent extract failure, the half-loaded file, the join that started fanning out.

The floor matters because quality failures compound with distance. A staleness bug caught at ingestion is a rerun; caught in a board deck, it is a credibility event. Regulated reporting makes the point sharply: a public financial reporting case study compresses a month-long manual close into a 15-minute auditable pipeline, an outcome that is only survivable because checks gate every stage. Auditable and unchecked do not coexist.

implementing the floor without a platform

Each check is a query and a threshold, so the entire suite fits in the transformation layer you already run. Freshness is a max(timestamp) compared against an expectation per table, and the expectation should come from the consumer, not the pipeline: "orders are queryable by 06:00" is a promise someone actually made. Volume is today's count against a trailing band; seven days of history is enough to start, and the band should be wide, because a narrow band on day one teaches the team to ignore the alert by day ten. Nulls and uniqueness are a single aggregate query each, scoped to the columns that money flows through.

Thresholds are the craft. Set them from the consumer's tolerance, not from statistical ambition, and revisit them when they page wrongly twice. An alert that fires without a human acting on it is not a check, it is noise with a timestamp, and noise is how quality suites die. The four-check floor stays alive precisely because it is small enough that every alert still means something.

Routing matters as much as detection. The alert goes to the team that can rerun the pipeline, with the table name, the expectation, and the observed value in the message. An alert that requires opening three tools to understand will be triaged tomorrow, and tomorrow is where data incidents grow up into board-deck incidents.

what the platforms actually add

Having reviewed several of the observability products, we can report what the invoice buys beyond the floor: scale (thousands of tables get checks without a human writing them), column-level anomaly detection (distributions drifting inside technically valid data), and lineage that turns "the dashboard is wrong" into "this upstream table broke at 09:14". These are real capabilities. They are also capabilities whose value depends on somebody having already established what normal looks like, which is what the four checks do, and why the platforms onboard best in teams that already ran a floor.

What no platform supplies is the conversation where a consumer states what they need and an engineer writes it down as a threshold. Products detect anomalies; only that conversation defines failures. Teams that skip it get a wall of statistically interesting observations and no way to rank them, which is the alert fatigue the products were supposed to cure.

the objection we hear, answered

The standard pushback on the four-check floor is that it is embarrassingly simple, and that a serious data organization should be doing something more sophisticated. Both halves are true and neither is an argument. Sophistication is a budget, and budgets should buy marginal coverage, not self-image. When we ask teams running the expensive platforms which alerts actually preceded their last five real incidents, the answer is almost always a freshness check or a volume check, occasionally a null spike, and once in a while something the anomaly model genuinely caught first. That last category exists and justifies the ceiling for estates large enough to amortize it. It does not justify skipping the floor, and it never justifies the pattern we review most often: a six-figure observability contract monitoring pipelines whose freshness promises were never written down in the first place. Simple checks with named owners embarrass no one. Dashboards that were wrong for a week do.

There is also a sequencing dividend that goes unmentioned in procurement. A quarter of running the four checks produces exactly the artifacts a platform rollout needs anyway: a list of tables that matter, thresholds a consumer has agreed to, and a routing sheet that says who acts on what. Teams that buy first spend their onboarding inventing those from scratch, inside a tool, at consulting rates.

verdict

Adopt the four checks this week, on the ten tables that feed money decisions. Evaluate platforms only after the basics have been boring for a quarter. Buying anomaly detection before freshness checks is buying a smoke detector for a house with no doors.