The forecast was wrong because the routing was
In a multi-series forecasting project, the question is not which model is best but what state each series is in right now. Model selection can be conditional on current observed behaviour.
TL;DR: In a multi-series forecasting project, the question is not which model is best but what state each series is in right now. A lightweight routing layer measures recent trajectory from history available at the forecast origin, classifies a current regime, and routes each series to candidate strategies suited to that behaviour. Routing features must obey the same point-in-time rules as forecast features, and the router itself must be evaluated with rolling backtests. Model selection can be conditional: some forecast errors begin before the model, with the wrong dispatch decision.
Visual Summary
The Problem
In a multi-series forecasting project, I spent less time asking "which model is best?" and more time asking "what state is this series in right now?" That change reshaped the whole workflow.
Not every series behaves the same way at the same moment. Some are accelerating. Some are flattening or decelerating. Some have almost no usable signal. Some are noisy enough that a more complex model adds instability rather than value. Sending every series through one forecasting strategy hides those differences.
The issue is not always that the model is weak. Sometimes the series was sent to the wrong strategy before the forecast was even made.
The Approach
I added a lightweight routing layer in front of the forecasting models, built around four steps:
1. Measure recent trajectory
Use historical windows available at the forecast origin to describe how the series has been moving — a longer baseline window against a shorter, recent one.
2. Classify the current regime
Turn that trajectory into a current regime: accelerating, flattening or decelerating, near-zero or low-signal, or ambiguous. These describe present observed behaviour, not permanent labels.
3. Route to candidate strategies
Send each regime to a set of candidate strategies suited to it: momentum-aware or robust ensembles for accelerating series; conservative or damped-trend candidates for decelerating ones; simple zero-aware baselines for near-zero or intermittent series; and rolling-backtest evidence for ambiguous ones.
4. Evaluate the whole system
Do not backtest models only — backtest the routing rule too. The router is part of the forecasting system and must be evaluated with rolling origins and end-to-end outcomes.
Routing features must obey the same point-in-time rules as forecast features. Classifying today's regime must never use future observations, or the router learns a lift that cannot exist in production.
Outcome
In this project, improving the routing logic created more lift than another round of model tuning. The router narrows the decision space; backtesting still chooses the strategy, and no strategy is treated as universally correct.
That result will not generalise automatically to every forecasting problem. But the question does.
Key Takeaway
Design insight: In a multi-series forecasting project, the question is not which model is best but what state each series is in right now. A lightweight routing layer measures recent trajectory from history available at the forecast origin, classifies a current regime, and routes each series to candidate strategies suited to that behaviour. Routing features must obey the same point-in-time rules as forecast features, and the router itself must be evaluated with rolling backtests. Model selection can be conditional: some forecast errors begin before the model, with the wrong dispatch decision.
Related
The Hardest Forecasting Decision Is Which Model to Use →Route Structurally Inactive Series Before Forecasting →Decomposition: A Forecasting Strategy, Not a Preprocessing Step →Aggregate, Forecast, Disaggregate: Forecast at the Level of the Signal →Conformal Prediction: Calibrated Forecast Intervals →Zero-Shot Forecasting Changes the Baseline →Purged Cross-Validation Is Not for Every Time Series →Seed Sensitivity Is Part of Model Selection →Label Validity Is Time-Based →MLforecast Made Me Rewrite My Forecasting Pipeline →
FAQ
What is the key takeaway from "Regime-Aware Forecasting: Route Each Series by Its State"?
In a multi-series forecasting project, the question is not which model is best but what state each series is in right now. A lightweight routing layer measures recent trajectory from history available at the forecast origin, classifies a current regime, and routes each series to candidate strategies suited to that behaviour. Routing features must obey the same point-in-time rules as forecast features, and the router itself must be evaluated with rolling backtests. Model selection can be conditional: some forecast errors begin before the model, with the wrong dispatch decision.
Who wrote this and what is it about?
This was written by Mahmoud Trigui, Senior Data Scientist. Regime-aware forecasting routing classifies each series by its current state, then routes it to candidate strategies instead of one model for all.