Decision Stability Is a Cost

Optimization models have an annoying habit: they can improve the objective every day while making the operation worse.

Monday’s model says buy 12,000 units from Supplier A. Tuesday gets a slightly different forecast and says buy 9,000 from A and 3,000 from B. Wednesday moves the volume back to A. Thursday pulls an order forward. Friday pushes it out again.

Every solve is individually defensible. The sequence of decisions is terrible.

People sometimes call this planning nervousness, churn, or instability. The usual response is to add a freeze window and prevent the optimizer from changing anything near term. That can work, but it is a blunt instrument. A frozen bad decision is still a bad decision.

The more useful framing is economic: changing a decision has a cost, and that cost belongs in the decision problem.

That cost may be literal money. It may also be supplier disruption, planner effort, expediting risk, lost credibility, production resequencing, or the consumption of organizational attention. Once we treat stability as an economic property rather than an aesthetic preference, the modeling gets much cleaner.

Start With the Decision, Not the Schedule

Suppose a weekly purchasing model chooses quantities

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

At today’s solve, there is already a previously communicated plan

[ \bar{x}_{i,t}. ]

A basic deterministic model might minimize purchasing, holding, shortage, and transportation cost:

[ \min ; C(x). ]

Nothing in that objective cares whether the new plan is radically different from yesterday’s plan. If moving 5,000 units from week 4 to week 3 improves the modeled objective by $11, the solver will happily do it.

Operationally, that $11 may be meaningless. The supplier may already have scheduled labor. A buyer may need to issue a change order. A truck reservation may move. Someone may spend an hour explaining the change.

The model did exactly what we asked. We just failed to model the decision correctly.

Before adding anything, ask:

• Which decisions have already been communicated externally?
• Which decisions are physically irreversible?
• Which can be changed, but only at a real cost?
• Does changing quantity matter, timing matter, or both?
• Is the first change expensive while subsequent units are cheap?
• Does the cost increase as execution gets closer?
• Are planners currently overriding the model mainly to preserve stability?

These questions separate three concepts that are often mixed together: irreversibility, commitment, and preference for stability.

Hard Commitment and Soft Stability Are Different

If a purchase order has been placed and cannot be cancelled, that is not a stability preference. It is state.

If the first two weeks of production are physically locked, those variables should be fixed or constrained to what remains feasible.

For example:

[ x_{i,t} = \bar{x}_{i,t}, \qquad t \in \mathcal{F} ]

for a truly frozen set of periods (\mathcal{F}).

But many real planning rules are softer than people admit. “Do not change the next four weeks” often really means “changes inside four weeks are painful and should require a good reason.”

Those are different models.

If a change is possible when the economics are strong enough, representing it as impossible throws away information. A shortage crisis, supplier outage, sudden demand spike, or major cost change may justify disruption.

A good model should be able to make that trade.

Model the Change Explicitly

A simple approach is to penalize deviation from the previous plan.

Introduce nonnegative variables

[ d^+{i,t} \ge x{i,t} - \bar{x}_{i,t} ]

and

[ d^-{i,t} \ge \bar{x}{i,t} - x_{i,t}. ]

Then

[ d^+{i,t} + d^-{i,t} = |x_{i,t} - \bar{x}_{i,t}| ]

at optimum when deviation has a positive cost.

The objective becomes

[ \min ; C(x) + \sum_{i,t} \lambda_{i,t}(d^+{i,t}+d^-{i,t}). ]

The coefficient (\lambda_{i,t}) is the economic cost assigned to changing one unit of the previous plan.

This immediately gives the optimizer a hurdle. It will change the plan when the expected benefit exceeds the disruption cost.

That is already better than an arbitrary freeze fence.

But a linear per-unit penalty is often not the real cost structure.

The First Change May Be the Expensive Part

Suppose changing a supplier order requires a planner to reopen the PO, contact the supplier, update transportation, and document the exception. Whether the quantity changes by 100 or 120 units may not matter much. The expensive part is touching the order at all.

Introduce a binary variable

[ y_{i,t}=1 ]

when the existing decision is changed.

Then link deviation to the binary with a valid bound (M_{i,t}):

[ d^+{i,t}+d^-{i,t} \le M_{i,t}y_{i,t}. ]

The objective can include

[ K_{i,t}y_{i,t} + \lambda_{i,t}(d^+{i,t}+d^-{i,t}). ]

Now there is a fixed cost to opening the decision plus a marginal cost for the magnitude of the change.

This often matches operations much better.

As always, do not use a ridiculous generic Big-M. Derive (M_{i,t}) from actual order, capacity, inventory, or demand bounds. A stability feature should not destroy the formulation you spent months making fast.

