Software Engineering
Data Quality Fixes Don't Stop System From Using Its Own Output in Verification
Structural improvements to data provenance tracking failed to prevent verification routines from relying on system-generated values, revealing a fundamental mismatch between where fixes target and what decisions actually consume.
Two safeguards designed to fix a production system's reliance on its own data for verification decisions—row-level grading and controlled write access—achieved their technical goals but left the underlying problem untouched, according to a measurement study of 194,620 records.
The Problem Being Addressed#
A companion paper had identified a critical flaw: verification routines were using data that the system itself had generated, rather than drawing only from independent observations. This created a logical circularity where a system was essentially verifying itself. The study tested whether two established defensive practices from other disciplines could break this cycle.
The Interventions Tested#
The first defense implemented structural grading on every row, assigning quality scores so verification routines could distinguish system output from external data. The second introduced single-point write control, ensuring that grade assignments were enforced by architecture rather than mere convention.
By the numbers:
- Expanding grade classification raised coverage from 36.1% to 98.4%
- A single ingress requiring grade validation rejected 3,070 attempted writes
- Filtering verification queries by grade flipped both test decisions from passing to undetermined
Why the Fixes Missed the Mark#
The prescriptions themselves are sound—both are established best practices in other fields. The problem is architectural mismatch. The defenses operate across the entire dataset, making broad improvements without knowing which specific records any given decision would actually consult. When researchers examined the overlap between records each intervention repaired and the 32 rows that the two verification decisions actually read, there was no intersection.
The most dramatic example illustrates this gap: the largest intervention reclassified 121,296 rows from unnameable to properly named status—yet all of those records fell outside the query windows that either decision would access.
Why This Matters#
The findings indicate that structural defenses at the system level may not translate into operational protection for specific verification routines unless they target the right data slice. The two decisions remain blocked, but for different reasons—a distinction that suggests different solutions may be needed for each.