GridCORTEX Live · Data Quality  ·  ← All Demos
On this page What you are watching The business case Run this at your utility Where you see it and how you say yes

The Foundation Synthetic Data · Simulation

The dirty secret under every ADMS, DERMS, and OMS: the model lies. A quarter of customers mapped to the wrong transformer, one in five on the wrong phase, connectivity that hasn't matched the field since the 90s conversion, and every advanced application you buy inherits all of it. The old fix is a four-year, $30M field-walk that gets scoped, quoted, and cancelled. The new fix: the grid already knows its own truth. Meters that sag together are connected together. Outages reveal who's really behind which device. Meter events identify phase. Watch the truth engine turn that evidence into 54,000 corrections with confidence scores, and a per-feeder Data Quality Index that finally tells you which apps can be trusted where.

WEEK 1
EVIDENCE INGEST
⏳ DECISION POINT: TIME SLOWED
SYNTHETIC DATA
Wrong transformer mapping Phase error (A/B/C) Connectivity error Corrected, evidence-linked AMI voltage evidence DQI = per-feeder Data Quality Index

The grid knew its own truth. Something finally listened.

Data quality as an evidence problem, not a field-walk problem, the foundation everything else stands on
,
Data Quality Index
,
Corrections applied
,
Cost & time vs field walk
The Model
WithoutWith GridCORTEXΔ
Everything Built on Top
WithoutWith GridCORTEXΔ
Illustrative simulation on synthetic data; error rates and dollar figures are placeholders informed by industry-typical GIS/connectivity error levels. In a GridCORTEX pilot, the truth engine runs on YOUR AMI intervals, YOUR outage history, and YOUR GIS, and the first correction list lands in weeks. See UC 5.2 "Demo and Proof Plan."
68
Territory Data Quality Index
72%
Customer-transformer accuracy
0
Corrections applied (evidence-linked)
0 / 3
Advanced apps trusting the model
Model Steward Feed: GIS · AMI · OMS · SCADA · stewards approve
Evidence
Truth list
Corrections
DQ gates
Apps unlocked
The Validated Use Cases Behind This Scenario
UC 5.2
Network Model Health
The truth engine itself: GIS vs field vs AMI vs OMS, reconciled continuously with confidence-scored corrections.
UC 5.6
Phase Imbalance & Correction
12,800 phase errors found from meter events, and the rebalancing plan that follows once phasing is finally true.
UC 17.1
AMI Interval Intelligence
The evidence source: 14 billion intervals of voltage correlation; meters that sag together are connected together.
UC 6.2
Hosting Capacity Twin
One of everything downstream: every twin, every study, every app inherits the model this demo fixes.
UC 5.7
ADMS Data Readiness & Migration Gatekeeper
Readiness as a program: per-feeder scoring against the vendor's model requirements, migration waves sequenced by readiness and value, go-live gates enforced with evidence, drift watched after.
Inside the Demo
What you are watching, and what it proves

The scenario is a 12-week data cleanup program at a fictional utility whose grid map has quietly rotted for decades. The master map lives in the geographic information system, or GIS, and every other tool trusts it. The dashboard's starting facts: a territory Data Quality Index of 68 out of 100, only 72 percent of customers mapped to the transformer that actually serves them, and line connections that have not matched reality since a 1990s records conversion. Why it matters: every advanced software product the utility buys inherits these errors and quietly misfires. The traditional fix, walking the entire territory to verify everything by hand, was quoted at 4 years and $30 million and cancelled twice. The demo's premise is that the grid has already recorded its own truth. The engine ingests 14 billion voltage readings from smart meters, 6 years of outage records, meter event logs, sensor feeds from the control system, and the full map export, and cross-examines them against each other. Early finds set the tone. On circuit FDR-108, the voltage of 61 meters sags in lockstep with transformer T-2214, yet the map assigns 19 of them to a different transformer two poles away. On circuit FDR-117, a 2024 automatic breaker operation darkened 412 meters when the map predicted 371; the 41-meter difference is itself a map error, recorded by the event.

Three decisions go to the board of data stewards, the people who guard the master map. Around week 4, the first presents the truth list: 41,300 customers mapped to the wrong transformer (28 percent), 12,800 recorded on the wrong phase, meaning the wrong one of the three wires that share each line, and 340 connection errors, such as switches that do not exist and links the map never knew about. In total, 54,100 proposed corrections, each carrying its evidence and a confidence score. Around week 6, the second decision sets the correction rules: fixes scoring 95 percent confidence or better, which is 94 percent of them, apply automatically in batches that a human steward approves; the 80-to-95-percent band gets a desk review; and only the ambiguous 6 percent requires a truck and a field visit. A field audit of the first 400 automatic fixes finds 98.2 percent were correct, and batches run at about 6,100 corrections a week. Fixing the phase records pays an immediate bonus: a planning tool finds 9 circuits where rebalancing the three wires frees real capacity (use case 5.6).

