Skip to content

Resilience validation

Trigger

A critical service or architecture needs evidence that resilience, RTO/RPO and dependency assumptions work under realistic failure.

Intended outcome

Business criticality, dependencies and recovery objectives are validated through exercised failure scenarios, findings are remediated and retested, and residual resilience risk is accepted by the correct authority.

Workflow steps and gates

Step Accountable role Activity Handover Gate
1 Business Continuity Manager confirms business criticality, impact tolerances and priority services/processes business criticality baseline Criticality and tolerances have business ownership
2 Operational and Technology Resilience Architect maps technical/supplier/data dependencies and correlated failure domains dependency/failure-domain model No critical path has an unknown/unowned dependency
3 Disaster Recovery Coordinator validates RTO/RPO and recovery sequencing against dependency reality validated recovery objectives Objectives are feasible end to end, not only per component
4 Operational and Technology Resilience Architect defines resilience/recovery architecture and degradation patterns resilience design with failure assumptions Design addresses single/shared failure modes and measurable outcomes
5 Test Manager builds the exercise plan, entry/exit criteria, injects and evidence capture method approved exercise plan Test design can falsify the resilience claims and protects production safety
6 Chaos and Resilience Engineer executes authorised failure experiments/exercises and captures telemetry exercise evidence Execution matches approved scope and evidence is attributable
7 Control Tester independently evaluates evidence and records control/resilience findings findings register Findings distinguish observation, criterion, impact and evidence
8 Operational and Technology Resilience Architect coordinates owned remediation across architecture, operations and suppliers remediation plan Every material finding has owner/date/design response
9 Test Manager retests failed claims after remediation using comparable criteria retest result Critical findings are demonstrated fixed, not administratively closed
10 IT Service Owner accepts demonstrated resilience or explicitly accepts residual risk within authority resilience acceptance Acceptance states evidence, residual risk and next validation date

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 resilience-validation 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.