Every timetabling program will hand you a timetable. The question nobody asks — and the one that decides how much of your August you lose — is what the program actually means when it says it is finished.
There are only two honest answers. Either the software searched until it ran out of time, moves or patience, and gave you the best arrangement it stumbled across. Or it searched until it could prove that no better arrangement exists. These sound like variations of the same thing. They are not. They are different mathematics, and they lead to very different weeks.
The heuristic bargain
Traditional timetabling engines are heuristic. They place lessons using rules of thumb, notice conflicts, back up, try a different order, and repeat. It is, deliberately, a mechanised version of what a human planner does with cards on a table — and vendors describe it that way. aSc TimeTables' own manual states that "the program uses dynamic and heuristic algorithms, which allow it to follow the same procedure a person would." Untis documents a two-phase process — an initial placement pass followed by a swap-optimisation pass — governed by weight sliders the planner sets themselves.
This approach has a real virtue: it is fast, and for a school whose constraints are loose it produces a perfectly good plan. Millions of timetables have been built this way.
But it comes with a bargain attached, and the bargain is rarely spelled out. A heuristic cannot tell you where you are. When it finishes, it knows one thing — that it stopped. It does not know whether the plan it handed you is excellent, mediocre, or two swaps away from something far better. There is no measurement of distance from the ideal, because there is no representation of the ideal.
The documentation is candid about the consequences. aSc warns that when generation fails, "a few unplaced cards will remain," and that restarting is "only worth two or three tries, then it is better to try to modify the criteria." Its generation settings include an option that performs automatic relaxation of the constraints — the program quietly breaks conditions you asked for in order to place the remaining cards. Untis reserves its best results for Übernacht-Optimierung: leave the computer running overnight.
What a solver does instead
Bildena is built on a constraint solver we have specialised, end to end, for one job: distributing lessons across a school week. It does not simulate a person moving cards. It translates your school into a mathematical model — every lesson a variable, every rule a constraint — and searches that model systematically.
The important part is not that it is faster. It is that it maintains two numbers at once: the best solution found so far, and a bound on the best solution that could possibly exist. As the search proceeds, the solution improves and the bound tightens. When they meet, the search is over — not because time ran out, but because there is provably nothing better. That is what optimality means, and it is a mathematical statement, not a marketing one.
Three things this makes possible
1. A plan that is certified, not hoped for. When Bildena reports zero conflicts, that is not "no conflicts were noticed." It is "no arrangement of these lessons violates your hard rules, and this is one of them." Hard constraints — a teacher in two rooms, a class in two places, a room double-booked — are structurally impossible in the model rather than penalised after the fact.
2. Infeasibility as an answer, not a failure. Sometimes the honest answer is that no timetable satisfies everything you asked for. Six hours of Mathematics in a five-day week with a teacher available three days is not a hard problem; it is an impossible one. A heuristic responds to impossibility the same way it responds to difficulty — it keeps trying, then leaves cards unplaced. A solver can prove that the requirements conflict and say so, before the run rather than after it. Bildena's Advisor performs these checks up front: capacity, availability, room types, teacher load.
3. A meaningful stop button. Because there is always a current best solution and a known gap, you can interrupt at any moment and keep what has been found — along with an honest statement of how far from optimal it might be. "98.4 out of 100, within 1.8% of the theoretical bound" is a sentence a heuristic cannot produce.
Hard rules and soft preferences
A school timetable is not one problem but two, layered. Some requirements are absolute: a teacher cannot be in two rooms at once, a lab lesson needs a lab. Others are preferences that trade against each other — minimise gaps, spread subjects across the week, balance daily load, avoid single lessons after lunch. Every school weighs these differently, and no software can decide the weighting for you.
The distinction matters because the two need different treatment. Hard requirements are constraints: the solver will not return a solution that breaks one, ever. Preferences become terms in an objective function with weights you control. The solver then does something a person cannot do reliably by hand — it finds the arrangement that maximises the weighted total across all of them simultaneously, rather than fixing one complaint at a time and creating two more.
Why nobody shows you the solve
There is a curious gap in this market. Every vendor describes generation as the heart of the product, and not one of them shows it happening. aSc advertises that its generator evaluates "over 5,000,000 possibilities" but displays nothing while it does. Untis reports quality percentages after the fact. Users have asked for this for years; one recurring complaint in reviews is the absence of any predictive indicator during generation.
We stream the solve live. As Bildena works, you watch the hard-conflict count fall, the quality score climb, the phase change from feasibility search to optimisation, and the gap to the theoretical bound narrow — a running commentary over a live connection, not a progress bar with an invented percentage.
This is partly transparency and partly diagnosis. A solve that stalls at 12 remaining conflicts on the teacher-availability cluster is telling you something specific about your data. A spinner tells you nothing.
What we are not claiming
Provable optimality is a property of the model, not a magic wand, and it is worth being precise about its limits.
- Optimal means optimal for the objective you defined. If you weight teacher gaps at zero, the solver will happily produce a plan full of them and prove it optimal. The mathematics is faithful to your priorities, including your mistakes.
- Garbage in, provable garbage out. A solver cannot invent a room you do not have or an hour that does not exist. It can only tell you, precisely and early, that you do not have them.
- Optimality is not always reached in the time you allow. For very large or tightly constrained schools, the solver may hit its time limit with a small remaining gap. The difference is that it tells you the gap, rather than presenting a partial search as a finished answer.
The claim we will make
When the run ends, you will know which of three things happened: this timetable is optimal; this timetable is feasible and within a stated distance of optimal; or these requirements cannot all be satisfied, and here is the set that collides.
You will never get "here is what I managed." That is the difference, and after thirty years of timetabling software it is a strange thing to still be able to say.
Bildena Scheduler is a web-based school timetabling system built on a constraint solver specialised for lesson distribution, developed and hosted in Germany. You can run a full generation on your own data during the free trial — importing from aSc TimeTables, Untis or Excel — and compare the result against your current plan.