Guarded recovery
Follow a full recovery lifecycle while keeping policy, approval, actuation, verification, and learning explicit.
Lifecycle and current status
| Stage | Current status |
|---|---|
| Detect | Local-log input, webhook normalization, and incident-source contracts; production detection stays external. |
| Triage | Deterministic classification, severity, and missing context. |
| Diagnose | Explainable legacy and structured rules; optional model gateway behind explicit policy. |
| Plan | Versioned playbooks and evidence-linked, bounded, expiring proposals selected through default-deny policy. |
| Approve | Revision-pinned, attributable, idempotent decisions; high risk never auto-approves. |
| Remediate | No core executor. Future work requires an RFC, allowlists, policy, audit, limits, and sandbox tests. |
| Verify | Explicit passed, failed, unknown, and timed-out records; non-passing outcomes escalate. |
| Learn | Conservative truth transitions, reusable-only retrieval, and deterministic replay evaluation. |
Recommendation-only orchestration
run_guarded_lifecycle retrieves context, diagnoses, proposes a plan, requests approval, records a verification result, and writes audit events. It intentionally has no action executor and composes no infrastructure adapter—persistence and reporting attach separately through their own ports.
Failure stays honest
Verification results are first-class: failed results become rejected memory, and unknown or timed-out results remain unconfirmed and require escalation. The framework never reports recovery it cannot support with an explicit confirmed resolution. This property—no false recovery claims—is a core invariant, not a convention.