AI Timetable Generator

Why simple placement is not enough

The intuitive approach is greedy placement: take each lesson in turn, drop it into a free slot, move on if there is a clash. It works on small schools and fails on real ones.

The problem is that greedy placement cannot backtrack. When you discover at lesson 400 that no slot remains, the cause is a choice made at lesson 50 — and that choice cannot be undone. The result is an incomplete timetable, manual intervention, and each intervention breaking something else.

Turning rules into constraints

Constraint solving reframes the problem. Each lesson becomes a variable; the day-period combinations it could occupy become its domain; the rules become relations between variables:

• Availability — a unary constraint removing values from a domain.
• Uniqueness — an all-different constraint across one teacher's lessons.
• Contiguity — an adjacency relation for double periods.
• Resource capacity — a cumulative constraint for shared rooms.

The question changes from "where do I put this lesson" to "does an assignment satisfying all of these relations exist".

Pruning rather than trying

The search space is genuinely astronomical: with 72 slots and 700 lessons, the raw combination count exceeds anything that could be enumerated.

Solvers therefore prune rather than enumerate. When a lesson is assigned a slot, that assignment propagates instantly: the same class's other lessons lose that value, so do the same teacher's, and so do lessons sharing the room. If any lesson's domain empties — no slot remains for it — the entire branch is proven unsolvable and discarded unexplored.

Two classical heuristics guide the order. Minimum remaining values assigns the most constrained lesson first, because leaving hard cases until last leaves nowhere to put them. Least constraining value picks the slot that restricts other lessons least, preserving room to manoeuvre.

What happens when lessons cannot be placed

Some instances are genuinely unsolvable, and this is arithmetic rather than a software limit. If more classes need lessons in a given period than there are teachers available in that period, no clash-free arrangement exists — a pigeonhole argument.

Apakademia does not hide this. Unplaced lessons are listed with the reason, so the bottleneck can be identified and fixed with a targeted change. In one real deployment, four unplaced lessons out of six hundred traced to a single period where seventeen classes needed fifteen teachers; opening availability for two teachers in that period resolved it completely.

Regenerating without losing your work

The practical advantage of a constraint formulation shows up in revision rather than first generation. Pin the lessons you want to keep and they become hard constraints in the next solve — their domains collapse to a single value. The solver then handles a much smaller problem, rebalancing only what is left.

Your rules are stored with the timetable, so regenerating reapplies them automatically. Previous versions are retained.

Is this the same as a language model?

No. Constraint solving belongs to the symbolic branch of artificial intelligence and does not predict — it proves. When a solution is produced, the fact that it satisfies every declared hard constraint is verifiable.

That guarantee is precisely what a prediction-based system cannot offer, and it is the reason scheduling is done this way rather than with generative models.

Do teachers' preferences matter?

Availability is a hard constraint — the system never schedules outside it. Beyond that, preferences such as concentrating a teacher's lessons on fewer days or minimising idle gaps are scored, and the solver favours solutions that satisfy them.

In practice the preference that matters most is gap reduction. A teacher with a lesson in the first period and another in the last, idle in between, is the most common source of dissatisfaction and the thing manual planning misses most reliably.