Rollback Plan Design Review Prompt

Use this prompt when an SRE, release manager, or platform engineer has drafted an automated rollback workflow and needs a structured design review before it is merged, approved, or tested in a staging environment. The prompt is designed to stress-test the plan against state reconciliation failures, data migration reversals, service dependency ordering mistakes, and idempotency gaps—the failure modes that turn a planned rollback into a prolonged outage. It is not a generic deployment safety checklist; it assumes the reader already has a concrete rollback design document, runbook, or workflow definition to evaluate.

The ideal input is a written rollback plan that includes the sequence of service reversals, data store rollback procedures, feature flag or configuration changes, and any manual approval gates. The prompt works best when the plan is detailed enough to reason about ordering and side effects. Do not use this prompt for high-level disaster recovery strategy documents, for reviewing individual database migration scripts in isolation, or for evaluating deployment strategies (canary, blue-green) that are not yet paired with a specific rollback procedure. The prompt requires architectural reasoning about distributed systems; it is not a substitute for actually running the rollback in a staging environment or for load-testing the rollback path.

After running the prompt, expect a structured analysis that identifies specific failure modes, ranks them by severity, and proposes concrete mitigations. The output should feed directly into a design review meeting or an architecture decision record. If the rollback plan involves regulated data, financial transactions, or safety-critical systems, always pair the prompt's output with a manual review by a senior engineer who owns the affected services. The prompt can find gaps, but it cannot verify that the plan matches the actual production topology.

This prompt template provides a structured framework for analyzing rollback plan designs. It is built for SREs, release managers, and platform engineers who need to evaluate whether an automated rollback workflow will actually work under production failure conditions. The template uses square-bracket placeholders that you replace with your specific deployment context, service architecture, rollback mechanism details, and evaluation constraints before sending to the model.

codeCopy
You are a senior site reliability engineer reviewing an automated rollback plan design. Your task is to produce a structured analysis that identifies failure modes, validates safety guarantees, and recommends improvements before this plan is approved for production use.

## DEPLOYMENT CONTEXT
[SYSTEM_ARCHITECTURE_DESCRIPTION]

## ROLLBACK PLAN DETAILS
[ROLLBACK_PLAN_DOCUMENTATION]

## CONSTRAINTS
- Recovery Time Objective (RTO): [RTO_IN_SECONDS]
- Recovery Point Objective (RPO): [RPO_IN_SECONDS]
- Maximum acceptable error rate during rollback: [MAX_ERROR_RATE]
- Regulatory or compliance requirements: [COMPLIANCE_REQUIREMENTS]

## OUTPUT SCHEMA
Produce a JSON object with the following structure:
{
  "summary": "One-paragraph assessment of overall rollback readiness",
  "state_reconciliation": {
    "database_rollback_strategy": "Description and assessment of database state reversal approach",
    "risks": ["List of data consistency risks during rollback"],
    "missing_safeguards": ["Gaps in data integrity protection"]
  },
  "service_dependency_ordering": {
    "rollback_sequence": ["Ordered list of service rollback steps"],
    "dependency_conflicts": ["Services that cannot rollback independently"],
    "circular_dependency_risks": ["Circular dependencies that complicate rollback"]
  },
  "idempotency_analysis": {
    "idempotent_operations": ["Operations safe to retry"],
    "non_idempotent_operations": ["Operations that cause double-execution problems"],
    "recommended_safeguards": ["Idempotency keys, deduplication, or state checks needed"]
  },
  "failure_modes": [
    {
      "failure_scenario": "Description of what could go wrong",
      "likelihood": "low|medium|high",
      "impact": "low|medium|high|critical",
      "detection_mechanism": "How this failure would be detected",
      "mitigation": "Recommended mitigation or existing safeguard"
    }
  ],
  "distributed_lock_analysis": {
    "lock_mechanisms": ["Locks used during rollback"],
    "contention_risks": ["Scenarios where lock contention could block rollback"],
    "deadlock_potential": "Assessment of deadlock risk",
    "timeout_configuration": "Review of lock timeout settings"
  },
  "partial_rollback_risks": {
    "scenarios": ["Situations where rollback could partially complete"],
    "detection_gaps": ["Missing checks for partial completion"],
    "recovery_procedures": ["How to recover from partial rollback state"]
  },
  "cache_invalidation": {
    "cache_layers_affected": ["Caches that need invalidation during rollback"],
    "staleness_risks": ["Scenarios where stale cached data causes incorrect behavior"],
    "invalidation_strategy_assessment": "Review of cache invalidation approach"
  },
  "message_queue_considerations": {
    "queue_replay_risks": ["Risks of replaying or dropping messages during rollback"],
    "ordering_guarantees": "Assessment of message ordering during rollback",
    "dead_letter_handling": "How failed messages are handled during rollback"
  },
  "overall_risk_score": "low|medium|high|critical",
  "recommendations": [
    {
      "priority": "critical|high|medium|low",
      "finding": "Specific issue identified",
      "recommendation": "Concrete action to address the issue",
      "rationale": "Why this matters for production safety"
    }
  ],
  "approval_readiness": "ready|conditional|not_ready",
  "conditions_for_approval": ["Specific changes required before this plan can be approved"]
}