Timing Changes Need Their Own Treatment

Quantity deviation is not enough when the business mostly cares about moving orders between periods.

Consider these two plans:

• Old plan: 1,000 units in week 5.
• New plan: 1,000 units in week 6.

Total quantity is unchanged, but operationally the decision changed.

One option is to compare the entire time-indexed vector as above. Another is to explicitly model rescheduling when the application requires traceability: how much previously planned supply was pulled in, pushed out, cancelled, or newly added.

For example, define flows from old planned period (s) to new period (t):

[ r_{i,s,t} = \text{quantity rescheduled from } s \text{ to } t. ]

Then the disruption cost can depend on distance:

[ \sum_{i,s,t} c_{i,s,t}r_{i,s,t}. ]

Moving something one week may be cheap. Moving it eight weeks may effectively be a cancellation and re-order. Pulling an order forward may be much more expensive than pushing it out.

Do not build this formulation unless the distinction matters. More detailed mathematics is not automatically better modeling. Use the simplest representation that captures the actual decision cost.

Stability Cost Should Usually Increase Near Execution

A change six months out is often cheap. A change tomorrow can be chaos.

That suggests time-dependent penalties:

[ \lambda_{i,1} > \lambda_{i,2} > \cdots > \lambda_{i,T}. ]

The exact shape should come from the operation, not from mathematical convenience.

A simple structure might be:

• days 0–7: physically frozen;
• days 8–21: high change cost;
• days 22–42: moderate change cost;
• beyond 42 days: low or zero change cost.

This creates a soft commitment horizon around the truly hard frozen horizon.

It also gives a much more useful interpretation than “the planning horizon is 26 weeks.” The model may look ahead 26 weeks while having very different degrees of commitment across those weeks.

Uncertainty Is Where Stability Gets Interesting

In a deterministic model, replanning churn often comes from forecast updates. But a deeper issue is that the optimizer is reacting to one forecast as if it were truth.

Suppose expected demand moves from 100 to 103. A deterministic model may cross a breakpoint and change the order from 100 to 120 because of a case pack. Tomorrow the forecast moves back to 99 and the order returns to 100.

The forecast barely changed. The decision jumped.

A probabilistic model can reveal whether the apparent improvement is robust across plausible futures.

Let (\omega) index demand, lead-time, or supply scenarios. Instead of comparing plans on one forecast, evaluate

[ \mathbb{E}_{\omega}[C(x,\omega)] + S(x,\bar{x}), ]

where (S) is the stability cost.

Now a plan change should earn its way across the uncertainty distribution.

This matters because small deterministic objective improvements are often noise. If two decisions have nearly identical expected economics, stability is a perfectly legitimate tie-breaker.

The existing plan has one enormous advantage: the organization has already started acting on it.

Stability Is Not the Same as Robustness

These ideas are related but should not be confused.

A robust decision performs acceptably across uncertain outcomes. A stable decision does not change unnecessarily across planning runs.

You can have a robust but unstable policy if repeated solves select different near-equivalent actions. You can also have a very stable policy that is consistently bad.

The goal is not minimum churn. The goal is economically justified churn.

If the world changes materially, the decision should change.

Measure the Value of the Change

A useful production system should log more than the new solution.

For every meaningful plan change, record at least:

• previous decision;
• new decision;
• absolute and percentage change;
• time until execution;
• objective value of the previous plan under current information;
• objective value of the new plan under current information;
• expected economic improvement;
• modeled disruption cost;
• constraints that became binding or stopped binding;
• major state or forecast changes that drove the decision.

The key comparison is not today’s optimal objective versus yesterday’s objective. Those were solved with different information.

Re-evaluate yesterday’s still-feasible plan using today’s state and information. Then compare it with today’s candidate plan.

That gives a much cleaner quantity:

[ \Delta V = V(\text{new plan} \mid \text{today}) - V(\text{old plan} \mid \text{today}). ]

If (\Delta V) is $40 and changing the plan creates hundreds of dollars of real operational cost, do not change it.

If (\Delta V) is $80,000, the model should probably be allowed to upset somebody.

What Metrics Should You Track?

Do not optimize stability using a single generic “number of changes” KPI.

Track economics and churn together.

Useful metrics include:

Decision value

• expected profit or total economic cost;
• shortage and lost-sales cost;
• inventory and working-capital cost;
• transportation and expedite cost;
• risk measures where appropriate.

Stability

• percentage of near-term decisions changed;
• units changed;
• number of orders touched;
• number of suppliers affected;
• average reschedule distance;
• pull-ins versus push-outs;
• churn by weeks-to-execution.

Decision quality

