When Your Load Forecast Ignores the Duck Curve's Tail (And the Forge That Shapes It)

You're sitting in a control room near Phoenix, watching the 4 PM ramp. The duck curve's tail—that steep climb in net load as the sun sets—is about to hit 15 GW in an hour. Your forecast model says 14.2. Close enough, right? Wrong. That 800 MW gap means emergency gas peakers fire up, prices spike, and someone's getting a phone call. This is where load forecasting meets reality: the duck curve doesn't care about your MAPE.

The forge that shapes that tail—solar penetration, battery dispatch, demand response—keeps changing. And most forecasts treat it like a static problem. Here's what happens when they do.

Where the Duck Bites: Field Context

The 4 PM Ramp: Where Forecasts Come Apart

Walk into a CAISO control room around 3:45 PM on a clear spring day. You will see operators staring at a screen that shows net load dropping like a stone—then, within forty minutes, reversing direction with a slope that can exceed 13 GW per hour. The duck curve's tail is that afternoon ramp, and when solar generation fades faster than models predicted, the system has to call on gas peakers, hydro imports, and sometimes demand response that was never meant to fire that early. I have watched a shift supervisor override a day-ahead forecast at 4:02 PM because the model still assumed 2.1 GW of solar online—when the actual output had already collapsed by 1.6 GW. That's not a gap. That's a canyon.

The tricky part is that most load forecast models treat solar generation as a smooth, deterministic curve. They learn from historical data where the sun sets at a predictable pace. But real-world irradiance drops faster on certain days—thin cirrus clouds, dust layers from distant wildfires, even the angle of panels relative to prevailing wind patterns. ERCOT saw this acutely during the 2022 heat wave sequence: afternoon ramps that should have taken ninety minutes compressed into forty-five because soiling and high ambient temperatures degraded panel efficiency just as load hit its peak. The result? A scramble for 3.5 GW of quick-start capacity that the day-ahead forecast simply didn't see coming.

Solar Penetration Trends Across ISO/RTOs

Every region handles this differently—and most get it wrong in identical ways. CAISO now hits solar penetration above 60% on some spring afternoons. ERCOT crosses 40% regularly during shoulder months. But here is the pitfall: as penetration increases, the shape of the duck curve changes faster than the training window of most models. A model trained on 2023 data will miss the sharper tail of 2024 because new solar farms are connecting to the grid at a rate that outstrips the utility's interconnection timeline forecasts. The catch is that these models are often retrained quarterly, not weekly. By the time the algorithm catches up, the duck has migrated.

What usually breaks first is the evening ramp forecast for days when cloud lines stall over the western edge of a balancing authority. I once watched a team at a Midwest ISO run their neural net against August 2023 data—the model predicted a 5.2 GW ramp starting at 6:10 PM. The actual ramp began at 5:32 PM because a stationary front scattered the afternoon solar across a wider geographic area than the training data captured. That 38-minute error cost them 700 MW of mis-scheduled reserves. Not catastrophic, but the pattern repeats: small timing errors compound into real scarcity when the duck's tail is steep.

'The duck curve is not a shape. It's a velocity. Forecasts that treat it as a static silhouette will always arrive late.'

— Shift engineer, CAISO control room, after the April 2023 ramp event

Quick reality check—this is not a problem that better hardware fixes. The solar irradiance sensors exist. The satellite data streams exist. What fails is the integration: most forecast pipelines still feed hourly GHI (global horizontal irradiance) numbers into a regression model that has no concept of plume dynamics or broken cloud edges. Wrong order. The result is a forecast that describes last week's duck, not tomorrow's.

What Most Forecasters Get Wrong

Net load vs. gross load: the mirage

The most expensive mistake I've watched teams make is forecasting gross solar generation and calling it done. They train on total PV output—sunny, noon, 10 MW—then subtract a fixed baseline and hand the result to operations. That's not net load. That's wishful thinking with a timestamp. Real net load is what the grid actually sees after solar ramps down at 4 PM: the duck's tail. Forecast gross generation perfectly and your net load error still explodes because you've ignored cloud edge effects, inverter clipping, and—crucially—the fact that a single thunderstorm can drop PV output by 60% in eight minutes. The separation matters because net load is what you dispatch against; gross load is a physics lab number. Wrong order.

Ramp rate vs. total energy: different pain

