Skip to content

Incident to permanent fix

Trigger

A service degrades or fails.

Intended outcome

Service restored, cause removed, and a control changed so the class of failure does not recur.

Workflow steps and gates

Step Accountable role Activity Handover Gate
1 Service Desk Analyst captures impact and what the user was trying to do incident record with impact and urgency Symptom-only records are returned for clarification
2 Incident Manager classifies by business effect and drives restoration priority, working hypothesis, comms cadence Priority from business impact, not technical severity
3 Site Reliability Engineer restores service while preserving evidence service restored; evidence preserved Evidence kept before destructive recovery
4 Major Incident Manager takes command when impact exceeds normal handling command log, stakeholder comms, notification assessment Comms on a fixed clock; regulatory clocks assessed
5 Problem Manager establishes the systemic cause problem record with root cause and known error "Human error" alone rejected as a root cause
6 Technical Lead designs the permanent fix fix approach and effort The fix addresses the cause, not the latest symptom
7 Change Manager authorises the fix through the normal path change authorisation Emergency path used only where justified, and logged
8 Detection Engineer or Observability Engineer closes the detection gap the incident exposed new or tuned alert with a runbook The alert would have fired earlier for this failure
9 Continual Improvement Manager confirms the improvement happened and held measured recurrence rate Baseline measured before the change, not asserted after

Running this workflow: operator and implementer boundary

In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.

For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.

How to use this workflow

A practical prompt pattern is:

Apply the incident-to-problem workflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.

Operational interpretation

The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.