AI Supply Chain Forecaster

The brief

The question arrives dressed as an AI problem, which is the first trap.

“Design an AI system that forecasts demand for our products and tells us how much inventory to hold. We have about eighty thousand SKUs across four hundred stores and two distribution centres.”

“Our planners are doing this in Excel and they’re wrong a lot. Can an LLM do it?”

The second phrasing is a gift, and the answer to it is no. Say so early, say it politely, and say why.

In plain terms the product does two things that people constantly conflate. It forecasts. For each product, at each location, for each future week, it produces a distribution over how many units will sell. Then it decides. Given that distribution, given lead times, and given what a stockout costs against what holding costs, it works out how much to order and when.

The forecast is a statistics problem. The decision is an optimisation problem. Neither is a language-model problem. A strong candidate separates them in the first ninety seconds, because almost every bad design in this space comes from treating “predict demand” and “set inventory” as one blob.

What I’d ask first

“What decision does this forecast feed, and on what cadence?”

This is the only question that sets the specification. A weekly replenishment order to a supplier with a six-week lead time needs a forecast at weekly granularity, out to at least eight weeks, at the SKU-location level, with uncertainty. A quarterly buy for a seasonal apparel line needs something completely different, at a much coarser level, with far more judgement in it. A daily fresh-food order needs a one-to-three-day horizon with a hard spoilage constraint.

If the interviewer cannot name the decision, then the project has no target. The honest answer is that I would spend the first two weeks finding one, because forecast horizon, granularity, and the entire accuracy bar fall out of it.

“What does a stockout cost, and what does holding a unit cost?”

I ask this because the asymmetry is the whole optimisation, and people leave it implicit. For a razor blade, a stockout is a lost margin of a dollar and a mildly annoyed customer. For a car part in a service bay, a stockout is a vehicle immobilised and a customer who leaves forever. For a vaccine, a stockout has a cost that is not denominated in dollars at all. Meanwhile holding cost is capital plus warehouse plus obsolescence. For perishables it also includes near-total write-off at expiry.

Until I know the ratio I cannot pick a service level. Until I have a service level, the forecast has no target quantile. This is also the question that separates a modelling candidate from a systems candidate.

“What data do we actually have, at what granularity, and for how long?”

Specifically, do we have transaction-level sales or aggregated sales? Do we have demand or only sales? Those are different, and the difference is the single most underrated technical issue in this domain. Sales are censored by availability. When you were out of stock you sold zero, but demand was not zero. If you train on sales, you teach the model that stockouts are low-demand periods, and it will under-forecast exactly the items that keep stocking out. Do we have historical on-hand inventory, so we can identify and correct censored periods? Do we have price and promotion history, aligned to the right dates, including promotions that were planned and then cancelled?

“How much of the assortment is new or short-lived?”

Fashion, electronics, and CPG innovation pipelines mean a large fraction of SKUs have no history at all. If 30% of next quarter’s revenue comes from products that do not exist yet, then the cold-start machinery is not a footnote. It is a co-equal system.

“What’s the intermittency profile?”

At store-SKU level in most retailers, the majority of series are mostly zeros. That single fact invalidates half the methods people reach for, and it changes the metric. MAPE is undefined when the actual is zero, and it is quietly useless when the actual is small.

“Who consumes the output, and can they override it?”

Planners will override. They should be able to. Whether their overrides improve or degrade accuracy is an empirical question, and you must instrument it from day one. In my experience the honest answer is “both, depending on the planner and the category,” which is itself a valuable finding.

The answers I’ll design against. Weekly replenishment, eight-week horizon, SKU-store granularity. Roughly 80,000 SKUs and 400 stores, which gives low tens of millions of active series. Three years of history, sales rather than demand, with on-hand snapshots available daily. Stockout-to-holding cost ratio around 4:1 on average, but varying enormously by category. About 20% of SKUs new each year. Heavily intermittent at the leaf level. Planners can override with a reason code.

