Campus timetabling at scale: constraints, not calendars
Timetables break because institutions model them as calendars. Modelled as constraints, they become tractable — and negotiable.
Every institution we work with has a timetable crisis in the two weeks before term. It is rarely a software problem. It is a modelling problem: the timetable is being maintained as a calendar of decisions instead of a set of constraints that generate decisions.
01Calendars record; constraints explain
A calendar tells you that Physics 201 is in Hall B at 09:00. It cannot tell you whether moving it is safe. A constraint model can, because the reason for the placement is written down: room capacity, lab adjacency, the lecturer teaching two campuses on the same day.
The constraint classes worth modelling
- Hard resource limits: seats, labs, equipment, licensed software stations
- Human availability, including part-time and visiting staff
- Curriculum rules: prerequisites, cohort co-attendance, contact-hour minimums
- Movement: travel time between buildings and campuses
- Policy: prayer times, protected teaching blocks, exam quiet periods
The value of the model is not the generated timetable. It is being able to answer "what breaks if we move this?" in ten seconds instead of ten days.
02Publish the conflicts, not just the plan
The most useful screen we build for registrars is not the grid. It is the conflict list: every constraint currently violated, ranked by how many students it affects, with the owner who can authorize the exception.
| Conflict | Students | Owner |
|---|---|---|
| Lab capacity exceeded, CHEM 110 | 42 | Dean, Science |
| Lecturer double-booked, 11:00 Tue | 18 | Head of Department |
| Travel gap under 15 min | 9 | Registrar |
03Let the exception be first-class
Institutions run on exceptions. A system that cannot record an approved violation forces staff back into spreadsheets, and the spreadsheet becomes the real timetable within a week. Model the exception, record who approved it, and expire it at term end.