A solver's objective value is only part of the story it tells about a result. Perhaps the software reports a cost of 82,471, a feasible schedule and a runtime of 12 seconds. Without more context, however, those details tell us surprisingly little. The schedule might be the best possible under the model, or it might be the best answer found before a time limit. The model might reflect the operation perfectly, or it might have omitted a critical rule.
Reading solver output well requires distinguishing what the software found, what it can prove, and whether the answer is useful outside the model. These are three different questions.
Feasible does not mean optimal
A feasible solution satisfies the constraints encoded in the mathematical model, subject to the solver's stated tolerances. That is already useful: the solver has found a way to meet the specified requirements. But feasibility does not establish that no better answer exists. An exact solver may keep searching and improve the current solution, while also deriving a bound on what any possible solution could achieve.
For a minimization problem, consider an illustrative result: the best known feasible cost is 120, while a valid lower bound is 100. The optimal cost, if a feasible solution exists and the bound is sound, lies between 100 and 120 inclusive. We cannot say the current solution is 20% worse than the optimum. We can say it is at most 20 cost units above the lower bound, which corresponds to a 20% relative gap under the common denominator convention used in this example. Actual solver gap definitions and tolerances vary, and some use the incumbent value in the denominator.
But feasibility does not establish that no better answer exists.
Now imagine the solver finds a plan costing 106, but the bound remains 100. The new solution is demonstrably better than the previous 120-cost plan, yet optimality is still unproven. If an exact method closes the gap to zero within relevant numerical tolerances, it may then report proven optimality for the specified mathematical model. A heuristic generally cannot make that guarantee merely because it stopped improving.
Understand the status, not just the score
| Reported outcome | Safe interpretation | What to ask next |
|---|---|---|
| Optimal | Proven optimal for the formulation, subject to tolerances and solver conditions | Does the formulation match the business problem? |
| Feasible / time limit | A valid candidate was found, but optimality may be unproven | What is the bound or gap? |
| Infeasible | No solution satisfies the model as solved, assuming the solver completed the required proof | Are the rules correct or mutually inconsistent? |
| No solution found | No usable feasible candidate was returned | Did the run stop before feasibility could be established? |
| Numerical or unknown status | The solver could not provide the expected conclusion reliably | Are scaling, modeling or numerical issues involved? |
In serious deployments, the quality of the measurement and the trustworthiness of the model matter as much as the speed of the algorithm.
These are generic interpretations rather than universal status names. Different solvers encode termination reasons in different ways. A production integration should preserve the actual returned status and reason, not translate every completed request into a simple success flag.
A strong mathematical result can still be a weak plan
Suppose a staffing model minimizes overtime and returns a schedule with zero overtime. That may be a mathematically optimal outcome. But if the data does not reflect employee availability, or if the model omits an operational rule, the plan may still be unacceptable. This is not a contradiction. The solver solved the problem it was given, not the unspoken requirements of the organization.
Validation therefore needs two layers. First, check the returned decision variables independently against hard constraints and objective calculations where possible. Second, review the schedule with people who know the operation. Unexpected results can reveal data errors, ambiguous objectives or useful tradeoffs that the team had not anticipated.
One of the most valuable habits is to keep the original baseline alongside the optimized result. A single low number is hard to interpret; a measured comparison to an existing process, under the same rules and data, is much more informative. In serious deployments, the quality of the measurement and the trustworthiness of the model matter as much as the speed of the algorithm.