All case studiesProof of concept
Probabilistic grid load forecasting with an approval gate: proof of concept.
An energy operator dispatched against a single-point spreadsheet forecast, with no uncertainty range and no record of decisions. A proof of concept demonstrated P10, P50 and P90 load forecasts, drift checks, a decision log and an approval gate in the tested workflow.
- Client
- An energy operator
- Sector
- Energy, grid operations
- Engagement
- Proof of concept
- Validated result
- P10 / P50 / P90probabilistic forecasts
P10 / P50 / P90probabilistic forecasts
Growth goal
Give grid operators load forecasts they can dispatch against, with the uncertainty visible.
Operating constraint
Dispatch ran on one forecast number per interval, with no drift monitoring and no record of the forecast behind a decision.
Validated result
P10, P50 and P90 forecast ranges, drift checks, a decision record and an approval gate, demonstrated in the tested workflow.
Summary
- Challenge
- Operators read a spreadsheet forecast and applied their own buffers. Past decisions could not be reviewed against what the operator had seen.
- What SIEL built
- Forecasts with P10, P50 and P90 values per interval, drift checks against realised load, and an assistant that assembles each dispatch proposal.
- Controls
- The assistant never dispatches. Every proposal passes an approval gate, and each decision is logged with the forecast shown, the action and the approver.
- Impact
- The tested workflow showed the four elements working together, with every decision traceable to the forecast behind it.
The full account
01One number and no record
The operator's grid is carrying more variable generation and demand, and dispatch teams are accountable for both stability and cost. Their decisions rested on a single load forecast per interval in a spreadsheet, adjusted by each operator's own buffer. There was no view of the plausible low and high cases, no warning when the forecasting model drifted, and no record of which forecast a decision had been based on.
02Forecast ranges and drift checks
In the proof of concept, we built forecasts that give P10, P50 and P90 load values for each interval. Load should fall below the P10 value in only one interval in ten and exceed the P90 value in only one in ten, so operators see how wide the uncertainty is, not only the central estimate. Drift checks compare forecasts with realised load. When the error moves outside agreed bounds, the model is flagged for review. It is treated as a monitored component, not a black box.
03A dispatch assistant behind an approval gate
An assistant sits alongside the existing dispatch tools, not in their place. When an operator prepares a plan, it shows the plan against the low, central and high cases and assembles a proposal with the forecast values, the planned action and the operator's notes. The assistant cannot dispatch. Every proposal passes an approval gate, a distinct recorded step where a named person takes responsibility.
04What the proof of concept showed
In the tested workflow, all four elements worked together: forecast ranges, drift monitoring, the decision log and the approval gate. Each decision was logged with the forecast available at the time, the action and the approver, so a past day can be reviewed against the uncertainty the operator actually saw. The workflow is not in production. A production build would connect to live grid data and the dispatch systems, and run alongside the current process before operators rely on it. We would keep the approval gate and the decision log as fixed requirements of any production version.
Discuss Your Operation With Our Engineers.
Describe one workflow and the systems it relies on. A senior engineer responds within two business days with an initial assessment: what we would build, what we would not, and why.