Around week 9, the third decision makes trust measurable circuit by circuit: a per-circuit Data Quality Index across connections, phase, customer-to-transformer mapping, and wire properties, with each advanced application unlocked only when the data it depends on is good enough. Outage prediction unlocks at a mapping score of 95 or better. Automatic fault rerouting, known as FLISR, unlocks at 97 on connections. Voltage optimization, known as VVO, unlocks at its own thresholds. A standing drift watch then feeds every switching order, meter swap, and outage back into the evidence, so the map stays true. The ending state: outage prediction unlocked territory-wide at 98.5 percent accuracy, automatic rerouting unlocked on 21 of 28 circuits, voltage optimization on 17, and the program finished at a Data Quality Index of 96, up from 68, in nine months for $4.2 million, with all 54,100 corrections traceable to their evidence.

Without GridCORTEX

The conventional path is living with the lies. The outage system predicts the wrong extent of a failure and sends crews to a transformer that was never involved: 40 minutes lost, again and again. The automatic rerouting pilot, switched on in good faith, opens the wrong switch because the map's connections were wrong, and the advanced applications get quietly demoted to advisory status while their licenses keep billing. The voltage optimizer pushes settings based on phase records that are 18 percent wrong, and field equipment gets blamed for the resulting complaints. The cleanup project is scoped again at 4 years and $30 million of field walks, loses to storm hardening in the budget, and is cancelled for the third time in a decade. The core failure: the only accepted source of truth is a field walk nobody will ever fund, so zero corrections get applied and the quality score drifts down from 68 forever.

With GridCORTEX

The capability is a truth engine (use case 5.2, fed by use case 17.1) working from three kinds of evidence: meters whose voltage sags together must be connected together; every historical outage is a natural experiment revealing who is really behind which device; and meter events reveal which of the three wires each customer is on. The engine weighs the evidence, writes each correction with its proof attached, and scores its own confidence. The 4-year field walk becomes a 9-month evidence program, with truck visits for only the ambiguous 6 percent. Humans stay in charge by design: map stewards approve every batch, and ongoing field audits keep the engine's confidence honest. The per-circuit quality gates then make "is the data good enough?" a number, so applications unlock only where trust is earned. The winning numbers: 54,100 corrections, mapping accuracy from 72 to 98.5 percent, quality index from 68 to 96, and $4.2 million instead of $30 million.

The scorecard, side by side
MeasureWithout GridCORTEXWith GridCORTEXDelta
Data Quality Indexa 0-to-100 health score for the accuracy of the utility's master grid map68: and drifting68 → 96+28 points
Corrections appliedindividual map errors found and fixed during the program054,100each fix carries its proof
Customer-transformer accuracythe share of customers mapped to the transformer that actually serves them72%98.5%26.5 points better
Phase accuracythe share of customers recorded on the correct one of the three wires that share each line82%99%12,800 corrected
Connectivity errorsplaces where the map's picture of how lines connect did not match the real grid340 unknown340 found & fixedthe links the map never knew
Correction basiswhat each fix rests onopinion + site visitsevidence chains + confidenceauditable
Field verification burdenhow much of the territory still needs an in-person truck visit to verify100% of territory6%: the ambiguous tailthe walk you can afford
Model after the projectwhether the map stays accurate once the cleanup endsrots immediatelydrift watch: stays truea diet, not a cleanse
Cleanup cost & timethe price and duration of getting to a trustworthy map$30M · 4 yrs · cancelled$4.2M · 9 months · done86 percent cheaper
OMS outage predictionthe outage management system's ability to predict which equipment failed and who lost powerwrong extents, wrong crewsunlocked territory-widetrucks to the right pole
FLISRautomatic switching that isolates a fault and reroutes power around it; a feeder is a main circuit serving a neighborhoodmisoperated, demotedunlocked on 21/28 feederssee Commissioning Day
VVOvoltage optimization software that fine-tunes delivery voltage to cut energy wastepushed on wrong phasesunlocked on 17/28phase truth first
Every study & twinevery engineering study and computer model built on top of the mapinherits the liesstands on the floorevery other tool benefits
Prudence & audit posturehow the utility defends its spending to regulators and auditors; Relay is the system's decision log"trust us"every fix evidence-linkedprovable, not asserted
The live numbers on the dashboard
Territory Data Quality IndexThe single 0-to-100 health score for the whole map. It starts red at 68 and climbs to 96 as corrections land; above the gate thresholds, applications can finally be trusted.
Customer-transformer accuracyThe share of customers mapped to the right transformer, rising from 72 percent to 98.5. Low readings mean outage prediction and storm response are guessing.
Corrections applied (evidence-linked)The running count of steward-approved fixes entering the master map, on its way to 54,100. Steady growth means the program is working; a stall means the review queue is stuck.
Advanced apps trusting the modelHow many of the three gated applications have cleared their quality thresholds. 0 of 3 is a grid running on faith; 3 of 3 means every unlock was earned with evidence.

The Business Case: Safety, Hours, and Cost

