Release Readiness Review Prompt Template

This prompt is for release managers and platform engineering leads who need to consolidate the outputs of multiple automated and manual release gates into a single, stakeholder-ready readiness report. The job-to-be-done is not to run the individual tests—it is to ingest a structured set of per-gate results, apply a consistent risk-scoring methodology, and produce a final recommendation with unresolved risks, required approvals, and clear next actions. Use this when you have already executed your quantitative threshold evaluations, qualitative rubrics, canary analyses, and security scans, and you now need a human-readable summary that can be reviewed by a change advisory board or product leadership before promotion.

The ideal user is someone who owns the release decision but does not have time to manually cross-reference a dozen gate reports. They bring a JSON payload of gate results—each with a status, a risk score, and a list of unresolved findings—and expect a structured readiness report in return. The prompt requires a well-defined [GATE_RESULTS] input schema, a [RISK_MATRIX] that defines how individual gate severities roll up into an overall risk level, and an [APPROVAL_POLICY] that specifies which roles must sign off based on the aggregated risk. Do not use this prompt for single-gate decisions, for real-time production monitoring, or for triggering automated rollbacks; those workflows need their own specialized prompts with tighter latency and decision boundaries.

This prompt is a decision-support tool, not an automated release authority. The output should always be treated as a recommendation that requires human review, especially when unresolved risks or policy exceptions are present. Before wiring this into a CI/CD pipeline, ensure that the upstream gate results are trustworthy and that the risk matrix has been calibrated against your organization's actual incident history. A common failure mode is feeding the prompt incomplete or stale gate data, which produces a confident but incorrect readiness report. Always validate the [GATE_RESULTS] payload for completeness and recency before invoking this prompt, and log every generated report as an audit artifact for post-release review.

This template is designed to be the final aggregation step in a prompt release pipeline. It consumes structured results from multiple upstream gates—quantitative thresholds, qualitative rubrics, semantic drift checks, and operational health metrics—and synthesizes them into a single, stakeholder-ready report. The output is not just a pass/fail signal; it is a decision-support artifact that surfaces unresolved risks, required approvals, and recommended actions. Use this when you have already run individual gate evaluations and need a formal, auditable summary before promoting a prompt version from staging to production.

codeCopy
You are a release readiness reviewer for AI prompt deployments. Your task is to aggregate the results of multiple pre-release gate evaluations into a final go/no-go summary with stakeholder context.

## Inputs
- [GATE_RESULTS]: A structured list of individual gate evaluation reports. Each report must include the gate name, pass/fail status, severity (BLOCKING | WARNING | INFO), metric values, and any human review notes.
- [RELEASE_CONTEXT]: Metadata about the release, including the prompt version identifier, target environment, deployment window, and rollback plan reference.
- [PRIOR_RELEASE_BASELINE]: Optional. Summary metrics from the previous successful release for trend comparison.
- [APPROVAL_MATRIX]: A list of required approvers and their current approval status (APPROVED | PENDING | REJECTED).
- [RISK_THRESHOLDS]: Organization-specific definitions for acceptable risk levels, including maximum allowed BLOCKING failures and WARNING tolerances.

## Output Schema
Return a single JSON object with the following structure:
{
  "release_id": "string",
  "overall_decision": "GO" | "NO_GO" | "CONDITIONAL_GO",
  "decision_confidence": 0.0-1.0,
  "gate_summary": {
    "total_gates": integer,
    "passed": integer,
    "failed_blocking": integer,
    "failed_warning": integer,
    "not_applicable": integer
  },
  "blocking_failures": [
    {
      "gate_name": "string",
      "failure_reason": "string",
      "recommended_resolution": "string"
    }
  ],
  "unresolved_risks": [
    {
      "risk_description": "string",
      "severity": "HIGH" | "MEDIUM" | "LOW",
      "affected_gate": "string"
    }
  ],
  "approval_status": {
    "required_approvers": integer,
    "approved": integer,
    "pending": integer,
    "rejected": integer,
    "missing_approvals": ["string"]
  },
  "trend_analysis": {
    "compared_to_baseline": "BETTER" | "SAME" | "WORSE" | "NO_BASELINE",
    "key_changes": ["string"]
  },
  "recommended_actions": ["string"],
  "executive_summary": "string"
}

