Find your way around the AtlasArc workspace

The AtlasArc tool window puts a lot on one screen: native IntelliJ command rows, a lens switcher, lens-local controls, the canvas, a left sidebar of navigation and filters, a right sidebar of evidence, and a status strip along the bottom. This page is a map of that screen. It names each region and links to the reference that explains it, so you can point at anything in the window and find out what it does.

The screenshots below show the Topology Graph, which is the view you land on after your first analysis. Shared product commands stay in IntelliJ's native command surface. Switching lenses changes what the canvas draws and replaces only the renderer-dependent controls inside AtlasArc; the surrounding workspace remains familiar.

The main window, region by region

Each number below points at a region of the tool window in the screenshot. The list is deliberately coarse: it maps the zones you navigate between, not every individual button. Follow the link on a region to read the page that covers it in full.

Screenshot: the AtlasArc tool window on the Topology Graph, with numbered callouts on each region
  1. Analysis row holds Analysis Source, the JVM-only Include tests qualifier, Analyze, and the last-analysis status. Start here with Getting started; the scope comparison below separates Analysis Source from Current Focus and repository Analysis Scope.
  2. Product command row uses native IntelliJ actions for Workflows, Architecture Health, Cycle Governance, Reset View, Auto-Hide Sidebars, Download, Settings, and Help. Settings owns analysis and presentation defaults that survive IDE restarts and applies them through reanalysis or rerendering as needed.
  3. Lens switcher swaps the canvas between the five lenses: Topology, Matrix, Subsystems, Hotspots, and Composition. Each one answers a different question about the same model. Compare them on the lenses overview.
  4. Lens-local controls sit with the active renderer. Zoom, fit, layout, capture, and posture-specific controls appear only where they have meaning, and active narrowing modes keep a visible way out.
  5. Left sidebar is the Navigation panel: View, Filters, Cycles, Exclusions, Safe Havens, Metric Thresholds, and Legend as an accordion, plus a Workflows button. Its own close-up is below.
  6. Canvas renders the active lens. On the Topology Graph it draws packages as nodes and dependencies as directed edges. Drag to pan, use the wheel or lens controls to zoom, and use Fit to restore the useful frame. See Topology Graph for how to read it and Right-click navigation for the actions that change structural posture.
  7. Graph stats bar reports the graph-level metrics for the whole model: NCCD, RACD, ARV, and GRV. Each value carries an info icon that explains it and when it becomes reliable. The metrics reference defines them.
  8. Cycles section is the standing cycle-review surface. It exposes detected groups, visual emphasis, cycles-only narrowing, and group navigation. The cycle-control comparison below separates their effects; the Audit individual cycle groups workflow puts them to work.
  9. Heatmap bar appears when you turn on the heatmap. It holds the metric dropdown, the gradient legend, and a Package or Subsystem choice: Package colours each unit by its own value; Subsystem colours a folder by its subtree rollup. The Heatmap overlay page goes deeper.
  10. Right sidebar shows the detail for whatever you select, split into a Node or Edge tab and a Metrics tab. Its own close-up is below.
  11. Status bar and Status Cluster run along the bottom with visible node and edge counts, the build tag, and indicator lamps for evidence, structural posture, scope, and narrowing. The close-up below explains how to read it.

When similar controls do different jobs

Most controls can be learned by using them. These are worth separating because they operate at different layers, cross lenses, or outlive the view currently on screen.

Evidence, focus, and repository scope

Control The question it answers What changes
Analysis Source Which built evidence should AtlasArc analyze? The next Analyze run acquires that source and replaces the loaded model. It does not commit repository policy.
Current Focus / Set as Root Where should every lens open on the model already loaded? All lenses start at that boundary, while the in-scope evidence and whole-model metrics remain unchanged.
Repository Analysis Scope What code should count everywhere? Committed rules remove evidence before metrics, cycle findings, whole-model reports, and CI evaluation.

Right-click navigation changes structural posture

Right-click a package or source-folder unit to open its architecture menu. Set as Root makes that unit the Current Focus for every lens. Pin subject · Graph or Pin subject · Matrix keeps it as the question while showing its surrounding relationships in the named rendering. Open Cycle Group View holds the detected group as the structural subject until you explicitly exit. The menu shows only actions that make sense for the selected kind of unit; it is not identical for packages, modules, classes, and files.

Screenshot: an architecture-unit context menu open on a package, showing Set as Root, Pin subject · Graph, Pin subject · Matrix, and Open Cycle Group View

Cycle controls layer rather than replace one another

Cycle findings and the group roster exist before Show cycles only is enabled. In Topology and Matrix, group checkboxes mute or restore visual emphasis without changing findings. Show cycles only removes unrelated structure; its previous and next controls browse one group temporarily. Open Cycle Group View is the stronger structural action: it keeps that group as the subject across Topology and Matrix until you exit. None of these actions accepts or suppresses a cycle; durable decisions remain in Cycle Governance.