A utility does not buy a demo. It buys a safety exposure that goes away and a cost that goes down. Below is that case for every use case behind The Foundation, written the way a plant manager, a safety lead, and a CFO each need to read it. Every hour and every dollar is a formula you run with your own rates and volumes. There are no vendor benchmarks in here and no invented percentages. If a number is not yours, it is not a number.
UC 17.1 AMI Interval Data Intelligence Engine

What happens today, without this

Interval data from every meter lands in the MDM, the meter data management system, gets used for billing, and stops there. A distribution engineer finds out a transformer is in trouble when it fails or when a customer calls. Transformer loading is reviewed once a year in a batch report built from monthly billed kilowatt hours, not from interval reads. A voltage complaint gets a truck roll to hang a recorder, a week of waiting, a second truck roll to collect it, and then an engineer opens the file. Phase imbalance is found during a feeder review, or it is not found at all.

What it replaces or shrinks

  • The annual transformer load management batch report built from billed kilowatt hours rather than interval reads
  • The truck roll to install a voltage recorder, the week of waiting, and the second truck roll to retrieve it
  • Hand written queries against the meter data warehouse for each one off power quality investigation
  • Discovery of degraded secondary service by customer complaint rather than by measurement
  • The manual sort of which transformers to look at first, currently done by age and by memory
  • Shrinks the engineer's work to reviewing a ranked anomaly queue instead of hunting for anomalies

Why it is safer

Two real exposures move. Troubleshooters stop being sent to hang and retrieve recorders on hunches, and transformers that were going to fail in service get changed out on a planned outage instead of failing hot, which is when oil, fire, and an unplanned energized job all arrive together.

Counted in units you already track:

  • Road miles driven for recorder installation and retrieval trips
  • Energized area entries for secondary and transformer troubleshooting performed without a diagnosis
  • Elevated work hours on pole mounted transformer work, converted from emergent to planned
  • Night driving hours for after hours callouts on transformer failures

Man-hours it gives back

Truck roll hours come back to troubleshooters and meter techs, and analysis hours come back to the distribution engineer who currently writes queries by hand.

HOURS AVOIDED PER YEAR = power quality investigations per year x truck rolls per investigation x crew hours per truck roll, plus annual transformer load study hours, plus emergent transformer failures per year x crew hours per emergent changeout, minus the engineer review hours spent on the flagged anomaly queue and the field verification of flagged units.

The numbers we need from you to run that formula:

  • Power quality and voltage investigations per year, truck rolls each, and crew hours per roll
  • Hours spent producing the annual transformer load management study
  • Emergent distribution transformer failures per year and crew hours per emergent changeout
  • Your cost difference between an emergent and a planned transformer changeout
  • Loaded hourly rate for a troubleshooter, a meter technician, and a distribution engineer, plus your fleet cost per mile

Where the dollars come from

Cost driverHow it is calculated, from a rate you supply
Field labor and vehicletruck rolls avoided x crew hours per roll x your loaded crew rate, plus miles avoided x your fleet cost per mile
Emergent to planned conversionyour own cost premium of an emergent changeout over a planned one x the changeouts you convert
Overtime and calloutafter hours callouts avoided x your callout minimum and overtime multiplier
Customer equipment claimsyour average paid claim for equipment damage from sustained voltage problems x the claims avoided by finding the condition first
Deferred replacementyour unit cost per distribution transformer x the units you defer once measured loading shows they have headroom

Reliability and maintenance

Reliability
A failed distribution transformer is a SAIFI, or system average interruption frequency index, event for every customer on it, and because it is emergent it usually carries a long restoration time, which drives CAIDI, the customer average interruption duration index. Converting those to planned changeouts is the whole reliability case, and how big it is depends on what share of your outages code to distribution transformer failure, a number your outage cause coding already has.
Maintenance
This is the classic emergent to planned conversion, driven by measurement you already own. Transformer replacement moves from an age based program to a condition based one, and secondary problems such as a loose neutral get corrected on a scheduled visit rather than after the customer has been living with it for months.

What else it moves

CustomerDegraded service gets fixed before the customer calls, and the customers who do call get an engineer who already has the interval data in front of them.
ComplianceVoltage delivered at the meter is a service quality obligation in most jurisdictions, and this measures it continuously across the whole population rather than by sample.
WorkforceExperienced troubleshooters stop chasing recorders and spend their time on the diagnoses only they can make.
EnvironmentA transformer changed out on plan does not lose its oil on the ground the way a failed one can.

What it costs you, stated honestly

You pay for the scoped engagement that builds and runs this and the compute to process the full meter population rather than a sample, for the integration into your MDM, your GIS, and your EAM, the enterprise asset management system, and for your engineers to validate the anomaly queue against a season of known outcomes. The honest prerequisite is meter to transformer connectivity data. If your GIS does not know which meters sit under which transformer, fixing that is the first project.

How to build the payback case

