Mid-year changes are where timetables die. A teacher drops Fridays. A room closes for six weeks. A new rule arrives from the ministry. Each is a small change to the requirements and a potentially large change to the plan, and the person who has to make it is usually not the person who built it in August.
This is the problem our assistant exists to solve. You describe the change in ordinary language; it translates that into constraints, re-solves the affected part of the plan, and shows you exactly what would move. Then it stops and waits.
The design decision that shaped everything
The assistant has no authority to change your timetable. Not "we have safeguards" — it structurally cannot. Every proposal is a diff that requires a human click to apply.
That sounds cautious to the point of dullness, and it is the most important thing about it. Here is why we did not build the obvious alternative.
A timetable is not a document; it is a commitment that hundreds of people have organised their lives around. A change that looks trivial in isolation — move one lesson to Tuesday — can ripple into a teacher's childcare arrangement, a student's bus, and a room booking three weeks out. Software that makes those changes autonomously is not saving anyone work. It is generating a different, worse job: verification after the fact, with no record of what changed.
What a proposal looks like
Say you type: "Mr Weber can't teach Fridays from next month."
The assistant does four things. It interprets the request as a constraint — teacher unavailable, specific day, specific date range. It shows you that interpretation, so a misreading is caught before anything runs. It re-solves with the new constraint in place. And it returns a diff:
- 9b Mathematics: Friday P2 → Tuesday P4 (room A104 free)
- 7a Mathematics: Friday P5 → Wednesday P1 (no gap created)
- 11 Advanced Maths: Friday P3 → Thursday P6 (course group intact)
Three lessons move, no new conflicts, teacher gaps unchanged. Below it: Apply, or Review in the grid. Until you press one, your timetable is exactly as it was.
The proposals come from the solver, not the model
This is the part that matters technically. The language model's job is to interpret the request and explain the result. It does not decide where lessons go. That decision comes from a real re-solve by the engine against your full rule set.
The practical consequence: the assistant cannot hallucinate a placement. It cannot suggest putting a lesson where the room is occupied, because such an arrangement is not in the solution space the solver is allowed to return. The natural-language layer is a translator at the front and a narrator at the back; the mathematics in the middle is unchanged.
Where the regulation lands
Since 2 August 2026, Article 50 of the EU AI Act requires that AI systems interacting with people disclose that they are AI. Our assistant identifies itself, and AI-generated proposals are labelled as such in the interface.
We treat this as a feature rather than a compliance obligation. A German school leader deciding whether to let software near their timetable is entitled to know which parts are deterministic and which are a model's interpretation. Labelling makes that boundary visible instead of blurring it.
On risk classification, a note for anyone doing the reading: Annex III of the AI Act lists four high-risk uses in education — admission and assignment to institutions, evaluating learning outcomes, assessing the appropriate level of education, and monitoring prohibited behaviour during exams. Administrative timetabling is not among them. That is not a loophole we are exploiting; it reflects that arranging lessons does not determine anyone's educational outcome. We mention it because it also constrains what we will build next: the planned administration suite must stay clear of those four functions, and we would rather design around that from the start than discover it later.
What we refuse to do with it
Some capabilities are technically straightforward and we have decided against them.
- No autonomous application, including for "obviously safe" changes. Once there is a category of change the software makes by itself, the question becomes where the boundary is — and nobody can remember the boundary at 8am in a crisis.
- No training on school data. Not ours, not a model provider's. This is in the data processing agreement, not just in a blog post.
- No decisions about people. The assistant will not suggest which teacher should take an extra class or which student should move sections. It arranges lessons in time. Judgements about people belong to people.
Where it genuinely helps
Stripped of the ambition to be autonomous, what remains is narrower and more useful than it sounds:
It removes the translation step. Expressing "no class should have more than two free periods" in a constraint editor requires knowing that this is a class-gap rule, finding the screen, and choosing a priority. Saying it in a sentence does not. For an occasional user — the deputy head covering for the timetabler who is on leave — that difference decides whether the change happens at all.
And it makes consequences visible before commitment. The diff is the actual product. Even for someone who knows exactly which constraint to edit, seeing "this is what your change does to three classes" before agreeing to it is worth more than the time saved typing.
The assistant is included in every Bildena plan. It always shows its changes before anything is applied — you keep the final say.