The 6 dimensions of data quality explained with real-world cases

Why distinguishing the dimensions matters

An overall quality rate of 94% can hide very different realities. A domain with 94% completeness and 100% accuracy has a manageable problem: there are empty fields that can be recovered. A domain with 100% completeness and 94% accuracy has a more serious problem: all fields have a value, but one in sixteen values is incorrect, and that is much harder to detect and correct.

The six data quality dimensions are the industry standard according to DAMA-DMBOK and the implicit reference of Article 10 of the AI Act when it requires that training data be "relevant, representative, free from errors and complete as far as possible." Each of those words points to a specific dimension.

1. Completeness: the most visible problem and the most ignored

Completeness measures whether all required values are present. It is the easiest dimension to detect automatically — a null field is a null field — and paradoxically one of the most ignored in quality programmes because it is perceived as a minor problem.

What it measures exactly

There are three levels of completeness. Field completeness measures what percentage of records have a value in a specific field. Record completeness measures what percentage of mandatory fields have a value in a specific record. Entity completeness measures whether all expected records for an entity exist.

Real-world impact cases

In an e-commerce system, 8% of order records have the shipping address field empty. The data is operationally correct during the checkout process because the address is extracted in real-time from the customer profile. But when that order is exported to the logistics system, which expects the address embedded in the record, 8% of orders fail silently.

How to measure it and what threshold to set

In dbt: not_null test per field. In Soda: missing_count and missing_percent. Threshold depends on the field: 100% for primary and foreign keys, ≥ 99% for critical business fields, ≥ 95% for optional relevant fields.

2. Accuracy: the most costly failure and the hardest to detect

Accuracy measures whether a data value correctly reflects the reality it purports to represent. It is the most critical dimension for decision quality and the hardest to measure automatically, because it requires knowing the reality to compare the data against.

What it measures exactly

A data item can be present, have the correct format and be technically valid and still be inaccurate. The weight recorded as 75 kg when the actual weight is 82 kg is complete, valid and exactly incorrect data.

Real-world impact cases

In an asset management system, the book value of a fixed asset is wrong in 3% of cases due to errors in manual depreciation entries. The balance sheets reconcile — because the errors offset each other in many cases — but per-asset profitability analysis is systematically wrong. The problem has sat in the system for years because no automated control catches it: the values fall within the expected range and have the correct format.

In a product recommendation model, user ratings carry an accuracy bias: a bug in the rating form inverted the scale for three weeks (5 stars was recorded as 1, and vice versa). The model trained on that data systematically recommends the worst-rated products as if they were the best.

How to measure it and what threshold to set

The most effective approach is validation against authorised sources: master reference tables, official records (tax ID, IBAN, postcodes) or designated record systems. For fields without an external source of truth, business rules (expected ranges, historical distributions) are the best approximation. Reference threshold: ≥ 98%.

3. Consistency: when the data says different things depending on where you look

Consistency measures whether a data item does not contradict other data in the same system or in related systems. It is the dimension that most frequently generates loss of trust in data, because its failures are visible in meetings: the same KPI gives different results depending on which system it is extracted from.

What it measures exactly

There are two types of inconsistencies. Internal inconsistencies occur within the same record: the country is "ES" but the telephone prefix is "+1", or the cancellation date is earlier than the creation date. External inconsistencies occur between systems: the CRM records 45,000 active customers, the billing system records 43,200 and the data warehouse shows 46,800.

Real-world impact cases

An airline calculates last month's passenger count three different ways depending on the system: the flight operations system counts boarded passengers, the revenue management system counts tickets sold, and the data warehouse aggregates both with a deduplication logic no one documented correctly. The leadership committee can't compare operational performance with commercial performance because the starting numbers are incompatible.

The root cause isn't technical — it's the absence of a canonical definition of "passenger carried" agreed between the owners of each system. That's exactly the job of the Data Steward and the Data Governance Committee.

How to measure it and what threshold to set

