There is a meaningful and often glossed-over distinction between a system that surfaces a dispatch recommendation and a system that executes it automatically. Here is why that boundary matters for grid operations teams, and why staying on the right side of it is the faster path to operator adoption.
Why the distinction matters for NERC and state regulation
NERC reliability standards draw a clear line between decision support systems and control systems. A system that generates recommendations for human review sits in a different regulatory category than a system that executes switching operations without individual human authorization. The compliance burden for the latter category is substantially higher, the testing and certification requirements are more demanding, and the documentation requirements for any event are more extensive.
For distribution systems that are not subject to NERC reliability standards at all, the distinction is still practically important. Your operations team's accountability structure, your insurance requirements, and your liability exposure in the event of a grid event all look different depending on whether an automated action or a human-authorized action initiated the sequence of events.
The operator adoption argument
Aside from the regulatory considerations, decision support is also the faster path to useful adoption. An automated dispatch system requires operators to trust the system enough to remove themselves from the execution path. That level of trust takes years to build and requires a track record of reliable operation across diverse conditions. A decision support system requires operators to trust the system enough to treat its recommendations seriously, which is a lower bar that can be established in months.
The practical sequence is: shadow operation (operators see recommendations, compare against their own judgment, build calibration), then active use with low-stakes recommendations first, then expansion to higher-stakes recommendations as confidence builds. Automating execution would require skipping most of this sequence, which most operations teams are not willing to do regardless of what the system's test performance shows.
What makes a recommendation actionable
A dispatch recommendation that operators will actually act on contains three things: a specific proposed action (switch tie at location X to shift load from feeder A to feeder B), a quantified expected outcome (projected to reduce feeder A's peak from 91 percent to 77 percent of rated capacity), and a confidence indicator based on the current forecast quality and the reliability of the recommendation model on similar historical situations.
Recommendations without specific proposed actions are not actionable. "Feeder A may be approaching capacity risk" is a monitoring alert, not a dispatch recommendation. "Activate tie switch at substation X to shed 15 MW from feeder A to feeder B, expected to reduce projected peak by 14 percent" is a dispatch recommendation. The operator can evaluate it in 30 seconds and make a decision.
Building toward the automation case over time
The long-term path toward automating some dispatch decisions runs through the recommendation stage. When operators have been reviewing and acting on system recommendations for 18 to 24 months, and the recommendation accuracy has been tracked and validated across that period, the case for automating specific low-risk, high-frequency actions becomes concrete rather than theoretical. You have a performance record to evaluate and a defined scope to automate rather than a general claim that the system is ready.
What goes into a recommendation that operators accept
Operator acceptance of dispatch recommendations is not purely a function of accuracy. How a recommendation is displayed and contextualized matters significantly. A recommendation that presents the proposed action, the expected outcome, and the basis for the recommendation (which feeder conditions and forecast values triggered it) takes longer to design but gets acted on more consistently than a bare alert with a proposed action appended.
We have found that showing the 30-minute and 2-hour load trend for the affected feeder alongside each recommendation is one of the most effective additions to recommendation presentation. An operator can see in a single view whether the condition is developing as forecast, whether a switching operation proposed 90 minutes ago is still applicable, and what the projected outcome looks like under the current trend. This contextual information is what separates a system that operators use thoughtfully from one they either follow blindly or ignore.
Handling recommendations that operators override
Operators will not act on every recommendation. That is expected and correct. The recommendation system is not a control system, and operator judgment about specific local conditions, crew availability, or equipment state will sometimes override the model's suggestion. The important thing is that overrides are recorded and reviewed.
Ampgrove maintains an override log that tracks which recommendations were not acted on and the subsequent feeder behavior. This serves two purposes: it allows us to identify patterns where recommendations are consistently overridden on specific feeder types or conditions, which informs model refinement, and it gives the operations team a record that demonstrates active engagement with the recommendation system for reliability reporting purposes. Overrides are not failures. They are part of the human-in-the-loop architecture working as designed.
Training operations teams for effective AI-assisted dispatch
Effective use of an AI-assisted dispatch recommendation system requires operations team training that goes beyond software onboarding. Operators need to understand the accuracy characteristics of the forecast at different horizons, the types of feeder conditions that produce higher-confidence versus lower-confidence recommendations, and the appropriate response protocols for recommendations at different confidence levels.
Our deployment process includes a structured 4-week shadow operation period where operators review recommendations without acting on them, building calibration between model outputs and their own assessments. During this period, we collect data on where operator and model assessments diverge and use those divergences to identify either model refinement opportunities or cases where operator intuition about local factors the model cannot see is genuinely superior to the model's suggestion.
After shadow operation, the transition to active recommendation use is typically gradual: starting with recommendations on feeders that operators are most familiar with, expanding to the full monitored set over the following 4 to 6 weeks. Utilities that follow this ramp-up process consistently show higher long-term recommendation utilization rates than those that go directly to full deployment on all feeders from day one.