The Seven Dimensions of Data Quality

Several widely used data-quality frameworks, across many industries and long before programme monitoring adopted them, converge on roughly the same handful of dimensions — because they describe genuinely distinct failure modes, not overlapping ways of saying the same thing. A record can be complete yet wrong, unique yet invalid, timely yet inconsistent with a related record elsewhere. Naming each dimension separately is what makes it possible to build one specific, deterministic check per failure mode, rather than a single vague "data quality" warning that tells nobody what to actually fix.

Completeness asks whether every required field on a record is actually filled in — a phone number, a GPS point, a reported indicator value for the period. A field silently left blank is often invisible until the moment someone needs it, which is usually the worst possible time to discover it.

Accuracy asks a harder question: does the value that IS present actually reflect the real, verifiable truth? A phone number can be complete, correctly formatted, and still belong to the wrong person, or an indicator result can be entered with full confidence and still not match what the underlying evidence — an attendance register, a survey — actually shows. Accuracy is the one dimension no format check can confirm on its own; it can only be checked against a real source of evidence.

Validity is often confused with accuracy but asks something narrower and more mechanical: does the value conform to the format, type and range a field is defined to hold? A date field holding a real calendar date, a GPS field holding coordinates that actually fall within the country of operation, a percentage that cannot exceed 100 — these are all validity checks, and a computer can enforce every one of them automatically. A value can be perfectly valid and still be inaccurate (a real, well-formatted GPS point recorded at the wrong location); validity is a necessary floor, never a substitute for accuracy.

Uniqueness asks how much unwanted duplication exists in a dataset — most consequentially, the same person registered more than once under slightly different spellings or details, each subsequent visit then counted as reaching a "new" person. This single failure mode is one of the most common and most damaging in programme reporting, because it inflates reach figures quietly, a few records at a time, until a headline number no longer means what it claims to.

Consistency asks whether the same fact reads the same way everywhere it appears. A budget-utilization figure shown on a dashboard should match the same figure in a formal report for the identical period and scope; a count of completed activities in a workplan should reconcile with the results actually recorded against them. Inconsistency is rarely caused by dishonesty — it is almost always a sign that two parts of a system are quietly calculating, or storing, the same fact two different ways.

Timeliness asks whether data was captured and reported within the period it actually describes, not months after the window in which it could still have informed a decision. A technically accurate report submitted two quarters late has already lost most of its practical value — the moment it could have changed a course of action has already passed.

Integrity asks whether a record can be trusted to have stayed what it claims to be over time — whether every change to it is attributable to someone, timestamped, and impossible to make silently. Without integrity controls, every other dimension above becomes unverifiable in hindsight: a number can look complete, accurate, valid, unique, consistent and timely today, and there would still be no way to know if it looked different yesterday, or who changed it, or why.

None of these seven require a separate system of their own. Several — completeness, validity, uniqueness, consistency, integrity — can be checked automatically and deterministically, because a computer can confirm a field is filled, a format is correct, a record has no duplicate, two figures agree, and a change is attributable, without any human judgement at all. Accuracy and, to a real extent, timeliness are different: no software can confirm a number is TRUE, only that it is present, well-formed, and hasn't silently changed — accuracy ultimately still depends on someone checking a reported figure against its real, named source of evidence.

The Data Quality Dashboard's deterministic checks cover completeness and validity directly — missing phone numbers, missing GPS, indicators with no target or no result reported, coordinates that fall outside real bounds — the moment the underlying record is entered, not discovered later during a report.

Uniqueness is handled through the Data Matching Center, a governed workflow for surfacing likely-duplicate beneficiary records and resolving them deliberately, with a named reviewer, rather than silently merging or silently ignoring them.

Consistency follows from architecture rather than a separate check: dashboards, Report Builder and every export read the same canonical indicator, budget and workplan definitions, so the same fact cannot quietly diverge into two different numbers depending on where it is viewed.

Integrity is enforced by an audit trail recorded on every create, update and delete across the platform, and by an explicit amendment workflow (rather than silent in-place editing) on records — such as a published report — where a change needs to be visible, not invisible.

Accuracy stays what it always is everywhere — a human judgement — but METRA GET supports it directly: every indicator carries a stated data-quality/verification method and can hold attached evidence, so a reported figure is never just a number with no way to check it.

Timeliness is supported by scheduled reporting cadences and a field-report submission cycle tied to real reporting periods, so a gap between when something happened and when it was recorded stays visible rather than hidden.