PASS
Pass
The observed result met the agreed threshold.
Retain the run result and continue.Data 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.
A delivered order with no customer code cannot be assigned to the customer group used in the monthly service report. An unknown product code can remove a complete supplier category from the monthly score.
A count of failed references is not enough. The reporting analyst needs the affected order keys, the result that would be wrong and the data owner who can correct the customer or product table.
The row remains held until the same rule runs again. The original failure, corrected customer or product record, independent retest and release decision stay connected for the reporting owner.
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.
INITIAL VALIDATION RUNOrder and delivery records
- Rows
- 550,000
- Rules
- 15
- G1PASS
Schema
Columns · types · keys
- G2WARNING
Data
Required · unique · timely
- G3FAIL
Business
Sequence · references · totals
REPORTING DECISIONHold monthly service report
Release only after all 15 checks pass
FAILED RECORDS244 rows failed; 238 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
RETESTSame rule, retained result
01 · Input and run metadata550,000 order, line and delivery records
02 · PASSSchema rules
Columns · types · keys
03 · WARNINGData 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 15 checks pass
PassThe rule met its threshold.
WarningThe 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.
WARNING
Warning
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.
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 readiness decision.
Executable project evidence
Four builds connect failed records to a report decision.
The retained builds cover validation, issue history, SQL controls and metric reconciliation. Their project pages explain the input records, execution, tie-out and limitation behind each view.
01
Executed rule results
Order and Delivery Data Quality Checks
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.
The initial run separates 15 failures, three warnings and one execution error. Each row also retains the affected report section and correction reason.Inspect this project02
One reporting incident from detection to release
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.
PRD-UNKNOWN is replaced by PRD-01001. The retained SQL returns Product category 06 and PASS before the reporting owner releases the corrected report.Inspect this project03
Executed mart and release results
SQL-backed Reporting Foundation
A wholesale reporting mart built from Microsoft’s Wide World Importers sample database so sales, purchasing, stock and margin reports use the same customers, products, dates and totals.
The retained result combines the actual query result with the release decision. It shows what loaded, what the latest monthly mart contains and whether the checks allow publication.Inspect this project04
Exact percentage bridge
On-time Delivery Metric Reconciliation
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.
Calculation, event-date, record-grain and extract-population adjustments bring every reported version to the same numerator and denominator with no residual.Inspect this projectTechnical 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 a reporting check into an executable rule that retains the failed rows, run time, affected report and later retest.
See how it is used in projectsSQL
SQL gives invoice lines, orders, receipts and reference data a declared grain before they become shared reporting totals.
See how it is used in projectsExcel and Power Query
Excel and Power Query are used when people need a familiar workbook without hiding file intake, transformation logic, adjustments or checks.
See how it is used in projectsEvidence boundary
A check can show what failed. It cannot prove unrecorded activity is complete.
Checks test observed data against agreed rules. They do not prove that unobserved real-world activity is complete, and a failed check becomes an incident only when its threshold or reporting impact warrants managed resolution.
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