Change Propagation Risk Assessment Prompt

This prompt is for architects and platform engineers who need to evaluate the blast radius of a proposed code or design change before implementation begins. The core job-to-be-done is producing a risk-scored impact report that lists affected modules, estimates breakage probability, and recommends test priorities. Use this when a change touches a shared interface, a foundational library, a database schema, or any widely-depended-upon component where an uncaught regression could cascade across the system. The prompt requires source-grounded evidence for every affected path it identifies, so it is only effective when the codebase, dependency graph, or design documentation is available for inspection.

Do not use this prompt for trivial changes with no transitive dependencies, such as isolated UI string updates or single-file utility functions with zero importers. It is also inappropriate when the codebase is not available for inspection—this is a design-level static analysis tool, not a runtime monitoring solution. The prompt works best when paired with concrete artifacts: import graphs, API specifications, database schemas, or architecture decision records. Without these, the model will hallucinate dependency paths. For high-risk domains like payments, auth, or data integrity, always require human review of the generated impact report before accepting it as a release gate. The output is a decision-support artifact, not an automated approval.

Before running this prompt, gather the proposed change description, the affected component's interface surface, and a dependency map if available. After receiving the output, validate that every affected path listed has a corresponding source reference. If the model cannot ground a path, flag it for manual investigation. The next section provides the copy-ready prompt template you can adapt with your own input variables, output schema, and risk thresholds.

The following prompt template is designed to be pasted directly into your AI harness. It instructs the model to act as a systems architect, analyze a proposed change against a provided dependency graph or codebase context, and produce a structured risk assessment. Every placeholder is enclosed in square brackets. Replace them with concrete values before execution. The prompt enforces source-grounding, meaning every affected module listed in the output must be traceable back to the evidence you provide in [DEPENDENCY_CONTEXT].

textCopy
You are a systems architect specializing in dependency analysis and change risk assessment. Your task is to evaluate the blast radius of a proposed change and produce a structured risk report.

## INPUT
[CHANGE_DESCRIPTION]

## CONTEXT
[DEPENDENCY_CONTEXT]

## CONSTRAINTS
- Ground every affected module, file, or service in the provided [DEPENDENCY_CONTEXT]. Do not invent dependencies.
- Classify each affected component's breakage probability as HIGH, MEDIUM, or LOW based on directness of coupling and interface contract strictness.
- If the change involves a public API, assess both internal and external consumer impact separately.
- Flag any circular dependencies that amplify risk.
- If the provided context is insufficient to assess a likely impact, explicitly state that instead of guessing.

## OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "change_summary": "A one-sentence summary of the proposed change.",
  "risk_score": "OVERALL_RISK_LEVEL", // HIGH, MEDIUM, or LOW
  "affected_components": [
    {
      "component_path": "string",
      "dependency_type": "DIRECT | TRANSITIVE | CONFIGURATION | DATA_CONTRACT",
      "breakage_probability": "HIGH | MEDIUM | LOW",
      "rationale": "string explaining the coupling and why breakage is likely or unlikely, citing specific evidence from [DEPENDENCY_CONTEXT]",
      "recommended_test_priority": "CRITICAL | HIGH | MEDIUM | LOW"
    }
  ],
  "amplifying_factors": ["List any circular dependencies, god components, or shared mutable state that increase the blast radius."],
  "test_recommendations": {
    "critical_path_tests": ["List of specific test cases or test suites to run first."],
    "integration_test_targets": ["List of integration points that need verification."],
    "monitoring_signals": ["List of metrics, logs, or alerts to watch during rollout."]
  },
  "insufficient_context_notes": ["List any questions that must be answered before a complete assessment is possible, or null if the context is sufficient."]
}

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

To adapt this template, start by replacing [CHANGE_DESCRIPTION] with a precise description of the proposed code, schema, or API change. Populate [DEPENDENCY_CONTEXT] with a dependency graph, import statements, build manifest, or architecture decision records. The quality of the output depends entirely on this context. [FEW_SHOT_EXAMPLES] should contain one or two example input-output pairs that demonstrate the desired level of detail and grounding. Set [RISK_LEVEL] to the organizational risk tolerance for this type of change, which influences how conservative the model's probability estimates should be. After generating the output, validate that every component_path in affected_components appears in your provided context. If the model returns insufficient_context_notes, resolve those questions and re-run the prompt before making a release decision.

This prompt is designed to operate inside a deterministic harness, not as a free-text chat. The harness must supply the proposed change description, the affected module or component list, and the dependency graph or import structure as structured [INPUT]. The model's job is to reason over that graph and produce a scored impact report. The harness is responsible for providing accurate graph data; the model is responsible for traversal reasoning and risk classification. Do not ask the model to invent the dependency graph from memory or training data—source-ground every edge.

Build the harness in three stages: pre-processing, invocation, and post-processing. In pre-processing, extract the dependency graph from your build system (e.g., madge, dependency-cruiser, or a custom import parser) and serialize it as an adjacency list or edge list in JSON. Attach file paths, module names, and any known architectural rules (layer boundaries, allowed dependency directions). In the invocation stage, inject this graph into the [DEPENDENCY_GRAPH] placeholder along with the [PROPOSED_CHANGE] description and a [RISK_THRESHOLD] for filtering low-impact paths. In post-processing, validate that every affected path in the model's output references a real edge present in the input graph. Reject hallucinated paths. Log the input graph hash, the prompt version, and the model response for auditability.

For high-risk changes—those touching authentication, data persistence, payment flows, or security boundaries—route the output to a human review queue before accepting it. The harness should flag any report where the estimated breakage probability exceeds 0.7 or where the blast radius crosses a declared architectural boundary. Use a structured output schema with fields like affected_modules, propagation_paths, breakage_probability, test_priority, and evidence_edges so that downstream tooling can parse the report and automatically generate a test plan or a CI/CD risk comment.

Model choice matters. Use a model with strong reasoning capabilities and a large context window if the dependency graph exceeds 200 edges. For smaller graphs, a faster model with constrained output (JSON mode, strict schema) works well. Implement retry logic: if the output fails schema validation or references edges not in the input graph, retry once with a stricter prompt that includes the validation error message. After two failures, escalate to a human with the partial output and the validation errors. Never silently accept an unvalidated risk report.