A record can look perfect and still lie. Six live meters, each computed from one small customer table, turn a vague feeling that the data is off into a named, testable diagnosis.
Six different diseases, six different tests
The vocabulary goes back to Wang and Strong's 1996 study of what data quality means to the people who consume it. Six dimensions survived into nearly every modern data-quality tool, and each one answers a different question about the same cell. The point of this guide is that they are separable: you can break exactly one at a time and watch exactly one meter move.
| Dimension | The question it asks | How this page computes it |
|---|---|---|
| Completeness | Is the value there at all? | percent of non-null cells across all six fields |
| Uniqueness | Is each customer recorded once? | duplicate rows found by exact email key match |
| Validity | Does the value look right? | email pattern check plus signup date range check |
| Consistency | Do the fields agree with each other? | country column versus phone country code |
| Timeliness | Is the value current? | last updated within 365 days of the pinned audit date 2026-07-01 |
| Accuracy | Is the value actually true? | field-by-field match against the verified contract file |
How this page stays honest: every number is computed in your browser from the 14-row customer table below, plus a small verified contract file for the accuracy check. The audit date is pinned to the constant 2026-07-01, so the timeliness math never shifts under you. Nothing is faked.
Corruption Lab
Each button injects one specific defect into the table, then repairs it on the second press. Predict which meter will move before you press. Inject and repair at least 3 different defect types to earn the diagnosis badges.
Blank out fields
Sets email on rows 3 and 10, phone on row 8, and name on row 12 to null.
Paste a customer twice
Appends exact copies of rows 2 and 5 to the bottom of the table.
Mangle formats
Drops the @ from row 4's email, pushes row 6's signup date to 2031, and gives row 11 the month 13.
Cross the wires
Rewrites the phone country codes on rows 1, 7, and 13 so they contradict the country column.
Let records age
Pushes last-updated on rows 2, 5, 9, and 14 back to dates in 2022 through 2024.
Drift from the truth
Respells verified names and emails on rows 2, 5, 9, and 13. Every new value still passes every format check.
Dimension Meters
6 of 6 meters clean
Completeness
100.0%
Is the value there at all?
84 of 84 cells hold a value
clean
Uniqueness
100.0%
Is each customer recorded once?
0 duplicate rows of 14 by exact email key
clean
Validity
100.0%
Does the value look right?
28 of 28 format checks pass (email pattern, signup range)
clean
Consistency
100.0%
Do the fields agree with each other?
14 of 14 country and phone pairs agree
clean
Timeliness
100.0%
Is the value current?
14 of 14 rows updated since 2025-07-01
clean
Accuracy
100.0%
Is the value actually true?
12 of 12 verified fields match the contract file
clean
The customer table
14 rows · audit date pinned to 2026-07-01
| # | id | name | country | phone | signupDate | lastUpdated | verified | |
|---|---|---|---|---|---|---|---|---|
| 1 | 1 | Ava Thompson | ava.thompson@nordicdata.io | US | +1 4155550132 | 2019-03-12 | 2026-05-14 | no |
| 2 | 2 | John Smith | john.smith@acmecorp.com | GB | +44 2075550198 | 2017-11-05 | 2026-06-20 | yes |
| 3 | 3 | Yuki Tanaka | yuki.tanaka@sakuratech.jp | JP | +81 355500147 | 2021-06-30 | 2026-04-02 | no |
| 4 | 4 | Maria Lopez | maria.lopez@solarisretail.com | US | +1 3055550173 | 2018-09-21 | 2026-03-18 | no |
| 5 | 5 | Sofia Berg | sofia.berg@fjordanalytics.no | NO | +47 22555018 | 2020-01-15 | 2026-06-08 | yes |
| 6 | 6 | Lucas Weber | lucas.weber@rheinlogistik.de | DE | +49 3055550166 | 2016-04-27 | 2026-02-25 | no |
| 7 | 7 | Elise Laurent | elise.laurent@parisfintech.fr | FR | +33 145550122 | 2022-08-09 | 2026-05-30 | no |
| 8 | 8 | Omar Haddad | omar.haddad@atlascloud.com | US | +1 2125550184 | 2019-12-02 | 2026-01-19 | no |
| 9 | 9 | Emma Wilson | emma.wilson@thamesmedia.co.uk | GB | +44 1615550111 | 2015-07-14 | 2026-06-27 | yes |
| 10 | 10 | Nora Iversen | nora.iversen@polarsoft.no | NO | +47 23555049 | 2023-02-18 | 2026-03-05 | no |
| 11 | 11 | Felix Braun | felix.braun@alpengruppe.de | DE | +49 8955550129 | 2020-10-11 | 2026-04-21 | no |
| 12 | 12 | Chloe Martin | chloe.martin@lyonlabs.fr | FR | +33 472550163 | 2024-05-06 | 2026-06-01 | yes |
| 13 | 13 | Kenji Sato | kenji.sato@fujidesign.jp | JP | +81 662550178 | 2018-02-23 | 2025-12-12 | yes |
| 14 | 14 | Grace Chen | grace.chen@harborsecurity.com | US | +1 6175550157 | 2021-09-08 | 2026-05-22 | yes |
Rows marked verified appear in the contract file below, which is what the accuracy meter compares against. Cells outlined in orange are flagged by the rules you build in the next section.
The contract file (ground truth for accuracy)
Accuracy is the only dimension you cannot compute from the table alone. It needs an external source of truth. Here that source is a set of six customers whose name and email were verified against signed onboarding contracts. The accuracy meter compares each verified field in the table against this file and counts mismatches.
| id | verified name | verified email |
|---|---|---|
| 2 | John Smith | john.smith@acmecorp.com |
| 5 | Sofia Berg | sofia.berg@fjordanalytics.no |
| 9 | Emma Wilson | emma.wilson@thamesmedia.co.uk |
| 12 | Chloe Martin | chloe.martin@lyonlabs.fr |
| 13 | Kenji Sato | kenji.sato@fujidesign.jp |
| 14 | Grace Chen | grace.chen@harborsecurity.com |
Build the rules that catch it
Meters diagnose; rules enforce. A validation rule is one column plus one assertion, evaluated against every row. Build at least 2 rules and watch the offending rows light up in the table above. Note that null values are skipped by every rule except not-null: each rule tests exactly one thing, which is what makes a failing rule diagnostic.
1. Pick a column
2. Pick a rule
3. Your rules (offending rows highlight in the table above)
No rules yet. Add one and the table lights up the rows that break it. Try not-null on email while fields are blanked out, or unique on email while a customer is pasted twice.
The trap: validity is not accuracy
Inject the "Drift from the truth" defect and look closely: jon.smith@acmecorp.com passes the email regex, is unique, agrees with every other field, and was updated recently. Five meters stay green. Only accuracy falls, and only because this page happens to have a contract file to compare against. That asymmetry is the most expensive lesson in data quality: validity checks are cheap and local, while accuracy needs an external source of truth that usually does not exist for most of your columns. In practice you automate the five cheap dimensions as rules in your pipeline, and you buy accuracy where it matters with audits, double entry, or reconciliation against an authoritative system.
The reverse confusion also costs money: a stale record is not invalid. Every aged last-updated date in this table still parses and sits inside the allowed range, so an in-range rule will never catch staleness. If a meter feels redundant, inject its defect and check which rules fire. Where none do, that dimension needs its own test. For what to do after the diagnosis, the next guide walks the exploratory workflow that turns a suspect table into an understood one.