Constraints before coverage
A roster is a promise made weeks ahead of the day it covers. The roster engine treats scheduling as a constraint problem with a public record: declare the constraints, generate coverage against them, surface every conflict explicitly, and publish only what a reviewer has seen.
Inputs the engine works from
- Availability — when each person can work, declared per location.
- Qualifications — the roles and certifications each position requires and each person holds.
- Hour and rest policy — weekly and pay-period limits, spacing rules, and overtime boundaries, configured as operator policy.
- Coverage demand — the positions each location needs filled, by day and interval.
- Location authorization — which people are granted to work at which locations, inside the brand's boundary.
What the engine does with them
Generation proposes a roster that satisfies the declared constraints. Where constraints conflict — more demand than qualified availability, a limit that cannot hold — the conflict is surfaced as a named exception for the scheduler, not silently resolved by bending a rule the record says exists. Publication is a review step: a named operator confirms the roster, and the confirmation is recorded.
After publication
Life happens after the roster is published. Call-outs and swaps move through the shift marketplace as explicit states — PROPOSED, PENDING, AWAITING_REVIEW, COMPLETED — with the same constraint checks re-evaluated before a trade finalizes. How a shift trade settles walks through the state machine. A change that would break an hour limit or a qualification rule does not proceed; it is recorded as a denial, and the coverage gap stays visible.
What this page does not promise
No fill rates, no time-to-cover figures, no labor-cost percentages. Those numbers belong to your locations and are read in the authenticated console, not asserted on a public page.