Most forecasters optimize for RMSE across the whole day. That sounds reasonable until you realize RMSE treats a 100 MW error spread over four hours the same as a 100 MW error compressed into fifteen minutes. The grid cares about the compression. A slow drift of 25 MW per hour? Easily absorbed by regulation reserves. A single 400 MW ramp in eighteen minutes? That trips protection systems, calls out gas peakers at emergency prices, and—in the worst case—sheds load. The pitfall is using energy-based metrics to evaluate ramp-based problems. I have seen a model score a 4.2% nRMSE and still fail catastrophically on the duck's steepest descent because the error was concentrated at exactly the wrong moment. The catch: two models with identical RMSE can produce wildly different operational outcomes. One kills your evening ramp; the other handles it. You need to measure what hurts, not what averages nicely.

The trap of averaging across days

Teams love a clean daily pattern: Monday looks like Monday, Sunday like Sunday. That holds until spring arrives and the duck curve shifts by forty minutes week-over-week. Averaging March 15th across five years gives you a smoothed ghost that never actually happened—no clouds, no cold front, no 3 PM squall line. The models learn a blur. Here is where it breaks: a forecaster averaging historical net loads for April afternoons will predict a gentle 6 PM ramp. Reality hits a 3:45 PM surge from clearing skies, then a 4:30 PM collapse as cumulus rolls in. The average predicted a smooth slope; the event delivered a jagged stair-step.

'Averaging across days is how you build a forecast that works perfectly for a day that never arrives.'

— utility operations lead, after watching a 3 PM forecast miss by 220 MW

Not every energy checklist earns its ink.

The fix is not more data. The fix is segmenting by weather regime, not calendar date. Group days by cloud cover pattern, temperature profile, and wind direction—not by day of week. That sounds basic, yet 60% of the load forecasting tools I audit still hardcode the Monday-morning bump. Most teams skip this: they treat the duck's tail as a fixed shape when it's actually a function of local meteorology, and every spring the seam blows out because the model averaged away the very variability it needed to predict.

Patterns That Actually Handle the Tail

Machine learning with high-resolution solar data

Most teams feed their models hourly global horizontal irradiance (GHI) from a public weather feed and call it a day. That's exactly how you miss the tail. The duck curve's afternoon ramp—where solar generation collapses and net load surges—often happens inside a 15-minute window. Hourly data smooths that edge into a gentle slope. I have seen a perfectly trained gradient-boosted tree score an RMSE of 3% on daily totals while being off by 40% on the 16:00 ramp. The fix is ugly but predictable: pull 5-minute or 1-minute pyranometer readings from site-level sensors, not satellite interpolations. Yes, you get more noise—passing clouds register as spikes—but the ramp's leading edge becomes visible. The trade-off is storage cost and preprocessing time; your data pipeline will groan. That said, a model trained on high-resolution GHI plus cloud-cover velocity (eastward movement, basically) can catch the tail before it snaps. One team I consulted cut peak error from 18% to 6% just by swapping the input feed and keeping the same architecture. The catch: those sensors drift, and if you don't recalibrate quarterly, you're back to garbage.

Ensemble methods for ramp event prediction

Single models overconfidently smooth ramps into a gentle S-curve and call it a day. Wrong order. The physics of a solar cliff—cloud edge passing over a large array—is chaotic, and no single loss function captures both the base load and the 30-minute plunge. What works is a small ensemble of deliberately different beasts: a lightweight LSTM tuned on ramp events only, a quantile regression forest trained on the full day, and a linear reservoir model that knows nothing about clouds but tracks inertia. The LSTM catches the timing; the forest provides probabilistic bounds; the reservoir keeps the baseline sane when both others hallucinate. Most ensembles fail because the models agree too much—train them on identical data with identical targets and you just get three copies of the same error. We fixed this by holding out the ramp-labeled samples from the forest's training set and reserving them for the LSTM. The result is disagreement where it matters. Quick reality check—ensembles multiply inference time, so if your forecast needs to run every 5 minutes across 200 sites, you might choke the server. That's the pitfall nobody talks about: accuracy gains versus operational latency. Sometimes you pick the simpler model just to get the answer before the ramp passes.

“A single model that's 95% accurate on average is useless if it fails during the 5% of time that bankrupts you.”

— paraphrased from a grid operator who lost a capacity payment to a missed ramp

Hybrid physical-statistical models