Payback is dominated by avoided truck rolls and by the emergent to planned conversion on transformer changeouts, because both are in records you already keep. Treat customer claims as upside.

This is a planning model built from your investigation counts, your failure counts, and your rates, not a vendor claim. Re run it after the first year, when you can compare flagged units against what actually failed.
UC 5.2 Network Model Health and Maintenance Assistant

What happens today, without this

Nobody audits the distribution network model on purpose. Errors surface when the advanced distribution management system (ADMS) behaves oddly: a dispatcher says fault location pointed at the wrong lateral, an engineer opens a ticket, a geographic information system (GIS) editor traces the circuit by hand to find what is wrong, and sometimes a crew is sent out to put a meter on a transformer and confirm which phase it is actually on. Phase labels and connectivity come from decades of as built drawings and field sketches of varying quality. A full model audit happens as a funded project every few years, then drifts again. In the meantime dispatchers keep an informal list of feeders where they do not trust the automation.

What it replaces or shrinks

  • Reactive, one ticket at a time chasing of model errors after an application misbehaves
  • Manual GIS traces to work out why a connectivity or phase result looks wrong
  • Truck rolls purely to verify the phase of a transformer, a meter, or a lateral
  • The periodic funded model audit project, replaced by a continuous audit against meter and outage evidence
  • Shrinks the dispatcher's informal list of feeders where automated restoration is turned off or overridden
  • Shrinks the guesswork in deciding which model corrections to fund first

Why it is safer

This one has a direct mechanism and it is worth stating in plain terms. A switch mapped in the wrong state or a lateral mapped on the wrong phase is a crew hazard, because isolation decisions and clearance boundaries are built on the model. Correcting the errors that matter most, and correcting them from meter and SCADA evidence rather than from a field visit, removes both the bad data and most of the trips taken to confirm it.

Counted in units you already track:

  • Road miles driven on phase and connectivity verification trips, which the evidence based audit replaces for most cases
  • Switching operations executed against model data later found to be wrong, which is the exposure the correction queue is designed to shrink
  • Energized area entries made solely to verify a model attribute in the field rather than to perform work
  • Night driving hours during restorations extended by an incorrect fault location or an incorrect isolation point

Man-hours it gives back

Investigation hours come back to the ADMS support engineers and the mapping team, and editors spend their day making corrections instead of hunting for what to correct.

HOURS AVOIDED PER YEAR = model error tickets per year x hours per investigation across the ADMS engineer and the GIS editor, plus field verification trips per year x crew hours per trip including drive time, plus the hours in your periodic model audit project divided across the years between audits, minus the editor time still spent making, checking, and promoting each corrective edit, which does not go away.

The numbers we need from you to run that formula:

  • Model error tickets raised per year and the average investigation hours each consumes
  • Field verification trips per year taken to confirm phase or connectivity, and crew hours per trip
  • Hours and elapsed months in your last full model audit, and how often you repeat it
  • Number of feeders running automated restoration, and how many are currently disabled or overridden for model reasons
  • Loaded hourly rate for a GIS editor, an ADMS support engineer, and a line crew including vehicle

Where the dollars come from

Cost driverHow it is calculated, from a rate you supply
Investigation laborinvestigation hours avoided x your loaded ADMS engineer and GIS editor rates
Field verificationverification trips avoided x crew hours per trip x your loaded crew rate, plus miles avoided x your fleet cost per mile
Restoration performancecustomer minutes attributable to incorrect fault location or isolation x your own cost per customer minute of interruption, using the share your outage records support and not a share we assert
Model audit projectsthe cost of your periodic audit project x the share the continuous audit displaces, which your mapping supervisor sets
Unrealized ADMS valuethe annual benefit your ADMS business case assigned to automated restoration x the share of feeders currently running with it disabled or overridden for model reasons

Reliability and maintenance

Reliability
Fault location, isolation, and service restoration accuracy is a model problem before it is a software problem, so this touches CAIDI and therefore SAIDI directly: a correct model puts the crew at the right lateral the first time and lets automation reclose the right sections. Be honest about the size, though. The benefit is bounded by how many of your long restorations your own outage records trace to model error, and that is a number you already have.
Maintenance
Model corrections stop being emergent work triggered by a misbehaving application and become a ranked, evidence backed queue the mapping team works through in priority order. Because the audit runs continuously, drift introduced by a batch of GIS edits is caught in the next cycle instead of at the next outage.

What else it moves

ComplianceEvery proposed correction carries the meter or SCADA evidence that justified it, which gives you a defensible record of model quality when a reliability report or a restoration event is questioned.
WorkforceEditors and ADMS engineers stop firefighting and start working a prioritized queue, which is the difference between a job people leave and a job people stay in.
CustomerFewer customers left out because the automation isolated the wrong section, and fewer wrong estimated restoration times built on wrong connectivity.

What it costs you, stated honestly

You pay for the GridCORTEX audit service, for read access and integration into GIS, AMI, SCADA, and your outage records, for the GIS editing queue integration, and for your editors' time to actually work the corrections. The finding is the cheap part. The correcting is real mapping labor and the queue will be long at first, so budget the editor hours before you buy the audit.

