# Impact Analysis Guide

**Complete guide for AI-powered dependency and blast radius analysis with the DevOps AI Toolkit.**

> **Note**: The examples below use MCP, but this tool is also available via the [CLI](/docs/cli), [Web Dashboard](/docs/ui), and [Headlamp Plugin](/docs/headlamp).

## Prerequisites

Before using this guide, complete the [Deployment Guide](../setup/deployment.md).

**Optional but recommended:**
- Scanned capabilities — see [Capability Management](capability-management.md)
- Resources synced to Vector DB — automatically handled by the [dot-ai-controller](/docs/controller/setup-guide)

## Overview

**What it does:**
- **Blast radius assessment** — Maps all resources affected by a proposed operation before you execute it
- **Multi-level dependency tracing** — Follows dependency chains iteratively (e.g., PVC → Pod → Service → Ingress), not just first-level relationships
- **Free-text input** — Accepts kubectl commands, YAML manifests, or plain-English descriptions
- **Confidence-level reporting** — Categorizes each discovered dependency as Definite, Likely, or Uncertain
- **GitOps-aware** — When you reference a git repo and file change, clones the repo and reads the actual manifest to verify the change
- **Safe/not-safe verdict** — Returns a clear signal on whether the operation is safe to proceed

**Use when:**
- Unsure about the impact of an operation on your cluster

### How It Works

The AI combines three sources to discover dependencies:

1. **Built-in AI knowledge** — Standard Kubernetes relationships (Deployment → ReplicaSet → Pod, Service → Endpoints) and ecosystem tools (CNPG Cluster → Pod/PVC/Service, Crossplane XR → MR, Istio VirtualService → Service, etc.)
2. **Cluster inspection** — Reads the actual cluster state: ownerReferences, resource specs that reference other resources by name, events, labels, and annotations
3. **Capabilities and resources** — If available, searches the Vector DB for semantic understanding of your cluster's resource types and their relationships

The AI iteratively follows dependency chains using these sources — the same way a human expert would investigate. When it can't confirm a relationship, it tells you.

### Confidence Levels

Each dependency in the analysis is tagged with a confidence level:

| Level | Meaning | Example |
|-------|---------|---------|
| **Definite** | Confirmed from cluster data or git source | ownerReference links Pod to its parent Cluster |
| **Likely** | Based on ecosystem knowledge, not verified in cluster | "CNPG typically creates a Service for each Cluster" |
| **Uncertain** | Might be affected but cannot confirm | Unknown CRD without documentation |

## Complete Workflow Examples

### Plain-English Input

```text
User: What happens if I delete the postgres service in the production namespace?
```

```text
Agent: I'll analyze the blast radius of deleting the postgres service.

[Uses impact_analysis tool with input: "what happens if I delete the postgres service in the production namespace?"]

The operation is NOT safe. Here's the analysis:

There's no service literally named "postgres" — the CNPG Cluster "test-pg" manages
three services: test-pg-rw, test-pg-r, and test-pg-ro.

Deleting any of them would cause:

DEFINITE impact:
- test-pg-rw — clients using it for write access to the primary (test-pg-1)
  lose connectivity immediately
- test-pg-r — clients reading from any instance lose connectivity
- test-pg-ro — clients using read-only routing lose connectivity

LIKELY impact:
- The CNPG operator will automatically recreate deleted services, but there's
  a disruption window
- Applications in other namespaces with hardcoded DNS references will get
  connection failures
- Monitoring targets become unavailable

Risk summary:
- Data loss risk: LOW — services are networking constructs, not data
- Service disruption risk: HIGH — all database connectivity breaks immediately
- Automatic recovery: YES — the operator recreates services within minutes,
  but there's a gap
- Cascading failures: MEDIUM — anything currently connected will fail

Recommendation: Don't delete these services. If you need to reconfigure,
modify them instead.
```

**What happened behind the scenes:**
- AI parsed the plain-English description and identified the target resources
- No service named "postgres" existed — AI discovered the actual CNPG-managed services
- Investigation traced dependencies: Services → Pods → client connections → monitoring
- Confidence levels distinguished between confirmed cluster state (Definite) and ecosystem knowledge (Likely)