Who it is for · 1 of 6
“I have to publish in three weeks and I already know two people are going to be short of rest days.”
Ana is a fictional persona, not a named customer. She stands in for the roster officer's actual decisions so the mechanism below can be made concrete.
The decision
Ana does not need to be convinced the product is capable. She needs to know, for these 96 people and this specific cycle, whether the roster she is about to publish holds up, and if it does not, whether she can fix it herself or has to walk it up to her head of unit.
Every required shift filled, against the manpower requirement she configured, not against a guess.
Named people, named shifts, named rule. Not a general sense that overtime looks high.
Or does the scale of what changed mean this one needs her head of unit's name on it too.
Building the month
Before Ana places a single shift, she has told the system how many people, with which qualification, she needs on which day. That demand is the Manpower Requirement (MPR), and it is what the solver optimises against, not an empty calendar she fills by hand.
Sequence MPR
A min/max headcount set per shift type. Morning needs 2 to 4 people, night needs 1 to 2, fixed across the cycle.
Weekly MPR
The same idea, but the number can differ by day of week. Weekday morning needs 4, weekend morning needs 2.
Pattern-based MPR
Demand expressed against a whole reusable shift pattern, such as a 4-on/4-off rotation, rather than shift by shift.
For every day and qualification, the system generates as many shift slots as the requirement's configured maximum, and marks the first of them, up to the configured minimum, as required. The rest sit above minimum as optional capacity Ana can fill or leave open, visible in a demand-first grid (the Position View) rather than buried inside each person's row.
The engine
The solver is a constraint optimiser (OptaPlanner), not a machine-learning model trained on past rosters. It builds a first feasible pass, then spends a time budget improving it against every active rule, scored in three tiers: hard violations dominate, then medium, then soft preferences break ties. How it decides →
Almost none of the rules the solver runs is fixed at one severity in the product's code. Whether "minimum rest time" is a hard stop or a weighted preference, and what the actual threshold is, comes from settings Ana's unit chose in Constraints Settings, not from one rulebook JLG wrote for everyone.configured
She can lock a shift so no re-solve ever touches it, hand-place an assignment directly in the Workbench, or work the Position View to add, remove or mark a slot required. A locked shift always wins over the solver, including over an automatic trainee or support pairing.
Before she publishes
Check Solution takes the roster exactly as it stands, solved, hand-built, or a mix of both, and re-scores it against every active rule in seconds, without changing a single assignment. See Check Solution →
For Ana's worry line, that means: if two people are short of rest days, Check Solution names them. The score bar splits into hard score, unassigned shifts and soft score, and hovering any of the three opens the exact rule that is firing, for example "There is a minimum rest gap between two duties", against the exact shift and the exact person. When the roster is clean, it says so. When it is not, Ana is looking at a list, not a hunch.
After she publishes
Every published shift keeps an append-only record of its own previous states: the template version at the time, a timestamp, and, usually, a reason such as leave approval, swap approval or manual publish. Hovering a shift after a republish shows what it looked like before.
Be precise about what this is. It is a real, working "what changed and roughly why" trail, useful the day a controller or a head of unit asks why their Tuesday moved. It is not yet a hardened, tamper-evident audit log, and some approval types are still recorded under a generic reason rather than the specific trigger. Ana can tell you what changed. Treat "prove nothing was altered outside process" as a separate, harder claim this does not yet make.
Publishing
Override
An in-place correction. Version number does not move. Ana can do this herself.
Minor
Version ticks up by one. Still delegable to any authorised planner, Ana included.
Major
Version rounds up to the next multiple of ten, so publishing Major from version 23 produces version 30. A unit can require the head of unit to sign this one, not Ana.configured
This is a mechanism, not a policy statement on this page: a permission gate keyed to how much changed, so a routine correction does not wait on anyone, and a real overhaul cannot go live on Ana's signature alone if her unit decided it shouldn't.
A working session is 45 minutes with your own roster on screen, not a canned demo. Bring the cycle where you already suspect a rest-day shortfall and we will run Check Solution against it.
Who else will ask, and what they will want
