Twelve questions, six knowledge graphs, and not one query written by hand

Stuart Broad has dismissed David Warner 20 times.

That is not a fact you can retrieve by embedding cricket commentary and searching for something similar. It is a count() over a typed edge. Ask a vector index and you get paragraphs about their rivalry — the number is nowhere, because the number was never written down anywhere. It only exists once you model dismissals as relationships and count them.

I have been trying to work out where that line falls: which questions want a vector index, and which want a graph. The most direct way to find out was to give a model six knowledge graphs and ask it things.

The setup

Six MCP servers, each in front of a different graph: bank model risk, cricket, drug interactions, football, Indian Supreme Court judgments, and biological pathways. Claude Code on the other end.

Before asking anything, I fixed the rules so I could not quietly help it along:

You are running a live, recorded demo with 6 MCP servers connected.
RULES for every question I ask next:

- Call exactly ONE MCP tool on the matching server, then stop.
- Answer in ONE short line per row, top 3 only.
- No preamble, no "let me...", no explanation, no follow-up offers. Just the result.
- Never restart or reconfigure anything. Never ask me to confirm.
Reply "Ready." and nothing else.

One tool call per question. No retries, no second attempts, no picking a better phrasing after seeing a bad answer. Whatever came back is what is in the video.

I never write a query. Claude picks the server, writes the Cypher, and the engine answers.

What came back

Bank model risk — "what feeds the CCAR stress test?"

Credit Scorecard · Unsecured Personal #00 (Model) → CCAR PPNR · CRE #15
Credit Scorecard · Unsecured Personal #00 (Model) → CCAR PPNR · CRE #27
CCAR PPNR · Project Finance #01 (Model) → CCAR 2026

This is lineage — a path through models, not a lookup. The interesting part is the shape of the answer: which upstream models reach a regulatory submission, and by which route. There is no document that states this. It is a traversal.

Pharmacology — "heaviest side-effect burden"

Pregabalin — 839 side effects
Aripiprazole — 827
Citalopram — 823

Biology — "most connected protein hubs"

TP53 — 739 partners
RPS27A — 717
EGFR — 502

Degree centrality, in other words. TP53 coming top is exactly what anyone in the field would expect, which is the point — it is a sanity check that the graph is loaded correctly and the question was understood.

Indian Supreme Court — "most productive judges"

Dipak Misra — 104 cases
T. S. Thakur — 81
Rohinton F. Nariman — 74

Six domains, one session, one tool call each. The model switches between banking and cricket and pharmacology mid-conversation without being told which server to use — it picks from the tool descriptions.

The part that is actually interesting

Every one of these is a counting or path question over typed relationships. Not one of them is a similarity question.

That is the split I have landed on, and it is less about which technology is better than about what shape the question has:

• "What is this like?" — a vector index. Fuzzy, semantic, tolerant of phrasing.
• "How many, via what route, ranked by what?" — a graph. Exact, structural, and gives the same answer twice.

RAG systems overwhelmingly do the first, then struggle when a user asks the second — because "who has dismissed Warner most" retrieves match reports, and the model counts them badly.

The honest caveat: there is no vector search anywhere in this video. Samyama Graph has HNSW vector search in the same engine, and none of these twelve questions use it. It is all traversal. The genuinely interesting case is the hybrid — retrieve by embedding, then expand the graph around the hits, or traverse first and embed the neighbourhood — and I have only tried the second.

Two things I would not put in a launch post

A cold query is slow. In the standalone cricket case study, the first traversal takes 3.1 seconds and the second takes 0.68. Same shape of query, same data. That is a cold cache, and it is the first number anyone will see.

One answer is a data-modelling trap. Asked for World Cup titles, the football graph returns Brazil 5, United States 4, Italy 4. If you know football you have already spotted it — that is men's and women's competitions counted together. The engine answered exactly what was asked; the graph does not distinguish the two tournaments. Which is a decent illustration of the real failure mode of this whole approach: the model will faithfully answer a question your schema quietly misunderstood, and it will sound completely confident doing it.

Reproducing it

All eleven case studies are built from public datasets and run end to end — cricket from Cricsheet (CC BY 4.0), drug interactions, pathways, football, legal judgments, and the rest:

https://github.com/samyama-ai/samyama-graph/tree/main/case_studies

The cricket graph is 36,619 nodes and 1,392,017 edges, which is small enough to load on a laptop and large enough that the traversals are not trivial.

Disclosure

I work on Samyama Graph — an open-source graph-vector database written in Rust, with OpenCypher queries and HNSW vector search in one engine, 14 graph algorithms, Apache-2.0. So I am not a neutral party on the engine.

I am much less certain about the retrieval question, and that is the bit I would like to argue about: for hybrid graph-plus-vector retrieval feeding an LLM, is it better to traverse first and embed the neighbourhood, or retrieve by embedding and expand the graph around the hits?

I have only tried the first. If you have tried the second, I would like to hear how it went.

https://github.com/samyama-ai/samyama-graph/tree/main/case_studies