In dbt: relationships tests and custom SQL tests validating conditions between fields. In Great Expectations: expect_column_pair_values_to_be_equal for consistency between fields. Cross-system inconsistencies require cross-comparisons in the integration pipeline. Threshold: ≥ 99%.

4. Timeliness: correct data that arrives late is useless data

Timeliness measures whether the data is available when needed. It is the most frequently ignored dimension in quality programmes because it is perceived as an infrastructure problem, not a quality one. Mistake: timeliness is a quality dimension as relevant as accuracy in contexts where decisions depend on real-time data or very short time windows.

What it measures exactly

Timeliness has two aspects. Latency measures the time between when data changes in the source system and when it becomes available in the consuming system. Freshness measures whether the data in the consuming system corresponds to the current state of reality, not to a past state that's no longer relevant.

Real-world impact cases

In a distribution chain's inventory system, in-store stock is updated in the data warehouse every 4 hours. The e-commerce system queries the data warehouse to show real-time availability. During the 4 hours between updates, the system can confirm orders for products that are no longer available in store. The result is 2.3% of orders with an availability incident, handled manually at a cost of €12 per incident. Multiplied across order volume, the annual cost of that latency exceeds the cost of implementing real-time sync.

How to measure it and what threshold to set

Monitor the timestamp of the last update of each critical table and compare it with the agreed SLA. In dbt, a custom test that alerts if max(updated_at) < current_timestamp - interval 'X hours' is sufficient to detect update delays. Threshold depends on the domain: minutes for operational data, hours for analytical data, days for master data.

5. Validity: the rules the data must meet before it is useful

Validity measures whether a data value complies with the format, range and domain rules defined for that field. It is the easiest dimension to implement automatically and the one that shows fastest results in a quality programme starting from zero.

What it measures exactly

There are three types of validity rules. Format rules check that a value has the correct structure (an email with @, a tax ID with a valid check letter, a date that exists on the calendar). Range rules check that a value falls within acceptable limits (an age between 0 and 120, a percentage between 0 and 100). Domain rules check that a value belongs to an allowed set of values (an order status is one of the ones defined in the catalogue).

Real-world impact cases

In a patient management system, the date-of-birth field accepts future dates with no validation on the form. 0.7% of records have a date of birth later than today's date, which makes age calculations negative and causes age-group filters to exclude them from every analysis. In a healthcare context, systematically excluding those patients from analysis can distort clinical study results.

In a training dataset for a classification model, the product category field has 47 distinct values but the official catalogue only defines 12. The 35 extra values are typos, encoding errors, and deprecated categories that the model learns as if they were distinct categories, reducing its ability to generalize.

How to measure it and what threshold to set

In dbt: accepted_values, expression_is_true for ranges, regex tests with custom macros. In Great Expectations: expect_column_values_to_match_regex, expect_column_values_to_be_between. Reference threshold: ≥ 99.5% for critical business fields, 100% for keys and identifier fields.

6. Uniqueness: duplicates that cost more than they seem

Uniqueness measures whether there are duplicate records where there should not be. It is the quality problem with the highest direct economic impact and the one most frequently discovered late: when duplicates have been in the system for months or years and have contaminated analyses, models and decisions.

What it measures exactly

There are two types of duplicates. Exact duplicates are identical records, or records sharing the same unique identifier, appearing more than once — easy to detect with a SQL query. Fuzzy duplicates represent the same real-world entity with variations: "John A Smith," "J. A. Smith," and "JOHN SMITH" are three different records in the system representing the same person. Detecting them requires text-similarity algorithms.

Real-world impact cases

At a telecommunications company, migrating two separate CRMs after a merger produces 4.2% duplicate customers in the consolidated database. The sales team doesn't know this and assigns two different reps to the same customer. The customer gets two renewal calls on the same day, with different offers and different prices. The impact isn't just operational — it creates a customer experience that destroys trust and, in some cases, triggers a churn request.

In a recommendation model trained on purchase history, duplicate customers make the model over-weight their purchase patterns: a customer with three records has three times the training weight of a customer with a single record. The model learns to recommend products that duplicated customers like, not the actual customer base.

