Architecture

Roll up event-log volume into KPI series → detect (trailing-window z-score per day + first-third/last-third drift) → board (spike/drop/drift, newest-first) → acknowledge (operator, ephemeral) or explain (metered AI-assist). Detection is a pure function with no randomness at call time, so the board is reproducible.

Owns the KPI threshold config and anomaly status (demo_eco_c8_kpi, demo_eco_c8_anomaly). Reads the derived KPI series from the shared event roll-ups. The data invariant holds: threshold and status edits are owner-only — C8 rejects viewer writes — persisted canonical and setWhere-guarded, while an operator's acknowledgement is ephemeral to their view.

Emits kpi.threshold_breached on acknowledge; each Explain emits cost.logged into the shared ledger. The explain stage is dual-mode (Cloud `claude-haiku-4-5` cost-capped/fail-closed · OSS recorded $0); detection is deterministic and $0. The lineage that feeds this app is documented in #28's lineage graph.

KPI series are generated from synthetic history rather than a live stream, and the AI explanation is a simulated metered narrative over recorded behavior. No real metrics, alerting integrations, or PII. In Stage-2 the same method surface maps to real repositories and a real detection job with no UI change.