Search/Keep Data Good Enough for Its Real Use, from Collection to Disposal

Keep Data Good Enough for Its Real Use, from Collection to Disposal

Use when data feeds decisions, reports, or services. Defines quality by how the data is used, names owners, sets checks at each stage from collection to sharing and disposal, measures each kind of problem separately, and fixes the root causes of repeat errors.

To use this AI rule
## Define Good Data by What It Will Be Used For Treat quality as the degree to which data can support a specific decision, service, analysis, or obligation. A dataset can be well-formed yet unsuitable for a particular use, so begin with context rather than a generic promise that the data is “good.” - Name the intended users, decisions, outputs, and consequences of error. - Record the minimum acceptable thresholds for the qualities that matter to that use. - Separate observable evidence from assumptions about fitness. - Reassess suitability when the purpose, users, or operating environment changes. ## Name an Owner for Each Dataset and Each Fix Make quality a shared operating responsibility with clear decision rights. Senior leaders fund and prioritize the work, accountable owners accept residual risk, specialists design controls, and people who create or handle data apply them in daily practice. - Give each important dataset, control, issue, and remediation action a named owner. - Define who can accept exceptions and who must be informed. - Train contributors in the standards and checks relevant to their role. - Review capability gaps, recurring defects, and overdue actions at a regular cadence. ## Ask How People Actually Use the Data and Rank Fixes by Impact Gather evidence about how data is actually consumed, not only how its producer expects it to be used. Different users may need different levels of freshness, detail, coverage, or precision, and one improvement may benefit one use while weakening another. - Interview representative producers, processors, analysts, operators, and recipients. - Map each use to decisions, dependencies, failure impact, and tolerance for uncertainty. - Prioritize improvements by user value, harm avoided, reach, and implementation cost. - Revisit priorities when demand changes or a new high-consequence use appears. ## Set Checks for Every Stage, from Planning to Disposal Model the lifecycle as a connected loop: plan; acquire; prepare and maintain; use; share; then retain or dispose. Quality work must follow the data across those stages because defects introduced early may remain hidden until a later decision or publication. - Define entry criteria, exit criteria, validation, evidence, and ownership for every stage. - Trace important fields from origin through transformations to final outputs. - Return an issue to the earliest stage where its cause can be removed. - Preserve enough lineage and decision history for a reviewer to reconstruct what happened. ## Catch Bad Values When Data Is First Entered or Collected Prevent avoidable defects at the point of capture. Collection rules should make expected values easy to provide, reject impossible values without hiding legitimate exceptions, and retain enough context to explain the source and meaning of each record. - Validate required fields, formats, ranges, identifiers, and reference values. - Detect missing, repeated, conflicting, or unexpectedly changed records. - Record provenance, collection time, definitions, and known transformations. - Provide a feedback route so downstream users can report defects to the source owner. ## Compare Counts and Totals Before and After Data Is Processed Protect meaning while data is standardized, linked, transformed, migrated, or refreshed. Automate stable checks where practical, but keep human review for ambiguous relationships, material anomalies, and changes that can alter interpretation. - Test transformations against documented rules and representative edge cases. - Reconcile counts, totals, keys, and critical attributes before and after processing. - Monitor drift, stale records, schema changes, broken links, and unexplained volume shifts. - Version definitions and controls together with the systems that implement them. ## Check the Data Still Fits Before It Is Used or Shared Before an analysis, operational release, or external share, verify that the data remains suitable for that exact use. Apply access, privacy, disclosure, and quality controls together, because technically valid data can still cause harm when context or safeguards are missing. - Review material outputs against source evidence and known limitations. - Publish or transfer the definitions, lineage, quality findings, and permitted uses with the data. - Record corrections and notify affected recipients when a defect changes a prior conclusion. - During retention or disposal, preserve integrity, audit evidence, and essential knowledge for the required period. ## Measure Each Kind of Data Problem Separately, Not as One Score Use separate measures for different failure modes instead of collapsing them into one score. At minimum, consider whether required values are present, entities are represented once, values agree across sources, data is current enough, values meet stated rules, and records reflect reality. - Define each metric with its population, numerator, denominator, exclusions, and time window. - Set thresholds by use case and risk rather than copying a universal target. - Keep rule conformance distinct from real-world correctness. - Add specialist dimensions when the decision depends on characteristics not covered by the core set. ## Tell Users What Was Tested and What Was Not Give users enough information to judge fitness for themselves. Quality reporting should state what was tested, what was not tested, the result, the business impact, unresolved uncertainty, and the owner and timing of the next action. - Use plain language while retaining the definitions needed for reproducibility. - Report both the current status and the direction of change. - Explain trade-offs, such as releasing earlier with less coverage or waiting for stronger assurance. - Distinguish confirmed defects, suspected risks, accepted exceptions, and unknowns. ## Fix the Root Cause of Repeat Errors and Close Issues with Proof Treat recurring defects as signals of a weak process rather than isolated cleanup tasks. Contain immediate harm, investigate how the defect entered and escaped detection, then change the earliest effective control and verify that the change works over time. - Log issues with severity, affected uses, evidence, owner, due date, and status. - Analyze patterns across incidents, stages, sources, and controls. - Compare results with thresholds and prior periods to identify deterioration or improvement. - Close an action only after evidence shows the root cause is controlled and no material downstream impact remains.