Your Planning Horizon Is Not Your Commitment Horizon

A common mistake in supply chain optimization is to confuse how far the model should look with how far the business should commit.

Suppose you place purchase orders every Monday. Your supplier has an eight-week lead time, ocean freight is involved, and demand becomes increasingly uncertain as you look farther out. Someone asks a reasonable question: how many weeks should the optimization model plan?

The discussion often goes wrong immediately.

One group argues for a short horizon because forecasts are unreliable after a few weeks. Another argues for a long horizon because the model needs to see future demand, capacity, and inventory. Both are partly right because they are answering different questions.

The model may need to look 26 weeks ahead while only committing the first week’s decisions.

That distinction is the foundation of rolling-horizon planning.

Start With the Decision

Before choosing a horizon, write down what actually becomes irreversible when the model runs.

For a purchasing problem, a simple decision variable might be

[ x_{i,t} = \text{units of item } i \text{ ordered in period } t. ]

A 26-week optimization may contain variables for all 26 weeks. That does not mean the business should transmit 26 weeks of purchase orders to suppliers.

The future variables can exist because they help the model understand the consequences of today’s decision. Only the near-term decision is executed.

Next week, the model runs again with updated inventory, demand information, supplier status, open orders, and forecasts. The old hypothetical week-two decision is discarded and replaced with a new decision based on the new state.

This is not indecision. It is a policy.

Three Horizons, Not One

Practitioners usually talk about “the planning horizon” as if there were one number. In practice, there are at least three.

The look-ahead horizon is how far the model considers future consequences.

The commitment horizon is how far decisions become operationally binding.

The information horizon describes how useful your knowledge of the future actually is.

These numbers do not need to match.

You may look ahead 26 weeks, commit one week, and have reasonably useful demand information for only six weeks. The optimization still benefits from seeing weeks 7 through 26 because inventory purchased today can survive into those periods, contracts can span them, capacity can tighten later, and end-of-horizon effects otherwise distort the answer.

The farther future should usually influence today’s decision less confidently, not disappear from the model entirely.

A Concrete Supply Chain Example

Imagine a retailer buying a seasonal product from an overseas supplier.

The state at week (t) includes on-hand inventory (I_t), outstanding purchase orders, expected arrivals, current prices, supplier capacity, and whatever demand information is available.

The model chooses orders (x_t, x_{t+1}, \ldots, x_{t+H}) over a horizon of length (H).

A simplified inventory balance is

[ I_{t+1} = I_t + A_t - D_t, ]

where (A_t) represents arrivals and (D_t) demand.

Real models add lead-time shifts, lost sales or backorders, pack sizes, minimum order quantities, budgets, capacity, expiry, transportation calendars, and other constraints.

The objective might minimize expected economic cost:

[ \mathbb{E}\left[\sum_{k=t}^{t+H} c_k x_k + h_k I_k^+ + p_k S_k\right], ]

where purchasing cost, holding cost, and shortage consequences are explicitly represented.

The optimizer solves for the entire path. Operationally, however, you may execute only (x_t).

Then reality happens.

Demand arrives. A shipment is delayed. A promotion changes. Inventory is counted again. The supplier updates capacity. The forecast distribution changes.

At (t+1), solve again.

That repeated mapping from observed state to action is more important than the frozen 26-week plan produced on Monday morning.

What Questions Should You Ask?

Before tuning the horizon, ask what decisions are reversible. A transfer recommendation that can be changed tomorrow is different from a purchase order that triggers production at a factory.

Ask when new information arrives. If forecasts and inventory positions update daily but the model runs monthly, you are throwing away information by design.

Ask what future constraints can affect today’s action. A capacity limit 12 weeks from now may matter today if replenishment lead time is ten weeks. A short model horizon can make that constraint effectively invisible until it is too late.

Ask what happens at the end of the model. If inventory remaining after the final modeled week is treated as worthless, the optimizer may artificially stop buying. If shortages after the horizon are invisible, it may understock. Terminal value matters.

Finally, ask how much the first-period decision actually changes as you extend the horizon. This is an empirical question and one of the best horizon diagnostics you can run.

Uncertainty Changes the Meaning of the Future

A long deterministic horizon can create fake precision.

