Open-source project
trustgraph-ai/trustgraph avatar
trustgraph-ai/trustgraph

TrustGraph: hypergraph context orchestration for agentic AI

The context orchestration layer powered by hypergraphs. Build a unified semantic context layer where agentic outcomes are deterministic and agent behavior is not just traceable, but cryptographically verifiable.

2,765 stars329 forksPythonApache-2.0

At a glance

What is it?
TrustGraph is an Apache-2.0 Python stack that turns raw enterprise data into RDF and OWL hypergraphs so agents query explicit relationships instead of guessing from embeddings. The idea is sound; the operational cost is real.
Who is it for?
Adopt TrustGraph if your agents must answer over entities whose names collide with ordinary words or whose relationships are n-ary, and you already run a graph or vector store you can point it at. Do not adopt it if you want a single pip install and a working demo in ten minutes, or if your data is already clean and your retrieval quality is fine.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository received new commits within the last day.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The problem TrustGraph names: context that two agents do not share

The README opens with Abbott and Costello's "Who's on First?" routine, and it is not decoration. In that sketch, `Who`, `What` and `I Don't Know` are the names of players, but a listener parses them as questions. The project argues that two agents fail the same way when they lack a shared context understanding. Its concrete claim is narrower than "RAG is bad": vector search operates on statistical proximity, so a query like "Who is playing on first base?" pulls the pronoun sense of "Who" rather than the person. The README walks through that failure step by step and concludes that semantic similarity "cannot distinguish between the linguistic usage of a word as a pronoun and its usage as a proper noun within a specific, localized context." That is the target audience: teams whose entities have ambiguous surface forms, or whose relationships involve more than two parties. If your corpus is prose about generic topics, this framing will feel like a solution in search of a problem.

How the hypergraph layer actually stores context

The mechanism is RDF plus OWL plus named graphs, not a proprietary graph format. TrustGraph states it leverages RDF 1.2 and Named Graphs serialized as N-Quads, because RDF 1.2 lets a statement itself be referenced as a node. That is what upgrades a binary edge into an n-ary one. The README contrasts the two directly: a standard knowledge graph records `Document` to `Author`, while TrustGraph connects `Document`, `Author`, `Approving Manager`, `Compliance Policy` and time or location metadata into one addressable relational event.

The README also shows the ontology side in Turtle, with `:Player` and `:BaseballPosition` as `owl:Class`, `:playsPosition` as an `owl:ObjectProperty` with `rdfs:domain` and `rdfs:range`, and the facts attached as `:Who :playsPosition :FirstBase`. Retrieval then runs over SPARQL or GraphRAG rather than embedding distance. Ingestion is the other half: the README describes a processing engine that takes PDFs, wikis, APIs and databases, extracts entities and relationships with LLMs, and writes them into the hypergraph. Note what that means operationally. An LLM still decides what becomes a triple, so determinism applies to retrieval and traversal, not to extraction. The project's own claim is that ontology-compliant retrieval is automated and that a supplied ontology governs semantic compliance for ingested data. Whether extraction errors survive that gate is the thing to test on your own documents.

Installing TrustGraph and running a first ontology-backed query

There is no single `pip install trustgraph` workflow documented in the README. The README points to a self-host config UI at `https://config-ui.demo.trustgraph.ai/` and to the docs at `https://docs.trustgraph.ai`. The repository carries `install_trustgraph.sh`, `install_packages.sh` and `README.dev-install.md` for a source install, and the Makefile reveals how the project is packaged: eleven separate distributions are built with `python -m build --sdist`, including `trustgraph`, `trustgraph-base`, `trustgraph-flow`, `trustgraph-cli`, `trustgraph-mcp`, `trustgraph-ocr`, `trustgraph-unstructured` and `trustgraph-docling`. Plan for a multi-package install, not a library you import and forget.

For a source checkout, the documented entry points are the shell scripts at the repository root. Run the installer from the directory you cloned:

bash
./install_trustgraph.sh

The README does not spell out what that script prompts for, so read it before running it. The Makefile is the build path for containers, and it defaults to `podman` rather than Docker:

bash
make containers

If you build wheels instead, the Makefile's `packages` target emits sdists into `dist/` for each of the eleven distributions, and `pypi-upload` pushes them with `twine upload dist/*-${VERSION}.*`. For a first real use, the README's own example is the right one: load an ontology in OWL format (the repository ships `schema.ttl` as a starting point), ingest a small corpus, then ask the "Who's on First?" question. On a correct setup the agent resolves `:Who` to `:Player` with `:playsPosition :FirstBase` rather than returning documents that merely mention the word "who". If it returns prose, your ontology did not reach the retrieval path.

The dependency and operations bill

`requirements.txt` is the most honest document in the repository. It lists `torch`, `transformers`, `sentence-transformers`, `langchain`, `langchain-community`, `pymilvus`, `scylla-driver`, `pulsar-client`, `rdflib`, `pypdf`, `anthropic`, `google-cloud-aiplatform`, `boto3`, `ollama`, `pyarrow` and `prometheus-client`. That is a vector store (Milvus), a wide-column store (ScyllaDB), a message bus (Pulsar), a graph library (rdflib), and model runtimes for both hosted and local inference, all in one environment. The repository layout confirms the split: there are separate packages for Bedrock, Vertex AI, Hugging Face embeddings, OCR, Unstructured and Docling, plus a `trustgraph-mcp` package for MCP integration and a `containers/` directory.

