Adaptive replenishment for multi-node commerce inventory: a design

1Context and motivation

Inventory policy has a long history. The economic lot size was already argued in 1913 from two opposing costs: interest on capital tied up in stock sets an upper limit on how much to make at once, and set-up cost sets a lower one¹. Reorder points, order-up-to levels and safety stocks computed from the mean and variability of demand over the lead time are the standard tools that followed².

Those tools are sound. The difficulty in commerce is how their parameters are maintained. A reorder point computed once from last year's average assumes that demand and lead time hold still. Online demand moves with promotions, seasons and social attention; lead times move with supplier performance and congestion; stock sits at several nodes that can cover for each other. Parameters that are not recomputed drift away from the conditions they were set for, and planners correct the drift by hand, one item at a time.

This paper describes the design we propose for a replenishment service that keeps the classical policy structures but recomputes their parameters continuously from probabilistic forecasts, with the network in view. An earlier version of this paper reported simulated comparisons between static and adaptive policies, and regional results; we cannot show those simulations, and they are removed.

2Scope

The service makes three kinds of decision for each item at each stocking node: when to order and how much, how to split inbound stock between nodes, and when to move stock between nodes. It covers stock the operator holds in its own nodes and, where a merchant opts in, stock held for a merchant in a shared node. Purchasing negotiations, supplier selection and production planning are outside its scope; it reads their outputs (minimum order quantities, quoted lead times, capacity) as constraints.

3Design principles

• Keep the policy structure, adapt the parameters. The service uses reorder-point and order-up-to policies whose logic planners already understand, and recomputes their parameters on a schedule and on events.
• Forecast distributions, coherently. Demand forecasts are distributions, and forecasts at item, category and location levels add up.
• Lead time is uncertain too. Lead time is modelled as a distribution per supplier and lane, updated from receipts.
• Objectives are inputs. Target service level, risk tolerance and working capital limits are set per segment and are visible.
• The network is one system. Safety stock placement and transfers consider all nodes together.
• Share demand, not just orders. Suppliers receive forecasts and sell-through, not only purchase orders.

4Architecture

4.1Demand forecasting

Each item is forecast per node and channel as a distribution over the replenishment horizon. Global models trained across many related series can produce probabilistic forecasts for large catalogues, and probabilistic demand forecasts are what inventory decisions in retail need³. Forecasts for items, categories and locations must be coherent, meaning that lower-level forecasts add up to the higher-level ones. Reconciliation adjusts a set of incoherent forecasts so that they add up, and the trace-minimisation approach uses the full covariance matrix of forecast errors, minimises the mean squared error of the coherent forecasts under an unbiasedness assumption, and has a closed-form solution with a computationally efficient representation⁴. The service reconciles before any policy parameter is computed, so that node-level orders and category-level budgets agree.

Promotions, price changes and campaign calendars enter as known future inputs. Leading signals such as product page views and basket additions enter as features where their history is long enough to learn from.

4.2Lead-time model

For each supplier and inbound lane, the service fits a distribution of lead time from past receipts and updates it as new receipts arrive. A rising variance or a shift in the median is flagged to planners, because it changes safety stock even when demand is stable.

4.3Policy parameter computation

For each item at each node, the service computes the reorder point and order-up-to level from the forecast distribution of demand over the lead time plus review period, the lead-time distribution, the target service level, holding and shortage costs, and order constraints such as minimum quantities². Parameters are recomputed daily and whenever the forecast or the lead-time distribution moves beyond a tolerance. A change in a parameter is logged with its cause, so that a planner can see why an order quantity changed.

4.4Network-aware placement and transfers

The nodes of a commerce network supply each other. When one installation is supplied by another, the time to receive stock depends on whether the upstream installation has it, not only on transit time⁵. Where to hold safety stock in such a network can be optimised when each stage commits to a service time towards its customers⁶. Holding stock for several locations in one place lowers expected holding and shortage costs, with the saving depending on how correlated the locations' demands are⁷. Table 2 shows how large that dependence can be.

The service uses these results to propose, for each item, whether safety stock should sit centrally, at the forward nodes, or split between them, given the delivery-time cost of serving from further away. It proposes transfers between nodes when the expected cost of a shortage at one node exceeds the cost of moving stock from another.

4.5Information to suppliers

Orders sent upstream are a distorted signal of demand: their variance can exceed that of sales and the distortion tends to grow at each step upstream, for reasons that include demand signal processing, rationing, order batching and price variation⁸. Forecasting and lead times both contribute, and centralising demand information reduces the effect but does not eliminate it⁹. The value of sharing demand information can be high, especially when demand is significantly correlated over time¹⁰. The literature also gives a caution: in one numerical study, sharing demand and inventory data lowered supply chain costs by 2.2% on average, while halving lead times lowered them by 21% and halving batch sizes by 22%¹¹. The service therefore shares forecasts and sell-through with suppliers, and reports lead time and batch size as levers alongside the forecast.