How to build the payback case

Payback is dominated by field verification trips avoided and by whatever restoration performance your own outage cause coding will support. If your dispatchers have automation disabled on a set of feeders today, the unrealized ADMS value line usually turns out to be the largest number on the page and the easiest one to defend internally.

This is a planning model built from your ticket counts, your outage records, and your own labor rates, not a vendor claim. Re-run it after the first correction wave, using the errors you actually found and the edit hours they actually took.
UC 5.6 Phase Imbalance Detection and Correction Planner

What happens today, without this

Phase balance is judged from the feeder head. A distribution engineer looks at SCADA phase currents during an annual feeder loading review, and if the three phases look close at the breaker, the feeder is called balanced. Imbalance that develops downstream, which is where single phase rooftop solar and single phase electric vehicle charging actually connect, is invisible from there. When someone wants real data, a crew is dispatched to put a clamp on ammeter on laterals, one at a time. Load transfers are designed by hand from circuit maps, and the customers to move are chosen by whoever knows the circuit. Most of the time, the imbalance is found after a phase fuse operates or a transformer fails.

What it replaces or shrinks

  • Clamp on ammeter survey trips to laterals to find out where the loading actually sits
  • The annual feeder loading review that can only see the feeder head in SCADA
  • Hand design of load transfer options from circuit maps and local knowledge
  • The post event investigation into why one phase overloaded and operated a fuse
  • Shrinks the guesswork in choosing which customers or taps to move and how much it will help
  • Shrinks the follow up survey trip taken to confirm that a transfer actually improved balance

Why it is safer

Two mechanisms, both real. Field surveys with a clamp on ammeter are energized area entries made purely to gather data, and detecting imbalance from advanced metering infrastructure (AMI) removes most of them. Separately, sustained imbalance drives neutral current and thermal loading on the heavy phase, and the failures that follow are the ones that put crews on emergency work at night.

Counted in units you already track:

  • Energized area entries to take clamp on current readings at laterals and transformers
  • Road miles driven on lateral load survey trips across a feeder
  • Night driving hours on emergency callouts for phase overload fuse operations and transformer failures
  • Switching operations executed as emergency transfers rather than as a designed, scheduled transfer

Man-hours it gives back

Survey crew hours and engineering design hours come back, and the engineer reviews a ranked transfer plan instead of building options from a map.

HOURS AVOIDED PER YEAR = feeders x annual loading review hours per feeder, plus lateral survey trips per year x crew hours per trip including drive time, plus transfer designs per year x engineering hours per design, plus post event investigation hours per phase overload event x events per year, minus the engineer review time still spent validating each recommended transfer before it goes to design.

The numbers we need from you to run that formula:

  • Number of feeders and engineer hours per feeder in your current loading review
  • Lateral survey trips per year and crew hours and miles per trip
  • Load transfer designs produced per year and engineering hours per design
  • Phase overload fuse operations and transformer failures per year, from your outage records
  • Loaded hourly rate for a distribution engineer and a line crew including vehicle, plus your fleet cost per mile

Where the dollars come from

Cost driverHow it is calculated, from a rate you supply
Field survey labor and travelsurvey trips avoided x crew hours per trip x your loaded crew rate, plus miles avoided x your fleet cost per mile
Engineering design labordesign hours avoided per transfer x transfers per year x your loaded distribution engineer rate
Lossesmegawatt hours of loss reduction from restored balance, computed on your own circuits by the analysis, x your own avoided energy cost per MWh
Avoided equipment lossdistribution transformers and conductor sections lost to imbalance driven thermal duty per year x your installed replacement cost, x the share you believe earlier detection would have prevented
Outage costcustomer minutes from phase overload fuse operations x your own cost per customer minute of interruption

Reliability and maintenance

Reliability
Imbalance driven fuse operations and transformer failures are direct SAIFI events, and because they typically require a crew to locate and replace equipment, they carry a long CAIDI tail. Correcting the drift before the heavy phase reaches its limit converts those into a scheduled transfer that customers do not see.
Maintenance
The heavy phase and the neutral are carrying the thermal duty that ages the equipment, and imbalance trend data shows which sections are accumulating it. That gives the asset team a loading based replacement priority and converts imbalance work from emergent response into planned design and switching.

What else it moves

CustomerCustomers on the heavy phase are the ones who see high loading, low voltage, and the outage when the fuse goes, and they are usually the ones nobody knew about.
WorkforceCrews stop being sent out to gather data that the meters already hold, and stop being called out at night for failures that were visible months earlier.
EnvironmentLoss reduction from restored balance is energy that never has to be generated, on circuits you already own.

What it costs you, stated honestly

You pay for the GridCORTEX analytics service, for AMI and SCADA integration good enough to trust at the meter level, for the connection into your work management system, and for the design and crew time to execute the transfers it recommends. The transfers themselves are the largest cost and they compete with everything else in the switching schedule, so sequence them rather than releasing the whole list at once.

