Change Management Gate Check Prompt

This prompt is designed for DevOps and platform engineering teams who need an automated, auditable gate check before a production change proceeds. It evaluates a proposed change against your organization's change management policy, producing a structured decision with risk classification, required approvals, testing evidence verification, and rollback plan assessment. Use this prompt inside a CI/CD pipeline, a deployment approval workflow, or an internal platform gateway where human reviewers need consistent, policy-grounded evaluations before they approve or reject a change.

The ideal user is a platform engineer embedding this prompt into a deployment pipeline, a release manager using it to standardize change review, or a compliance lead who needs every production change to have a documented, policy-referenced gate decision. The prompt requires three inputs: the full text of your change management policy, a structured description of the proposed change (including scope, affected systems, and risk self-assessment), and any evidence artifacts such as test results, monitoring dashboards, or previous approval records. Without the policy text, the prompt cannot ground its evaluation and will produce unreliable results.

This prompt does not execute the change. It only produces a gate decision. Human approval is still required for any change above low risk. Do not use this prompt for real-time operational actions like auto-scaling events or alert acknowledgments—those require runbook automation, not policy deliberation. Do not use it as a substitute for a security review or a capacity planning exercise; it checks compliance with a provided change management policy, not technical correctness. If your policy is unwritten or exists only as tribal knowledge, write it down first. The prompt is only as good as the policy text you provide.

After reading this section, you should have a clear picture of where this prompt fits in your deployment workflow. Next, copy the prompt template, adapt the placeholders to your policy and change schema, and wire it into your pipeline with the validation and human-review steps described in the implementation harness.

This prompt acts as a policy enforcement gate before a production change proceeds. It evaluates a proposed change against your organization's change management policy, producing a structured decision with risk classification, required approvals, testing evidence verification, and rollback plan assessment. The template is designed to be wired into a CI/CD pipeline, deployment approval workflow, or internal platform, ensuring every change is reviewed against consistent criteria before execution.

textCopy
You are a Change Management Gate Check agent. Your job is to evaluate a proposed production change against the provided change management policy and return a structured gate decision. You do not approve changes; you assess compliance and surface risks, missing evidence, and required approvals.

## POLICY
[CHANGE_MANAGEMENT_POLICY]

## PROPOSED CHANGE
- Change ID: [CHANGE_ID]
- Requester: [REQUESTER]
- Service/System: [SERVICE_NAME]
- Description: [CHANGE_DESCRIPTION]
- Change Type: [CHANGE_TYPE] (e.g., code deploy, config change, database migration, infrastructure modification)
- Risk Self-Assessment: [SELF_ASSESSED_RISK]
- Planned Window: [CHANGE_WINDOW]
- Affected Components: [AFFECTED_COMPONENTS]

## EVIDENCE PROVIDED
- Testing Evidence: [TESTING_EVIDENCE]
- Rollback Plan: [ROLLBACK_PLAN]
- Monitoring Plan: [MONITORING_PLAN]
- Communication Plan: [COMMUNICATION_PLAN]

## CONSTRAINTS
- Evaluate strictly against the provided policy text. Do not infer requirements not stated.
- If the policy references external standards or regulations not provided, flag this as a missing dependency.
- Do not approve changes that lack required evidence or approvals.
- Flag any ambiguity in the change description that prevents a clear assessment.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "gate_decision": "APPROVED" | "CONDITIONAL_APPROVAL" | "REJECTED" | "NEEDS_REVIEW",
  "risk_classification": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
  "policy_checks": [
    {
      "policy_requirement": "<specific requirement from policy>",
      "status": "PASS" | "FAIL" | "INSUFFICIENT_EVIDENCE" | "NOT_APPLICABLE",
      "evidence_found": "<what evidence was provided or what was missing>",
      "blocking": true | false
    }
  ],
  "required_approvals": [
    {
      "role": "<role required>",
      "reason": "<why this approval is required, citing policy>",
      "status": "OBTAINED" | "PENDING" | "NOT_REQUIRED"
    }
  ],
  "testing_evidence_assessment": {
    "sufficient": true | false,
    "gaps": ["<specific gaps in testing evidence>"],
    "minimum_required": "<what the policy requires for this change type>"
  },
  "rollback_plan_assessment": {
    "exists": true | false,
    "viable": true | false | "UNCLEAR",
    "concerns": ["<specific concerns about the rollback plan>"]
  },
  "blocking_issues": ["<list of issues that prevent approval>"],
  "conditions_for_approval": ["<list of conditions that must be met for conditional approval>"],
  "summary": "<one-paragraph summary of the assessment and reasoning>"
}

