Poke the grid. This is a living digital twin of a synthetic service territory. Pick a move on the right, then click anywhere on the map: drop a 200 MW data center and get the interconnection answer in seconds, drop a solar farm and watch the feeder flip to reverse flow, or fail a substation and watch the twin re-route power through the tie switches before a truck would have left the yard. Every answer would take the traditional process weeks to months. In a pilot, this twin is built from your network model, and your engineers validate every answer against your engines of record.
The Grid Twin Sandbox is not a timed storyline. It is a digital twin, a working computer model of a real power grid used to test decisions safely before making them, built here for a synthetic Gulf-coast territory. You poke it yourself. The map holds 8 substations, the fenced equipment yards that step high-voltage power down for local delivery (NORTHGATE, CEDAR PARK, LAKELINE, MIDTOWN, RIVERSIDE, EASTPORT, SOUTH YARD, BAYSHORE, with transformer capacities from 260 to 380 MVA, a standard measure of how much power each can carry). It holds 28 feeders, the local lines that carry power from a substation out to homes and businesses, plus a 138 kilovolt high-voltage transmission loop and a set of tie switches: switches that normally sit open but can connect neighboring circuits to reroute power. Every substation wears a live headroom tag, its spare capacity in megawatts, computed honestly: the equipment's rated limit minus its actual measured peak load, not the stale figure in the planning book, updated as you add load. You are the decision-maker. Pick one of three moves on the right, click the map, and the twin computes for about 1.25 seconds before answering. Nothing is executed on any real grid; every answer is a first screening that the utility's engineers would confirm in their official study tools.
Drop a Load lets you place a big new customer on the map: a 50 megawatt electric-vehicle fleet depot, a 200 megawatt data center, or a 450 megawatt AI computing campus. (One megawatt powers roughly 750 homes; 450 megawatts is a small city.) The twin returns one of four verdicts. Serviceable: the substation can host it with room to spare, priced with the miles of new dedicated line and an estimate of when power flows, and the twin notes the answer took 4.2 seconds against the 9 to 14 months the formal study queue would take. Serviceable with conditions: the equipment can carry the load, but voltage would sag 3 to 6% at peak, enough to dim the neighborhood, so the twin prices voltage-support equipment plus heavier wires, and suggests flexible terms for the last 15% of the load. Portfolio answer: no single substation can serve the request, so the twin splits it across two grid connection points with a paired dedicated line, and shows how. Needs major upgrade: the honest no. The site needs a new large transformer with a 24-month manufacturing wait, so the twin offers to bring the load online in stages, which keeps the deal alive.
Drop a DER places customer-owned energy equipment: 5 MW of community solar, a 20 MW solar farm, or a 10 MW battery that stores 40 megawatt-hours. The twin computes the hosting margin at your exact click point, meaning how much new solar or storage that local line can accept before it needs upgrades. It runs the standard national screen for connecting such equipment (the IEEE 1547-2018 test) and reports which way power flows at noon, when solar output peaks. If the request is over the limit, the twin ranks three engineered fixes: an inverter setting that helps hold voltage steady, a battery placed alongside and sized to close the gap, or a limit on power exports from 11:00 to 14:00. Batteries always pass, valued at roughly $14K per MW per year, because the utility can call on them whenever it needs them. Break Something knocks out a substation transformer where you click. Feeders flash red, and the answer card counts customers in the dark and megawatts interrupted. Then the twin closes tie switches one by one, rerouting power from healthy neighboring circuits within safe equipment limits, and reports the share of customers whose lights come back through remote switching within minutes. It also names who still needs a repair crew on site (estimated 6 to 9 hours) and the exposure if a second failure hits while the grid runs rerouted. If no neighboring circuit has spare capacity, the twin says so and flags that substation as a candidate for resilience investment. There is no scripted ending: Reset Grid heals everything, and Attract mode makes the twin poke itself every 9 seconds for booth screens.
Every question you just clicked is, conventionally, a paid engineering study: weeks to months each, and 9 to 14 months for a large new customer's connection request. The process fails because it looks at one thing at a time. The published capacity map shows one stale number per line. The study process considers one connection point at a time, so a 450 MW request gets a flat no instead of a two-substation split. The voltage problem surfaces at month 11 of the study, after the customer has planned around a yes. The over-limit solar application gets a rejection letter after 60 business days with no alternative offered. And the proof that the grid survives losing any one major component lives on paper in an annual planning deck, never demonstrated to the executive who has to fund the fix.
The software trains an AI model to reproduce the answers of full physics-based grid studies, then answers in seconds at study quality. It is built from the utility's own network map, its smart-meter usage history, and its control-room operating records. Connection screenings come back in 4.2 seconds with the construction cost, the time until power flows, and the fix already priced. Capacity answers are computed for your size, at your exact spot, against today's actual loading, with three ranked ways to get to yes. Failure drills become a live conversation, with the rerouting plan performed in front of the audience. People stay in charge by design: the twin never touches the real grid's controls, and every commitment is confirmed afterwards by the utility's official engineering tools and engineers of record.
| KPI | Without GridCORTEX | With GridCORTEX | Delta |
|---|---|---|---|
| Large-load interconnection screenthe check that decides whether a big new customer can plug into the grid, and at what cost | 9 to 14 months in the study queue | 4.2 seconds, confirmed by engineers afterwards | the customer is still in the room |
| Finding the voltage problemdiscovering that a new load would drag the neighborhood's voltage down at peak hours | discovered at month 11 of the study | found and priced with its fix, in seconds | fix known up front |
| An ask no single bank can servea request too big for any one substation transformer to carry alone | the one-at-a-time process says no | a split across 2 connection points, with the how | a workable yes instead of a no |
| Transformer-scale bad newswhen the honest answer is a new large transformer with a 24-month manufacturing wait | bad news in 14 months | bad news in 5 seconds, with a phased offer | the deal survives |
| DER hosting answerhow much customer solar or battery capacity a local line can accept at a given spot | one stale published number per line | your size, your point, today's loading, plus the fix | the limit and the remedy |
| Over-limit solar applicationa solar request bigger than the local line can accept without changes | rejection letter after 60 business days | three engineered ways to yes, in seconds | ways to yes, ranked |
| N-1 contingency proofproof the grid keeps serving customers after losing any one major component | proven on paper in the annual planning deck | performed live: switches closed, customers restored in minutes | shown to the person who funds the fix |
| The unswitchable outagea failure no neighboring circuit can pick up, leaving customers waiting on a repair crew | 8 to 12 hour crew restoration, learned the hard way | flagged now: one new tie switch changes this answer permanently | the investment case, pre-written |
A feasibility report has no direct safety benefit. The honest indirect mechanism is specific to co-location: a deal agreed before the plant side topology is understood produces late scope changes at an operating plant, and late scope at a running plant means work forced into an outage window that was already fully booked.
Counted in units you already track:
Hours come back to four departments at once, and the corporate development director stops being a document assembler.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Cross department staff time | department hours avoided x your loaded rates for planning, plant engineering, regulatory, and commercial staff |
| Outside advisor fees | consultant and outside counsel hours avoided on feasibility scoping x your contracted rates |
| Deal capture | your own expected annual revenue from the deal x the probability you assign to your report arriving inside the developer's decision window being the reason you win it, a probability you set, not us |
| Bad sites screened early | your own average spend on a co-location deal that dies in late diligence x the number of such deals per year an early screen would have stopped, a count your team judges |
| Reinforcement right sizing | the difference between the reinforcement scope a coarse screen assumes and the scope the detailed model supports, at your own unit costs |
You pay for the feasibility service, for the work to load your plant models, network model, and interconnection data into it, and for commercial, legal, and engineering review time on every draft, because nothing goes to a developer without your people signing it. The internal review discipline is the cost that people forget to budget.
Payback is carried by staff and advisor hours across four departments, which you can audit. Deal capture is the number that dwarfs everything else and the one you should present as upside, because you cannot prove the counterfactual.
There is no direct field safety benefit from a faster study, and we will not dress one up. The honest indirect mechanism is schedule compression: when a study takes months, the construction and energization window gets squeezed to hold a date the customer already announced, and squeezed windows are where overtime, short notice switching, and rushed field work come from. Returning the answer earlier gives the schedule its slack back.
Counted in units you already track:
Senior planning engineer hours come back to the study queue, and the engineer's day shifts from case setup to judgment on results.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Planning engineering labor | engineer hours avoided x your loaded planning engineer rate |
| Outside study support | consultant study hours avoided x your contracted consultant rate |
| Load you win on speed | the proposed load in megawatts x your own expected annual revenue per megawatt of served large load x the probability you assign to winning a deal you would otherwise lose on time to answer, a probability you set, not us |
| Right sized upgrades | your own estimated cost of the upgrade set a coarse screen would have assigned, minus the upgrade set the detailed study supports, on the cases where the two differ |
| Queue carrying cost | study weeks removed x your own cost per week of carrying an open request, including customer facing staff time and account management |
You pay for the modeling service and its compute, for the work of getting your planning network model and case library into it and keeping them current, and for planning engineer time to validate the accelerated results against studies you have already run by hand. That validation set is not optional and it is where your engineers will spend real hours in the first quarter.
Payback is normally carried by engineering labor and outside study fees, which you can audit from timesheets and invoices. The deal you win on speed is the larger number, and it is the one your CFO will discount hardest, so present it as upside rather than as the base case.
The safety effect here is indirect and we will say so plainly. Nobody climbs anything because of a hosting capacity map. The real mechanism is that accurate capacity values keep DER, distributed energy resources, from being approved onto feeders that then need reactive voltage work, emergency reconfiguration, and field verification trips to sort out.
Counted in units you already track:
Planning engineering hours come back to the distribution planning group and to interconnection staff, who stop running the same screening study over and over.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Planning engineering labor | engineering hours avoided x your loaded planning engineer rate |
| Outside study support | feeder studies you currently contract out x your consultant fee per feeder study |
| Interconnection screening labor | screening studies avoided x your loaded interconnection analyst rate |
| Deferred reinforcement | your own cost per feeder upgrade x the upgrades you decide are deferrable once you can see real headroom, a judgment you make, not us |
| Queue carrying cost | your internal cost of holding a project in queue per month x months of queue time removed |
You pay for the scoped engagement that builds and runs this, for the integration into your GIS and your DER enrollment records, and for your own planners to validate the twin against a sample of feeders they have already studied by hand. The honest large item is network model data quality. If your connectivity and transformer data are rough, the cleanup is real work and it is work you would have had to do anyway.
Payback is dominated by planning engineering hours and contracted study fees, because those are the two you can audit line by line. Treat deferred reinforcement as upside, not as the base 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 live hosting capacity service for distribution planners and interconnection staff: a map and per-node capacity values that refresh whenever the network model or DER fleet changes. 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 | read-only API |
| Planning and study tools | CYME, Synergi, WindMil | scheduled file export (CSV or CIM XML) |
| Metering (AMI head-end and meter data management) | Itron, Landis+Gyr, Oracle meter data systems | database replica refreshed nightly |
| Market and grid operator interfaces | PJM, MISO, ERCOT queues; OASIS | read-only API |
| Document and knowledge stores | regulatory filings, land records, permits | document upload |
| DER management (DERMS) and DER program platforms | Schneider, GE Vernova, EnergyHub, Uplight | read-only API |
Runs in your own cloud account on GPU instances or on an on-premises NVIDIA server, with read-only connections through your existing data zone and no link to control systems. The pilot runs in shadow mode: the live map is compared against your published map before anyone outside planning sees it.
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 planner who owns the public hosting capacity map in the GridCORTEX console:
Approve writes the refreshed per-node values to the GIS hosting capacity layer through the GIS API and refreshes the public map. Nothing in the network model or ADMS is touched; this is an advisory data update, and your planners still control the model of record.
The trigger is automatic: topology changes and DER additions arrive from the GIS, ADMS, and interconnection feeds, so the planner never enters anything.
Reads the network model from GIS and ADMS and the DER fleet continuously, AMI data daily; each card shows the as-of timestamp of the model it was computed from.
Lives as a GIS map layer and a GridCORTEX console page; email push when any feeder shifts more than 20 percent. 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: "We have PSS®E/CYME, a published hosting-capacity map, and an ADMS, isn't this that?" Here's the honest answer.
When someone asks "what did it actually calculate?", this is the list. In this sandbox the factors drive a simplified surrogate; in a pilot they are computed from your network model, GIS, AMI, and historian data, accelerated on NVIDIA infrastructure.
Presenter's one-liner: "Everything you just clicked would have been a months-long engineering study. The twin pre-computes the physics of the whole territory so those questions become queries, and when you're ready to commit, your own engineers validate the answer in the tools you already trust. That's what a digital twin is for."