Rule-based demand response dispatch made sense when the assets being dispatched changed state slowly and predictably. A commercial HVAC system set to pre-cool before a demand response event. A large industrial load that could shed 500 kW on a 10-minute notification. These are assets with defined response envelopes. Static threshold rules handle them adequately.
Virtual power plants built on residential solar and battery assets operate in a fundamentally different regime. The individual asset response envelope is narrow (a 5 kWh battery can only do so much), the fleet is large and geographically distributed, generation output changes on timescales of minutes, and the aggregate dispatchable capacity at any given moment depends on the intersection of current SoC across hundreds of batteries and real-time solar output across thousands of inverters. Rule-based dispatch, applied to this kind of portfolio, will leave capacity on the table in the scenarios that matter most.
What rule-based VPP dispatch actually does
A typical rule-based VPP dispatch system works roughly like this: the program administrator defines trigger conditions (system load exceeds X MW, locational marginal price exceeds Y $/MWh, operator manual trigger) and response actions (dispatch battery assets with SoC above Z%, request curtailment from enrolled solar inverters, notify enrolled customers). When the trigger fires, the system issues dispatch signals to qualifying assets and logs the event.
This architecture is deterministic and auditable, which are genuine operational virtues. An operator can trace exactly why a dispatch was or was not triggered. The ISO settlement documentation is clean. The program rules are legible to both the operations team and the program participants.
The problem is that the rules are static and the conditions are dynamic. The SoC threshold Z% was set during program design based on an assumption about what constitutes a "charged enough" battery to contribute meaningfully to a dispatch event. But whether a battery at 60% SoC should be dispatched depends on how long the dispatch event is expected to last, what the grid state is on the specific feeder that battery sits on, whether the battery has been cycled heavily in the past 48 hours, and what the solar forecast looks like for the next three hours. Static rules cannot incorporate all of those variables simultaneously.
The scenario where static rules fail most visibly
The failure mode that made us most skeptical of pure rule-based dispatch is the rapid solar ramp-down scenario.
A well-studied pattern in high-solar-penetration service territories: a frontal cloud system moves over the service territory in mid-afternoon. Solar generation falls 35 to 45 percent within 10 to 15 minutes. For a VPP with 3,000 enrolled solar-plus-storage customers contributing, say, 12 MW of aggregate solar generation at the time of cloud passage, that is 4 to 5 MW of generation disappearing faster than a demand response program's standard 10-minute notification period.
In a rule-based system, the response chain looks like this: the load spike that follows the solar drop triggers the demand threshold rule; the system issues dispatch to batteries with SoC above the threshold; those batteries begin responding within their standard ramp time. But the notification, confirmation, and ramp cycle takes time. If the peak demand charge window closes before the battery response reaches full dispatch, the utility absorbs the peak charge and the VPP program's financial case takes a hit.
An adaptive dispatch system that has been continuously tracking generation forecast confidence intervals can anticipate this scenario. When the 15-minute solar forecast shows sharply increasing uncertainty (standard deviation widening significantly), the dispatch model can begin pre-positioning battery reserves before the ramp-down occurs rather than reacting after it.
What AI dispatch actually adds to the decision process
The honest framing here is that AI dispatch is not magic; it is a better optimization loop. The inputs to the dispatch decision are the same: asset SoC, grid state, load forecast, generation forecast. The difference is that a continuously updating model can weigh those inputs against each other in ways that static threshold rules cannot represent.
Specifically, there are two improvements that matter operationally. First, the optimization can consider the full portfolio simultaneously rather than applying rules asset-by-asset. When 800 batteries qualify for dispatch under a static SoC rule, an AI dispatch system can order them by their feeder-level impact, battery thermal state, and recent cycling history, and issue a staged dispatch that achieves the needed load reduction while minimizing battery wear and maintaining reserve margins. A static rule dispatches all 800 uniformly; the AI dispatches 400 strategically.
Second, the forecast uncertainty signal can be incorporated directly into dispatch timing. A probabilistic load forecast that shows a 70% confidence interval spanning 8 MW to 14 MW suggests a very different dispatch posture than one spanning 10 MW to 11 MW. Rule-based systems don't act on forecast uncertainty as a first-class signal; they act on point estimates exceeding thresholds.
Where rule-based systems remain the right tool
We are not arguing that rule-based dispatch should be replaced wholesale. There are dispatch scenarios where deterministic rules are the correct approach, and removing them would introduce reliability risks.
Voltage support actions on specific feeders are one example. When a feeder voltage drops below a defined threshold due to a specific load or generation event, the corrective action (requesting reactive power adjustment from nearby inverters via IEEE 2030.5) needs to execute deterministically and quickly, without probabilistic deliberation. That is a rule, and it should stay a rule.
Emergency load shedding under NERC reliability standards is another. The rules there are regulatory requirements, not optimization preferences. An AI dispatch system layered on top of a VPP should not interfere with deterministic emergency response logic.
The practical architecture that works well is a layered model: deterministic rules for safety and regulatory requirements, AI optimization for economic dispatch and DER portfolio coordination. The two layers need to be aware of each other's actions; a key failure mode in early hybrid implementations is when the optimization layer doesn't know the rule layer just issued an emergency signal and the two actions conflict at the asset level.
Implementation considerations for VPP operators
Moving from rule-based to AI-assisted dispatch in an active VPP is not a flag-flip. The operations team needs confidence that the AI recommendations are explainable, not a black box. An operator who cannot understand why a dispatch recommendation is suggesting pre-positioning 200 batteries before a visible trigger condition will override it every time, correctly. The AI dispatch layer needs to surface its reasoning: "pre-positioning recommended based on solar forecast uncertainty widening on feeders F-22 through F-31; expected generation loss 3.2 MW within 18 minutes, 65% confidence."
That explanation is also what goes into the dispatch audit log. ISO settlement documentation and program reporting require traceability. An AI dispatch event needs to carry the same decision context that a rule trigger carries, because the downstream accountability is the same.
The progression from pure rule-based to AI-assisted dispatch that we have seen work in practice starts with running both in parallel: the AI model generates recommendations in shadow mode while rule-based triggers continue to govern actual dispatch. Operations teams review the AI's divergent recommendations over several weeks, build intuition about where it catches things the rules miss, and define the scenarios where they want AI recommendations to escalate to operator confirmation rather than auto-execute. That parallel period is not optional; it is how the operations team builds the trust needed to let the AI act.