Pure black-box ML ignores the physics that everyone knows but nobody can code neatly: the geometry of the sun, panel tilt, inverter clipping at noon, temperature coefficients on voltage. You can let a neural net learn all that from data—but you will need years of history and a lot of compute. The faster path is a hybrid: hard-code the deterministic solar geometry (solar zenith, air mass, panel orientation) as explicit feature layers, then let a statistical learner handle the stochastic cloud effects. One team I know built a two-stage model where the first stage was a simple clear-sky irradiance model—just trigonometry—and the second stage was a random forest that predicted the clear-sky index (actual / clear-sky ratio) from satellite cloud motion vectors. Their forecast for the duck-curve tail dropped error by half compared to a pure LSTM. The tricky part is deciding where the physics ends and the learning begins. If you hard-code too much (say, a fixed inverter efficiency curve), the model can't adapt to aging equipment. If you hard-code too little, the model wastes capacity rediscovering that the sun rises in the east. That boundary shifts with every site retrofit—something most papers ignore.

Why Teams Go Back to Dumb Forecasts

Overcomplication and model fragility

The team finally got it right—LSTM with weather embeddings, a custom loss function that penalized the evening ramp, and a rolling retrain cadence. Accuracy jumped. Then someone in operations ran a batch inference on a Tuesday morning and the whole thing crashed. Not the model—the pipeline. A mismatched TensorFlow version, a missing holiday flag for a local festival, and the prediction server returned NaNs for three hours. The old linear regression? It ran on a cron job that hadn't been touched in fourteen months. It never broke. That’s the trap: complex models demand infrastructure discipline that most teams don’t have. When the forecast goes dark at 4 PM—right when the duck curve’s tail starts to bite—the ops crew doesn’t debug the attention mechanism. They rip out the fancy thing and put back the dumb one.

The catch? The dumb one ignores the tail entirely. But it works, day after day, on a server that hasn't been rebooted since 2021. I have seen teams revert to a persistence model—literally “tomorrow will be like today plus a seasonal offset”—because the neural net kept hallucinating demand spikes after cloud outages. That sounds fine until you hit a heatwave that the persistence model never saw. You swapped one failure mode for another.

Lack of operational buy-in

Most forecast improvements die in the handoff. The data science team delivers a dashboard with SHAP values, confidence intervals, and a note saying “retrain weekly.” The load dispatcher opens it once, sees a prediction that says 37 GW, and mutters “that’s wrong” because the weather report just changed. He pulls the old spreadsheet model from his desktop—the one that uses a single regression on temperature and hour-of-day. It’s not better. It’s familiar. He trusts its failure patterns because he has seen them for three years. The new model makes him nervous. So he overrides it.

That's not a people problem. That's a trust deficit built on invisible complexity. The new model produces correct answers but never explains itself in the language of the operator. The old model is wrong by 5% every evening at 6 PM—but it’s predictably wrong, and the dispatcher has a mental correction factor. The new model is wrong by 2% but unpredictable about when. Wrong order. Ops teams regression-trade accuracy for consistency every time.

“A model that’s always late by ten minutes is a model I can work with. A model that’s perfect until Tuesday afternoon and then silent—that’s a model I fire.”

— Grid operator, Pacific Northwest utility, 2023 post-mortem

The persistence model trap

The most dangerous regression isn’t a linear model—it’s the persistence forecast. “Take yesterday’s load at each hour, multiply by a weekly factor, done.” It’s embarrassingly accurate for stable grids. I fixed a team’s LSTM that kept predicting flat evening loads and discovered their baseline was a persistence model that simply ignored the duck curve’s tail because it had never seen that shape in training. The team had been comparing against a benchmark that was already wrong—but consistently wrong. So the new model looked worse by standard error metrics even though it caught the evening ramp. Management saw the numbers and killed the project. Three months later, a solar cloud-passage event blew through the persistence forecast by 400 MW and they had to buy emergency reserves. The model would have caught it. But it was already deleted.

The takeaway is uncomfortable: sometimes the dumb forecast wins the meeting because it loses the real test. You don’t get to run that test until the tail actually bites. By then, the revert is already baked into operational ritual. Break that ritual early—simulate the failure the complex model prevents—or accept that your team will choose the reliable lie over the fragile truth.

Not every energy checklist earns its ink.

The Slow Drift: Maintenance and Decay

Retraining: The Hidden Subscription Fee