How to build the payback case

Payback is dominated by avoided survey trips and by avoided equipment loss on the circuits where imbalance is worst. Losses are real but small per feeder, and outage cost depends entirely on how many of your fuse operations your own records attribute to overload rather than to trees or animals.

This is a planning model built from your AMI data, your outage records, and your own labor rates, not a vendor claim. Re-run it after the first set of transfers, using the balance improvement your meters actually measured against what was predicted.
UC 5.7 ADMS Data Readiness and Migration Gatekeeper

What happens today, without this

Advanced distribution management system (ADMS) data readiness is tracked in a spreadsheet that a program manager updates from emails and status calls. Readiness against the vendor's data model requirements is checked by sampling: an engineer opens a handful of feeders, walks the requirements list for one application, and the result is generalized to the region. When the steering committee asks which feeders are ready for fault location, isolation, and service restoration (FLISR) or for volt/VAR optimization, assembling a defensible answer takes a week or two, and the answer is stale by the next model sync. Drift is the part nobody watches: feeders certified in an early wave get edited in the geographic information system (GIS) months later, and nobody rechecks them until an application starts giving bad answers after go live.

What it replaces or shrinks

  • The manually maintained readiness spreadsheet and the status call chasing behind it
  • Sampling based manual feeder checks against the vendor's data model requirements
  • The multi week scramble to assemble a defensible readiness answer before each steering committee
  • Manual re-verification of previously certified feeders after each GIS or model sync
  • Shrinks the post go live root cause investigation when an advanced application underperforms
  • Shrinks the negotiation with the vendor and the integrator about whose problem the data is

Why it is safer

The mechanism is indirect but specific, and it is the reason gate discipline exists. Automated restoration acts on the model. Letting FLISR go live on a feeder whose connectivity or switch status is wrong means an automated switching scheme operating on a picture that does not match the field, which is a crew and public exposure. Holding those feeders is the safety benefit, and it costs schedule, which is exactly the trade the gate report is meant to make visible.

Counted in units you already track:

  • Switching operations executed by automation on model data that had not been verified for that application
  • Energized area entries during field verification sampling, reduced because readiness is scored from evidence in your systems rather than from field visits
  • Road miles driven on verification trips across a multi year, multi region rollout

Man-hours it gives back

Program office and engineering hours come back to the ADMS program, and the director walks into the steering committee with a current number instead of a two week reconstruction.

HOURS AVOIDED PER YEAR = feeders in the program x manual readiness check hours per feeder per wave x waves, plus steering committee reporting cycles per year x hours per report package across the program office and engineering, plus model syncs per year x re-verification hours per sync, plus post go live investigation hours per underperforming application, minus the program office time still spent reviewing and signing each generated gate report.

The numbers we need from you to run that formula:

  • Feeders in the program, number of migration waves, and advanced applications in scope
  • Engineer hours to check one feeder against one application's data requirements today
  • Steering committee reporting cycles per year and hours to assemble each package
  • Model syncs or GIS promotion cycles per year and hours spent re-verifying after each
  • Loaded hourly rate for a program manager, an ADMS engineer, and your systems integrator's contracted rate

Where the dollars come from

Cost driverHow it is calculated, from a rate you supply
Program office and engineering laborreadiness check and reporting hours avoided x your loaded program manager and ADMS engineer rates
Integrator reworkrework hours attributable to data problems found after an application went live x your systems integrator's contracted hourly rate, from your own change order history
Schedule slipmonths of program delay avoided x your own carrying cost per month for the ADMS program, which your finance group already computed for the business case
Unrealized application valuethe annual benefit your ADMS business case assigned to each advanced application x the share of feeders where that application is not live or not trusted because of data
Field verificationverification trips avoided across the rollout x crew hours per trip x your loaded crew rate, plus miles x your fleet cost per mile

Reliability and maintenance

Reliability
The ADMS is your reliability instrument, so this is a reliability use case at one remove. The SAIDI and SAIFI improvement in your ADMS business case only lands on feeders where the advanced applications are actually enabled and actually trusted by dispatchers. Every feeder held back, disabled, or overridden for data reasons is business case benefit you are paying for and not receiving, and this makes that gap countable.
Maintenance
Data corrections stop being an undifferentiated cleanup backlog and become a sequenced queue tied to a wave and a gate date, so the mapping team knows what has to be right by when. Continuous scoring means drift after a GIS edit batch is caught in the next cycle rather than after go live.

What else it moves

ComplianceEach gate decision carries the evidence behind it, which is the record you need when a regulator asks why a modernization program is behind schedule or over budget.
WorkforceThe program office stops spending its week on spreadsheet reconciliation and status chasing, which is the work that burns out program managers on multi year rollouts.
CustomerThe restoration performance the program promised customers arrives on the schedule it was promised, on feeders where it will actually work.

What it costs you, stated honestly