The design

  DATA PLANE                              MODEL PLANE
  ----------                              -----------
  POS transactions ─┐
  Inventory snaps  ─┤                    ┌──────────────────────┐
  Price / promo    ─┼──► [Ingest ETL] ──►│  Feature Store       │
  Product master   ─┤     validate       │  point-in-time       │
  Store master     ─┤     dedupe         │  correct, versioned  │
  Supplier lead t. ─┘     late-arrival   └──────────┬───────────┘
                          handling                  │
  Weather / events ──► [External ETL] ──────────────┤
  Competitor px    ──►                              │
  Unstructured:                                     ▼
   supplier emails ──► [LLM extractor] ──► ┌─────────────────────┐
   news, notices        structured         │  Base forecaster    │
   promo PDFs           signals + conf.    │  GBDT global model  │
                                           │  + intermittent     │
                                           │    specialists      │
                                           │  + new-product      │
                                           │    analog model     │
                                           └──────────┬──────────┘
                                                      │ quantiles per
                                                      │ SKU-store-week
                                                      ▼
                                           ┌─────────────────────┐
                                           │  Reconciliation     │
                                           │  (coherent across   │
                                           │   the hierarchy)    │
                                           └──────────┬──────────┘
                                                      ▼
  DECISION PLANE                           ┌─────────────────────┐
  --------------                           │  Inventory optimizer│
  lead times, MOQs, ──────────────────────►│  safety stock,      │
  capacity, shelf life                     │  reorder point, qty │
                                           └──────────┬──────────┘
                                                      ▼
                                     ┌────────────────────────────────┐
                                     │  PLANNER WORKBENCH             │
                                     │  proposed orders, exceptions,  │
                                     │  drivers, override + reason,   │
                                     │  LLM explanation of the change │
                                     └────────────┬───────────────────┘
                                                  ▼
                                            [ERP / purchase orders]
                                                  │
                                            [Outcome log] ──► backtests,
                                                              override analysis

Ingestion. POS data lands nightly, and it is late, partial, and occasionally replayed. The non-negotiable property here is point-in-time correctness. For any historical date, the feature store must be able to reproduce exactly the data that was available as of that date, not the data as it looks now after corrections. Without point-in-time correctness you cannot backtest honestly, and everything downstream is fiction. There is more on this below, because it is the chapter’s central failure mode.

External signals arrive on their own schedules. That includes weather, holiday calendars, local events, and competitor pricing. Each needs its own freshness contract and its own fallback for when the vendor is down.

Feature engineering. The features are calendar features, lags, rolling statistics at several windows, price and relative price, promotion flags with lead and lag windows, days-since-launch, store attributes, category embeddings, and the stockout mask. The stockout mask matters. For every SKU-store-day where on-hand was zero, the observation is censored. So you either mask it from the loss or impute demand for it.

The base forecaster. Use one global gradient-boosted model trained across all series, not eighty thousand local models. This is the settled empirical result in this domain. The M5 competition used exactly this Walmart-shaped hierarchical retail data. It was won by ensembles of LightGBM models trained across series. All fifty top methods beat the statistical benchmarks, and the winner improved roughly 22% over the best benchmark (Makridakis, Spiliotis & Assimakopoulos, IJF 2022). Cross-learning is why. A new store’s SKU borrows the shape of ten thousand similar series, instead of learning from its own thin history.

Train it to produce quantiles, not a point estimate, because the decision layer needs a distribution. Use pinball loss at the quantiles you actually use.

Alongside it, add specialists where the global model is weak. That means an intermittent-demand method for the very sparse leaf series, and a separate analog-based model for new products.

Deep learning and time-series foundation models are real and worth benchmarking. That includes N-BEATS, DeepAR, Chronos, and TimesFM, and they are especially attractive for zero-shot cold start. However, make the boosted-tree ensemble your baseline, and make anything else beat it on your data before it ships. In M5, deep learning appeared in the top five but did not win, and the operational cost of the tree model is far lower.

