A Timetable That Respects Reality: Inside Flocci Schools' Constraint Engine

Illustrative conflict · not a real school timetable or a guaranteed solution. · Open the full-size diagram

A timetable is a promise about people

Every occupied cell says that a teacher and a class can be in a particular place at a particular time.

The grid may look simple. The promise is not. Teachers have different subject capabilities. Classes need different numbers of periods. Some slots are unavailable. Workload limits matter. Existing lessons may need to remain fixed.

The interesting engineering question is how to produce a useful schedule while respecting those realities.

Flocci Schools includes a reviewed generator built around that question.

Separate what must hold from what would be better

Some scheduling conditions are fundamental: one teacher should not occupy two simultaneous lessons, and a class section should not receive two lessons in one slot. Teacher eligibility and availability constrain which assignments are even valid.

Other goals describe quality. Workloads should be reasonably balanced. A subject’s lessons should be distributed sensibly. Continuity can be useful, as can avoiding unnecessary gaps.

The distinction prevents an attractive-looking schedule from hiding an invalid assignment. It also makes tradeoffs more explicit: a schedule can satisfy the essential constraints while leaving room to improve a softer goal.

Assign, schedule, inspect and repair

The reviewed implementation separates teacher assignment from lesson placement. It prioritizes more constrained requirements, builds a schedule and attempts repairs when placements are difficult.

Reproducible generation provides another useful property. Given consistent inputs and a seed, the process can be repeated; another seed can explore a different arrangement. That helps a human compare alternatives without pretending that the first output is the only possible solution.

This article makes no speed benchmark or optimality claim. A heuristic can produce useful arrangements without guaranteeing the best possible timetable for every input.

An impossible request deserves an explanation

A class can require more lessons than the week has slots. A subject can have no eligible teacher. Availability restrictions can leave insufficient capacity.

Those are input problems, not problems a polished table can solve.

The implementation includes feasibility warnings and reporting of unmet requirements. That is a valuable product behavior: make the constraint visible so an administrator can adjust staffing, requirements or availability rather than trust a schedule that quietly omitted work.

Explainable student signals follow the same discipline

Schools’ reviewed risk path computes a score from attendance, marks and homework signals, exposing reasons and contributing factors. Fee dues can appear as a separate concern without increasing the academic score.

That design keeps the signal closer to its purpose. A financial issue should not silently become a claim about academic performance.

The score is still a bounded heuristic. It is not a diagnosis, a validated forecast or an automatic decision about a child’s opportunities. Human review and complete records remain essential to interpreting it.

Domain intelligence earns trust through its constraints

The strongest education-software story here is practical: intelligence can mean making a complicated operational decision easier to inspect.

For scheduling, that means valid assignments and visible unmet requirements. For student signals, it means transparent contributing facts. Generated language can help explain the result, while the underlying computation remains responsible for the question it actually answers.

Explore Flocci Schools, industry systems and Flocci’s evidence-first intelligence approach.