Part 3 · Working with the data · 4 of 6
Data Quality Dimensions (and how to write an SLO)
Six dimensions — completeness, uniqueness, timeliness, consistency, validity, accuracy — each becomes an SLO once you name the measurement, threshold, and check time.
1 min read
A data product's SLOs are promises about the data, not about the pipeline. The classic six dimensions give you the vocabulary:
| Dimension | Question | Example SLO at Meridian |
|---|---|---|
| Completeness | Are required values present? | 100% of closed deals have a closed_date |
| Uniqueness | Is each real-world event recorded once? | No two transactions share (deal, amount, date) |
| Timeliness (freshness) | Is the data recent enough? | Latest successful deals load < 24h old at 09:00 |
| Consistency | Do two representations agree? | deals.stage equals the latest deal_stage_history row |
| Validity | Do values conform to rules? | stage ∈ the six allowed values; amount > 0 |
| Accuracy | Does the value match reality? | Bookings reconcile to signed contracts (sampled) |
Writing an SLO that can actually be checked
An SLO has three parts: the measurement (a query), the threshold, and
when it is evaluated. "The pipeline runs at 02:00" is a schedule. "The
latest successful run is never more than 24 hours old at 09:00, measured
from pipeline_runs" is an SLO.
Why "success" is not enough
A run can succeed and still ingest a partial file (row count drops 70%), re-ingest yesterday's file (duplicates), or land on time with stale upstream data. Every one of those is invisible to a status column and visible to a data check. That's the difference between pipeline observability (did it run?) and data quality (is it right?).
Source: Synthesized for DPM Lab from common data-quality practice; ties to the Playbook's Activation week.
Where this shows up