No runtime when expected.

RTU is silent during its scheduled operating hours with communications confirmed healthy — indicating an equipment-side problem (power loss, control disable, mechanical failure). A communications-failure alarm is a separate event at the platform layer.

01 Detail

Trigger, action plan, and escalation criteria.

optimization_metric hvac high essential tier AI: hybrid

Related metric: runtime
Trigger: runtime_hours_in_scheduled_window ≈ 0 (with comms-health confirmed)
Value drivers: Customer experience Avoided truck rolls
Preconditions: Site schedule + zone-to-RTU map. Platform-layer comms-health signal is healthy.
Human role: Primary when AI cannot restore operation; coordinates dispatch and store communication.
Action plan: (1) Attempt remote restart or re-enable. (2) Cross-check Temperature Compliance — is the space at immediate comfort risk? (3) If the remote attempt fails or comfort risk is imminent, dispatch.
Escalation: (1) Remote restart fails on first attempt → dispatch within SLA; do not retry the remote action. (2) Silent RTU during peak occupancy → out-of-cycle notification to client ops; vendor coordination by the Keedian account manager. (3) Multiple RTUs silent at the same site → suspect site-wide power or control-panel issue; engage facilities lead, not vendor. (4) Recurrence > 2 events per quarter at the same RTU → flag for replacement evaluation at the MBR.
Prevention: (1) Routine pre-business-hours operational check by Keedian Agentic Ops — catches a silent RTU before the store opens, not after the comfort complaint. (2) RTU-to-zone mapping kept current at install and at every site change (remodel, equipment swap) — stale maps misroute the alarm and delay dispatch. (3) Recurrence ledger per RTU — flag any RTU with > 2 silent events per quarter for replacement evaluation before it fails outright.