Wind Power Forecasting for Operations: Build a Decision Ledger Before You Add AI

Problem definition: A wind forecast is not ready for operations just because it predicts megawatt-hours. The dispatch, trading, or asset-management team needs to know what was known when the forecast was issued, whether the turbines were available, how uncertain the forecast was, and when a person must intervene. This guide shows how to run that control loop for a wind plant. It does not prescribe a bidding rule for any market.

Recommendation: start with a decision ledger, not a new model

Use an ML correction only after it is evaluated beside a persistence baseline and an NWP-only baseline at the same issue time and delivery interval. Keep the first release advisory: a human accepts, changes, or rejects the suggested schedule. Do not start with automatic market submission if your team cannot reconstruct an individual forecast decision later.

This approach suits operators with timestamped SCADA data, a defined scheduling process, and someone who owns exceptions. It is a poor first project for a small site with unreliable availability labels or no operational consequence tied to the forecast. In that case, improve data capture and the manual forecast review before adding a model.

What the system must separate

A useful forecasting system has four distinct layers. Combining them makes both measurement and recovery harder.

Layer	Question it answers	Output to retain
Weather input	What did the weather provider predict at issue time?	Provider, run time, location mapping, horizon, ensemble or quantiles
Plant state	Could the turbines have produced?	Availability, curtailment, maintenance, communications status
Forecast model	What output range follows from those inputs?	Persistence, NWP-only, corrected P10/P50/P90 forecasts and model version
Decision control	What did the operator do and why?	Suggested action, approval, override reason, fallback reason

ECMWF describes ensemble forecasts as a way to represent forecast uncertainty; wider spread means lower confidence. That is why a single P50 value is not enough for a control decision. NREL’s wind-forecasting material also frames forecasts around operational horizons such as dispatch, scheduling, and reserve planning rather than a generic accuracy score.

Design trade-offs: simple baselines first

Approach	Best use	What it gives up	Promotion condition
Persistence	Short-horizon sanity check	Misses weather changes	Never remove it; it is the fallback benchmark
NWP-to-power mapping	Day-ahead planning with explainable inputs	Plant-specific bias can remain	Data and issue-time snapshots are stable
ML correction	Repeated, measured plant-specific error patterns	More monitoring and drift risk	It beats both baselines across pre-agreed slices

Do not claim that ML is better from one average MAE. Measure error separately by horizon, wind regime, season, availability state, and high-cost settlement interval. A small average gain can be operationally useless if it worsens the intervals that trigger the largest penalty or reserve cost.

Step-by-step: build a controlled pilot

1. Freeze the decision timestamp

For each run, store the UTC issue time before joining any later observations. Retrieve only the weather forecast and turbine state that were available at that moment. A backtest that joins corrected observations or revised weather runs is not evidence for production performance.

issued_at_utc, delivery_start_utc, horizon_h,
nwp_run, nwp_power_mwh, persistence_mwh,
ml_p10_mwh, ml_p50_mwh, ml_p90_mwh,
availability_state, curtailment_flag, model_version,
decision, override_reason, fallback_reason

2. Label unavailable production before scoring

Mark outages, maintenance, curtailment, communications loss, and plausibility failures separately from normal weather-driven production. A model cannot learn the right wind-to-power relationship if an unavailable turbine is treated as weak wind. Preserve the raw SCADA value as well as the operational label so an auditor can revisit the classification.

3. Run three forecasts on every issue

Generate persistence, NWP-only, and ML-corrected forecasts for the same delivery intervals. Add a forecast interval from an ensemble, quantile model, or calibrated residual distribution. The interval is a control signal, not decoration: route a wide interval to review instead of silently using the midpoint.

4. Define review and fallback before the pilot starts

Write a local rule with the operations and risk owners. For example: review when required input is missing, the interval is wider than the team’s agreed tolerance, or the plant state is unclear. Fall back to the NWP-only or persistence view when a required feed is stale, the model version is unapproved, or the pilot’s pre-agreed quality test fails. The thresholds belong to the local market and contract; they are not universal numbers.

5. Compare by decision-relevant slices

After actual delivery data arrives, calculate MAE and signed bias for each horizon, then check interval coverage: how often did actual output land between the lower and upper forecast bounds? Review the results by plant availability and costly intervals. Keep the comparison table versioned; it is the evidence required to promote, pause, or roll back the model.

Pitfalls and recovery

• Leakage from revised data: A historical test uses a weather run or availability correction that was not available at issue time. Recovery: rebuild the evaluation dataset from immutable issue-time snapshots and rerun the comparison.
• Outage data treated as weather error: The model learns that a stopped turbine means low wind. Recovery: exclude or label non-available intervals, retain the original SCADA record, and rescore each availability class.
• One score hides an unsafe segment: A low MAE masks systematic over-forecasting during high-cost intervals. Recovery: add signed bias and decision-cost slices to the review report; hold the ML recommendation for the failing slice.
• Silent input failure: A stale weather feed produces a plausible-looking forecast. Recovery: check source run time and expected record count before inference, then publish the fallback reason with the forecast.

Cost and operating ownership

The recurring cost is not only model inference. Budget for weather-data access, storage of issue-time snapshots, SCADA quality work, monitoring, and a named person or rotation to handle exceptions. A managed vendor can reduce model-maintenance work, but it does not remove the need to define plant availability, approval authority, or the fallback rule. A small internal pilot is usually preferable when those local rules are still unknown.

Limits and alternatives

This workflow improves decision traceability; it does not guarantee forecast accuracy, revenue, or regulatory compliance. Market rules, telemetry quality, turbine fleet differences, and weather-provider coverage determine what can be automated. If your main problem is missing SCADA labels, use a data-quality project first. If operators already have a reliable vendor forecast but lack accountability, add the decision ledger and review queue before replacing the forecast engine.

Further study

• ECMWF: Medium-range forecasts — ensemble spread and forecast uncertainty; accessed August 18, 2026.
• NREL: Forecasting Wind and Solar Generation — operational uses across forecast horizons; accessed August 18, 2026.
• OpenOA documentation — reproducible wind-plant operational analysis; accessed August 18, 2026.

For related operating patterns, see our AI workflow automation guide, evaluation and drift review guide, and human approval queue guide.

Implementation checklist

• Every forecast has an immutable UTC issue time and delivery interval.
• Persistence, NWP-only, and corrected forecasts share the same evaluation rows.
• Availability, curtailment, and maintenance are labeled independently of weather error.
• Forecast uncertainty is retained and has an explicit review rule.
• Signed bias, MAE, and interval coverage are reviewed by horizon and decision-relevant slice.
• A named owner can approve an override and invoke the fallback.
• The local market and contract rules have been reviewed before any automated submission.

Definition of done: for a pre-agreed pilot period, the team can reproduce each forecast decision from issue-time inputs, explain every override, and safely fall back when a required control fails.

Editor’s judgment: I recommend this ledger-first sequence for teams moving from manual forecasts to AI-assisted scheduling. I do not recommend a black-box, fully automated rollout before the data and review controls exist. The operational question is not whether a model can produce a number; it is whether the team can defend, monitor, and reverse the decision made from that number.