Hierarchical reconciliation. Your forecasts must add up. Store-level forecasts must sum to region, and region must sum to national. SKU must sum to subcategory, and subcategory to category. Independent forecasts at each level will not be coherent. Incoherent numbers destroy trust instantly, the first time finance and supply chain quote different totals in the same meeting. So use a reconciliation method. MinT-style optimal reconciliation is the standard reference, and it typically improves accuracy as well, because it pools information across levels (Wickramasuriya, Athanasopoulos & Hyndman).

The decision layer. This is where the money is, and it is not machine learning. The inputs are the quantile forecast over lead time, the service-level target derived from the cost ratio, the supplier’s lead time and its variance, minimum order quantities, case packs, truck capacity, and shelf life. From those you compute reorder points and order quantities. Use newsvendor logic for the perishables, standard safety-stock formulations elsewhere, and a constrained optimisation where capacity actually binds.

The human surface. Planners do not want to see eighty thousand forecasts. They want an exception queue: the two hundred items where the recommendation changed materially, or confidence is low, or the model disagrees with last cycle, or a business rule tripped. Every recommendation shows its drivers. Overrides are one click and require a reason code, and the reason codes are a dataset.

Where the AI actually is

Here is the part to say plainly, because it is the point of the chapter. This is a classical forecasting and operations-research problem, and the large language model is a peripheral.

If you propose “feed the sales history to an LLM and ask it to predict next week,” you have failed the question. Language models are not trained on numeric sequences with the right inductive biases. They cost several orders of magnitude more per prediction than a boosted tree. They cannot be calibrated to a quantile, and they are not reproducible run to run. Meanwhile you need tens of millions of predictions per night, on a schedule.

Where a language model genuinely earns its place, in three spots:

Ingesting unstructured external signal. That includes supplier emails announcing a delay, trade-press articles about a factory fire, local event listings, regulatory notices, competitor promotion PDFs, and internal Slack threads where a buyer mentions a launch has slipped. This is real, valuable, structured-extraction work that used to require humans, and it is exactly what an LLM is good at. It turns messy text into {signal_type, sku_scope, location_scope, effect_direction, effect_window, confidence, source_url}. That structured record then goes into the feature store as a feature, or into the planner’s exception queue as a flag. The LLM produces evidence. The forecaster produces numbers.

Explaining a forecast. “Why did the recommendation for this SKU drop 40%?” You compute the answer deterministically, with feature attributions and a diff of the inputs. The LLM’s job is to render that computation as two sentences of English a planner reads in three seconds. It is a renderer, not a reasoner, and this distinction keeps it honest.

A natural-language interface over the planning data. “Show me every SKU in the Northeast where projected coverage falls below two weeks before the Thanksgiving promo.” That is text-to-query against a well-defined schema, with the query shown to the user before it runs.

What is ordinary engineering, and it is the overwhelming majority: the ETL and its late-arrival handling, the feature store and its point-in-time guarantees, and master data management. Master data management is a genuinely hard and thankless problem, covering SKU merges, store openings, category re-mappings, and unit-of-measure inconsistencies. Then there is the training and scoring orchestration for tens of millions of series on a nightly window, the backtesting harness, the reconciliation implementation, the optimiser, the ERP integration, the planner workbench, and monitoring and alerting on data freshness and forecast drift.

What I would deliberately not use an LLM for: producing any number that flows into an order, deciding a safety stock, or classifying a SKU into a category when you have a labelled master and a classifier. I would also not use one to detect an anomaly in a numeric series, because that is what statistical process control is for. And I would not use one for anything that must be reproducible for an audit.

Key decisions and tradeoffs

The fork worth dwelling on is forecast accuracy versus business outcome, because it separates a data scientist’s answer from an engineer’s.

You can improve WMAPE by 3% and save nothing, because the improvement landed on slow-moving low-margin items where inventory was never the constraint. You can also leave accuracy flat and save eight figures, by fixing the service-level targets on the two hundred SKUs that drive the stockouts. The objective is not accuracy. The objective is expected cost, and the cost function is asymmetric and varies by item. Design your evaluation around that from the start, or you will spend a year optimising the wrong scalar.

