Phased Rollout Risk Segmentation Prompt

This prompt is for release coordinators, SREs, and engineering leads who need to move beyond a binary go/no-go decision and design an incremental, risk-segmented rollout. Use it when you have a release candidate that has passed baseline quality gates but carries residual risk from specific features, infrastructure changes, or external dependencies. The prompt ingests your release context, risk register, and observability signals to produce a phased plan: starting with low-risk internal cohorts, expanding through progressively riskier segments, and defining explicit progression gates, monitoring windows, and abort thresholds at each phase.

The ideal user brings structured inputs: a list of features or changes in the release, a risk register with severity and likelihood per item, known cohort definitions (internal teams, beta users, geographic regions, or traffic percentages), and the observability signals available at each phase (error rates, latency p95, business metrics, customer feedback channels). The prompt works best when you can define what 'good' looks like for each signal and what deviation triggers a halt. It is not a replacement for your deployment pipeline or feature flag system; it is the planning layer that tells those systems what sequence to follow and what signals to watch.

Do not use this prompt when the release has no residual risk worth segmenting—if all gates are green and confidence is high, a standard rollout suffices. Do not use it when you lack the observability infrastructure to actually monitor the gates it defines; a plan without measurable progression criteria is theater. Do not use it when the release contains changes that cannot be incrementally exposed (e.g., irreversible schema migrations without feature flags). In those cases, invest in the missing infrastructure or accept the binary risk profile before attempting phased planning. The output is a plan document, not an execution engine—you must wire it into your actual deployment tooling, monitoring dashboards, and incident response workflows.

After generating the plan, validate it against reality: can you actually target the defined cohorts with your feature flag or deployment system? Are the monitoring windows long enough to catch the failure modes you care about? Are the abort thresholds tight enough to prevent customer impact but loose enough to avoid noise-triggered rollbacks? Walk the plan with the on-call team and the release manager before committing it to execution. The prompt produces a starting point; your operational judgment makes it safe.

This prompt template is designed to be copied directly into your AI orchestration layer or evaluation harness. It instructs the model to act as a release coordinator and produce a phased rollout plan segmented by risk. The output is a structured JSON object that can be parsed by deployment automation, monitoring dashboards, or approval workflows. Every decision the model makes—cohort assignment, progression criteria, abort thresholds—must be derived from the release data you provide in the placeholders.

textCopy
SYSTEM:
You are a release coordinator planning a phased rollout for a software release. Your goal is to minimize blast radius while gathering sufficient signal to validate release health. You must produce a risk-segmented rollout plan based on the provided release data.

INPUT DATA:
- Release Version: [RELEASE_VERSION]
- Change Summary: [CHANGE_SUMMARY]
- Affected Components: [AFFECTED_COMPONENTS]
- Known Risks: [KNOWN_RISKS]
- Test Results Summary: [TEST_RESULTS_SUMMARY]
- Open Defects: [OPEN_DEFECTS]
- Historical Rollout Data: [HISTORICAL_ROLLOUT_DATA]
- Available Cohorts: [AVAILABLE_COHORTS]
- Monitoring Capabilities: [MONITORING_CAPABILITIES]
- Organizational Risk Tolerance: [RISK_TOLERANCE]

OUTPUT_SCHEMA:
{
  "plan_name": "string",
  "release_version": "string",
  "overall_risk_assessment": "string",
  "phases": [
    {
      "phase_number": "integer",
      "phase_name": "string",
      "cohort_definition": "string",
      "cohort_size_percentage": "number",
      "duration_hours": "number",
      "progression_criteria": [
        {
          "metric": "string",
          "threshold": "string",
          "evaluation_method": "string"
        }
      ],
      "monitoring_gates": [
        {
          "signal": "string",
          "expected_behavior": "string",
          "alert_threshold": "string"
        }
      ],
      "abort_conditions": [
        {
          "condition": "string",
          "severity": "critical|high",
          "automatic_rollback": "boolean"
        }
      ],
      "rollback_procedure": "string"
    }
  ],
  "global_abort_thresholds": [
    {
      "condition": "string",
      "applies_to_phase": "integer | all"
    }
  ],
  "communication_plan": {
    "stakeholders": ["string"],
    "update_cadence": "string",
    "escalation_path": "string"
  },
  "assumptions": ["string"],
  "residual_risks": ["string"]
}

CONSTRAINTS:
- Phase 1 must target the lowest-risk cohort with the smallest feasible percentage.
- Each subsequent phase must increase cohort size and risk exposure incrementally.
- Progression criteria must be measurable and tied to specific monitoring signals.
- Abort conditions must include both automated triggers and human-judgment gates.
- If historical rollout data shows a pattern of regressions in a specific component, increase the duration of phases that touch that component.
- If monitoring capabilities are insufficient to evaluate a progression criterion, flag it as an assumption and recommend instrumentation before rollout.
- Do not invent metrics, thresholds, or cohorts not present in the input data.

Adapting the template: Replace every square-bracket placeholder with concrete data from your release management system. The [AVAILABLE_COHORTS] field should describe real deployment segments you can target—such as internal employees, canary regions, beta customers, or percentage-based traffic splits. The [MONITORING_CAPABILITIES] field must be honest about what you can actually observe; if you lack real-user monitoring for a critical signal, the model will flag it as an assumption rather than silently producing an unverifiable plan. For high-risk releases, run the output through a human review step before feeding phase definitions into your deployment pipeline. The JSON schema is designed to be machine-readable, so you can parse it directly in CI/CD systems, feature flag configurations, or incident management tools.

What to do next: After generating the plan, validate that every progression criterion maps to a real metric you can query during the rollout. If the model proposes a threshold you cannot measure, either instrument the missing signal or replace the criterion with an observable proxy. Run the plan past your SRE team to confirm that abort conditions align with your actual rollback capabilities—a plan that assumes instant rollback when your system requires a 20-minute database restore is a plan that will fail in production. Store the generated plan alongside your release record for post-rollout review and auditability.

This prompt is designed to sit between your release readiness assessment and your actual deployment orchestration. It should be invoked after you have a go/no-go recommendation but before you begin rolling out to production. The prompt consumes structured quality signals—test pass rates, defect severity distributions, coverage gaps, and environment stability data—and produces a phased rollout plan with explicit cohort definitions, progression gates, and abort thresholds. The output is not a deployment script; it is a risk-segmented strategy document that a release coordinator reviews, adjusts, and then feeds into a feature flag system, canary deployment tool, or staged rollout pipeline.

To integrate this into an application, build a harness that first validates all required inputs are present and non-empty before calling the model. Required fields include: a release identifier, a list of known risks with severity and likelihood scores, a set of target cohorts with user counts and risk tolerance labels, and the current quality gate results. If any required field is missing, the harness should refuse to call the model and return a structured error indicating which input is absent. After the model responds, validate the output against a schema that requires at least one cohort definition, progression criteria per phase, and explicit abort thresholds. If validation fails, retry once with the validation errors appended to the prompt as [CONSTRAINTS] feedback. If the retry also fails, escalate to a human release coordinator with the partial output and validation failure details logged.

For model choice, use a model with strong reasoning and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or equivalent. Set temperature to 0.2 or lower to reduce variance in risk thresholds. Log every invocation with the full prompt, response, validation result, and any human overrides. Store the final approved plan as an auditable artifact linked to the release record. Do not automate the execution of the plan directly from model output; always require a human to review and approve the cohort sequence, progression criteria, and abort thresholds before any deployment action begins. The most common production failure mode is the model proposing overly aggressive progression criteria that ignore real-world observation lag—your harness should flag any plan where the observation window between phases is less than a configurable minimum duration.