Data Quality

Data quality is the degree to which data is fit for a particular purpose, receiver and moment in time.

High-quality data is not data that looks clean. It is data whose limitations are understood well enough that it can be used without pretending to know more than it actually represents.

Data quality is often reduced to a cleaning exercise: remove duplicates, standardise dates, fix spelling, fill missing fields. Those tasks matter, but they address only visible symptoms. The deeper problem is whether the data correctly represents the part of reality that a receiver is trying to understand.

ARTICLE ID: DATA.MANAGEMENT.006
Canonical function: fitness for use and error control
Series route: What Is Data Management? → Data Architecture → Data Quality.

The First Question: Correct for What?

A value can be high quality for one purpose and poor quality for another.

A city temperature rounded to the nearest degree may be adequate for a weather display but too coarse for a laboratory experiment. A student’s age in whole years may be sufficient for a school cohort summary but not for an eligibility rule based on an exact date. A location recorded to the nearest kilometre may be useful for regional planning but inadequate for emergency dispatch.

Quality therefore depends on the relationship:

Representation + Purpose + Receiver + Time + Consequence

Remove any one of those and a generic “quality score” can become misleading.

The Main Dimensions of Data Quality

Accuracy

Accuracy asks whether the recorded value corresponds closely enough to reality. A correct-looking format does not prove accuracy. “31/12/2026” may be a valid date but still be the wrong date.

Completeness

Completeness asks whether necessary values, records, periods or populations are missing. A dataset can be complete at the row level yet incomplete because an entire class of people was never captured.

Consistency

Consistency asks whether related representations agree where they should. If one system records a student as enrolled while another records the same student as withdrawn, the conflict must be resolved or made explicit.

Timeliness

Timeliness asks whether data is current enough for the intended decision. Yesterday’s vehicle location may be perfectly accurate historically and useless operationally.

Validity

Validity asks whether a value conforms to the rules of its representation: type, range, format, allowed code, relationship or business constraint.

Uniqueness

Uniqueness asks whether one real-world entity or event is represented more than once when it should not be. Duplicate identities can distort counts, payments, communications and analysis.

Integrity

Integrity asks whether relationships and constraints remain coherent. An order should not point to a customer that does not exist. A transaction should not reference an invalid currency code.

Traceability

Traceability asks whether users can determine where data came from, what happened to it, which version they are seeing and why they should trust it.

Quality Is Not One Number

Organisations often want a single data-quality score because it is easy to display. The danger is that a combined score can hide the dimension that matters most.

A dataset might score 99% overall yet contain a 1% identity error that affects the highest-risk cases. Another might be only 90% complete but fully adequate because the missing fields are optional.

Quality metrics should therefore be tied to explicit business or research consequences.

The Quality Chain

Data quality emerges from a chain of events:

Reality → Observation → Capture → Interpretation → Storage → Transformation → Delivery → Use

Errors can enter at any point.

The wrong thing can be measured.
A correct observation can be entered incorrectly.
A value can be assigned the wrong unit.
A valid code can be interpreted under the wrong dictionary.
A transformation can exclude the wrong records.
A dashboard can use stale data.
A receiver can use a historical value as if it were current.

Cleaning only the final table cannot repair all of these failure modes.

Quality Begins at Collection

The cheapest error is often the one prevented before capture.

Good collection design uses:

clear field labels;
controlled choices where appropriate;
reasonable defaults;
unit display;
validation near entry;
stable identifiers;
minimum necessary fields;
contextual help;
error messages that explain how to repair the input.

Poor interface design creates poor data. Data quality is therefore partly a human-factors problem.

Missing Data Is Information

Missingness should not always be treated as an empty cell to fill.

Different kinds of missingness can mean different things:

not collected;
not applicable;
unknown;
declined;
temporarily unavailable;
lost;
invalidated;
suppressed for privacy.

Collapsing these states into a blank value throws away useful information.

Zero Is Not Missing

One of the most common data mistakes is to replace missing values with zero. Zero is a statement. Missing is an absence of a statement.

