Data Quality as an SLA

Every check covered so far in this module answers one question at one moment: did this expectation pass, right now? This article covers turning that single answer into a time series tracked over time — the same shift a service-level agreement represents for uptime, applied to the six dimensions Data Quality Fundamentals introduced.

A single pass/fail hides a slow decline#

A completeness check that passes today, passed yesterday, and passed the day before hides a null rate quietly climbing from 0.1% to 0.4% to 0.9% across those three runs — each individual run passes a loose threshold, while the trend itself is the actual problem. Recording each run's result as a point on a tracked metric, rather than discarding it the moment the check passes, is what makes that trend visible before it crosses a threshold and becomes an incident:

Day 1: null_rate = 0.1%  -> PASS (tracked)Day 2: null_rate = 0.4%  -> PASS (tracked)Day 3: null_rate = 0.9%  -> PASS (tracked)                             ... trend visible only across the three points,                                 invisible in any single day's pass/fail

Not every violation deserves the same response#

Treating every failed expectation identically forces an uncomfortable choice: block the pipeline on everything, and a minor, low-stakes violation halts real work; or block on nothing, and quality checks become decorative, logged and ignored. A deliberate two-tier response avoids both:

• Hard failure — stop the pipeline. Reserved for violations that make downstream data actively wrong or dangerous to use: a row count of zero where thousands were expected, a primary key suddenly containing duplicates.
• Soft failure — log and alert, let the pipeline continue. For violations worth a human's attention but not severe enough to block real work waiting on the data: a null rate elevated but still low, a statistical anomaly from Statistical Methods for Anomaly Detection that could be a real problem or could be legitimate variation.

Setting the target requires the consumer, not just the producer#

A completeness target of "99% of rows have a customer_id" is only meaningful relative to what the data is actually used for — a downstream consumer running financial reporting may need a target far stricter than one producer would set in isolation. The same ownership principle Data Contracts covers for the contract itself applies to the SLA built on top of it: the target should reflect what actual consumers need, negotiated with the producer who has to meet it — not a number the producer alone picked because it seemed reasonable.

Common mistakes#

No tier distinction between failures#

Every violation treated as a hard stop makes the pipeline too fragile to run reliably; every violation treated as a soft log makes quality checks functionally invisible. Both extremes come from skipping the deliberate severity decision this article covers.

Discarding check results instead of tracking them as a trend#

A pass/fail check whose result is not recorded anywhere durable cannot reveal a slow decline — only a sudden, threshold-crossing failure. The value of tracking quality "as an SLA" is specifically in the trend a recorded history makes visible.

Setting quality targets without input from who actually depends on the data#

A target set unilaterally by the producer, without asking what consumers actually need, tends to be either needlessly strict (blocking real work over violations nobody downstream cares about) or too loose (missing problems that matter to a specific, unconsulted consumer).

Further reading#

• Service-level agreement — the general concept a data quality SLA is modeled on.
• Root-cause analysis — the practice a hard-failure violation should trigger immediately.
• Data Contracts — the agreement a quality SLA's targets are typically drawn from.
• Statistical Methods for Anomaly Detection — the technique behind many of the soft-failure checks this article's severity tiers apply to.

See also#