Measure Stability Before You Constrain It

A planning team says the new optimization model needs a stability constraint.

That sounds reasonable. Purchase orders should not whip around every time the forecast moves by 2%. Production schedules should not be rebuilt for no economic reason. Planners should not spend Monday explaining a recommendation that disappears on Tuesday.

But there is a step people skip surprisingly often:

Measure the instability before you constrain it.

If you add a stability constraint first and then report that the model is stable, you have learned almost nothing. You proved that a constraint can constrain.

The useful question is whether the underlying decision system is naturally stable, where it is unstable, what causes the instability, and whether the changes are economically meaningful.

That distinction matters because stability can be a property of the model, a consequence of the data, a requirement of the operation, or a bandage over a modeling defect. Those are four different problems.

Start With the Decision Sequence

Suppose a purchasing model runs every Monday. For item (i), it recommends purchase quantities

[ x_{i,t}^{(r)} ]

where (t) is the planned arrival or order period and (r) is the planning run.

Last week’s plan was

[ x_{i,t}^{(r-1)}. ]

This week’s plan is

[ x_{i,t}^{(r)}. ]

The first mistake is to ask only whether the objective value changed.

The business does not execute the objective value. It executes the decision vector.

Two runs can have nearly identical objective values and completely different purchase orders. They can also have noticeably different objective values while producing almost the same executable near-term decisions.

So the object you need to compare is the decision itself.

Before writing a stability constraint, answer these questions:

Which decisions are actually communicated or executed?
At what grain does the operation experience a change: units, cases, trucks, purchase orders, suppliers, or dates?
Which periods are still editable?
Which changes require human work?
Which changes create supplier or operational disruption?
Which changes are economically immaterial?
Is the concern near-term churn, total-horizon churn, or both?
Are we measuring recommendations or only decisions that cross an execution threshold?

If the team cannot answer those questions, it is too early to choose a stability formulation.

Stability Is a Metric Before It Is a Constraint

A basic quantity metric is absolute change:

[ S_{\text{abs}} = \sum_{i,t} \left|x_{i,t}^{(r)} - x_{i,t}^{(r-1)}\right|. ]

This tells you how many units moved in aggregate.

It is useful, but crude. Moving 10,000 units on a million-unit business may be irrelevant. Moving 200 units on a low-volume critical component may be a major event.

A normalized version is often more interpretable:

[ S_{\text{rel}} = \frac{\sum_{i,t}|x_{i,t}^{(r)}-x_{i,t}^{(r-1)}|} {\epsilon + \sum_{i,t}x_{i,t}^{(r-1)}}. ]

Now you have a churn rate rather than a raw unit count.

But even that can hide the operational reality. A plan can move the same quantity from week 6 to week 7 and look highly unstable by element-wise comparison even though the supplier barely cares. Another plan can keep total quantity constant but move an order across a contractual cutoff and create a real problem.

The metric has to reflect the decision interface.

Measure More Than One Kind of Churn

For purchase planning, I usually want several views.

Quantity churn

How much recommended volume changed?

[ C_Q = \sum_{i,t}|x_{i,t}^{(r)}-x_{i,t}^{(r-1)}|. ]

Timing churn

How much volume moved across periods?

A simple implementation can compare cumulative quantities through each period:

[ C_T = \sum_{i,t}\left| \sum_{\tau \le t}x_{i,\tau}^{(r)} - \sum_{\tau \le t}x_{i,\tau}^{(r-1)} \right|. ]

Cumulative comparison is useful because moving 1,000 units from week 4 to week 5 should look different from deleting the 1,000 units entirely.

Activation churn

Did the model create or remove an order?

Define

[ y_{i,t}^{(r)} = \mathbf{1}{x_{i,t}^{(r)} > 0}. ]

Then measure

[ C_A = \sum_{i,t}|y_{i,t}^{(r)}-y_{i,t}^{(r-1)}|. ]

This can matter more than unit churn when every new purchase order has a fixed administrative or transportation consequence.

Supplier churn

If volume moves between suppliers, measure that explicitly. A stable item-level quantity can still hide a completely different sourcing plan.

Near-term churn

Weight changes by proximity to execution:

[ C_N = \sum_{i,t}w_t|x_{i,t}^{(r)}-x_{i,t}^{(r-1)}|, ]

with larger (w_t) for periods close to execution.

Changing week 2 should usually count more than changing week 30.

There is no universal stability metric. There is only a metric that is or is not aligned with the operational decision.

Establish the Unconstrained Baseline

Now run the model without the proposed stability mechanism.

This is the baseline people often skip.

Take a sequence of realistic historical planning dates. Reconstruct the information that would have been available at each date: forecast vintage, inventory state, open orders, costs, capacities, lead times, outages, and business rules. Solve the model exactly as it would have been solved then.

For each consecutive run, record the stability metrics.

Do not use today’s forecast to recreate last quarter’s planning runs. That removes one of the main sources of real-world change and makes the model look artificially stable.

