Context for AI

Model the business once. Give every agent the same answer.

graph.build turns your source systems into a governed knowledge graph of entities, relationships and the definitions behind them, then serves it to your models as structured context with provenance attached. Your agents stop guessing what a customer is, because somebody wrote it down.

Book a demo See the platform

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

What it does

Three moves, and you can watch all of them

Model the domain, map the sources to it, write the result. Nothing in that chain is proprietary: the ontology comes out as OWL and RDFS, the mapping is a file you keep, the output is RDF or node and edge CSV, and the target is any database that speaks SPARQL, Gremlin or openCypher. Everything below is the product, not an illustration of it.

01 · model

Studio holds the definition

Entities, relationships, constraints and the vocabulary the business already uses, as RDF or as a labelled property graph, in the same editor. The analyst edits it directly by dragging source fields onto the model; nobody opens a ticket. There is a code view for the people who want one, and it round-trips.

The consequence: one answer to “what is a customer”, and it is version-controlled.

Supplier 4,214 nodes

legalName string · required

dunsNumber string · unique

supplies → Part

operates → Site

tier enum · 1–3

02 · transform

Transformers map source to meaning

Point a Transformer at SQL, a REST API, a Kafka stream or a pile of CSV, JSON, XML, XLSX and ODS files, and it produces graph data shaped by the model. What comes out is subject, predicate, object: open standard triples you could read yourself. Over a hundred built-in functions cover the usual reshaping, and you can add your own for the cases that are only yours.

The consequence: because the ontology exists first, Studio can warn you as you build that a mapping does not conform to it, or refuse it outright. Records that fail on the way through go to a dead letter queue rather than disappearing.

gbo:Supplier/213847561 Northgate Ltd

gbo:Supplier/213847561 gbo:Supplier

gbo:Supplier/213847561 gbo:Part/HX-8841

gbo:Part/HX-8841 14 (integer)

n-triples 8 emitted, validated against supply-chain.ontology all passed
unmapped: 0 · quarantined rows keep their reason

03 · write

The graph stays current

The transformation writes straight into your graph database. Writers emit its native load in insert or update mode, so the run that produces the data is the run that lands it, with no hand-off in between. Change data capture is the addition on top: point it at any Debezium-compatible source and the graph keeps itself in step. If you would rather not load at all, take the same output as files, RDF or node and edge CSV.

The consequence: the graph is a system of record your teams query, not a snapshot someone refreshes.

09:41:02 insert · nodes + 1,904

09:41:03 upsert · nodes ~ 312

09:41:03 insert · edges + 4,118

09:41:04 upsert · edges ~ 96

09:41:04 run complete 00:00:02

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.

Sources Build Store Consume

Kafka & Files

SQL

RESTful endpoints

graph.build Transformers
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

Vendor independence

The model is the asset. The database is a deployment detail.

Most teams pick a graph database before they know what they are modelling, and the model ends up shaped by that choice, particularly with property graphs, where nothing is standardised and the shape becomes commercially sticky. graph.build keeps the model in the platform and treats the database as an output. Switching vendor is a configuration change and a re-run, which also means you can benchmark two of them on your own model before committing to either.

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.

Docker

Every component is a container. Run the whole platform on a laptop before you run it anywhere else.

Scales both ways

Transformers and Writers scale horizontally; add processors for a bigger load rather than a bigger box.

Your network

On-premise, or your own tenancy on AWS, Azure or Google Cloud. Sources, model and database stay inside your perimeter.

Fits the pipeline

Kafka in, CDC through, scheduled or event-driven. It joins the platform you have rather than replacing it.

# bring the platform up

docker compose up -d

# transform: a source file, and the mapping that gives it meaning

curl -X POST http://transformer:8080/process \

-H 'Content-Type: application/json' \

-d '{

"inputFileURL": "file:///var/local/suppliers.csv",

"logicalSource": "suppliers.csv",

"mappingURL": "file:///var/local/supply-chain.ttl"

# it answers with the graph data it wrote

/var/local/graphbuild-output/suppliers.nq

# write: hand the writer that file

curl -X POST http://writer:8080/process \

-H 'Content-Type: application/json' \

-d '{ "inputFileURL": "/var/local/graphbuild-output/suppliers.nq" }'

graphDatabaseProvider: neptune · 1,204 ms · 0 rejected

ontology model designer

Class Supplier

Literal hasLegalName as string

Predicate hasPart to Part

Generate, then Publish as v14

2 classes · 5 predicates · published v14

@prefix owl: .

@prefix rdfs: .

@prefix gbo: .

gbo:Supplier a owl:Class .

gbo:Part a owl:Class .

gbo:hasPart a owl:ObjectProperty ;

rdfs:domain gbo:Supplier ;

rdfs:range gbo:Part .

gbo:hasLegalName a owl:DatatypeProperty ;

rdfs:domain gbo:Supplier ;

rdfs:range xsd:string .

supplier.csv

:ID,legalName,dunsNumber,riskTier,:LABEL

part.csv

:ID,sku,leadTimeDays:int,:LABEL

supplier_part.csv

:START_ID,:END_ID,:TYPE

One model, two standard outputs, which is why the work survives a change of database and a change of us.

Which graph databases can you write to?

Any database that supports SPARQL, Gremlin or openCypher, in both insert and update mode. That covers Amazon Neptune, Neo4j, Stardog, Memgraph, GraphDB, RDFox, Virtuoso, AllegroGraph and a couple of dozen more. RDF* is supported. The current list is on the compatibility page.

Can we change database vendor later?

Yes, and this is the point of the platform. The model lives in graph.build, so moving it is a configuration change and a re-run. This holds for property graphs as well as RDF, which is where teams usually find themselves stuck. A property graph model is not standardised, so its shape tends to bind you to the vendor you built it in.

How is this different from Neo4j's tooling?

Neo4j's tooling is excellent and it is built around Neo4j's database. graph.build is vendor-agnostic by default: the same model writes to any of the supported databases, and you can benchmark several on your own data before choosing one.

Do we have to use the visual editor?

No. One click opens the model in code and you can edit it there, then flick back. The platform is designed so that no coding is required, not so that coding is forbidden.

Our model is enormous. Can a visual editor cope?

Yes. You work on the region you care about rather than the whole graph. One person holds edit control at a time and hands it over explicitly, while everyone else has the model open read-only. The platform has run some very large and complex models; we are happy to share benchmarks against a use case like yours.

What can you read data from?

SQL databases, REST APIs, Kafka streams, and CSV, JSON, XML, XLSX and ODS files. Remote data can also be virtualised into the model rather than copied into it.

How does the graph stay current?

Change data capture from any Debezium-compatible source, including SQL databases, MongoDB and Cassandra, applied as inserts, updates or deletes, with provenance carried through.

Where does it run, and does our data leave our network?

Every component is a Docker container, deployed on-premise or in your own cloud tenancy. Your data does not leave your infrastructure.

How does an agent get to the graph?

It queries your graph database directly, in whichever dialect that database speaks, under the access control you already run there. Separately, Studio publishes a read-only MCP server so an assistant can read the ontology itself: the classes, the properties and the relationships between them. That is the part most teams are missing, because it is what tells a model what your data means.

We already have a vector database. Does this replace it?

No, and you should keep it. Vector search finds passages that resemble a question; graph retrieval returns the entities, how they relate, and where each came from. They answer different questions and the strong systems run both. What a vector index cannot give you is a definition.