When data teams talk about data quality, they're usually referring to a few specific things: whether the data matches the source, whether required fields are populated, and whether the pipeline ran on time.
These are real concerns, and they're worth measuring. But they're a fraction of the full picture.
Data quality has more dimensions than most programs test, and the dimensions that tend to get skipped aren't minor edge cases. They're often the ones responsible for the most expensive incidents: data that looks correct but violates business rules, records that were consistent last month but have drifted since, relationships between entities that are quietly broken.
The commonly cited frameworks - accuracy, completeness, consistency, timeliness, validity - are a useful starting point. But even within those standard five dimensions, most teams only cover part of what each dimension actually requires.
And beyond those five, there are dimensions that matter in real data environments, such as uniqueness, referential integrity, standards compliance, data security, and precision — that don't appear on the standard list at all.
Understanding what's in and out of your current coverage is the first step toward a program that actually reflects your risk.
Why Quality Dimensions Matter More Than a Single Score
A single "data quality" metric can't tell you much more than a single vital sign tells a doctor. Blood pressure tells you something important. It tells you nothing about blood glucose, oxygen saturation, or kidney function. Each metric captures a distinct aspect, and each can fail independently.
Data quality works the same way. A dataset can be highly accurate but critically incomplete. It can be complete and accurate, but delivered too late to matter. It can pass every structural check but contains values that violate business rules, corrupting downstream calculations.
Different dimensions also require different tools, owners, and testing approaches. Some dimensions, such as validity and business rule compliance, are hard to automate without input from those who understand the business logic.
Others, like timeliness and completeness, can be fully automated but are often left to manual spot-checking. Understanding dimensions separately allows you to match the right approach to each one, rather than applying a uniform testing strategy to a non-uniform problem.
What the Standard Five Actually Cover
Accuracy
Accuracy is the most intuitive dimension: does the data correctly represent the real-world entity or event it describes?
An accurate transaction record reflects what actually happened — the right amount, the right account, the right timestamp. An inaccurate one contains errors introduced during capture, transformation, or transit. Accuracy testing typically works by comparison: the data in the warehouse is checked against the source system, a prior calculation, or an expected formula.
It's also the dimension most visible to business users — when a report shows the wrong total, they notice. That visibility is a large part of why accuracy tends to get the most testing attention: it's the dimension where failures are most legible to the people who have the loudest voice when something is wrong.
The important limitation: accuracy testing can only validate against a reference.
If the reference itself is wrong — a source system that has been capturing data incorrectly, a formula that was miscalculated from the start—accuracy testing passes the error through. And for data representing real-world events without a reliable external reference, "accurate" is genuinely difficult to verify solely through automated testing.
Completeness
Completeness measures whether all the data that should be present actually is. Not whether records are accurate, but whether they exist.
Completeness failures are uniquely dangerous because they're silent. A missing record doesn't cause an error — it causes an absence. A pipeline that drops 2% of transactions on every load produces no error messages, no alerts, no obvious indication that anything went wrong. It just consistently undercounts, and the undercount becomes the baseline.
Three forms of completeness matter:
Column completeness: required fields are populated. Nulls in key fields propagate silently into aggregations and reports.
Record completeness: every record that should exist does exist. If your daily orders table consistently has fewer records than your source system, something is being dropped in transit.
Partition completeness: for time-partitioned data, every expected time period is present. A missing day's partition produces no error; queries against it return empty results, not incorrect ones.
Consistency
Consistency measures whether data is coherent across the contexts in which it should agree. This dimension has several distinct subtypes, and conflating them leads to coverage gaps.
Cross-system consistency is the most familiar: does the data in your warehouse match the data in the source systems that fed it? Finance sees one revenue figure; operations sees another. Both systems may be internally accurate — the failure is that they don't agree. This is the root cause of most "the numbers don't match" conversations.
Internal record consistency validates that values within a single record are logically coherent. A shipment date before its order date, an employee termination date before their hire date, an invoice where the paid amount exceeds the total — these are consistency failures that accuracy checks don't catch, because each individual value may be technically correct.
Temporal consistency validates that data is consistent with its own history, that values haven't shifted in ways that can't be explained by real changes in the underlying entity. Unexpected changes in dimensions that should be stable, or distributions that shift without a corresponding business event, are temporal consistency signals. This is the most commonly used consistency type for detecting silent drift in long-running pipelines.
Timeliness
Timeliness measures whether data is available when needed and whether it reflects the correct point in time.
A dataset can be accurate, complete, and consistent, and still be useless if it arrives after the decision it was meant to inform has already been made.
Freshness failures: data that hasn't been updated when it should have been. A pipeline that stopped running, a source system that delayed its export, a transformation that ran but failed to publish.
Latency failures: data that is technically current but represents a lag that's too long for its use case. A regulatory report that requires same-day accuracy but runs on T+1 data. An operational dashboard that refreshes hourly for a team making minute-by-minute decisions.
The right threshold depends entirely on how the data is used. There's no universal freshness standard. The question is whether actual currency matches what consumers of that data need.
Validity
Validity measures whether data conforms to the rules, formats, and constraints that define what correct looks like for your specific domain.
This is distinct from accuracy. An accurate record reflects what happened. A valid record reflects what's allowed to happen. A transaction amount might be technically accurate, it reflects what was entered, and still be invalid if negative amounts are prohibited in that context. A phone number field that contains free-text notes is structurally incorrect regardless of what the text says.
Validity failures are common at system boundaries: where data is extracted from one format and loaded into another, where business rules defined in one system aren't enforced downstream.
Validity is also the dimension most dependent on business knowledge. Technical teams can validate formats, ranges, and referential constraints, but the rules that determine what's valid for your business often live with domain experts, finance teams, compliance functions, and operational owners.
A data quality program that captures only the validity rules that engineers know how to write is almost certainly missing the ones that matter most to the business. This is one reason tool flexibility matters: validity rules are most effective when business users can define and maintain them without requiring a technical intermediary for every change.
Hidden Dimensions, Real Risk
The five dimensions above cover a lot. But real data environments have quality concerns that fall outside them.
Uniqueness: Do the appropriate fields have the cardinality expected?
A customer table where customer_id isn't actually unique creates fan-out errors that propagate through every downstream join. Uniqueness failures are structural and often silent: the data looks correct record-by-record, but the population is wrong.
Referential integrity: Are the defined relationships between entities consistently maintained?
Orphaned records, broken foreign keys, and missing parent records all represent referential failures that accuracy and completeness checks don't surface.
Standards compliance: Are naming conventions, data types, and structural standards being followed?
This matters more in complex environments where multiple teams contribute to shared data models.
Precision: Is the level of detail appropriate for the use case?
A financial calculation rounded to two decimal places when four are required, or a timestamp truncated to the day when hour-level precision is needed, is a precision failure that passes every accuracy check.
Security: Are appropriate access controls and data masking rules applied consistently?
In regulated environments, this is a data quality concern, not just an IT concern. Sensitive fields exposed to the wrong consumers or masked inconsistently across environments constitute a quality failure with direct compliance implications.
How many of these your program needs to cover depends on your environment and your risk. The point isn't that every team needs to test all thirteen possible dimensions. It's that defaulting to the five most commonly discussed, without consciously evaluating what else matters, is how coverage gaps form invisibly.
Why Coverage Gaps Form
Most quality programs don't consciously skip dimensions. They start with what's easiest to measure and expand when failures force the issue.
Accuracy testing maps naturally to the instinct to "check the data." Completeness gets partial attention because null fields are visible in query results. But consistency, timeliness, and validity require different questions, and in many cases, different ownership.
Temporal consistency requires monitoring that watches data over time, not just validating each load in isolation. Cross-system consistency requires connecting systems that aren't always connected in a quality context. Validity requires encoding business rules as explicit test definitions, knowledge that often lives in people's heads, in documentation, or in the implicit constraints of legacy systems that the receiving environment doesn't enforce.
Some of these dimensions are difficult to automate without business-user involvement. Validity is the clearest example: technical teams can implement constraints they know about, but the rules that define validity for a specific domain often require input from the people who work with that data operationally.
A program that only covers what engineers can implement unilaterally will systematically underweight business-logic dimensions.
What to Do Now
Coverage audit
For each dimension relevant to your environment, ask: What percentage of your important data assets have explicit tests?
Most teams find that accuracy and completeness coverage is reasonable, consistency coverage is partial, and validity, uniqueness, and temporal consistency coverage are minimal or reactive.
Failure diagnosis
When a data incident occurs, the dimensions provide a diagnostic framework. Is this an accuracy failure (wrong values), completeness failure (missing records), consistency failure (systems or records disagree), timeliness failure (data is stale), or validity failure (values violate constraints)?
The answer determines where to look and how to prevent recurrence.
Ownership mapping
Not every dimension is owned by the same team. Timeliness and structural completeness are natural engineering ownership. Validity and business rule compliance often require shared ownership with domain experts.
Making ownership explicit prevents gaps that form when each team assumes the other has a dimension covered.
Key Takeaways
-
The commonly cited five dimensions are a starting point, not the full picture. Uniqueness, referential integrity, temporal consistency, and others matter in real environments — and aren't covered by a program built around the standard list alone.
-
Different dimensions require different owners. Some are fully automatable by technical teams. Others, especially validity and business rule compliance, require input from domain experts. A program that captures only what engineers know how to write will systematically miss business-logic dimensions.
-
Coverage gaps form by default, not by decision. Most programs start with accuracy and completeness because they're visible and easy to implement. The dimensions that don't generate obvious failures tend to stay uncovered until a failure forces the issue.
-
The right number of dimensions to cover depends on your environment and risk. The goal isn't to test every possible dimension — it's to know which ones you're not covering and make a conscious decision about each.
Where Are Your Gaps?
Most data teams have a clearer picture of their accuracy and completeness coverage than of their validity, consistency, or uniqueness coverage, because failures in the first two are loud, while failures in the others often aren't. The harder question is which uncovered dimensions pose the greatest risk to your most important data assets.
If you'd like to think through that question against your own environment, Jonathan is available for a 30-minute coverage gap review — no prep required, just a conversation about where your program stands and where the blind spots are most likely hiding.
Tags: