An Optimal Solution Is Not the Only Optimal Solution

The Solver Gave You an Answer. That Does Not Mean It Gave You the Answer.

A supply chain model decides how much to produce at each plant. Plant A and Plant B have the same modeled cost, both have capacity, and the customer does not care which one ships the product.

The model sends everything through Plant A.

The team assumes the optimizer discovered that Plant A is better.

It did not. The model was indifferent. Plant A was simply one optimal solution among many.

A mixed-integer linear program can have one optimal objective value and many different optimal solutions. The solver is generally asked to find an optimal solution, not to characterize every decision vector that achieves the same objective.

This becomes especially confusing when presolve is involved. You see variables removed or fixed and assume their reported values must be the same in every possible optimum.

That conclusion is not generally valid.

A solver can remove a variable because it is redundant, substitute it through another relationship, aggregate it, or reconstruct it after solving. None of that automatically means the value you later see is shared by every optimal solution of the original model.

Optimality belongs to the objective value. The returned variable values are one witness of that optimality.

If the variable values themselves matter operationally, you need to model that fact.

Frame the Real Decision Before You Blame the Solver

Suppose a company must allocate 10,000 units across fulfillment centers. Let x_i be units allocated to location i, c_i the modeled cost per unit, and u_i available capacity.

The model minimizes total cost:

min sum_i c_i x_i

subject to total allocation equaling 10,000 and each location staying within capacity.

If two locations have exactly the same modeled cost and enough capacity, shifting units between them may leave the objective unchanged.

The model is not broken. It is telling you that, according to the economics you encoded, those allocations are equivalent.

That should trigger a better question: Are they actually equivalent to the business?

Maybe one allocation creates more workload volatility. Maybe it disrupts yesterday’s plan. Maybe it leaves one facility with no contingency capacity. Maybe every change triggers manual work.

If those consequences matter but are absent from the objective and constraints, the solver is correct to ignore them.

Before changing parameters, ask:

1. Which decisions can vary without changing the primary objective?
2. Does the business care which equivalent solution is selected?
3. Are there hidden costs in changing yesterday’s plan?
4. Are operational preferences missing from the model?
5. Is the tie real, or caused by rounded coefficients and missing economics?
6. Do downstream systems assume the solution is unique when it is not?

These questions are more useful than asking why the solver chose the wrong optimum.

What Multiple Optimal Solutions Actually Mean

Consider maximizing x_1 + x_2 subject to x_1 + x_2 <= 10 and both variables being nonnegative.

Every point with x_1 + x_2 = 10 is optimal. The objective value is always 10, but the decision could be (10,0), (0,10), (4,6), or thousands of other combinations.

The optimizer only needs to return one of them.

In a MILP, the alternatives may be discrete. You might have 200 production schedules with exactly the same modeled profit. One uses Line 1 on Tuesday. Another uses Line 2 on Wednesday. Another changes sourcing but preserves the same total economics.

Multiple optima are common with identical costs, interchangeable resources, coarse objective coefficients, symmetric facilities, equivalent fixed-charge combinations, or integer rounding that collapses small economic differences.

Large operational models often have far more degeneracy than the team realizes.

Presolve Does Not Mean What Many People Think It Means

Presolve transforms the model into an equivalent problem that is easier to solve. It may remove redundant constraints, tighten bounds, fix variables, substitute variables, aggregate rows and columns, detect implied relationships, or eliminate variables whose values can later be reconstructed.

Suppose the original model contains x + y = 10. The solver may eliminate y and solve in terms of x, reconstructing y = 10 - x later.

That does not mean y has one universal value across all optimal solutions. Its value depends on the selected value of x.

Now consider a variable z with z >= 1 and z <= 1. Here z equals 1 in every feasible solution and therefore every optimal solution.

Those are very different cases.

A presolve log that says variables were removed does not, by itself, tell you which interpretation applies. Some values are structurally unique. Some are reconstructed from remaining variables. Some disappear because they are irrelevant to the optimization.