## INSTRUCTIONS
1. Parse the proposed change and identify the change type and risk profile.
2. For each requirement in the policy, determine if it applies to this change type.
3. Check whether the provided evidence satisfies each applicable requirement.
4. Identify all required approver roles based on risk classification and change type.
5. Assess the testing evidence and rollback plan for completeness and viability.
6. If any blocking issues exist, set gate_decision to REJECTED or NEEDS_REVIEW.
7. If all requirements are met but approvals are pending, set gate_decision to CONDITIONAL_APPROVAL.
8. If all requirements are met and all approvals are obtained, set gate_decision to APPROVED.
9. Do not fabricate evidence. If evidence is missing, report it as INSUFFICIENT_EVIDENCE.
10. Cite specific policy clauses in your reasoning.

To adapt this template, replace each square-bracket placeholder with real data from your change management system. The [CHANGE_MANAGEMENT_POLICY] placeholder should contain the full text of your organization's policy, including change type definitions, risk classification criteria, required approver roles per risk level, testing evidence requirements, and rollback plan standards. If your policy is long, consider pre-processing it into a structured summary or using a RAG retrieval step to pull only the relevant sections for the change type being evaluated. The output schema is designed to be machine-readable for downstream automation: use gate_decision to block or allow pipeline progression, blocking_issues for operator notifications, and required_approvals to route approval requests to the correct teams. For high-risk changes, always require a human to review the full assessment before acting on the gate decision.

The Change Management Gate Check prompt is designed to sit directly in the path of a production deployment pipeline, acting as a policy-enforcement gate before any apply or deploy command is executed. The harness should invoke this prompt after a change request is fully assembled—including the proposed diff, the target environment, the risk classification from the requesting team, and any linked incident or maintenance window metadata—but before infrastructure-as-code tools or orchestration engines are given execution permissions. The prompt is not a replacement for static policy-as-code checks; it is a reasoning layer that evaluates whether the assembled evidence satisfies the organization's change management policy, which often contains nuanced, context-dependent requirements that are difficult to encode in rigid rules.

The implementation should wrap the LLM call in a validation and retry layer. The prompt's output schema must be strictly validated: the gate_decision field must be one of APPROVED, REJECTED, or NEEDS_REVIEW; the risk_classification must match the organization's defined tiers; and any REJECTED decision must include a non-empty blocking_reasons array with specific policy references. If the model returns malformed JSON or an invalid enum, the harness should retry up to two times with an error message injected into the retry prompt, such as: "Your previous response failed schema validation. The field gate_decision must be one of: APPROVED, REJECTED, NEEDS_REVIEW. Please correct your output." After two failed retries, the harness should escalate the change request to a human change manager with the raw model output and a diagnostic note. For high-risk changes, configure the harness to force a NEEDS_REVIEW outcome by setting the [RISK_LEVEL] placeholder to HIGH and requiring explicit human approval in the pipeline before the gate can be passed.

Logging and audit trail construction are critical for this prompt. Every invocation should be logged as an immutable record containing: the full prompt with all substituted variables, the model's raw output, the validated and parsed output, the retry count, the model version, and a timestamp. This log becomes the audit evidence that a change management gate check was performed. For changes that are approved, the log should be attached to the deployment record. For changes that are rejected or escalated, the log should be routed to the change advisory board's review queue. Avoid wiring this prompt directly to an auto-approval path for any change that modifies customer-facing infrastructure, authentication systems, or data storage layers. The harness should treat NEEDS_REVIEW as a blocking state that requires a human to examine the model's reasoning, the proposed change, and the policy citations before manually advancing the pipeline.