A vector search is good at "what looks like this" and blind to "how are these two connected". The knowledge graph is the other half. It stores the corpus as entities and relationships, an Entity{name, type} table joined by a REL{predicate} table, in an embedded KuzuDB with Cypher and, like the vector store, no Docker. A pure-Python in-memory backend stands in for the keyless and test paths behind the same interface.
Retrieval is a traversal, not a similarity score. The query matches the entities the question names against the nodes actually in the graph, then asks the structural question: with two or more entities it returns the shortest paths between them, with one it returns that node's immediate neighbourhood, and with none, or no path inside the hop bound, it returns nothing and the caller abstains. Traversal is undirected and capped at three hops, so two projects that share a technology are found through it while a cyclic relationship cannot run away.
The frame that matters is what a path is worth. A traversed path is a hard structural fact, not a guess about proximity, so it enters the evidence set with a score of 1.0 and the path itself is what gets cited. The graph does not estimate that two things are related; it shows the route by which they are.