Build the Map

3 min read

Atlas builds a first draft from structure you already have: your test folder tree and your requirement hierarchy. It is a starting point to rearrange, not a finished map.

Run the First Sync

Open a project and select Atlas in the left navigation. The map is created on first open.
In the action rail, select Sync.
Wait for the sync to finish. The header shows it running; the page updates when it lands.

Sync reads two sources:

Test folders — how your test cases are filed
Requirements — what was asked for, including sub-requirements

Each folder and each requirement becomes a node, and its parent becomes the node’s parent. Nodes created this way are marked as derived, and the node keeps a link back to the folder or requirement it came from.

Choose What Sync Reads

Sync sources are per-map settings, not global configuration.

Source	Default	Notes
Test folders	On	The shape your tests are already organised in
Requirements	On	The shape the product was specified in
Include tasks	Off	Tasks share the requirement id-space, so they are available — but a task is a work item, not product structure

Re-syncing Keeps Your Edits

This is the part worth understanding before you invest in curating a map.

Sync is a merge, not a refresh. For each node it compares three things: what the source said at the last sync, what the source says now, and what you have changed since.

A field you edited is yours. Sync never overwrites it, no matter what the source says.
A field you did not touch follows the source. Rename a folder and the node’s title follows.
A node you moved stays where you put it, even if its folder sits elsewhere.

So you can rename a folder-derived node to something a person would recognise, drag it under a different area, and re-sync a month later without losing either change.

Nodes Whose Source Disappeared

When a folder or requirement behind a node is deleted, Atlas keeps the node and marks it as orphaned. The Sync rail action shows a count of them.

That is deliberate: the folder is gone, but the part of the product it described may not be. Orphans need a human decision — rename the node and keep it as manual structure, or delete it.

Deleted Nodes Stay Deleted

Deleting a node records it as deleted. A later sync will not bring it back, even if its folder or requirement still exists.

This is the right trade. The alternative — resurrecting on every sync — would mean a map you can never finish tidying.

AI Proposals Are Not a Sync Source

Sync reads folders and requirements only. Both are deterministic and free.

Canon-derived proposals are deliberately excluded, because the same corpus does not produce the same tree twice — one run proposed ten areas, the next proposed seven, grouped differently. Anything that variable must never be merged automatically, so it goes through a review step instead. See Propose a map from Canon.

Nodes you accept from a proposal are exempt from sync entirely. Sync will not touch them.

When to Re-sync

After adding or restructuring test folders
After a batch of new requirements lands
Before a release review, so coverage reflects current structure
After the orphan count on the Sync action changes

Sync is an Update permission, not a Create — it changes the map for everyone in the project.