The developer’s guide to planning optimization

When rules stop working

Every scheduling system starts as a rulebook. If a technician holds the certification, they can take the job. If someone worked Saturday, don’t give them Sunday. The rules are readable, the behaviour is predictable, and for a while that is enough. The ceiling arrives quietly: rules begin to contradict each other, the order they run in decides the outcome, and every new requirement needs another exception. The plan is technically valid and still obviously wrong to the person who has to run it.

What planning optimization actually is

Optimization inverts the problem. Instead of writing the logic that produces a schedule, you describe what a good schedule looks like and let a solver search for one. Three pieces do the work: a model of what can be decided, constraints that say what is forbidden and what is merely undesirable, and a score that turns any candidate plan into a number so two plans can be compared. The solver explores the space of possible plans, keeps what improves the score, and stops when it runs out of time or out of better ideas.