Grounding AI: Reasoning Layers and Factual Graphs

Part 1 — the work: rules that keep an LLM honest. Getting an LLM to emit valid, consistent RDF isn't a one-shot prompt, it's a feedback loop. The pipeline validates every extraction against SHACL shapes (a source-layer shape for the raw extraction, an inference-layer shape for completeness after reasoning), checks that every asserted URL actually resolves, and feeds failures back to the model for correction. Once data is accepted, a library of SPARQL CONSTRUCT rules — one file per inference, from schema.org typing to composer nationality to "performs-with" relationships — runs to a fixpoint over the whole assertions store, materialising everything the raw extraction implies but never states outright. The result is a hard boundary between asserted fact and derived fact, with the derived layer fully disposable and reproducible.

Part 2 — the idea: ontologies as the contract for MCP tools, not just the data. Most MCP tool servers are hand-written: someone decides "there should be a search_performances tool" and hard-codes its arguments, return shape, and the query behind it. The idea this talk puts forward is that when a domain already has an ontology and SHACL shapes describing what's true and how it's structured, that same artefact should be doing double duty — defining the tool's contract as well as the data's shape. A tool's inputs mirror the ontology's classes and properties; its outputs are constrained by the same shapes that already validate the graph; and the SPARQL behind it is generated from the ontology rather than written by hand and left to drift out of sync. A small proof-of-concept — a stdio MCP server exposing one tool over the live SPARQL endpoint, walked through step by step from human question to tool call to answer — is offered not as a finished product but as the smallest possible sketch of that idea, and a starting point for discussing what a genuinely ontology-driven MCP server would need.

Part 1 — the work: what it takes to compute an answer instead of retrieving one. Three properties carry the weight, and none of them is free. Reasoning runs inside the database, at query time — GQLDB derives inverse, symmetric, transitive, sub-property and property-chain relationships as virtual edges while the query executes, so nothing is materialized and a correction to the data changes the inferred answer on the very next read. For anyone who has run CONSTRUCT rules to a fixpoint, that is the same clean boundary between asserted and derived fact, without the re-computation — and GQLDB will import your OWL/RDF, export it losslessly, and federate to a remote SPARQL endpoint from inside a GQL query. Every answer carries its derivation, down to the source record it rests on. And the same question returns the same answer — which sounds trivial, and is in fact something you engineer deliberately and then test for. Drug repurposing is where we chose to prove all this, because it is a domain that will actually score you: rank candidate compounds by traversing declared biological mechanisms, then hide every known drug across 75 diseases and measure how many the engine brings back in its top ten. Across 752 held-out pairs it recovers them 8.6× more often than a random draw of the same size — an unglamorous number, stated the unglamorous way on purpose. The vertical is one studio among several on the same engine; the machinery underneath it is not biomedical.

Part 2 — the idea: your benchmark should be grading your data, not just your engine. Most of us build a retrospective benchmark to answer one question — does the thing work? — and then we leave it there. The idea this talk puts forward is that the same artifact should be doing double duty. Run it again with one source database removed, and the drop in recall is that source’s contribution, measured in the units the application is actually judged by rather than asserted in a datasheet. Across the integrated biomedical graph behind that benchmark, the result was uncomfortable. Three-quarters of the edges are never traversed at all. Thirteen integrated source databases move the ranking by exactly zero, while the single smallest contributor carries two-thirds of the ranking quality. Size is not value. This is offered not as a finished methodology but as an instrument any graph team can build in days, and as a starting point for two conversations: what we owe the sources we integrate, and where the line sits between a structural hypothesis and a causal claim — a line this engine deliberately does not cross.