Short framing
The core question is simple: can a set of time-bounded staffing needs be filled by qualified, available candidates without violating hard rules?
If your mental model includes sequencing, optimization, overtime choice-making, or production flow, that is already beyond this boundary.
Recurrence types now exist in the package surface, but recurrence expansion is still not available as end-user behavior. The current boundary keeps recurrence domain-side and finite-horizon focused.
What you give the system
| Domain concept | What it means here |
|---|---|
| Site | Scoping context for shifts and local staffing expectations. |
| Line | Where a need belongs and how coverage is grouped back in explanations. |
| Shift | A time interval on a date, possibly site-scoped. |
| Need | A role requirement on a shift, compiled into atomic demand units. |
| Candidate | A person who may be eligible, subject to qualifications and availability. |
| Qualifications | Exact-match capabilities with validity windows. |
| Availability / rules | Hard limits such as time off, shift-pattern rules, rest, and utilization max. |
| Recurrence | Domain-side template and exception types exist; expansion into concrete input is still planned. |
What the solver actually works on
Domain input
Shifts, needs, candidates, qualifications, availability, and hard rules.
Compiled boundary
Atomic demand units, eligibility checks, overlap checks, and hard constraints.
Solver state
A feasibility search over assignments, not a schedule optimizer or sequencing engine.
What you get back
- Feasible: a complete assignment set.
- Infeasible: regrouped explanations in domain terms.
- Explanations: failed needs first, with supporting blockers nested underneath.
- Metadata: site and line identifiers are preserved when they matter to the caller.
What is not in the current model
| Bucket | Examples |
|---|---|
| Explicitly out of scope | Production sequencing, machine routing, optimization, soft preferences, fairness ranking, and line-balancing as a search objective. |
| Not modeled yet but plausible next expansions | Overtime cost, preference weights, richer site/line hierarchy, recurrence templates and exceptions, substitution lattices, and more advanced staffing policy layers. |
| Common user assumptions that do not currently hold | The solver does not pick the “best” schedule, does not infer substitutions between qualifications, and does not treat partial fill as a successful solve. |
Good fit / poor fit
| Good fit | Poor fit |
|---|---|
| Shift staffing with exact qualifications and hard rules. | Production sequencing, machine routing, or line-balancing optimization. |
| Site-local or line-local coverage expectations. | Soft preference ranking or cost minimization. |
| Availability, rest, consecutive-day, and rolling max constraints. | Choosing the “best” schedule among many feasible ones. |
Worked example
A plant has one site, two lines, and one day shift. The shift needs an operator on each line and a lead on line A. One candidate is qualified for the lead role, one candidate is unavailable for the forklift role, and one candidate is restricted by a shift-pattern rule.
The compiler turns that into atomic demand units and hard eligibility checks. If the lead qualification is removed, the solver returns infeasible. The regrouped explanation points to the failed need on the lead role rather than exposing primitive witness details first.
Domain input -> compileDomain(...) -> solver boundary: demand units + eligibility + hard rules -> solve(...) -> feasible assignments OR regrouped explanations