If a student did not sit a test, a score of zero means something different from “no score recorded”. If a sensor failed, zero temperature is not the same as no measurement. Quality systems protect this distinction.

Duplicate Data

Duplicates arise when one real-world entity or event is represented more than once. They are common when systems rely on names, free-text addresses or local identifiers instead of stable identity.

Deduplication may use exact matching, fuzzy matching, probabilistic methods or domain rules. But every merge carries risk. Two similar records may be two different people. Good quality processes preserve evidence of why a match was accepted.

Outliers: Error or Discovery?

An outlier is a value that differs strongly from expectation. It may be an error. It may also be the most interesting observation in the dataset.

Quality systems should flag unusual values for investigation rather than automatically deleting them. In science, medicine, finance and operations, genuine extremes can reveal important phenomena.

Validation Is Not Verification

Validation checks whether data satisfies rules. Verification checks whether the representation is supported by an authoritative source or observation.

A passport number may pass format validation and still belong to the wrong person. A temperature may be within a plausible range and still be wrong because the sensor was miscalibrated.

Good quality systems know what each test can and cannot prove.

Quality Rules

Quality rules make expectations machine-testable where possible.

Examples include:

date of birth must not be in the future;
order quantity must be greater than zero;
student ID must exist in the authorised identity table;
currency code must come from an approved reference list;
measurement unit must be recorded;
daily dataset refresh must arrive before a defined time;
critical fields must have less than a defined missingness threshold.

Rules should have owners, severity and a repair route. Otherwise they become alarms that everybody learns to ignore.

Quality Thresholds

Not every quality issue should stop a system. A missing optional demographic field may be tolerable. A missing payment amount may not be.

Thresholds should therefore reflect consequence. Critical data can have stricter controls, faster escalation and lower tolerance for unresolved error.

Quality at the Interface

Every system boundary is a quality boundary. Producers and consumers need explicit contracts around schema, semantics, freshness and allowed change.

A pipeline can be technically successful while quality fails because meaning changed. For example, a source can keep sending a valid field called status after redefining what the values mean.

Interface quality therefore includes semantic stability as well as technical availability.

Data Quality and Metadata

Metadata makes quality interpretable. A quality score without context is weak. Users need to know which version was measured, which rules applied, when the checks ran and which known limitations remain.

See Metadata and Data Lineage.

Data Quality and Lineage

When a quality problem is found, lineage reveals where it came from and where it may have spread.

If one source field was wrong, lineage can identify affected reports, models and downstream datasets. This turns repair from guesswork into bounded impact analysis.

The Quality Incident Lifecycle

A mature quality incident follows a route:

Detect → Triage → Contain → Trace → Correct → Propagate → Validate → Explain → Prevent Recurrence

The objective is not merely to fix the row. It is to understand the system that allowed the error to persist.

Root Cause vs Symptom

If the same error returns every week, manual correction is not a quality process. It is evidence that the root cause remains.

Common root causes include:

ambiguous field definitions;
poor user-interface design;
unstable identifiers;
missing reference data;
silent schema changes;
incorrect transformation logic;
weak ownership;
incentives that encourage users to bypass controls;
system integrations that drop context;
stale data not marked as stale.

Quality Debt

Quality debt accumulates when organisations tolerate unresolved issues faster than they repair them. Like technical debt, it makes future changes harder and more expensive.

Quality debt appears as:

manual spreadsheet patches;
special-case transformation rules;
duplicate identities;
unowned exceptions;
reports with undocumented caveats;
analysts spending more time cleaning than analysing;
teams maintaining private correction files.

The debt is not only operational. It reduces trust, and low trust encourages more local copies, which creates more quality debt.

The Trust Spiral

Data quality can produce a positive or negative spiral.

Low trust → local copies → local corrections → more inconsistency → lower trust

Or:

Visible quality → clear ownership → faster repair → fewer shadow copies → stronger trust

Data Profiling

Data profiling examines the actual contents of a dataset to discover distributions, null rates, patterns, outliers, distinct values and relationships.

