SkyRoster's rostering engine is a constraint solver: an algorithm that searches for an arrangement of shifts satisfying a fixed set of rules, the same broad class of technique used for vehicle routing, factory scheduling and exam timetabling. It is not a machine-learning model, and there is no large language model, and no training pipeline, anywhere inside it. The distinction is not a technicality. A model trained on data behaves differently as the data changes, and its reasoning is not fully inspectable after the fact. A constraint solver applies the rules you gave it and nothing else, and every decision it makes can be traced back to one of those rules by name.verified
The engine
It does not learn from you
This page is for the union representative who has heard ‘AI’ and pictured a black box scoring people, and for the engineer who wants the actual mechanism before believing any of it. Neither should have to take our word for it. Everything below is specific enough to check, and it links to the catalogue that makes it checkable: the rule that decided your Tuesday has a name, and you can read it.
The mechanism
A constraint solver, not a model
Straight questions
Six questions, answered plainly
Does it learn from our data?
No. It is a constraint solver, an algorithm that searches for an arrangement satisfying a fixed set of rules, not a model trained on rosters, on requests, or on anyone's history. There is no training step anywhere in the rostering engine, and no model that gets better, or different, the longer you use the product.
Does it build a profile of individual controllers?
No. It does not track who swaps often, who calls in sick before a night shift, or score anyone as difficult. There is no behavioural model attached to a person's name. The one running fairness figure the product does keep, the Vacation Score used to prioritise popular leave dates, is a table your administrator configured, visible on your own dashboard, with every change to the table on the audited record.
Does it predict anything, fatigue risk, attrition, who is about to leave?
No. It checks a roster against rules that are true or false right now, for example whether a rest period is long enough. It does not forecast a future state. Nothing on this site claims a prediction, because nothing in the product makes one.
If I run it twice on the same month, do I get the same roster?
Scored the same, very likely placed differently. The algorithm always applies the exact rule set your organisation configured, in the same way, every single time. There is no randomness standing in for a decision a person should make. What it does not guarantee is identical shift-by-shift placement between two separate solves: a large roster usually has several arrangements that tie at the same best score, and which one a given run lands on depends on the order its search happened to try moves in. Re-running Check Solution on one unchanged roster, by contrast, always returns the same result, because scoring has nothing left to search. See how it decides for the full mechanism.
Can it override a rule, or decide something a person didn't authorise?
No. Every rule it can enforce exists because an administrator in your organisation enabled it, and every threshold and weight it uses is a value that administrator set. A locked shift always wins over the solver. There is no rule running in your instance that your organisation did not, at some point, switch on.
Traceability
Every decision traces to a named rule a human configured
“Explainable” is an overused word on rostering websites. Here is the specific, checkable claim behind it: every shift the engine proposes can be attributed to the demand and the rules active when it was placed, and every one of those rules has a name, a family, and a page.Read the full catalogue, filter it by layer or family, and open any rule to see exactly what it protects and whether your organisation set it hard or soft.
Want to see the same idea applied to one roster instead of the catalogue in the abstract? Check Solution names the exact rule, the exact shift and the exact person behind any violation, on demand, on your own roster.
A person can always overrule it
The solver proposes. A person can lock, edit, or refuse.
A planner can lock a shift so no re-solve ever touches it, hand-place an assignment directly, or leave a slot open rather than accept what the solver proposed. A locked shift always wins over the solver, including over an automatic trainee or support pairing. Nothing here removes a person's judgement. It removes the tedium of checking a thousand combinations by hand every time that judgement is exercised.
The engine
How it decides
Construction, local search, hard and soft rules, and what “optimal” means.
Every rule, named
The rule catalogue
Every rule the engine can enforce, compiled from the product on every build.
Said plainly
What it does not do
The product-wide limits page. If it isn't there, it isn't a claim we make.
Ask us the question you actually have.
If there is a version of “does it learn from us” we have not answered here, ask it directly. We would rather answer it in a working session than have you guess.