Practice: Verifying a Reported Solution

Primal feasibility, against the model as written.

First constraint: $2(8)+4=20\le 20$. Holds, with equality, binding.

Second constraint: $8+3(4)=20\le 24$. Holds, with slack $4$.

Sign restrictions: $8\ge 0$ and $4\ge 0$. Hold.

Feasible.

Objective consistency. $7(8)+3(4)=56+12=68$. Matches the reported $68$. Consistent.

Status credibility. The claim is optimality. One constraint binds and one has slack, so the point sits on an edge rather than at a corner of both, worth checking. Consider moving along the first constraint's boundary: increasing $x_1$ by $1$ requires decreasing $x_2$ by $2$ to stay on $2x_1+x_2=20$. The objective changes by , an improvement. Moving to $(9,2)$: the second constraint gives $9+6=15\le 24$, feasible, and the objective is .

The status is refuted. A feasible point with a strictly better value exists, so $(8,4)$ is not optimal.

Continuing in that direction. Increasing $x_1$ further reaches $(10,0)$: $20+0=20\le 20$ and $10\le 24$, feasible, objective $70$. Here $x_2=0$ binds too, so this is a corner. The true optimum is $(10,0)$ with value $70$.

Verdict and attribution. The reported point is feasible and its reported value is correct for that point; only the optimality claim fails. That pattern, feasible, consistent, not optimal, points at a premature termination or at an objective row that differs between the model and the solver's input, not at a transcription error in the constraints, since those checked out exactly.

What the solver's status actually claims. That for the program it received, the reported point is feasible and no feasible point has a better objective value. That claim is almost certainly true. It is also almost beside the point.

What it does not claim. That the program it received is the program the planner meant. The solver has no access to intent. A constraint entered with a reversed inequality, a coefficient mistyped, a bound omitted. Each produces a perfectly well-posed linear program with a genuine optimum, solved correctly, reported without complaint.

Why the absence of errors carries no information. Software that rejects malformed input trains the expectation that silence means correctness. Solvers break that expectation, because nearly any input is a legitimate problem. There is no category of 'wrong model' for the solver to detect.

Where the reasoning inverts the actual economics. Checking is not a slower re-derivation of the solve. Finding the optimum is the expensive part; substituting a known point into the constraints is a handful of multiplications, and recomputing the objective is one dot product. The check costs a fraction of the solve and tests something the solve cannot test, agreement between the written model and the input.

What should have been done before sending it to operations. Substitute the reported point into the constraints as originally written on paper, including bounds and sign restrictions. Recompute the objective from that point and compare. Ask whether the status is credible given what the model can support. Three checks, a few minutes.

What checking still would not establish. That the model represents the situation. A constraint that exists in the world and was never written into the model will pass every check, because nothing in the model contradicts the point. That remains a formulation question, and it is a further reason not to treat any automated output as self-certifying.

What follows immediately. The status cannot be true of the model as described. Unboundedness requires a direction in which the feasible region continues without limit and the objective improves along it. If every variable carries a finite capacity limit, the region is contained in a box and admits no direction of unlimited travel at all. No objective can be unbounded over a bounded region.

So the model solved is not the model described. That is a firm conclusion, reached without seeing the file, and it should be stated plainly before any debugging begins. It rules out a whole class of investigation, including anything about the objective.

What to ask for first. The list of variables the solver received together with their bounds, compared against the intended list. The claim is that every variable is capacity-limited; the fastest test is to find the variable that is not.

Most likely cause: a bound that never reached the solver. A capacity limit present in the written model and absent from the input. A row omitted, a loop that skipped an index, a bound applied to the wrong variable name. One unbounded variable with a favourable objective coefficient is enough to produce the status.

Second most likely: a variable that is not what it is thought to be. An auxiliary or slack variable introduced during formulation, or a sign-unrestricted variable that was split, may carry no capacity limit because none was ever meant for it. If such a variable has a nonzero objective coefficient, for instance because a constant from a shifted variable was folded in wrongly, it can run away freely.

What would decide it. Ask the solver for the unbounded ray if it reports one. The ray names the variables increasing without limit, which points directly at the missing bound and usually ends the investigation in one step.

Why this is the transfer. The checks were introduced as things to run on a report in front of you. Here the reasoning runs before the model is available at all: a status is a claim, and some claims are refutable from a description alone.