When you choose timetabling software you are not really choosing an interface. Screens look alike and buttons are learned in an afternoon. What decides how much of your August you get back is the engine behind the Generate button — and in almost every product that engine is a closed box.
This article opens ours. The Bildena scheduling engine has five layers. We will walk through what each one does, why it is there, and how we would know if it were quietly wrong.
1. School data is translated into a model without loss
The engine does not work with lesson cards. It works with decision variables. Each card is split into blocks according to its weekly hours, and every block chooses a day, a run of consecutive periods and, where it matters, a room. A school's entire week is one consistent combination of those choices.
That translation has exactly one rule, and the rule is strict: it must be lossless. The engine never says "I did not understand this constraint, I will skip it." Shared lessons, split classes, elective bands, A/B weeks, double-shift schools — all of them live in the same variable space and are expressed in the same mathematics. Every field the interface asks for has a counterpart in the model; a field with no counterpart is never asked for.
This is a larger commitment than it sounds. Adding a constraint to the interface without binding it to the model is a quiet lie to the user: you tick the box, the plan is generated, the rule was never applied — and a teacher discovers it in September.
2. Impossibility is caught before solving starts
The expensive way to learn that a timetable cannot be built is to try. Conventional checks look at each dimension separately: does the class have enough open periods, does the teacher have enough available ones? Both can pass comfortably while the timetable remains impossible — because a lesson can only go where the class is open and the teacher is free. When both sets are wide but their intersection is narrow, counting tests see nothing.
Bildena builds a two-part matching instead, for every class and every teacher, between lesson hours and eligible slots. A class teaches one lesson at a time and a teacher stands in one place at a time, so hours must map one-to-one onto slots. If no complete matching exists, the timetable is definitely impossible — not a guess, but a consequence of Hall's condition.
One rule in this layer is not negotiable: it never returns a false positive. The candidate slot sets are kept deliberately wide. If the scan says "buildable", that only means it passed this test; but if it says "impossible", it is impossible. Sending a planner down a dead end that does not exist costs more than being late.
3. Hard constraints and preferences never share a box
At the core runs a constraint solver built on Google's optimisation technology and specialised by us for school scheduling. That specialisation is where the work actually is: what decides the result is not the core itself, but how faithfully a school has been described to it.
At the centre of that description sits one distinction. Some things cannot be violated, others are merely preferred, and the two never share a box.
| Hard — never violated | Soft — competes on penalty |
|---|---|
| Teacher, class, group and room clashes | Spreading a subject across the week |
| Student clashes (in student-based scheduling) | Teacher gaps |
| Unavailable periods and closed days | Daily workload balance |
| A/B week separation | Soft ordering preferences |
| Teacher daily and weekly lesson limits | Use of flagged periods |
| Hard ordering rules and preparation limits |
4. "Nothing better exists" is a bound, not a feeling
Throughout the search the solver carries two numbers: the cost of the best timetable it holds, and the theoretical lower bound below which no arrangement can go. As the search proceeds one falls and the other rises. When they meet, the work is finished and the result is not merely good — its optimality is proved.
If they have not met, you are told the remaining gap. "This timetable is at most this far from the best possible" is the sentence that lets you decide whether to accept the plan or let the engine keep working. A heuristic cannot form that sentence: with no representation of the ideal, it cannot measure its distance from it. All it knows when it finishes is that it stopped.
We covered that distinction in its own article: what it means for a timetable to be provably optimal.
5. The result is measured with one number — but not the solver's
Every run receives a perfection score out of 100. Eighty points are placement: full marks if every lesson hour found a place. The remaining twenty are measurable quality — class gaps, teacher gaps, conditional situations and violated planning relations.
That choice is deliberate: the solver's own penalty total is not used as the score. It is a single sum, it cannot be compared between schools, and its meaning shifts the moment you change a weight — last week's 1,240 and this week's 980 do not measure the same thing. The score is therefore re-measured from the timetable itself, and the same formula runs on the server and in the browser: drag a lesson on screen and the score changes before you have saved anything.
Who checks the engine?
The most dangerous failure in a scheduling engine is not a crash; it is being quietly wrong. The plan is produced, the screen is green, and one constraint was never applied. You cannot find that class of bug by looking — you find it with tests. More than 2,800 automated tests run on the engine side alone, and three families of them target this risk directly:
- Binding tests. For every hard constraint we construct an input that deliberately violates it and require the engine to answer infeasible. Confirming that a timetable "looks right" is not enough: this is the only way to know whether a rule actually reached the model from the code.
- Real-school regression. Runs against imported data from real schools with a fixed seed. If an improvement to the engine degrades another school's timetable, it shows before the release does.
- Formulation equivalence. The same problem is expressed two different ways and the results are checked for equivalence — the proof that changing the model did not change its meaning.
Supervision duty uses the same engine, in a separate model
Teacher supervision is solved by the same core, covering both break-based and day-based arrangements. What matters is the architectural boundary: the duty planner reads lesson placements and never writes them. Regenerating a duty roster does nothing to your timetable. That rule is enforced in code review, not left to good intentions.
What we do not promise
Stating the limits up front is cheaper than explaining them later.
- Optimality is relative to the objective you defined. Weight teacher gaps at zero and the engine will happily produce a plan full of them and prove it optimal. The mathematics is faithful to your priorities, including your mistakes.
- It cannot invent resources you do not have. No solver can create a room you lack or an hour that does not exist. All it can do is tell you early and precisely that you lack them.
- The proof is not always reached within the time limit. For very large or very tight schools the engine may stop with a small remaining gap. The difference is that it tells you the gap instead of presenting a partial search as a finished answer.
The claim we will make
When a 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.
Bildena Scheduler is a web-based school timetabling system built on Google's optimisation technology with our own scheduling algorithms on top, 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.