This is a platform, and it should be budgeted like one. The upside of the split is that you can run local embeddings via `trustgraph-embeddings-hf` and `ollama` instead of sending data to a hosted model, which matters if the compliance-policy part of the pitch is what drew you in. The downside is that an upgrade touches several independently versioned packages, and the Makefile's `VERSION=0.0.0` default suggests the release process rewrites versions at build time rather than reading them from a tag.

Where TrustGraph is the wrong tool

If your retrieval already works, TrustGraph adds a graph, a bus and a column store to solve a problem you do not have. The "Who's on First?" argument is a genuine failure mode of embedding search, but it is a narrow one, and most teams can patch it with a glossary or a reranker for far less operational surface.

The harder limitation is the ontology itself. TrustGraph's accuracy claim rests on ontology-compliant ingestion, and the README does not describe what happens when an LLM extracts a relationship that violates the supplied ontology. It says the hypergraph "will use the provided ontology for semantic compliance for all ingested data", which implies a rejection or correction step, but the README does not document the failure path, the error surface, or how a rejected triple is reported back. Without that, a malformed extraction can look identical to a document that simply had nothing to contribute.

Second, the cryptographic verifiability claim in the project description is not explained in the README. The description says agent behavior is "cryptographically verifiable", but the README body does not describe a signature scheme, a hash chain, or a verification command. Treat that as a roadmap statement until you find it in the docs.

Third, the README does not document rollback, schema migration, or how to remove data from the graph once ingested. For a system that stores policy-bearing context, that gap matters more than any performance number.

TrustGraph compared with GraphRAG and Graphiti-style temporal graphs

The most common comparison is GraphRAG, and the difference is where structure comes from. GraphRAG-style pipelines build a graph from the corpus: an LLM reads the documents, proposes entities and relationships, and the graph is whatever the extraction produced. TrustGraph inverts the direction by accepting a Bring-Your-Own-Ontology in OWL and using it to govern what may be ingested. In the first case the graph is a summary of your documents; in the second it is a constrained model of your domain that your documents must fit. That is a real trade-off, not a marketing one. A corpus-derived graph accepts everything and stays flexible. An ontology-governed graph rejects anything the ontology cannot express, which is exactly what you want when a compliance policy is part of the relationship, and exactly what you do not want when you are still discovering what your entities are.

Graphiti and similar temporal graph tools sit closer to the corpus-derived end, with time as the organizing axis. TrustGraph handles time as one attribute inside a named-graph event rather than as the primary structure. If your questions are mostly "what changed since last week", that difference will show up quickly. If your questions are "who approved this, under which policy, and where", TrustGraph's n-ary grouping is the better fit.

Licence, maintenance and upgrade cost

TrustGraph is Apache-2.0, and the LICENSE file is at the repository root. Apache-2.0 is permissive: you can use it commercially, modify it, and redistribute it, provided you keep the licence and notice files and state significant changes. It also includes an explicit patent grant, which is the clause enterprises usually care about. It does not grant trademark rights, so the TrustGraph name and logo are not yours to reuse. None of this is legal advice; if you are embedding the stack in a shipped product, have counsel read the NOTICE requirements against your own distribution model.

The repository is not archived, and the last push was on 2026-09-03, with v2.8.17 (TrustGraph 2.8) released on 2026-09-08. That is a recent cadence. The upgrade cost is the part to plan for: eleven distributions built separately, a `VERSION` variable that defaults to `0.0.0` in the Makefile, and a dependency set that pins you to a specific combination of Milvus, ScyllaDB, Pulsar and LangChain. Upgrading one of those without the others is the failure mode to expect.

Editorial conclusion

Adopt TrustGraph if your agents must answer over entities whose names collide with ordinary words or whose relationships are n-ary, and you already run a graph or vector store you can point it at. Do not adopt it if you want a single pip install and a working demo in ten minutes, or if your data is already clean and your retrieval quality is fine. Before committing, load your own OWL ontology through the config UI and check that ontology-compliant retrieval rejects a deliberately malformed triple, because that behaviour is the whole product.

Frequently asked questions

What is a context graph and how does TrustGraph implement one?

A context graph is the structured layer an agent queries instead of relying on embedding similarity. TrustGraph implements it as an RDF 1.2 hypergraph with named graphs serialized as N-Quads, so a statement can itself be a node and relationships can involve more than two entities.

What is the difference between a knowledge graph and a context graph in TrustGraph?

The README frames standard knowledge graphs as limited to binary relationships such as Document to Author, while TrustGraph groups Document, Author, Approving Manager, Compliance Policy and time or location metadata into one addressable relational event. The distinction is n-ary grouping rather than a different storage engine.

What are the key differences between GraphRAG and a TrustGraph context graph?

GraphRAG-style pipelines derive the graph from the corpus, so the graph reflects whatever the extraction produced. TrustGraph accepts a Bring-Your-Own-Ontology in OWL format and uses it for semantic compliance on all ingested data, which constrains what the graph may contain.

What are the different types of knowledge graphs TrustGraph supports?

The README does not enumerate knowledge graph types. It describes one architecture: an RDF 1.2 hypergraph using named graphs as N-Quads, with an OWL ontology supplied by the user.

What is a trustgraph alternative for building agent context?

A corpus-derived GraphRAG pipeline is the closest alternative, and the difference is direction: it builds the graph from your documents instead of governing ingestion with a supplied ontology. Temporal graph tools are another option when time is the primary axis of your questions rather than one attribute of an event.

Official sources

  1. License: Apache-2.0
  2. Project website
  3. README
  4. Releases
  5. trustgraph-ai/trustgraph on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/trustgraph-ai-trustgraph.svg)](https://hysenlabs.com/projects/trustgraph-ai-trustgraph)