Profiling is useful because documentation may describe what data should contain while profiling reveals what it actually contains.

Reconciliation

Reconciliation compares records or totals across systems to confirm that transfers and transformations preserved expected results.

Financial systems often use reconciliation heavily because small mismatches can have material consequences. The same principle applies elsewhere: compare source and receiver to detect silent loss or duplication.

Data Observability

Data observability continuously watches whether data systems behave as expected. Useful signals include freshness, volume, schema, distribution, lineage and quality-rule failures.

Observability is especially valuable because many data failures do not crash software. A dashboard can keep loading while the underlying data becomes stale or incomplete.

Quality and AI

AI systems inherit the strengths and weaknesses of their data. Training quality, label quality, evaluation quality, retrieval quality and feedback quality all matter.

Important AI data-quality questions include:

Does the dataset represent the deployment population?
Are labels defined consistently?
Are duplicates causing leakage between training and evaluation?
Are source rights and provenance documented?
Has the world changed since collection?
Are rare but important cases present?
Are generated or synthetic records distinguishable from observed records?

A bigger training dataset is not automatically a better training dataset.

Quality and Education

Educational data illustrates why quality must be interpreted carefully. A test score may be recorded accurately but still be a weak representation of overall ability if the test samples only a narrow set of skills.

Quality therefore includes measurement validity, not only database correctness. A technically perfect record can still represent the wrong construct.

A learner’s old score can also be high-quality historical data and low-quality current evidence. Time matters.

Quality and Science

Scientific quality depends on measurement conditions, calibration, units, protocols, sampling, uncertainty and reproducible transformation.

A raw value should not be separated from the method that produced it. Measurement uncertainty should not be hidden simply because a database field can store many decimal places.

False Precision

False precision occurs when a representation implies more certainty than the underlying evidence supports.

Examples include reporting a loosely estimated quantity to six decimal places or assigning a precise risk score to an input that is itself highly uncertain.

High-quality data represents uncertainty honestly.

Data Quality and Governance

Quality needs governance because somebody must decide what is good enough, who fixes problems and which risks can be accepted.

See Data Governance.

A Quality Scorecard

A useful scorecard for a critical dataset can contain:

owner;
purpose;
critical fields;
quality dimensions;
thresholds;
current measurements;
known exceptions;
incident age;
downstream impact;
repair status.

The scorecard should make action visible, not merely status.

A Quality Maturity Ladder

Reactive: errors are fixed when users complain.
Validated: basic rules catch obvious defects.
Measured: quality dimensions are monitored.
Owned: critical datasets have accountable owners.
Traceable: lineage supports impact analysis and repair.
Preventive: root causes are corrected upstream.
Adaptive: thresholds and controls evolve with changing use.
Trusted: users understand both strengths and limitations.

The Most Dangerous Quality Failure

The most dangerous quality failure is not always obviously wrong data. It is data that is wrong in a way that remains believable.

A missing record can trigger investigation. A plausible but incorrect number may flow through a dashboard, report, decision or model without resistance.

For this reason, quality systems need provenance, reconciliation and challenge—not only format checks.

The Receiver Test

Before using a dataset, a receiver should be able to answer:

What does this data represent?
How was it collected?
How current is it?
What is missing?
What quality rules were applied?
What known errors remain?
Which source is authoritative?
What transformations occurred?
Is the data fit for this specific decision?

If the receiver cannot answer those questions, the quality problem may be a metadata problem as much as a data problem.

A Practical Quality Operating Loop

Define → Measure → Detect → Triage → Repair → Trace → Prevent → Re-measure

Each loop should reduce uncertainty about the estate. If quality incidents recur without learning, the organisation is cleaning data but not improving data management.

Data Management Series

Final idea: data quality is not the elimination of every imperfection. It is the disciplined reduction, exposure and control of error so that receivers can make decisions with an honest understanding of what the data can and cannot support.

Data Quality | Accuracy, Completeness, Consistency, Timeliness, Validity and Trust