How it actually works
The reasoning behind the roster — the architecture, the honesty about what's proven versus still learning, and where this started.
Scroll to watch it resolve
Language and law are not the same kind of thing.
A manager's note — “give Sam Friday off, we're quiet this week” — is language: flexible, ambiguous, full of context a person fills in without thinking. Two managers reading it would agree on what it meant and disagree on exactly what it implied.
A roster's constraints are law: nobody works more than their contracted hours, everybody gets their minimum days off, nobody works a role they are not qualified for. These are exact. They admit no interpretation, and there are usually hundreds of them interacting across a single week.
Almost every failure in this category of software comes from one mistake — treating the second kind of thing as though it were the first.
So each job gets the tool that fits it.
Horarium uses a large language model for the first job and a mathematical constraint solver for the second, and never asks either to do the other's work. The model reads a manager's notes and translates intent into structured hints. The solver takes those hints plus every hard constraint for every person that week, and either finds an assignment satisfying all of them or reports exactly which ones conflict.
Below is a real week at a three-person venue, with the weekly-hours rule being checked against it in the margin as you read. Nothing about that check is illustrative — the totals are summed from these shifts.
| Sambar | Thu 8h Fri 9h Sat 9h |
|---|---|
| Adafloor | Fri 7h Sat 8h |
| Marcofloor · bar | Thu 6h Sat 7h |
Which is what buys the ability to prove a negative.
This is the same category of technique used for exam timetabling and crew scheduling — problems where checking every arrangement by trial and error breaks down almost immediately. It is how a whole week of interacting constraints settles in seconds.
But the property that matters most is not speed. Sometimes there genuinely is no valid roster: not enough people, or someone's constraints simply cannot all be met that week. Asked to produce one anyway, a language model will produce something, because producing something plausible is what language models do — even when nothing correct exists.
The same week again with one shift moved: Ada, qualified for floor only, put behind the bar on Saturday. The margin runs the identical check, and this time it refuses — naming the assignment that caused it. Being able to say no, precisely, is the whole property.
A solver does not produce an answer that breaks a constraint you gave it. It mathematically cannot.
And here is where the proof does not yet reach.
A guarantee about constraints is worth exactly what the constraints are worth. When you set up a venue, Horarium loads an industry pack — typical roles, shift patterns, vocabulary. Hospitality is built entirely from a real bar's real weekly rosters, so it is marked proven because it is. Hotels, schools and retail are not there yet, and the wizard says so plainly rather than presenting a guess as settled fact.
Choosing an industry at signup
Three mechanics are not built, and the wizard does not pretend otherwise. A hotel front desk needs a handoff overlap between shifts, and the solver has no concept of linking two shifts at all. Occupancy-driven staffing is not there. A school's real constraint is not “this teacher is free” but “this teacher is qualified for this subject”, and today's matching is one flat role field per person.
Shift-handoff overlap windows
Occupancy-driven headcount
Subject / certification matching
Each needs a genuine new piece of modelling, not a parameter tweak — so rather than ship something that half-works, they have not shipped. A hospitality venue and a retail floor work end to end today, and most of a hotel does. That is the extent of the claim, and the extent of it is the point.
One manager, one bar, one weekly problem.
Horarium did not start as a scheduling platform. It started at Raw Bar in Sydney, solving one manager's actual weekly problem: build a fair, workable roster for a small team without losing an evening to it, every week.
That constraint — an actual manager, an actual bar, actual staff with lives outside their shifts — shaped everything after it. Every rule this system enforces exists because a real week at a real venue needed it enforced, not because a specification listed it as a nice-to-have. It is expanding beyond hospitality now. Hospitality is still where the whole approach came from, and still the only pack that has earned proven.
