An unfamiliar system offers too many places to start. The first useful map does not try to show everything; it identifies the inputs, trust boundaries, and behaviors that deserve a closer look.
Define the boundary.
Begin with the version and configuration being examined. List what can enter the system, what authority each input carries, and which operations matter if that input is mishandled. A boundary might be a parser, an authentication check, a plugin interface, or a file written with elevated privileges.
Keep observations separate from assumptions. “This endpoint accepts an archive” is observable; “the archive parser is unsafe” is a hypothesis. The distinction prevents an early guess from becoming a fact in the rest of the investigation.
“A useful map points to what can be checked next.”
Use AI for questions.
AI can summarize a large codebase, group related entry points, or suggest paths between an input and a sensitive operation. Ask it to name the files, functions, and assumptions behind each suggestion. A claim without a path back to source remains a lead.

Challenge the map with the simplest counterexample: a validation step, a permission check, a different call path, or a configuration that makes the suspected behavior unreachable. These checks often remove more noise than another round of broad prompting.
Trace a real path.
Pick one input and follow it through the program. Record where it is parsed, transformed, checked, and used. If the path crosses a process or privilege boundary, mark the transition explicitly. When static analysis cannot settle a question, design a small test that observes the relevant behavior.
The result should be a path another researcher can retrace, not a diagram whose arrows merely seem plausible.
Keep uncertainty visible.
Write down what the model suggested, what direct inspection confirmed, and what still needs a test. Note which files or paths were not examined. That record makes it possible to return to a promising lead without confusing a hypothesis with a verified weakness.
The first map is a working instrument. Its value is in helping the next observation change the map, rather than defending the first version of it.
