Insight-to-decision presentation · Seven sections · Scroll to read
Synthetic demonstration · 12 respondentsA QIB diagnostic of where data-quality responsibility stops short of durable resolution
People can finish a report by correcting a dataset locally. When a similar problem returns on the next refresh, that success may have concealed unfinished system work.
This synthetic demonstration uses employee experience to distinguish a problem with finding the owner from one with getting a source problem resolved.
Working question: What causes a known source problem to be repeatedly absorbed downstream?
The snapshot connects recurrence, known ownership, and local remediation—not just their separate rates.
The loop is a diagnostic hypothesis from recurring experiences and comments, not a verified chain for one unique defect.
Six of seven assessable employees had personally seen a similar issue with their data source/process. Every one of those six identified an existing responsible party. Five nonetheless reported either local correction with unknown source status or a workaround instead of a confirmed source fix.
This looks less like a routing failure and more like a potential learning/repair-loop failure: the immediate deliverable is recovered, but durable prevention is not reliably visible.
A possible data-cascade mechanism is visible: repairing an output is easier to observe than eliminating the condition that required repair.
“We reconstruct missing outcome fields from partner workbooks each month. The data team knows the source is incomplete, but upstream changes keep getting deferred.”
“Two dashboards use incompatible program-status definitions. We remap categories for every report because the original intake fields have not changed.”
The more revealing question is whether the identified owner can authorize, prioritize, or coordinate a lasting fix.
For the five most recent incidents where the owner was already clear, respondents reported three work-specific corrections with uncertain source status and two workarounds without source correction. That is a striking contrast to the conventional instinct to solve data problems with an ownership inventory.
The comments point to at least two possible binding constraints: a known owner without capacity to change an import process; and an external-data authorization decision with no agreed decision-maker.
Investigate whether the bottleneck is capacity, authority, competing priorities, or external dependency before redrawing job responsibilities.
“We correct duplicate case records downstream in each report. The source-system owner is known, but does not have capacity to change the import routine.”
“We still do not know who can authorize access to the external data. Several people have offered to help, but there is no agreed decision maker.”
“We found the source owner and corrected a misleading field definition before the team used the results. The correction went into the data dictionary.”
The effects appear in both the task and employees’ broader assessment of how data issues get resolved.
Counts as reported in Q2 × Q9 cross-tab; not a causal or population relationship.
Extra checking/cleaning or retrieval affected six of eight people describing recent incidents; four reported delays, and four reported reduced confidence. All six recurrent cases were paired with extra work in the snapshot’s recurrence-by-effects table.
Among employees reporting zero problems, both rated remediation well/very well (2/2). Among those reporting 3–9 occasions, three of four rated it poorly/very poorly. The directional contrast is worth investigating, not generalizing.
Repeated friction likely matters more than isolated defects. Preserve early validation and disciplined scope changes—the survey contains concrete examples of both.
“We validate row counts and required fields whenever a new file arrives, and we compare definitions with the previous cycle.”
“Our shared data dictionary and a designated steward make it easy to confirm data are usable before analysis.”
“The available sample excluded several smaller programs. We revised the analysis scope instead of pretending the data represented everyone.”
The right management lever depends on where the fault originates—and whether correction is worth making.
| Problem type | Observed pattern | What to test | Research |
|---|---|---|---|
| Missing fields / duplicates / mismatched definitions | Repeated manual reconstruction and report-level corrections | Prioritize the source change; add one lightweight intake check | Breck et al., SysML (2019), Sambasivan et al., CHI (2021) |
| Partner files / access permissions | Delayed files or unresolved authorization | Name the decision authority and agree a stable access route | UK Government Digital Service (2025) |
| Unrepresentative / unfit data | Some outcomes should not be fixed by cleaning | Document an acceptable scope, exclusion, or no-go decision | DataKind, Data Audit Playbook |
Rows are management pathways, not mutually exclusive theme frequencies.
The most recent problems span missingness, conflicting values, access, unclear meaning, and suitability. This variety argues against buying a broad cleaning or governance system before locating the consequential repeating sources.
Research supports different responses: production validation for predictable anomalies, accountable authority for access and stewardship decisions, and early data auditing for fit-for-purpose judgments.
A focused source pilot can determine which of these pathways creates actual value, while preserving justified limitation decisions.
“Two dashboards use incompatible program-status definitions. We remap categories for every report because the original intake fields have not changed.”
“We still do not know who can authorize access to the external data. Several people have offered to help, but there is no agreed decision maker.”
“The available sample excluded several smaller programs. We revised the analysis scope instead of pretending the data represented everyone.”
Proposed experiment, not a decision already made. Choose deliberately, assign authority, and inspect what happens next.
Select one consequential repeating defect, verify its practical origin, and document the owner who can authorize a source change. Keep a temporary workaround only when needed and record why it is acceptable.
Check the actual next data extract or process execution, not just whether a report was delivered. Then repeat comparable QIB questions over a four-week window to see whether the experience changed.
The hypothesis is testable: if the source is durably corrected, repeated local cleanup should decline on comparable work. A failure to improve should trigger a competing-explanation check.
Better data remediation means closing the loop between the person who discovers a problem and the source that creates it.
In this 12-person synthetic demonstration, the standout signal is not missing ownership: all six people who recognized recurrence could identify an existing owner, but five reported local correction of uncertain source status or a workaround.
Comments illustrate deferred upstream changes and capacity/authorization barriers. Academic and professional research suggests why unresolved data work can accumulate downstream and why accountable authority and early validation matter.
“We correct duplicate case records downstream in each report. The source-system owner is known, but does not have capacity to change the import routine.”
Pilot one consequential repeating source defect, establish a decision-maker who can authorize correction, check the next extract, and repeat the QIB on a comparable four-week window.