The graph, and how the mapping works.

The map is plain reading of your code. It draws the connections it can prove and says nothing about the ones it cannot.

One file with the files that import it
on the left and the files it reaches on the right. — **Lanes.** What imports this file on one side, what it reaches on the other. The view for "where does this sit".

The same file at the centre of rings,
with what it touches placed by strength of connection. — **Orbit.** The file at the centre, everything it touches on rings by how strongly. The view for "what is closest".

The whole repository drawn as
coloured regions of connected files. — **Islands.** Every folder in the repository at once, so you can see its shape before you know any of its names.

The map zoomed in so file
names are readable and one file’s links are highlighted. — **Neighbourhoods.** Closer in, files carry their names and one file's links light up across the whole picture.

What a scan actually does

It parses each file, finds the things in it — modules, classes, functions, imports, calls, database tables — and records which file reaches which. Every line on the map is one of those resolved connections.

Two rules keep it honest. An edge is said once, not once per row, so a file that imports another ten times is one connection with a count, not ten lines of noise. And a file with nothing pointing at it says so plainly rather than being quietly hidden — the map reports "nothing the scan can prove points here", which is a fact about your code worth seeing.

No model runs during any of this. It is reading, not inference.

Five ways to look at one file

Pick a file and the graph will draw it five ways. They show the same resolved connections arranged for different questions. Lanes and Orbit are in the pictures at the top of this page, drawn from the same file so they compare. The other three:

Fan

Follows one direction outward, for tracing where a change would travel.

Radial

Arranges by depth, for seeing how far the reach actually goes.

Table

The same connections as rows you can read and sort — the view that shows the map is data, not decoration.

The whole map

Beyond one file there is the whole repository at once. Folders become coloured regions; files become dots sized by how connected they are. Zoom in and it resolves — regions become neighbourhoods, neighbourhoods become named files.

How far each language is read

Not every language is read to the same depth, and the map does not pretend otherwise.

Read in full

Python, JavaScript, TypeScript, Java, JSP, Ruby, C, C++, Swift and Go. The scan reads the grammar and resolves imports, includes and calls between files.

Read at connection level

SQL and shell are read for what they connect to — the tables and the files they reach — rather than parsed as full grammars.

Frameworks it knows by name

FastAPI, Flask, Next.js and Express for your routes, and Supabase for your tables. Knowing the framework means the map can tell a route from an ordinary function.

When a language is not covered

The same map, with the languages the plain reader does not parse handled by your own assistant instead. Your subscription, your model, your machine. It opens the same way and stops the same way.

$ python -m ambitgraph mapllm "<the folder with your code>"