Documents → knowledge graph

Turn documents into a knowledge graph your AI can query.

Point InvariantDB at your documents. It reads them, pulls out the entities and the relationships that connect them, and merges everything into one graph — deduplicated against what you already have. Then your AI answers from connected facts, not just the nearest paragraph.

Get started See graph-grounded retrieval

Ingest via HTTP or any MCP client One canonical version — never stale Grounded answers — not just nearest text

What you get

From raw text to a graph you can walk.

A document isn't just something to search — it's full of facts and the relationships between them. InvariantDB pulls those out for you and keeps them connected, current, and queryable.

01 · Extract

Entities and relationships, found for you

Send a document; InvariantDB extracts the people, places, and things in it — and the relationships that tie them together — then merges them into the graph. New facts deduplicate against the ones already there, so the same entity doesn't fork into copies.

02 · Keep it living

One canonical version, never stale

Save a document under a stable name. Each new revision supersedes the last while the earlier versions stay readable. Fetch the current version before you rely on it — or read it exactly as it stood on any past date.

03 · Retrieve by walking

Answers from connected facts

Start from the best-matching text, then walk the relationships around it to bring back the facts an answer actually needs. This is GraphRAG — graph-grounded retrieval — instead of returning the nearest chunk and hoping it was enough.

Ingest a document

One call turns a document into graph.

1Send the document. POST /graphs/{name}/ingest with the text, a stable uri and a revision — or call the save_document tool from any MCP client.
2InvariantDB extracts. Entities and relationships are pulled out and merged into your graph, deduplicated against what's already there.
3Query it. The new facts are immediately available to Cypher, search, and graph-grounded recall — no separate load step.

POST /ingest

# turn a document into graph — one call
curl -H "Authorization: Bearer $INVARIANTDB_API_KEY" \
     -H "content-type: application/json" \
     -X POST https://invariantdb.com/e/graphs/$GRAPH/ingest \
     -d '{
       "uri": "docs://pricing-policy",
       "revision": "1",
       "text": "Acme Supply ships tents to the Northwest region...",
       "mode": "full",
       "entity_types": ["Product", "Supplier", "Region"],
       "min_confidence": 0.6
     }'

The document is read, its entities and relationships are extracted and merged into your graph, and you get back a job you can poll for a plain-language summary of what was added. Save the same uri again later with a new revision and the new version supersedes the old one. Extraction runs with "mode": "full"; the default, document-only, stores the text without extracting.

MCP tools

// the same ingest, in one tool call
save_document({
  uri: "docs://pricing-policy",
  revision: "2",
  text: "...revised copy...",
  entity_types: ["Product", "Supplier", "Region"]
})

// always read the current version before relying on it
get_document({ uri: "docs://pricing-policy" })

// see how it changed — read it as of any point
list_document_revisions({ uri: "docs://pricing-policy" })

Living documents

Never argue with an out-of-date copy.

A document saved under a stable uri is a single source of truth. Each revision supersedes the last, so there's always exactly one current version — and the full history stays readable behind it.

→save_document ingests a new revision under an existing uri; the prior version is superseded, not overwritten.
→get_document returns the current canonical version — the one your AI should read before it acts.
→list_document_revisions lists every revision, newest first, so you can read the document as it stood at any moment.

Steer the extraction

Tell it what to look for.

By default InvariantDB decides what's worth extracting. When you want tighter control, hand it a contract — the kinds of entity you care about, and how sure it has to be before it commits a fact to the graph.

→entity_types — restrict extraction to the categories that matter for this graph (for example Product, Supplier, Region).
→min_confidence — drop low-confidence extractions so only facts the engine is sure about land in the graph.
→A per-graph ontology — set the contract once for the whole graph and every ingest follows it, without repeating it per request.

ontology contract

# steer a single ingest
{
  "uri": "docs://pricing-policy",
  "revision": "3",
  "text": "...",
  "mode": "full",
  // only extract these kinds of entity
  "entity_types": ["Product", "Supplier", "Region"],
  // require this much confidence before committing
  "min_confidence": 0.6
}

# or set the contract once, per graph, and
# every future ingest inherits it

Graph-grounded retrieval (GraphRAG)

Retrieve by walking the graph.

Nearest-text search is a good way to find a starting point — and a poor way to finish an answer. Once the document is a graph, you can find the best-matching facts, then expand across the relationships around them to bring back the connected context the answer really needs. One call, no external retrieval pipeline to wire together.

In Cypher

`gds.semanticMatchExpand`

Best-matching seeds plus an N-hop expansion across your relationships, in a single Cypher call — the seed match and the graph walk in one step.

// seeds + 2-hop expansion, one call
CALL gds.semanticMatchExpand(
  'Document', 'embedding', $q, 10, 2)
YIELD nodeId, distance, score
RETURN nodeId, distance, score
ORDER BY distance, score DESC

Over HTTP

`POST /memory/recall`

One round-trip ranked recall for an agent turn: full-text and graph expansion combined server-side, returning the top-k grounded snippets ready to drop into a prompt.

# ranked recall in one round-trip
curl -X POST \
  .../graphs/$GRAPH/memory/recall \
  -d '{"query":"who supplies
        tents to the Northwest region",
        "k":5,"hops":1}'

Both return facts with their surrounding relationships attached, so the model reasons over connected evidence rather than a bag of similar sentences. Because everything lives in one engine, you can constrain retrieval with any predicate your graph supports — team, status, tenant, or a point in time. See the Cypher reference for predicate-filtered vector search.

Who it's for

For teams with documents — and for people who build with them.

Knowledge workers & teams

Your documents, connected and current

Frameworks, playbooks, and profiles that stay the current version everywhere.
Ask across everything you've saved and get answers grounded in the connections between facts.
Organize it in your own words — your entity types, not a generic schema.
Nothing to run; the assistant ingests and recalls for you.

Developers & AI builders

A GraphRAG backend over one endpoint

Documents in, knowledge graph out — entities and relationships extracted and merged for you.
Graph-grounded retrieval in one call, plus full Cypher, full-text, and vector search when you need them.
Living, versioned documents with as-of history built in.
Steer extraction with an ontology contract; pair it with durable AI memory.

Get started

Give your AI a knowledge graph, not a pile of PDFs.

Ingest your first document and query it in a couple of minutes.

Request access Explore InvariantDB →