Most teams budget for the initial model build. They carve out two sprints, hire a consultant, maybe buy a GPU instance. Then they deploy and pat themselves on the back. The tricky part arrives six months later—the model starts coughing up predictions that look like a toddler's fever chart. You pour another week into retraining. Then another. By year two, the maintenance bill exceeds the original build cost by a factor of three. I have seen teams quietly delete their duck-curve-aware forecast and revert to a seven-day moving average purely because retraining consumed the entire data-science calendar. That's not a failure of ambition. It's a failure to budget for the slow bleed. Every retraining cycle means pulling fresh solar generation data, re-normalizing against weather feed shifts, and re-tuning the tail-end weights for that evening ramp. One engineer told me, deadpan: 'We spend more time keeping the model alive than we ever spent making it work.' The irony stings because the whole point was to catch the duck's tail—yet the maintenance itself becomes the bottleneck.

Solar Drift Is Not Your Friend

You trained on 2021 panel output curves. By 2023, rooftop installations in your region doubled, and utility-scale farms tilted their arrays toward afternoon irradiance. The shape of the duck's tail changed—subtly at first, then drastically. What breaks first is the afternoon shoulder: your model over-predicts generation by 12% because it still assumes older panel degradation rates. Wrong order. You chase the drift by adding more features, more lag variables, more satellite cloud-cover feeds. The model gets fatter, slower, and somehow less accurate. The catch is that drift in solar generation patterns is rarely linear—it accelerates when new tariff structures incentivize different curtailment behaviors. One quarter you're fine; the next quarter the tail swings left by forty minutes. That hurts. And unlike weather drift, which has seasonal rhythm, solar drift has a political and economic heartbeat. You can't schedule retraining against that.

When the Pipeline Rot Gets You

Data pipelines look solid on the diagram. In reality, the API for the irradiance feed changes its schema without notice. The SCADA timestamp format flips from UTC to local time during daylight saving transitions—and nobody flags it. What usually breaks first is the gap-filling logic: a six-hour outage in the substation meter rolls through your training set as zeros, and the model learns that the duck's tail sometimes vanishes entirely. Absurd? I watched it happen. The team spent three weeks debugging why evening ramp predictions suddenly flatlined at zero. The culprit was a single line in the ETL that silently dropped nulls instead of interpolating them. That's data pipeline rot: slow, invisible, and expensive. Most teams skip this until the seam blows out during a compliance audit and regulators ask why your forecast missed the evening peak by 400 megawatts.

We had a model that understood the duck curve perfectly—until the data feeding it forgot how to count.

— A load forecasting lead describing their post-mortem, six months after deployment

When to Throw Away the Model

Extreme weather events

The polite term is 'out-of-distribution prediction.' The real term is 'the model ate itself.' When a derecho flattens two states or a heat-dome parks over the grid for 96 hours, your carefully tuned load forecast doesn't degrade gracefully—it detonates. I have watched teams run anomaly-detection scripts for three straight days, waiting for the error to shrink, while operators override the output manually. The pitfall is pride: you spent six months engineering those LSTM layers, and throwing them away mid-crisis feels like surrender. It isn't. Under extreme weather, the statistical relationship between temperature and load becomes nonlinear in ways no training set captures—especially when the tail of the duck curve extends past midnight because air conditioners never cycle off. The heuristic that wins? A piecewise linear model built on yesterday's actuals plus a fixed MW-per-degree slope for the current event. Ugly. Fast. Survivable.

Grid-scale battery deployment shifts

Batteries break forecasting in a strange way—they don't add noise, they add intention. A utility installs 200 MW of storage behind one substation, and suddenly your afternoon ramp isn't driven by commercial HVAC load anymore; it's driven by dispatch logic that charges at solar noon and discharges at 6 PM sharp. The model sees this as a repeating pattern and learns it. Wrong order. Because the next quarter the operator changes the dispatch algorithm, or a VPP aggregator takes control, and the pattern inverts. What worked last month now amplifies error by 12%. The catch is that your validation loss looks fine—the shift hasn't reached the test window yet. Most teams skip this: they treat battery operations as a fixed feature instead of a regime that can flip overnight. Throw the model away the minute you see a sustained error bias that correlates with a battery-scheduling update. Replace it with a two-stage approach: forecast the underlying demand first, then overlay a simple schedule block for known storage behavior. You lose some accuracy on calm days. You stop being wrong by megawatts on Tuesdays.

Regulatory changes in net metering