If the model assumes one exact demand path for the next year, extending the horizon may simply give a wrong forecast more opportunities to influence today’s decision.

The fix is not automatically to shorten the horizon. The better fix is to represent uncertainty appropriately.

That could mean demand scenarios, probabilistic forecasts, stochastic lead times, stress cases, robust bounds, or a simulator used to evaluate candidate policies.

For scenario (s), demand becomes (D_{t,s}). The objective can evaluate expected economics across scenarios rather than pretending a single future is known.

But be careful: future decisions should not magically know which scenario occurred before that information would actually be available. Otherwise you have created a model with perfect foresight and will overestimate its value.

This is where scenario-tree structure, non-anticipativity constraints, or a simpler parameterized policy becomes important.

The MILP Trap

MILP practitioners sometimes extend the horizon until the model becomes painfully slow and then frame the problem as solver tuning.

Maybe the solver is not the problem.

Doubling the horizon can multiply variables, binaries, inventory balances, setup decisions, scenario copies, and coupling constraints. If each period contains supplier activation binaries, MOQ logic, transportation choices, or facility decisions, a longer horizon can change the computational problem dramatically.

Do not start by changing MIPGap, cuts, heuristics, or threads.

First ask whether every future decision needs the same resolution.

A useful pattern is high resolution near the decision and lower resolution farther away. Model the next eight weeks weekly, then aggregate later periods monthly. Another option is to freeze structural decisions farther out while keeping quantities flexible. You can also use a terminal-value approximation instead of modeling another 30 nearly irrelevant periods.

The mathematical model should spend detail where detail can change the action you are about to take.

How to Choose the Horizon in Practice

Do not pick 13, 26, or 52 weeks because those numbers appear in an existing planning process.

Run experiments.

Solve the model with horizons of 8, 13, 26, and 52 weeks. Record the first executable decision, objective value, runtime, optimality gap, and important constraint activity. Then replay those decisions through historical or simulated futures.

You are looking for decision stability, not merely objective stability.

If the 13-week and 26-week models produce nearly identical first-period orders and similar realized economics, the extra horizon may not buy much. If the 8-week model behaves radically differently because it cannot see a capacity bottleneck in week 10, then eight weeks is structurally too short.

The right horizon is often the shortest one that captures the economically relevant downstream consequences of today’s action, plus enough terminal treatment to avoid boundary artifacts.

Failure Modes

The first failure mode is committing the entire optimized path. A model run today produces future actions based on today’s information. Treating those actions as immutable defeats the purpose of receiving new information.

The second is using a short horizon because “the forecast is bad.” Forecast uncertainty should affect how future information is represented, not automatically erase future economics.

The third is using a huge horizon to eliminate end effects. Sometimes a good terminal-value approximation solves the actual issue much more cheaply.

The fourth is evaluating the model with hindsight. If your backtest gives each historical run the demand forecast that was created months later, your rolling-horizon policy is cheating.

The fifth is measuring only forecast accuracy. A forecast can deteriorate while the ordering policy improves. The final test is the realized economics of the decisions.

What I Would Build

For a production replenishment system, I would separate the architecture into four pieces.

First, maintain a clean state representation: inventory, open orders, lead-time state, supplier restrictions, prices, capacities, and forecast vintages as they existed at decision time.

Second, generate a probabilistic view of relevant uncertainty. Do not generate thousands of scenarios merely because you can. Use enough uncertainty representation to distinguish materially different decisions.

Third, solve a rolling optimization or evaluate a parameterized policy. Execute only the decisions that must be committed before the next planning cycle.

Fourth, replay the entire process through historical and simulated environments. Each period should reveal only the information that would have been available then.

Track realized margin, holding cost, shortage cost, write-offs, capacity violations, expedites, decision volatility, and runtime. Service level can be reported, but it should not automatically become the economic objective.

The Practical Rule

A supply chain plan is a temporary consequence of the information you have today.

The real analytical product is the rule that tells you what to do when the state changes tomorrow.

So let the model look far enough ahead to understand the consequences of today’s action. Commit only as far as operational reality requires. Then observe, update, and solve again.

That is a much more useful way to think about planning than arguing whether the forecast should be 13 weeks or 52.