FIX-001-1
Add the product code to the category reference and reload the affected line.
- Submitted by
- Product data owner
- Review
- Ready for retest
KPI Definitions and Data Quality
Reporting Data Issue and Retest Register
A reporting data incident register that holds an affected report section, separates the product-record correction from independent retest and records release, limitation or reopening without erasing history.
Project previewOpen full image
The retained workbook covers 60 issues across 6 reporting cycles and follows OL-0001001 from a failed product mapping to an independent SQL retest and the decision to publish or hold the report.
A supplier category disappeared
One missing product code removed £5,747.91 from two monthly reports.
A wholesale distributor's supplier report groups order lines by product category. In the initial quality run, OL-0001001 carries PRD-UNKNOWN, so it cannot join to Product category 06.
The reporting analyst must decide what the missing line affects. The product data owner corrects the reference table, a separate reviewer reruns the failed SQL check, and the reporting owner decides whether the two reports can be issued.
Decision: hold the supplier-category sections until FIX-001-1 is accepted and RT-001-1 returns PASS; then record DEC-001 and release both reports.
The visual signature
The correction history and the retest history are deliberately separate.
The product data owner fixes the missing code. The independent reviewer then reruns the SQL check and records whether the row can return to the two monthly reports.
- FixFIX-001-1
Add the product code to the category reference and reload the affected line.
- RetestRT-001-1: PASS
OL-0001001 maps to Product category 06
- ReleaseRELEASE
The fix passed an executed independent retest.
From failed row to a publish or hold outcome
A corrected record is not proof that the report is safe to release.
The register keeps the failed row, business impact, workaround, fix record, independent retest and publish or hold outcome as separate records. A repeat failure reopens the original issue instead of replacing its history.
- 01Detected
DQ-02 retains the failed row and the report it affects.
- 02Triaged
High severity follows from the stated business impact.
- 03Assigned
Product data owner owns the product-code correction and due date.
- 04Workaround agreed
The reporting owner holds the supplier category section.
- 05Fix in progress
FIX-001-1 identifies the changed product record.
- 06Ready for retest
The reporting analyst checks the fix record before a separate reviewer tests it.
- 07Retested
The retained SQL returns PASS.
- 08Closed
Reporting owner records whether the report is published or held.
- 09Reopened
A later run can return the same issue to active correction without erasing its first closure.
Native Excel register
60 issues retain their report impact and release condition.
The generated register covers 6 reporting cycles from 2025-07 to 2025-12. Its summary formulas count releases, holds, accepted limitations, retests and closures from the issue and retest sheets.
The workbook is built from the executed DuckDB model and retained CSV records. It is evidence from the claimed tool, not a web dashboard standing in for it.
Follow OL-0001001
PRD-UNKNOWN becomes PRD-01001, then the same check returns PASS.
The order line contains 21 units at £273.71. The initial category mapping is absent. After the reference table is corrected, the line joins once to Product category 06. The reporting owner records RELEASE only after the independent result is linked.
- Issue
- DQI-2025-07-001
- Detection run
- DQ-2025-07-INITIAL
- Owner
- Product data owner
- Due date
- 2025-07-06
Complete retained history
Eight linked events connect detection to the release record.
- 012025-07-03 · Reporting analystFailed check recorded
DQ-02 failed for OL-0001001 in run DQ-2025-07-INITIAL.
3b9a2c88764c… - 022025-07-03 · Reporting analystImpact assessed
High because The supplier category total excludes one order line and two monthly reports cannot be released as prepared.
ece1661eba9e… - 032025-07-03 · Reporting analystOwner assigned
Assigned to Product data owner; due 2025-07-06.
21ac35a29fba… - 042025-07-03 · Reporting ownerReport section held
Hold the supplier category section and retain the affected lines outside the report total.
94bab3f9a470… - 052025-07-04 · Product data ownerRecord correction submitted
The owning team corrected the failed business record.
6cef624548f4… - 062025-07-04 · Reporting analystFix record accepted for retest
FIX-001-1 identifies the changed business record.
475d6341af05… - 072025-07-05 · Independent data-quality reviewerIndependent retest passed
Release affected report
b05f0767f7cd… - 082025-07-10 · Reporting ownerClosure approved
The fix passed an executed independent retest.
0269e69cc645…
Evidence keys: DQ-2025-07-INITIAL → COR-001-1 / FIX-001-1 → RT-001-1 → DEC-001.
Affected-report lineage thread
The failed field is connected to the reports that use it.
For the featured order line, the missing product code travels from the order management system through quality rule DQ-02 and into Supplier quality report; Monthly purchasing review. That thread tells the analyst which report sections to hold and tells the owner which reference table to correct.
- 01Business recordOL-0001001
Order management system order line
- 02Failed fieldproduct_id
PRD-UNKNOWN has no supplier category.
- 03CheckDQ-02
Reporting mart quality gate
- 04Held reportSupplier quality report
Supplier category section cannot be issued.
- 05Second reportMonthly purchasing review
Monthly purchasing review waits for the same correction.
- 06Publish or hold outcomeRELEASE
PASS retest recorded before report release.
Two decisions, two records
The product owner completes a fix. The reviewer decides whether it passes.
RT-001-1: PASS
OL-0001001 maps to Product category 06
- Executed by
- Independent data-quality reviewer
- Decision
- Release affected report
Closure can be reversed
DQI-2025-12-051 reopened when the same condition returned.
The issue concerns DQ-06: Unexplained negative quantity in Order management system.order_lines.ordered_quantity. Its first fix passed, but a later quality run returned the failure. The register adds a Reopened event, a second fix record reference and another independent retest under the original issue ID.
- History events
- 13
- Owner
- Customer service analyst
- Final retest
- PASS
- Report release
- RELEASE
- 30 NovReporting analystFailed check recorded
DQ-06 failed for OL-0002001 in run DQ-2025-12-INITIAL.
- 01 DecCustomer service analystRecord correction submitted
The owning team corrected the failed business record.
- 02 DecIndependent data-quality reviewerIndependent retest passed
Release affected report
- 02 DecReporting ownerFirst closure approved
The first fix passed retest and the affected report was released.
- 04 DecReporting analystRepeat failure reopened issue
The next quality run returned the same failed condition.
- 05 DecCustomer service analystRecord correction submitted
The owning team corrected the failed business record.
- 06 DecIndependent data-quality reviewerIndependent retest passed
FIX-051-2 leads to PASS.
- 07 DecReporting ownerClosure approved
The second fix passed after a later run reopened the issue.
Two states that must remain distinct
Reopening resumes the correction. A limitation permits a controlled release.
Neither state erases the failed condition. The register keeps the owner, affected report, retest result and release basis visible so a reviewer can tell whether the correction resumed or a named exception was accepted.
DQI-2025-12-051
DQ-06: Unexplained negative quantity returned after the first closure. The original issue ID stays active through FIX-051-2and a second independent PASS retest.
- Owner
- Customer service analyst
- Report release
- RELEASE
DQI-2025-11-047 · OL-0001046
The FAIL retest does not prove a fix. The affected row remains excluded from Product service level and supplier score, and the reporting owner records DEC-047 with this explicit note: The affected record remains excluded and the report states the category-level limitation.
- Owner
- Product data owner
- Report release
- RELEASE WITH LIMITATION
Recurring causes, not a single quality score
Reference data caused the largest share of retained issues.
The framework groups incidents by the condition that created them. Counts reconcile to the register, and reopened incidents remain visible inside their original category.
Reference data explains 50 of 60 issues, so the owner review starts with product and customer reference tables before smaller process and extract causes.
High535.9 average days
Medium57.0 average days
Low20.2 average days
Verified build position
The lifecycle is exercised across six monthly reporting runs.
60issues reviewed
469history events
56executed retests
28 / 28build controls pass
The register records 44 releases, 10 holds, 4 releases with a stated limitation and 2 merged duplicates.
What runs here and what remains a tenant design
The local build is executable. The Microsoft 365 workflow is documented for deployment.
Executed locally
Python, DuckDB and Excel
The build selects failed rows, creates issues and history, runs the featured SQL retest, checks the register and writes the Excel workbook.
Retained deployment design
Microsoft Lists and Power Automate
List schemas define current issues and append-only history. The flow definition covers assignment, SLA reminders and review notifications without claiming that a live tenant or production notification exists.
Checks before report release
Release, retest, lineage and history must agree.
- 01
Every issue retains the detection run, failed field, affected report, owner, due date and publish or hold outcome.
- 02
Severity and SLA follow a documented impact policy rather than a colour selected by the analyst.
- 03
The fix record and independent retest are separate records with separate roles.
- 04
A report cannot be released without a passing retest or a stated, approved limitation.
- 05
Every lifecycle event keeps its prior hash, so a later change breaks the retained history chain.
- 06
Root-cause totals, issue totals and cycle totals reconcile to the same generated register.
- 07
The featured SQL returns one corrected line, the expected category and a passing result.
The native verifier reran the analytical build and web-evidence renderer, then matched 29 retained data and image files byte for byte. It also inspected 13 workbook sheets and 8 evidence-image families.
Data and limits
Generated records demonstrate the operating model, not a live observability service.
The build uses a deterministic non-client order and delivery dataset, seed 240605: 120,000 orders, 250,000 order lines and 180,000 delivery events and 60 reporting incidents.
- The deterministic generated records do not measure a real distributor, supplier or reporting team.
- The register covers defects raised by the configured checks; it does not prove every retained value or reporting rule is correct.
- The Microsoft Lists and Power Automate files are deployment designs; no live Microsoft 365 tenant or production notification is claimed.
- The severity thresholds, escalation recipients and service levels are sample settings that a real organisation would need to approve.
- An accepted limitation permits a controlled sample release; it is not evidence that the failed condition was corrected.
- The local build demonstrates a contained reporting incident process, not enterprise-wide data observability or an audit opinion.
Technical detailsView the data, rebuild steps and detailed limits
A passing retest proves only that the named query passed for the retained record. The project does not demonstrate enterprise-wide monitoring, live Microsoft 365 notifications, production security or an audit opinion.
Customer service and warehouse operations
Order and Delivery Data Quality Checks
Incomplete or contradictory order records are stopped before the monthly service report. Each failed row keeps a specific reason, the team that can correct it and the result of the next test.
What it helps answer: Can the service report be released, released with a stated limitation or held for correction?
- Platform
- Configuration-driven SQL and Python checks
- Data scale
- 120,000 orders, 250,000 lines and 180,000 delivery events, verified
- Project status
- The Python and DuckDB checks run successfully, and all 15 rules pass a separate retest.
Wholesale distribution
Order-to-Delivery Metric Dictionary
Finance reports on-time delivery at customer receipt. Operations uses dispatch date, while one report counts delivered lines. The project agrees how partial and cancelled orders should be counted.
What it helps answer: Which on-time delivery definition belongs in the monthly service report, and how should split, partial and cancelled orders be treated?
- Platform
- SQL, Excel and Power BI measure definitions
- Data scale
- 120,000 orders, 250,000 lines and 180,000 delivery events, verified
- Project status
- The Excel catalogue and SQL calculations have been checked. Matching DAX and TMDL files are included, but have not been run in Power BI Desktop.
Next step
Keep a reporting defect connected to the record, correction, retest and decision to publish or hold the report.
Start with the measures people dispute or the failed checks that need clearer ownership before reporting.