Infeasibility Is a Modeling Signal | Learn

A solver returning INFEASIBLE is frustrating, but it is also useful information.

It means the model has proven something very specific: there is no assignment of the decision variables that satisfies every constraint you gave it.

That does not automatically mean the solver failed. In production optimization, infeasibility is usually telling you something about the system around the solver: contradictory business rules, stale state, impossible commitments, broken units, duplicated constraints, or a model that confused a preference with a physical law.

The worst response is to immediately add slack everywhere until the model solves.

The better response is to ask what the infeasibility is teaching you.

Start With the Decision

Before debugging algebra, restate the operational decision.

Suppose a replenishment model chooses order quantities:

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

The model may include inventory balance, supplier capacity, warehouse receiving capacity, minimum order quantities, pack sizes, budgets, service commitments, and previously placed purchase orders.

Now imagine the solver reports infeasible.

The first questions should not be about solver parameters. Ask:

Which decisions are actually controllable today?
Which quantities are already committed?
Which constraints represent physics, contracts, or accounting identities?
Which constraints represent targets or preferences?
What state was known when the decision was constructed?
Are all quantities expressed at the same grain and in compatible units?
Could the real operation encounter this state?

That last question matters. If production can encounter the state, then simply declaring it impossible in the optimization model is not enough. The real system still has to do something.

A Small Example

Assume three products share a supplier with 100 units of available capacity.

The model requires:

[ x_A \ge 50 ]

[ x_B \ge 40 ]

[ x_C \ge 30 ]

and:

[ x_A + x_B + x_C \le 100 ]

The minimum requirements sum to 120. Capacity is 100.

There is no solver trick here. The model is infeasible because the requirements contradict each other.

The interesting question is what those lower bounds mean.

If all three are legally committed orders, perhaps the capacity data is wrong or an emergency sourcing action is missing from the model.

If the lower bounds are service targets converted into hard constraints, the formulation may be wrong. The business can physically ship less than the target. It just dislikes the consequence.

Those are completely different problems even though the solver status is identical.

Classify Constraints Before Debugging Them

A useful production model should distinguish at least three kinds of constraints.

1. Physical or logical constraints

These should generally remain hard.

Examples include inventory conservation, machine compatibility, nonnegative physical quantities, mutually exclusive configurations, and a truck that cannot carry more than its actual capacity.

2. Contractual or committed constraints

These may also be hard, but verify that the commitment is real and represented correctly.

Examples include already-issued purchase orders, locked production quantities, regulatory restrictions, or contractual supplier limits.

3. Economic or operational preferences

These are where many models get into trouble.

Examples include target service levels, preferred inventory bands, smoothing targets, desired allocation shares, preferred production sequences, and internal policy limits.

A preference can be important without being physically mandatory.

If violating a rule is possible but expensive, model the economics of violating it rather than pretending violation cannot happen.

Use an IIS, but Do Not Worship It

Most serious MILP solvers can compute an irreducible infeasible subsystem, usually called an IIS.

An IIS is a subset of constraints and variable bounds that is itself infeasible, while removing any one member makes that subset feasible.

That is extremely useful because a production model may contain millions of constraints. You do not want to inspect all of them manually.

But an IIS is not necessarily the explanation.

A model can contain multiple IISs. The solver may return one conflict while another equally important contradiction remains elsewhere.

Suppose the IIS contains:

a warehouse capacity constraint,
a locked receipt,
an inventory balance equation,
and a minimum ending-inventory requirement.

Do not stop at, “warehouse capacity caused infeasibility.”

Ask why those four constraints cannot coexist. Perhaps the locked receipt was duplicated. Perhaps the ending-inventory target should be soft. Perhaps warehouse capacity is in pallets while receipts are in cases. Perhaps the state snapshot contains inventory from two timestamps.

The IIS narrows the crime scene. It does not solve the case.

Variable Bounds Are Constraints Too

Practitioners often inspect named constraints and forget variable bounds.

Consider:

[ 0 \le x_i \le 20 ]

combined with:

[ x_i \ge 25. ]

The upper bound is part of the conflict even if it was generated deep inside model-building code rather than given a descriptive constraint name.