What breaks

Leakage, and it is the classic failure here. This is the one an interviewer is waiting for you to raise unprompted.

The mechanisms are specific, and they are worth naming individually. Using future information in a feature. Examples are a rolling mean computed over the whole dataset, a “was this item promoted” flag built from the final promotion calendar including promotions decided after the forecast date, and a category assignment that reflects a later re-mapping. Random train/test splits. Shuffling a time series and testing on interspersed points means the model sees next week to predict this week. Splits must be by time, always. Restated history. The sales figure for a date, as it stands in the warehouse today, is not what it was three days after that date. Returns, corrections, and late store uploads changed it. Backtesting against restated data flatters you. Target leakage through inventory. On-hand at end of day is a function of sales that day.

The mitigation is architectural, not procedural. Build a feature store with point-in-time joins. Every feature carries a valid-from timestamp, and the backtester can only see rows whose timestamp precedes the forecast creation date. Build that first. It is unglamorous, and it is where the engineering is. It is also the difference between a model that backtests at 15% error and delivers 15%, and one that backtests at 9% and delivers 22%.

Stockout censoring. I covered this above, but it belongs in the failure list because it silently corrupts the training signal, and because it self-reinforces. You under-forecast the item, stock less, sell less, observe lower demand, and under-forecast further. So detect censored periods from inventory snapshots, and either mask them or impute.

Promotions. Promotion effects are enormous and non-linear, and they interact with each other and with cannibalisation. A promoted item lifts, its substitutes drop, and its complements rise. If you model each SKU independently, you will over-forecast the whole category during a promo week. There is a worse problem. Promotional plans change late, so the plan you trained on is not the plan that ran. So require the promotion calendar to be versioned, with the same point-in-time discipline as everything else.

New products and cold start. No history means the global model has nothing to lag on. The workable approach is an analog model. Represent the new product by its attributes, meaning category, price tier, pack size, brand, and increasingly a text or image embedding of its description. Find the k most similar historical launches, and use their scaled launch curves as the prior. Then blend toward the observed data as it arrives, with the blend weight driven by weeks of history. Be explicit that cold-start forecasts should carry visibly wider intervals, and that they should be over-represented in the planner’s review queue.

Structural breaks. The pandemic broke every retail forecasting system on earth, and smaller versions happen constantly. A competitor opens across the street, a store remodels, a category is re-merchandised, or a supplier is switched. Models trained on a long window revert to a world that no longer exists. The mitigations are recency weighting in training, a regime-change detector that flags series whose recent error distribution has shifted, and a manual override path. That override path lets a human declare “this store’s history before March is not comparable,” and it matters more than it sounds.

Hierarchy churn. SKUs get merged, split, and renumbered. Stores open, close, and get re-districted. Categories are reorganised annually by people who do not know you exist. Every one of those breaks a time series silently, and the model happily forecasts a series that has been two different products. This is master data management, and it will consume more of your team than the model does.

The optimiser amplifies forecast error. A small forecast error at the leaf can produce a large order error, once minimum order quantities, case packs, and truck rounding are applied. So evaluate the ordering decision, not just the forecast. A system that is 2% more accurate and 10% worse after rounding is a regression.

Planner distrust, which is fatal and non-technical. If planners do not believe the numbers, they will override everything, and you have shipped an expensive Excel. Trust is built by four things. Coherence means the numbers add up. Explanation means they can see why. Stability means the recommendation does not swing wildly week to week for no reason. The fourth is conceding the first few arguments where they were right. Forecast stability is a genuine objective in tension with accuracy, and it is worth trading a little accuracy for it.

How you’d evaluate it

