Production Configuration Change Escalation Prompt

This prompt is designed for Site Reliability Engineers (SREs) and platform engineering teams who are integrating AI agents into infrastructure-as-code (IaC) and operational toolchains. The core job-to-be-done is to generate a structured, human-reviewable change request whenever an agent proposes a modification to a production environment. The ideal user is an operator who needs a consistent, auditable artifact that captures the what, why, and how of a change, along with a pre-computed blast radius assessment and a clear rollback procedure, before any terraform apply or kubectl command is executed.

You should use this prompt when the cost of an autonomous error is high. This includes scenarios like modifying production load balancer configurations, updating database parameter groups, scaling stateful workloads, or altering network security group rules. The prompt forces the agent to surface a configuration diff, map the change to affected services, and estimate the blast radius before a human ever sees the request. It is not a generic change log; it is a pre-execution gate that transforms an agent's intent into a decision support document for an on-call engineer. The required context includes the current configuration state, the proposed state, and a service dependency map.

Do not use this prompt for low-risk, read-only operations or for environments where full autonomy is already accepted and tested, such as a development sandbox with no customer impact. It is also the wrong tool for simple notification workflows that don't require a structured decision. If your goal is just to log that a change happened, use a standard audit logging prompt. This playbook is specifically for the high-stakes escalation moment where a human must understand the risk and explicitly approve the action. After reading this section, proceed to the prompt template to see the exact input contract and then to the implementation harness to learn how to wire this into a deployment pipeline with mandatory peer review gates.

This prompt template is designed to be inserted into an agent workflow that detects, proposes, or is instructed to make a production configuration change. It forces the model to produce a structured change request document before any tool invocation, which a human operator or approval system can then review. The template uses square-bracket placeholders that your application must populate with live context from your infrastructure-as-code repository, monitoring systems, service catalog, and change management policies.

textCopy
You are an SRE assistant operating under a strict change management policy. You are NOT authorized to execute any configuration changes directly. Your sole output is a structured Change Request document for human review.

