Production Deployment Gate Approval Prompt

This prompt is for DevOps and release engineering teams who need an AI system to evaluate a production deployment request against pre-defined gates before any code reaches production. It ingests structured evidence about the deployment (test pass rates, change size, affected components, timing windows, and on-call availability) and outputs a gate decision with blocking conditions and required manual approvals. Use this prompt when you want a consistent, auditable gate check that encodes your release policy without hardcoding every rule in application code.

The ideal user is a release manager or platform engineer integrating this prompt into a CI/CD pipeline or a deployment approval chatbot. The prompt requires a complete evidence package as input: quantitative metrics like test pass percentage and lines changed, qualitative context like a change risk description, and operational data like the deployment window and on-call roster. When these inputs are provided, the prompt acts as a deterministic policy enforcer, applying the same rules to every request. However, do not use this prompt when the deployment evidence is incomplete or when the gate policy itself is still being drafted; the model will make assumptions that should be explicit policy decisions, potentially approving a deployment that a human would block or blocking one that should proceed.

This prompt is not a replacement for a deployment orchestration tool. It does not execute deployments, run tests, or verify the evidence it receives. It is a decision-support layer that sits between your evidence collection systems and your deployment executor. Before wiring this into a production pipeline, you must define your gate policy in writing, test the prompt against historical deployment data to calibrate its decisions, and implement a human review step for any gate decision that is not a clear 'approved' or 'blocked'. The next section provides the copy-ready prompt template you can adapt to your specific release gates.

This prompt template is designed to be integrated into a CI/CD pipeline or a release management chatbot. It takes a structured deployment request and a set of organizational policies as input, then produces a deterministic gate decision. The prompt is engineered to require specific evidence for each gate, preventing the model from making assumptions about test results, change size, or on-call availability. Use this template as the core decision engine, but always wrap it in application-level validation to enforce the schema and handle edge cases.

textCopy
You are a strict production deployment gate evaluator. Your only job is to evaluate a deployment request against a set of predefined gates and output a structured decision. Do not approve a deployment if any gate condition is not met with explicit evidence. Do not infer or assume evidence that is not provided.

## GATES AND POLICIES
[GATE_DEFINITIONS]

## DEPLOYMENT REQUEST
[REQUEST_DETAILS]

## EVIDENCE PROVIDED
[EVIDENCE_PACKAGE]

## INSTRUCTIONS
1. For each gate defined in [GATE_DEFINITIONS], determine if the condition is met based *only* on the provided [EVIDENCE_PACKAGE].
2. If a gate requires evidence that is missing, mark it as FAILED with the reason "MISSING_EVIDENCE".
3. If the current time falls within a defined [BLACKOUT_WINDOW], mark the timing gate as FAILED.
4. If any gate is FAILED, the overall decision is "BLOCKED".
5. If all gates are PASSED, the overall decision is "APPROVED".
6. If the decision is "BLOCKED", generate a list of blocking conditions and the specific manual approvals required to override each one.

## OUTPUT FORMAT
You must output a single JSON object conforming to this exact schema. Do not include any other text.
{
  "decision": "APPROVED" | "BLOCKED",
  "gate_results": [
    {
      "gate_name": "string",
      "status": "PASSED" | "FAILED",
      "reason": "string",
      "required_evidence": "string",
      "provided_evidence": "string"
    }
  ],
  "blocking_conditions": [
    {
      "failed_gate": "string",
      "reason_blocked": "string",
      "manual_override_approvers": ["string"],
      "override_justification_required": true
    }
  ]
}

To adapt this template, replace the square-bracket placeholders with structured data from your deployment pipeline. [GATE_DEFINITIONS] should be a markdown list of your organization's gates, such as 'All critical tests must pass with a 100% pass rate' or 'Deployment must occur within the standard maintenance window of 02:00-04:00 UTC'. [REQUEST_DETAILS] should contain the service name, version, and requester. [EVIDENCE_PACKAGE] is the most critical input; it must be a structured dump of CI test reports, change logs, affected component lists, and the current on-call schedule. The output is a strict JSON object that your deployment tooling can parse to automatically allow or block the pipeline, or to open a ticket for the required manual approvers. In high-risk environments, always log the full prompt and response for auditability, and consider a human-in-the-loop review for any "BLOCKED" decision before it is surfaced to the requester.

The Production Deployment Gate Approval prompt is designed to sit at a critical decision point in your CI/CD pipeline, typically after all automated tests have run but before any infrastructure changes are applied. The prompt receives a structured deployment request containing test pass rates, change size metrics, affected components, timing windows, and on-call availability. It returns a gate decision—APPROVE, BLOCK, or MANUAL_REVIEW—along with blocking conditions and required manual approvals. This prompt is not a replacement for your CI/CD orchestrator; it is a policy evaluation step that encodes your deployment risk rules in natural language rather than hardcoded condition trees.

To wire this into an application, build a deployment gate service that constructs the prompt payload from your CI/CD context. The service should gather: test suite results (pass/fail counts, coverage deltas), change size (lines added/removed, files touched, services affected), deployment window (current time mapped against allowed windows), and on-call schedule (who is available, escalation path). Validation is critical before the model call—reject any deployment request missing required evidence fields. After receiving the model response, validate the output schema strictly: the decision field must be one of the three allowed values, blocking_conditions must be a non-empty array when BLOCK, and required_approvals must list specific role identifiers. If validation fails, retry once with the validation errors appended to the prompt as [PREVIOUS_ERRORS]. If the second attempt fails, default to MANUAL_REVIEW and log the failure for investigation.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities. For production deployment gates, prefer a model that supports constrained decoding or JSON mode to prevent format drift. Set temperature=0 to maximize determinism. Logging and audit are non-negotiable: capture the full prompt payload, the model response, the validation result, and the final gate decision in an immutable audit log. This log serves as your deployment decision record for incident reviews and compliance evidence. Human review integration should connect the MANUAL_REVIEW path to your incident management or chat platform (PagerDuty, Slack, ServiceNow) with a pre-formatted message containing the blocking conditions, affected components, and a direct link to approve or reject. Never allow the model to execute the deployment itself—the gate service should be the sole actor that triggers the deployment after receiving an APPROVE decision. Avoid wiring this prompt directly into a chatbot or conversational interface; it is a machine-to-machine prompt that should be called programmatically with structured inputs and outputs.