Pipeline Rollback Decision Prompt with Error Context

This prompt is designed for a data platform lead or SRE who must decide whether to roll back a recent pipeline deployment after encountering errors in production. The job-to-be-done is not just to get a 'yes' or 'no' on rollback, but to receive a structured, evidence-backed recommendation that weighs the deployment diff, error rate, data freshness impact, and the downstream dependency graph. The ideal user is someone with the authority to approve a rollback but who needs a rigorous, consistent analysis to make that call under pressure, especially when the blast radius spans multiple data products.

To use this prompt effectively, you must provide concrete, machine-readable context. This includes the deployment diff (what changed), the current error rate and error samples, a quantified impact on data freshness (e.g., SLA violation in minutes), and a list of downstream dependencies with their criticality. The prompt is not a substitute for a real-time monitoring dashboard; it is a reasoning tool that synthesizes that data into a decision memo. It requires a human-in-the-loop for final approval, as the model's recommendation is advisory, not executable.

Do not use this prompt for minor, non-blocking errors or for pipelines without a clear rollback mechanism. It is also unsuitable when the error context is purely speculative or when the deployment diff is unavailable. The prompt's value collapses if you feed it vague descriptions like 'the pipeline is broken.' If the error is a known, transient infrastructure issue (e.g., a network blip) with a standard retry policy, use a simpler retry prompt instead. This playbook is for the high-stakes moment when you are weighing the known cost of a rollback against the uncertain cost of letting errors propagate.

This prompt template is designed to be copied directly into your AI harness. It takes structured inputs about a failed pipeline deployment and produces a rollback recommendation with a confidence score, a step-by-step rollback plan, and a safety check. The template uses square-bracket placeholders for all dynamic inputs, making it easy to wire into a data platform's CI/CD or runbook automation system. Before using this prompt, ensure you have collected the deployment diff, current error rate, data freshness impact, and the downstream dependency graph. The prompt is designed for a decision-support workflow, not autonomous execution; the output must be reviewed by a human before any rollback is initiated.

textCopy
You are a data platform reliability engineer evaluating a pipeline deployment failure. Your task is to produce a structured rollback recommendation based on the provided error context, deployment diff, and downstream impact analysis.

## INPUTS

### DEPLOYMENT DIFF
[DEPLOYMENT_DIFF]

### ERROR CONTEXT
- Error Rate: [ERROR_RATE]
- Error Sample (last 5 errors): [ERROR_SAMPLE]
- Failure Duration: [FAILURE_DURATION]

### DATA FRESHNESS IMPACT
- Affected Datasets: [AFFECTED_DATASETS]
- Max Data Delay: [MAX_DATA_DELAY]
- SLA Breach Risk: [SLA_BREACH_RISK]

### DOWNSTREAM DEPENDENCY GRAPH
[DOWNSTREAM_DEPENDENCY_GRAPH]

### DEPLOYMENT METADATA
- Pipeline Name: [PIPELINE_NAME]
- Deployment Version: [DEPLOYMENT_VERSION]
- Previous Stable Version: [PREVIOUS_STABLE_VERSION]
- Deployment Timestamp: [DEPLOYMENT_TIMESTAMP]

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
You must respond with a single JSON object conforming to this schema:
{
  "recommendation": "rollback" | "hold_and_investigate" | "forward_fix" | "insufficient_data",
  "confidence_score": 0.0-1.0,
  "rationale": "string explaining the primary factors driving the recommendation",
  "rollback_plan": {
    "steps": ["ordered list of rollback actions"],
    "estimated_rollback_duration_minutes": number,
    "rollback_risk_level": "low" | "medium" | "high",
    "rollback_safety_check": {
      "data_loss_risk": "none" | "minimal" | "moderate" | "severe",
      "downstream_breaking_changes": ["list of downstream systems that may break"],
      "requires_data_backfill": boolean,
      "backfill_instructions": "string or null"
    }
  },
  "alternative_actions": ["list of alternative actions if rollback is not recommended"],
  "escalation_required": boolean,
  "escalation_reason": "string or null"
}