4.6Learned policies

Replenishment over time is a sequential decision under uncertainty. Deep reinforcement learning has matched state-of-the-art heuristics on stationary lost-sales, dual-sourcing and multi-echelon problems, after demanding initial tuning, and its policies give little structural insight¹². In our design a learned policy is a candidate to be evaluated offline against the parameterised policies above, not a replacement for them.

Component	Problem it addresses	Evidence
Reorder-point and order-up-to policies	Trading ordering, holding and shortage costs	1, 2
Probabilistic forecasts per item and node	Point forecasts hide the variability that sets safety stock	3
Hierarchical reconciliation	Node orders and category budgets that do not add up	4
Network-aware safety stock placement	Upstream stock shapes downstream lead time	5, 6
Pooling decisions by demand correlation	Duplicate safety stock across nodes	7
Demand data shared with suppliers	Order variance amplified upstream	8, 9, 10
Lead time and batch size reported as levers	Overestimating what information alone can do	11
Offline-evaluated learned policy	Sequential effects of ordering under uncertainty	12

Source: our design, with the works cited in the table.

5A worked model of pooling

Table 2 applies the standard normal-demand safety stock formula to four nodes with identical demand. Each node faces lead-time demand with a standard deviation of 100 units, and the target cycle service level corresponds to a safety factor of 1.65. Held separately, each node carries 1.65 x 100 units. Held centrally, the pooled standard deviation is 100 x sqrt(4 + 12 x rho) for four nodes with pairwise correlation rho.

Pairwise correlation (input)	Separate nodes (units, computed)	Pooled (units, computed)	Pooled divided by separate (computed)
0.0	4 x 165 = 660	1.65 x 200 = 330	0.50
0.5	660	1.65 x 316.2 = 522	0.79
1.0	660	1.65 x 400 = 660	1.00

Source: Worked model; inputs in the table.

With independent demand, pooling halves safety stock for four nodes, which is the square-root effect of the cited result⁷. With perfectly correlated demand it saves nothing. Commerce demand across nodes is often correlated through national promotions and seasons, so the service estimates correlation from data before proposing to pool. Pooling also lengthens delivery for customers far from the central node and concentrates risk in one place; both enter the placement decision as costs.

6Evaluation protocol

Before any claim about stock-outs, inventory value or service could be made, a deployment would need the following.

• Forecast evaluation. Probabilistic accuracy by item, node and horizon, measured on held-out periods, with coherence checked after reconciliation. The M5 competition, built on 42,840 hierarchical series of unit sales from Walmart, offers a public benchmark against which the forecasting components can be compared¹³.
• Policy replay. Replay the candidate parameters on logged demand and receipts and compare fill rate, stock-outs, average inventory and orders placed against the incumbent parameters.
• Controlled rollout. A pre-registered test with fill rate as target and inventory value, expedite cost and markdowns as guardrails¹⁴. Because nodes share stock and suppliers, the test randomises by item group rather than by order.

7Fairness, privacy and governance

When a shared node holds stock for several merchants, placement decisions affect which merchants' products ship fast. The service applies the same placement rules to every merchant's items, and reports service level by merchant size so that systematic differences are visible. Merchant sales, costs and supplier terms are confidential; they are used to compute that merchant's parameters and are not exposed to other merchants. Planners can override any parameter, and overrides are logged with a reason so that the service can be checked against the people who know the business.

8Limitations

• No measurements. We have not measured this design's effect on stock-outs, inventory value or service. Figures quoted from the literature come from the cited studies.
• Forecasts fail at the edges. New items, rare events and step changes in demand are where forecasts are weakest and where replenishment errors cost most.
• Normal approximations. Table 2 and the standard formulas assume normally distributed demand; slow-moving items are not normal.
• Supplier behaviour. Sharing demand data helps only if suppliers use it; the design cannot make them.
• Regional claims removed. The earlier version described demand and lead-time behaviour by continent without a source. Those claims are cut.
• Learned policies. The deep reinforcement learning evidence cited concerns stationary problems; commerce demand is not stationary.

9Conclusion

We have described a replenishment service that keeps reorder-point and order-up-to policies and keeps their parameters current: probabilistic and coherent forecasts, a lead-time distribution, explicit service and capital targets, network-aware placement, and demand data shared with suppliers. Each part rests on published work summarised in Table 1, and Table 2 shows why pooling decisions depend on measured correlation. The next step is the policy replay on logged demand, reported with its method.