Current investigation versus durable state

Reset View returns the current investigation to a known starting point and reruns analysis. It clears Current Focus and active narrowing, restores the active lens defaults, and turns off view-only exclusions without deleting their stored entries. It does not erase Safe Havens, repository governance, repository Analysis Scope, or Shared Views.

Settings owns durable analysis and presentation defaults and applies a change through reanalysis or rerendering as required. Controls used while investigating stay beside the view they affect; some, such as Metric Thresholds and sidebar preferences, retain their own saved state rather than moving into the Settings dialog.

The Status Cluster shows cause and effect

The lamps answer two questions at a glance: what evidence the view rests on, and what is currently shaping or limiting it. Hover a lamp for the exact state; most lamps also jump to the related control, while Build is deliberately informational. Read Filters and Pruned together: Filters shows how many minor filters are engaged, while Pruned shows how much structure they actually hide. The cluster is orientation and a set of shortcuts; the toolbar and sidebar controls remain the source of truth.

The left sidebar up close

The left sidebar is the Navigation panel. It mirrors the right sidebar: pin it to keep it open on a canvas click, or collapse it to a strip. It holds persistent view controls as an accordion, so opening one section closes the others. Commands that need one of these controls, such as opening the Legend, bring you to the matching section rather than creating a second copy of the state.

Screenshot: the left Navigation sidebar with a section expanded, and numbered callouts on each section
  1. View reshapes the hierarchy without changing the model, through deep-package rollup and single-child folder contraction. The reasoning behind both is in Handling large projects.
  2. Filters is the section that opens by default. It carries the reference-count and fan-in and fan-out ranges and Hide isolated, so you can narrow the graph to the packages that have a reason to be on screen.
  3. Cycles holds the detected-group roster, emphasis toggles, cycles-only detail levels, and group navigator described in the cycle-control comparison. The Audit individual cycle groups workflow works from here.
  4. Exclusions starts in View only: package patterns and Hide ... from view context actions reduce visual noise while metrics and cycle findings still use the complete in-scope analysis. Switch to Analysis scope to inspect durable policy impact and open the Governance hub for reasoned rules that the IDE, reports, and CI all apply before metrics and cycles.
  5. Safe Havens lists every package or source folder AtlasArc remembers as broad cycle suppression in this workspace, each with a control to revoke it. Use precise Intentional/Debt governance when you need a reasoned decision on narrower evidence.
  6. Metric Thresholds sets the full-red ceiling for each unbounded metric, calibrating colour in every heatmap and bubble chart. Thresholds do not create violations, governance policy, or CI gates. The metrics reference covers what each one means.
  7. Legend explains the node, border, and edge language. It appears for the structural lenses, the graph and the matrix, and is hidden where there is no node colour to explain.
  8. Workflows is a button rather than a section. It opens the workflow wizard, which sets a lens and its filters for a chosen investigation.

The right sidebar up close

The right sidebar is where a selection becomes evidence. It is shared across every lens, so the tabs and their contents work the same way whether you selected a node on the graph, a cell in the matrix, or a bubble in Hotspots. Collapse it to a strip when the canvas needs the room, or pin it to keep the selected evidence visible while you explore elsewhere. Select a package to fill the Node tab; select a folder and the Metrics tab adds a subsystem section.

Screenshot: the right sidebar Metrics tab for a selected subsystem, with numbered callouts including the Boundary Flow glyph
  1. Node / Edge tab shows the selected package's name, size, fan-in and fan-out, dependency lists, cycle warning, and Safe Haven toggle. When an edge is selected it shows the reference examples behind that dependency, each one clickable to the exact source line.
  2. Metrics tab shows the architecture metrics for the selection: instability, abstractness, distance, and relative visibility. Click a value to open a drill-down that explains what the reading means and exposes the contributing evidence available for that metric—such as coupled units and edge references, formula operands, contributing classes or methods, packages, or edge sets. For a folder the tab also adds a Subsystem section with the rolled-up health of the whole subtree.
  3. Boundary Flow glyph appears in the Metrics tab for a selected subsystem. It is a compact wheel of the subsystem's strongest boundary neighbours, sized by combined inbound and outbound traffic. Its balance signal distinguishes inbound- from outbound-dominant exchange, and hover shows both directional counts. Open Boundary Matrix is the primary route to the exact pinned-boundary evidence; when the wheel is too dense to summarize, it directs you there instead of guessing.
  4. Confidence signals mark where a metric could be read the wrong way. Drill-down panels carry a "Keep in mind" note for when a metric misleads, and small packages show a low-confidence badge where a ratio metric would otherwise look alarming. The metrics reference explains the caveats.

Where to go next

Now that the window has names, put it to work. Run your first analysis with Getting started, learn what each lens is for on the lenses overview, or follow a guided investigation from the workflow library. When a project is too big to read at once, Handling large projects covers the reductions that make it small enough to reason about.