Ask a language model to build you a shift roster and it will. Fourteen people, three zones, a morning bank and an afternoon lull, formatted neatly, with a short explanation of the reasoning.
It will look right. That’s the problem.
Read it properly and you’ll find someone rostered in two places at 07:15, a person assigned to a task they’re not certified for, and a shift that quietly runs nine and a half hours. The document is excellent. The roster is unusable.
This isn’t a bad model or a bad prompt. It’s what happens when you ask a system that produces plausible text to produce a correct answer, and those are different jobs.
Plausible is not the same as feasible
A language model generates the next token given everything before it. Scale that up enormously and you get something that can write, summarise, translate, and hold a conversation about ground handling that would pass for informed. Genuinely remarkable, and I’m not being sarcastic — the language capability is real and we use it.
But feasibility isn’t a local property. It’s global.
When you assign a person to a task at 07:15, you’ve changed what’s possible for every other assignment in the shift. That one decision propagates. Whether the schedule is valid depends on all of the assignments simultaneously — the working-time rules, the qualification requirements, the turnaround windows, the fact that two tasks at opposite ends of the apron can’t be done by the same person twenty minutes apart.
A model writing left to right can’t hold that. It can hold the appearance of it, because rosters have a recognisable shape and it has read a great many of them. But it has no mechanism that checks the whole thing at once, and no way to know that it has failed.
A wrong roster that announces its uncertainty is fine. A wrong roster delivered with a confident summary paragraph goes into production.
That last part is what makes it dangerous rather than merely unhelpful.
The three things a solver does that a model can’t
It proves feasibility. A constraint solver doesn’t produce a schedule that looks valid. It produces one that satisfies every constraint you declared, and you can check that mechanically. If a person can’t be in two places at once, that’s encoded, and no solution violating it can come out. Not “unlikely to.” Cannot.
It tells you when there is no answer. This is the output people undervalue most, and it’s the one I’d argue is worth the most money.
Some mornings there is no valid roster. The flights and the rules and the people you have simply don’t fit together. A solver returns infeasible, and a well-built one tells you which constraints are in conflict — you’re two qualified pushback operators short between 06:00 and 08:00.
That’s actionable. Call someone in, move a turnaround, negotiate a window. You know at 05:00 instead of finding out at 07:30 when it’s already gone wrong.
A language model asked the same question will hand you a roster. It always hands you a roster. It has no concept of “there isn’t one,” so it produces the most plausible-looking thing, which is a schedule that cannot be run.
It knows how good the answer is. Solvers work against an objective, and a good one can tell you how far the current solution is from the best possible. So you can decide to stop — this is within two percent of optimal, ship it — rather than wondering whether a better plan existed. A generated roster has no such notion. There’s nothing it’s better or worse than.
Where language models earn their place
I’m not arguing against using them. We build with them. The argument is about which job they get.
Turning documents into constraints. Every ground handler has SOPs, collective agreements, service level annexes, and a training matrix. Buried in those is most of the constraint model — the working-time rules, the qualification requirements, the response times you’ve contractually committed to. Extracting that has historically meant a consultant reading everything for three weeks.
That’s a text problem, and text problems are what these models are for. A model drafts the constraint model from your documents; a person who knows the operation corrects it. The correction pass is not optional and it isn’t a formality. But going from a blank page to a reviewable draft is a real reduction in the most expensive part of the work.
Being the interface. A supervisor dealing with a delayed inbound shouldn’t have to open a scheduling screen and adjust parameters. They should be able to say what happened. The 11:40 is forty minutes late, move the crew to the A-gate turnaround. That sentence needs to become constraint parameters, and turning a sentence into structured parameters is exactly a language job.
Explaining the result. Solver output is not human-readable. “Why is Anna on stand 12 instead of stand 8” has an answer buried in the constraint model, and a model that can read that model can explain it in a sentence. This matters more than it sounds — an optimizer people don’t trust is an optimizer people override.
Notice what all three have in common. Language in, language out, or language into structure. In none of them does the model decide anything.
The division of labour
Language for the edges. Math in the middle.
You talk to the system in words. Those words become constraint parameters. A solver computes a plan that’s provably valid against those constraints. Then the model explains what it did and why, back in words.
The model never picks the assignment. That boundary isn’t a limitation we’re working around until models improve. It’s the property that makes the thing usable in an operation where a bad plan means an aircraft doesn’t leave on time.
And it doesn’t dissolve as models get better. A more capable language model is still generating plausible continuations — it’ll be wrong less often and more convincingly, which for operational scheduling is not obviously an improvement. The reason to use a solver isn’t that models are currently weak. It’s that constraint satisfaction is a different kind of problem, with a mature set of methods that have been solving it since long before any of this.
What to ask a vendor
If someone is selling you AI-driven scheduling, one question separates the categories quickly:
“What does your system do when there’s no feasible solution?”
If the answer is a plan, it’s generating text. If the answer is “it tells you it’s infeasible and which constraints conflict,” there’s a solver under there.
A useful follow-up: “How do I know the plan doesn’t break a rule?” Either the constraints are declared somewhere you can inspect, or someone is checking the output by hand. There’s no third option, and the second one is what you’re presumably trying to stop doing.
Optimum Intelligence builds erdosP-3, an optimization engine for real-world operations, with a language layer on top of it rather than in place of it. If you’re evaluating scheduling systems and want a straight answer about what’s actually doing the deciding, we’re happy to talk.