Skip to main content

Graph Explorer

This page introduces the main controls in the Graph Explorer panel.

DependencyAtlas builds this graph from static and compiler-time source analysis. It is not a runtime execution trace, and the Graph Explorer should be read with that boundary in mind.

Graph Explorer

Modules: 4Files: 8Methods: 31Edges: 66
includedefineimportcall_exactcall_inferredcall_possiblecall_dynamic

Summary counters​

The four summary counters at the top show how many modules, files, methods, and edges are currently in the loaded graph snapshot.

They are useful as a quick sanity check before you start filtering:

  • Modules gives the current module count in the snapshot
  • Files gives the current file count
  • Methods gives the current method count
  • Edges gives the current edge count

These numbers describe the loaded graph data, not only the nodes currently visible after every filter.

Layer​

DependencyAtlas exposes three graph layers:

  • method
  • file
  • module

The Layer selector switches between them. Each layer answers a different question.

Method view​

Use method view when you want the most detailed call and define relationships.

This is usually the best place to:

  • inspect concrete call chains
  • examine overloads
  • study external calls

File view​

Use file view when you want a structural overview of how source files relate to each other.

This is often the best entry point for understanding project shape without reading every method-level edge.

Module view​

Use module view when you want the highest-level architectural picture.

This is useful for:

  • package-level or subsystem-level understanding
  • explaining a codebase to someone else
  • finding broad boundaries before zooming back in

Confidence >=​

Confidence >= filters call evidence by evidence class.

DependencyAtlas uses:

  • exact
  • inferred
  • possible
  • dynamic

These values tell you what kind of evidence produced an edge. They do not mean "100% certain" versus "50% certain".

A useful way to read them is:

  • exact: direct structural evidence
  • inferred: compile-time inferred evidence
  • possible: ambiguous or heuristic static evidence
  • dynamic: unresolved or dynamic-dispatch evidence

In particular, call_inferred should be read as compiler-time or analysis-time evidence. It is helpful, but it is not a proof of complete runtime truth.

Node Search filters the graph by node label, fully qualified name, or kind.

Use it when you already know what you want to inspect and want to reduce the canvas quickly.

Layout​

Layout changes the broad layout direction or family used to place nodes.

In the current UI, the main presets are:

  • layered, left to right
  • layered, top to bottom
  • organic, left to right

Use layered layouts when you want clearer flow direction. Use the organic layout when you want a less rigid overview.

Layout Model​

Layout Model changes the layout engine variant behind the selected layout.

The current options are:

  • sugiyama lite (fastest)
  • elk layered crossing-min (slower)

Choose the faster option when you want quick iteration. Choose the slower option when you want a cleaner layered result and can tolerate more waiting.

Edge Path​

Edge Path changes how edges are drawn between nodes.

The current options are:

  • curved
  • orthogonal

This only changes edge routing style. It does not change the underlying graph data.

Reachability Direction​

Reachability Direction controls whether a reachability query follows:

  • callers
  • callees
  • both directions

Use callers when you want to know what can reach a node. Use callees when you want to know what a node can reach. Use both when you want a bounded neighborhood around the selected node.

Reachability Depth​

Reachability Depth sets how many steps away from the selected node the reachability query can expand.

A lower depth keeps the result focused. A higher depth shows more context, but can grow quickly in dense graphs.

Show Overloaded Functions​

Show Overloaded Functions reveals overloaded Base, Core, or stdlib generics that are relevant to the current graph.

This is useful when project methods extend shared generics and you want those overload sites to stay visible.

Show Base/Stdlib Calls​

Show Base/Stdlib Calls controls whether calls into Base and the Julia standard library remain visible.

Turn it on when you want more complete dependency context. Turn it off when you want to focus more narrowly on project-owned code.

Show External Package Calls​

Show External Package Calls controls whether calls into external packages remain visible in the graph.

This is especially useful when your project relies on package APIs and you want to see where those boundaries appear in the dependency story.

Edge kind filters​

The edge-kind chips let you enable or disable specific relationship kinds.

Typical examples include:

  • include
  • define
  • import
  • call_exact
  • call_inferred
  • call_possible
  • call_dynamic

Use these chips when the graph feels dense and you want to temporarily suppress one class of relationship without changing everything else.

Export controls​

The export buttons let you take the current graph state out of the UI:

  • Export to Clipboard
  • Export to File
  • Export .drawio

These are useful for sharing, debugging, creating static examples, or continuing work in external diagram tools.

Reading the graph itself​

The sections above describe the controls in the Graph Explorer panel. The sections below explain how to interpret the graph shown on the canvas once those controls are applied.

Read nodes first​

At a high level, nodes represent entities in the current layer:

  • methods in method view
  • files in file view
  • modules in module view

Some nodes belong to your project, while others represent external code such as Base, stdlib APIs, or external packages.

External nodes are useful because they show where your project touches code outside your own repository.

Then read edges​

Edges express relationships such as:

  • include
  • import
  • define
  • call relationships such as call_inferred, call_possible, and call_dynamic

Not every edge means the same thing. Structural edges such as include and define are different from call evidence edges.

Overloads and piracy-like styling​

DependencyAtlas also highlights overload-related semantics.

The important categories are:

  • none: no overload signal
  • safe: overload with project-type evidence
  • piracy_like: overload-like signal without project-type evidence

As a user-facing reading rule:

  • safe overloads usually mean "this extends behavior in a project-owned way"
  • piracy-like signals should make you slow down and inspect the definition more carefully

This is especially useful when project methods interact with Base, stdlib generics, or external package generics.

Why external nodes matter​

External nodes are not noise. They help answer questions like:

  • where does this project call into Base
  • which stdlib APIs are on the path
  • which external package symbols show up in the dependency story

Without them, the graph would often hide exactly the boundaries you want to inspect.

A good first reading workflow​

If a graph feels dense, use this order:

  1. start broad in file or module
  2. identify one region or node that matters
  3. switch to method
  4. inspect node details and source snippets
  5. only then worry about more ambiguous evidence kinds

That keeps the graph useful instead of overwhelming.