How GitNexus Calculates Blast Radius and Confidence Scores in Impact Analysis

GitNexus calculates blast radius by performing a depth‑bounded traversal of the knowledge graph up to three levels deep, then classifies risk using thresholds on direct dependencies, affected processes, and module hits, while confidence scores propagate directly from edge properties assigned during code ingestion.

The gitnexus impact command evaluates how a change to any symbol propagates through your codebase. This analysis relies on a Neo4j‑backed knowledge graph that stores symbols as nodes and relationships as typed edges with confidence metadata. Understanding the precise calculation methods helps teams assess deployment risk and prioritize testing efforts.

How GitNexus Calculates Blast Radius

The blast radius calculation occurs in three distinct stages implemented in gitnexus/src/mcp/local/local-backend.ts (lines 1316‑1476). Each stage refines the set of impacted entities and assigns a risk classification.

Stage 1: Symbol Resolution

The engine begins by locating the target symbol in the graph using a Cypher query:

MATCH (n) WHERE n.name = $targetName

Once the target node is identified, the system prepares for directional traversal. You can analyze upstream impact (who calls or imports the symbol) or downstream impact (what the symbol calls or imports).

Stage 2: Depth‑Bounded Graph Traversal

Starting from the target node, GitNexus walks CodeRelation edges with configurable constraints. The traversal stops at maxDepth (default 3), recording the depth level for every discovered node to enable grouping (d = 1, 2, 3).

The query builder filters on three criteria (see lines 29‑31, 36‑37, 69):

• Relation types: Only CALLS, IMPORTS, EXTENDS, and IMPLEMENTS edges are followed
• Confidence threshold: Optional minConfidence filter (default 0.7) prunes low‑trust edges
• Test file exclusion: Nodes where isTestFilePath is true can be excluded

The directional Cypher templates look like this:

const query = direction === 'upstream'
  ? `MATCH (caller)-[r:CodeRelation]->(n) WHERE n.id IN [${idList}]
     AND r.type IN [${relTypeFilter}]${confidenceFilter}
     RETURN n.id AS sourceId, caller.id AS id, caller.name AS name,
            labels(caller)[0] AS type, caller.filePath AS filePath,
            r.type AS relType, r.confidence AS confidence`
  : `MATCH (n)-[r:CodeRelation]->(callee) WHERE n.id IN [${idList}]
     AND r.type IN [${relTypeFilter}]${confidenceFilter}
     RETURN ...`;

Each discovered node stores its confidence value (taken from r.confidence or defaulting to 1.0) and the depth at which it was first encountered (lines 75‑82). The system builds a byDepth map (lines 90‑94) that groups results by traversal distance.

Stage 3: Enrichment and Risk Classification

After the graph walk completes, GitNexus enriches the raw impact set to calculate business risk:

1. Affected processes – Queries STEP_IN_PROCESS edges to identify which execution flows contain impacted nodes (lines 105‑112)
2. Affected modules – Queries MEMBER_OF edges to count hits per community and determine if a module is hit directly (d = 1) or indirectly (lines 115‑124)

Risk scoring applies threshold logic to four metrics: directCount (depth = 1 hits), processCount, moduleCount, and total impacted.length (line 50). The classification matrix works as follows:

• CRITICAL: directCount >= 30 OR processCount >= 5 OR moduleCount >= 5 OR impacted.length >= 200
• HIGH: directCount >= 15 OR processCount >= 3 OR moduleCount >= 3 OR impacted.length >= 100
• MEDIUM: directCount >= 5 OR impacted.length >= 30
• LOW: All other cases

This matrix mirrors the risk assessment table documented in gitnexus/skills/gitnexus-impact-analysis.md.

Confidence Score Calculation and Propagation

Confidence scores in GitNexus are not calculated during impact analysis; they are assigned during graph ingestion and propagated unchanged to results.

Edge Confidence Origins

Every CodeRelation edge stores a confidence property of type DOUBLE, defined in gitnexus/src/core/graph/types.ts. The ingestion pipeline assigns these values based on detection method:

• Graph‑derived edges: AST‑detected calls receive confidence: 1.0 (see call-processor.ts and related ingestion files)
• Fuzzy or text‑search edges: Receive lower scores based on heuristics:
  • Same‑file matches: 0.85
  • Import‑resolved matches: 0.9
  • Ambiguous global matches: 0.5 or 0.3 (lines 273‑293 in call-processor.ts)

Confidence Filtering in Impact Analysis

During the impact traversal, the stored edge confidence is copied directly into result objects (line 81). Users can filter results via the minConfidence parameter to exclude uncertain relationships. The UI displays confidence parenthetically (e.g., “(conf: 0.85)”) to help developers assess the reliability of each dependency link.

Practical Usage Examples

Run a basic upstream impact check using defaults (depth = 3, confidence ≥ 0.7):

gitnexus impact AuthService --direction upstream

Restrict the blast radius to two levels and require high confidence:

gitnexus impact validateUser \
  --direction upstream \
  --maxDepth 2 \
  --minConfidence 0.9

Invoke programmatically via the MCP API in Node.js:

await backend.callTool('impact', {
  target: 'validateUser',
  direction: 'upstream',
  maxDepth: 2,
  minConfidence: 0.9,
});

Summary

• Blast radius is determined by a depth‑bounded traversal (default 3 levels) of CodeRelation edges in the knowledge graph, tracking upstream or downstream dependencies.
• Risk classification uses hard thresholds on direct dependencies (depth = 1), affected process flows, affected modules, and total impacted node count to produce LOW, MEDIUM, HIGH, or CRITICAL ratings.
• Confidence scores originate during ingestion (AST‑derived = 1.0, fuzzy = 0.3‑0.9) and propagate unchanged through the impact analysis; the minConfidence filter (default 0.7) removes low‑trust edges from results.
• Core implementation resides in gitnexus/src/mcp/local/local-backend.ts (lines 1316‑1476), with tool schema defined in gitnexus/src/mcp/tools.ts (lines 75‑95).

Frequently Asked Questions

How does GitNexus determine which risk level to assign?

GitNexus assigns risk levels by evaluating four metrics against specific thresholds. If direct dependencies (depth = 1) exceed 30, or affected processes exceed 5, or total impacted nodes exceed 200, the change is marked CRITICAL. Lower thresholds trigger HIGH, MEDIUM, or LOW classifications accordingly, as implemented in the conditional block starting at line 50 of local-backend.ts.

What confidence score should I use for high‑trust analysis?

Set --minConfidence 0.9 or higher to include only import‑resolved and AST‑derived relationships, excluding fuzzy text matches. The default value of 0.7 balances coverage with accuracy, while values below 0.5 include highly ambiguous global symbol matches that may produce false positives.

Can I exclude test files from the blast radius calculation?

Yes. The impact analysis query builder supports filtering on the isTestFilePath property (line 69). When enabled, nodes located in test directories are excluded from traversal results, ensuring the blast radius reflects only production code dependencies.

Where does the graph store confidence values for edges?

The confidence property is defined as a DOUBLE on all CodeRelation edges in the graph schema (gitnexus/src/core/graph/types.ts). During ingestion, processors like call-processor.ts assign values ranging from 1.0 for precise AST detections down to 0.3 for ambiguous global matches, which the impact tool then reads without modification.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}