This is one reason model diagnostics should preserve metadata for every important variable and row: product, location, vendor, time period, source rule, units, and the input record that generated it.

A row named c_4839201 is nearly useless at 2:00 AM.

A row identified as vendor_capacity / vendor_731 / week_2026_37 / units is actionable.

Feasibility Relaxation Can Tell You How Far You Are From Reality

Another useful diagnostic is a feasibility relaxation.

Instead of requiring every constraint to hold exactly, introduce violation variables and penalize them.

For a lower bound:

[ a^T x \ge b ]

write:

[ a^T x + s^- \ge b, ]

where (s^- \ge 0) measures the shortage.

Then minimize weighted violation:

[ \min \sum_j w_j s_j. ]

This can answer a practical question an IIS cannot:

What is the smallest set or magnitude of changes required to recover feasibility?

Maybe supplier capacity needs 18 more units. Maybe a service target must fall from 98% to 94%. Maybe a committed receipt must move one week.

But the weights matter enormously.

If every violation receives the same penalty, the relaxation may choose something operationally absurd because one unit of warehouse overflow is not economically comparable with one unit of contractual shortfall.

Use feasibility relaxation first as a diagnostic. If slack becomes part of the production policy, give it real economics and explicit ownership.

Debug Data Before Rewriting the Formulation

Many apparent optimization problems are state-construction problems.

Check the boring stuff first:

Units. Cases, eaches, pallets, kilograms, dollars, and thousands of dollars get mixed surprisingly often.

Signs. Returns, cancellations, adjustments, and transfers can enter balances with the wrong sign.

Time. A receipt in week 12 and a capacity limit in fiscal period 12 may not refer to the same dates.

Duplicates. The same purchase order or inventory record may appear twice after a join.

Missing records. A missing capacity record may default to zero instead of unknown.

Stale snapshots. On-hand inventory may come from 8:00 AM while open orders come from midnight.

Key mismatches. SKU-location records may be joined against SKU-level constraints and accidentally multiplied.

Rounding. A continuous quantity may be rounded before entering one part of the model but not another.

A solver can perfectly prove the infeasibility of garbage data.

Build Reduced Instances

Large production instances are terrible debugging environments.

Once you identify suspicious entities, create the smallest instance that reproduces the failure.

If the conflict involves one vendor, four SKUs, one warehouse, and two weeks, extract exactly that.

Then inspect:

initial state,
committed flows,
decision bounds,
balance equations,
shared constraints,
objective coefficients,
generated rows.

A reduced instance has two benefits. It is easier for a human to understand, and it can become a permanent regression test.

That second part is important. A production incident should ideally leave behind a test that prevents the same class of failure from returning.

Uncertainty Can Create False Certainty

Deterministic models often turn uncertain quantities into hard requirements.

Suppose forecast demand next month is 1,000 units. Someone converts that forecast into:

[ \text{available inventory} \ge 1{,}000. ]

Now the forecast has quietly become a constraint.

If supplier capacity only permits 900 units, the model is infeasible.

But demand was never a physical requirement. It was uncertain information about a future outcome.

A better model might represent shortage economically:

[ \text{profit} = \text{revenue} - \text{purchase cost} - \text{holding cost} - \text{shortage consequence}. ]

Under scenarios (\omega), inventory outcomes can differ:

[ I_{t+1}^{\omega} = I_t^{\omega} + R_t^{\omega} - D_t^{\omega}. ]

The decision should trade shortage risk against inventory, capacity, and cash rather than demand forecasts masquerading as laws of nature.

This does not mean every uncertain constraint should disappear. Some organizations genuinely require probabilistic or robust guarantees. The point is to be explicit about what is uncertain and why a guarantee exists.

Infeasibility Under Scenarios Needs Special Attention

Stochastic models introduce another failure mode: a decision may be feasible under most scenarios and impossible under a rare one.

For example, an uncertain lead time can delay supply while a hard minimum-inventory constraint still requires inventory to appear on schedule.

If recourse exists operationally, model it. Possible recourse actions may include:

