Staff & Workforce Scheduling · Documentation
Architecture
Staff & Workforce Scheduling's pipeline, its owned data, the events it emits/consumes, and what is out of scope.
← Staff & Workforce SchedulingPipeline, owned data, and coupling
App 43 owns the `staff_shift` entity (the C5 `demo_eco_*` slice, ready for a Stage-2 Drizzle/Postgres swap) and reads shared demand and staff. Its pipeline is read-signals → forecast (metered) → roster-solve → labour-check. Its coupling to app 14 is through shared data, not an event: publishing the roster changes which staff app 14 sees as on-shift. The labour-cost total feeds app 27. Loading/empty/error states are handled on every surface, including the empty "no roster yet" prompt before the first solve.
Metered AI, the data invariant, and out of scope
The one metered stage is `forecast`, simulated. Cloud mode bills a representative per-call cost (≈ $0.004) against `claude-haiku-4-5`; OSS mode is recorded at $0 against a local stand-in (qwen2.5-7b-instruct, recorded on M4); the per-session cost cap fails closed to the $0 OSS path. The roster solve and labour cost are deterministic and $0. The data invariant: auto-roster is an owner-only canonical write (audited) — `upsertShifts({ ownerOnly })` throws for a viewer; a viewer's swap/leave is an ephemeral overlay the owner never sees, cleared on reset. Out of scope and labelled: no real HR/payroll backend, no real staff notifications, no PII.