School timetabling

Constraint validation before generation

How static and dynamic checks catch data and constraint problems before optimisation.

Juho Isola, Smootables founder

What should validation prove before generation? It should show that timetable data and constraints are ready for placement. Static analysis finds data problems such as missing values, duplicates, and unstaffed lessons. Dynamic analysis combines data and constraints to find problems static checks cannot see.

Validation does not guarantee a finished timetable. It makes feasibility more likely and tells the planner which critical issues must be fixed before optimisation starts. These guides cover planner process and decisions, not a product comparison. To evaluate software capabilities, see automatic school timetabling software.

Key takeaways

  • Static analysis finds missing values, duplicates, and unstaffed lessons.
  • Dynamic analysis tests data and constraints together.
  • Critical issues must be fixed before optimisation starts.
  • Passing validation makes feasibility more likely, but never certain.

What does static analysis catch?

Static analysis checks whether the raw timetable data is usable. It can find missing values, duplicate records, and unstaffed lessons before the solver starts. These are data problems, not placement problems.

Which checks belong before optimisation?

Before optimisation, focus on issues that block creation.

  • Missing teacher, class, subject, or room values
  • Duplicate teachers, rooms, groups, or lessons
  • Unstaffed lessons that cannot be placed
  • Constraint conflicts that make required placement impossible
  • Block build, combing chart, and clash table issues from planning
  • Critical messages that need a fix before a run

How should planners validate a model?

Use validation as a gate before optimisation.

  1. Run static analysis on the timetable data.
  2. Fix missing values, duplicates, and unstaffed lessons.
  3. Run dynamic analysis against the active constraints.
  4. Resolve critical issues before optimisation starts.
  5. Check structural planning outputs such as block builds and clash tables.
  6. Start generation only when the remaining issues are understood.

How do planning checks carry into validation?

Block build, combing charts, and clash tables test whether the planned structure can fit before individual lessons are placed. If planning already shows a clash, fix the structure before asking the solver to rediscover it.

What should a validation result tell the planner?

The result should point to a fixable cause.

  • Whether the issue is a data error or a constraint conflict
  • Which teacher, class, room, or lesson is involved
  • Whether the issue blocks generation or can wait
  • Which planning output may need review
  • Whether another validation pass is needed after the fix
  • Whether generation can start with the current model

Questions planners ask about validation

What is static validation?

It checks the data by itself, including missing values, duplicates, and unstaffed lessons.

What is dynamic validation?

It checks the data together with constraints, so it can reveal problems that only appear when placement logic is applied.

Does a clean validation guarantee success?

No. It means feasibility is more likely. Some conflicts only appear during placement.

More guides on this topic

See how Smootables fits your school

Book a walkthrough and we will map Smootables to your planning, workload, and timetabling process.