EdictumEdictum Control Plane
Failure Modes
Current high-level failure modes for the hosted control-plane path.
AI Assistance
Right page if: you want the current high-level failure model. Wrong page if: you want the retired health/readiness doc for the old server stack. Gotcha: rules are still evaluated locally, so the most important failure boundary is between local enforcement and remote coordination.
The most important current rule is simple:
- enforcement happens locally in the SDK runtime
- the control plane coordinates ruleset delivery, approvals, events, and visibility
Current High-Level Failure Modes
| Failure | What it means |
|---|---|
| API unavailable before connect | server-backed agent cannot complete remote bootstrap |
| API unavailable after connect | remote updates and remote coordination degrade; local runtime still owns enforcement |
| notification delivery failure | notifications can fail without changing the underlying approval record |
| app unavailable | operators lose UI visibility until recovery, but the API/agent boundary is separate |
| stale ruleset name or revoked key | agent bootstrap fails until corrected |
What This Page Does Not Claim
The old docs described Redis workers, readiness probes, drift dashboards, and
old /api/v1/health* semantics from the retired server stack. That is not the
current public documentation baseline.
Last updated on