expediting,
substitution,
transfers,
emergency procurement,
backlog,
lost sales,
overtime,
temporary capacity,
or controlled rule violations.

If none of those actions exists, then the scenario may reveal genuine operational exposure. That is valuable information too.

The model should distinguish “bad outcome” from “mathematically impossible outcome.”

Do Not Hide Infeasibility With Giant Penalties

A common workaround is to add a slack variable to every important constraint with an enormous penalty such as (10^9).

Now the model always solves.

Congratulations: you may have converted a visible modeling error into an invisible economic error.

Huge penalties can create numerical problems, distort the LP relaxation, and make different violations effectively indistinguishable. Worse, teams stop noticing that the model violates the same supposedly sacred constraint every day.

If emergency slack is necessary for operational continuity, log it as a first-class event.

For every violation, capture:

constraint family,
entity and period,
violation magnitude,
economic penalty,
reason code if known,
input state,
recommended action,
and whether a human override occurred.

A model that needs emergency slack every run is not robust. It is sending you a message.

Metrics for Production Feasibility

Solver status alone is too crude.

Track at least:

Infeasible-run rate. What percentage of scheduled optimization runs fail feasibility?

Conflict frequency by constraint family. Which rules repeatedly appear in IISs or relaxations?

Relaxation magnitude. How far from feasible is the state?

Economic cost of recovery. What does the least-bad feasible action cost?

State-quality incidents. How many failures came from data construction rather than legitimate business conflicts?

Fallback usage. How often does production use a heuristic, previous plan, or manual decision?

Time to diagnosis. How quickly can an engineer identify the conflicting business entities?

Repeat incidents. Are the same failure modes returning?

These metrics turn infeasibility from an occasional fire drill into an engineering signal.

Build a Fallback Policy

Production systems should assume that something will eventually go wrong.

The fallback should be designed before the incident.

A reasonable hierarchy might be:

solve the primary optimization model;
if infeasible, run automated diagnostics;
attempt a controlled feasibility relaxation on approved soft constraints;
if still unresolved, execute a known-safe fallback policy;
alert with the reduced conflict and relevant state;
preserve the entire instance for replay.

The fallback could be yesterday’s executable plan, a conservative replenishment heuristic, or a restricted model containing only hard physical constraints.

The exact choice depends on the decision.

What matters is that failure behavior is itself part of the decision system.

What to Log

When a model is infeasible, save enough information to reproduce it exactly.

At minimum:

model version and commit,
data snapshot identifiers,
forecast vintage,
policy parameters,
solver version,
constraint and variable counts,
presolve statistics,
solver status,
IIS members,
feasibility-relaxation results,
decision timestamp,
committed actions,
and relevant entity identifiers.

If you cannot replay yesterday’s infeasible model, you do not really have a debugging process. You have anecdotes.

A Practical Debugging Sequence

When INFEASIBLE appears in production, I would work in this order:

Confirm the status. Distinguish infeasible from infeasible-or-unbounded and from numerical failure.
Validate the state. Check units, timestamps, duplicates, joins, signs, and missing values.
Compute an IIS or conflict. Use it to narrow the relevant rows and bounds.
Map algebra back to business entities. Identify the exact SKU, vendor, location, period, and rule.
Classify each conflicting rule. Physical, committed, or economic preference?
Build a reduced reproducer. Remove everything unrelated to the conflict.
Run a feasibility relaxation. Measure what must change and by how much.
Check uncertainty treatment. Did a forecast or scenario become an impossible hard requirement?
Fix the cause, not the symptom. Correct data, formulation, or policy semantics.
Add a regression test and monitoring. Make the incident useful.

Only after this would I spend meaningful time tuning solver parameters.

The Bigger Lesson

Optimization models are executable statements about how you believe a decision system works.

When the model is infeasible, two or more of those statements cannot simultaneously be true.

That is not merely a solver problem.

Sometimes the data is wrong. Sometimes the formulation is wrong. Sometimes two departments have handed you mutually incompatible requirements. Sometimes the real operation has been surviving through undocumented exceptions that the mathematical model finally exposes.

That is why infeasibility can be valuable.

Do not just make the red solver status disappear.

Find out what the model is trying to tell you.