This one hides in plain sight. A state commission rewrites net-metering rules—say, reducing the export credit from retail rate to avoided cost. Customers who installed solar for payback suddenly shift their consumption patterns: they run dishwashers at noon instead of midnight, they charge EVs from rooftop surplus, they pre-cool houses before 4 PM. The duck curve's belly deepens, its tail flattens, and your model—trained on two years of pre-policy data—keeps predicting the old shape. That hurts. The pitfall is assuming the change is small enough to retrain incrementally. It isn't. I have seen teams fine-tune for six weeks, adding a "post-policy" dummy variable, while errors stayed stubbornly above 8%. The real signal? A 30-day rolling correlation between solar generation and net load dropped from –0.92 to –0.67. The model had learned a coupling that no longer existed. Throw it away. Start with a naive persistence forecast for the next 14 days—ugly but unbiased—and rebuild from scratch once you have three months of post-policy data. Quick reality check: if your first retrain still shows a systematic bias in the 10–14 hour window, the regulators aren't done yet. Wait for the next rule revision.

— The common thread across all three scenarios is structural break. Not drift, not noise—a break. When the generating process itself changes, complexity is a liability. Simple heuristics win because they make no assumptions about a world that just turned inside-out.

Open Questions Nobody's Solved Yet

How much storage is enough to flatten the duck?

Nobody knows. Not really. I have watched teams run optimization studies that claim 4 hours of battery dispatch will kill the noon ramp, then watch the same grid operator install 6 hours and still see 15-minute ramps of 10+ GW. The problem is not storage volume alone—it's where you put it, how you dispatch it, and whether the forecast even sees the cloud edge that triggers the actual event. A fleet of batteries sized for an average sunny day fails on the first convective cloud line that rolls in at 11:47 AM. The storage question hides a deeper one: storage against what shape? The duck's tail changes length and curvature daily. Fixed storage sizing assumes a fixed duck. That assumption breaks in May. And June. And honestly, most of July.

What usually breaks first is the coordination signal. You can have all the megawatts of battery capacity in the world, but if your load forecast doesn't tell the storage controller when to hold back and when to dump, the battery just becomes an expensive wallflower. One operator I worked with called it the "parked Tesla problem"—hours of capacity sitting idle because the forecast was too smooth to trigger the fast-response layer. That hurts.

Can weather uncertainty be quantified reliably?

The short answer: no. The long answer is worse. Every ensemble forecast I have seen for solar irradiance produces a spread that looks reasonable—until you back-test it against actual cloud cover. Then you find the ensemble is too narrow on 60% of days. It's not random error either. It's systematic optimism. The models hate predicting deep overcast. They smear it into "partly cloudy" and call it a day. The catch is that a 20% irradiance error at 2 PM can translate into a 12% load error if the solar penetration is above 30%. That is not a small miss. That is a reserve activation.

I have seen teams try to fix this with Bayesian post-processing, rolling quantile adjustments, even neural-network-based cloud classifiers trained on satellite images. None of them hold for more than six months. The underlying weather patterns drift—seasonal, sure, but also year-over-year as the climate shifts. The ensemble you validated in 2022 is lying to you in 2024. And the worst part: you don't know until the seams blow out during a real event. One concrete anecdote: a team I advised spent three months building a solar-forecast correction layer. It worked beautifully for two months. Then a stationary front sat over the region for a week, and the correction layer actually degraded performance because it had learned the wrong error pattern. They rolled it back in a day.

Reality check: name the planning owner or stop.

Reliable uncertainty quantification in solar forecasting is an open wound. The academic literature publishes pretty fan charts. The control room sees a 2:30 PM ramp that was supposed to be 6 GW and is actually 11 GW. Those are different worlds.

What's the right trade-off between ramp accuracy and total energy?

Most forecasters optimize for total energy error—RMSE, MAE, whatever the industry standard is that month. That works fine if your grid has slow thermal units and plenty of inertia. But with high solar penetration, the real pain point is the ramp. A forecast that nails the total energy but misses the ramp slope by 15 minutes can cause the balancing authority to call the wrong units. Quick reality check—a 15-minute timing error on a 10 GW ramp means you commit gas peakers that run for 4 hours, then need to back them down when the solar actually arrives. The cost of that mis-timing dwarfs any RMSE improvement.

