Define data quality by the decision it must support, then prove the controls actually work.

1. Scope quality to an intended use

For each high-consequence data use, write a short quality contract:

• decision, service, report, model, or process supported;
• dataset/data product and authoritative source;
• consumer and accountable owner;
• quality dimensions that materially affect the use;
• threshold, tolerance, or review condition;
• measurement frequency and evidence source;
• action when the expectation is not met.

The Federal Data Strategy's federal-scope practices likewise emphasize aligning quality with intended use rather than treating all data identically.^{Federal Data Strategy — Practice 28}

2. Choose dimensions that explain failure

Common dimensions include accuracy, completeness, consistency, currentness/timeliness, validity, uniqueness, and credibility/provenance. W3C DQV references quality dimensions as a way to organize metrics without asserting that one fixed dimension set or score fits every consumer.^{W3C DQV}

A metric is useful only if the organization knows what decision follows a breach.

3. Put controls as close to the source as practical

Data-quality assurance should combine preventive, detective, and corrective controls.

Do not rely exclusively on downstream cleansing. Repeatedly repairing the warehouse while the source process continues creating defects hides the real control failure.

4. Use reconciliation where independent evidence exists

Reconciliation is strongest when two independently generated records should agree. Examples include source-versus-target counts, ledger/subledger totals, transaction-versus-settlement records, source-system versus published data products, or operational records versus regulatory submissions.

Document the population, tolerance, timing, unresolved-difference owner, and evidence retained. A reconciliation that routinely carries unexplained differences without escalation is not functioning as assurance.

5. Test transformations and pipelines as data-producing systems

• version schemas and material business rules;
• test expected transformations using representative data;
• record source/target counts and rejected records;
• detect silent truncation/type coercion;
• monitor late or duplicated loads;
• make backfills/replays attributable;
• compare post-change quality against baseline.

Quality controls should travel with the data product and survive platform migration. Avoid hard-coding all knowledge into one orchestration tool with no external documentation or owner.

6. Operate data-quality incidents by consequence

A data-quality incident exists when a material use may be wrong, delayed, incomplete, or misleading—not merely when a rule fails.

Incident record

• detected condition and time;
• affected data/products/consumers;
• consequence and decision risk;
• containment (stop publication, qualify result, switch source, etc.);
• root cause;
• corrective action and owner;
• backfill/reconciliation evidence;
• consumer notification;
• validation that the defect no longer recurs.

Escalate faster when public reporting, safety, financial decisions, personal data, automated decisions, or critical operational services are affected.

7. Publish enough quality metadata for consumers to judge fitness

W3C DQV exists specifically to help publishers express quality information so consumers can judge fitness for purpose.^{W3C DQV} Whether or not DQV is used technically, expose meaningful limitations:

• refresh frequency and last successful refresh;
• coverage/population limits;
• known missing fields or geographies;
• definition/version changes;
• material quality incidents;
• measurement method;
• contact/owner for correction or questions.

Do not publish an opaque “97% quality” badge without explaining dimensions, weights, measurement period, and consequence.

8. Build an assurance sample that tests the control, not the dashboard

Periodic assurance should select important controls and reconstruct them from source evidence:

1. choose a critical data product/use;
2. identify its quality contract and owner;
3. recompute selected metrics from underlying data;
4. verify detected exceptions were routed and resolved;
5. trace a change through tests and consumer notification;
6. sample a prior incident and confirm corrective action stayed effective.

This gives leaders evidence that the DQA process works, not merely that dashboards rendered successfully.

9. Design thresholds that trigger proportionate action

A threshold should connect measurement to an operational response. Avoid choosing limits only because they produce a comfortable green dashboard. Start from the consequence of bad data: what happens if a critical field is missing, a feed is six hours late, two systems disagree, or an identifier is duplicated? Then set warning and breach conditions that give the responsible team enough time to contain the consequence.

Use different thresholds where use cases differ. A dataset that is adequate for exploratory analysis may be unacceptable for payment, eligibility, safety, public reporting, or automated decision support. Record the intended use beside the threshold so a consumer cannot mistake one team's tolerance for a universal quality guarantee.

For every material threshold, define the measurement population, calculation method, evaluation window, owner, notification path, containment action, and exception authority. Review thresholds after incidents and major process changes. If a control breaches frequently without action, either the process is not under control or the threshold has become ceremonial. If it never breaches, test whether it would actually detect the failure modes the organization cares about.

Exceptions should be time-bounded. Record the affected consumer or process, reason, compensating control, approver, expiry date, and evidence required to close the exception. Repeated extensions are a signal for management attention because they convert a temporary tolerance into an undocumented operating condition.

Measure whether quality risk is being controlled

• critical data products with explicit intended-use quality contracts;
• material controls with current owners and measurement evidence;
• open quality incidents by consequence and age;
• repeat incidents caused by the same root cause;
• consumer-visible defects detected internally before use;
• unexplained reconciliation differences;
• changes that caused quality regression;
• time from detection to consumer notification/correction for material defects.

30-day data-quality reset

1. Week 1: select ten highest-consequence data uses and define quality contracts.
2. Week 2: map source, preventive/detective controls, owner, and consumer for each.
3. Week 3: test reconciliation and simulate one quality incident through containment/correction.
4. Week 4: remove vanity metrics, publish limitations, and establish monthly assurance review.

Current sources

• ISO 8000-61:2016 — Data quality management process reference model
• W3C — Data Quality Vocabulary
• Federal Data Strategy — Practices (federal scope)
• W3C — DCAT Version 3