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 starts with a retained failed row and ends with verified closure, an approved limitation or a continued hold.
Verified Excel issue registerOpen image
The retained workbook covers 60 issues across 6 reporting cycles and traces OL-0001001 from a failed product mapping to an independent SQL retest and publication decision.
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.
From failed row to publication decision
A source fix is not proof that the report is safe to release.
The register keeps the failed row, business impact, workaround, fix evidence, independent retest and publication decision 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 source correction and due date.
- 04Workaround agreed
The reporting owner holds the supplier category section.
- 05Fix in progress
FIX-001-1 identifies the changed source record.
- 06Ready for retest
The reporting analyst checks the evidence before a separate reviewer tests it.
- 07Retested
The retained SQL returns PASS.
- 08Closed
Reporting owner records the publication decision.
- 09Reopened
A later run can return the same issue to active work 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 outputs. 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 correction, 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
The affected route is explicit
The failed field is connected to the reports that use it.
For the featured line, the path runs from Order management system.order_lines.product_id through quality rule DQ-02 and the reporting mart to Supplier quality report; Monthly purchasing review. That path tells the analyst what to hold and the owner what to correct.
Two decisions, two records
The source 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 evidence reference and another independent retest under the original issue ID.
- History events
- 13
- Owner
- Customer service analyst
- Final retest
- PASS
- Publication
- RELEASE
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.
Business process52 reopened
Reference data502 reopened
Schema change10 reopened
Source extract20 reopened
Timing10 reopened
Transformation10 reopened
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, validates the register and writes the native 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 publication
Release, retest, lineage and history must agree.
- 01
Every issue retains the detection run, failed field, affected report, owner, due date and publication decision.
- 02
Severity and SLA follow a documented impact policy rather than a colour selected by the analyst.
- 03
Fix evidence 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.
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.
Technical documentationOpen the retained data, rebuild command and detailed limitations
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.
Decision: 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
- Maturity
- Native Python and DuckDB build verified; all 15 rules pass on independent 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.
Decision: 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
- Maturity
- Native Excel catalogue and executed SQL verified. Equivalent DAX and TMDL retained; Power BI Desktop execution not claimed.
Next step
Keep a reporting defect connected to the record, correction, retest and release decision.
Start with the measures people dispute or the failed checks that need clearer ownership before reporting.