The industry's open secret: utilities buy ADMS advanced applications, FLISR, Volt/VAR optimization, load flow, and then never turn them on, because the apps are only as good as the network model and the field devices they command. This is the demo of getting them on and keeping them on: a full field-device audit (65 of 198 devices fail verification), a model remediation list ranked by what FLISR actually needs, 340 staged faults replayed in the digital twin before any live enablement, and then the question that decides success: where do the FLISR and VVO pilots go first? Not the feeder the vendor picked. The one the math picks.
| Without | With GridCORTEX | Δ |
|---|
| Without | With GridCORTEX | Δ |
|---|
A fictional utility spent $14 million on two advanced software applications for its control room, and 14 months later neither has ever been switched on. The first, called FLISR (fault location, isolation, and service restoration), automatically finds a broken section of power line, seals it off, and reroutes power around it in seconds. The second, Volt/VAR optimization (VVO for short), fine-tunes voltage along each line so customers get stable power while the utility wastes less energy. Both are common purchases across the industry, and both commonly sit unused, because they are only as good as the utility's computer model of its own grid. Here that model is only 71% accurate. The simulation covers a 10-week program to turn the apps on safely. Weeks 1 and 2 are a full census: all 198 field devices (automatic pole-top circuit breakers, voltage-support equipment, and motorized switches) are checked against the utility's map database, its control-room model, its live sensor feeds, and its smart-meter data. The census exposes the industry's open secret in one line: 65 of the 198 devices, one in three, fail verification. There are 47 map and model errors, 11 devices that no longer communicate, and 7 sensors with the wrong calibration settings, so their readings are wrong. Automatic switching software running on this model would be guessing.
Three recommendations go to the engineering team for approval. Week 2: a repair list ranked by consequence, not by discovery order. The 23 errors that would make the automatic-switching app misfire come first, the 18 that would mislead the voltage app come second, and cosmetic errors come last. That ordering turns a 6-month clean-everything project, the kind that never finishes, into an estimated 6 weeks of mapping-technician work. Model accuracy climbs from 71% to 84% by week 3, 92% by week 4, and eventually 98%. Week 5: rehearsal in a digital twin, a working computer model of the grid where decisions can be tested safely. Before anything goes live, 340 simulated line failures are replayed against the corrected model, and the voltage settings are tested against 12 months of real smart-meter voltage readings. Replay 88 shows the payoff: the switching app isolates a simulated failure in 3 moves and restores 2,240 of 2,610 affected customers in 41 seconds. Replay 204 catches a plan that would have opened the wrong switch. In all, 12 replays fail, and 2 of those failures would have been live wrong-switch events that dropped real customers. All 12 are fixed in simulation, and the rehearsal finishes 340 of 340 passing.
Week 7 is the decision that makes or breaks the program's reputation: where to run the first pilot. Not the line the vendor suggests. The software scores every candidate and picks the RIVERSIDE loop (lines F-101 and F-117) for the switching pilot: it has the right layout, healthy equipment, and the territory's worst outage-frequency record, so the improvement will be visible to everyone. The voltage pilot goes to line F-104, which has the widest voltage swings and full smart-meter coverage to prove the savings. Go-live is staged so trust can build: watch-only mode in week 8, then advisory mode, then full automatic control in week 9. That week the first real failure hits the pilot loop, and 2,180 customers get their power back in 47 seconds, before anyone's phone rings. The voltage app follows and delivers a measured 2.3% cut in energy use on its line. The closing scorecard compares this against the industry's usual outcome. Its headline tiles: model accuracy 98% versus 71%, outage duration on the pilot loop down 38% versus no change with the apps off, and wrong-switch events 0 versus 1 followed by the software being shelved.
The failure is sampling under schedule pressure. The installation contractor spot-checks 40 of the 198 devices, they pass, and the automatic-switching app goes live everywhere on the 71% model. In its first storm it opens the wrong switch and cuts power to 1,800 customers whose lines were healthy. The mistake makes the morning meeting, then the newspaper. The voltage app, misled by two failing pieces of voltage equipment the model did not know about, switches them on and off 30,000 times in six weeks, wearing them out, so operations quietly turns it off. By month 8 both applications are disabled "pending model cleanup," and the $14 million in licenses joins the shelf of software the utility owns but does not use.
The software does three things, each approved by people. It runs a census instead of a sample: every device checked across four data systems at once, with fixes ranked by which application they would break. It runs a rehearsal instead of a gamble: 340 simulated failures replayed in the digital twin, where a wrong switch costs nothing and harms no one. And it places the pilots by scoring, so the first win happens where equipment is healthy and customers will notice. Protection engineers sign off on every switching plan, and operations controls every step up from watch-only to automatic. The result: 98% model accuracy at go-live, zero live wrong-switch events, outages on the pilot loop 38% shorter, 2.3% energy savings on the voltage pilot, and applications that stay on because the checking never stops.
| KPI | Without GridCORTEX | With GridCORTEX | Delta |
|---|---|---|---|
| Device censushow many of the 198 field devices were actually checked before go-live | 40-device sample | all 198 verified | a census, not a sample |
| Model accuracy at go-livehow well the utility's computer model matches the real grid when automation switches on | 71% | 98% | the whole game |
| Fix effortthe work needed to correct the model errors, and the order the fixes happen in | 6-month cleanup (never done) | 6 weeks, app-impact order | ranked by consequence |
| Misoperationstimes the automation opened a wrong switch and cut power to healthy customers | 1 live, 1,800 customers | 2 caught in twin, 0 live | mistakes made where they are free |
| VVO cap-bank huntingthe voltage app rapidly switching worn voltage equipment on and off, wearing it out | 30,000 cycles, then OFF | sick banks fixed pre-launch | audit first, automate second |
| Pilot placementwhich power line hosts the first live trial, and who chose it | vendor reference feeder | scored: layout + health + outage history | the win is visible |
| The $14M licenseswhat actually happens to the software the utility paid for | shelfware by month 8 | closed-loop and trusted | the investment performs |
| FLISR pilot CAIDICAIDI is average outage length per affected customer; here, on the pilot loop | n/a (apps off) | −38% on the pilot loop | an improvement regulators can see |
| VVO energy (CVR)CVR means conservation voltage reduction: energy saved by holding voltage slightly lower and steadier on the pilot line | n/a (apps off) | 2.3% on the pilot feeder | measured from real meter data |
| Operator trustwhether the control-room staff believe the automation enough to leave it on | burned by the misop | built in monitor mode | the apps stay ON |
| Post-go-live driftthe model slowly going stale again after commissioning day | next year's problem | audit runs continuously | stays commissioned |
| Commissioning evidencethe proof that the system was tested before it was trusted | binders | traceable sign-offs & replay logs | built for auditors |
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:
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.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Investigation labor | investigation hours avoided x your loaded ADMS engineer and GIS editor rates |
| Field verification | verification trips avoided x crew hours per trip x your loaded crew rate, plus miles avoided x your fleet cost per mile |
| Restoration performance | customer 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 projects | the cost of your periodic audit project x the share the continuous audit displaces, which your mapping supervisor sets |
| Unrealized ADMS value | the 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 |
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.
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.
There is a direct mechanism here, through targeting. A regulator or a pole mounted capacitor bank visit is an energized area entry, often elevated work, and usually a switching operation to isolate the bank. Sending crews to the devices the performance data actually names, rather than to every device on a calendar, removes the entries that were never going to find anything.
Counted in units you already track:
Crew hours come back to distribution operations and engineer hours come back to the voltage owner, who reviews a ranked gap report instead of building one.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Recovered energy | megawatt hours recovered by closing the identified gap x your own avoided energy cost per MWh, where the megawatt hour figure comes from the audit against your own feeder measurements and not from any external benchmark |
| Peak demand | kilowatts of peak reduction restored x your own capacity cost per kilowatt year |
| Field labor and travel | device visits avoided x crew hours per visit x your loaded crew rate, plus miles avoided x your fleet cost per mile |
| Consultant studies | CVR study fees displaced per cycle x cycles per year |
| Energy efficiency program credit | recovered megawatt hours x the incentive or lost revenue mechanism rate in your own jurisdiction, where one exists, and zero where it does not |
You pay for the GridCORTEX audit service, for AMI, SCADA, and VVO telemetry integration, for the connection into your enterprise asset management or work order system and your ADMS change queue, and for the field crew time to actually perform the recalibrations the audit recommends. The recalibration work is a real cost and it lands on a crew that is already busy, so schedule it before you commit to the energy number.
Payback is usually dominated by recovered energy and peak, but only if your VVO is genuinely underperforming. If the audit finds a small gap, the case rests on avoided calendar visits and displaced consultant studies, which are smaller but far easier to defend. Run the audit on a few feeders first and let the answer decide the program size.
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:
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.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Program office and engineering labor | readiness check and reporting hours avoided x your loaded program manager and ADMS engineer rates |
| Integrator rework | rework 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 slip | months 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 value | the 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 verification | verification trips avoided across the rollout x crew hours per trip x your loaded crew rate, plus miles x your fleet cost per mile |
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.
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.
The safety effect here is indirect and we will not dress it up: no field task is removed by an answer on a screen. The mechanism is that a sourced diagnosis in the control room reduces the exploratory dispatch, the crew sent to look around a circuit at night because nobody in the room could say what tripped, and it reduces trial switching done to find out rather than to fix.
Counted in units you already track:
Search time comes back to the operator on shift, and callout hours come back to the on-call engineer who currently answers history questions by phone.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Operator search labor | search hours avoided x your loaded operator rate, at the overtime rate for any hours worked past a shift |
| Engineering callout | after-hours callouts avoided x hours per callout x your loaded engineer rate, plus your callout premium |
| Avoided exploratory truck roll | investigative dispatches avoided x your fully loaded cost per truck roll, which you supply, including vehicle, crew, and premium time |
| Time to competency | new operator ramp weeks reduced x weeks x your loaded rate for the trainer and the trainee, using your own current ramp schedule |
| Event write-up | event reports per year x hours currently spent reconstructing what happened x your loaded rate |
You pay for the scoped engagement that builds and runs this, for read integrations into your historian, supervisory control and data acquisition (SCADA) system, OMS, and procedure library, and for your own staff time. The staff time is the part people underestimate: somebody on your side has to clean up point naming and confirm which procedure documents are current, because an assistant that cites a superseded procedure is worse than no assistant. Budget operator time in the first months to check citations before trusting them.
Payback is driven by operator search minutes and after-hours engineer callouts, both of which you can count from your own logs today. Avoided truck rolls are real but harder to attribute, so treat them as upside rather than as the basis of the case.
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.
A data quality service for the ADMS and mapping teams: it audits the distribution network model against meter and outage evidence and produces a prioritized correction work queue, each item with evidence and operational impact. The demo above uses synthetic data; everything below describes what the real deployment needs from your organization.
| Your system | Typical products | How we connect |
|---|---|---|
| Geographic Information System (GIS) | Esri ArcGIS Utility Network, GE Smallworld | scheduled file export (CSV or CIM XML) |
| Advanced Distribution Management System (ADMS/DMS) | Schneider EcoStruxure ADMS, GE Vernova PowerOn, Oracle NMS | scheduled file export (CSV or CIM XML) |
| Metering (AMI head-end and meter data management) | Itron, Landis+Gyr, Aclara; Oracle or Itron meter data systems | database replica refreshed nightly |
| Customer Information System (CIS) / billing | Oracle CC&B, SAP IS-U | database replica refreshed nightly |
| SCADA historian | AVEVA PI System, AspenTech eDNA, GE Proficy | historian mirror (one-way feed) |
| Outage Management System (OMS) | GE PowerOn, Oracle NMS, ADMS outage module | read-only API |
| Document and knowledge stores | SharePoint, procedure libraries, operator logbooks | document upload |
Runs in your cloud account on GPU instances or an on-premises NVIDIA server, read-only through your existing data zone. Corrections are made by your GIS editors through their normal update process, never written back automatically; customer data is limited to service point identifiers.
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 ADMS model manager and the mapping supervisor in the GridCORTEX console:
Approve opens correction tasks in your GIS editing queue through its API, each with evidence attached, inside your mapping team's normal workflow; nothing edits the model directly. Your editors make every change, and the ADMS model updates through your standard promotion process.
Data triggered by continuous comparison of the model against AMI and SCADA evidence; nothing to enter. Editors mark a finding as false in one click and it stays suppressed.
Audits run nightly against the latest AMI voltages and SCADA states; each finding shows its evidence dates, and the dashboard shows the last full audit time.
A GridCORTEX model health dashboard with a weekly email; an error blocking an ADMS application 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 fair question from any grid-mod director: "The ADMS vendor has a commissioning methodology and we hired an SI, what's new here?" Here's the honest answer, and it's why so many advanced-app licenses are shelfware.
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 GIS, ADMS, SCADA, and AMI data.
Presenter's one-liner: "Everyone buys FLISR; almost nobody turns it on, because the model lies and the first misoperation kills the program. We audited every device, fixed the model in app-impact order, replayed 340 faults in the twin until it was boring, and put the pilots where the math said the win would show. The apps went live, stayed live, and the CAIDI drop showed up in the regulator's numbers."