Risk Assessment

1. Affected files and modules. Trace the root cause from the analysis artifact to the source files that need to change. List them.
2. Number of repositories. Will the fix span multiple repos (e.g., carbon-apimgt + product-apim)? Check if template files, config files, or build artifacts in other repos also need updating.
3. Dependency graph. Identify what depends on the code being changed — downstream callers, API consumers, template renderers, serialization paths.
4. Change type. Classify as one of:
   • Cosmetic — typo, log message, comment, docs
   • Config — property/config file change, feature toggle
   • Logic — behavioral change in a single method/class
   • Structural — new/renamed classes, changed method signatures, moved code
   • Cross-cutting — changes spanning multiple modules, layers, or repos
   • Schema — database migration, API contract change, wire format change

Step 2: Score Each Risk Dimension

Evaluate each dimension independently on a 0-3 scale (0 = no risk, 1 = low, 2 = moderate, 3 = high). Use the rubrics below.

Dimension 1: Diffusion (how spread out is the change?)

Dimension 2: Criticality (how sensitive is the affected area?)

Dimension 3: Reversibility (how hard is it to undo?)

Dimension 4: Blast Radius (how many things could break?)

Dimension 5: Complexity (how hard is the fix to get right?)

Step 3: Compute the Risk Score

Calculate the weighted composite score:

raw = (Diffusion x 1.0) + (Criticality x 1.5) + (Reversibility x 1.5) + (Blast Radius x 1.0) + (Complexity x 1.0)
max_possible = (3 x 1.0) + (3 x 1.5) + (3 x 1.5) + (3 x 1.0) + (3 x 1.0) = 18
risk_score = round((raw / max_possible) x 10)

Criticality and Reversibility are weighted 1.5x because security issues and irreversible changes have outsized consequences.

After computing, apply a sanity check. Does the score match your gut feeling? If not, explain why in the report and adjust by at most 1 point with justification. The formula is a guide, not a prison.

Score Interpretation

Step 4: Identify Risk Factors

List specific risk factors that contribute to the score. For each factor, explain:

• What the risk is
• Why it matters for this specific issue
• What could go wrong if the fix is incorrect

Also list any mitigating factors that reduce risk (e.g., good test coverage exists, the change is additive-only, the affected code path is already well-understood from reproduction).

Step 5: Estimate Fix Scope

Based on your analysis, estimate:

• Number of files likely to change
• Number of repos involved
• Whether a product rebuild is needed
• Whether the fix requires template/config changes alongside Java code
• Expected fix complexity (will the agent need many iterations or should it be straightforward?)

Step 6: Write the Output Artifact

Create .ai/risk-assessment-<issue_number>.md using this exact format:

# Risk Assessment — Issue #<issue_number>: <issue_title>

## Risk Score: <score>/10 (<level>)

## Dimension Scores

| Dimension | Score (0-3) | Rationale |
|-----------|-------------|-----------|
| Diffusion | <n> | <one-line explanation> |
| Criticality | <n> | <one-line explanation> |
| Reversibility | <n> | <one-line explanation> |
| Blast Radius | <n> | <one-line explanation> |
| Complexity | <n> | <one-line explanation> |

**Weighted calculation:** (<diffusion> x 1.0) + (<criticality> x 1.5) + (<reversibility> x 1.5) + (<blast_radius> x 1.0) + (<complexity> x 1.0) = <raw> / 18 x 10 = <score>
**Sanity adjustment:** <none, or +/- N with justification>

## Risk Factors

- <factor 1>: <explanation of what could go wrong>
- <factor 2>: <explanation>
- ...

## Mitigating Factors

- <factor 1>: <explanation of why this reduces risk>
- ...

## Estimated Fix Scope

- **Files to change:** ~<n>
- **Repos involved:** <list>
- **Rebuild required:** Yes / No
- **Template/config changes:** Yes / No
- **Expected iterations:** <low — should be straightforward / medium — may need 2-3 attempts / high — complex multi-step fix>

## Recommendation

<One of:>
- **PROCEED** — Low risk, suitable for automated fix.
- **PROCEED WITH CAUTION** — Medium risk, automated fix is reasonable but human should review the output closely.
- **HUMAN REVIEW REQUIRED** — High risk, a human engineer should review the analysis and approve the fix approach before the agent proceeds.
- **HAND OFF** — Critical risk or unclear root cause. This issue should be fixed by a human engineer, not an automated agent.

<Brief explanation of why this recommendation was chosen.>

Important Rules

• Never guess dimension scores. If you cannot determine a dimension (e.g., you don't know what the affected code path touches), score it as the higher option and explain your uncertainty.
• Read the actual source code. Don't score based only on the issue description. Trace the root cause to the source files, check what calls the affected code, check if tests exist.
• Calibration examples for reference:
  • Fixing a duplicated word in an error message string → 1/10
  • Adding a missing null check in a single method → 2/10
  • Fixing endpoint security copy constructor + template file across 2 repos → 6/10
  • Changing OAuth token validation logic in the Key Manager → 8/10
  • Database schema migration to add a column used by the gateway → 9/10
• Artifacts over memory. The report must be complete enough for a human reviewer or a different agent to understand the risk without re-doing the analysis.