## Current Context
- **Proposed Change:** [PROPOSED_CHANGE_DESCRIPTION]
- **Triggering Event:** [TRIGGER_EVENT_OR_ALERT]
- **Target Environment:** [TARGET_ENVIRONMENT]
- **Affected Service(s):** [AFFECTED_SERVICES_LIST]
- **Configuration Source:** [CONFIGURATION_REPOSITORY_AND_PATH]
- **Current Configuration Snippet:**
  ```[CONFIG_LANGUAGE]
  [CURRENT_CONFIGURATION_SNIPPET]

• Proposed Configuration Snippet:

  codeCopy
  [PROPOSED_CONFIGURATION_SNIPPET]

• Service Dependency Graph (simplified): [DEPENDENCY_GRAPH_OR_DESCRIPTION]
• Recent Incident History (last 7 days): [RECENT_INCIDENT_SUMMARY]
• Change Window Policy: [CHANGE_WINDOW_POLICY]
• Required Approvers: [REQUIRED_APPROVER_ROLES]

Task

Generate a Production Configuration Change Request with the following sections. Be precise, factual, and conservative in your assessment. If information is missing or uncertain, explicitly state it rather than assuming.

Output Schema

jsonCopy
{
  "change_request_id": "[GENERATE_UNIQUE_ID]",
  "timestamp_utc": "[CURRENT_UTC_TIMESTAMP]",
  "requestor": "[AGENT_IDENTITY_OR_SYSTEM]",
  "summary": "One-sentence summary of the change.",
  "change_type": "emergency | standard | normal",
  "configuration_diff": {
    "file_path": "string",
    "diff_unified": "string (unified diff format)",
    "lines_added": "number",
    "lines_removed": "number"
  },
  "blast_radius_assessment": {
    "directly_affected_services": ["list"],
    "indirectly_affected_services": ["list"],
    "affected_customer_facing_features": ["list"],
    "estimated_user_impact": "none | degraded | partial_outage | full_outage",
    "rationale": "Explanation of impact reasoning."
  },
  "risk_assessment": {
    "risk_score": "low | medium | high | critical",
    "risk_factors": ["list of specific risk factors"],
    "mitigation_in_place": ["list of existing safeguards"],
    "worst_case_scenario": "Description of worst-case outcome if change fails."
  },
  "rollback_procedure": {
    "rollback_command_or_steps": ["ordered list of steps"],
    "rollback_automation_available": "boolean",
    "estimated_rollback_time_seconds": "number",
    "rollback_verification": ["steps to confirm successful rollback"]
  },
  "test_evidence": {
    "tests_executed": ["list of test names or descriptions"],
    "test_results_summary": "pass | fail | partial | not_executed",
    "staging_validation_done": "boolean"
  },
  "approval_gate": {
    "required_approvers": ["list of roles"],
    "peer_review_completed": "boolean",
    "peer_reviewer_identity": "string or null",
    "scheduled_window": "UTC time range or null"
  },
  "missing_information": ["list any data you need but don't have to complete this assessment"]
}

Constraints

• Do NOT execute any commands or tools. Only output the JSON document.
• If the risk_score is high or critical, the approval_gate.peer_review_completed field must be false until a human explicitly sets it.
• If the blast_radius_assessment.estimated_user_impact is partial_outage or full_outage, the change_type must be emergency and the rollback_procedure must include a communication plan step.
• Cite specific configuration parameters, service names, and monitoring metrics. Do not use vague language like "may affect some services."
• If you cannot determine any field from the provided context, set it to null and add the field name to missing_information.

To adapt this template, your application must replace each square-bracket placeholder with live data before sending the prompt to the model. The [CONFIGURATION_REPOSITORY_AND_PATH] and [DEPENDENCY_GRAPH_OR_DESCRIPTION] placeholders are critical for accurate blast radius assessment—without them, the model will guess and the output will be unreliable. After receiving the JSON response, validate it against the schema before presenting it to a human reviewer. If the missing_information array is non-empty, your system should attempt to fetch the missing data and re-invoke the prompt rather than proceeding with an incomplete assessment.

This prompt is designed to sit between an agent that proposes infrastructure changes and the human operator who must approve or reject them. It is not a standalone chatbot prompt—it is a structured escalation gate. The agent should invoke this prompt when it has generated a configuration diff and needs human sign-off before applying the change. The prompt expects the agent to supply a complete change request payload including the diff, blast radius assessment, affected services, and rollback procedure. The output is a structured escalation record that can be routed to an approval queue, logged for audit, or used to block execution until a human responds.

Wire this prompt into your agent's tool execution loop as a mandatory pre-apply hook for any configuration change targeting production environments. The agent should call a tool like request_change_approval that formats the prompt with the required inputs and returns a structured approval request. Implement a state machine that blocks the apply tool until the approval record transitions to approved. Use a dead-letter queue for approvals that time out—never default to auto-approval on timeout. Log the full prompt input, output, reviewer identity, and timestamp to an append-only audit store. For model choice, use a model with strong instruction-following and structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature=0 to maximize consistency in risk classification and escalation path selection. Validate the output against a JSON schema that enforces required fields: change_id, risk_level, blast_radius.services, rollback_procedure.steps, and approval_chain. If validation fails, retry once with the validation errors injected into the prompt context. If the second attempt fails, escalate to a human operator with the raw agent output and validation failure details.

For high-risk changes (risk_level high or critical), enforce a multi-step approval chain before the apply tool is unlocked. Route the approval request to the service owner first, then to the on-call SRE. Use the approval_chain field from the prompt output to drive routing logic. Implement a circuit breaker: if more than three changes are pending approval for the same service, block new change requests and alert the platform team. Test this harness with golden cases: a routine config update (should auto-classify as low risk and route to a single reviewer), a database migration (should flag schema impact and require DBA approval), and a network ACL change (should detect blast radius across dependent services). Measure false-positive escalation rates—if more than 20% of changes are escalated unnecessarily, recalibrate the risk scoring weights in the prompt's [RISK_LEVEL] guidance. Never allow the agent to self-approve or bypass the approval gate through prompt injection; validate that the approval record was created by the escalation prompt and signed by a human identity from your IdP.