How nOS actually builds a schedule.
For the person who has to explain it to a head of school. No mathematics beyond arithmetic, and the limits are stated rather than left out.
Why this is not a job for an afternoon.
Five hundred students, seven periods, ninety sections. Roughly three thousand placements.
Every student asks for six or seven courses, and each placement narrows what is left for everyone else.
Each one has to satisfy several things at once. The student cannot be in two rooms at the same time. The teacher cannot either. The room has a capacity. The course has a capacity. Some courses run once and once only, so every student who wants one is fighting for the same period. And every choice you make narrows the choices left for everyone else.
The number of possible schedules is larger than the number of atoms in the observable universe, and it is not close. You cannot check them all. Neither can any software, including this one. What you can do is search well, and know how far from the best answer you have landed.
Four passes at the same problem.
Four attempts, each picking up where the last ran out of ideas. The same inputs always give the same schedule.
Place the hardest things first
A quick first pass builds a complete schedule by always taking the most constrained decision next: the student with the fewest options left, the course with the fewest places it can go. This is fast, and it is usually mediocre. Its job is to give the next three passes something real to improve.
Tear up parts of it and try again
The long pass repeatedly destroys a slice of the schedule and rebuilds it a different way, keeping whatever turns out better. Early on it accepts changes that look slightly worse, because a schedule that never gets worse gets stuck in the first decent answer it finds. As the search goes on it gets stricter.
Follow the chain of who has to move
Some students cannot be placed unless someone else moves first, and that person cannot move unless a third person does. nOS follows those chains and makes the whole sequence of swaps at once. This is what unsticks the last stubborn handful that no single change can fix.
Tighten what is left, exactly
The final pass hands the remaining slack to a mathematical solver, which finds the genuinely best arrangement of the part it is given rather than a good one. It is too slow to run on the whole school, which is why it goes last, on what the first three passes could not settle.
You are told the ceiling before you start.
Separately from building anything, nOS works out an upper bound: the largest share of your requests that any schedule could fill given your courses, sections, rooms and rules. A proof about your data, not a guess about the software.
If a build fills 97 percent and the ceiling is 97, there is no better schedule and nobody needs to keep looking. If the ceiling itself is low, the constraint is not the software: you have promised more than the timetable holds.
Every build is checked by something that did not build it.
A separate pass re-reads the finished schedule against every hard rule, capacity and count.
What it looks for
A student or teacher in two places at once. A section over its capacity or the room's. A hard rule broken. Anything in the output that was not in your data.
What happens if it fails
The run does not ship. You never see a schedule that failed the check, and it can never reach your student information system.
Why it is separate
A builder that grades its own work always passes. This one knows nothing about how the schedule was made.
And when a request misses, you are told why.
Grouped by cause, in ordinary words. These are the shapes the answer takes.
- Every section of the course was already full.
- The only sections that had room clashed with something the student had to take.
- Two courses the student asked for run only in the same period.
- A rule you wrote made the placement impossible.
- The course has no section at all in the data.
- No teacher in the data is able to teach it.
- The section had no room large enough.
- The teacher's day was already full.
- A required course group crowded the elective out.
- The request was for a course the student was not eligible for.
- The student's own day was full before this request came up.
- The course runs in a term the student is not enrolled for.
What nOS does not do.
All of these get asked for. None of them exists, and you should hear it here rather than in week three.
- No version history or restore. There is no timeline of past schedules to roll back to. You can keep several schedules side by side and compare two of them, but you cannot rewind one.
- No share link, and no publishing to staff. nOS does not produce a public URL for a schedule or email schedules to teachers and students. You export the files and distribute them, or you send the schedule back to your student information system and let that do it.
- No approval workflow. There is no draft-and-sign-off state, and no official schedule flag. Staged changes are reviewed before they commit, and that is the whole of the review that exists.
- No shared undo. Undo inside a session is yours alone and does not reach across a refresh or across people. Committing is the durable step, so it is the one that asks.
- No user management screen. A school administrator cannot add, remove or re-role staff. We set your team up and change it when you ask.
- No viewer role or permission matrix. There are two roles, member and account administrator, and no way to scope someone to one department.
- Notes are not threaded. No replies, mentions, assignments, due dates or notifications, and no private notes. A note is a note, and anyone at your school can resolve it.
Try it on data you actually recognise.
The free audit gives you the ceiling for next year's requests. No account, no upload, no call.