Solver Logs Are Economic Documents

Most teams only look at solver logs when something breaks.

That is a mistake.

A solver log is not just a technical artifact. It is a record of how difficult the business decision actually was. If you learn how to read it, the log will tell you where your model is weak, where your data is inconsistent, where your formulation is fighting itself, and where money is being left on the table.

Many supply chain optimization projects spend months debating algorithms while ignoring the evidence already produced by every run.

The solver log is evidence.

The real problem

Imagine a purchasing optimization model.

The model decides:

• What to buy.
• When to buy.
• Which supplier to use.
• Whether to expedite.
• How much inventory risk to accept.

The model has already been deployed.

Planners use it.

Executives trust it.

Then one day runtime jumps from 20 seconds to 15 minutes.

Most teams immediately ask:

“What happened to the solver?”

That is usually the wrong question.

A better question is:

“What changed in the business that made the decision harder?”

Problem framing

Before looking at the mathematics, define the operational decision.

Who owns the decision?

How often is it made?

What happens if the recommendation arrives late?

What actions can actually be executed?

If a planner only has five minutes before releasing purchase orders, a twenty-minute solve time is not a technical issue. It is an operational failure.

The optimization model exists to support a business process, not to impress another optimization professional.

What the log is really telling you

A typical MILP log contains information about:

• Presolve reductions.
• Root relaxation quality.
• Number of cuts.
• Heuristic solutions.
• Branch-and-bound growth.
• Integrality gap.
• Memory usage.
• Runtime.

Most practitioners stop there.

The more useful interpretation is economic.

Presolve

Large presolve reductions often indicate that business rules are redundant.

If presolve removes half the model, ask why those constraints existed in the first place.

Many planning systems accumulate historical rules that no longer matter.

The solver frequently discovers this before the business does.

Root relaxation

The root relaxation is often one of the best diagnostics available.

If the LP relaxation is extremely optimistic compared to the first integer solution, your formulation may be weak.

From a business perspective, this means the mathematical representation is allowing unrealistic behavior.

Common examples include:

• Weak big-M constraints.
• Poor fixed-charge formulations.
• Loose activation logic.
• Artificial inventory movement.

The solver is effectively saying:

“Your model believes impossible economics are achievable.”

Branch-and-bound growth

A rapidly growing search tree usually means the model is struggling to distinguish between competing decisions.

This often occurs when:

• Costs are nearly identical.
• Too many equivalent solutions exist.
• Business priorities are poorly specified.
• Decision hierarchy is unclear.

This is frequently framed as a solver issue.

In reality it is often a policy issue.

The organization has not clearly expressed what it wants.

Questions to ask when runtime increases

When solve time suddenly changes, investigate the business before changing parameters.

Ask:

• Did a new supplier enter the network?
• Were new products added?
• Did lead-time uncertainty increase?
• Were additional business rules introduced?
• Did planners request new fairness constraints?
• Did a previously optional policy become mandatory?

Many optimization systems become slow because organizations continuously add exceptions.

The formulation becomes a museum of historical requests.

Metrics worth tracking

Every production optimization system should store:

• Runtime.
• Objective value.
• Root gap.
• Final gap.
• Node count.
• Presolve reductions.
• Number of cuts.
• Infeasible runs.
• IIS frequency.
• Manual override frequency.

Do not store them for technical curiosity.

Store them because they describe the health of the decision process.

Failure modes

Failure Mode 1: Chasing parameters

Teams often spend weeks tuning solver settings.

Meanwhile a single poorly constructed constraint is responsible for most of the runtime.

Formulation improvements usually outperform parameter tuning.

Failure Mode 2: Ignoring infeasibility

An IIS report is often treated as a technical debugging tool.

It should be treated as evidence that operational policies are contradictory.

If inventory cannot physically satisfy all commitments, the organization has a decision problem, not a software problem.

Failure Mode 3: Measuring only objective value

A model can produce excellent objective values while becoming increasingly fragile.

Rising runtime, growing node counts, and expanding root gaps are early warning signs.

Eventually the system reaches a scale where it becomes operationally unusable.

Practical implementation

Create a run-history table.

For every optimization run, save:

• Input snapshot identifier.
• Solver log.
• Runtime metrics.
• Solution metrics.
• Constraint violations.
• User overrides.
• Model version.

Then create dashboards showing trends over time.

Do not focus only on business KPIs.

Track optimization KPIs as well.

A model that slowly becomes harder to solve is telling you something important about the evolution of the business.

What to do in practice

The next time you look at a solver log, do not ask whether the solver is working.

Ask what the log reveals about the decision.

Optimization models sit between business policy and operational execution. The solver log is one of the few places where both worlds become visible at the same time.

Treat it like an operational record.

The best optimization teams do not just optimize decisions.

They continuously optimize the optimization system itself.