You pay for the GridCORTEX readiness service, for integration to GIS, AMI, SCADA, your outage records, and your project schedule, and for the work of encoding your ADMS vendor's data model requirements per application, which is a joint exercise with your vendor and your integrator. Then you pay in mapping editor hours to close the gaps the scoring finds, and there will be more of them than the program plan assumed.

How to build the payback case

Payback is dominated by schedule slip avoided and by integrator rework, both of which your program already tracks in change orders. Program office labor is real but small. The unrealized application value line is usually the largest, and it is the one your steering committee will find hardest to argue with.

This is a planning model built from your program plan, your feeder counts, and your own labor and integrator rates, not a vendor claim. Re-run it after the first gated wave, using the correction hours the wave actually consumed rather than the ones the plan assumed.
Each of these opens in full on the use case page, alongside the integration plan, the data ask, the path to production, and the operator console. Open the use case library.
For Your Architects and Data Owners
Run this at your utility

What is this, exactly? It is AI software: intelligent agents and models built and delivered by SoftServe, running on NVIDIA accelerated computing. It is not a hardware appliance and it does not replace the systems you run today. It deploys in your own cloud or on your premises, connects read-only to your existing systems, and recommends; your people approve every action, starting in shadow mode until it earns trust.

An analytics and planning service for distribution engineering: it detects phase imbalance drift from advanced metering infrastructure (AMI) data and returns a ranked list of load transfer recommendations, each with the customers to move and the expected balance improvement. The demo above uses synthetic data; everything below describes what the real deployment needs from your organization.

Systems it connects to

Your systemTypical productsHow we connect
Metering (AMI head-end and meter data management)Itron, Landis+Gyr, Aclara; Oracle or Itron meter data systemsdatabase replica refreshed nightly
Geographic Information System (GIS)Esri ArcGIS Utility Network, GE Smallworldread-only API
SCADA historianAVEVA PI System, AspenTech eDNA, GE Proficyhistorian mirror (one-way feed)
DER management (DERMS) and DER program platformsSchneider, GE Vernova, or your interconnection registryscheduled file export (CSV or CIM XML)
Customer Information System (CIS) / billingOracle CC&B, SAP IS-Udatabase replica refreshed nightly
ADMS vendor requirementsthe vendor's data model and application prerequisite documentsdocument upload
Project schedulingOracle Primavera P6, Microsoft Projectscheduled file export (CSV or CIM XML)

Data it needs from you

How it runs on your systems

Runs in your cloud account on GPU instances or an on-premises NVIDIA server, read-only through your existing data zone, with meter data handled under your customer data rules. Transfers are planned and executed by your engineers and crews through the normal work process; the tool only recommends.

Path to production

Weeks 1-4: data access and connection setup
Metering, GIS, and telemetry feeds connect; customer data approvals are the usual gate.
Weeks 5-12: regional pilot
One region is analyzed for imbalance signatures and a transfer plan is generated for the top 20 cases, checked by engineers.
Weeks 13-14: evaluation and go or no-go
Confirmed findings and the projected overload and loss relief drive the decision.
Months 4-5: production hardening
Security review, automated refresh, monitoring, and routing into the work order process.
Month 6 onward: in production
Engineers pull balance work from the ranked queue each planning period, region by region.

What we need from your team

Full integration, data, and timeline detail for each use case in this scenario: UC 5.6 · UC 5.7 · UC 17.1 · UC 5.2
For Your Operators and Dispatchers
Where you will see it and how you say yes

The Approve button you just clicked in the demo above is the real workflow. This is what it looks like on the screen of the distribution engineer watching feeder loading in the GridCORTEX console:

GridCORTEX ConsoleSigned in: the distribution engineer watching feeder loading
Notifications
Feeder F-19: phase B at 71 percent loading versus 44 on A and C after a 1.2 MW single-phase solar cluster
Daily model refresh complete; all connected feeds healthy
Recommendation
Transfer 3 lateral taps, 214 customers, off phase B on feeder F-19
  • AMI shows phase B loading drifting 2 points a month
  • SCADA still reads the feeder head as balanced
  • Transfer restores balance to within 8 percent across phases
✓ Send plan to work managementModifyDecline
After you approve: The transfer opens as a design job in the work management system; crews carry out switching under ADMS control, and an audit entry records who approved it and why.
Computed from data as of 17:42:10 local; every card shows the timestamp of the data behind it.

What happens when you hit approve

Approve creates the transfer as a draft design job in your work management system through its API; design reviews it, and crews switch under ADMS control per your procedures. GridCORTEX never initiates switching or edits the model.

How you tell it what it cannot see

Data triggered from AMI population analysis; nothing to enter. An engineer can defer a recommendation or flag a customer constraint in one click.

Live data, not stale data

Rescans AMI data nightly and rereads SCADA continuously; each recommendation shows the analysis window and its as-of timestamp, including on pilot replicas.

Where it lives day to day

