Release Deployment Freeze Architecture Prompt

This prompt is for release managers, SREs, and platform engineers who need to design or audit a deployment freeze architecture. Use it when you are defining freeze scope, exception approval chains, emergency override procedures, or post-freeze verification requirements. The prompt produces a structured review that identifies bypass risks, missing controls, and compliance evidence gaps before the freeze policy goes live. It assumes you have a draft freeze policy, a service catalog, and a known compliance framework.

The ideal user brings a concrete freeze policy document, not just a vague intention. You should have a list of in-scope services, their deployment pipelines, and the compliance standard you are operating under (e.g., SOC 2, PCI DSS, internal change management policy). The prompt works best when you can describe your current exception workflow—who approves, how they approve, and what evidence they require. If you are designing a freeze from scratch, provide your organization's risk tolerance and any prior incident postmortems that motivate the freeze. The prompt will cross-reference your policy against your service catalog to find gaps where a service could be deployed outside the freeze window due to pipeline misconfiguration, permission inheritance, or toolchain bypasses.

Do not use this prompt for general change management outside software delivery or for real-time incident response during an active freeze. It is not designed to evaluate whether a specific hotfix should be deployed right now—that requires an on-call decision prompt with live system context. This prompt also does not replace a formal compliance audit; it prepares your architecture for one by surfacing design-level gaps. If your freeze policy is already live and you are investigating a specific violation, use an incident analysis prompt instead. The output is a design review, not an operational runbook, though it may recommend runbook improvements.

This section provides the core prompt template for a Release Deployment Freeze Architecture review. It is designed to be pasted directly into an LLM interface. The prompt instructs the model to act as a release architecture reviewer, analyzing a described freeze policy against a structured set of criteria. Before using it, you must replace the square-bracket placeholders with your specific context, such as the freeze policy document, your deployment architecture, and your organization's risk tolerance. The template is self-contained and does not require the rest of the article to function, but the surrounding playbook provides essential guidance on validation, failure modes, and implementation.

markdownCopy
You are a senior release architect reviewing a deployment freeze policy. Your goal is to identify risks, gaps, and failure modes in the proposed freeze architecture.

**Freeze Policy to Review:**
[FREEZE_POLICY_DOCUMENT]

**Deployment Architecture Context:**
[DEPLOYMENT_ARCHITECTURE_DESCRIPTION]

**Review Criteria:**
1.  **Scope Clarity:** Is the scope of the freeze (services, environments, deployment types) unambiguously defined? Identify any gray areas.
2.  **Exception Workflow Integrity:** Analyze the exception approval chain. Are the approvers clearly identified? Are the criteria for granting an exception objective and testable? Is there a risk of routine exceptions bypassing the freeze's intent?
3.  **Emergency Override Safety:** Evaluate the emergency override procedure. Does it require a post-hoc review? Does it generate an immutable audit log? Is the blast radius of an emergency change during a freeze clearly understood and minimized?
4.  **Post-Freeze Verification:** Assess the plan for verifying system health after the freeze is lifted. Does it include checks for configuration drift, pending changes that were queued, and a staggered rollout of accumulated deployments?
5.  **Bypass and Compliance Risks:** Identify any technical or procedural mechanisms that could inadvertently bypass the freeze (e.g., direct infrastructure access, ungoverned CI/CD jobs). Evaluate the process for collecting compliance evidence during the freeze period.

**Output Format:**
Provide your review in a structured markdown report with the following sections:
-   **Executive Summary:** A 2-3 sentence risk assessment.
-   **Detailed Findings:** For each of the 5 criteria above, state a finding (Pass/Warning/Fail) and provide a concise explanation.
-   **Top 3 Failure Modes:** List the three most critical ways this freeze architecture could fail in production.
-   **Recommended Mitigations:** Provide actionable recommendations for each Warning and Fail finding.

**Constraints:**
-   Base your analysis strictly on the provided documents.
-   Do not invent scenarios that are not supported by the context.
-   If information is missing to make a determination, state that explicitly.

To adapt this template, replace [FREEZE_POLICY_DOCUMENT] with the full text of your proposed freeze policy, including any runbooks or communication templates. Replace [DEPLOYMENT_ARCHITECTURE_DESCRIPTION] with a description of your relevant systems, such as your CI/CD pipeline design, infrastructure-as-code setup, and service dependency map. The more concrete and detailed your input, the more specific and actionable the model's review will be. For high-risk production systems, the output of this prompt should be treated as a starting point for a formal human-led architecture review, not as the final risk assessment.

After running the prompt, you must validate the output. Check that the model correctly identified the freeze's scope from your document and didn't hallucinate a different policy. The next step is to feed the findings into your team's decision-making process, using the 'Failure Modes and Mitigations' section of this playbook to anticipate common issues. Do not implement the recommendations directly without human engineering judgment, especially for emergency override procedures where safety is paramount.

This prompt is designed to be integrated into a release management platform, CI/CD pipeline gate, or internal change advisory board (CAB) workflow. It should not be used as a standalone chatbot interaction for high-risk production decisions. Instead, treat it as a structured analysis step that takes a freeze policy document and a list of proposed exceptions as input, and returns a risk-assessed review that a human release manager must approve before any freeze override is executed.

The implementation harness should enforce a strict input contract. Before calling the model, validate that [FREEZE_POLICY] contains the freeze window, scope, and approval chain, and that [EXCEPTION_REQUESTS] includes the change description, justification, and requester. On the output side, parse the model's response against the [OUTPUT_SCHEMA] to extract structured fields: exception_id, risk_score, bypass_risk_flags, approval_recommendation, and evidence_required. If the model fails to return valid JSON or omits a required field, retry once with a stricter schema reminder. After two failures, escalate to a human release manager and log the raw response for debugging. For high-risk exceptions (e.g., those touching payment systems or auth services), the harness should require explicit human approval in a ticketing system before the freeze override is applied, regardless of the model's recommendation.

Log every prompt invocation, the model's response, the parsed risk score, and the final human decision in an audit trail. This is critical for compliance evidence collection during post-freeze verification. Wire the harness to your incident management tool so that any emergency override procedure automatically creates a time-bound exception record and notifies the on-call commander. Avoid wiring this prompt directly to automated deployment gates without a human-in-the-loop step; the model can identify risks, but it cannot own the decision to bypass a production freeze.