Features
Switch between 5 lenses to answer any question.
You arrived with something to get done. This page expands the product overview into the specific features that do the work, all built on one shared package model, so filters, focus, and navigation carry across every lens. Start wherever your question is.
Free runs from Topology through committed cycle decisions, CI, and a one-page HTML summary. The full workspace carries that model into the lenses, metrics, and reports below. Follow the free route →
Choose the architecture question you need to answer
Each row maps a question you came to ask onto the lenses that answer it. Jump straight to the one you need.
- 01 Understand how the codebase is put togetherSee the structure you have, not the one you assume. → Explore the structure
- 02 Find cycles, boundary leaks, and misplaced packagesWork the problem graph one cluster at a time. → Diagnose structural problems
- 03 Find complex code that the tests don't coverComplexity and branch coverage in one view. → Expose complex, undertested code
- 04 Decide where refactoring effort pays offInstability, complexity, and the zone of pain. → Prioritize refactoring work
- 05 Govern exceptions and stop new cycles in CICommit one AtlasArc governance file; evaluate the same evidence in the IDE and build. → Govern intentional exceptions
- 06 Audit architecture findings and report them to the teamArchitecture Reports, HTML, Printable Version. → Review and report
Explore the structure
The Topology Graph shows package dependencies as a directed graph. The Package Matrix shows them as a cell grid, making coupling patterns and off-diagonal dependencies immediately visible. The Composition view maps where the code mass sits as a treemap, sunburst, or circle pack. Structural lenses expand package hierarchy in place; the Graph can also open one visible package/source folder into contained classes or files when you need local implementation evidence. Re-scope every lens by setting any package as the architectural root. On a large project, the same controls reduce a model that is too big to read. See handling large projects.
- Topology Graph with inline package expansion
- Graph-only package internals for local class/file tangles
- Package Matrix with TSV export
- Composition treemap, sunburst, and circle pack by code mass
- Heatmap overlay for any metric on structure-preserving lenses
Relevant lenses
Diagnose structural problems
Cycles are the headline, but not the whole story. AtlasArc separates the structural dependency graph from the cycle problem graph: accepted exceptions remain structurally visible but leave problem detection entirely, so the distinction between real design problems and governed exceptions is always explicit. The Cycles section filters the Topology Graph to packages in the problem graph, grouped by cluster, and the same model surfaces boundary erosion, leaked internals, package-local implementation tangles, and packages sitting in the wrong layer for the way they actually depend.
- Cycle detection and group navigation with the cycle-group navigator
- Structural graph vs problem graph: accepted edges remain visible, not deleted
- Spot boundary erosion and leaked internals in the Package Matrix
- Contained Topology internals for the class/file evidence inside one suspicious package
- Navigate from any cycle participant or boundary breach directly to the class
Relevant metrics
Relevant lenses
Workflows
Expose complex, undertested code
Structure is only half of maintainability. AtlasArc reads cyclomatic and cognitive complexity down to the method, and overlays branch and line coverage from the reports your tests already produce. The CC vs Coverage Hotspots Map shows the packages that are both complex and thinly tested. Switch to Galaxy to keep that reading, add Fan-in as depth, and reveal dependency routes between nearby candidates.
- Cyclomatic and cognitive complexity at package, class, and method level
- Branch and line coverage loaded from JaCoCo or LCOV reports
- CC vs Coverage Map, with a Galaxy continuation for architectural reach and dependency routes
Relevant metrics
Relevant lenses
Workflows
Prioritize refactoring work
Hotspots Map shows which packages stand out. Galaxy adds a fifth metric signal and reveals which nearby candidates actually depend on one another. Its trade routes show whether a hotspot stands alone or travels with company. Subsystems maps the package boundaries currently visible through shared expansion, keeping terminal units and dashed-ring aggregate parents so pressure can be read at coarse and fine scales.
- Hotspots: Map and Galaxy renderers with customizable metrics and package dependency Routes
- Subsystems: boundary risk, complexity load, and visibility surface presets
- Zone of pain, zone of uselessness, and backbone presets
- Expand packages in Topology or Matrix to carry the same coarse-to-fine boundary map into Subsystems
Relevant lenses
Workflows
One model, every metric
Thirty-plus metrics from one analysis.
Fan-in and fan-out, instability and abstractness, cyclomatic and cognitive complexity, line and branch coverage, size, and more. They are all connected in the same architecture model. Explore the evidence from project overview to class detail.
Explore the metric matrix →Govern intentional exceptions
Not every cycle is a design problem. Some dependencies are intentional, some are tracked debt, and some broad cycle regions simply obscure the question you are investigating. AtlasArc provides two controls without hiding structural reality.
Safe Havens remember a broad package or source-folder suppression in your workspace, keeping familiar cycle noise out of the way. Repository governance records give you finer control over supported dependency evidence: Intentional or Debt, with a required reason, optional ticket, searchable register, evaluation status, and repair lifecycle in .atlasarc/governance/cycles.json.
Those records are useful locally. Commit the governance file when you also want the decisions versioned with the code, reviewed by other developers, and enforceable in CI. Explicit acceptance and repair actions write the AtlasArc governance file directly under revision guards; AtlasArc never edits application source or build files. The matching evaluator uses the same schema, evidence matcher, debt precedence, and problem-graph classifier as the IDE for Java, Kotlin, and TypeScript.
- Safe Havens: remembered workspace decluttering with broad package or source-folder reach
- Governance records: precise, searchable Intentional or Debt decisions
- Commit the governance file to share, version, and enforce those decisions in CI
- Fully governed references leave the problem graph but stay structurally visible
- One headless evaluator for JVM bytecode and TypeScript artifacts, with IDE/CI parity
Review and report
When the investigation is done, you need something the team can actually use. AtlasArc generates Architecture Reports: browsable HTML with a Printable Version for PDF, covering project health reviews, subsystem audits, module-boundary reviews, cycle triage, and current-investigation handoff. Right-click any package to set it as the architectural root, inspect its neighbourhood or boundary in Graph and Matrix, or navigate straight to the class in the editor. Export raw lens files when you need them, or generate one report that reads from overview into selected evidence.
- Architecture Reports for project health, subsystem, boundary, cycle, and current-investigation reviews
- Browsable HTML plus a Printable Version for PDF or meeting packets
- Set as Root, Neighbourhood or Boundary subject reads, and direct IDE navigation from any node
- PNG snapshots for every lens, plus CSV, TSV, and DOT exports
- Global overview, Subject Audit, Current Investigation, and focused evidence sections in one report
- Generates quietly without changing the lens you are working in
Relevant lenses
Workflows
Get started
Install AtlasArc free
The graph, cycle decisions, CI gate, and one-page summary do not expire. Try the full workspace for 30 days when you want the complete instrument set.