A missing rule behind a reassuring dashboard
In this fictional scene set in 2021, a team prepares to launch a planning tool. Its dashboard reports 98% completeness, but two branches interpret “available date” differently. One records physical receipt; the other records completion of inspection. The plan combines those values as though they represent the same event. Every figure, person and result is invented for teaching purposes. None describes a CYTIZEN client engagement. The underlying problem is an unresolved business definition, rather than a shortage of populated cells.
Data quality becomes a hidden project when a programme promises a new capability without addressing the rules needed to use it. Cleaning a migration file may hide the defect without preventing recurrence. Decide what values mean, which errors prevent which decisions, who fixes the cause and how exceptions remain visible. This retrospective analysis of 2021 uses official sources checked in October 2026. The UK framework published in December 2020 provides a historical reference; current page versions are not represented as archived copies.
Begin with the decision
Ask which decision the data must support. In the fictional planning flow, the team must decide whether a batch can be promised for a particular date. Operations identifies the necessary events: receipt, completed inspection and availability at the correct location. A single field cannot silently substitute for all three. Identify the data critical to this decision before measuring every field in the system. This narrows the work to defects with operational consequences.
A date can be present and correctly formatted while still being wrong. A reference can be accurate but arrive too late. A unique identifier can identify the wrong object. The business owner explains the consequences of each defect and selects a proportionate response. A threshold should state whether the decision can proceed, needs human review or must stop. It should not exist only to make a dashboard look healthy. Different uses of the same data may legitimately require different quality conditions.
Turn definitions into executable rules
For each critical item, specify scope, test, timing, response and owner. “Correct date” is insufficient. “For a batch offered for sale, availability means final inspection completed and cannot precede receipt” can become a control. Historical imports may require distinct handling. A syntax check can run automatically, while a business contradiction may require source evidence and an authorised decision. Do not confuse a successful automated test with verification that the underlying event actually happened.
Agree definitions with people who create, use and correct the data. Technical teams implement checks, but should not independently choose which business interpretation prevails. In the scenario, operations retains separate receipt and inspection dates. Finance preserves events needed for reconciliation. Planning accepts a block when final inspection is missing. Record the effective date and treatment of existing records. Otherwise a definition change can silently alter both operations and historical performance measures.
Version the rules. If a definition changes, explain whether previous measures remain comparable. A defect rate can fall because scope shrank or a check was disabled, without any improvement in the data. Report the tested population and rule version alongside the result. Count and explain exclusions. Users should see what was checked, what was not and what they can reasonably conclude. This prevents a headline percentage becoming a substitute for evidence about the actual decision.
A completed rules and decisions register
This fictional example contains illustrative controls, not industry standards. The full register also includes source systems, correction owners, due dates and evidence locations.
| Decision and data | Illustrative rule | Response and owner | Documented exception |
|---|---|---|---|
| Promise a batch; final inspection | Completed status and date for every batch offered for sale | Block promise; workshop quality owner | Demonstration batch excluded from sales, with reason and expiry |
| Reconcile receipt; supplier reference | Reference linked to an active supplier and received document | Review queue; purchasing administrator | Temporary supplier approved by purchasing manager |
| Calculate elapsed time; events | Final inspection occurs no earlier than receipt | Correct at source; operations owner | Isolated historical recovery with retained event evidence |
Every row identifies the protected decision and consequences of failure. A missing value in a rarely used field may wait, while ambiguity in a promise date needs immediate attention. The data owner is not necessarily the person entering the value. The owner needs authority to define meaning, accept a bounded exception and obtain a lasting process correction. A register of technical tests without this authority will accumulate findings rather than resolve them.
Manage exceptions without erasing defects
An acceptable exception is explicit, limited and reviewable. Record the case, reason, risk, approver and review date. State which activities remain permitted. A demonstration batch can take a separate route but must not silently enter stock available for sale. “Historical data is imperfect” is not a useful exception: replace it with defined scope, a temporary rule and an owner. Expired exceptions return to review rather than becoming permanent informal permissions.
Report open defects, completed corrections and active exceptions separately. Increasing exceptions must not make the headline rate look better merely because records leave the denominator. Repeated exceptions can mean a rule is unsuitable, or that people are under pressure to bypass it. Review the reasons and decide whether to change the rule, repair the flow or retain the block. An authorised waiver does not make the underlying data accurate, and its residual limitations must remain visible.
Correct the source where possible. Reconstructing dates in an analytical warehouse may protect a report while leaving operational teams exposed. Investigate why the value is wrong: ambiguous form, absent responsibility, truncated interface code, entry before the event or a performance target encouraging premature dates. Match the remedy to the cause. Mandatory fields do not resolve conflicting definitions. Training does not repair an incorrect interface transformation. Treat these as different problems requiring different decision owners.
The fictional programme introduces distinct events and a consistency check, then observes whether defects recur in new batches. That provides more information than a snapshot immediately after cleaning. Operations also reviews a sample to detect records that pass automated checks but remain wrong. State the sample's limits. No control justifies a promise of perfect data; the aim is sufficient reliability for a defined decision and a workable response when uncertainty remains.
Make quality a release condition
Before migration or launch, specify critical rules, admitted exceptions and the authority accepting residual risk. Preserve results and tested populations. An average is insufficient when an important category remains unusable. In the example, the team authorises standard batches but defers batches recovered from an old system. A bounded decision avoids both a disproportionate global block and concealment behind a favourable overall score. Record what the restricted release permits and who reviews the deferred population.
After launch, transfer the register and authority into service ownership. Continue observing controls after the programme ends. Correction workload, decision delays and recurring defects help measure value. The hidden project becomes visible when the sponsor can see the cost of absent definitions and fund their resolution. A first scope connected to an important decision can establish governance and a reusable method without attempting to repair every dataset simultaneously.
Select critical data for the sector
Manufacturing needs consistency between physical events, batch identifiers, logistics and planning. Financial services may depend on shared counterparty definitions and event meanings for reconciliation. Public services need eligibility information that supports understandable decisions and accessible correction. Professional services need engagement statuses and workload periods understood consistently by planning and billing teams. These are design examples, not observed client outcomes or mandatory thresholds. Ask who can decide despite a defect, what evidence is missing and which exception is acceptable.
Quality is a relationship between data and use, with an accountable owner and a traceable decision. A dashboard can support that relationship; it cannot replace agreement on definitions, consequences and responsibilities.
Official sources and consultation date
Sources checked in October 2026. They support a structured, fit-for-purpose approach. Rules, thresholds and cases above are independent teaching examples.
- GOV.UK — The Government Data Quality Framework, published 3 December 2020.
- GOV.UK — The Government Data Quality Framework: guidance, 2020 publication consulted in its current version.