Modelling choices that bite

Four questions, asked of every model, in this order. Are all the terms in a row measured in the same thing? Is every limit that physically exists actually written down? Does the objective contain every cost that changes when the plan changes? And is everything in the constraint block genuinely impossible to cross, rather than merely undesirable? Each question catches a different fault, each fault produces a different symptom, and none of the four is detectable by looking at the solution alone. You have to look at the model.

• Formulation. The translation from a real situation into variables, an objective and rows. The part with no error messages.
• Dimensional consistency. Every term in a row measured in the same unit, and the right hand side measured in that unit too.
• Missing constraint. A limit that exists in the world and not in the model. It never causes infeasibility; it causes a plan that cannot be run.
• Unpriced cost. Something the plan consumes that the objective does not charge for. The solver will consume as much of it as it can.
• Soft constraint. A requirement written as a penalty in the objective, so the plan may pay to break it.
• Hard constraint. A row the plan may not cross at any price. Writing one as the other is a modelling decision, not a detail.
• Indicator variable. A variable restricted to 0 or 1, standing for a yes-or-no decision such as whether a line is set up at all.
• Big-M. The constant that links an indicator to a quantity, as in quantity <= M * indicator. Its value is a choice, and both directions of getting it wrong are bad.

A constraint row is a sum of terms compared against a ceiling, and the comparison only means something if every term and the ceiling are measured in the same thing. Write one product's milling requirement in minutes while the rest of the row is in hours and the arithmetic still works perfectly, because arithmetic does not know what an hour is. The row now says something false about the mill, and the solver optimises faithfully against the false statement.

What makes this the nastiest of the four is that it does not push the model towards infeasibility, where you would notice. It rescales one column of one row, which tilts the trade-offs between products by a constant factor. The plan shifts, the objective shifts, everything still solves, and the only evidence is that the mix looks slightly odd to somebody who knows the plant. Write the unit next to every coefficient when you build the matrix, and check the ceiling's unit against the row's, every time.

Adding a limit can only shrink the feasible region, so leaving one out can only enlarge it. A larger region contains everything the real one does and more, so the optimum over it is at least as good as the true optimum, and usually strictly better. That is the whole mechanism, and it explains the characteristic experience: the model's first run produces a suspiciously attractive plan, and the attractiveness is the symptom.

The limits that go missing are almost never the ones on the capacity sheet. They are the ones so obvious to the people on the floor that nobody thinks to say them. A minimum batch size. The fact that two products cannot run on the same day. A customer who must get something every week whatever the margin says. The reliable way to surface them is to show a specific optimal plan to somebody who runs the operation and ask what is wrong with it, because people recognise a violation far faster than they recall a rule.

If something the plan consumes is not in the objective and not in a row, then as far as the model is concerned it is free and unlimited. The optimiser will use as much of it as helps. This gets described as the solver gaming the model, which gives it too much personality: it is doing precisely what it was told, and the omission is the instruction.

The practical test is to list everything that changes when the plan changes, then check each item against the objective and the rows. Anything on the list that appears in neither is being consumed for free. Then decide deliberately: price it in the objective, or bound it with a row, and note that those two choices produce different plans. Pricing lets the plan buy more of it when it pays; bounding forbids that trade entirely.

Writing a requirement as a row means the plan may never break it, at any price. Writing it as a penalty in the objective means the plan will break it precisely when breaking it earns more than the penalty. Both are legitimate, and which one is right is a question about the world rather than about modelling: is there a price at which the organisation would genuinely accept the violation?

A hard rule written soft yields plans that break rules, which is a different kind of failure from the other three. The model is not inaccurate, it is unusable, and the people who have to reject its output learn to reject its output. The reverse error is quieter and also expensive: a preference written hard forbids plans that would have been worth their cost, and because those plans never appear, nobody sees what was lost. The second error has no symptom at all, which is why the question deserves to be asked explicitly for every row rather than settled by whichever is easier to write.

Too small is a correctness failure. The row forbids quantities that were always achievable, so the true optimum may not even be in the model's feasible region any more. The output is optimal for a problem you did not mean, and there is no signal: not an error, not an unusual status, not a suspicious number. This is the one to be afraid of.

Too large is a performance failure, and it works through the relaxation. In the relaxed problem the switch is not forced to 0 or 1, it can take any value in between. With a very large M, a switch value of a tiny fraction still permits a substantial quantity, so the relaxation can enjoy the output while paying almost none of the setup cost. That makes the relaxed value far better than any real plan, the bound becomes weak, branches that should be pruned survive, and the search inflates. The answer stays correct and the time to get it does not.

Which is worse depends on what you can tolerate, and it is worth saying plainly that the two are not on the same scale. A slow model announces itself. A quietly infeasible-for-no-reason model does not.

Derive it, do not pick it. For each switched quantity, work out the largest value it could take if everything else were maximally favourable, using the rows you already have: what the capacity ceilings permit on their own, what any demand limit permits, whichever is smaller. That number is the tightest honest M, and deriving it from the constraint data means it stays correct if the data change. A round number typed because it looks big enough is the version that goes wrong in both directions at once, on some future dataset.

Then measure rather than assume, because the trade-off is empirical. Solve at the derived M and record three things: the objective, the value of the relaxation at the root, and the node count. Multiply M by ten and record them again. The objective should not move at all, and if it does, the smaller M was cutting off valid plans and you have just found a real defect. The relaxation should get worse and the node count should rise, and how steeply they do that on your problem is the thing worth knowing. Then try a deliberately undersized M and watch the objective fall with no other indication that anything is wrong, which is the failure you are learning to recognise.

The mill's own numbers carry no big-M measurements to quote, so treat the paragraph above as the experiment to run on your model rather than a result to repeat. What is not in doubt is the shape: the objective is the correctness check, the node count is the cost, and they respond to M in opposite directions.

Big-M is taught everywhere and disliked by many of the people who teach it, and the argument is about whether it should be used at all in serious models.

One camp says it is fine and the objection is academic. It is one row, it is readable by anyone, it survives being handed to a colleague, and with a bound derived from the constraint data rather than typed in, the weakness of the relaxation is modest. Models are maintained by people, and a formulation that a maintainer understands at a glance has a practical value that does not appear in any benchmark.

The other camp says the construction is a trap with a friendly face. The relaxation it produces is weak by design, the weakness grows with the size of the constant, and the failure when the constant is too small is silent and severe. There are alternative formulations of the same logic that are tighter, and on larger models the difference is not a few percent but the difference between finishing and not. On this view the readability argument is how people end up with a model that runs overnight.

Both camps derive M from the data rather than guessing it, and both would run the objective-must-not-move check. The disagreement is about what to do when the derived M is still large: tolerate a weak relaxation, or reformulate. That is a real fork, and which side you take usually depends on whether you have personally waited on one of these.