Traversal / hop
Graphify glossary
Following edges from node to node — one hop is a single edge, a traversal is a path of them. How graphs answer multi-step questions.
A hop is following a single edge from one node to another; a traversal is a path of hops: endpoint → handler → service → table. Traversal is the fundamental operation of a graph — the thing you can do with typed edges that you can't do with a search index — and it's how a graph turns a multi-step question into a mechanical procedure instead of an act of imagination.
One hop is easy for any tool; grep can usually find the direct callers of a function. The separation happens past that. 'What breaks if this schema changes?' is three or four hops — table → queries → services → endpoints — and every hop multiplies the ways text search goes wrong: name collisions, re-exports, dynamic references, files that mention the term without touching it. Similarity search degrades the same way, because no chunk of text contains a relationship that spans four files. A graph just keeps following edges; hop three is exactly as reliable as hop one.
Traversals also come with a property no retrieval score offers: the answer is the path. When graphify path traces how two pieces of code connect, the output is a sequence of real nodes and real edges — each one a file you can open, each edge tagged with how it was established. You can check the reasoning by walking it. Try it directly with graphify path, or let your assistant run traversals through the MCP server; the query commands are covered in the docs.
Related terms
- Edge — A typed, directed relationship between two nodes — calls, imports, defines, references — each carrying a provenance tag.
- Blast radius — Everything transitively affected by a change — the callers of a function, their callers, and the configs and tests that reference them.
- Token reduction — The context-window savings from answering with graph structure instead of pasting whole files into an assistant's context.