Probe, Then Commit: Why Solver Tuning Finally Grew Up Planning is where business software goes to meet reality. A factory needs a schedule. A logistics team needs routes. A utility company needs network decisions. A hospital needs staff allocation. The model is elegant, the constraints are clear, and then the solver quietly asks the question nobody put in the PowerPoint: ...
A solver can lose time in a very boring place: deciding which internal bookkeeping trick to use. That sounds too small to matter. Business people usually expect optimization performance to come from grand architecture, better mathematical modeling, expensive hardware, or some heroic AI layer sprinkled on top. Researchers know better, though not always loudly enough. Sometimes the expensive part is not the model. It is the tiny repeated decision made millions of times while the solver tries to keep the model logically alive. ...
A requirements document walks into a model. It says: assign resources, respect capacity, avoid conflicts, minimise waste. The model nods politely, emits a tidy block of MiniZinc, and everyone is briefly tempted to believe the future has arrived. Then someone changes the story from cars to knapsacks, or adds one stray sentence about maximising something, and the same system quietly forgets the assignment. ...
A schedule looks reasonable until someone asks why. Why did this nurse get the night shift? Why was this invoice routed for manual review? Why did the configuration engine reject one product bundle and approve another? In many operational systems, the answer is not a single rule. It is a chain of constraints: availability, capacity, dependencies, exclusions, thresholds, and the occasional policy clause someone wrote in 2017 and nobody wants to touch. ...