RESEARCH AND SCIENCE

Introducing Timestral: known-future inputs and leakage

Event source: Mistral introduces Timestral forecasting models ↗

In this analysis
THE RETROSPECTIVE TAKE

A known-future input must be available when the forecast is issued; a final revised table is not automatically historical evidence.

Timestral’s known-future covariates are inputs available at forecast time, not permission to include future outcomes that the forecasting system would not yet know.

Availability is the decisive property

A variable can refer to a future period while already being known: a planned schedule is different from the realized outcome of that schedule. The relevant question is what information existed when the forecast would have been issued, rather than whether a column’s timestamp lies beyond the forecast origin.

The October forecasting event

The Timestral announcement supports past and known-future covariates in probabilistic forecasting. The earlier decoder-only forecasting paper and Chronos paper provide dated research context. They do not validate a dataset that includes information unavailable at the moment being simulated.

The release’s feature should therefore be interpreted through an information boundary. Supplying a future input can be legitimate, but only when its availability matches the historical decision point. A table assembled after all outcomes are known can accidentally erase that distinction.

A demand-planning example

Imagine forecasting demand using a promotion calendar. A promotion planned before the forecast is a candidate known-future input. The final realized sales or a schedule correction made after the forecast belongs to a different information state, even if it is stored beside the original plan in the same database.

Preserve the version of the calendar that was available at issuance. If only the final revised table survives, state the limitation instead of treating it as the original planning input. The model cannot repair an evaluation whose evidence boundary was already violated before inference.

Leakage changes the question

A forecast evaluated with later knowledge answers a different task from a real decision made earlier. An apparently improved score can reflect extra information rather than improved forecasting. Without an availability record, those explanations cannot be separated by looking only at the final predictions.

Keep observation time, effective period and revision history distinct where the source supports them. These fields describe different aspects of a covariate. A future effective date alone does not prove illegitimate leakage, while a plausible variable name does not establish legitimate availability.

The retrospective lesson

The release broadens the ways external information can enter a forecasting model. Its practical value depends on preserving the difference between planned future inputs and subsequently observed facts.

The conclusion is to reconstruct the information available at forecast issuance. Known-future support makes useful covariates possible; it does not remove the need for a chronological evidence boundary or certify every future-labelled column in a retrospective dataset.

Further analysis: Reproducible inference stacks: preserving a GPU pilot’s result; A GPU inference benchmark you can trust.

← All retrospectives