各系統格式不同
1. 子系統原生 Telemetry
作用與資料流：各子系統用自己的格式送資料 — 欄位名稱、時間表示法（epoch 毫秒／秒、UTC、本地字串）與數值包法都不同。原樣保留，交給下一步轉換。
原生格式 → 統一 schema
2. 正規化為 Observation
作用與資料流：每個子系統一個 adapter，把原生欄位對映為統一的 Observation；system 與 zone 不由 telemetry 提供，而是從 Building Context 的設備登錄查出。原始 payload 保留在 raw_payload，AI 不覆寫。
明確規則判定
3. 事件（Event）
作用與資料流：依明確門檻與規則，從 Observation 產生可追蹤的 Event，區分原始事實與規則判定。
跨系統關聯
4. 關聯事件（Incident）
作用與資料流：依時間、區域與語意關係，將多個 Event 整合為同一個 Incident，協助管理者掌握跨系統問題。
依建築脈絡查詢
5. AI 脈絡查詢
作用與資料流：AI 透過設備、能力、關係、狀態與歷史紀錄查詢工具，取得 Building Context，作為分析依據。
以證據支持的結構化輸出
6. AI 分析
作用與資料流：整合 Incident 與工具查詢結果，產生附有證據參照的結構化分析，保留推論與事實的區別。
審核依據
7. 人工審核
作用與資料流：管理者依據分析與設備查詢快照核准或拒絕；核准前不送出任何控制指令。