Offline, and the harness is the deliverable. Use rolling-origin backtesting, sometimes called walk-forward. Pick an origin date, train on everything strictly before it, forecast the horizon, step forward, and repeat across many origins spanning at least a full seasonal cycle. One holdout period is not enough. You need the distribution of performance across origins, because a single split can be lucky or land entirely inside a stable regime.

The metric choice matters more than usual here, because of the zeros. MAPE is unusable at the leaf. It is undefined on zero actuals and explosive on small ones. Use scaled errors instead: RMSSE or MASE, weighted by value. That is essentially what M5’s WRMSSE does, and it is a defensible default. For the quantiles, use pinball loss plus a calibration check. If your 90th percentile is exceeded 20% of the time, your safety stock is wrong, regardless of what the point accuracy says. Report by segment, always: by velocity band, by category, by newness, and by store format. An aggregate number hides that you are excellent on the fast movers that were already easy, and terrible on the tail that drives your stockouts.

Baselines are mandatory, and they should be embarrassing to lose to: seasonal naive, last-four-week average, and the incumbent process including planner overrides. “Beats the current planners” is the only bar the business cares about.

Online. Run shadow mode first. Run the system for a full cycle producing recommendations nobody acts on, and compare against what the planners actually did and what subsequently happened. Then run a geo or store-level randomised rollout, which is the cleanest experiment available in this domain, because stores are natural units. Match on volume and format, run for at least a full seasonal cycle, and accept that this means months rather than a week.

The metric that actually matters to the business is not forecast error at all. It is inventory cost plus stockout cost. Realistically that is expressed as on-hand inventory value or turns, in-stock rate or fill rate, and waste or markdown for perishables, all held together at a target service level. Frame every result that way. “WMAPE improved 4%” is a means. “We held eleven million dollars less inventory at the same in-stock rate” is the result.

Catching regressions. Data quality gates run before training and block the pipeline. They check row counts, null rates, distribution shifts on key features, and freshness of every external feed. Most forecasting incidents are data incidents, and most of those are silent. A feed stops updating, and the model happily forecasts on stale features for a week. Store every model version’s backtest and compare them, with segment-level gates, so an aggregate improvement that tanks the fresh-produce category is caught. Monitor prediction distributions in production against training, and monitor realised error weekly with alerts on drift.

The sibling agentic-ai-evaluation-guide is the reference for evaluating the LLM-shaped components here. Those are the unstructured-signal extractor and the explanation layer, and both need their own precision and recall discipline and their own golden sets. The numeric forecaster’s evaluation is ordinary, rigorous, well-understood forecasting practice, and it should be treated as such.

Follow-ups they will ask

“Where would you actually use an LLM here, if anywhere?” Three places, and none of them produce a number. First, extracting structured signals from unstructured external text, such as supplier delay notices, news, event calendars, and competitor promo materials. Those become typed records with a confidence and a source, which then become features or planner alerts. Second, rendering an explanation of a computed forecast change into plain English, where the computation is deterministic and the model is only the writer. Third, a natural-language query interface over the planning data, with the generated query shown before execution. Anywhere else and I would be paying a thousand times the cost for a worse, slower, less reproducible number.

“Why not just use a time-series foundation model zero-shot?” I would benchmark one. Chronos, TimesFM, and similar models are genuine advances, and they are legitimately compelling for cold start, where you have no history to fit. However, I would not lead with one, for three reasons. First, they have not consistently beaten well-tuned global gradient-boosted models on rich retail data with strong covariates. Covariates are exactly what you have here: price, promotion, calendar, and store attributes. Zero-shot models are weakest precisely where your signal is strongest. Second, inference cost at tens of millions of series per night is a real constraint. Third, you lose the ability to explain a forecast in terms of features, which is what earns planner trust. The sensible shape is a boosted-tree workhorse, with a foundation model as a cold-start component and as an ensemble member if it earns its place on your backtest.

