A forecasting system has at least two jobs: produce useful estimates and continue behaving intelligibly when its data or environment changes. Model selection addresses part of the first job. The second depends on fairly ordinary engineering.
The title is not a ranking of forecasting models in 2026. It is an argument for the durable parts of a production workflow: explicit baselines, reproducible evaluation, predictable delivery, and an owner for exceptions. A new architecture still has to earn its place within that workflow.
Begin with a small, inspectable comparison
Use a baseline that reflects the series: a last-observation forecast, a seasonal-naive method, or an established planning rule. Add candidates when their assumptions fit the task and the available data. The relevant question is whether a candidate improves the decision at a reasonable total cost.
Score each candidate at the same forecast origins and horizons. Keep preprocessing and feature availability consistent. A model trained with more recent data is not a clean comparison with a baseline deprived of that information.
Write the temporal contract
Specify the observation frequency, timezone, aggregation rule, and treatment of missing periods. A missing record is not always a zero. A delayed update is not always a demand collapse. Revision policies also matter when historical figures change after publication.
For an illustrative weekly demand service, the contract might say that each region is reported in the same business timezone and that a forecast is withheld if the latest aggregation has not completed. The exact policy depends on the workflow; the important part is making it explicit.
Evaluate the uncertainty you publish
Prediction intervals express a range for a future observation under modeling assumptions. They are not a promise that the future will resemble the past. Check empirical coverage on held-out forecast origins, by horizon and relevant segment, and inspect interval width alongside coverage.
If the intervals become too wide to guide the decision, that is useful product information. It may call for a shorter horizon, a different decision process, or manual review rather than a more confident-looking chart.
Design for late data and broken jobs
Choose an explicit fallback: a last valid forecast labeled with its issue date, a simple baseline, or an unavailable state. Avoid quietly substituting outputs whose meaning differs from the normal prediction. Consumers need to know when the operating mode changes.
Keep the data snapshot, feature definitions, model version, and forecast cutoff together. That makes an unexpected output reproducible. A model artifact without the data and transformation context is often insufficient to explain a historical decision.
Monitor more than the error
Track freshness, completeness, forecast delivery, and downstream acceptance. Forecast error may arrive only after the target period ends, while an ingestion failure needs attention immediately. A shift in the input distribution is a diagnostic signal, not proof that the forecast has become inaccurate.
Write an action for each alert. If no one knows whether to pause publishing, switch to a baseline, or inspect a feed, the alert is merely a notification. Retraining should follow evidence and validation rather than fire automatically whenever a distribution changes.
The strongest production stack is not necessarily the smallest or the newest. It is the one whose additional complexity buys a measurable improvement and whose failures have a practiced response. Continue with monitoring after launch and forecasting around operational decisions.
Foundation models still enter the same comparison
A pretrained forecasting model can reduce task-specific training work, but still needs a clean cutoff, appropriate covariates, horizon-specific evaluation, and a deployment licence. Freeze the exact checkpoint and preprocessing when comparing it with seasonal-naive or local supervised baselines. A zero-shot claim concerns training for the target task; it does not mean the model has no prior training or that the target corpus is guaranteed absent from pretraining. Check model lineage and benchmark overlap where that matters.