# who_uses and impact_of: what a real call graph does that grep can't

Grep finds text. A resolved call graph answers "who calls this?" and "what breaks if I change it?" — across modules, ranked by confidence, without guessing.

Ask grep "who calls `verifyToken`?" and it finds every line with the text `verifyToken` — the definition, the imports, the comments, a variable that happens to share the name, and the actual callers, all mixed together. Useful, but it's *text matching*, not *understanding*.

## What a resolved call graph knows

SecondOS parses your repo into real symbols and resolves the calls between them — across files and modules, honoring import aliases and re-exports. So it can answer questions grep can't:

- **`who_uses(verifyToken)`** — the actual callers, resolved across modules, ranked by confidence (exact / resolved / heuristic). Not text hits.
- **`impact_of(verifyToken)`** — the blast radius of a change: what *will* break vs what *might* break, following the graph outward.

This works across seven languages with full call-graph resolution: TypeScript/JS, Go, Python, Rust, Java, PHP and Ruby.

## The honest part: it won't guess

Some calls genuinely can't be resolved without running your code — dynamic dispatch, an instance method whose receiver type isn't statically known. SecondOS marks those `unknown` rather than pointing you at a plausible-but-wrong caller. A lower resolution number is a *precision stance*, not a coverage gap: `impact_of` is only useful if you can trust it.

## Why it matters for AI tools

When your AI tool reads the graph over [MCP](/docs/mcp), its suggestions get better because it knows which function actually calls which — not which functions share a substring. And the graph is what lets SecondOS auto-write the [dependency map and module docs](/docs/knowledge-base) no text-based tool can.

[See how the graph fits together](/product).