How to measure it and what threshold to set

For exact duplicates: unique test in dbt on the natural key. For fuzzy duplicates: tools like Splink (open source) or IBM MDM (enterprise) with Levenshtein or Jaro-Winkler algorithms. The exact duplicate threshold should be 0% for primary keys and < 0.5% for business attribute combinations.

Summary: the 6 dimensions at a glance

The dimension the AI Act adds: representativeness

The six standard dimensions cover data quality in operational and analytical environments. The AI Act implicitly adds a seventh dimension for training datasets: representativeness.

A dataset can be complete, accurate, consistent, timely, valid and duplicate-free and still train a biased model if it does not adequately represent the distribution of the population on which the system will operate in production. Article 10.4 of the AI Act requires taking into account "the necessary statistical characteristics, including the representation of the persons or groups on which the system will operate." Measuring and documenting that representativeness is a regulatory obligation.

Why the dimensions aren't independent

The most common mistake when implementing a data quality programme is treating each dimension in isolation. In practice, failures in one dimension can cause failures in others. A completeness problem — incomplete records — can cause a consistency problem if the empty field gets backfilled with the wrong default value downstream. A uniqueness problem — duplicates — can cause an accuracy problem if the deduplication process picks the wrong record as the master.

Root-cause analysis for any quality issue needs to look across all six dimensions, not just the one where the failure became visible. The symptom and the cause can live in different dimensions.

Conclusion: the dimensions are the vocabulary, not the solution

Knowing the six data quality dimensions lets you diagnose problems precisely, communicate them clearly, and measure their evolution objectively. But diagnosis isn't the solution.

Knowing that the Customer domain's duplicate rate is 3.2% doesn't fix the problem. What fixes it is understanding where those duplicates come from, what process generates them, what business rule should apply to identify the master record, and who has the authority to decide that rule. That's exactly the Data Governance conversation the technical team can't have on its own.

To learn how to measure these dimensions with concrete KPIs and actionable dashboards, see How to Measure Data Quality: KPIs, Thresholds, and Dashboards.

Checklist: assessing the 6 dimensions

• Completeness assessed across required fields, relevant fields, and relationships between entities.
• Accuracy validated against authorized sources or master reference tables.
• Consistency checked both within internal record rules and across related systems.
• Timeliness monitored with a per-domain SLA and active delay alerts.
• Validity implemented as code in the pipeline (format, range, allowed domain).
• Uniqueness verified on primary keys (0%) and on natural business keys.
• Representativeness analyzed for AI training datasets (AI Act Art. 10.4).
• Root-cause analysis documented whenever a failure in one dimension produces effects in others.

Frequently asked questions

Why does distinguishing data quality dimensions matter?

Different dimensions fail in different ways and require different fixes — a dataset can be highly complete but inaccurate, or highly accurate but inconsistent, so treating quality as one single measure hides where the real problem is.

What is completeness in data quality?

Completeness measures whether all the data that should be present actually is — missing fields or records are often the most visible data quality problem, and the most commonly ignored.

What is data accuracy, and why is it hard to detect?

Accuracy measures whether data correctly reflects reality; it is often the most costly failure because inaccurate-but-plausible-looking data can pass unnoticed through validation checks that only test format, not truth.

What is data consistency?

Consistency means the same piece of data shows the same value across every system where it appears — inconsistency shows up when different systems tell conflicting stories about the same entity.

What's the difference between validity and accuracy?

Validity measures whether a value complies with format and domain rules (a tax ID in the correct format). Accuracy measures whether the value reflects reality (that tax ID is actually correct for that person). Data can be valid but inaccurate, and format rules alone can never catch that.

How does data quality affect AI models?

A model learns from the patterns in its training data. Inaccurate data produces models that learn the wrong patterns. Representativeness problems produce models that don't generalize well. Duplicate data over-weights certain examples during training. The AI Act requires documenting the quality analysis of training datasets precisely for these reasons.