Abstract framing
The domain layer is the category of staffing/problem instances. Objects are time-bounded domain states: sites, lines, shifts, needs, candidates, qualifications, and policy declarations. The primitive solver boundary is the category of compiled feasibility states. The system is not an optimizer category and not a production-flow category.
Objects and morphisms
| Layer | Object | Meaning of a morphism |
|---|---|---|
| Domain | Shift, Need, Candidate, Qualification, Site, Line | A pure domain transform: add/remove metadata, derive sample variants, or compile to solver input. |
| Compiler | Compiled demand units and hard constraints | Preserves feasibility-relevant structure while removing domain naming and grouping details. |
| Solver | Partial assignment states | Extends or rejects an assignment candidate under hard constraints; no ranking or optimization morphism. |
| Regrouping | Primitive failure witnesses | Lifts primitive failures back into failed-need / coverage / candidate-blocker explanations. |
Preserved structure
- Exact qualification membership and validity windows.
- One assignment per atomic demand unit.
- Site and line identifiers as regrouping metadata when present.
- Coverage, availability, pattern, rest, and utilization as hard constraints.
- Feasible/infeasible as a binary result, not a scored preference order.
What is quotiented away
- Presentation order.
- Human-friendly labels and grouping names.
- Any non-feasibility-relevant coincidence in how a need is authored.
- Internal branching choices during search.
What is preserved only partially
- Failed needs are preserved, but candidate blockers may be regrouped under them.
- Site and line scope are preserved where the rule carries them.
- Rolling-window and temporal reasoning is preserved semantically, not as a direct trace of search.
Where the boundary is lossy
- Multiple primitive failure paths can map to one domain explanation.
- A single failed need can absorb several candidate-level blockers.
- Coverage regrouping does not retain the entire solver search tree.
Boundary statement
If you want a complete staffing optimizer, this kernel is only a projection. If you want a feasibility functor from domain staffing descriptions to binary solve outcomes plus regrouped explanations, this is the intended boundary.
Practical reading: compile the domain, solve the compiled state, then regroup the witness. Do not expect the solver to preserve every domain distinction literally; expect it to preserve the distinctions that matter to hard feasibility.