What the pre-flight check does

FET can spend a long time failing. A single rule that makes one lesson unplaceable does not announce itself — the solver simply searches, and searches, and eventually gives up or produces nothing.

The pre-flight check reads your rules and does the arithmetic first. Where it can prove a timetable is impossible, it says so in seconds and names the rules responsible.

Where it is

Pre-flight sits with the constraints on the timetable's data screen. It is available to people who can edit the timetable — it is a tool for the person building the rules.

Each constraints section also carries a one-line summary at the top, so you see the state of things while you are working rather than only when you go looking.

The report: a verdict, then each finding with the rules behind it.

Where the arithmetic runs

The check does not run in your browser. Your browser reads your rules and sends a summary to our server. Our server does the arithmetic and sends the findings back.

The summary carries no names. Teachers, rooms, subjects and student groups travel as numbers, and your browser puts the names back before it shows the report.

We store nothing from the check. The check builds the report again from your current rules each time you open it.

That has a practical consequence worth knowing: it is fast enough to use as a working tool. Change a rule, come back, look again.

What it is actually reading

Your constraints, as they stand — not a solved timetable. It never places a lesson and never modifies anything.

What it does is arithmetic on the room you have left:

• How many hours a teacher is committed to, against how many slots remain available to them.
• Which starting times a lesson could legally take, once every rule that touches it has been applied.
• Whether two lessons that must both happen are forced into the same slot while sharing a teacher, a room or a class.
• Whether a group of lessons demands more distinct days than the week contains.

When the arithmetic leaves no room, that is not an opinion about difficulty. It is a proof, and the check says so.

What to do with it

Run it before you send a project to FET, and again after a large change. A clean report is not a promise that FET will solve quickly — see What it cannot tell you — but a report with a proven-impossible finding in it tells you the solve cannot succeed, which is worth knowing before rather than after.

The report is in four parts

The report does not grade findings by how serious they feel. It sorts them by what it can prove, into four kinds: Proven impossible, Mistakes, What makes this file hard, and What ran on this file.

Each kind is a tab, and each tab carries its own count. A kind with nothing in it has no tab at all, so a quiet file shows fewer tabs than a busy one. The first tab with something in it opens by itself.

A group with many findings shows them as a list rather than as cards. Select a row to see the arithmetic behind it beside the list.

Only the first kind proves that FET cannot build the timetable. See The four kinds of finding.

Connections

Connections answers a different question: not what is wrong, but what is attached to this teacher.

Pick a teacher, a student group or a room. You get their activities, the rules that name them, the resources they share a room or a slot with, and a picture of those links. Select any node in the picture to move the view to it.

The colour of a node says what it is — a teacher, a student group, a room or a rule. A ring around a node says the check found something about it. A solid red ring marks an error. A broken amber ring marks a warning. Most files have no rings at all, and that is the normal state.

A broken grey line between two rules means they say the same thing twice.

Entities with nothing attached are hidden until you ask for them, because a large file declares many that carry no activities.

Where to go next

• The four kinds of finding — what each kind actually promises.
• Fixing what it finds
• What it cannot tell you