How to Read the Navigation Map

After a run, you can see exactly how much of your app Manta reached — and where it stopped — in one view. The navigation map is that view: a graph of the pages Manta discovered and the paths between them. This guide is about reading it well enough to turn it into a to-do list.

What the map is

Every run produces a map. Nodes are pages or distinct states your app can be in — the dashboard, a settings tab, a specific step of a checkout flow. Edges are transitions — a click, a form submit, a redirect that took Manta from one node to another. Taken together it's a behavioral picture of your app as Manta actually experienced it on this run, not a sitemap you maintained by hand.

[Screenshot: a full navigation map for a small app, nodes and edges labeled]

Step 1 — Find the shape you expected

Start by looking for the flows you know should be there. Signup, login, the main object your app is built around (a project, a document, an order), settings, billing. Trace them on the map.

If a flow is present and connected, Manta exercised it.
If a flow you care about is missing, that's the first thing to note. Either Manta couldn't get to it, or it needs a nudge — see Step 3.

Step 2 — Look at the edges of the graph

The interesting information is usually at the boundary — the nodes with few connections, out at the rim.

Dead ends — a page Manta reached but couldn't leave. Sometimes that's correct (a terminal confirmation screen). Sometimes it means the only way forward was a control Manta didn't recognize as clickable, which is worth checking manually.
Thin branches — a whole section of the app hanging off a single edge. If that one transition breaks in a future release, everything past it drops out of coverage. These are good candidates to pin down with an explicit test.
Clusters with no path in — states that exist but that Manta only reached by luck. Ask how a real user gets there.

[Screenshot: the same map with a dead-end node and a thin branch highlighted]

Step 3 — Turn gaps into coverage

For each gap that matters:

Behind authentication or a specific role? Make sure the run used credentials for an account that can actually see that area. An admin-only section won't appear on a map built from a regular user's session.
Behind a step Manta didn't complete — a payment form, a multi-field wizard, a confirmation dialog? Describe the flow in plain English and let Manta run it directly. That's covered in How to Generate a Test Suite from a Plain-English Prompt.
Genuinely unreachable? That's a finding in itself — a page users can't navigate to is usually a bug or dead code.

Step 4 — Compare maps across runs

The map is most useful over time. Run Manta again after a release and compare:

Nodes that disappeared — a flow that used to be reachable and now isn't. That's a regression in navigation, even if nothing throws an error.
New nodes — either a feature you shipped (good, it got picked up) or a state you didn't intend to expose.
Edges that moved — a flow that now takes a different path through the app.

Common mistakes

Treating the map as a sitemap. It's a record of one run. A page missing from the map isn't necessarily missing from your app — it might just have been out of reach this time.
Chasing 100% of the nodes. Some states aren't worth covering. Use the map to make that call deliberately, not to feel bad about the rim.
Ignoring it after the first run. The single-run map is a snapshot; the value compounds when you diff it release over release.

What to try next

How to Generate a Test Suite from a Plain-English Prompt — lock down the flows the map says matter most.
The Testing Pyramid, and Where It Breaks Down — where broad, unscripted coverage fits alongside unit and integration tests.

Want a map of your own app? Start a free run.