Atlas answers it as a ranked retest list, and every test case on it says why it's there. It can, because it keeps a model of what your product is made of — areas, screens, behaviours, what depends on what. Your folder tree only knows where tests are filed.
Seed it from what changed — a part of the map, a requirement, a test case, a spec, a defect, or a whole release. Atlas walks the dependencies backwards, from the thing you changed to the things that need it, and sorts what it finds into three tiers.
A diagram, not a screenshot. The point is the glyph on every row: two tests can both be must retest for entirely different reasons, and the list is only checkable if it says which.
The retest list above is the point. These are what let the map produce it — and what stop it going stale the week after you build it.
A five-step journey with four green steps and no test on checkout is not 80% covered — nobody completes 80% of a purchase. Atlas reports the weakest step, not the reassuring average, because that is the only honest answer for an end-to-end path.
Rename a node, drag it somewhere sensible, sync again next month — your edits survive. Sync compares what the source said last time, what it says now, and what you changed, and your change always wins. Delete something and it stays deleted.
Everyone in the project sees the same map, so an impact answer is something two people can argue about with the same picture in front of them. Reading is open to every role; reshaping it is not.
Nobody wants to draw a product map from scratch, so you don't. Two of the three steps are a button.
Reads your test folder tree and requirement hierarchy — structure your team already wrote down. Free, repeatable, and the same every time. Tasks are left out by default, because a map full of “write the migration script” describes your backlog, not your product.
Reads every document in Canon by heading and proposes the areas, screens and routes your folders never named. It is a draft you review node by node — nothing is accepted by default, and each suggestion shows the passage it came from.
Rename things a person would recognise, regroup, draw the dependency routes that actually exist, and name the journeys whose failure would stop a release. This is the part that is yours — and it survives every later sync.
Routes come in two kinds and that is also on purpose: navigation (a user moves from here to there) and dependency (changing the target can break the source). Impact analysis walks the second kind in reverse, which is why there are only two.
Most coverage views colour everything empty in red, so the real gaps drown. A heading you drew is supposed to be empty. Something specified, filed, and reached by no test is not.
Health comes from the same rule the traceability matrix uses, so the map and the report can't tell you two different stories about the same requirement. Narrow the whole map to one execution and it answers “how did this run do?” instead of “what has ever passed?”
Each of these could have gone the other way and produced something that looks more impressive and is less true.
A proposal is a reviewable draft. Nothing is accepted by default, a title already on your map defaults to merge rather than add, and nodes the model grouped itself instead of reading are flagged for a harder look.
There is no data to calibrate a weighted risk number against, and a number nobody can predict is worse than a bucket they can. Must retest, Should retest, Consider — and the rule behind each is written down.
“Nothing depends on this” and “the map doesn't know about this yet” are different answers. Atlas distinguishes them, because a blank list that means the second one is the most expensive kind of wrong.
The requirement-to-test and defect-to-entity links already live in your repository. Atlas draws them live rather than keeping a copy, so editing a test case can never make the map quietly lie.
Atlas is built from your folders, your requirements, your specs and your hand. There is no repository scan and no traffic capture — which is why the map says what your team believes the product is, and disagreements show up as gaps.
It never is. Somebody opens Atlas, points at the auth node, and gets twenty-eight test cases back — seven of them must retest, three of those on the critical sign-up journey, one of them never run at all. The estimate changes in the meeting rather than on the Thursday before release, and the list goes straight into the run because every row already says why it's there.
Atlas shows what your product is made of. Canon holds what it promises — and hands a node's context to the generator so a run knows both where a feature sits and what it is supposed to do.
Every feature is free while Hawzu is in early access — no credit card required.