From an empty project to a published week.

A project is one timetable — a term, a season, a cohort. It needs a name and a start and end date, and that is the whole form. The dates are not decoration: they bound the calendar feeds attendees subscribe to, and once the end date has passed the project stops accepting new solver runs until you move it, so a finished term cannot be quietly re-scheduled by accident.

Events are the sessions that need to happen — a class, a shift, a workshop. Each carries how many times a week it runs, how many people fit, which days it is allowed on and the window it must sit inside. Attendees are the people who need placing.

Instructors and rooms are entirely optional. Add them and they become real constrained resources — eligibility lists, availability, capacity matching, never double-booked. Skip them and the solver simply does not model them. Most projects start without either.

Three ways in, and you can mix them. Type them into the admin grid, import a CSV of names and emails, or share the project's public enrolment link and let people sign themselves up — no account, no app, no password.

An enrolment can be partial ("attend two of the four sessions") and it can be marked high priority, which counts double when the solver has to choose.

One click. Before it starts, a pre-flight pass looks for the problems that would waste your time: someone with no availability at all, an event that needs more hours than its window contains, more demand than capacity, an event that requires an instructor when no eligible instructor is free. Warnings you can override; the genuinely impossible ones stop the run and name the event and the fix.

The search budget scales with the size of your problem rather than being a flat timer, so a small project comes back quickly and a large one gets the time it needs.

You get one of four answers, and they mean different things. Best possible — proven optimal, nothing better exists. Stopped at the time limit — a good schedule, plus the gap that bounds how much a longer run could still win. Ran out of time — no answer yet, which is not the same as impossible. No schedule possible — your constraints genuinely contradict each other.

Anyone who could not be placed is listed with a reason in plain words: not free at any available time, every session already full, clashes with another event they are enrolled in (and it names the event), or the event has no slot that fits.

This is the step most tools do not have. Pin a session and its day, time, instructor and room are locked; the next run treats it as fixed and rearranges everything else around it. Pins carry forward on their own, so you can pin a handful, run, pin a couple more, run again, and converge on the week you wanted.

If a pin can no longer be honoured — you changed the event, or the room went away — the run does not fail. The pin is dropped, the schedule is still produced, and you are told which pins were dropped and why.

Re-running a solver normally throws the whole timetable in the air: add one person and everything moves because the new arrangement is a fraction of a percent better. That is fine for the maths and terrible for the humans who already rearranged their Tuesday.

A run can be anchored to the previous one. Placements that can stay where they were are rewarded — but only at the very weakest tier, so stability never costs anyone a place. Add one attendee, and one thing moves.

Runs are kept as drafts. Put two side by side and see exactly what changed — sessions that moved (reported as a move, not as a delete and an add), who gained a place, who lost one, and which instructors are now teaching a different week.

Publishing is the deliberate act. Nothing an attendee sees changes until you publish, and personal schedule pages always show the published week, never your working draft.

On publish, every attendee with an email and at least one placement gets their schedule. Every instructor teaching at least one session gets theirs. People with nothing on are skipped rather than mailed an empty week.

When you republish, you do not have to mail everyone again. Send to only the people whose week actually differs between the two runs — the difference is recomputed on the server, and the email names the change: which class moved, from when, to when. Someone who lost their place gets told that plainly rather than being left to compare two timetables.