GraphRAG is not a wiki with extra steps

GraphRAG is having a moment because teams discovered that dumping a repository into a context window does not produce understanding. The proposed fix is “put a graph in front of the model.” That only helps if the graph is made of evidenced relationships.

A wiki with embeddings is still a wiki. A hallucinated knowledge graph is worse: it is a wiki that looks like math.

Facts before inference

Helix’s order of operations is boring on purpose.

1. Reconstruct what merged: authors, reviewers, files, timestamps, mentions.
2. Encode patterns that the history will still admit: silos, coupling, expertise, DNA.
3. Retrieve from those nodes. Cite them.
4. Only then let language smooth the answer.

If step 1 is skipped, step 4 is fiction. GraphRAG demos that skip step 1 are search engines wearing a force-directed layout.

const hits = retrieveEvidence(engine, question, 8);
if (hits.length === 0) {
  return "The graph does not support a claim.";
}

Ask Helix will not invent an owner. The API will not either. That is the product.

What “RAG over a graph” should mean

It should mean the retriever walks AUTHORED, REVIEWED, MODIFIED, COUPLED, CONTAINS, OWNS, TOUCHED, MENTIONS. It should not mean “we extracted nouns from README.md and drew circles.”

The language model is a speaker. The graph is the memory. Mixing those jobs is how you get a confident paragraph about a service that was deleted in 2024.

Helix Review is GraphRAG with a verdict

The same retrieve-and-cite path writes a pull request comment: blast radius, silos, reviewers, ship / review / hold. The comment is structured so a human can disagree. The marker is hidden so Helix updates one thread instead of stacking sermons.

That is closer to how engineering actually decides than a chatbot in the sidebar.

If you want GraphRAG that starts from merge history instead of a wiki, open Helix and ask a question that used to take a Slack archaeology expedition.