Picture three forecasters at the same utility staring at three different screens: one is running the net-load model that accounts for behind-the-meter solar; one is reconciling the morning's weather forecast ensemble; one is building a high-growth scenario for a data-center rate case. None of them is talking to the others. Their outputs will collide in the resource planning meeting at 2 p.m., and the planner chairing that meeting will have to reconcile three incompatible numbers on the spot. This is not a technology failure. It is a pipeline architecture failure, and it is how most utilities still operate.

Why Separate Forecasts Are a Reliability Problem

The day-ahead load forecast has three analytically distinct components that are often modeled separately: the gross load forecast (what physical consumption will be, before any DER offset), the DER offset forecast (what behind-the-meter solar, storage, and demand response will subtract from or add to grid-served load), and the scenario layer (what assumptions about economic growth, data-center expansion, or policy changes will produce alternate load trajectories for planning decisions). When these components are modeled in separate workflows, with separate teams, separate data sources, and separate review cycles, the resulting forecasts are internally inconsistent.

The consistency problem is not abstract. If the gross load model uses a 3 percent annual growth assumption and the DER offset model uses a 5 percent growth assumption for rooftop solar, the net load forecast embeds a tension between those two assumptions that neither team is aware of. If the scenario planner uses a different weather normalization than the gross load team, the high-growth scenario and the base-case day-ahead forecast are not comparable. When the planner stacks these in a capacity planning model, the errors compound.

The solution is a unified pipeline architecture where the net-load, weather, and scenario models are explicitly linked: they share input data sources, share assumptions about key parameters, and produce outputs that are reconciled before they reach any decision-maker. This lesson walks through how that architecture works and what it takes to make it defensible.

The Three Model Components and How They Connect

Net-Load Model: The Grid-Serving Load

Net load is the load that the transmission and distribution system must actually serve after accounting for behind-the-meter generation and storage. The formula is straightforward: net load equals gross load minus behind-the-meter DER output. In practice, building an accurate net-load model is significantly harder than this formula suggests, because behind-the-meter resources are, by definition, on the customer side of the meter and are not directly measured by the utility's SCADA or AMI systems in real time.

The net-load model requires three sub-components. First, the gross load forecast from the AI forecasting system described in the previous lesson. Second, a DER output forecast that estimates the generation and storage output of behind-the-meter resources by zone and interval. This DER output forecast is itself a model: it ingests the solar irradiance forecast (from the weather model), the DER registry of installed capacity by zone, and behavioral patterns about when storage charges and discharges. Third, a reconciliation mechanism that combines the gross load forecast and the DER output forecast into a net load number while propagating the uncertainty from both components.

The DER output forecast is where the greatest accuracy challenges currently lie. Behind-the-meter solar capacity has been growing faster than most utility registries can track; in fast-growth service territories, the registry may be 10 to 20 percent behind actual installed capacity. The behavioral patterns of behind-the-meter storage are highly variable: some batteries are programmed for price arbitrage, some for demand-charge reduction, and some are enrolled in utility demand-response programs where the utility has partial dispatch visibility. Each of these behavioral patterns produces a different net-load signature, and a single aggregate DER model may not resolve them correctly.

Weather Model: The Shared Driver

Weather is the single most important input driver for both the gross load forecast and the DER solar output forecast, yet many utility forecasting organizations treat weather as two separate inputs, one for load and one for solar, obtained from potentially different providers or different model runs. This creates a fundamental inconsistency: the load forecast may assume a partly cloudy 88-degree afternoon while the solar forecast assumes a clear 88-degree afternoon, producing a net-load number that is systematically biased because it combines a conservative load estimate with an optimistic solar estimate.

The unified pipeline uses a single weather forecast source for all models. This sounds simple but requires deliberate architecture. The weather forecast file is ingested once, goes through the quality gate once, and is distributed to both the gross load model and the DER solar model as the same data object. Any update to the weather forecast (for example, a model run revision at noon that changes the afternoon temperature by three degrees) must be propagated simultaneously to all dependent models, not selectively to one.

