Load the declared inputs
The run records files, row counts, period, checksum where practical and run identifier.
Python
Use Python to show exactly which records failed and why.
For reporting and data teams that need repeatable checks, retained exceptions and a dependable retest before publication.
Quanta Meridian uses Python when a rule or analytical method needs controlled inputs, executable tests and outputs another analyst can reproduce.
The working question
Which rows can enter the report, which rows must be held and what evidence is needed before a corrected row can return?
Inspect the project evidenceThe order and delivery project runs 15 named checks across more than 100,000 records. A delivered order with a missing customer code is held because its service result cannot be assigned to the right customer group. The failed row, correction reason, affected report section and later independent retest all remain connected.
Execute named rules
Completeness, validity, consistency and timeliness checks use report-specific thresholds.
Retain failed rows
Each exception keeps its record key, observed value, correction reason and affected output.
Apply the correction
The source or reference-data owner fixes the record rather than editing the report result.
Run an independent retest
A second run proves whether the same rule now passes and whether the report may be released.
A failed count is not enough
Eleven unmatched product codes matter because those deliveries cannot be assigned to a category and must be excluded from the supplier score. The run therefore keeps the failed record keys and says which metric or report section would be wrong.
The rules distinguish a business failure from an execution error such as a missing file. That difference controls whether rows are held, a limitation is accepted or the complete report refresh stops.
Repeatability includes the correction
Configuration, environment details, deterministic generated data, tests and retained outputs allow the same run to be repeated. Known seeded failures establish the expected rule counts and guard against duplicate failure multiplication.
A correction is not closure. The failed rule must execute again, the passing row total must reconcile and the release decision must cite that retest.
Readable project evidence
Executed rule results
From Order and Delivery Data Quality Checks. The initial run separates 15 failures, three warnings and one execution error. Each row also retains the affected report section and correction reason.
Evidence type: Rendered from retained project records
Used in public projects
How Python executes repeatable checks and retained outputs
These links cover the complete set of current projects that use this capability. Each project states its data, native build, validation and limitation.
Order and Delivery Data Quality Checks
A monthly service report contains incomplete and contradictory order and delivery records.
How Python is used
Python runs named checks, separates pass, warning, failure and execution error, and writes the failed rows.
Retained proof
The retained run includes known injected failures, exact counts, CLI output and one order traced through correction and retest.
Reporting Data Issue and Retest Register
A missing product category changes a supplier report and must be independently retested before release.
How Python is used
An executable retest verifies the mapping fix and the restored report total.
Retained proof
The issue register links the query result, tester role and release decision without treating the fix itself as closure.
Purchase Order, Receipt and Invoice Reconciliation
Purchase orders, goods receipts and invoices need record-level comparison before payment.
How Python is used
Python supports deterministic ingestion and validation around the SQL reconciliation build.
Retained proof
Tests preserve case counts, duplicate handling, rule outcomes and held invoice records.
Working boundary
What an executed script does not prove about production use
A passing Python check proves only that the stated rule passed for the stated input. It does not prove that the source is correct in every respect or that untested business conditions are safe.
Bring one failed report check, the records it should test and the decision that depends on the result. The first task is to make the consequence and retest condition explicit.
Discuss this capabilityReturn to all capabilities