Load the declared inputs
The run records files, row counts, period, checksum where practical and run identifier.
Python
Use Python to test reporting rules and forecasts against retained records.
For reporting, planning and data teams that need repeatable checks, retained exceptions or a forecast evaluation another analyst can inspect.
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 records can enter the report, which must be held, and how does an analytical result compare with a clear baseline on later data?
See the finished examplesThe document triage build reads generated invoices, credit notes, receipts, control evidence and reporting requests, then holds contradictory items for an intake analyst. The cycle-hire research applies the same executable discipline to forecasting: every prediction keeps its issue time, target hour, uncertainty range and later observed demand.
Three uses of Python
Python answers three different analytical questions.
These examples use the same discipline of declared inputs, repeatable runs and retained results, but they do not make the same claim.
- 01Model selection across Python and RView Day-ahead Electricity Demand Forecast Review
Compare the published forecast with Python and R corrections across six rolling origins, then apply the fixed selection gate.
- 02Operational demand forecastingView Cycle Hire Demand and Service Planning
Estimate station demand one, three and six hours ahead and compare each forecast with the same-station weekly baseline.
- 03Repeatable failed-record checksView Order and Delivery Data Quality Checks
Run named checks, retain the failed order and delivery rows, and prove a correction by running the same test again.
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 run again, the passing row total must reconcile and the decision to publish the report must cite that retest.
A forecast must beat a useful baseline
The cycle-hire study predicts completed departures one, three and six hours ahead. Expanding time splits keep later station-hours out of training, and the selected model is compared with demand at the same station and hour one week earlier.
The final May test retains point error, peak-period error and forecast-range coverage by station and notice period. Wide ranges enter a planner watch list; they do not become automatic instructions to move cycles.
A finished example
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: executed analytical evidence
Where this is used
How Python reruns the same checks and produces the same result
These examples use Python for repeatable data checks, time-ordered forecasting and document triage. Each one separates the measured result from the production behaviour it cannot establish.
Browse all 7 project examplesDay-ahead Electricity Demand Forecast Review
A day-ahead electricity forecast has two challenger corrections, but a lower average error is not enough on its own to replace the published operating reference.
How Python is used
Python reproduces six rolling origins, checks the timing boundary and applies the pre-agreed selection rule. R appears only as a challenger implementation in the comparison, not as a separate Quanta Meridian capability.
Evidence retained
The comparison covers 8,066 held-out predictions, all six rolling origins, later outturn and why the R correction is suitable for more testing rather than replacing the published forecast.
Document and Request Triage
A Finance and Operations intake receives invoices, receipts, evidence documents and reporting requests that need different specialist reviewers.
How Python is used
Python suggests the record type, extracts named fields and applies deterministic checks before a person accepts, edits, rejects or reroutes the record.
Evidence retained
The contained build retains 6,000 generated documents, a 900-document test split, 130 held suggestions and the full correction history for DOC-CRN-000417.
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.
Evidence retained
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.
Evidence retained
The issue register links the query result, tester role and publish or hold outcome 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.
Evidence retained
Tests preserve case counts, duplicate handling, rule outcomes and held invoice records.
Supplier Invoice Matching and Review
A price or quantity difference needs a buyer answer and an independent rematch before Accounts Payable can make its decision.
How Python is used
Python rebuilds the contained workflow, generates the reviewer report and tests that failed or errored rematches cannot release an invoice.
Evidence retained
Nineteen automated tests, 27 validation checks and 8,303 retained workflow events are generated from the same invoice-review records.
Cycle Hire Demand and Service Planning
A cycle-hire service planner needs to know which busy London station deserves a closer check before the next operating shift.
How Python is used
Python creates station-hour histories, compares a weekly baseline with regularised Poisson and boosted forecasts, and evaluates one-, three- and six-hour notice periods in time order.
Evidence retained
The retained May test contains 26,784 forecasts, errors and uncertainty ranges, plus one Waterloo station-hour followed from counted journeys to human review.
Working boundary
What an executed script still needs before production use
A passing Python check proves only that the stated rule or evaluation passed for the stated records. Historical forecast accuracy does not prove deployed performance, causation or that an automated operating decision is 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.
View the Analytics Engineering solutionDiscuss this capabilityReturn to all capabilities