Staged Release Readiness Assessment Prompt

This prompt is designed for AI product leads and release managers who need a structured, evidence-based assessment of whether an AI system is ready to advance to the next deployment stage. Use it before a stage-gate review meeting to produce a readiness report that covers performance against defined gates, residual risks, rollback preparedness, and any outstanding concerns that should block promotion. The prompt forces the model to act as a skeptical reviewer, not a cheerleader, and to flag missing evidence rather than assume readiness.

The ideal user has already defined concrete stage-gate criteria, collected performance metrics from the current deployment phase, and gathered evidence such as eval results, incident reports, and human review statistics. The prompt requires these inputs to be assembled into a structured context block. Without this evidence, the model will correctly flag the assessment as incomplete. The output is a human-readable report intended to inform a deliberate approval decision in a review meeting, not to automate the gating decision itself.

Do not use this prompt for real-time gating decisions in production code paths. It is not designed for programmatic consumption or low-latency decision-making. For automated gating, implement a deterministic rules engine that checks metric thresholds directly. This prompt is exclusively for human-in-the-loop review workflows where the output informs a deliberate approval decision. Avoid using it when the stage-gate criteria are undefined or when the evidence package is too sparse to support a meaningful assessment.

This prompt template is designed to be the core instruction set for a Staged Release Readiness Assessment. It forces the model to act as a structured auditor, not a cheerleader. The template requires concrete evidence for every claim, explicitly asks for outstanding concerns, and mandates a rollback readiness check—three areas commonly skipped in informal readiness reviews. Use this as the foundation for an automated gate check in your CI/CD or governance pipeline.

textCopy
You are an AI release auditor evaluating whether [SYSTEM_NAME] is ready to advance from deployment stage [CURRENT_STAGE] to [TARGET_STAGE].

Your assessment must be based strictly on the provided evidence. Do not infer readiness from incomplete data. If evidence is missing for a criterion, mark it as UNKNOWN and flag it as a blocking concern.

## INPUT

**System Profile:**
[SYSTEM_PROFILE]

**Performance Gate Criteria:**
[PERFORMANCE_GATES]

**Evidence Package:**
[EVIDENCE]

**Previous Stage Assessment:**
[PREVIOUS_ASSESSMENT]

## ASSESSMENT INSTRUCTIONS

For each performance gate in [PERFORMANCE_GATES], produce a finding with:
- **Status:** MET | NOT_MET | UNKNOWN
- **Evidence Reference:** Direct quote or pointer to the specific evidence used.
- **Confidence:** HIGH | MEDIUM | LOW
- **Rationale:** One-sentence explanation of the determination.

After evaluating all gates, produce a **Readiness Summary** with:
- **Overall Readiness:** READY | NOT_READY | CONDITIONAL
- **Blocking Concerns:** List of gates with NOT_MET or UNKNOWN status.
- **Risk Assessment:** Top 3 risks if promoted to [TARGET_STAGE], with severity (HIGH/MEDIUM/LOW).
- **Rollback Preparedness:** Assessment of whether the system can safely revert to [CURRENT_STAGE] if the promotion fails. Include detection time, rollback procedure, and data integrity checks.
- **Outstanding Items:** Any open questions, missing evidence, or follow-up actions required before the next assessment.

## CONSTRAINTS

- Do not assume missing evidence indicates success.
- If [RISK_LEVEL] is HIGH, require explicit human approval before returning a READY status.
- Flag any gate that relies on stale evidence (older than [EVIDENCE_FRESHNESS_WINDOW]).
- If the system has been demoted from [TARGET_STAGE] previously, require evidence that the original demotion trigger has been resolved.

## OUTPUT_SCHEMA

Return a valid JSON object matching this structure:
{
  "assessment_id": "string",
  "system_name": "string",
  "current_stage": "string",
  "target_stage": "string",
  "assessment_timestamp": "ISO8601",
  "gate_findings": [
    {
      "gate_name": "string",
      "status": "MET | NOT_MET | UNKNOWN",
      "evidence_reference": "string",
      "confidence": "HIGH | MEDIUM | LOW",
      "rationale": "string"
    }
  ],
  "readiness_summary": {
    "overall_readiness": "READY | NOT_READY | CONDITIONAL",
    "blocking_concerns": ["string"],
    "top_risks": [
      {
        "risk_description": "string",
        "severity": "HIGH | MEDIUM | LOW"
      }
    ],
    "rollback_preparedness": {
      "detection_time_seconds": number,
      "rollback_procedure_validated": boolean,
      "data_integrity_checks": ["string"],
      "assessment": "string"
    },
    "outstanding_items": ["string"]
  },
  "human_approval_required": boolean
}

To adapt this template, replace the square-bracket placeholders with data from your release management system. [SYSTEM_PROFILE] should include the system's purpose, criticality, and current autonomy level. [PERFORMANCE_GATES] is the formal criteria specification—ideally generated from a companion Performance Gate Criteria Definition Prompt. [EVIDENCE] must be a structured dump of monitoring data, test results, and human review statistics. If your evidence is large, pre-process it into summaries keyed to each gate before passing it into this prompt. The [RISK_LEVEL] placeholder should be set to HIGH for any system that touches PII, financial data, or irreversible actions, which will force the human approval flag. After the model returns the JSON, validate it against the OUTPUT_SCHEMA before surfacing the readiness decision in your dashboard. If the model returns CONDITIONAL or NOT_READY, route the blocking concerns and outstanding items to the engineering lead and block the stage promotion in your deployment pipeline.

This prompt is designed to be the final gate in a deployment pipeline, not a one-off query. The implementation harness should treat the prompt's output as a structured decision artifact that blocks or unblocks a stage promotion. The primary integration point is a release management or CI/CD system (e.g., GitHub Actions, GitLab CI, Jenkins) that invokes the LLM with a pre-assembled context payload. The harness must enforce a strict contract: if the model's output does not meet the required schema or if the readiness verdict is not PROMOTE, the pipeline must halt and route the report to a human release manager via a notification channel like Slack, PagerDuty, or a review queue.

To wire this in, build a pre-processing step that gathers the required inputs: the current stage definition, target stage definition, performance gate results (error rates, latency p95, evaluation scores), a summary of open incidents, and the rollback plan. Assemble these into the [STAGE_EVIDENCE] placeholder as a structured JSON block. The model call should be configured with temperature=0.0 and a strict JSON mode or function-calling API to enforce the output schema. Implement a retry loop (max 3 attempts) that re-prompts with the previous malformed output and a specific error message if schema validation fails. After a successful parse, the harness must check the top-level verdict field. If verdict is BLOCK, HOLD, or REQUEST_CLARIFICATION, the pipeline must fail the stage promotion job and post the full readiness_report to the designated review channel.

Logging is critical for auditability. The harness must write an immutable log entry containing the full prompt payload, the raw model response, the parsed verdict, the timestamp, the target stage, and the pipeline run ID. This log serves as the audit trail for governance reviews. For high-risk systems, introduce a mandatory human approval step even on PROMOTE verdicts for the first few runs to calibrate trust in the assessment. Avoid the temptation to auto-promote without this calibration period. The most common production failure mode is a missing or stale evidence payload, which causes the model to hallucinate a readiness assessment. Always validate that the evidence payload contains recent data (e.g., timestamps within the last 24 hours) before sending the prompt.