Output contract
Every consumer of meter data — CIS billing, settlement, customer-facing, operational, regulatory and timing — listed with an owner, a tolerance and an exit criterion, agreed and locked before anything is compared.
Prove the go-live
Grid Data Conversion Testing Tool Switch your MDMS with proof, not hope.
GDCT runs the Grid Data Management Platform beside your production MDMS on identical inputs, compares every output that matters from the bill down, and gives every difference one explained disposition — so cutover ends in a signed decision instead of an argument.
Output-first
contract agreed before the run
Identical inputs
to both systems, archived
Zero unexplained
the exit test
Signed off
billing · finance · regulatory
Why a parallel run
Most differences come from setup, not from the MDM
When the Grid Data Management Platform replaces an incumbent MDMS, the two run side by side and the utility has to be convinced that switching will not change bills, settlement, customer data or operations in ways it has not agreed to. Without controls, a parallel run produces thousands of differences — most caused by different inputs, master data, conventions or manual edits — and the incumbent is usually a black box. GDCT controls the first and opens the second.
Identical inputs
Head-end data delivered identically to both systems and archived as it arrives, with daily parity reports — so any day can be replayed, and an input difference is never mistaken for a logic difference.
Setup reconciled first
Master data, conventions, VEE rules and quality codes reconciled and mapped one by one, and configuration frozen or versioned — before a single read is compared.
Top-down comparison
Both systems compared as they stood at the same cut-off: billing determinants for every account and the money on the bill first, then daily usage, intervals, VEE outcomes, timeliness and interface files.
Difference register
Every difference carries exactly one disposition, its evidence and its approvals. The exit test is zero unexplained differences — not zero differences.
Patterns, not piles
Recurring differences are recognized as patterns and a disposition is suggested for the analyst to confirm, so many differences with one cause are handled once.
Estimates as their own test
Where both systems used actual reads, values must match. Estimates are judged separately: known reads are hidden from both systems and each one's estimates are measured against the truth, with systematic bias weighed first.
Opening the black box
The incumbent's estimation and validation rules are inferred from its own outputs and set out in plain language for specialist review — so each of its estimates can be judged better, the same or worse, and explained.
Manual edits by policy
Edits made in the incumbent during the run are either mirrored into GDMP or compared as a separate group — chosen up front, never handled case by case.
Scripted scenarios
The situations that break conversions — duplicate resends, late data after the bill, rollovers, reverse flow, meter exchanges, move-in and move-out, daylight-saving days, month-end — injected into both systems and verified.
Readiness & sign-off
Exit criteria evaluated daily with a readiness status; sign-off by billing operations, finance and regulatory owners; and a tamper-evident evidence pack of the whole run.
AI analyst assistant
Optional and read-only: explains a difference and suggests its disposition, answers plain-English questions about the run, and drafts the daily summary and decision briefs — with customer data masked.
How it works
How a parallel run works
Step 1
Agree the outputs
Owners set tolerances and exit criteria in the output contract, and lock it.
Step 2
Pass the gates
Identical inputs, reconciled master data, mapped rules and codes, agreed conventions, frozen configuration, a chosen edit policy, and a frozen sample and run period — each checked by the tool and approved by its owner.
Step 3
Stabilize
Setup differences are found, fixed and re-run until they trend to zero, and the scenarios are injected.
Step 4
Prove
A daily cycle at a fixed cut-off — compare, classify, decide, report — across multiple full billing cycles, including a month-end and a daylight-saving change.
Step 5
Sign off
Exit criteria met, every decision signed, and the evidence pack sealed for cutover.
The difference register
Every difference, one disposition
Input difference
The two systems received different data. Fix the feed or replay the day, and re-run.
Setup difference
Master data, configuration, a convention or a mapping does not match. Fix it, and prove the difference is gone.
Agreed method difference
The systems differ by design, within the output's tolerance. Approved by the VEE specialist, with the proof.
Defect in the current system
GDMP is more correct — but bills would still change. The utility decides: reproduce the old behavior, or accept the change with customer communication and regulatory sign-off.
Defect in the new system
GDMP is wrong. Raised, fixed and re-run until the difference is gone.
Use cases
Where Grid Data Conversion Testing Tool earns its keep
MDMS replacement
A defensible go-live decision when GDMP replaces an incumbent MDMS.
Bill protection
Every account's determinants and bill amount compared before cutover, not discovered after it.
Regulator and auditor confidence
Evidence that bills did not change — or that every change was decided and signed.
A shorter stabilization
Setup problems separated from logic differences early, so the proving run starts clean.
Hypercare
Continued comparison after cutover while the incumbent stays available read-only.
Who works in it
One run, every owner at the table
Field analysts
The daily cycle: load outputs, investigate and classify differences, run forensics and scenarios.
VEE specialists
Map rules and quality codes, review the incumbent's inferred rules, approve agreed-method differences.
Deployment lead
Gates, configuration freeze, exit criteria, replay approvals and the sign-off proposal.
Output owners
Billing, finance, regulatory and operations: agree tolerances, decide current-system defects, co-sign readiness.
Feed operators
Set up and monitor the input feeds, and approve anything that touches the production path.
Better together
Part of the Grid Data Family
GDCT is how a Grid Data Management Platform deployment proves itself. GDMP already records the rule, method and replaced value behind each of its values — and what it served at any past cut-off — so GDMP's side of every difference arrives explained.
The new MDMS whose go-live GDCT proves.
Single sign-on and notifications for the run.
Verifies each release before it reaches the parallel run.
The method behind a parallel run, step by step.
How every output difference gets one disposition before go-live.
FAQ
Common questions about Grid Data Conversion Testing Tool
What is the Grid Data Conversion Testing Tool?
The Grid Data Conversion Testing Tool (GDCT) proves a Grid Data Management Platform go-live. GDMP and the utility's production MDMS run in parallel on the same inputs, and GDCT shows, output by output and account by account, whether switching would change bills, settlement, customer data or operations in any way the utility has not agreed to.
Why do most parallel runs end in arguments?
Because most differences come from setup, not from the MDM logic: different inputs, master data, conventions, rule parameters or manual edits. GDCT makes the inputs identical, reconciles the setup before reads are compared, and classifies every remaining difference, so the discussion is about decisions rather than noise.
What does "zero unexplained differences" mean?
Every difference gets exactly one disposition: an input difference, a setup difference, an agreed method difference, a defect in the current system, or a defect in the new system. The run is ready when none are left without one, not when there are no differences at all.
How are estimated reads compared?
Where both systems used actual reads, the values must match. Estimates are judged as a separate test: known reads are hidden from both systems, each system's estimates are measured against the real reads, and systematic bias counts most. The incumbent's own estimation rules are inferred from its outputs so each of its estimates can be explained.
What if our current system turns out to be wrong?
Then GDMP is the more correct of the two, but bills would still change. That is recorded as a defect in the current system and needs an explicit utility decision: reproduce the old behavior, or accept the change with customer communication and regulatory sign-off.
How long does a parallel run last, and who signs it off?
The proving run covers multiple full billing cycles, including a month-end and a daylight-saving change, after a preparation and stabilization phase. Readiness is signed off by the utility's billing operations, finance and regulatory owners, with a tamper-evident evidence pack of the whole run.
Plan your parallel run
See a parallel run end to end — the output contract, the difference register and the sign-off — on realistic simulated data.
Connect With Us