Provable data quality

Statement

Data quality must be explicitly defined and provable through testing

What this means in practice

Quality expectations are declared up front for each data set based on its intended business use. These expectations are expressed as measurable criteria -- completeness, timeliness, validity, uniqueness -- and are tested automatically. Data does not need to be perfect in the abstract; it needs to be good enough and trustworthy for the specific use case it serves, with quality thresholds that are explicit and testable.

Why this matters

Vague commitments to "good data" are unenforceable and erode confidence. Defining quality in measurable terms allows teams to detect degradation early, demonstrate compliance, and make informed trade-offs. Fitness-for-purpose quality prevents over-engineering for low-risk data whilst ensuring high-value data meets the standard it demands.

Practices that meet this principle

• Define data quality dimensions and acceptance thresholds per data set during solution design

• Implement automated quality checks that run on ingestion, transformation, and delivery

• Surface quality metrics through dashboards or alerting so degradation is visible in near real time

• Include data quality validation in test suites alongside functional and integration tests

• Review and refine quality definitions periodically as business requirements evolve

• Document the expected quality profile for each data set alongside its schema

Validation

A project meets this principle when:

• Data quality criteria are documented with measurable thresholds for each data set

• Automated tests validate data against those criteria as part of the delivery pipeline

• OR:

• No data set is consumed downstream without a defined quality expectation