The First Test of the Model: Can You Trust a Graph Answer?

Code-Graph-RAG becomes genuinely useful when a graph result can support a bounded judgment, not merely produce a plausible list of names. The structural model, site-aware relationships, resolution labels, and flow coverage described so far can be combined into a practical audit. The question is simple: when the system answers a repository question, what exactly has been established, how was it established, and what still needs to be checked in the source?

Start with the claim, not the graph

Suppose a maintainer asks, “Which parts of the application call the authentication service, and could a value from an environment variable reach its output?” That sentence contains at least two claims. The first is about call relationships and their sites. The second is about value provenance from a source to a sink. They may involve the same area of code, but they are not the same query and should not be judged by the same evidence.

The first step is to make the intended conclusion more precise. “Which parts call the service?” asks for callers, call sites, and perhaps the way each call was resolved. “Could a value reach its output?” asks for a modeled source, a modeled sink, and a FLOWS_TO path. If the reader instead asks only for functions whose names contain “auth,” the answer may be useful for discovery but cannot establish either relationship. A graph does not remove the need to define the claim; it makes it possible to ask for the objects that could support it.

The route from question to judgment has several distinct stages:

sequenceDiagram participant R as Reader participant Q as Retrieval interface participant G as Graph participant S as Source and coverage R->>Q: Ask a structural or provenance question Q->>G: Run a fixed or generated graph query G-->>Q: Return candidate rows with provenance Q->>S: Check relationship, source, and coverage S-->>Q: Confirm, qualify, or expose a gap Q-->>R: Return a calibrated answer

A deterministic tool may answer the caller portion with fixed graph queries. An open-ended agent may generate Cypher from the question. Either route returns graph candidates, not an automatic warrant for every sentence that could be written about them. The relationship type is the first check. A module that imports an authentication module is not necessarily a function that calls its service. A function that references a callback is not necessarily the function that invokes it. A definition edge shows ownership, not execution.

The site is the second check. If several call sites appear, the reader can inspect their recorded lines and columns rather than treating a pair of qualified names as one undifferentiated fact. Argument count and keyword names can reveal whether the call matches the scenario being investigated. An import alias can explain why the source uses a local name different from the definition. These details do not make a relationship more important; they make its meaning inspectable.

Resolution is the third check. An exact binding supports a narrower conclusion than a heuristic match. An overload result may point to multiple possible definitions.