## RISK LEVEL
[RISK_LEVEL]

## INSTRUCTIONS
1. Compare the deployment diff against the error sample to determine if the errors are causally linked to the deployment change.
2. Assess the downstream dependency graph to identify which systems are affected and the blast radius of continued failure.
3. Evaluate data freshness impact against any SLAs defined in the constraints.
4. If the error rate exceeds the threshold defined in constraints and the deployment diff shows a likely cause, recommend rollback.
5. If the error cause is unclear or the error rate is below threshold, recommend hold_and_investigate.
6. If a forward fix is possible and less disruptive than rollback, recommend forward_fix with specific fix steps.
7. If insufficient data exists to make a recommendation, recommend insufficient_data and set escalation_required to true.
8. Always include a rollback safety check, even if rollback is not the primary recommendation.
9. Do not fabricate error causes. If the link between the deployment diff and errors is uncertain, state that explicitly in the rationale.
10. If RISK_LEVEL is "high", set confidence_score no higher than 0.7 unless the evidence is overwhelming.

To adapt this template, replace each square-bracket placeholder with data from your pipeline observability stack. The [DEPLOYMENT_DIFF] should include the full diff of configuration, SQL, or code changes between the current and previous deployment. The [DOWNSTREAM_DEPENDENCY_GRAPH] should be a structured representation of which datasets, models, or dashboards depend on the affected pipeline outputs. The [CONSTRAINTS] placeholder should include your organization's specific thresholds for error rate tolerance, maximum acceptable data delay, and any regulatory or SLA requirements. The [RISK_LEVEL] should be set based on the pipeline's criticality: use "high" for pipelines feeding financial reporting, clinical data, or customer-facing systems; "medium" for internal analytics pipelines; "low" for experimental or non-critical pipelines. After receiving the model's output, always validate the JSON structure against the schema before presenting the recommendation to the on-call engineer. The rollback plan steps should be reviewed for feasibility against your actual deployment tooling before execution.

This prompt is designed to sit at the decision gate of a CI/CD or data pipeline deployment workflow. After a deployment is attempted and errors are detected—whether from data validation checks, schema mismatches, or task failures—the harness collects the deployment diff, error rate, data freshness impact, and downstream dependency graph, then calls the model. The model's output is not executed directly. Instead, the harness parses the structured recommendation, validates the confidence score and rollback-safety check, and routes the decision to a human approval queue if the recommendation is to roll back or if the confidence score falls below a configurable threshold (e.g., 0.85).

To wire this into an application, build a pre-call context assembler that gathers: (1) the deployment diff from your version control or CI system, (2) the error rate and error samples from your monitoring or pipeline logs, (3) the data freshness impact expressed as the time delta since the last successful ingestion for each affected dataset, and (4) the downstream dependency graph as a structured list of consumers (dashboards, ML models, other pipelines) with their SLA tiers. The harness should enforce a retry budget—if the model returns an unparseable output or a confidence score below the minimum threshold, retry up to 2 times with the same context before escalating to the on-call engineer. Log every model call, including the raw prompt, the raw response, the parsed recommendation, and the final human decision, to an audit trail for post-incident review.

For model choice, use a model with strong structured-output and reasoning capabilities. If your platform supports structured output modes (e.g., JSON mode with a schema), supply the output schema directly rather than relying on the prompt's [OUTPUT_SCHEMA] placeholder alone. This reduces parsing failures. The harness must validate the model's output against the expected schema before routing to human approval. Key validation checks include: the rollback_recommendation field is one of the allowed enum values, the confidence_score is a float between 0 and 1, the rollback_steps array is non-empty if a rollback is recommended, and the rollback_safety_check includes a safe_to_rollback boolean. If validation fails, increment the retry counter and re-invoke with the validation error appended to the prompt context. After the retry budget is exhausted, escalate with a clear summary of what the model returned and why it failed validation. Never auto-execute a rollback from this prompt's output without human approval.