Measuring data quality: completeness, accuracy, and timeliness

Reference article · 5 min read

A dashboard loses credibility slowly. Someone notices a count that does not match the source system, a chart that dropped a month, a field blank for one whole district. The number gets corrected in a meeting, and after that people quietly verify anything they plan to repeat.

Rebuilding that trust takes more than a better chart. It takes a repeatable way to say whether the data behind a number is fit for the decision being made. Data quality is measurable: the dimensions have plain definitions, any table can be profiled before it is trusted, and the expectations that follow can be written as automated rules that run on every load. The step most often skipped is the last: naming a person who receives each failure and acts on it.

The dimensions in plain terms

• Completeness. Are the values that should be present actually present? Two failures hide here: fields missing inside a record, and records missing entirely.
• Validity. Does a value conform to its defined type, format, range, or code list? A date that parses and falls in a plausible window is valid, which is not the same as right.
• Accuracy. Does the value match the real world? The hardest dimension to test automatically, because it needs a trusted reference: an authoritative address file, the system of record, or a sample reviewed by program staff.
• Consistency. Do related values agree, inside a record and across systems? A close date before an open date, or a summary count that does not match its own detail rows, fails even when each field is valid.
• Timeliness. Is the data current enough for the decision? Measure the lag between an event and its availability for reporting, and the age of the last successful load.
• Uniqueness. Is each real entity represented once? Duplicates inflate counts and split one case history into pieces.

Profile the table before you trust it

Profiling is a deliberate first read of a dataset to learn what is in it rather than what the documentation claims.

For each column, capture row count, distinct count, and null rate; minimum and maximum for dates and numbers; the most frequent values, which exposes undocumented code lists and defaults left in place; and text length distribution, which exposes truncation. Watch for sentinel values standing in for missing data: far past or far future dates, negative or zero placeholders, strings like "UNKNOWN" or "N/A". Identify which column or combination is genuinely unique. At the table level, chart row counts by load date to find gaps and spikes, reconcile totals against the source system, and measure how much data arrives after the cutoff.

Write the findings down, including the problems you decide to accept. That record becomes the baseline for rules and the honest answer when someone asks what the data supports.

Turn expectations into rules with thresholds

A useful rule is specific and testable. Each one should state:

• Scope. The table and column, plus any filter limiting which rows the rule applies to.
• Expectation. Null rate below a stated level, values drawn from a named code list, a unique key, a load finished within a stated number of hours.
• Threshold and severity. Separate a warning that means investigate from a failure that means hold publication.
• Action on failure. Block publication, quarantine the offending rows and load the rest, or publish with a notice.
• Owner. A named person, recorded with the rule.

Set thresholds from the profile and from what the decision needs, not from an aspirational zero. A field sparsely populated for years will fail a zero-null rule every run, and an alert that always fires is one nobody reads. Start at the observed baseline, alert on change, and tighten as the process improves.

Run the checks in the pipeline after load and before publication. Warehouse-native test frameworks, data quality tools, and scheduled SQL all do this. What matters is that rules live in version control and run every time.

Route failures to a named owner

A shared inbox is where alerts go to be ignored, because everyone assumes someone else has it. Route them instead:

• Name a data owner on the program side, accountable for what the data means and whether it is right, and a technical steward accountable for the pipeline.
• Send failures into the ticket queue that owner already works, tagged by dataset and severity.
• Put enough in the alert to act on: the rule, the threshold, the observed value, sample failing rows, the last known good run.
• Track how long failures stay open. A rule that fails constantly is either an upstream problem nobody is fixing or a rule calibrated wrong.
• Publish current status beside the dashboard, so readers see freshness and known issues without asking.

What to ask vendors and require in the contract

Much of the data an agency reports on lives in a vendor system. Ask before signing:

• Which quality checks run today on the data you host or deliver, and can we see the results?
• Can we export the full dataset, including history and reference tables, in a documented format?
• Where is the data dictionary, and how is it maintained when the schema changes?
• How are records corrected, is correction history retained, and what load windows do you commit to?

Then put the answers in the contract: documentation as a maintained deliverable, advance notice of schema changes, export rights at no added cost during the term and at exit, defined freshness windows with notice when missed, access to error logs, and a named technical contact for data issues. Requirements change, so confirm specifics with your counsel and current official sources.

HQT works with state and local agencies on data platforms, pipeline instrumentation, and reporting.

Frequently asked questions