## Constraints
1. If any gate has a BLOCKING failure, overall_decision must be NO_GO unless a documented exception exists in [RISK_THRESHOLDS].
2. If all BLOCKING gates pass but WARNING gates remain unresolved, overall_decision must be CONDITIONAL_GO with explicit conditions listed in recommended_actions.
3. If any required approver has REJECTED status, overall_decision must be NO_GO regardless of gate results.
4. The executive_summary must be no more than 4 sentences and must state the decision, the primary risk, and the next step.
5. Never fabricate gate results. If [GATE_RESULTS] is incomplete, mark the release as NO_GO and list missing gates as unresolved risks.
6. All recommended_actions must be specific and assignable to a team or role.

## Instructions
1. Parse [GATE_RESULTS] and categorize each gate by severity and status.
2. Cross-reference failures against [RISK_THRESHOLDS] to determine if any BLOCKING failures are waiverable.
3. Check [APPROVAL_MATRIX] for missing or rejected approvals.
4. If [PRIOR_RELEASE_BASELINE] is provided, compare key metrics and note significant regressions or improvements.
5. Synthesize findings into the output schema. Prioritize clarity and actionability over exhaustive detail.
6. If the decision is NO_GO, the recommended_actions must include the specific gates that must be re-evaluated and the conditions for re-submission.

To adapt this template, start by ensuring your upstream gate evaluations produce structured outputs that map to the [GATE_RESULTS] input. Each gate report should include at minimum a gate_name, status, and severity field. If your existing gates output unstructured text, insert a normalization step before this prompt that extracts those fields into a consistent schema. The [RISK_THRESHOLDS] input is critical for avoiding false NO_GO decisions—define these thresholds in your application configuration, not in the prompt text, so they can be updated without changing the prompt version. For high-stakes deployments, route the final overall_decision and executive_summary to a human approval queue before automated promotion. The output JSON should be validated against the schema before any downstream system acts on it; a malformed response should trigger a retry or escalation, not a silent default to GO.

The Release Readiness Review prompt is designed to be the final aggregation layer in a multi-gate release pipeline. It consumes structured results from upstream evaluation prompts—such as the Golden Dataset Pass Rate Gate, Hallucination Rate Gate, and Schema Adherence Gate—and produces a unified go/no-go recommendation. The harness must enforce that all required gate results are present before the prompt executes, preventing incomplete reviews from generating a false sense of confidence. This prompt is not a replacement for individual gate evaluations; it is a synthesis layer that applies organizational risk tolerance and stakeholder context to the aggregated data.

To wire this into an application, build a gate result aggregator that collects outputs from each upstream evaluation step into a structured JSON payload matching the [GATE_RESULTS] placeholder. Each gate entry must include: gate_name, status (pass, fail, warning, not_executed), score (numeric where applicable), threshold, evidence_summary, and blocking (boolean). The harness should validate this payload before calling the LLM—rejecting missing required gates, malformed statuses, or conflicting evidence. After the LLM returns the readiness report, run a structural validator that checks for required sections (per-gate status, unresolved risks, required approvals, recommended action) and a risk score range check to ensure the output falls within expected bounds. If validation fails, retry once with the validation errors injected into [CONSTRAINTS]; if it fails again, escalate to a human release manager.

For production deployment, integrate this prompt into your CI/CD pipeline as a manual approval gate with automated evidence collection. The harness should log every execution—including the full input payload, model response, validation results, and final decision—to an audit trail for governance review. Use a deterministic model (such as gpt-4o or claude-3-5-sonnet with temperature set to 0) to maximize consistency across runs. If your organization requires multi-stakeholder sign-off, extend the harness to route the generated readiness report to a review queue (e.g., Jira, ServiceNow, or a custom approval dashboard) where designated approvers can confirm or override the recommendation. Never allow automated promotion to production based solely on this prompt's output without human confirmation when [RISK_LEVEL] is set to high or when any blocking gate has failed. The harness should enforce this policy in code, not rely on the prompt to remember it.