Exogenous Covariates and Known-Future Inputs

A demand model that has the promotion calendar is doing a different job from one that does not. The promotion calendar for next month is already decided, sitting in a planning system, and using it is not cheating. The competitor's price next month is also causally relevant and is not known, and using its future values is a look-ahead bug that will make your backtest beautiful and your production forecast useless. The distinction between those two cases is the single most consequential piece of plumbing in an applied forecasting system.

Three kinds of input

The taxonomy that most modern tooling follows comes from the Temporal Fusion Transformer (Lim, Arık, Loeff & Pfister, 2021, IJF 37(4), 1748-1764):

Static covariates do not vary with time: store region, product category, device model, customer tier. They are the main mechanism by which a global model tells series apart without memorising an identifier, and they are what makes a forecast possible at all for a series with no history.

Known-future (or a priori known) covariates have values defined for the whole forecast horizon at prediction time: calendar features, public holidays, scheduled promotions, contracted prices, planned maintenance windows, the day-of-week index itself. These can be fed to the decoder for every future step.

Past-observed covariates are measured alongside the target and stop at the forecast origin: web traffic, sensor readings, realised competitor prices, weather actuals. They can inform the encoder but cannot be read forward without a forecast of their own.

Weather is the instructive case, because it sits in both buckets depending on the horizon. A weather forecast is a known-future covariate, with uncertainty that grows with lead time; weather actuals are past-observed. Systems that quietly train on actuals and serve on forecasts inherit a train-serve skew that shows up as an unexplained accuracy drop in production and nowhere in the offline metrics.

What covariates are actually worth

The honest answer is that it depends on how much of the variance is driven by things outside the series' own history, and that varies enormously by domain. Retail demand under promotions is heavily covariate-driven; aggregate electricity load is dominated by calendar and temperature; many web metrics are almost purely autoregressive and gain nothing.

The pretrained-model literature made this measurable. Purely univariate time-series foundation models had no covariate channel at all, and the first generation of them was evaluated on univariate benchmarks where that was invisible. When benchmarks began including covariate-informed tasks, covariate handling became the axis on which models separated: Chronos-2 was built around in-context learning over related series and covariates and reported state-of-the-art results among public pretrained models on fev-bench, which includes covariate-informed tasks (Ansari, Shchur et al., 2025, Chronos-2: From Univariate to Universal Forecasting, arXiv:2510.15821), and TabPFN-TS reached competitive covariate-informed accuracy with 11M parameters by treating forecasting as tabular regression over temporal features, where covariates are simply more columns (Hoo, Müller, Salinas & Hutter, 2025, arXiv:2501.02945).

That is a useful corrective. A tabular model with the promotion calendar frequently beats a much larger sequence model without it, because the calendar contains information the history does not.

Encoding them without leaking

Three rules cover most of the failure surface.

1. Build every feature from a timestamped snapshot. The value of a covariate at time \(t\) must be the value that was known at \(t\), not the value later corrected. Restated sales figures, backfilled sensor data and revised economic indicators all violate this by default.
2. Keep the future window and the past window physically separate in code. Known-future covariates fill a matrix of shape \((H, d_{\text{known}})\); past-observed ones fill \((L, d_{\text{past}})\). A single tensor with a mask is where bugs live.
3. Evaluate with the covariate quality you will have. If promotions are planned four weeks ahead and confirmed two weeks ahead, backtest with the four-week-ahead plan for horizons beyond two weeks, not the realised promotion.

When it breaks

The covariate needs its own forecast. Past-observed covariates are only usable forward if you forecast them, and that forecast's error enters yours. Sometimes the right answer is to drop the covariate rather than stack two error distributions.

Rare-level categorical covariates overfit. A promotion type that appears in 40 of 3 million rows will be memorised by a flexible model and will produce an extreme prediction the next time it appears. Frequency thresholds and fallback levels are not optional.

Covariates can be colliders. Conditioning on a variable that is caused by both the target and something else can make a model worse in exactly the situations you care about. Realised inventory is a common example: it is depleted by demand, so including it as a feature teaches the model to read demand off stock levels, which breaks precisely when the supply chain changes.

Causal direction is not tested by accuracy. A covariate can improve backtest accuracy and still be useless for the decision, because the decision changes the covariate. If a model forecasts demand from price and the plan is to use it to set price, the model is not answering the question being asked.