CompletenessDQ-10
Is every expected monthly order file present?
A missing month changes the report population and its denominators.
Initial FAIL · independent retest PASSData Quality
Hold incomplete order records before they distort the monthly report.
For reporting, data and operational teams that need to decide whether a scheduled report can be issued, limited or held.
Quanta Meridian shows which order or delivery row failed, which service or supplier result would be wrong, who must correct the customer or product record and what the independent retest found.
When data needs a controlled response
The problem is not only that a value failed a check.
Order ORD-0001041 records customer receipt on 16 November and warehouse despatch on 17 November. That impossible sequence would produce a negative delivery cycle time if it entered the monthly service report.
A failure count alone cannot tell the reporting analyst what to do. The retained row must show the two events, DQ-04, the affected delivery measures and the warehouse systems analyst responsible for correcting the warehouse timeline.
The order remains outside on-time and cycle-time reporting until an independent reviewer runs DQ-04 again. The original events, amended dates, retest and decision to include or exclude the order stay connected.
Validation field
Keep the failed record connected to the reporting decision.
Rules test the batch in order. Material failures retain their record keys, affected report and owner, then return through the same rule for retest.
ValidityDQ-18
Is every order date on or before the reporting cut-off?
A future-dated order cannot enter the December reporting period.
Initial FAIL · independent retest PASSReconciliationDQ-12
Does order-line value tie out after duplicate removal?
A residual difference holds sales value and margin from release.
Initial FAIL · independent retest PASSINITIAL VALIDATION RUNOrder and delivery records
- Rows
- 550,000
- Rules
- 19
- G1PASS
Schema
Columns · types · keys
- G2REVIEW
Data
Required · unique · timely
- G3FAIL
Business
Sequence · references · totals
REPORTING DECISIONHold monthly service report
Release only after all 19 checks pass
FAILED RECORDS250 rows failed; 241 orders held
Record key · rule · value · expected condition
AFFECTED REPORTMonthly service report
Customer, product and on-time delivery results
OWNER RESPONSECorrect · accept · escalate
Evidence and target retest remain in history
RETEST19 / 19 pass
01 · Input and run metadata550,000 order, line and delivery records
02 · PASSSchema rules
Columns · types · keys
03 · REVIEWData rules
Required · unique · timely
04 · FAILBusiness rules
Sequence · references · totals
05 · Failed-record branchRetain records and assess report impact
Assign an owner only when the threshold or impact warrants it.
06 · Resolve and retestRun the same rule and retain both results
07 · Reporting decisionHold until all 19 checks pass
Follow one failed order through correction and retest
The same rule fails, the warehouse record is corrected, then the retest passes.
Order ORD-0001041 is excluded from delivery measures when its customer receipt appears before warehouse despatch. The original events remain beside the corrected timeline.
- 01Initial warehouse events
Customer receipt · 2024-11-16
ORD-0001041 · quantity 10
Warehouse despatch · 2024-11-17 - 02DQ-04 · FAIL
Customer receipt is dated one day before warehouse despatch.
Hold on-time delivery and order cycle-time reporting - 03Warehouse correction
Correct the two retained event dates and preserve the amended timeline.
Warehouse systems analyst - 04DQ-04 · PASS
Warehouse despatch · 2024-11-16
Independent data-quality reviewer
Customer receipt · 2024-11-17
Publish or hold: The order is admitted to delivery cycle-time and on-time reporting.
View the rule and failed rowsPassThe rule met its threshold.
ReviewThe result needs review but does not automatically block.
FailThe rule breached its agreed threshold.
ErrorThe check could not complete, so no quality conclusion is made.
Result states
State what happened before deciding what to do.
Status is written as text and paired with its consequence. Colour is used only to help scanning.
PASS
Pass
The observed result met the agreed threshold.
Retain the run result and continue.REVIEW
Review
The result needs review but does not automatically block the report.
Assess impact and record any limitation.FAIL
Fail
The observed result breached the threshold for this reporting purpose.
Hold or limit the affected report and assign the failed rows as agreed.ERROR
Error
The check did not complete, so it cannot support a quality conclusion.
Resolve the execution problem and run it again.Data-quality review history
Carry the rule, failed records and decision through one history.
The same configured check is used for the first run and retest so the correction can be compared with the observed failure.
Each check names the order or delivery fields tested, the threshold and the report consequence. The run keeps its input period, identifier, time, observed result and failed record keys.
A missing customer code is assigned to the customer-data owner; a missing product mapping goes to the product-data owner. The reporting owner records whether the affected page is held or issued with a stated limitation.
After the customer, product or delivery record is corrected, the same rule is run again by a second analyst. Only a passing retest and reconciled row total allow the held row or report page to return.
Check result and incident
A failed check is evidence. An incident is a managed response.
What one rule observed in one run
It records the rule, threshold and severity alongside the input, run time and result state. Failed record keys retain the observed values and show which measure or report is affected.
How a material failure is resolved and closed
It adds impact, urgency and recurrence, then keeps the data owner’s response, correction or accepted limitation. Retest evidence supports the final closure decision and history.
A bounded first review
Start with one report that cannot yet be released.
The first engagement does not require a platform programme. It establishes whether one material result is blocked by missing records, invalid values or a reconciliation difference, then names the control and owner needed next.
- Bring
- One scheduled report, whether it is currently published or held, and the order rows or received files people suspect are incomplete or contradictory.
- First review
- Map the failed condition to the affected measure, severity, responsible data owner and evidence needed for retest.
- Leave with
- An agreed rule, failed-row trace, reporting boundary and a controlled next step for correction or accepted limitation.
The check and retest package
Controls that can be run, investigated and handed over.
Define the controls
Agree what should be tested and what each result means for the reporting purpose.
The retained package contains rule, severity and threshold register and dataset, field and affected-report mapping.
Execute and investigate
Retain the run and the records needed to explain where the data failed.
The retained package contains configuration-driven SQL or Python checks and run metadata, failed records and quarantine table.
Resolve and monitor
Connect material failures to an owner, a reporting decision and evidence from the retest.
The retained package contains issue or accepted-limitation record and named owner, retest history and publish or hold outcome.
A finished example
Four featured builds show different parts of the control lifecycle.
Validation, incident history, model controls and metric reconciliation need different evidence. Each featured build keeps its input, execution, tie-out and limitation visible.
01
Executed rule results
Order and Delivery Data Quality Checks
Rule, correction and independent retest
Nineteen configured checks retain failed rows, owners and the publish or hold outcome before all 120,000 orders are admitted on retest.
A repeatable set of checks that stops incomplete or contradictory order records from entering the monthly service report and gives each failed row a specific correction reason.
Inspect Order and Delivery Data Quality Checks02
One reporting incident from detection to release
Reporting Data Issue and Retest Register
Managed incident and release history
A reporting defect keeps its consequence, correction, independent retest and publish or hold outcome together instead of disappearing from an issue list.
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.
Inspect Reporting Data Issue and Retest Register03
DuckDB mart results and report checks
Wholesale Sales, Margin and Stock Reporting Mart
Model and reconciliation controls
SQL checks protect declared grains, required relationships and incoming-to-report totals before shared reporting tables are released.
A reporting analyst prepares the wholesaler’s May sales, margin and stock report from invoice lines, supplier orders and warehouse movements, with each figure checked before finance, sales and warehouse managers use it.
Inspect Wholesale Sales, Margin and Stock Reporting Mart04
Exact percentage bridge
Why five reports show different on-time delivery rates
Cross-report metric reconciliation
Four implementations of one delivery measure are bridged to an approved definition and a zero-residual result.
A row-level reconciliation explaining why the SQL reporting mart, Power BI model, Excel management pack, operational extract and manually maintained report show different on-time delivery percentages.
Inspect Why five reports show different on-time delivery ratesTechnical patterns
Put the rule at the layer that can explain and maintain it.
Schema rules
Use when
Columns, types, keys or file structures must remain stable enough for the next process to run.
Boundary
A valid structure does not show that the values are complete, timely or meaningful for the report.
Data rules
Use when
Records need tests for completeness, uniqueness, validity, freshness, sequence or reference integrity.
Boundary
Thresholds must reflect the reporting purpose; a universal quality score cannot make that decision.
Business rules
Use when
Amounts, populations or states must reconcile to an agreed definition before a report can be issued.
Boundary
The rule needs a business owner and must not silently replace a disputed definition.
Issue response
Use when
A recurring or material failure needs ownership, impact assessment, a recorded data correction and independent retest.
Boundary
Minor warnings can remain check results. Creating an incident for every failed row adds noise without improving the data.
Related capabilities
Execute the check in the simplest maintainable environment.
Python
Python turns reporting rules and analytical methods into repeatable runs with declared inputs, retained results and tests another analyst can inspect.
Explore the Python capabilitySQL
SQL gives invoice lines, orders, receipts and reference data a declared grain before they become shared reporting totals.
Explore the SQL capabilityExcel and Power Query
Excel and Power Query are used when people need a familiar workbook without hiding file intake, transformation logic, adjustments or checks.
Explore the Excel and Power Query capabilityStart the review
Bring the report decision and one record that should not be trusted yet.
The first conversation can work from field names, rule wording and the reporting consequence. Confidential customer or employee records are not needed to decide whether a focused review is useful.
Bring one report, the records that cause concern and the decision due next. Confidential or protected data is not needed for the first conversation.
Discuss a data quality reviewReturn to all solutions