Skip to content

Design to operational readiness

Trigger

A solution design is becoming build/release ready and must prove it can be operated safely before go-live.

Intended outcome

The receiving service organisation explicitly accepts an evidenced, supportable and recoverable service.

Workflow steps and gates

Step Accountable role Activity Handover Gate
1 Solution Architect defines the target architecture, NFRs, dependencies and failure modes solution architecture and decision records Quality attributes and failure modes are explicit and testable
2 Security Architect defines security controls and residual security risks security architecture and control requirements Controls trace to risks and objectives
3 Operational and Technology Resilience Architect tests the design against failure domains, impact tolerances and recovery paths resilience architecture and validation scenarios Resilience claims identify dependencies, failure domains and validation method
4 Site Reliability Engineer defines SLOs, observability, alerting and operability signals SLO/monitoring design and runbook requirements Alerts are actionable and every SLO has a data source
5 Service Transition and Operational Readiness Manager assembles and assesses operational acceptance evidence operational readiness assessment and evidence pack Every readiness criterion is pass/fail/waived with evidence and owner
6 Change Manager checks the production change path and risk-class approval change authorisation decision Change risk and readiness evidence match the approval route
7 IT Service Owner accepts service ownership and residual operational risk service acceptance Support ownership, SLOs and residual risks are explicitly accepted

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 design-to-operational-readiness 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.