# Introducing Timestral: chronological holdouts after the release

A chronological holdout for Timestral must preserve the information available at each forecast origin, because zero-shot use does not automatically make a retrospective evaluation leakage-free.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-10-15
Original announcement: https://mistral.ai/news/timestral/
Canonical URL: https://retrivium.ai/retrospectives/retro-mistral-timestral-forecast-splits/

A chronological holdout for Timestral must preserve the information available at each forecast origin, because zero-shot use does not automatically make a retrospective evaluation leakage-free.

## Start from the decision time

A forecast simulates a decision made before its target outcome is observed. The evaluation therefore needs a boundary separating inputs available then from information learned later. Randomly mixing records can remove that boundary even when the model itself is never fine-tuned on the held-out outcomes.

## The release and its predecessors

The [Timestral announcement](https://mistral.ai/news/timestral/) introduces the specialist forecasting family. The earlier [decoder-only forecasting paper](https://arxiv.org/abs/2310.10688) and [Chronos paper](https://arxiv.org/abs/2403.07815) provide research context. Neither makes an arbitrary local split chronologically valid or establishes the provenance of every dataset an operator later chooses.

Zero-shot describes a particular adaptation claim. It does not determine whether preprocessing learned from future records, whether revised values were used or whether the selected evaluation period was chosen after inspecting outcomes. Those are separate properties of the assessment procedure.

## A rolling-origin example

Imagine issuing forecasts repeatedly as new observations arrive. Each issuance should use the history and preprocessing state available at that point. A scaler fitted once over the final full table can give earlier simulated forecasts information from later records, even if no future target is visibly included in their input rows.

| Evaluation artifact | Historical question |
| --- | --- |
| Input history | Which observations existed at the simulated issuance? |
| Preprocessing state | Which records were used to derive transformations? |
| Selected evaluation cases | Were they defined independently of their eventual outcomes? |

## Keep revisions visible

Some datasets are corrected after initial publication. A final cleaned series can be useful for a stated research purpose, but it is not automatically the same information stream available to an earlier operational forecaster. The distinction should be documented rather than hidden behind a simple train-test label.

If original snapshots are unavailable, state what reconstruction was possible and what remains uncertain. A limited evaluation can still be informative. It should not claim to reproduce a historical decision environment more exactly than its surviving data permits.

## The retrospective lesson

The release makes zero-shot forecasting a practical evaluation route, while the operator still owns the temporal validity of the experiment. Model access and dataset chronology answer different questions.

The conclusion is to preserve an issuance-based ledger of history, transformations and outcomes. That makes the evaluation explainable without assuming that a no-fine-tuning setup has automatically controlled every way future information can enter a retrospective experiment.

Further analysis: [A GPU inference benchmark you can trust](/journal/inference-benchmark-method/); [Reproducible inference stacks: preserving a GPU pilot’s result](/journal/software-stack-reproducibility/).