TimesFM-3 folds the promotion column into the forecast without a per-SKU model

The interesting part of a call is which columns you must be able to fill in for dates that have not happened yet. TimesFM-3 splits inputs into the target series, past covariates whose future values are unknown, and past-future covariates whose future values you claim to know ^[8]. In the horizon, target and past-covariate patches are masked while the past-future covariates stay visible, which is what carries a holiday flag or a scheduled promotion into the prediction ^[8]. A weather forecast passed in as a known future signal is still a forecast, with its own error, and the post lists weather forecasts alongside promotions and holidays as example future-known features ^[11].

The tokenisation is what puts the promotion on the right day. Points are grouped into patches of 32 steps and normalised per series to handle wildly different scales ^[5]. For past-future covariates, each token concatenates the current patch with future patches, a lookahead that lets the model peek at upcoming known signals ^[13]. Tokens pass an input residual block, then the stack alternates attention along time and across series for several layers ^[6]. The authors say the older patch-at-a-time decoding cost latency, compounding error and compute ^[7].

The promotion chart is Google's own illustration, and the mechanism behind the lift matters more than its size. The post says the relationship between promotion and sales lift is learned from the historical context, then applied to future days with planned promotions ^[10]. A SKU whose context window contains no promotions gives the model nothing to learn the lift from. New mechanics on new products remain your problem.

The accuracy claim is where I would spend the review. Google states that TimesFM-3 significantly outperforms other forecasting models across major benchmarks ^[17], and the text I have names no dataset, no baseline and no metric ^[18]. For that number to transfer, your covariates have to be genuinely known at forecast time rather than backfilled during evaluation, and your sampling frequency and series count have to sit somewhere inside a pretraining mix of more than a trillion real and synthetic points ^[2]. The comparison also has to be fair on inputs. A univariate baseline denied the promotion column is not evidence about your workload.

Output is nine quantiles per target series at every horizon step, the 10th through the 90th percentile ^[14]. That works out to 10 percentile points of spacing and nothing above p90 ^[16]. If your safety stock is set at a 97.5% service level, you are extrapolating a tail off a decile grid, which is a modelling decision you now own rather than one the model made for you.

What actually weakens is narrow. If a per-SKU pipeline exists to bolt a promotion dummy and a holiday calendar onto univariate models, the replacement is a column layout plus an evaluation harness, with no training run, because the multivariate mode is zero-shot ^[4]. Google went from strictly univariate at 2.5 to native multivariate in roughly eleven months ^[3][15]. Pipelines that exist for hierarchical reconciliation, intermittent demand or business overrides are untouched here, because the post does not discuss them ^[18]. In my context the right sequence is to keep the harness, run the zoo and the foundation model side by side on your own series, and delete only what loses.