Atlas Overview
3 min read
Atlas is a map of the application your project tests. Not a folder tree of where test cases are filed, and not a list of what was asked for — a model of what the product is made of and how a user moves through it.
Where Canon says what the product promises, Atlas shows what it is made of.
What a Map Gives You
Section titled “What a Map Gives You”A folder tree says how tests are filed. A requirement says what was asked for. An execution says what ran. None of them can answer the questions a release owner actually asks.
| Question | How Atlas answers it |
|---|---|
| We changed the payment service — what has to be retested? | Impact analysis walks what depends on what |
| Is sign-up actually covered end to end? | Journeys score an ordered walk, weakest link first |
| Which parts of the product have no tests reaching them? | Coverage rolls test results up the map |
| What does this product even consist of? | Sync and Canon proposals draft it for you |
One Map per Project
Section titled “One Map per Project”Each project has exactly one live map. It is created the first time you open Atlas in the left navigation — there is no “create a map” step.
Atlas is project-scoped only, unlike Canon. A map of “the application” is one product’s structure, and the requirements and folders a node points at only exist inside a project.
What a Map Is Made Of
Section titled “What a Map Is Made Of”Nodes are the parts of the product, arranged in a containment tree.
| Type | Meaning |
|---|---|
| Area | A top-level part of the product |
| Module | A grouping inside an area |
| Feature | Something a user can do |
| Screen | A page or view they do it on |
| Behaviour | One observable action or rule. Never has children |
| Integration | Another system this connects to |
| State | A condition the product can be in |
| Note | Context that is not part of the structure |
Area, Module, Feature and Screen form the spine — the stable structure. Behaviours are leaves, where detail lives and where phrasing changes most between syncs.
Each node can link to the requirements, test cases, folders and Canon documents it relates to. Those links are what make coverage and impact analysis possible.
Routes
Section titled “Routes”Routes are relationships that containment cannot express. There are two kinds:
- Navigation — a user moves from one screen to another. Label it with what they click.
- Dependency — the source depends on the target. Changing the target can break the source.
Direction matters most on dependency edges, because impact analysis walks them in reverse.
Journeys
Section titled “Journeys”A journey is an ordered walk through the map that accomplishes something real: a new customer lands, signs up, creates a project and adds their first test case. See Journeys.
Two Views Over One Model
Section titled “Two Views Over One Model”Atlas has a view switch in its header.
- Tree is the default. Containment is a tree and indentation already shows it, so the map is readable the instant it loads without anyone arranging anything.
- Canvas is for the work the tree cannot do — drawing and reading routes between things that are not related by containment.
Both views show the same nodes. Switching does not change the map.
The Action Rail
Section titled “The Action Rail”Page-level actions live in the rail at the right edge, grouped by intent.
| Group | Actions |
|---|---|
| Discover | Read Canon and propose a map, or find what the map is missing; review a pending proposal |
| Navigate | Open journeys; find and filter on the canvas |
| Analyze | Recompute coverage; show areas connected by a shared test case or defect |
| Data | Export as JSON; download the current view as a picture |
| Manage | Add a node; sync from folders and requirements |
Actions you lack permission for are simply absent. See Atlas best practices for how permissions are shaped.