Weather uncertainty is also a shared source of uncertainty. When the weather forecast ensemble shows high spread (meaning the forecast models disagree significantly about tomorrow's conditions), that uncertainty must be reflected simultaneously in the load forecast confidence band, the DER output confidence band, and the net-load confidence band. A pipeline that produces a tight net-load confidence band by coincidentally canceling weather uncertainty in the load model against weather uncertainty in the DER model is not producing accurate uncertainty estimates; it is producing the mathematical accident of correlated errors that reduce apparent variance.

Scenario Model: The Planning Layer

The scenario model is the layer that translates a base-case day-ahead forecast into a range of planning assumptions about the future load trajectory. It answers questions like: what does the next 10 years look like if data-center load in this zone grows at 15 percent annually? What if behind-the-meter solar penetration doubles? What if industrial load declines as manufacturing relocates? These are not day-ahead forecast inputs; they are Integrated Resource Plan inputs that require a different modeling framework.

The connection between the scenario model and the day-ahead forecasting pipeline is the calibration of growth assumptions. The scenario model's base case should use the same growth parameters as the day-ahead model's long-term trend features. If the day-ahead model is trained with a 2 percent annual load growth assumption embedded in its trend features, and the IRP scenario uses a 3 percent growth assumption, the two models will produce divergent 5-year outlooks even when they agree on the current-year baseline. This inconsistency is not immediately visible, but it surfaces when the IRP scenario's projected peak load for year three is 500 MW higher than the extrapolation of the day-ahead model's recent accuracy trend would suggest.

In the unified pipeline, the scenario model uses the day-ahead pipeline's historical calibration data (the actual versus forecast residuals, the load regime classifications, and the DER offset history) to anchor its growth assumptions to observed load behavior rather than to analyst judgment alone. When the data-center-driven load growth in the day-ahead feedback log is running 40 percent above the prior IRP growth assumption, that signal should update the scenario model's high-growth trajectory before the next IRP filing, not after.

Building One Defensible Pipeline

A defensible combined pipeline has four properties: shared data sources, consistent assumptions, propagated uncertainty, and a single sign-off record that covers all three model outputs.

Shared data sources mean that the gross load model, DER output model, and scenario model all draw from the same versioned data objects. The weather file, the DER registry, the SCADA historical data, and the economic indicator files are each stored once and referenced by all models in a given run. A change to any source data is applied to all models in the same pipeline run, not in a piecemeal fashion where different models may be operating on different vintages of the same underlying data.

Consistent assumptions mean that parameters shared across models are explicitly governed. The annual load growth assumption, the DER penetration rate, the behind-the-meter storage dispatch behavior parameters, and the weather normalization method are all documented in a shared parameter registry. When an analyst wants to change the DER penetration assumption for a scenario run, they change it in the parameter registry, and the change propagates to all models that depend on it.

Propagated uncertainty means that the confidence band on the net-load forecast reflects the combined uncertainty of the gross load forecast and the DER output forecast, including the correlation between them (because both are driven by weather). The correct propagation is not a simple sum of the two uncertainty bands; it is a joint uncertainty calculation that accounts for the positive correlation of weather-driven errors.

Single sign-off means that the forecaster or planner reviewing the combined output reviews all three model outputs together, not sequentially in separate workflows. The sign-off record states which versions of the gross load model, DER model, weather model, and scenario parameter set were used, and the reviewer's attestation covers the combined output, not just the individual components.

Worked Example: The Duck Curve and the Data Center

A coastal utility serves a service territory with high rooftop solar penetration (approximately 18 percent of residential customers have behind-the-meter solar) and a growing data-center corridor on the transmission-level eastern edge of the service territory. The utility is preparing for a summer peak planning season and needs a defensible net-load forecast to use in its resource adequacy filing.

The gross load model is forecasting a warm-weather Tuesday afternoon peak of 8,400 MW at 4 p.m. The DER solar output model is forecasting 1,200 MW of behind-the-meter solar generation at peak irradiance (noon) declining to 300 MW by 4 p.m. as the sun angle drops. Three data centers in the eastern corridor are scheduled to draw a combined 480 MW in the evening hours starting at 6 p.m.

Run as separate models with separate weather inputs, the gross load model uses an NWP weather forecast showing 92 degrees and 60 percent cloud cover at 4 p.m. The DER model uses a different solar irradiance file that shows 40 percent cloud cover at the same time. The inconsistency produces a DER solar output estimate that is 80 MW higher than it should be given the shared 92-degree, 60-percent-cloud-cover conditions. The net load is understated by 80 MW.

In the unified pipeline, both models use the same weather file. The 60 percent cloud cover assumption produces a consistent DER solar estimate and a consistent gross load estimate. The net load at 4 p.m. is 8,400 MW minus 300 MW of DER output equals 8,100 MW, with a 10th to 90th percentile confidence band of 7,850 to 8,350 MW driven by the weather forecast spread on cloud cover and temperature. The data-center ramp starting at 6 p.m. is flagged by the step-load guardrail, adding 480 MW to the 6 p.m. to 10 p.m. intervals with a widened uncertainty band reflecting commissioning timing uncertainty.

The forecaster reviews both the afternoon peak (8,100 MW, within the normal warm-weather range) and the evening ramp (8,580 MW at 8 p.m., a level the grid has not previously needed to serve on a Tuesday). The resource adequacy filing uses the evening ramp as the peak planning scenario, not the afternoon peak, which is the correct planning decision when data-center load shifts the daily peak from mid-afternoon to early evening.

Scenario Construction for Planning Decisions

The scenario model must produce a range of outcomes, not a single point. The three standard scenarios for resource planning are a base case (consistent with current growth trends and policy assumptions), a high case (data-center growth accelerates, behind-the-meter DER growth slows, climate extremes intensify), and a low case (data-center growth moderates, behind-the-meter DER growth accelerates, load efficiency improves faster than projected). Each scenario uses a different parameter set drawn from the shared parameter registry, and each runs through the same gross load and DER output models to produce a scenario-specific net-load trajectory.

The scenarios are not arbitrary. Each parameter choice in the scenario model should be anchored to a specific assumption that can be stated and defended: "the high-growth DER scenario uses a 12 percent annual rooftop solar installation rate, consistent with the prior three years of building permit data in this service territory." A scenario that uses unanchored analyst assumptions is not defensible in an IRP proceeding; a scenario that explicitly links its parameters to observed data has a much stronger evidentiary foundation.

For data-center-dominated load zones, the scenario structure may need to include explicit uncertainty about whether announced projects will be built on their announced timelines. Industry data suggest that significant fractions of announced hyperscale data-center projects are delayed by 12 to 24 months or canceled. The scenario model should have a "project realization rate" parameter that allows the planner to stress-test what happens if 30 percent of announced capacity does not materialize within the planning horizon.

Common Failures in Combined Pipeline Design

The most common failure in combining net-load, weather, and scenario models is not a technical modeling failure. It is a governance failure: the assumption that the models are already consistent without explicitly verifying it.

Assumption drift: A parameter is changed in one model but not in the others. Over months of independent model updates, the gross load model is running with a 2 percent growth assumption and the scenario model is running with a 3 percent growth assumption. Nobody updated the scenario model when the load model was recalibrated after the data-center ramp was observed. The pipeline produces internally inconsistent outputs that appear consistent because nobody is checking the cross-model assumptions.

Weather inconsistency: Two teams subscribe to different weather forecast vendors. The load team uses Provider A; the solar team uses Provider B. On most days the forecasts are close enough that the inconsistency is invisible. On a day when the two providers diverge significantly (a common event around complex weather systems), the net-load forecast combines load and solar estimates from different realities. The signed forecast cannot be audited for consistency because the weather inputs are not shared.

DER registry staleness: The net-load model is accurate when the DER registry is current. In fast-growing territories, the registry is a snapshot of a moving target. If the pipeline does not have a registry-staleness alert with a defined action threshold, the net-load model progressively overstates the load the grid must serve as new behind-the-meter solar goes unregistered. The result is systematic over-procurement of grid resources relative to what the actual net load requires.

Scenario-base inconsistency: The scenario model's base case differs from the day-ahead model's base trajectory because they use different load growth assumptions. A planner who looks at the base-case scenario in the IRP and compares it to the day-ahead model's recent output finds them diverging, but does not know which to trust. Without explicit linkage between the two, the IRP may be built on assumptions that the day-ahead model's actual performance has already invalidated.

Key Takeaways

• Net-load, weather, and scenario forecasting must be unified in a single pipeline with shared data sources and consistent assumptions. Separate workflows with separate teams and separate data sources produce internally inconsistent outputs that compound errors in planning decisions.
• Weather is the shared driver of both gross load and DER solar output. Both models must use the same weather file from the same source and the same model run; otherwise the net-load calculation combines forecasts from inconsistent weather assumptions.
• Weather uncertainty is a correlated source of error in both the gross load and DER output forecasts. The net-load confidence band must reflect this correlation rather than treating the two uncertainty bands as independent.
• The scenario model's base case must be explicitly linked to the day-ahead model's current growth assumptions. When observed data-center-driven load growth diverges from the prior IRP growth assumption, the scenario model should be updated before the next planning filing.
• The DER registry is the weakest link in the net-load pipeline. Fast-growing service territories need registry update frequencies and staleness alerts that match the pace of DER installation, not annual registry sweeps.
• A defensible combined forecast requires a single sign-off record that covers all model versions, all shared parameter set versions, and all reconciled outputs. The reviewer attests to the combined output, not just the individual model outputs.
• Scenario parameters for data-center-heavy load zones should include an explicit project realization rate, allowing the planner to stress-test what happens when announced data-center projects are delayed or canceled relative to their announced timelines.