## EVALUATION CRITERIA
- Every failure mode must include a detection mechanism and mitigation
- State reconciliation risks must cover both forward and reverse data migrations
- Service dependency ordering must account for API version compatibility during rollback
- Idempotency analysis must distinguish between safe retries and double-execution hazards
- Partial rollback scenarios must include recovery procedures, not just identification
- Recommendations must be actionable with clear rationale
- If the plan is scored critical risk or not_ready, conditions_for_approval must be non-empty

## INSTRUCTIONS
1. Analyze the rollback plan against the constraints and output schema
2. Identify gaps between the documented plan and production safety requirements
3. Flag any assumptions the plan makes that may not hold during an actual incident
4. Prioritize findings by production impact, not theoretical completeness
5. If the plan documentation is insufficient to assess a category, note what information is missing rather than guessing

To adapt this template, replace each square-bracket placeholder with your actual deployment details. The [SYSTEM_ARCHITECTURE_DESCRIPTION] should include service topology, data stores, message queues, and cache layers. The [ROLLBACK_PLAN_DOCUMENTATION] should contain the full rollback runbook, automation scripts, or design document being reviewed. Set [RTO_IN_SECONDS] and [RPO_IN_SECONDS] to your actual SLO targets, and [MAX_ERROR_RATE] to the acceptable error budget consumption during rollback. If no compliance requirements apply, set [COMPLIANCE_REQUIREMENTS] to "none" rather than leaving it empty.

Before using this prompt in production, validate that the output JSON matches the schema exactly. Common failure modes include the model omitting the detection_mechanism field in failure modes, producing recommendations without the required rationale field, or generating conditions_for_approval as a string instead of an array. Implement a JSON schema validator in your application layer that rejects malformed outputs and triggers a retry with the validation errors included in the next request. For high-risk deployments, route outputs scored critical or not_ready to a human reviewer before the analysis reaches the approval workflow. Log every review result with the rollback plan version, model version, and reviewer identity for audit trail purposes.

This prompt is designed to be called programmatically as part of a change management or deployment pipeline, not as a one-off chat interaction. The typical integration point is a pre-release gate where a rollback plan document (markdown, JSON, or a structured runbook) is submitted for automated review before a deployment can proceed. The application should fetch the rollback plan from a source of truth (e.g., a Git repository, an internal wiki, or a deployment tool's plan artifact), inject it into the [ROLLBACK_PLAN] placeholder, and call the model. The output is a structured analysis that downstream systems can parse to decide whether to block the release, flag it for manual review, or allow it to proceed with warnings.

Validation and Output Contract: The prompt instructs the model to return a JSON object with specific fields (overall_risk_score, critical_gaps, recommendations, requires_human_review). Your application must validate this JSON against a strict schema immediately after receiving the model response. If parsing fails, retry once with a repair prompt that includes the raw output and the schema. If the second attempt fails, escalate to a human reviewer and log the failure. The overall_risk_score field should be a float between 0.0 and 1.0; validate this range and reject values outside it. The requires_human_review boolean is the primary gating signal—if true, the deployment pipeline should halt and create a ticket in the on-call queue with the full analysis attached. Model Choice and Latency: Use a model with strong reasoning capabilities (e.g., Claude 3.5 Sonnet, GPT-4o) because the task requires multi-step analysis of state reconciliation, dependency ordering, and idempotency. This is not a low-latency, high-throughput classification task; it runs once per deployment, so a 10-30 second response time is acceptable. Set a timeout of 60 seconds and handle timeout errors as a requires_human_review escalation.

Retries, Logging, and Audit Trail: Implement exactly one retry on model invocation failure (network error, timeout, 5xx). Do not retry on validation failures without a repair prompt. Log every invocation with: the prompt version hash, the model ID, the input plan's content hash, the raw output, the parsed output, the validation result, and the final gating decision. This log becomes your audit trail for compliance and post-incident review. Store it in an append-only system (e.g., a dedicated S3 bucket or an audit database table) and never delete or mutate these records. Human Review Integration: When requires_human_review is true or when the system cannot produce a valid output after retries, create a structured ticket that includes the original rollback plan, the model's partial analysis (if any), and a clear prompt for the human reviewer: "Review the rollback plan for state reconciliation gaps, data migration reversal safety, and service dependency ordering. The automated review flagged the following critical gaps: [list]." Do not allow the deployment to proceed until a human explicitly approves the ticket. What to Avoid: Do not use this prompt as a real-time decision-maker during an active incident. It is a pre-release design review tool, not an incident response tool. Do not skip the JSON schema validation step—unstructured model output will break downstream automation. Do not treat a low overall_risk_score as a guarantee of safety; the score is a signal for prioritization, not a replacement for engineering judgment.