Updated 7 October 2026. This page previously said graph could earn its way back onto the hot path by winning an entity-dense benchmark. That is not the gate. LongMemEval cannot prove whether graph helps, and another synthetic slice cannot either. Graph retrieval stays off until a real pilot shows it helps a task that project actually has.
If a graph layer is going to stay on your retrieval path, it should stay because it clearly earns its place.
Not because it sounds sophisticated.
Not because your architecture deck looks stronger with more boxes.
And not because you want pricing to justify infrastructure that the product does not actually need on the hot path.
That is the shift visible in Accord Book's current retrieval docs.
Accord Book's default retrieval path is vector + lexical + supersedes-aware reranking, while graph is positioned as a derived intelligence layer for provenance, change impact, and related project reasoning.
What changed
Earlier framing treated graph as an enrichment lane inside retrieval. The current graph-positioning document resets that story directly.
The finding on the runs we have is consistent: across every evaluation variant since April 2026, graph channels contributed zero retrievals to the final answer set.
That measurement is real, and it is the wrong instrument for a stronger conclusion. LongMemEval is long-context recall. It does not contain the relational structure a graph would be for. Zero there does not prove graph is useless on agency work. It also does not earn graph a place on the default retrieval path. We are not going to keep a hot-path dependency that this benchmark cannot justify, and we are not going to treat the next synthetic fixture as the proof either.
The production-default stance now
The retrieval implementation reference says the production hybrid retrieval surface runs:
- vector retrieval
- lexical retrieval
- supersedes-aware reranking
And it says graph retrieval lanes are:
- deprecated as a production path,
- gated behind
GRAPH_RETRIEVAL_LANES_ENABLED, - and disabled by default.
That is a healthy architectural correction. It narrows the public story to the path the implementation docs actually describe as default behavior.
Why this narrower default is better
1. It is easier to explain honestly
A buyer or engineer can understand "we combine semantic retrieval, lexical recovery, and freshness-aware reranking" much faster than a story that tries to make graph the hero before graph is clearly contributing on the main benchmark lane.
2. It is easier to operate
Every always-on production dependency needs to justify its cost in reliability, debugging, and cognitive overhead. A narrower default path reduces that burden.
3. It is easier to validate
If the default path is simpler, it becomes easier to reason about what actually improved retrieval quality and what is still hypothetical.
What graph still does well
This is the important nuance. The current repo does not say graph should disappear entirely.
The current graph-positioning doc reframes graph as the project intelligence layer for questions like:
- change impact,
- ownership,
- decision provenance,
- scope and supersession chains,
- entity disambiguation,
- related tooling that depends on multi-hop structure.
That is a stronger and more defensible role than pretending graph must be on the default memory-recall path at all times.
Default retrieval vs derived intelligence
| Surface | Best current public framing | Why |
|---|---|---|
| Default retrieval | Vector + lexical + supersedes-aware rerank | This is what the implementation docs describe as the production default |
| Neo4j | Derived intelligence layer | Better fit for provenance, change impact, and structured traversal |
| Conflict detection | Separate Postgres-first path | Graph is not on the conflict path |
| Docs generation | Git-backed publication workflow | Different trust problem entirely |
The real benchmark question
The old question was too pricing-heavy: "Can vector-only be cheap enough to sell?"
The better question is now:
On which product tasks does graph materially improve the result enough to justify being on the hot path?
That is a much more useful standard, because it is tied to product truth rather than architecture aesthetics.
Graph stays off the default retrieval lane until a real pilot shows it materially improves a task that project actually has: change impact, provenance, or a recall miss the vector and lexical path got wrong. A benchmark, including an entity-dense one, can be a diagnostic. It cannot by itself turn the lanes back on.
Closing thought
A graph database does not justify itself by existing in the architecture.
It justifies itself when it wins on a real product task.
Right now, Accord Book's current docs support a narrower and more credible claim: graph still matters, but not as the default retrieval lane.
For the broader retrieval architecture story, read Why Production Retrieval Needs More Than Vector Search. For the benchmark results, read Accord Book Retrieval Benchmarks: What the April 2026 Run Showed.