Chronos converts scaled and quantised series values into tokens from a fixed vocabulary, then trains transformer-based language-model architectures with cross-entropy loss. The reported models use the T5 family and range from 20M to 710M parameters. This mechanism matters more than the linguistic analogy: the model learns a distribution over token sequences, not an understanding of garments, prices or customer intentions.[S25]
Tokenisation creates specific checks for the evaluation harness. The team should record the scaling rule, treatment of zeros and missing intervals, context length, quantisation behaviour and conversion from generated tokens back into demand units. A coarse representation may be acceptable for a noisy launch, but that is an empirical question. Very small counts, abrupt order spikes and long zero runs should be inspected in their original units so that a smooth token sequence cannot conceal an implausible operating forecast.
Sampling from a probabilistic model supplies a predictive distribution, but it does not certify calibration. The forecast service must retain enough sampled paths or quantiles to reproduce the published output, then assess interval coverage, width and quantile loss on held-out launches. A narrow distribution can be confidently wrong. A wide one can be unhelpful even when its coverage looks acceptable. Proper scoring rules provide a principled way to compare the full forecasts rather than selecting whichever quantile happens to flatter the candidate.[S14]
10.5 Chronos earns a test through transfer, not through scale
The Chronos results distinguish datasets included in training from new zero-shot datasets. The authors report stronger performance in the former setting and comparable, occasionally superior performance in the latter. That pattern is exactly why the apparel evaluation should preserve separate readouts for reference launches used in any adaptation and wholly unseen target launches. It also prevents the strongest reported setting from becoming the default headline for a different use case.[S25]
Model size is a deployment variable, not a proxy for cold-start relevance. The parameter range reported for Chronos gives the evaluator several possible operating points, but the smallest adequate candidate is the one that belongs in a small team's complexity budget. The selection record should show accuracy and distribution quality beside runtime and failure behaviour for each tested variant. A larger checkpoint earns its additional burden only through the same launch replay.[S25]
10.6 Lag-Llama adds lag-based probabilistic transfer
Lag-Llama is presented as a general-purpose model for univariate probabilistic forecasting, using a decoder-only transformer with lag covariates. Its authors describe pretraining on a diverse corpus and zero-shot generalisation on downstream datasets across domains. They also report gains from fine-tuning on relatively small fractions of previously unseen datasets. These findings support two distinct candidate modes: direct inference and documented adaptation.[S27]
The distinction controls leakage. Direct inference can be evaluated on a held-out launch with no parameter update from that launch. Fine-tuning requires the target launch, or a defined portion of its early history, to enter training. The evaluation must then replay exactly when those observations became available and keep later outcomes out of every fitting and preprocessing step. A fine-tuned result cannot be presented as a pre-launch forecast merely because the adaptation was small.
Lag covariates also have a precise operational meaning. They encode earlier values at selected offsets; they do not automatically encode product attributes, stock availability or future promotions. A forecaster that performs well after seeing a stable weekly rhythm may still have no valid representation of a first production lot whose sizes are only partly available. The input register should list the lags actually used and confirm that each exists at the forecast origin.
For both probabilistic candidates, output validation should test count plausibility as well as statistical loss. Negative demand, non-monotone quantiles, unstable samples under a fixed seed and excessive mass on impossible order sizes require explicit handling. The team should not silently clip every implausible result and call the repaired distribution a model success. Any transformation belongs in the candidate specification and is applied identically during replay and operation.