The output should not be one average stability number. Look at the distribution.

You want to know:

median churn,
90th and 99th percentile churn,
churn by decision horizon,
churn by supplier and item class,
churn around forecast revisions,
churn around capacity changes,
churn around outages,
churn when the economic recommendation is close to a breakpoint.

A model that is stable 95% of the time and makes large rational changes during disruptions is a very different system from one that randomly reshuffles purchase orders every week.

The average can hide that distinction.

Separate Natural Stability From Forced Stability

This is the key experiment.

Run the same historical sequence twice.

In experiment A, use the economic model without a stability constraint.

In experiment B, add the proposed stability mechanism.

Then compare at least three things:

decision churn,
modeled economic value,
realized or simulated downstream performance.

If experiment A is already stable, the new constraint may be solving a problem that does not exist.

If experiment A is unstable but the instability is economically valuable, a hard stability constraint may make the system worse.

If experiment A is unstable and the changes have almost no economic value, then you have evidence that a stability mechanism is useful.

That is a much stronger argument than saying, “The business wants stable POs.”

Put a Price on the Change

A useful diagnostic is the economic gain from replanning.

Let the old plan, updated only where physically necessary, have objective value

[ J(\bar{x}). ]

Let the new optimized plan have value

[ J(x^*). ]

For a minimization problem, define the modeled benefit of changing as

[ \Delta J = J(\bar{x}) - J(x^*). ]

Now compare (\Delta J) with the amount of churn.

A practical metric is economic value per changed unit:

[ V_C = \frac{\Delta J}{\epsilon + C_Q}. ]

You can define similar measures per changed order, supplier switch, or shifted truck.

Suppose the optimizer changes 80 purchase-order lines to save an expected $430. That is a very different conversation from changing three lines to avoid an expected $2.4 million shortage.

This is where stability stops being a vague preference and becomes an economic decision.

Look for Breakpoints

Discrete planning models can be unstable for perfectly legitimate mathematical reasons.

Suppose a vendor has a 10,000-unit MOQ. The economics of ordering 9,999 units and 10,000 units are not smooth. One extra unit of expected need can activate an entire order block.

Likewise for truck capacities, pack sizes, supplier activation costs, tiered pricing, production setups, and contractual thresholds.

If the state repeatedly sits near one of these breakpoints, small changes in inputs can create large changes in the recommended plan.

That is not necessarily solver noise. It may be the real economics of the decision.

Log the distance to important thresholds. For an MOQ (M_v), for example, track how close the unconstrained desired quantity is to the activation boundary.

If most instability occurs near known economic breakpoints, a generic stability penalty can hide the symptom without improving the underlying decision logic.

You may instead need better treatment of uncertainty around the breakpoint.

Test Input Sensitivity Directly

A stability analysis should deliberately perturb the inputs.

Change the demand forecast by ±1%, ±5%, and ±10%.

Shift lead time by a week.

Change available capacity.

Move inventory by one case pack.

Change a cost coefficient within its estimation error.

Then resolve.

You are trying to estimate a local decision response:

[ \Delta x \approx f(\Delta s), ]

where (s) is the observed state and (x) is the decision.

A model whose decisions change smoothly for ordinary input movement and sharply only at meaningful business thresholds is behaving differently from a model whose decisions flip everywhere.

This sensitivity map is often more useful than a single stability KPI.

Do Not Confuse Solver Variability With Model Instability

There is another failure mode: multiple solutions have almost identical objective values.

A MILP may find one sourcing pattern on Monday and a different one on Tuesday even when the economics are nearly indistinguishable. Small coefficient changes, solver version changes, thread timing, or a different incumbent can expose another near-equivalent solution.

The business experiences churn even though the model sees almost no economic difference.

This is a strong case for tie-breaking or secondary objectives.

For example:

[ \min C(x) ]

first, then among solutions within an acceptable economic tolerance, minimize deviation from the prior plan.

Conceptually:

[ \min C_{\text{change}}(x,\bar{x}) ]

subject to

[ C(x) \le C^* + \delta. ]

Here (\delta) is an explicit amount of economic value you are willing to trade for stability.

This is much cleaner than pretending stability and economics are the same objective.

It also gives the business a statement it can understand: “We preserve the previous plan when doing so costs less than $X.”

Uncertainty Changes What Stability Means

A deterministic stability test is incomplete when the underlying problem is uncertain.

Suppose two order quantities have almost identical expected cost, but one performs much better in high-demand scenarios. A small forecast revision may rationally switch the preferred decision.

You need to distinguish instability caused by noisy point estimates from instability caused by meaningful changes in the distribution of outcomes.

For a candidate policy (\pi), evaluate the decision under scenarios (\omega):

[ J(\pi) = \mathbb{E}_{\omega}[C(\pi,\omega)]. ]

Then evaluate both economic performance and decision churn across sequential planning runs.

