Architecture

Five stages run over one inbound signal: intake (receive) · perceive (classify + score — the one metered stage) · enrich (attach zone + room context) · rules → priority (deterministic keyword map) · confirm-gate (≥ 70% confidence is eligible for operator dispatch; below it is held for human confirmation). Each stage emits a trace row the shared inspector renders identically; the perceive row alone carries a cost, mode and model.

App 07 owns the `service_request` entity (modelled here as the C5 `demo_eco_*` slice, ready for a clean Stage-2 swap to Drizzle/Postgres) and reads shared property, zone and room context. On a confirmed dispatch it produces `service.requested` on the shared event bus — its single outbound coupling — which app 14 consumes. The data invariant holds: owner writes are canonical and audited; a viewer's confirm is an ephemeral, own-credential overlay the owner never sees, cleared on reset, and can never mutate a canonical row.

The one metered stage is `perceive`, simulated. In Cloud mode it bills a representative per-call cost (≈ $0.003) against the model `claude-haiku-4-5`; in OSS mode it is recorded at $0 against a local stand-in (qwen2.5-7b-instruct, recorded on M4 hardware), and replays a slightly lower confidence than Cloud on the same input — an honest gap rather than a flattering one. A per-session cost cap fails closed: once Cloud spend would cross the session budget, the stage falls back to the $0 OSS recorded path rather than fabricate an over-budget call. Every other stage is deterministic and $0 in both modes.

There is no real model call, no real backend, and no real guest devices — the inbound signals are synthetic, the perception output is canned-but-plausible, and there are no real staff notifications. All of it is labelled in-surface. No real imagery, no PII, and no production prompts or proprietary metrics appear anywhere.