Do not infer global uniqueness from presolve elimination.

If you need to know whether a variable has the same value across all optimal solutions, test that question directly.

How to Test Whether a Decision Is Unique

Suppose the solver returns optimal objective value z-star, and you care about variable x_j.

First solve the original model and record z-star. Then constrain the model to remain optimal, allowing for an appropriate numerical tolerance epsilon.

For a minimization model, require the original objective to stay below z-star + epsilon.

Now solve two additional problems:

• minimize x_j
• maximize x_j

subject to the original constraints and the optimality restriction.

If the minimum and maximum are the same, the variable is fixed across the optimal set within your tolerance. If they differ, multiple optimal or near-optimal values exist for that decision.

For a handful of important variables, this is extremely useful. For millions of variables, solving two additional models per variable is obviously impractical. Focus on decisions with operational consequences: which supplier is activated, which plant makes a product, which orders are expedited, which customer is shorted, or which week receives production.

You do not need to prove uniqueness for every auxiliary variable.

The Better Question Is Usually Stability

Suppose two plans have exactly the same modeled cost.

Plan A changes 800 purchase orders from yesterday’s recommendation. Plan B changes 12.

The model is indifferent. Operations is not.

The right response is not to hope the solver returns Plan B. The right response is to represent the preference.

A clean approach is lexicographic optimization.

Stage 1: Optimize the primary economics

Minimize the true economic cost C(x) and obtain the best value C-star.

Stage 2: Preserve primary quality and optimize stability

Require C(x) <= C-star + epsilon, then minimize deviation from the previous plan, such as:

sum_i |x_i - x_i_previous|

Now the model says what the business means:

1. Do not materially damage the economics.
2. Among economically equivalent plans, prefer the stable one.

This is usually better than hiding a tiny arbitrary weight inside one blended objective. If one objective is truly primary and another is a tie-breaker, model them as priorities.

Supply Chain Models Are Full of Hidden Tie-Breakers

A production planner may say, “Either line can make it.”

Then the model switches the product between lines every day.

Suddenly the planner says, “Not like that.”

Human operators carry unwritten preferences that the model does not know: keep products on their usual lines, avoid opening a supplier for a tiny quantity, preserve scarce capacity for uncertain future demand, consolidate orders when economics are close, and avoid changing a plan already communicated to operations.

These are not cosmetic concerns. They are part of the decision.

A useful policy can be viewed as a mapping from current state, current information, and policy parameters to an action. If the primary model has many equivalent solutions, tie-breaking logic becomes part of that policy.

Two systems with the same cost objective can behave very differently because they resolve indifference differently.

That matters in repeated decision systems. A one-time arbitrary choice may be harmless. A daily optimizer that makes arbitrary choices can create constant operational churn.

Uncertainty Makes Indifference More Dangerous

Two plans can be equal under a deterministic model and very different under uncertainty.

Suppose two inventory allocations have the same expected modeled profit. Plan A concentrates all spare stock in one region. Plan B spreads some stock across regions.

Under the point forecast, they tie. Under uncertain demand, Plan B may preserve more optionality.

The deterministic optimizer did not necessarily select the wrong optimum. The objective may have collapsed uncertainty into a single number and erased the distinction.

Evaluate tied or near-tied solutions across the same demand, lead-time, and disruption scenarios. Compare expected lost sales, tail shortage, expedite frequency, unused capacity under disruption, inventory imbalance, and recovery time after forecast error.

A deterministic tie is often a signal to ask whether the model is missing an uncertain consequence.

Do not automatically add stochastic complexity. First determine whether the alternatives actually behave differently under plausible uncertainty. Use common random numbers when comparing them so the difference reflects the decisions rather than simulation noise.

Constraints Can Create Accidental Equivalence

Suppose a supplier MOQ is satisfied, but many SKU combinations have identical objective contribution because the model uses the same unit margin or shortage penalty across products.

The solver may choose a strange mix that satisfies the mathematics but makes no operational sense.

