The code graph

From source to relationships#

Arbor parses source code into symbols and relationships. Functions, classes, and modules become nodes. Resolved references connect them, allowing queries to follow dependencies across files.

The parser and graph engine provide structured context without an embedding service. A graph describes relationships recognized in source; it does not execute your program or observe production traffic.

Symbol

A named element of the code, associated with a file and source location.

Call edge

A resolved relationship from a caller to a callee.

Blast radius

Nodes the analysis reaches from changed or selected code, within its traversal rules and depth.

Centrality

A ranking derived from graph structure. Useful for orientation; not a measure of runtime usage or business importance.

Resolution and confidence#

A written import or a same-file definition gives the resolver stronger evidence than a name match elsewhere. Arbor records confidence for relationships so that a direct resolution and a heuristic match need not be treated as equivalent.

In v3.0.3, file imports and the caller's language family help choose between definitions that share a name, and Rust paths such as crate::jobs::enqueue() resolve through the module tree. Ambiguous names and incomplete type information can still produce missing or incorrect edges. When a name has one definition and no callers, arbor callers says which kinds of call the graph cannot follow.

Confidence describes the evidence used by the analyzer. It is not a calibrated probability that a change will break a caller.

Language coverage#

The public repository lists dedicated parsers for these languages:

• Rust
• TypeScript / JavaScript
• Python
• Go
• Java
• C / C++
• C#
• Dart

Kotlin, Swift, Ruby, PHP and Shell use a line-based fallback parser instead. It records declarations but not the calls inside them, so callers, callees and impact for those files are mostly empty. Coverage also varies within the languages above: a language appearing in the list does not mean every construct resolves.

Known limits in the public release#

The public v3.0.3 notes, and checks against the released binary, identify limitations that matter when interpreting results:

• Inheritance is only partly followed. v3.0.3 records class inheritance, so changing a base class now reports downstream impact. Python method calls are matched by their written text: self.run() inside a subclass is listed among the callers of Base.run, but Child().run() and item.run() on a local variable are not.
• Dynamic imports can be invisible. Runtime imports and reflection, including importlib, __import__, and dynamic JavaScript imports, may not resolve.
• Impact can overcount. Some smaller targets in the published fixture have more reported downstream nodes than the ground truth.

Turn a result into a review#

1. Check that the intended project and files were indexed.
2. Confirm the selected symbol's file and source location.
3. Inspect reported relationships and uncertain resolutions.
4. Read the code and run tests for the behavior being changed.

The recorded example on this site illustrates a review workflow. Its provenance identifies the engine used for that capture; it should not be read as a guarantee that every public release returns identical results.