Configuration Change Impact Summary Prompt

This prompt is designed for SRE and operations teams who need a human-readable checkpoint before a configuration change is applied. It forces the model to reason about the blast radius, cascading effects, and risk level, producing a structured summary that can be reviewed and approved before any irreversible action. Use this when your change management process requires documented impact analysis, when you are building an AI-assisted operations copilot, or when you need to generate audit-ready pre-change summaries.

The ideal workflow integrates this prompt into a deployment or change pipeline where a proposed configuration diff is the primary input. The model receives the diff, the target environment, and a list of dependent services, then outputs a structured impact assessment. This output should be routed to a human approval queue, not executed automatically. The prompt is most effective for changes that touch shared infrastructure, security groups, network policies, or stateful services where a misconfiguration could cause cascading failures. It is less useful for stateless, read-only, or fully isolated changes where the blast radius is trivially zero.

Do not use this prompt for trivial or read-only operations where the overhead of a summary outweighs the risk. Avoid it for changes that are fully covered by automated canary analysis with automatic rollback, or for environments where every change already requires a manual change ticket with a filled-out risk template. In those cases, the prompt adds latency without adding decision quality. The prompt is also not a substitute for static analysis of configuration files; it should complement, not replace, linting and policy-as-code checks.

This prompt template is designed to be pasted directly into your system instructions or sent as a user message. It instructs the model to act as an SRE reviewer, generating a structured summary of a proposed configuration change. The summary captures the change itself, the systems affected, a blast radius analysis, a risk assessment, and a clear go/no-go recommendation. The template uses square-bracket placeholders that you must replace with real data from your change management system, such as the change ticket, the target system, and the proposed configuration diff.

markdownCopy
You are an SRE Change Review Assistant. Your task is to generate a structured summary of a proposed configuration change before it is applied. You must analyze the provided information and produce a report that helps a human reviewer quickly understand the intent, scope, and risk of the change.

## Input Data
- **Change Ticket:** [CHANGE_TICKET_ID]
- **Requestor:** [REQUESTOR_NAME]
- **Target System:** [TARGET_SYSTEM]
- **Proposed Configuration Diff:**
  ```diff
  [CONFIGURATION_DIFF]

• Change Window: [CHANGE_WINDOW_START] to [CHANGE_WINDOW_END]
• Rollback Plan: [ROLLBACK_PLAN]
• Related Recent Incidents: [RELATED_INCIDENT_IDS]

Output Schema

Generate a JSON object with the following structure. Do not include any text outside the JSON. { "change_summary": { "intent": "A one-sentence summary of what this change intends to accomplish.", "technical_details": "A concise technical description of the configuration change." }, "blast_radius_analysis": { "directly_affected_systems": ["List of systems directly modified by this change."], "indirectly_affected_systems": ["List of upstream/downstream systems that could experience cascading effects."], "potential_cascading_failures": "A description of how a failure could propagate, e.g., 'A failure in the auth service could prevent all users from logging in.'" }, "risk_assessment": { "risk_level": "Low | Medium | High | Critical", "justification": "A clear explanation for the assigned risk level, referencing the blast radius, change complexity, and recent incidents.", "key_risks": ["A list of the top 2-3 specific failure modes."] }, "recommendation": { "action": "Proceed | Proceed with Caution | Do Not Proceed", "preconditions": ["A list of conditions that must be met before proceeding, e.g., 'Verify backup is complete', 'Notify on-call engineer'."], "monitoring_plan": "Specific metrics or logs to monitor during and after the change." } }

Constraints

• If the [CONFIGURATION_DIFF] is empty or missing, set the risk_level to "Critical" and the action to "Do Not Proceed", with a justification stating the diff is missing.
• If the blast radius cannot be determined from the provided information, explicitly state "Unknown - requires manual review" in the potential_cascading_failures field and escalate the risk level.
• Do not invent system dependencies. Only list systems mentioned in the input or that are universally known dependencies (e.g., DNS).
• The monitoring_plan must include at least one specific metric or log query.

To adapt this template, replace each [PLACEHOLDER] with data from your source of truth. The [CONFIGURATION_DIFF] is the most critical input; a unified diff format works best. For high-risk environments, you should add a [REQUIRED_APPROVERS] field to the prompt and a corresponding approval_status object to the output schema. Before deploying this prompt, run it against a golden dataset of past changes—both successful and failed—to calibrate the risk assessment logic and ensure the blast radius analysis is not missing critical downstream dependencies.

This prompt is designed to be a synchronous pre-action gate in a change management pipeline. The application should call the LLM with the structured prompt before executing any configuration change, treating the generated summary as a required artifact. The output must be parsed, validated, and logged to an audit system (e.g., a change management database or an incident management platform like ServiceNow or PagerDuty) before the change proceeds. The harness should never allow a change to execute if the summary generation fails validation or if the risk assessment exceeds a predefined threshold without explicit human approval.

The implementation should enforce a strict schema on the LLM's output. Parse the response as JSON and validate that all required fields are present: change_summary, affected_systems, cascading_effects, risk_assessment (with level and justification), and rollback_plan. If the output fails to parse or is missing a field, retry the prompt once with a specific error message injected into the [CONSTRAINTS] variable (e.g., 'Your previous response was missing the cascading_effects field. You must provide a complete JSON object.'). If the second attempt fails, block the change and escalate to a human on-call with the raw LLM output and the validation error. For model choice, use a model with strong JSON mode and reasoning capabilities (e.g., Claude 3.5 Sonnet or GPT-4o) and set temperature to 0 to minimize variance in risk classification.

The risk assessment field must drive an automated routing decision in the harness. Implement a rule: if risk_assessment.level is high or critical, the change must be routed to a human approval queue with the full summary, and execution must be blocked until an authorized responder approves it. For medium risk, the change can proceed automatically but must be logged with a flag for post-deployment review. The harness should also check for a missing blast radius analysis by scanning the cascading_effects array; if it is empty or contains only generic statements like 'no impact,' treat this as a potential failure mode and escalate for human review, as it likely indicates the model failed to identify downstream dependencies. Always log the full prompt, the model's response, the validation result, and the routing decision for auditability.