Every VPP performs on day one. The question the grid asks is different: what have you got on day four of a heat dome, when the batteries are shallow, the thermostat customers are tired of being asked, the EVs aren't home, and the system needs the capacity more than it did on day one? BrightPlain Energy's VPP: 45,000 enrolled devices, 62 MW on paper, committed as a 42 MW resource. Four days, four events, and the two numbers that decide whether a fleet of houses is a power plant or a brochure: deliverable capacity, a forecast of physics AND of people, and the opt-out rate that quietly decides day four before day one is over. Cohort rotation, solar pre-charging, comfort guardrails, a mid-event re-optimization when fatigue shows up early, and the M&V receipt that protects next season's accreditation. The peaker that shows up on day four is made of houses.
| Without | With GridCORTEX | Δ |
|---|
| Without | With GridCORTEX | Δ |
|---|
The Fourth Day follows BrightPlain Energy, a fictional utility running a virtual power plant: thousands of small customer devices coordinated by software so they act like one large power plant. This one holds 45,000 enrolled devices: 30,000 smart thermostats, 8,000 home batteries, 5,000 electric vehicles, and 2,000 water heaters across four neighborhoods (NORTHSIDE, RIVERBEND, EASTGATE, SOUTH COMMONS). Day 1, 06:00, the forecast lands: a four-day heat dome at 103 to 107°F, with the grid needing relief for five hours, 15:00 to 20:00, every day. On paper the fleet is 62 megawatts. But paper capacity assumes every device performs every day, and the software runs the honest math on both machines and people. Call everything at full strength and the four days produce 44, then 36, then 29, then 24 MW, because batteries come back less charged each day and customers get tired of being asked and start opting out. A managed plan holds 41 to 42 MW all four days. So Recommendation 1 asks the program director to promise the grid 42 MW, not 62, and publish the four-day plan before day one starts.
Recommendation 2 manages the people side. Neighborhoods take turns, each resting one day, so no home is called more than two days straight. Houses pre-cool from 13:00 to 15:00, so thermostats can ease off later without anyone getting uncomfortable. Batteries charge up during the 11:00 to 14:00 midday solar window, topping off at 96% while power is cheap and plentiful. Electric-vehicle calls go only to cars whose own data confirms they are plugged in. And 1,140 medically vulnerable customers are never called at all; they are checked on instead. Event 1 delivers 41.8 of the promised 42 MW (99.5%), with 1.8% of customers overriding the call. Event 2 delivers 41.9 MW (99.8%) with opt-outs at 2.9%, exactly where the fatigue model predicted. Then Day 3, 40 minutes into the hottest event yet, the model fires a warning: opt-outs in RIVERBEND and EASTGATE are running three times the fleet average, 20 minutes from a rush for the exits that would take 6 MW with it. Recommendation 3 is a mid-event rebalance: release those two neighborhoods' thermostats immediately, cover the 6 MW from battery reserves and plugged-in vehicles, and shorten the remaining thermostat calls to 2.5 hours, staggered. Event 3 closes at 41.2 MW (98.1%) with opt-outs steadied at 4.1%.
Recommendation 4 handles the ending. Devices come back on in 15-minute waves, with batteries bridging until 21:30, so thousands of air conditioners do not all restart at 20:00 and create a second demand spike. The software also produces the official measurement paperwork that proves what each event actually delivered, plus a four-day evidence file for the grid operator. Day 4 is the test the demo is named for: the hottest day, the system's peak, the fourth straight day of asking, and the fleet answers with 41.5 of 42 MW (98.8%), opt-outs peaking at just 4.6%. The simulation ends at settlement: four honest measurement packages and an evidence file showing a resource that delivered 99% across a four-day heat dome. Decline the recommendations and the demo plays the other story: a 44 MW hero chart on day one, then 36, then 29 with 200 customers quitting the program in a single day, then 24 of the 42 MW promised on the day it all existed for, barely half. That brings a penalty for under-delivery, 18 MW of replacement power bought at emergency prices, and roughly $310K gone for the week.
The failure is treating 62 paper megawatts like a light switch: every device, full strength, every day. Day one looks like a triumph at 44 MW, but the fleet is spent as if there were no tomorrow. By Event 2 the batteries arrive half empty and delivery drops to 36 MW. By Event 3, customers worn out by daily calls override at 14%, and 200 quit the program in one day. Day 4, the day the grid actually peaks, delivers 24 of the 42 MW promised. The bill: a penalty for under-delivery plus replacement power bought at emergency prices, about $310K for the week; opt-outs at 19%; 3,800 customers gone from the program; and next season's official capacity credit cut from 42 toward 31 MW. Nobody modeled day four, so day four was lost before day one ended.
The software forecasts people as carefully as physics: how full the batteries will be after days of back-to-back use, how likely each thermostat customer is to say yes, which vehicles will actually be plugged in, and how fatigue builds neighborhood by neighborhood. That honest math turns 62 paper megawatts into a 42 MW promise the fleet keeps four days running (41.8, 41.9, 41.2, 41.5 MW). Resting neighborhoods in turn, pre-cooling homes, and charging batteries on cheap midday solar protect day four through restraint on day two. The live fatigue model catches the Day 3 opt-out surge at minute 40 and rebalances in 4 minutes. Staged restoration prevents the after-event spike. And the measurement paperwork protects an official capacity credit worth about $1.1M per year. The program director approves every promise, every event, and every rebalance, and no call ever exceeds what customers agreed to when they enrolled.
| KPI | Without GridCORTEX | With GridCORTEX | Delta |
|---|---|---|---|
| Day 4 delivery (the test)how much of the promised power the fleet actually produced on the fourth straight day of the heat wave | 24 / 42 MW (57%) | 41.5 / 42 MW (98.8%) | the whole point |
| Four-day profilemegawatts delivered on each of the four days; a flat line means the fleet paced itself | 44 → 36 → 29 → 24 | 41.8 → 41.9 → 41.2 → 41.5 | flat is the win |
| Opt-out trajectorythe share of customers overriding each day's call; it snowballs when the same homes are asked daily | 2 → 8 → 14 → 19% | 1.8 → 2.9 → 4.1 → 4.6% | the cliff never came |
| Day-3 fatigue signalthe mid-event warning that two neighborhoods were about to drop out in large numbers | invisible until the after-season reviews | caught at minute 40, rebalanced | 6 MW saved mid-event |
| Rebound snapbackthe second demand spike when every device restarts at once as the event ends | second peak at 20:05, covered with bought power | staged waves + battery bridge | the event stays won |
| Vulnerable customersmedically sensitive households that must never be asked to cut back | on the call list | never called; 1,140 protected | the regulator's first question, answered |
| Event-week economicswhat the four days cost or earned once penalties and replacement power are counted | −$310K in penalties and emergency-priced power | $0, commitment met daily | the week paid for the platform |
| Program attritioncustomers who quit the program during the week | 3,800 unenrollments | 240 | years of goodwill kept |
| Next-season accreditationthe official capacity credit the grid operator grants for power you can prove you will deliver | cut from 42 toward ~31 MW | 42 MW intact, receipt attached | ~$1.1M/yr of capacity value |
| Commit credibilitywhether the grid operator can trust the number the fleet promises | operators stop trusting the number | 42 promised, 42 delivered ×4 | a resource, not a program |
| M&V / settlementthe official measurement paperwork that proves what was actually delivered and settles payment | asserted, then disputed | honest baselines, ready for audit | the receipt IS the product |
| Customer experiencewhat the week felt like inside the enrolled homes | angry app reviews and cancellations | most never noticed | how these programs survive |
The safety effect is indirect and worth stating honestly. Managing over generation with dispatch rather than with hardware and switching means fewer manual field actions taken under time pressure on a constrained feeder.
Counted in units you already track:
Event handling hours come back to the DER operations engineer on shift, and settlement hours come back to the back office analyst who reconciles curtailment.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Avoided curtailment payments | megawatt hours of curtailment avoided x your compensation rate per megawatt hour under the applicable interconnection or program agreement |
| Operations labor | event handling hours avoided x your loaded DER operations engineer rate |
| Settlement labor | reconciliation hours avoided x your loaded settlement analyst rate |
| Deferred reinforcement | your own cost per feeder or transformer upgrade x the upgrades you judge deferrable because flexibility now manages the constraint |
| Make whole exposure | your contractual make whole or lost production payment per megawatt hour x megawatt hours no longer curtailed |
You pay for the scoped engagement that builds and runs this, for the integration into your DERMS, the distributed energy resource management system, and for telemetry quality work on enrolled resources, because an optimizer is only as good as the measurements it dispatches against. Plan on running it in shadow mode through one shoulder season while your operators build trust, and count that operator time as real cost.
Payback is dominated by avoided curtailment payments if you compensate for curtailed energy, and by deferred reinforcement if you do not. Work out which of those two you actually are before you build the case.
The safety effect is indirect. A VPP that actually delivers what it promised on a peak day reduces the emergency operations that follow when it does not: manual load transfers, callouts, and field staff working a hot afternoon into the night.
Counted in units you already track:
Event day hours come back to the program director and the monthly reporting week comes back to the program analyst.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Capacity value delivered | incremental megawatts delivered against commitment x your capacity price or your own avoided capacity cost |
| Program labor | event and reporting hours avoided x your loaded program staff rate |
| Underdelivery exposure | your penalty or shortfall charge per megawatt x the shortfall megawatts you currently incur in a typical season |
| Market revenue | megawatt hours bid into energy or ancillary products x the settled price in your market, for the hours the portfolio was previously idle |
| Incentive efficiency | your incentive payment per enrolled device x the devices you no longer need to call because the dispatch is better ordered |
You pay for the orchestration platform, for an integration to each vendor DERMS dispatch interface, and for the contract work to get the vendors to expose those interfaces at all, which is often the slow part. Your program staff also need time to validate the combined forecast against a season of real events before they will offer against it.
Payback is usually dominated by the capacity value of delivering the commitment plus the penalty exposure you stop carrying. Program labor is real but it is the smaller line.
The safety effect is indirect and specific. Capacity that is offered but not delivered is capacity the system operator counted on, and the actions that follow a shortfall are the dangerous ones: emergency load transfers, manual shed, and crews working a multi day heat event into the night.
Counted in units you already track:
Settlement and evidence assembly hours come back to the analyst, and forecasting hours come back to the resource adequacy manager.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Accredited capacity value | the change in accredited megawatts x your capacity price in the applicable market, using your own accreditation methodology |
| Shortfall exposure | your ISO, the independent system operator, penalty or shortfall charge per megawatt x the megawatts you currently fall short in a typical season |
| Settlement and evidence labor | package assembly hours avoided x your loaded settlement analyst rate |
| Enrollment retention | your customer acquisition cost per enrolled device x the enrollments retained by rotating cohorts instead of over calling them |
| Program forecasting labor | forecasting and offer preparation hours avoided x your loaded resource adequacy manager rate |
You pay for the scoped engagement that builds and runs this, for device level telemetry feeds from each vendor platform, which is often a contract negotiation before it is an integration, and for your own staff to validate the forecast against a full season of events before you offer against it. Expect to run one season in parallel with your current method.
Payback is usually dominated by shortfall penalty exposure removed plus the accredited capacity you can defend, with settlement labor as the auditable floor.
This one has a direct field mechanism and it runs in two directions. A welfare check is a person walking up an unfamiliar driveway, often after dark, sometimes into a household in distress, and today those visits are dispatched broadly because nobody knows who was actually reached. Reaching people by phone and text first sends the in person visits only where they are needed. The other direction matters more: a life support customer reached before the outage is a customer who is not in medical distress during it.
Counted in units you already track:
The coordinator gets list building and reconciliation back, and the care team spends the event making contacts instead of maintaining a spreadsheet.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Coordinator and analyst labor | events per year x hours per event avoided x your loaded coordinator rate |
| Outreach labor | attempts avoided by reaching the right channel first x minutes per attempt x your loaded care representative rate |
| Welfare check field cost | in person checks avoided because contact was confirmed remotely x your fully loaded cost per field visit, including vehicle and mileage |
| Regulatory reporting | event reports per year x hours to assemble the contact record today x your loaded regulatory analyst rate |
| Complaint and inquiry handling | complaints and commission inquiries about missed vulnerable customer notification x your loaded hours per case, from your own case history |
You pay for the GridCORTEX planning service, for integrations into your customer information system registry, outage management system, contact center platform, and work management system, and for your own care and regulatory staff time to approve scripts, set priority rules, and release every batch. The registry cleanup you will want to do first is real work and it belongs to you, not to us.
Payback here is not mainly dollars and you should say so internally. The countable savings are coordinator hours and avoided in person checks. The reason to buy it is the regulatory and reputational exposure of one missed life support customer, and only you can size that.
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 forecasting and settlement evidence service for DER and resource adequacy teams: a deliverable-capacity forecast per event, device class, and event day, plus the measurement and verification package the ISO needs for accreditation. The demo above uses synthetic data; everything below describes what the real deployment needs from your organization.
| Your system | Typical products | How we connect |
|---|---|---|
| DER management (DERMS) and DER program platforms | EnergyHub, Uplight, Virtual Peaker | read-only API |
| Metering (AMI head-end and meter data management) | Itron, Landis+Gyr, Oracle meter data systems | database replica refreshed nightly |
| Market and grid operator interfaces | CAISO, PJM, MISO portals; settlements | scheduled file export (CSV or CIM XML) |
| Weather and environment | National Weather Service feeds, commercial forecast services | read-only API |
| Customer Information System (CIS) / billing | Oracle CC&B, SAP IS-U | database replica refreshed nightly |
| Outage Management System (OMS) | GE PowerOn, Oracle NMS, ADMS outage module | read-only API |
| Contact center platform | Genesys, NICE, outbound notification systems | read-only API; outreach lists are written back only after a person approves, via your existing system's own interface |
Runs in your cloud account on GPU instances with customer data anonymized on a need-to-know basis; all connections are read-only and nothing dispatches anything. The pilot is a backtest against last event season, so no live operation is required.
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 resource adequacy manager in the GridCORTEX console:
Approve submits the capacity offer through your existing market interface, subject to the ISO's own validation and confirmation, and writes the dispatch cap to the DERMS as a program setting your team can change. GridCORTEX uses your existing market pathway; it never bids outside it.
Event days and fleet state arrive automatically from the ISO interface and vendor platforms; declare an unscheduled event with one click plus the MW obligation and window.
Device state of charge and opt-outs stream from vendor platforms near real time, weather every 15 minutes; each forecast card shows its as-of timestamp.
Lives in the GridCORTEX console; mobile push during event sequences when the forecast drops below the commitment. 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 VP of DER: "We have a DERMS, three vendor DR platforms, and a program team that runs events every summer, what's new here?" Here's the honest answer.
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 program's event history, device telemetry, and AMI data.
Presenter's one-liner: "Sixty-two megawatts on paper, and the model committed forty-two, because forty-two is what day four could actually deliver. It rotated who got asked, pre-charged the batteries on free solar, never called the vulnerable list, caught the fatigue cliff on day three forty minutes in and re-balanced mid-event, and staggered the restoration so the rebound never showed. Day four, the hottest day, the tiredest fleet, 41.5 of 42, and the ISO got the receipt. The peaker that showed up was made of houses."