A 96-hour storm arc over a synthetic service territory. Watch GridCORTEX read the Earth-2 forecast, score every feeder for outage risk before the first outage, recommend crew pre-staging and material trailers with a human in the loop, back-feed customers through tie switches before a truck rolls, and measure the difference at restoration. The demo that matters runs on your data.
| Without | With GridCORTEX | Δ |
|---|
| Without | With GridCORTEX | Δ |
|---|
A hurricane is 72 hours from a fictional coastal utility with 8 substations, 28 distribution lines (called feeders), and about 119,000 customer meters. The map also shows a 138 kilovolt transmission backbone, the high-voltage highways that carry bulk power, and 14 normally open tie switches: spare connection points where a healthy line can pick up a damaged neighbor's customers. The problem is timing. Every hour of preparation the utility fails to use before landfall becomes hours of customers sitting in the dark afterward, and every extra hour of outage costs money in crew overtime and lost service.
The clock runs 96 hours, from 72 hours before landfall to 24 hours after. At 72 hours out, GridCORTEX reads a weather forecast built from 51 slightly different storm simulations (NVIDIA's Earth-2 weather system); running many versions at once shows how much to trust the forecast, and trust starts at 62%. At 60 hours out, a second model called CorrDiff sharpens the wind picture down to 2-kilometer detail. By 48 hours out, the software has combined that wind forecast with this utility's own tree cover, pole ages, and outage history, and 6 feeders show more than a 40% chance of storm damage. By 36 hours out, confidence in the storm's path reaches 81%, and the landfall window narrows to 34 to 40 hours away. The lines on the map change color as their risk climbs.
Twice, the clock pauses and waits for a person. At 24 hours before landfall, the software projects 9 feeders in the northeast corner above a 70% chance of losing power and asks the operator to approve moving 4 repair crews to the Lakeline and Eastport staging sites while roads are still safe. At 18 hours out, it asks to send 2 trailers of materials, loaded with poles, pole-top transformers, fuses, and wire, matched to a predicted damage bill of 14 broken poles and 6 lost transformers at 81% confidence; approving this also stages two more crews. Nothing moves until the operator clicks Approve. The software recommends; people decide. At 12 hours out, it drafts a request for help from 2 neighboring utilities (40 line workers) for the operator to review, and pre-computes a rerouting plan for every at-risk line.
Landfall brings sustained 62 mph winds gusting to 78. The model had flagged 84% of the lines that failed at least 12 hours in advance. Eight hours after landfall, drone photos and the dying "last gasp" signals that smart meters send when they lose power confirm 54 of 61 predicted damage sites. Because rerouting plans were ready, the operator closes two tie switches and customers get power back from healthy neighboring lines before any repair truck arrives. Sixteen hours after landfall, 93% of critical customers (the hospital, water plant, and communications sites) have power. One note on the numbers: the closing scorecard is recomputed from the exact storm you just watched, anchored to a minimum event of 18,000 customers out at the peak. The table below shows the math at exactly that size; the demo's ratios are fixed, so the comparisons hold on every replay. At that size, the three headline tiles read 8.7 million customer-minutes of outage avoided, a 73-minute cut in the average outage across all customers, and $166,000 of storm cost avoided.
The utility gets the same weather forecast, but nothing translates "70 mph gusts" into "which of my lines will break." So crews and materials wait at the depots until the first customer calls come in after landfall, because that is the only signal the old process has. The 18 hours when preparation was still possible pass unused. The result: 18,000 customers out at the peak, an average outage of 15 hours, 48 hours to get 95% of customers back, the hospital and water plant waiting 22 hours, and zero customers restored by rerouting, because no rerouting plan was ever computed. Borrowed crews from neighboring utilities work 3 days at $288,000, overtime reaches $142,000, and the storm costs $434,000 to work.
The software reads the storm forecast plus the utility's own records of trees, pole ages, and past failures. It predicts which specific lines will break, recommends where to place crews and materials, and a person approves every step. Crews are in position a full day early, materials match the predicted damage, and rerouting plans run the moment lines fail. The peak outage is 18% smaller, the average outage falls to 8.5 hours, 95% of customers are back in 28 hours instead of 48, critical sites are back in 8 hours instead of 22, and the storm costs $268,000 instead of $434,000. Same storm, same crews: $166,000 saved.
| KPI | Without GridCORTEX | With GridCORTEX | Delta |
|---|---|---|---|
| Customers interrupted (peak)the most homes and businesses without power at any one moment | 18,000 | 14,760 | 18% fewer went dark |
| Customer-minutes interruptedevery customer's outage minutes added together across the whole storm | 16.2M | 7.5M | −54%, over half avoided |
| Event SAIDI contributionSAIDI is the industry's standard reliability score: outage minutes averaged across every customer the utility serves | 136 min | 63 min | 73 fewer minutes |
| Event SAIFI contributionSAIFI counts how many times the average customer lost power in this event | 0.15 | 0.12 | −18% |
| CAIDI (avg. interruption)once your lights went out, how long they stayed out on average | 15.0 h | 8.5 h | −43%, out for 6.5 fewer hours |
| Time to 95% restoredhours until 95 of every 100 affected customers had power again | 48 h | 28 h | 20 hours sooner |
| Restored by tie switchingcustomers fed from a healthy neighboring line instead of waiting for a repair | 0; no plan computed | 2 feeders, pre-computed | power back before trucks roll |
| Critical loads restoredhours until the hospital, water plant, and communications sites had power | 22 h | 8 h | 14 hours sooner |
| Crew hours workedtotal paid hours of repair-crew labor for the event | 2,484 | 1,408 | 1,076 fewer hours |
| Overtime premiumthe extra pay above normal wages for storm hours | $142K | $74K | −$68K |
| Mutual assistancecrews borrowed from neighboring utilities, paid by the day | 3 days · $288K | 2 days · $192K | one day and $96K less |
| Truck rollshow many times a repair truck was dispatched | 163 | 99 | −39% |
| Fleet miles / drive timemiles and hours trucks spent driving instead of fixing | 3,584 mi · 253 h | 2,048 mi · 109 h | −57% drive time |
| Event O&M costoperations and maintenance: the total labor, fleet, and outside-help cost of working the storm | $434K | $268K | $166K saved |
| Unserved energyelectricity customers wanted but could not get, measured in megawatt-hours | 405 MWh | 188 MWh | −54% |
| Customer economic impactwhat the outage cost customers themselves: spoiled food, lost business, idle workers | $4.0M | $1.9M | $2.1M of harm avoided |
| Customer-minutes avoided (headline tile)the gap between the two runs; the number on the big closing tile | 16.2M incurred | 7.5M incurred | 8.7M avoided, the whole point |
Crews staged ahead of the front do not drive into it. The exposure that goes away is the mid-event repositioning drive, where crews cover long distances on storm damaged roads, often after dark, to reach work that was assigned late.
Counted in units you already track:
Preparation hours come back to the storm coordinator and the division operations managers, and restoration hours come back to line crews who start on real work instead of driving.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Preparation labor | planning hours avoided x your loaded rate for the staff on the preparation calls x events per year |
| Repositioning labor | crew hours avoided x crew size x your loaded crew rate, summed over the events in a season |
| Mutual assistance | crew days you do not request, or request later, x your all in mutual assistance cost per crew day. You set how many days a better forecast actually releases, not us |
| Vehicle and fuel | repositioning miles avoided x your fleet cost per mile |
| Customer minutes | customer minutes of interruption avoided x whatever value your commission or your own reliability case places on a customer minute, which is your number |
You pay for the forecast and modeling service, for the integration work to feed it your outage history, asset health, vegetation findings, and crew and material positions, and for your own staff time to run it in shadow mode through a full storm season before you trust it. The integration and the data cleanup usually cost more than the subscription.
Payback is driven by mutual assistance crew days and mid event repositioning labor, because those are the two lines your storm cost accounting can already show. Treat avoided customer minutes as upside, since that is the number a reviewer will question first.
The safety effect here is indirect and worth saying plainly. Nobody is removed from a hazard by a dashboard. What changes is that crews get dispatched against a confirmed picture rather than a stale one, so fewer crews drive to a location that was already restored or that turns out to be a different job than the one they were sent for.
Counted in units you already track:
Status collection and reporting hours come back to the people running the event, and the EOC director gets the projection built for them instead of assembled by them.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| EOC staffing | collection and reporting hours avoided x your loaded rate for those positions x event hours per year |
| Crew productive time | crew hours recovered from misdirected moves x crew size x your loaded crew rate |
| Restoration duration | hours cut off the event x your fully loaded restoration cost per hour, including contractor and mutual assistance crews already on the clock |
| Mutual assistance right sizing | crew days released earlier x your all in mutual assistance cost per crew day. You decide how many days a better picture actually releases |
You pay for the scoped engagement that builds and runs this, for integrations into SCADA, the outage management system, crew scheduling, weather, and whatever imagery feed you use, and for your own staff time to run it alongside the current process through at least one real event. The number of integrations is the cost driver, and crew status is usually the hardest one, because it is the least standardized system you own.
Payback is driven by hours cut off event duration and by EOC staffing hours, in that order. Event duration is the larger number but the harder one to attribute, so build the base case on staffing hours and treat duration as upside you validate over a season.
This is not a safety use case and it should not be sold as one. The only human exposure it touches is fatigue: reporting and finance staff working nights and weekends through close and board season, which your own overtime records already show.
Counted in units you already track:
Board book assembly hours come back to the directors and analysts who are pulled off their departments to build it, and the chief of staff stops being a document coordinator.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Director and analyst labor | assembly hours avoided x your loaded director and analyst rates |
| Ad hoc analysis | analyst hours avoided on KPI decomposition requests x your loaded analyst rate |
| Outside support | advisory or agency hours you stop buying for benchmarking and board material preparation x your contracted rate |
| Reconciliation rework | hours per cycle spent making two versions of the same figure agree x your loaded rate x cycles per year |
You pay for the scoped engagement that builds and runs this, for connection to your reporting warehouse and document store, and for executive and analyst review time on every draft. The real cost is agreeing on one definition and one source for every KPI, which is your work and not ours, and which most utilities discover they have been deferring for years. Drafts still need an accountable human author before anything goes to a board.
Payback is dominated by director and analyst hours in board season plus any outside support you stop buying. Be aware that the reason this gets funded is usually the executive's own meeting prep, which never appears as a line item in the model.
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 storm preparation planning service used in the days before a forecast event. It produces a damage-likelihood map by area and a recommended staging plan for crews and materials. The demo above uses synthetic data; everything below describes what the real deployment needs from your organization.
| Your system | Typical products | How we connect |
|---|---|---|
| Outage Management System (OMS) | GE PowerOn, Oracle NMS, ADMS outage module | database replica refreshed nightly |
| Weather and environment | National Weather Service feeds, commercial forecast services, satellite and LiDAR imagery | read-only API |
| Geographic Information System (GIS) | Esri ArcGIS Utility Network, GE Smallworld | scheduled file export (CSV or CIM XML) |
| Asset / work management (EAM/CMMS) | IBM Maximo, SAP PM, Oracle WAM | database replica refreshed nightly |
| Field and crew systems | ARCOS crew scheduling, vehicle location (AVL) | read-only API |
| SCADA historian | AVEVA PI System, AspenTech eDNA, GE Proficy | historian mirror (one-way feed) |
| Document and knowledge stores | damage assessment photos, EOC logs | document upload |
Runs in your cloud account on GPU instances, where the physics-based weather models can scale; an on-premises option exists. All feeds are read-only through your existing data zone, with no link to control systems, and the first storm season runs in shadow mode beside your current playbook.
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 storm preparation coordinator in the GridCORTEX console:
Approve turns the plan into draft crew assignments and material requests: staged crew assignments go to your crew scheduling system and draft material transfer orders go to your work management system, all in pending status for your storm coordinator to confirm in those systems.
Nothing to enter; the run triggers automatically when connected weather feeds forecast a qualifying storm, and you can start a run manually for any forecast window.
Fuses weather updated every 15 minutes with OMS, GIS, and asset data refreshed daily; every staging card shows the forecast cycle and data as-of time it was computed from.
A planning map in the GridCORTEX console; staging lives in the work and crew systems; mobile push when a storm crosses the 48-hour threshold. 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 utility with a mature storm process: "We have an OMS, an ADMS, weather vendors, and a storm playbook, what's new here?" Here's the honest answer.
When someone asks "what did it actually calculate?", this is the list. Every risk score, pre-staging recommendation, and restoration estimate in this demo is the output of analyses across the categories below. In the simulation these factors drive the storyline; in a pilot they are computed from your weather feeds, GIS, asset registry, OMS history, AMI, and crew systems.
Presenter's one-liner: "It fused the weather physics, the vegetation, the health of every pole and transformer, and your own outage history into a per-feeder damage forecast, then turned that into a crew, materials, and switching plan an operator approved before the wind arrived, and measured the difference in the exact metrics you report. That's what you just watched."