Healing-as-Code
Understand the long-term direction: a versioned, policy-controlled recovery lifecycle whose decisions and outcomes can be inspected.
A direction, not a shipped executor
Healing-as-Code is the project's direction from diagnosis toward the full lifecycle: detect, triage, diagnose, plan, approve, remediate, verify, and learn. As of 0.0.8, Lumis SDK ships diagnosis-centered behavior plus typed, tested contracts for planning (versioned playbooks and evidence-linked proposals), approval (idempotent, attributable decisions), verification (explicit passed/failed/unknown/timed-out records), and learning (conservative truth promotion)—but no core action executor.
Required properties
- Every executable action must come from a typed, versioned allowlist (a playbook).
- Policy must evaluate risk before approval, and unknown actions must fail closed.
- High-risk and irreversible work cannot auto-approve.
- Proposals must be linked to their diagnosis and evidence by digest, and must expire.
- Audit events must make every transition inspectable.
- Execution must be idempotent and bounded.
- Verification must follow execution before recovery is confirmed.
- Learning must use confirmed outcomes, not model confidence.
How the roadmap approaches it
| Phase | Direction | Status |
|---|---|---|
| Phase 1 — trustworthy Python foundation | Stable contracts, deterministic diagnosis, guarded proposals, verification learning, and supply-chain hardening. | Complete; releasing as 0.1.0 |
| Phase 2 — model, prompt, and bounded agents | Provider-neutral model routing, prompt packages, read-only evidence planning, loop guards, and evaluation gates. | Next |
| Phase 3 — intelligence, memory, and integrations | Correlation, lineage, rule analytics, memory quality, semantic retrieval, and demand-led integrations. | Planned |
| Phase 4 — guarded recovery and ecosystem | Side-effect-aware plugin contracts, executor/verifier protocols, signing, and policy conformance. | Planned; RFC-gated |