It cannot resolve an entity
Customer, account holder and counterparty are the same party in three systems, or deliberately are not. A passage retriever has no way to know which, so it picks whichever text scored highest.
Context for AI
Your model does not know what a customer is
Retrieval finds text that resembles the question. It cannot tell you whether the customer in your CRM is the account holder in billing, because nobody wrote that down. graph.build is where you write it down, and where your agents read it.
Input
Hierarchy
Vocabulary
supply-chain.ontology · Ontology Model Designer
Input
Class
Literal
IRI Config
http://graph.build/ontology/
hasPart
hasLegalName
hasDuns
hasDescription
hasLeadTime
Supplier
Part
string
string
string
integer
supply-chain.ontology · 2 classes · 5 predicates
Publish
supply-chain.ontology
Name supply-chain
Access Private
Latest 2026-08-13 11:19
Version v14
publish to inform or restrict
the creation of other models
The problem
Fluent, unciteable, and occasionally wrong
None of these is a model problem, which is why none of them is fixed by a bigger context window or a better prompt. They are all the same missing artefact: a definition of the business that a machine can read.
It cannot show its working
An answer assembled from chunks can cite a document but not a fact. When someone asks which system the number came from and as of when, there is nothing to point at.
It is reading an old index
Embeddings are computed once. Unless something re-indexes on every source change, the agent is confidently describing the state of the business on the day the job last ran.
What fixes it
An ontology is the schema your LLM never had
Not a data schema, which says a column is a varchar. A definition of what things are, how they relate, and which rules hold.
the artefact
Meaning, written down once
Studio is where the definitions live: entities, relationships, constraints and the vocabulary the business already uses, as RDF or as a labelled property graph. They are versioned, reviewed and governed centrally, so the answer to “what is a customer” has one owner rather than four opinions.
The consequence: an agent traversing the model reaches the same definition your finance system uses, because it is the same definition.
studio · entity · Supplier · v14
Supplier 4,214 nodes
legalName string · required
dunsNumber string · unique
supplies → Part
operates → Site
tier enum · 1–3
validates · 0 constraint violations
AI context
Entities and provenance, not the three nearest paragraphs
Retrieval over a modelled graph returns the things themselves, the relationships between them, and where each one came from. The difference is whether an answer can be checked.
Grounded
The agent traverses your definitions, so an answer names the same entity your finance system does, and knows whether “counterparty” and “account holder” are the same thing or deliberately are not.
Traceable
Every node carries the source and the run that produced it. “Where did that come from” has an answer you can hand to an auditor.
Current
Change data capture keeps the graph in step with the systems underneath, so retrieval is not reading last quarter.
Serving path
16:9
Sources
Build
Store
Consume
Kafka & Files
SQL
RESTful endpoints
graph.build
Transformers
Ontology
Writers
Ontology
Writers
Your graph database
SPARQL · Gremlin · Cypher
Agent
any model, any framework
MCP
MCP on the Studio Node: an assistant reads the published ontology, read-only, with no source credentials handed to the model
No lock-in, old or new
Your context should outlive your agent framework
The model lives in graph.build, not inside a database and not inside whichever orchestration library the team picked this quarter. The reason you can change graph database vendors with a configuration entry is the same reason the definitions you write this year survive the next rewrite of your AI stack.
- The model is a file in the platform, not a schema in a database
- Switching target is a configuration change and a re-run
- Benchmark two vendors on your own model before committing
one model · four targets
supply-chain.model · v14
Neo4j
openCypher
Amazon Neptune
Gremlin
Memgraph
openCypher
RDFox
SPARQL
Same model, four generated loads. Changing target is a configuration change and a re-run.
Scope
What graph.build does not do
Being specific here is the point. We build and serve the context; what consumes it stays your choice.
We do not run the model
No hosting, no training, no fine-tuning. Bring the model you have already chosen and the platform you already run it on.
We do not replace vector search
Passage similarity and entity traversal answer different questions. Keep the vector database; serious systems run both.
We are not an agent framework
No orchestration, no tool-calling layer, no opinion about how you build the agent. The graph is reached through a standard interface.
We do not claim to end hallucination
We claim an answer can be checked: grounded in your definitions, traced to a source, current with the systems underneath. That is the property that gets a system into production.
Bring a question your agents get wrong
We will model the part of your domain it turns on and show you the same question answered from the graph, with provenance.
- 45 minutes, your data, no installation
- Runs in your account when you want it to
- You keep the model either way