The Timetable Conflict Problem
How might we create an intelligent scheduling system that detects conflicts and communicates relevant changes?
The problem
Where students run into it today.
A room changes. Forty people find out at different times.
Why it matters
A schedule change is cheap to make and expensive to distribute. The cost lands on students who show up to the wrong room.
Conflict detection is a genuinely hard constraint problem hiding behind a boring interface — good training for anyone who wants to work on optimisation.
It is also a communication problem. The best solver in the world is useless if the change reaches people after the class starts.
Possible directions
Several credible approaches, no obvious winner. Choosing between them is part of the work.
Constraint modelling
Express rooms, cohorts, faculty and time as constraints and let a solver find the violations. Start by detecting conflicts, not resolving them.
Change propagation
Work out who is actually affected by a given change, and reach only those people. Precision matters more than speed.
Personal schedule view
A read-only layer that assembles one student’s real timetable from electives and section allocation, and shows the diff when it moves.
Technologies & difficulty
Real users, real failure modes. Reliability, privacy, access control, monitoring and the discipline to keep it running.
Difficulty describes the work, not the person. A level 04 problem is not closed to a first-year — it just needs a team and a longer runway.
Potential project
Smart Campus Scheduler
A conflict detection engine over timetable data, with a personal schedule view and targeted notifications when something a student depends on moves.
No team has taken this on yet.
Skills needed
Open roles & possible team
- Backend
Constraint engine and change detection
- Data
Schema design and import of timetable formats
- Frontend
Personal schedule and diff visualisation
Research questions
The things nobody in the group can currently answer.
Which conflicts can be detected from partial data, and which need the full picture?
How do you rank conflicts when you cannot resolve all of them?
What notification frequency stops being helpful and starts being ignored?
Next steps
What the first two weeks would sensibly look like.
- 1
Model a single department’s week as a constraint graph on paper first.
- 2
Write the detector before the solver. Detection alone is a useful product.
- 3
Test propagation logic against invented worst cases — two changes that cancel each other out, a change reverted an hour later.