• realized value after execution;
• regret versus reasonable alternatives;
• frequency of changes later reversed;
• planner override rate;
• overrides specifically attributed to stability concerns.

That last group is important. A system that changes 20% fewer orders but loses millions in margin is not better. Neither is a model that gains 0.01% in modeled cost while creating a daily fire drill.

Tune Stability in Simulation

The penalty coefficients are policy parameters. Treat them that way.

Do not choose (\lambda=5) because it “seems conservative.”

Build a replay or simulation that mimics repeated planning cycles:

1. Start from a historical state.
2. Give the policy only information that was available at that time.
3. Solve and record the decision.
4. Advance the system.
5. Reveal new demand, lead-time, inventory, and forecast information.
6. Re-solve using the previous decision as the reference plan.
7. Charge both operational outcomes and realistic change costs.
8. Repeat over many periods and scenarios.

Then test candidate penalty structures.

The important part is repeated replanning. A one-shot simulation cannot measure planning stability because there is no previous plan to destabilize.

You may find that the best policy has almost no penalty far out, a moderate penalty in the middle, and a steep penalty near execution. You may find different suppliers need different values. You may find that fixed change costs matter much more than per-unit costs.

Let the evidence tell you.

Watch for Endogeneity

There is a subtle implementation problem here.

The previous plan is not external data. It was produced by your own policy.

If the model makes a strange decision today, tomorrow’s stability penalty can encourage it to preserve that strange decision. Bad decisions can become sticky.

That is why stability should not be infinitely expensive and why true state must be separated from previous recommendations.

Ask of every component of (\bar{x}):

• Has this actually been committed?
• Has anyone acted on it?
• Is there a real consequence to changing it?
• Or is it merely yesterday’s suggestion from the same optimizer?

A recommendation nobody saw should usually have little or no commitment value.

Common Failure Modes

Freezing too much

A six-week freeze window is easy to explain and easy to code. It can also make the optimizer useless exactly when conditions change.

Freeze what is truly irreversible. Price the rest.

Penalizing all changes equally

Changing next week’s factory schedule is not the same as changing a tentative order four months out. Use state- and time-dependent costs when the business distinction is real.

Using stability to hide a bad model

If decisions swing because of bad data, discontinuous business logic, weak formulations, solver tolerances, or unstable forecasts, adding a giant change penalty can hide the symptom without fixing the cause.

Inspect why the solution moves.

Ignoring discrete structure

MOQs, case packs, truckloads, setup binaries, and price breaks naturally create jumps. A tiny state change can legitimately cross a decision boundary. Do not expect continuous-looking plans from a discrete operation.

Measuring objective improvement incorrectly

Comparing Monday’s objective with Tuesday’s objective is usually meaningless because the state and information changed. Reprice the old plan under the new information.

Treating planner overrides as noise

If experienced planners repeatedly undo near-term changes, investigate. They may be protecting an unmodeled cost that the objective does not see.

That is model-discovery data.

A Practical Production Architecture

A mature planning system should carry decision history as part of state.

At each solve:

1. Read current inventory, pipeline, commitments, capacities, prices, and other physical state.
2. Read the latest probabilistic information about uncertain quantities.
3. Read the last communicated or committed plan.
4. Classify prior decisions into irreversible, costly-to-change, and freely revisable.
5. Build the optimization model with hard commitment constraints and soft stability costs.
6. Solve the candidate plan.
7. Re-evaluate the prior feasible plan under current information.
8. Log the economic reason for material changes.
9. Publish only the decisions relevant to the current execution cycle.
10. Feed realized outcomes and overrides back into policy evaluation.

This architecture also makes debugging easier. When someone asks, “Why did the model change this order again?” you should be able to answer with economics, not “because the solver found a different optimum.”

What to Do in Practice

Start small.

Pick one decision family where churn is genuinely painful: supplier orders, production quantities, transfer plans, labor schedules, or transportation bookings.

Identify what is actually irreversible. Fix those decisions.

For everything else, estimate the cost of changing the prior plan. Do not obsess over perfect estimates initially. Even rough economics are better than pretending the cost is zero or infinity.

Add a simple deviation formulation. Log how often it binds and what economic improvements are being rejected. Replay historical planning cycles if you can. Then refine the structure only where the evidence says it matters.

The objective is not to make the optimizer calm.

The objective is to make it understand that decisions live in an operation with memory.

Yesterday’s plan changes today’s state before a single unit moves, because people start coordinating around it. A production optimization system that ignores that fact will keep rediscovering mathematically attractive plans that the business learns not to trust.

A good policy changes its mind when the world changes enough to justify it.

Not every time the third decimal place moves.