Use common random numbers when comparing alternative stability settings in simulation. If policy A and policy B are evaluated on different random demand paths, simulation noise can look like policy improvement.

The goal is not the most stable plan. The goal is the best decision policy after accounting for the real cost of unnecessary change.

Stability Can Expose a Modeling Bug

Sometimes high churn is telling you the model is wrong.

Common causes include:

the planning horizon cuts off meaningful future costs,
terminal inventory is valued incorrectly,
holding cost is charged inconsistently across runs,
open orders are reconstructed differently each day,
forecast aggregation changes with calendar boundaries,
an MOQ or pack rule is applied at the wrong level,
lead-time logic moves decisions between buckets,
rounding happens outside the optimization model,
a supposedly fixed business rule changes with data extraction,
the objective contains large arbitrary penalties that dominate real economics.

Adding a stability constraint can make the output look better while leaving the defect intact.

That is why unconstrained stability is a diagnostic.

If the model changes dramatically, ask why before preventing the change.

Measure Stability at the Commitment Boundary

A 52-week plan can change dramatically in weeks 30 through 52 without creating any operational pain.

Meanwhile, a small change tomorrow can create chaos.

Do not report one full-horizon churn number and call it stability.

Partition the horizon into decision zones:

committed,
near-term editable,
tactical,
long-range planning.

Then report churn separately.

If the first four weeks are the actual purchase-order commitment zone, that is where stability deserves the highest scrutiny.

The far horizon still matters because it influences near-term decisions, but it should not dominate the stability KPI simply because it contains more periods.

Production Logging Matters

If stability matters enough to constrain, it matters enough to log.

For every planning run, persist:

run timestamp,
state snapshot or state version,
forecast vintage,
prior plan version,
new plan version,
solver status and objective,
quantity churn,
timing churn,
activation churn,
near-term churn,
economic gain from replanning,
number of decisions changed,
largest individual changes,
reason codes for known state changes,
stability-constraint or penalty parameters,
whether a planner overrode the recommendation.

Without this history, six months later the team will know that planners complain about instability but will not know which model version, forecast change, or business condition caused it.

A production optimization system needs an audit trail of decisions, not just solver logs.

Failure Modes

Measuring only after the stability constraint is added

You cannot tell whether the model was naturally stable or whether you simply forced the answer.

Using only objective-value stability

A stable objective does not imply stable decisions.

Using only total-horizon quantity churn

It ignores timing, activation, supplier switches, and commitment proximity.

Treating every change as bad

A model should change when the world changes enough to justify it.

Hard-freezing what is actually a preference

If a decision can change at a cost, model or evaluate that cost rather than declaring the change impossible.

Ignoring near-equivalent solutions

If many plans have nearly identical economics, use explicit tie-breaking instead of accepting arbitrary churn.

Hiding model defects with penalties

A stability term can make a broken model look calm.

Evaluating on reconstructed data with leakage

If historical runs use information that was unavailable at the time, your stability estimate is not representative of production.

A Practical Stability Test

Here is the workflow I would use before adding a stability constraint to a production planning model.

1. Define the executable decision. Identify exactly what the business experiences as a change.

2. Reconstruct the prior plan. Use the actual previous recommendation or committed plan, not an approximation created from today’s state.

3. Choose several stability metrics. Include quantity, timing, activation, and near-term churn where relevant.

4. Run the unconstrained model across historical planning vintages. Establish natural stability first.

5. Segment the results. Look by horizon, supplier, item class, and business event rather than only at the average.

6. Measure the economic value of each replan. Identify high-churn, low-value changes.

7. Perturb inputs. Find the thresholds and state variables that actually drive decision changes.

8. Investigate unexplained churn. Check horizon effects, state construction, rounding, MOQs, costs, and near-equivalent solutions.

9. Add the lightest stability mechanism that solves the demonstrated problem. This may be a tie-breaker, change cost, tolerance band, commitment rule, or hard constraint.

10. Re-run the same evaluation. Quantify the reduction in churn and the economic price paid for it.

That last number matters.

If a stability mechanism cuts near-term PO churn by 70% and costs 0.03% of expected economics, that may be an excellent trade.

If it cuts churn by 8% and materially increases shortage risk, it probably is not.

What to Do in Practice

Do not start the stability conversation by debating penalty coefficients or writing absolute-value constraints.

Start by plotting the decisions from consecutive runs.

Show what changed. Show where it changed. Show what input moved. Show how much economic value the new plan gained. Show whether the change crossed a real operational threshold.

Then ask whether the instability is actually undesirable.

Sometimes the answer will be yes, and you should model the cost of change.

Sometimes the answer will be that the model is already stable enough.

Sometimes the answer will be that the optimizer is exposing a bad state pipeline, a horizon artifact, or a poorly specified objective.

And sometimes the answer will be that the business is asking the model to ignore new information simply because the old plan feels familiar.

Those cases should not receive the same constraint.

Stability is an outcome to understand before it becomes a rule to enforce.