Why a data fix does not release the report

Why is correcting a missing product code different from proving the monthly report is safe to release?

The correction changes the source or reference record. Release requires separate evidence that the affected row now passes the intended check and that the report consequence has been resolved.

Quanta Meridian2026-07-265 minute research brief

Reporting data issue register showing a missing product category, correction, independent SQL retest and report release — Executed incident traceThe missing category returns only after retest
The retained register follows OL-0001001 from PRD-UNKNOWN to PRD-01001, Product category 06, a passing SQL result and the release decision.

Issue DQI-2025-07-001 began when order line OL-0001001 used product code PRD-UNKNOWN. The missing mapping removed Product category 06 from the supplier report and held £5,747.91 outside the category total. The product-data owner supplied the mapping on 4 July, an independent reviewer executed the retained SQL on 5 July, and the reporting owner released the report on 10 July.

The correction and the release answer different questions

The product-data owner is responsible for adding PRD-01001 to the reference table. That action repairs the known cause, but it does not show whether the reporting query picked up the change, whether the affected row maps once or whether the supplier total now includes the value.

The retest uses the corrected order-line table and product reference to return the line, its category and the affected value. A pass requires one mapped category and no failed record. Only then does the reporting owner decide whether the held report section can be released.

Independence is a control, not a job title

The retained history separates the person who changed the mapping from the person who ran the test. This does not make the work an audit. It reduces the risk that the same person treats completion of their own fix as proof that the reporting consequence has disappeared.

The history keeps detection, containment, assignment, correction, retest, release and closure as separate events. A failed retest can therefore return the issue without erasing the correction that was attempted.

Research record

Question, method and finding

Research question: What evidence should separate a submitted data correction from a decision to release the affected report?
Source: Quanta Meridian: Reporting Data Issue and Retest Register; Quanta Meridian: Order and Delivery Data Quality Checks; Microsoft Purview: Data quality thresholds; Great Expectations: Retrieve unexpected rows
Method: The review compared the seven retained history events for DQI-2025-07-001 with the failed-row output, the correction record, the executable SQL retest and the final report decision. Current Microsoft Purview threshold guidance and Great Expectations failed-row guidance were used as implementation benchmarks.
Finding: A correction becomes release evidence only when a separate test runs against the corrected record and the affected reporting rule. In this case the mapping fix was submitted on 4 July, the independent SQL retest passed on 5 July and the reporting owner released the report on 10 July.
Limitation: This is one deliberately generated non-client issue. The passing query proves the specified product mapping and affected value; it does not prove that every field or supplier total in the report is correct.
Implication: A reporting issue workflow should keep the attempted fix, retest result, tester, affected report and release decision as separate records. Marking the fix complete should never close the report hold by itself.

Implementation evidence

Executed product-mapping retest

This excerpt is checked against the retained sql source used by the project build.

select
    line.order_line_id,
    line.product_id,
    product.product_category,
    round(line.ordered_quantity * line.unit_value, 2) as affected_value,
    case
        when product.product_id is not null then 'PASS'
        else 'FAIL'
    end as retest_result
from source_quality.order_lines_retest as line
left join source_quality.product_reference as product
    on line.product_id = product.product_id
where line.order_line_id = 'OL-0001001';

Retained comparison

Featured issue chronology

The dates and values come from the retained issue trace.

Date	Event	Responsible role	Result
3 July 2025	Failed mapping detected and report section held	Reporting analyst and reporting owner	OL-0001001 excluded from Product category 06
4 July 2025	Reference mapping submitted	Product-data owner	PRD-UNKNOWN corrected to PRD-01001
5 July 2025	SQL retest executed	Independent data-quality reviewer	Pass; £5,747.91 maps to Product category 06
10 July 2025	Supplier report released	Reporting owner	Release recorded after the passing retest

Records behind the finding

Inspect the correction and independent retest

Supplier reportingReporting Data Issue and Retest Register

Order line OL-0001001 moves from PRD-UNKNOWN to PRD-01001, Product category 06, a passing independent SQL retest and report release.

Inspect project →Customer service and warehouse operationsOrder and Delivery Data Quality Checks

Delivered order ORD-0000001 is held because its customer code is missing, corrected by the customer data owner and admitted only after DQ-01 passes an independent retest.

Inspect project →

Sources

Sources used to answer the research question

Reporting Data Issue and Retest RegisterQuanta Meridian
Issue history, correction, executed SQL retest and release record.
Order and Delivery Data Quality ChecksQuanta Meridian
The failed-row and affected-report records that initiate the issue.
Data quality thresholdsMicrosoft Purview
Benchmark for applying thresholds according to the intended use of the data.
Retrieve unexpected rowsGreat Expectations
Benchmark for retaining the records that fail a data-quality expectation.