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.

300 Lessons
12 Cohorts
20 Teachers
40 Weekly timeslots
10 Rooms
11 Constraints

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.

Teacher availability Teachers can teach only the timeslots they are available for.
Cohort availability Student groups can attend only the timeslots they are available for.
Room capacity An assigned room must have capacity for the class size.
Single booking One teacher, one cohort, and one room cannot host overlapping lessons.
Assignment completeness Medium pressure keeps every lesson assigned to both a timeslot and a room.
Timetable quality Room kind, late-day lessons, and repeated subjects stay visible as soft pressure.
Runtime walkthrough Watch the school week fill cohort by cohort, then check the same 300 lessons from rooms, teachers, and score analysis. Narrated walkthrough (2:02): cohort timetables, room utilization, teacher loads, score analysis, the data tables, and the REST surface of one retained timetable solve.
Group timetable The cohort view lays out each group's week across a fixed Monday-to-Friday teaching week, with the status strip, score, and constraint dots on the same surface.
  1. The status strip keeps lifecycle state, score, moves per second, and all 11 constraint dots visible.
  2. Each scheduled lesson carries its room, teacher, and cohort inside the block.
Room utilization Room utilization turns the same retained plan around: every lane is one room, with booked lessons placed against the teaching day.
  1. Room lanes show how the building is used across the week.
  2. The same 300 lessons, read from the rooms instead of the cohorts.
Teacher loads Teacher loads expose the working week of every teacher, so a timetable that fits the cohorts can be checked against the people teaching it.
  1. Each view is one retained plan; only the grouping changes.
  2. Teacher lanes expose that teacher's own week and load.
Score analysis Score analysis makes the timetable auditable: hard legality, medium assignment pressure, and soft quality stay separated with match counts.
  1. Hard, medium, and soft score components stay separate.
  2. Soft pressure keeps its contribution and match count per constraint.
Data view Data views keep cohorts, subjects, teachers, rooms, and timeslots next to the plan, with the assigned timeslot and room visible per lesson.
  1. Input facts stay in the same surface as the generated plan.
  2. Assignment columns show the chosen room and timeslot per lesson.
REST API The REST guide exposes the same retained workflow for integration: demo data, solve creation, status, snapshots, analysis, lifecycle actions, and events.
  1. Every endpoint ships a copyable curl example.
  2. Retained-job endpoints cover create, status, snapshot, analysis, and events.