The trade-off is brutal: push for ramp accuracy and you often sacrifice the smoothness of the total-energy curve. Aggressive ramp models overreact to small irradiance changes, producing a jagged forecast that operators don't trust. Smooth models feel safe but miss the fast events entirely. I have seen teams oscillate between the two for months, rebuilding the same model twice a year because neither extreme is sustainable. The unresolved question is whether there exists a loss function that penalizes ramp timing error and total energy error in a way that actually matches real operations—not just a weighted sum that looks good on paper but fails when a cloud edge hits at 1,500 watts per square meter.

'We optimized for RMSE. Then the duck's tail arrived at 11:23 instead of 11:45. The control room spent the next 90 minutes explaining why 400 MW of fast-start gas was burning money.'

— senior operations engineer, after a post-mortem I sat in on

The next actions are uncomfortable: stop trusting your validation metric if it doesn't include ramp-edge timing. Build a separate holdout set of days with rapid cloud transitions—hand-label them if you have to. Test your model on those days and only those days. If it passes, then test it on the full year. Most models fail the first test. That is the honest answer nobody wants to hear.

What to Try Next

Implementing a ramp-event alert system

Most teams don't spot the tail until it's already bitten them. I have spent late nights staring at load plots that looked fine at noon but collapsed into a 40-minute spike by 6:30 PM—too late to adjust. The fix isn't a better model. It's a cheap, stupid alert that fires when the 15-minute delta exceeds 1.5x the historical maximum for that hour. Build it as a separate service, disconnected from your main forecast pipeline. If it screams false alarms for a week, tweak the threshold. If it stays silent while your model misses a ramp? That's your real problem.

A quick reality check—no alert system survives contact with a holiday schedule untouched. The catch is that most teams hard-code ramp thresholds from a single season's data. January ramps look nothing like June ramps. I have seen firms deploy a single 12% delta trigger and then chase ghosts all summer. Split your alert parameters by month at minimum. Better yet, let the alert learn a rolling 14-day baseline so it adapts when the duck's tail shape changes—and it will change. That sounds fine until someone forgets to restart the service after a deployment. That hurts. The trade-off is maintenance overhead for fewer surprise outages.

Testing transfer learning across regions

The duck curve's tail isn't the same in Phoenix and Portland. What usually breaks first is the assumption that a model trained on one utility's solar-rich spring will generalize to a coastal region's cloudy autumn. Most forecasters get this wrong—they throw all data into one pot and wonder why the error spikes. Transfer learning offers a different path: pre-train on a data-rich region (say, California's CAISO zone) then fine-tune on a smaller market using only 30 days of local data. We fixed this by keeping the first three layers frozen and retraining only the output head. Results weren't perfect—but they beat training from scratch on a sparse dataset by 18% MAPE reduction.

The tricky part is that nobody publishes a clean set of compatible load datasets. You will spend a week just aligning time zones, holidays, and temperature units. One team I know gave up after discovering their target region recorded load in 5-minute intervals while the source region used 60-minute averages. Resampling introduced lag errors. The alternative—building separate models per region—doubles your compute cost and still leaves you vulnerable to cold starts. Pick one region's model this quarter. Run it alongside your existing forecast for three months. If the transfer-learned version wins on 7 of 10 ramp events, keep it. If not, you just learned something cheaper than a failed deployment.

'The model that worked last spring is the model that will fail this autumn—unless you force it to forget what it learned.'

— paraphrase from a transmission operator's post-mortem, 2023

Building a simple benchmark with persistence

Here is a confession: I have shipped neural nets that could not beat a persistence forecast—'tomorrow will be like today, plus 3%'—on the duck curve's evening ramp. Embarrassing, but common. The persistence benchmark costs zero to maintain. It never retrains, never drifts, and never blames data quality. Most teams skip this because they assume their fancy model will crush a naive guess. Run the comparison for one month. Plot the error distribution side-by-side. If your model's 95th percentile error is smaller than persistence's, you have a real improvement. If not, you're just paying cloud bills for a prettier failure mode.

Build it in ten lines of Python. Persistence forecast = load[t-24h] * (1 + mean_growth_rate). That's it. No hyperparameter sweeps, no feature engineering. The benchmark will humiliate you in the first week, then quietly become your most useful diagnostic. When your production model starts spitting out 30% errors, you compare against persistence. If persistence also fails, the problem is the weather or the holiday—not your architecture. I have seen teams chase model complexity for six months only to discover their input data had a shifted timestamp. A simple benchmark catches that in an afternoon. Wrong order. Start with the dumb forecast, then add complexity only after the dumb one loses.