Imagine you run a bakery. An AI forecasts that tomorrow’s demand will be 100 loaves. You need to order ingredients, set the ovens and decide how much unsold bread you can afford.
That number leaves an important question unanswered: does the model expect demand to stay close to 100, or could tomorrow plausibly bring demand for 60 loaves—or 140?
The bakery scenarios and loaf counts are invented for explanation. They are not model-test results.
Mistral’s October 15 release of Timestral gives this question a timely hook. It is a model family for forecasting numbers over time, such as demand or sensor readings. Its forecasts include estimates of uncertainty. The useful idea for everyone else is simple: a forecast should help you understand how much room to leave for being wrong.
Two forecasts, one headline number
Suppose two hypothetical forecasts describe tomorrow like this:
| Forecast | Middle estimate | Estimated middle 80% range |
|---|---|---|
| A | 100 | 95–105 |
| B | 100 | 60–140 |
A dashboard displaying only “100” would make these look identical. For the baker, they suggest different preparations. Forecast B might prompt a smaller first batch with ingredients held for a second, provided the oven schedule allows it. Forecast A might support a more settled plan—if its narrow range has earned trust.
Neither forecast tells the baker exactly what to do. Suppose leftover loaves can be frozen for another product. Extra bread may then be less costly than turning customers away. If leftovers must be discarded, the same forecast could lead to a different baking plan. Available staff, oven capacity and advance orders matter too.
The prediction describes possible demand. The baker still has to choose which consequences to accept. Treating 100 as an instruction to bake exactly 100 skips that choice.
First, though, check what is being counted. In our invented shop, 100 customers could buy 160 loaves. And 100 loaves sold could mean the shelves emptied at closing—or at eleven in the morning. If the baker made only 100 but customers wanted 140, the till would still record 100 sales. A forecast of recorded sales would be answering a different question from a forecast of all the bread customers wanted. Write down the quantity and time period before deciding whether the prediction is useful.
What the range actually means
Timestral’s official documentation says it returns 21 quantiles: cut points in its estimated distribution of future outcomes. The median is the middle cut point. The 10th and 90th percentiles can bracket a range intended to contain roughly the middle 80% of outcomes.
That is a model estimate, not a promise that exactly 80 of the next 100 days will land inside the range. A narrow range can be confidently wrong. Whether the stated probabilities match observed outcomes is something to check. Hyndman and Athanasopoulos explain prediction intervals and their evaluation in their forecasting textbook.
In the bakery example, a result of 120 loaves would sit outside A’s range and inside B’s. That one day would be worth recording; it would not establish which forecasting approach is better. The ranges already allow for outcomes outside them.
Give the forecast a fair test
Test on later observations, using only information that was available when each forecast would have been made. Compare with a simple reference such as demand on the same weekday last week. Track both missed outcomes and range width: predicting anything from zero to a million would cover plenty of days while helping little. These checks follow the textbook’s guidance on simple baselines, interval evaluation and time series cross-validation.
Record each forecast before opening. Add the outcome afterward, and investigate repeated misses on particular days.
Also ask what the model knew. Timestral supports information known ahead of time, such as a holiday calendar, according to its model documentation. A planned closure could be an input. Tomorrow’s actual demand cannot be smuggled into a test of tomorrow’s prediction.
What is available now
Developers can inspect the published inference library and obtain the model files. The documentation includes CPU and GPU use. Those are development resources; using them for a bakery would still require preparing the data, integrating the forecasts and evaluating the result.
Mistral reports strong benchmark performance, but those are the vendor’s results. Its announcement still describes a fuller technical report as forthcoming. This article has not independently tested the model, and a benchmark cannot settle how it will perform in our imaginary shop.
The next time a dashboard confidently presents one number, ask to see the range and its track record. For the baker, the useful answer is one that helps decide whether to load another tray into the oven.