“How do you forecast a product that doesn’t exist yet?” With attribute-based analogs. Represent the new item by its structured attributes and an embedding of its description and image. Retrieve the k most similar historical launches, align their launch curves by weeks-since-launch, scale by expected distribution and price point, and use the resulting curve as the prior. Weight the analogs by similarity and recency. Then update. As the first weeks of real sales arrive, shift weight from the prior to the observed data, with a Bayesian-flavoured blend whose rate you tune on historical launches. Be honest about uncertainty. The intervals here should be wide, and the planner workbench should show that they are wide rather than presenting a false precision. I would also evaluate this component separately, backtested on past launches, because its error profile is completely different from the mature-SKU model, and averaging them together hides it.

“Explain leakage in this system and how you prevent it structurally.” Leakage is any information in a training row that would not have been available at the moment the forecast is made. There are four common vectors. The first is features computed over the full history rather than as of the origin. The second is random rather than time-based splits. The third is training against restated data that has been corrected since. The fourth is target-derived features like end-of-day inventory. Procedural prevention fails, because a smart person will add a helpful feature six months from now and reintroduce it. So I make it structural. Every row in the feature store carries an available_at timestamp. The backtester constructs training sets by point-in-time join against that timestamp, so it is physically impossible to select a feature value that was written after the origin. Then I add a canary: a deliberately leaky feature in a test suite that must show unrealistic backtest performance, which proves the harness would have caught it. And I treat a suspiciously large accuracy jump as a leakage alarm until proven otherwise, because that is almost always what it is.

“Your model is 5% more accurate and the business saw no benefit. What happened?” Most likely one of four things, and I would check them in order. First, the accuracy gain landed where it does not matter. That means slow movers, or items where the order quantity is dominated by a case pack, so the forecast could move 20% without changing the order. Second, the gain was in the point forecast, but the decision uses a tail quantile, and the tail did not improve or got worse. Third, the optimiser or the business rules absorbed it. That means minimum order quantities, truck rounding, or a planner override policy that ignores changes below a threshold. Fourth, the constraint was never inventory. You were stocking out because of supplier fill rate or transport, and no forecast fixes that. The diagnosis is to evaluate the decision, not the forecast. Replay the optimiser on both forecasts and compare simulated cost, which is why I want that simulator built early.

“How do you handle the promotion the marketing team scheduled and then cancelled on Thursday?” There are two separate problems. For training, the promotion calendar must be versioned, so that a backtest at origin T sees the plan as it stood at T, not the final executed plan. Otherwise the model learns from a future it could not have known. For serving, the calendar is an input that changes after the forecast is produced. So I need a re-forecast trigger on material plan changes, and a clear cutoff. After the cutoff the order is placed, and changes go to an exception queue for a human, not to an automated re-order. I would also measure plan-versus-actual promotion execution as its own data-quality metric, because in most organisations it is bad and nobody has quantified it. If 30% of planned promotions do not run as planned, that is a number the model needs to know.

“How do you deal with the fact that most of your series are mostly zeros?” First, by not pretending they are continuous. Intermittent series need methods built for them. Use Croston-family approaches and their variants as a baseline, or a global model with a loss that handles zero inflation. Often you want a two-part formulation that separates “will it sell at all” from “how much, given it sells.” Second, by choosing the right metric. Use scaled errors rather than percentage errors, and evaluate the quantiles rather than the mean. For an item that sells zero most weeks, a mean forecast of 0.3 units is both correct and operationally useless. The useful output is the probability of selling at least one case. Third, by aggregating where the decision permits. If replenishment is weekly, forecast weekly rather than daily, because aggregation is free variance reduction.

“The forecasts don’t add up. Finance says one number, supply chain says another. Fix it.” That is a coherence problem, and it is solvable, which is the good news. Produce forecasts at multiple aggregation levels and reconcile them into a single coherent set. MinT-style optimal reconciliation weights each level’s forecast by its estimated error covariance, which both guarantees coherence and typically improves accuracy over any single level alone. The organisational half matters as much. There must be exactly one published forecast object, with one version number, and every consumer reads from it. Finance running its own model in a spreadsheet is the actual root cause, and reconciliation only fixes the technical symptom.

