# x2Clouds — illustrative delivery pack Version: 1.0 — 3 October 2026 **Original illustrative example. All workload details and evidence below are synthetic. No customer environment was reviewed, no cloud change was executed and no acceptance check has passed.** ## Scenario and boundary One Azure application has a manually operated infrastructure release process. Its example change record does not identify a recovery owner or link to a validated recovery procedure. **Scope:** One agreed non-production workload and one infrastructure delivery workflow. Production rollout, wider subscriptions and ongoing support require separate agreement. ## Finding EX-01: Make the recovery decision and owner explicit. **Provisional priority:** High before the next production release ### Observation in this example The synthetic change record names the implementer but has no recovery decision owner. Its runbook contains no linked validation result. ### Why it matters If a release fails, the team may not know who decides to stop or recover, or which procedure has been demonstrated. ### Priority and rationale Resolve before a production release because recovery ownership affects service continuity. Reassess this priority if a current, accepted procedure and accountable owner already exist. ### Evidence and confidence Based only on the synthetic change record and runbook outline. Actual permissions, recoverability and business impact have not been assessed. ### Next action and owner The client service owner names the release/recovery approver. The delivery lead prepares the scoped workflow, acceptance checks and recovery exercise for approval. ### What remains unknown Workload criticality, recovery objectives, data dependencies, the approved recovery method and the result of any rehearsal. ## Proposed implementation ### 1. Agree the boundary Record the workload, repositories, environments and exclusions. Confirm the client approver, evidence access and temporary-access expiry. **Output:** Scope and ownership record ### 2. Prepare a reviewable change Version the agreed infrastructure change, identify its impact and approval point, and document the change-specific stop and recovery procedure. **Output:** Change proposal and runbook ### 3. Demonstrate and transfer Run the agreed non-production checks. Capture actual results and have the receiving engineer demonstrate the operating procedure before acceptance. **Output:** Acceptance record and handover ## Acceptance criteria — no checks executed ### A1. Scope and intended change - **Expected:** The named workload and planned changes match the approved scope; unrelated resources are excluded. - **Evidence required:** Approved inventory, reviewed change/plan and resource-owner sign-off. - **Accountable role:** Client technical owner - **Stop when:** Unexpected resources or unexplained changes appear. - **Status:** Not executed — example criteria - **Actual result / evidence reference / review date:** Not recorded; no exercise executed. ### A2. Approval before change - **Expected:** The agreed approver reviews the intended change before any apply or deployment action. - **Evidence required:** Versioned proposal and approval record for the specific change. - **Accountable role:** Release approver - **Stop when:** Approval is missing, expired or does not match the proposed change. - **Status:** Not executed — example criteria - **Actual result / evidence reference / review date:** Not recorded; no exercise executed. ### A3. Non-production validation - **Expected:** The receiving engineer can run the agreed workflow and verify the stated application/infrastructure checks. - **Evidence required:** Run identifier, actual check results, reviewer and recorded exceptions. - **Accountable role:** Receiving engineer - **Stop when:** Any agreed acceptance criterion fails or the result is unavailable. - **Status:** Not executed — example criteria - **Actual result / evidence reference / review date:** Not recorded; no exercise executed. ### A4. Recovery exercise - **Expected:** An authorized exercise demonstrates the agreed recovery procedure within the test scope. Record actual results against the agreed objectives. - **Evidence required:** Exercise plan, approval, observations and unresolved limits. - **Accountable role:** Recovery decision owner - **Stop when:** The recovery method, safe test conditions or authorization are missing. - **Status:** Not executed — example criteria - **Actual result / evidence reference / review date:** Not recorded; no exercise executed. ### A5. Ownership and close-out - **Expected:** The client owns the repository, state and deployment identities; documentation and remaining work are accepted, and temporary access is removed or explicitly extended. - **Evidence required:** Owner register, handover acknowledgement and access close-out record. - **Accountable role:** Client service owner - **Stop when:** No receiving owner, unaccepted handover or unaccounted temporary access. - **Status:** Not executed — example criteria - **Actual result / evidence reference / review date:** Not recorded; no exercise executed. ## Handover contents ### Ownership Repository and state locations, deployment identities, the receiving engineer and the client service owner. Use the client’s private record for real identifiers. ### Operations How to run the workflow, inspect a failure, stop a change and use the agreed recovery procedure. Include known limits and remaining dependencies. ### Support boundary Agreed support window, intake route, triage and engineering escalation owners. Ongoing coverage is a separate scoped commitment. ## Acceptance and next decision Complete only after the agreed evidence is reviewed and the authorized client owner accepts the deliverables. A missing result stays open; an illustrative checklist is not a successful test. Use this example to discuss a suitable work product. It is not a client case study, proof of a cloud deployment, a contractual scope or a guarantee of recovery. View the example: https://www.x2clouds.com/delivery-example Discuss a scope: https://www.x2clouds.com/devops-automation#contact