How to Set Up Data Quality Checks in a Lakehouse

A pipeline that crashes is annoying but safe — you know something is wrong. The dangerous failure is the one that succeeds: the load runs, the report refreshes, and the numbers are wrong. A SKU changed pack size and the volume calculation is now nonsense; a source sent nulls where quantities should be; a duplicate doubled a total. Nothing errored. The dashboard is green and lying.

This is how a lakehouse loses trust. Not in a dramatic outage, but in a slow accumulation of quietly-wrong numbers that someone eventually notices, after which they stop trusting the platform and go back to their spreadsheet. The whole value of a governed lakehouse — one number everyone trusts — evaporates the first time it is confidently wrong.

Data quality checks are what prevent the quiet failure. They are not optional polish; they are what makes the trusted single source of truth actually trustworthy.

The common mistake is to bolt one big validation step at the end, just before the data reaches Power BI. By then the bad data has flowed through every transformation, and finding it there tells you something is wrong without telling you where it entered. Checks belong at each layer of the medallion architecture, catching problems where they originate.

At the bronze layer (raw ingestion), check that the data arrived at all and matches its expected schema — the right columns, the right types, a plausible row count. At the silver layer (cleaned and joined), check the content: nulls where there should be values, out-of-range numbers, broken relationships, duplicates. At the gold layer (business-ready), check the business rules and reconciliation: does the total reconcile to the source system, does a governed metric fall in a sane range.

Layering the checks means a failure is caught early and located precisely. A schema break is caught at bronze before it corrupts anything downstream; a reconciliation break is caught at gold before it reaches a report. Each layer defends the next.

The useful checks fall into a handful of categories, and covering them is more valuable than any single sophisticated test. Schema checks: the data has the expected structure, columns and types. Completeness checks: required fields are not null, and the row count is in a plausible range (a load that returns ten rows when it usually returns ten thousand is a failure even if those ten rows are perfect).

Validity checks: values fall in sensible ranges (a negative quantity, a date in the future, a temperature outside physical bounds are all flags). Referential checks: keys resolve — every order references a real customer, every transaction a real SKU — so a join does not silently drop or duplicate rows. Uniqueness checks: no unexpected duplicates that would double a total. And freshness checks: the data is as recent as it should be, so a stalled feed is caught rather than silently serving yesterday.

Covering these categories at the appropriate layer catches the large majority of real-world data quality failures. They are not exotic; they are the systematic version of the sanity checks a good analyst does by eye, applied automatically at every load.

A check that finds a problem has to do something, and the right response differs by check. Some failures should stop the data: a schema break or a reconciliation failure at gold means the data is not safe to serve, so the batch is quarantined — held out of the gold layer, not published — and someone is alerted. Better a delayed report than a wrong one.

Other failures should flag but not block: a small number of nulls in a non-critical field, a freshness warning on a secondary source. These raise an alert and are recorded, but the load proceeds, because stopping everything for a minor issue creates its own problem. The decision — quarantine or alert — is made per check based on how dangerous that failure is.

What matters is that the decision is deliberate. The failure mode to avoid is checks that detect problems and do nothing, or checks that block everything so aggressively that people disable them. Each check should have a defined action proportionate to the risk, so the system fails safe without failing constantly.

Checks that run silently are half a system. Data quality should be a visible, monitored metric in its own right — a view of which checks passed and failed, on which loads, trending over time. This turns quality from an invisible background process into something someone watches and owns.

The value of monitoring is that it catches degradation before it becomes a crisis. A source that is slowly getting worse — more nulls each week, freshness slipping — shows up as a trend before it produces a visibly wrong report. And when a stakeholder asks "can I trust this number," a quality dashboard is the honest answer: here is what we check, here is the current state.

This also needs an owner — the data platform engineer or model owner whose job includes watching the quality metrics and acting on failures. A check with no owner is a log nobody reads. Monitoring plus ownership is what makes the quality system a living defence rather than a box that was ticked at build time.

Setting up data quality in a lakehouse is a discipline, not a tool: checks at each medallion layer (schema at bronze, content at silver, business rules and reconciliation at gold); coverage of the categories that matter (schema, completeness, validity, referential, uniqueness, freshness); a deliberate quarantine-or-alert action per check; and quality monitored as a first-class metric with a named owner.

Built this way, bad data is caught where it enters, before it reaches a report someone trusts — and the lakehouse earns the "single source of truth" claim rather than quietly undermining it. The alternative is the confident wrong number that erodes trust in the whole platform.

On Microsoft Fabric this is implemented with the platform's own pipeline, notebook and monitoring capabilities, and where a team wants engineering-grade testing discipline, a transformation-testing tool can formalise it. But the tooling is secondary. The discipline — test at each layer, fail safe, monitor, own — is what keeps the lakehouse trustworthy.