Grounding LLMs in Verified Knowledge with Oxigraph

Large language models are remarkably fluent — and that fluency is exactly the problem. A model will answer a question about your supplier hierarchy, your IT asset topology, or a tax rule in the same confident tone whether it knows the answer or is reconstructing something plausible from statistical patterns. In enterprise settings, plausible is not good enough. We need answers that are verifiable.

This is where a knowledge graph backed by an RDF triple store changes the equation. Instead of asking the model to recall facts from its parameters, we let it query a curated, explicitly modelled source of truth. Here is why Oxigraph is a pragmatic choice for that source of truth, and how the grounding pattern works in practice.

The Limits of Vector RAG

Retrieval-Augmented Generation with vector embeddings is the default grounding technique today, and it earns its place. But embeddings retrieve text that is semantically similar to a query — not text that is true. A vector index has no concept of an entity, a relationship, or a constraint. Ask "which suppliers are owned by Company X and approved for category Y?" and a vector store returns the chunks that read most like the question. It cannot join facts, guarantee that a relationship holds, or confirm that the answer is complete.

Knowledge graphs solve the other half of the problem:

The strongest enterprise systems use both: embeddings to find the right entities, and the graph to retrieve verified facts about them.

Why Oxigraph

A triple store does not have to be heavyweight infrastructure. Oxigraph is an open-source graph database, written in Rust, that implements the SPARQL 1.1 standard — Query, Update and the HTTP protocol — over the full RDF model, including named graphs and RDF-star.

What makes it a good fit for an LLM-grounding layer:

For a proof of concept you can have a queryable graph running inside a Python service in a handful of lines: no cluster, no licence negotiation.

The Grounding Pattern

The architecture I keep returning to has five steps.

1. Model the domain as an ontology

Define the classes and properties that matter — Supplier, Category, approvedFor, ownedBy. This schema is what makes the data verifiable: it states what kinds of things exist and how they may relate.

2. Load verified data as triples

Ingest your authoritative records — from SAP, a CMDB, a contract repository — and materialise them as RDF. This curation step is where trust is established.

3. Translate the question to SPARQL

The model's job is not to know the answer. It is to translate a natural-language question into a SPARQL query, guided by the ontology and a few worked examples. Text-to-SPARQL is a far safer use of an LLM than text-to-answer, because the output is checkable before it ever runs.

4. Execute against Oxigraph

The query runs against the triple store and returns an exact result set. This step is deterministic: the same query over the same graph always yields the same facts.

5. Verbalise the result

The model turns the result set back into prose — but the facts come from the graph, not from the model. Attach the underlying triples as provenance, and every claim becomes traceable.

from pyoxigraph import Store, RdfFormat

store = Store()
store.load(input=open("procurement.ttl", "rb"), format=RdfFormat.TURTLE)

# A query the LLM produced from the user's question
query = """
PREFIX ex: <https://oesterwitz-consulting.de/ontology#>
SELECT ?name WHERE {
  ?supplier a ex:Supplier ;
            ex:name ?name ;
            ex:approvedFor ex:IndirectMaterials ;
            ex:ownedBy ex:CompanyX .
}
"""

for row in store.query(query):
    print(row["name"].value)   # verified facts, not a guess

The model never asserts that a supplier is approved — it asks the graph, and the graph answers from data you curated.

Why the Answer Is "Verified"

Three properties make this trustworthy in a way a raw model response is not:

You can go further and run SHACL validation over the graph, so the data itself is checked against your business rules before any question is asked.

Guardrails That Matter

Letting a model generate queries demands discipline:

From PoC to Production

In a recent knowledge-graph proof of concept for IT software asset management, this was exactly the pattern: an ontology over the managed systems, an LLM generating SPARQL, and a triple store answering questions about architecture and component relationships that vector search simply could not express. Oxigraph makes that same pattern cheap to stand up — small enough for an afternoon experiment, standards-based enough to grow into a production grounding layer.

Conclusion

The interesting question is no longer "can the model answer?" but "can the model prove its answer?" Grounding an LLM in a knowledge graph — with a standards-compliant, self-hostable triple store like Oxigraph underneath — turns generation from an act of recall into an act of retrieval against verified facts. For any enterprise where a wrong answer carries a cost, that is the difference that matters.