Intent Map

The "why" behind code disappears the moment the original author leaves. The Intent Map reconstructs what each file is for — and is explicit about which parts are computed from your repository and which are a model's reading of it.

How it works

Two layers, kept visibly apart. Most of the page is measured: derived deterministically from your code, with no model involved. A smaller part is inferred: a language model reads the file and states what it appears to be for.

Measured

Importance and blast radius — from the real import graph, citing the files that actually import this one.
Relationships — who imports it, what it imports, and what breaks if it is removed.
Entry points — the URL and methods a route answers on, read from the route map.
Step sequence — for entry points, the operations in the order the code performs them, read from the AST.
Lifecycle — active, zombie or dead, from the same findings the Dead Code and Zombie tabs report.
Operational facts — environment variables read, feature flags, and whether a test file covers the source.

Inferred

Purpose — a plain-English summary of what the file does.
Capability — the business capability it appears to implement, used to group files.
Actor, trigger, outcome and side effects.
Dependency rationales — why one file depends on another (opt-in, see Cost below).

NOTE

The model reads the file's contents and nothing else. The Intent Map does not read git history, commit messages or authorship — nothing in it can tell you who owns a file.

Live demo

Click any file to see how the two layers are presented. Note the third file: the model would not name a capability for one of these, and the page says so rather than inventing one.

mapnostics.com/repo/mapnostics-app/intent-map

Intent Map

8 capabilities · 312 of 312 files classified

● LIVE

FILES · 3

INFERRED · A MODEL'S READING

Raise and track support tickets

MEASURED · COMPUTED FROM THE REPO

· Critical — imported by 9 files

· POST /api/tickets

· Reads 2 environment variables

· A test file matches this source

1. Auth check2. Validate3. Write4. External call5. Respond

Understanding the output

Capabilities

Files are grouped by the capability the model named for them, with near-identical phrasings merged. Selecting one shows the ways into that capability — its routes and framework entry points — and filters the file list beneath it.

Evidence

Every file card carries a collapsed evidence block listing each claim and where it came from. Measured means derived from the repository; it does not mean verified, because Mapnostics never observes your code running. Corroborating facts make an inferred claim more plausible but never promote it to measured.

Intent smells

Mechanical signals that a file's purpose is unclear: a generic name, no tags, or no identifiable consumers. These are findings, not descriptions — a starting point for cleanup.

Cost & coverage

Generation makes one model call per file, so a large repository takes a while on the first run. Afterwards it is incremental: a file is only re-read when its content has actually changed, so re-generating an untouched repository costs nothing.

The Relationship Map — the AI explanation of why each dependency exists — is a separate, opt-in pass behind its own button, because it costs another call per source file. The dependency graph itself is always available without it.

TIP

If a run is interrupted or rate-limited, the tab says how many files still have no summary rather than reporting success. Click Re-generate and it picks up exactly the files it missed.

Tips & use cases

Start on the Overview tab to see the capabilities before inspecting individual files.
Open an entry point to read its step sequence — the fastest way to learn what a route actually does.
Cross-reference with Dead Code: a file marked Zombie whose capability nobody recognises is a strong deletion candidate.
Check the evidence block before acting on anything the model inferred.