Grid operators are not generally resistant to automation. They use SCADA systems, automatic generation control, and protection relay logic every day without needing to understand every underlying calculation. The skepticism toward AI-based dispatch recommendations is specifically a skepticism toward decisions they cannot interrogate when something unexpected happens.
That is a rational position. When an automatic protection relay trips a line, the trip logic is documented, testable, and traceable. The operator knows why the trip occurred. When an AI dispatch system changes a battery schedule from the planned profile, the operator needs to know why too, especially if the change is counterintuitive or if something goes wrong downstream.
The Override Problem
The practical consequence of unexplained recommendations is manual override. In operations centers where AI dispatch recommendations run alongside operator screens, an operator who does not understand why the system is suggesting a particular battery charge/discharge schedule will frequently override it and revert to their own judgment.
This is not a failure of the operator's technical skill. It is a failure of the human-machine interface. When a system issues a recommendation without supporting context, a trained professional has no basis for deciding whether the recommendation reflects information they did not have or a model behavior they should distrust. Defaulting to override is the conservative response under uncertainty.
The consequence, from a system performance standpoint, is that the AI's potential value is largely unrealized. The model may be producing optimal dispatch schedules, but if those schedules are consistently overridden because operators cannot verify the logic, the operational output reverts to human intuition with a slightly better underlying data feed.
What "Explainability" Actually Means in a Dispatch Context
The term explainability covers a range of different capabilities, and not all of them are operationally useful for grid dispatch.
Feature importance scores, such as those produced by SHAP (SHapley Additive exPlanations), tell you which input variables had the most influence on a particular model output. This is useful for model validation and for identifying when a model is relying on spurious correlations. But for an operator sitting at a dispatch screen at 09:30, "irradiance forecast confidence was the dominant feature" is not actionable information.
What operators actually need is decision-path transparency: why did the dispatch schedule change from what was planned, and what would need to be different for it not to have changed? This is closer to counterfactual explanation than to feature attribution. The distinction matters for how explainability is implemented.
A useful dispatch explainability output might read: "Battery charge schedule for 10:00-12:00 was revised from 3 MW charge to 1 MW charge because the revised solar forecast shows cloud cover reducing generation to an estimated 40% of plan during this window. To maintain committed delivery at 14:00-16:00, the system is preserving SOC rather than charging at the originally planned rate." That sentence contains a forecast update, a causal chain, and a decision rationale. An operator can accept or override it with full understanding of what they are accepting or overriding.
Approaches That Work in Practice
Forecast-linked dispatch explanations
For solar dispatch, the most frequent reason for a schedule revision is a forecast update. Linking the dispatch recommendation directly to the specific forecast change that triggered it is a straightforward explainability layer that covers a large fraction of real-world explanations. The format is: "Recommendation changed because [forecast metric] changed from [value A] to [value B]."
Constraint surfacing
Dispatch decisions are often driven by constraints that the operator may not be tracking in real time: SOC floor requirements before a committed delivery window, interconnection limits, or imbalance penalty thresholds. Surfacing the binding constraint (the one limiting the dispatch option that would otherwise be preferred) converts an opaque output into a navigable one. Operators can then decide whether to relax the constraint or whether the system's constraint definition needs updating.
Scenario comparison
Rather than issuing a single recommendation, presenting two or three dispatch scenarios with their expected outcomes (projected SOC at end of day, expected revenue, imbalance exposure) gives operators a structured basis for judgment. This approach treats the AI as a scenario generator rather than a decision maker, which is often a better fit for how experienced operators prefer to work. The tradeoff is operational speed: reviewing scenarios takes longer than accepting a single recommendation.
What Explainability Cannot Fix
Explainability is not a substitute for model accuracy. A model that produces clearly explained recommendations that are systematically wrong will lose operator trust faster than a black-box model that is occasionally correct. The sequencing matters: accuracy needs to be established and verifiable through backtesting against historical data before explainability layers add value. An operator who has seen evidence that the model's recommendations outperformed manual dispatch in back-tests has a reason to take the explanations seriously. Without that evidence, explanations are just a narrative accompanying an untrusted output.
We also do not claim that full decision transparency is achievable in all cases. For neural network-based components of a dispatch model, the feature attribution approach gives a useful but incomplete picture of the model's internal logic. The goal is not complete transparency. It is sufficient transparency: enough information for an operator to make a calibrated judgment about whether to follow the recommendation or override it.
Explainability as Operational Infrastructure
The practical path for building operator trust in AI dispatch systems is to treat explainability as infrastructure, not as a post-hoc communication exercise. This means the forecast model and the dispatch optimizer are designed from the start to emit explanation objects alongside their numerical outputs, in a format that can be displayed in the operator interface without manual interpretation.
When an explanation is wrong or missing, it should be as visible an error as a missing dispatch recommendation. An operator who notices that a schedule changed without an explanation has found a bug in the explanation pipeline, not just a mysterious recommendation. Building this kind of accountability into the system changes how both the technology team and the operations team relate to the AI component: it is no longer a black box that must be trusted or overridden. It is a system with traceable logic that can be audited, improved, and eventually delegated to.