GridCORTEX imbalance rankings with a monthly email; a phase projected to overload within 30 days pushes a Teams alert. The console runs in a browser beside your existing screens on day one; embedding into your own systems is a roadmap step once the read-only phase has earned trust. Approve, Modify, and Decline are all captured in an audit trail your compliance team can pull, and GridCORTEX never blocks or overrides anything in the systems you run today.

The Gap: Why Your Existing Systems Don't Already Do This

The fair question from any grid-mod or GIS leader: "We have a GIS team, data stewards, and a cleanup project in the roadmap, what's new here?" Here's the honest answer, and it's why the cleanup project keeps getting cancelled.

What you own keeps doing its job

  • GIS, remains the system of record. It receives corrections; it isn't replaced.
  • The GIS/records team, they stop chasing errors blind and start approving evidence-ranked corrections.
  • ADMS / DERMS / OMS, the consumers of the model; they get a foundation they can finally trust, with a gate that says when.
  • Field verification, still happens, but on the 6% of corrections where evidence is ambiguous, not on 100% of the territory.

The gap GridCORTEX fills, above them, not instead of them

  • The field walk is unaffordable, so it never happens. Walking every span and opening every handhole is a 4-year, $30M project that loses to every other budget line, every year. Meanwhile the errors compound.
  • The grid already recorded the truth. Every outage is a connectivity experiment (who ACTUALLY went dark?). Every voltage sag is a topology fingerprint (who sags together?). Every meter event carries phase. Nobody's system cross-examines this evidence at population scale, that's the product.
  • Corrections need confidence, not opinions. Each proposed fix carries its evidence and a confidence score: ≥95% auto-applies under steward approval, the rest becomes a ranked field list. The 4-year walk becomes a 9-month evidence program with a 6% field tail.
  • "Is the model good enough?" needs a number. The per-feeder Data Quality Index gates the apps: FLISR unlocks at 97 connectivity, VVO at phase+impedance thresholds, storm prediction at customer-transformer ≥95. No more enabling apps on faith (see Commissioning Day; this is the territory-wide engine under it).
  • Data quality is a diet, not a cleanse. Every new meter, switching order, and outage updates the evidence; the model stays true after the project ends, which is the part every cleanup effort has always failed.
Accent, don't replace: GridCORTEX cross-examines your AMI, OMS, SCADA, and GIS against each other · produces evidence-linked corrections with confidence scores · and your stewards approve them into the GIS you already run. Nothing works without clean data. This is how the data gets clean, and stays clean.
Under the Hood: What GridCORTEX Took Into Account in This Scenario

When someone asks "what did it actually calculate?", this is the list. In the simulation these factors drive the storyline; in a pilot they are computed from your AMI, OMS, SCADA, and GIS.

🔬 The Evidence Sources

  • AMI voltage correlation at 14-billion-interval scale: meters whose voltage moves together share a transformer and phase; the strongest connectivity signal that exists (RAPIDS-class compute)
  • Outage forensics: every historical outage re-read as a connectivity experiment, who called, who pinged dark, versus who the model SAID was behind that device
  • Meter event phase identification and SCADA feeder-load sanity checks closing the loop

⚖ The Truth Engine

  • Bayesian reconciliation: GIS says X, voltage says Y, outages say Y, the correction proposes Y with the evidence attached and a confidence score
  • Auto-apply threshold (≥95%) under steward approval; 80-95% queued for cheap desktop review; <80% ranked for targeted field verification
  • Sample field audits continuously calibrate the engine's confidence against ground truth

🚦 The DQ Gates

  • Per-feeder Data Quality Index across four dimensions: connectivity, phasing, customer-transformer mapping, impedance calibration
  • App unlock thresholds: OMS prediction, FLISR, VVO each gated on the dimensions THEY depend on; trust becomes granular and earned
  • Drift watch: switching orders, meter exchanges, and new construction feed the evidence stream; the index is live, not annual

🧾 The Record & The Stack

  • Every correction carries its evidence chain, the GIS audit and the rate-case prudence question answer themselves (Relay-traced)
  • Feeds every other demo on this site: the twins, FLISR commissioning, storm prediction, hosting capacity, all stand on this floor
  • Runs always-on via the NVIDIA Agent Toolkit, the evidence never stops accumulating, so the model never drifts far

Presenter's one-liner: "A quarter of the customers were mapped to the wrong transformer, and the fix was a thirty-million-dollar field walk nobody would ever fund. But the grid had been recording its own truth all along, every sag, every outage, every meter event. The engine cross-examined the evidence, wrote fifty-four thousand corrections with confidence scores, and gave every feeder a data quality number that tells you which apps to trust where. Nine months, four million dollars, and everything you've bought finally works."

GridCORTEX Live Scenario Demo · Synthetic data throughout, no utility or system is depicted; error rates are industry-typical placeholders · GIS stewards approve every correction · SoftServe + NVIDIA · Created by Ronnie Mauldin, NVIDIA Solutions Director, Power & Utilities, SoftServe · JUL 2026