Before adding tie-breakers, inspect whether the economics are too coarse. Are holding costs differentiated by product? Are shortage costs actually equal? Is shelf life represented? Do products consume different amounts of scarce cube or labor? Is future flexibility valuable?

A tie-breaking objective should not cover up missing primary economics.

First make the main objective economically credible. Then resolve genuine indifference.

Metrics That Matter Beyond Objective Value

If your model runs repeatedly, track more than cost, profit, and MIP gap.

Track decision churn: how many decisions changed from the previous run?

Track magnitude of change: the total absolute difference between today’s decision and the previous plan.

Track structural churn: how many suppliers, lanes, facilities, or production lines switched status?

Track the economic regret of stability: how much primary objective value did you sacrifice for a more stable plan?

Also measure near-optimal flexibility. How much can important decisions vary while remaining within 0.1%, 0.5%, or 1% of the best objective?

The exact optimum may be fragile while the near-optimal region is huge. A business may prefer a solution that is 0.05% worse in modeled cost but dramatically easier to execute.

That is not rejecting optimization. It is optimizing the decision the business actually has to live with.

Implementation Notes

Keep a clean model-building path. Alternate-optimum analysis is hard to debug if the only available model object has been mutated by temporary constraints and objective changes.

Use explicit tolerances. “Same objective” needs a numerical definition tied to business scale and solver numerics.

Separate primary economics from preferences. Do not mix core economics, stability, symmetry breaking, and cosmetic preferences into one unexplained weighted objective.

Use symmetry-breaking constraints carefully. They can improve solve time by removing equivalent representations, but do not remove alternatives that are operationally different just because the current objective values them equally.

Log the full tie-breaking process: primary objective value, secondary objective value, allowed degradation, number of changed decisions, solve status for each stage, and whether a fallback was used.

Finally, test with perturbed inputs. Slightly change costs, forecasts, or capacities and observe the decision. If tiny input changes create massive plan changes with almost no economic difference, you likely have a stability problem.

Common Failure Modes

Assuming the returned solution is economically preferred

The solver may have selected one of many equivalent solutions because of internal algorithmic details. Do not invent a business explanation after the fact.

Assuming presolve-fixed means fixed across all optima

Presolve transformations are not a uniqueness certificate.

Adding random epsilon costs everywhere

This can make results reproducible, but it can also create fake economics and numerical problems. If the preference is real, model it clearly.

Forcing uniqueness for no reason

Not every variable needs a unique value. Auxiliary and accounting variables may vary harmlessly.

Ignoring repeated-decision behavior

An arbitrary optimum may be fine once. Arbitrary switching every morning is not.

Using stability to preserve a bad plan

A secondary objective should not make yesterday’s decision sacred. Preserve stability only after protecting primary economics within an explicit tolerance.

Confusing reproducibility with correctness

A fixed seed or deterministic setting can make the same solution appear every run. That does not mean the solution is uniquely optimal or operationally preferred.

What to Do in Practice

When a solver returns a surprising optimal solution:

1. Verify the primary economics. Make sure the objective contains the costs and values that actually distinguish decisions.
2. Check for genuine indifference. Ask whether multiple operational choices really should have the same modeled value.
3. Identify the decisions that matter. Do not analyze uniqueness for every variable.
4. Test important variables directly. Hold the primary objective at its optimum and minimize or maximize the decision of interest.
5. Evaluate uncertainty where relevant. Compare alternate solutions on the same demand, lead-time, or disruption scenarios.
6. Add explicit secondary priorities. Stability, consolidation, optionality, and execution simplicity should be modeled intentionally.
7. Measure churn in production. A model can have a stable objective and an unstable decision policy.
8. Document the hierarchy. Make it clear which objective is primary and which preferences only break ties.

The important idea is simple:

A solver returning one solution does not prove that the decision is unique.

And if the business cares which optimal solution it gets, that preference belongs in the decision model.

Do not ask the solver to read your mind.