Housekeeping & Maintenance Ops · Documentation
Architecture
Housekeeping & Maintenance Ops's pipeline, its owned data, the events it emits/consumes, and what is out of scope.
← Housekeeping & Maintenance OpsPipeline, owned data, and events
App 14 owns the `work_order` entity (the C5 `demo_eco_*` slice, ready for a Stage-2 Drizzle/Postgres swap) and reads shared service requests, staff and app 43's published shifts. It consumes `service.requested` (from 07) and emits `work_order.created`. Assignment is a deterministic scorer — skill match (required) → on-shift (preferred) → least current load — run idempotently so a double-delivered event never creates a duplicate order. OPERATE, the status board, and the SLA badge are real; loading/empty/error states are handled on every surface.
AI posture, the data invariant, and out of scope
App 14 is AI-assist, not metered: every stage is $0 in both Cloud and OSS modes — there is no model call, and the inspector reflects that. The data invariant holds: owner writes are canonical and audited; a viewer's status changes are an ephemeral, own-credential overlay the owner never sees, cleared on reset. Out of scope and labelled: no real staff devices, notifications, or backend — assignment and tracking are real, the human dispatch is simulated. No PII, no real imagery.