Exogenous and Known-Future Covariates

Forecasting a stock's trading volume for the next five days, you know some things about those five days already: which ones are Federal Reserve meeting days, which one is quadruple-witching expiry, which one falls right after a holiday. You do not yet know what the price will do on those days. Lumping every input variable together as "a feature" hides an important distinction: some future inputs are already nailed down, and a forecasting model that's designed to exploit that difference will generally beat one that treats every input as equally uncertain.

Three kinds of extra information

Beyond the series' own past values, a forecasting model typically has access to three categories of additional variable, called covariates:

• Static covariates — facts that don't change over time for a given series, like an asset's sector or exchange listing.
• Past-only (observed) covariates — series only known up to "now," like realized trading volume so far today, which you have historical values for but cannot know in advance for future days.
• Known-future covariates — variables whose future values are already determined today, like the calendar (day of week, holiday flags), a scheduled corporate action, or a pre-announced Fed meeting date.

The key modeling decision is: known-future covariates can be fed into the model for the entire forecast horizon at once, because you're not guessing them — you're looking them up. Past-only covariates can only be fed in as history up to today; for future time steps, the model has to do without them (or forecast them separately, which introduces its own error).

Why the distinction matters for architecture

A model like a temporal fusion transformer explicitly separates these three streams: static features enter once, observed-past features enter only through the encoder (the history window), and known-future features enter through both the encoder and the decoder (the forecast window), because they're valid inputs there too. A model that doesn't make this distinction — say, one that simply concatenates every feature into a single vector per day and only ever conditions on history — throws away the free information contained in known future dates and forces the model to relearn calendar effects from scratch rather than being told directly "next Tuesday is options expiry."

Worked example: forecasting five days of trading volume

Suppose you're forecasting daily share volume for a stock over the next five trading days. Your known-future covariates for those five days include: day-of-week (Mon–Fri), a flag for the day being month-end rebalance day (yes for day 5), and a flag for scheduled earnings (no for all five). Your past-only covariate is realized volume itself — you have it for the last 60 days but obviously not for the next five, which is exactly what you're forecasting. A well-built model feeds the day-of-week and rebalance flags for all five future days into the decoder directly. If day 5 (month-end) historically sees 40% higher volume, the model can apply that learned adjustment to day 5's forecast specifically, using information it was never uncertain about, rather than treating day 5 forecast-wise the same as day 1.

Adjust the curve above and notice how a known future input (like where you are on the x-axis) directly determines the output shape — a known-future covariate plays the same deterministic role inside a forecasting decoder, rather than being another uncertain quantity to predict.

What this means in practice

Getting this classification wrong in either direction costs accuracy: treating a known-future variable as unknown throws away free predictive power, while accidentally treating a past-only variable as if it were known for the future is a leakage bug — it means the training pipeline saw information (like actual future volume) that a live model would never have on forecast day.