The framework workflow
See how incident context moves through bounded evidence, deterministic diagnosis, optional reasoning, guarded proposals, verification, and confirmed learning.
1. Normalize bounded context
A consuming application creates an IncidentInput from whatever detected the failure—a local log, a webhook payload, or its own monitoring. Evidence providers then contribute typed, bounded context: EvidenceService enforces timeouts, kind filtering, duplicate handling, item and character budgets, and optional redaction before anything reaches diagnosis. Provider errors become structured failures, never silent empty successes.
2. Diagnose deterministically first
DiagnosisService evaluates ordered project rules first. A known match returns evidence references and explanation metadata—rule ID, version, priority, matched conditions. An unknown result can route to a ModelGateway only when both an enabled ModelUsePolicy and a gateway implementation are supplied; otherwise the honest unknown result is returned unchanged.
3. Propose and govern
ProposalService selects an action from a versioned, typed playbook, evaluates it against a default-deny policy document, links it to the diagnosis and evidence by digest, and bounds its parameters. The result is an ActionProposal with execution_allowed=false and an explicit expiry. ApprovalDecision records who approved or rejected it and why; high-risk actions can never auto-approve. The guarded lifecycle orchestrator ties context, diagnosis, proposal, approval, verification, and audit together—and intentionally has no action executor.
4. Learn only from confirmation
Operational memory starts as unconfirmed_hypothesis. A human resolution moves it to human_confirmed. A passed verification with an explicit ConfirmedResolution moves it to verification_confirmed through learn_from_verification. Failed verification becomes rejected memory; unknown and timed-out results stay unconfirmed and escalate. Retrieval can be restricted to reusable (confirmed) records only.