“Planners override 40% of your recommendations. Is that a problem?” It is a measurement opportunity before it is a problem. Every override is a labelled experiment. I have the model’s number, the human’s number, and eventually the actual. So I compute override value-add. Did the override move the forecast toward or away from truth, and by how much in cost terms? I slice that by planner, category, reason code, and magnitude. The usual finding is bimodal. Overrides on new products and promotions add real value, because the planner has information the model does not. Small routine adjustments on stable items destroy value, and they are mostly anchoring. Then act on that. Keep overrides where they help, and reduce them where they do not by fixing the underlying gap. Usually the model was missing the information the planner had, so the fix is a new feature rather than a lock on the UI. And publish the scorecard back to planners. It changes behaviour faster than any policy.

“What breaks when a pandemic happens?” Everything. The honest answer is that no forecasting system predicts a structural break, and expecting one to is a category error. What a well-designed system does is detect and adapt fast. Concretely, it needs four things. A regime-change detector monitoring recent error distributions per series and per category, which flags when the model’s errors have shifted beyond what noise explains. Recency-weighted retraining that can be dialled up so recent weeks dominate. A mechanism for a human to declare a period non-comparable and exclude it from training. And a rapid fallback to simpler, more adaptive methods for affected segments, because in a break a four-week moving average often beats a sophisticated model that is confidently reverting to a dead seasonality. It also needs wider intervals, communicated as wider, so the safety stock rises automatically where uncertainty rose.

“How do you set the service level?” From the cost ratio, not from a policy document. The critical fractile is the stockout cost divided by the sum of stockout and holding costs. It tells you which quantile of the demand distribution to stock to. The interesting work is getting those costs, and they are never in one place. Stockout cost includes lost margin, substitution rate, and long-run churn effects. Substitution matters, because a customer who buys the alternative costs you very little. Churn effects are genuinely hard to estimate. So I would segment rather than pretend to precision. Use a handful of service-level tiers by category and margin, set with the merchandising team, and refined by A/B where volumes permit. I would also make the resulting quantile explicit in the system. Then, when someone asks “why are we holding this much,” the answer is a number with a cost behind it rather than “the model said so.”

“What’s the compute story for tens of millions of series?” It is a batch scheduling problem rather than a serving problem, which makes it easier than people fear. Training is a handful of global models, partitioned sensibly, often by category or by store cluster. That parallelises trivially and runs in hours on a modest cluster. Scoring is embarrassingly parallel. Shard by store, run distributed, and write to a columnar store. The binding constraint is the nightly window. POS lands at 2am and orders must be cut by 6am, so the whole pipeline, including data quality gates, has to fit in about three hours with room to rerun once. I would design for a partial-failure mode where a shard that fails falls back to the previous day’s forecast, rather than blocking the entire order cycle. A stale forecast for one region is vastly better than no orders for the chain.

“How much of this project is AI?” Less than a fifth, and the model is not where it goes wrong. The bulk is data engineering: ingestion, master data, and the point-in-time feature store. Then the optimiser, the ERP integration, the planner workbench, and the backtesting harness. The projects I have seen fail here failed on SKU master data quality, or on a nightly window that could not be met, or on planners who never trusted the output and quietly kept their spreadsheets. None of those are model problems, and a plan that budgets like they are will slip.

Say it in one breath

Demand forecasting is a classical time-series and operations-research problem, not a language-model problem. It is a global gradient-boosted model producing quantiles per SKU-location-week, reconciled across the hierarchy, feeding an inventory optimiser that uses the asymmetric cost of stockouts versus holding to pick a service level. The language model belongs at the edges. It turns unstructured external text into structured signals, and it turns a computed forecast change into a sentence a planner reads. It never produces the number itself. The engineering that decides whether it works is a point-in-time-correct feature store, because leakage is the classic failure here. The metric that decides whether it matters is inventory cost at a target in-stock rate, not forecast error.