NeuroNomixer
  • Home
  • Blog
  • Visual Guides
  • Authors
  • Contact
Sign InSign Up
HomeBlogAuthorsContactPrivacy Policy

© 2026 NeuroNomixer — Built with Next.js & Tailwind CSS

Visual Guides/The Six Faces of Bad Data
Data & Analysis

The Six Faces of Bad Data

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.

Inject and repair 3 defect types (0/3)
Build 2 validation rules (0/2)

Sign in to save progress

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.

DimensionThe question it asksHow this page computes it
CompletenessIs the value there at all?percent of non-null cells across all six fields
UniquenessIs each customer recorded once?duplicate rows found by exact email key match
ValidityDoes the value look right?email pattern check plus signup date range check
ConsistencyDo the fields agree with each other?country column versus phone country code
TimelinessIs the value current?last updated within 365 days of the pinned audit date 2026-07-01
AccuracyIs 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.

Inject it, read the meters, repair it.

Paste a customer twice

Appends exact copies of rows 2 and 5 to the bottom of the table.

Inject it, read the meters, repair it.

Mangle formats

Drops the @ from row 4's email, pushes row 6's signup date to 2031, and gives row 11 the month 13.

Inject it, read the meters, repair it.

Cross the wires

Rewrites the phone country codes on rows 1, 7, and 13 so they contradict the country column.

Inject it, read the meters, repair it.

Let records age

Pushes last-updated on rows 2, 5, 9, and 14 back to dates in 2022 through 2024.

Inject it, read the meters, repair it.

Drift from the truth

Respells verified names and emails on rows 2, 5, 9, and 13. Every new value still passes every format check.

Inject it, read the meters, repair it.

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

#idnameemailcountryphonesignupDatelastUpdatedverified
11Ava Thompsonava.thompson@nordicdata.ioUS+1 41555501322019-03-122026-05-14no
22John Smithjohn.smith@acmecorp.comGB+44 20755501982017-11-052026-06-20yes
33Yuki Tanakayuki.tanaka@sakuratech.jpJP+81 3555001472021-06-302026-04-02no
44Maria Lopezmaria.lopez@solarisretail.comUS+1 30555501732018-09-212026-03-18no
55Sofia Bergsofia.berg@fjordanalytics.noNO+47 225550182020-01-152026-06-08yes
66Lucas Weberlucas.weber@rheinlogistik.deDE+49 30555501662016-04-272026-02-25no
77Elise Laurentelise.laurent@parisfintech.frFR+33 1455501222022-08-092026-05-30no
88Omar Haddadomar.haddad@atlascloud.comUS+1 21255501842019-12-022026-01-19no
99Emma Wilsonemma.wilson@thamesmedia.co.ukGB+44 16155501112015-07-142026-06-27yes
1010Nora Iversennora.iversen@polarsoft.noNO+47 235550492023-02-182026-03-05no
1111Felix Braunfelix.braun@alpengruppe.deDE+49 89555501292020-10-112026-04-21no
1212Chloe Martinchloe.martin@lyonlabs.frFR+33 4725501632024-05-062026-06-01yes
1313Kenji Satokenji.sato@fujidesign.jpJP+81 6625501782018-02-232025-12-12yes
1414Grace Chengrace.chen@harborsecurity.comUS+1 61755501572021-09-082026-05-22yes

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.

idverified nameverified email
2John Smithjohn.smith@acmecorp.com
5Sofia Bergsofia.berg@fjordanalytics.no
9Emma Wilsonemma.wilson@thamesmedia.co.uk
12Chloe Martinchloe.martin@lyonlabs.fr
13Kenji Satokenji.sato@fujidesign.jp
14Grace Chengrace.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.

← All GuidesNext Guide →