School timetabling
300 lessons. 12 cohorts. 20 teachers. One inspectable school week.
Lesson timetabling shows two scalar decisions per lesson: which weekly timeslot and which room. Teacher availability, cohort availability, room capacity, and single-booking rules hold at the same time as soft timetable quality.
A timetable is not a table of slots. Every lesson needs a room that fits the class, a teacher who is available at that hour, and a cohort that is not already booked. No teacher can teach two lessons at once, no cohort can be in two places, and no room can host a double booking.
The app keeps the generated week, the retained job, score analysis, the input tables, and the REST surface on one inspectable timetable: cohort, room, and teacher views are three readings of the same retained plan.
- The status strip keeps lifecycle state, score, moves per second, and all 11 constraint dots visible.
- Each scheduled lesson carries its room, teacher, and cohort inside the block.
- Room lanes show how the building is used across the week.
- The same 300 lessons, read from the rooms instead of the cohorts.
- Each view is one retained plan; only the grouping changes.
- Teacher lanes expose that teacher's own week and load.
- Hard, medium, and soft score components stay separate.
- Soft pressure keeps its contribution and match count per constraint.
- Input facts stay in the same surface as the generated plan.
- Assignment columns show the chosen room and timeslot per lesson.
- Every endpoint ships a copyable curl example.
- Retained-job endpoints cover create, status, snapshot, analysis, and events.