VeritasGraph: a governed GraphRAG and agent framework that runs on your own hardware

What VeritasGraph solves, and who it is actually for

Standard retrieval-augmented generation finds passages that look similar to a question. It does not know that two documents describe the same entity, and it cannot follow a chain of relationships across them. VeritasGraph attacks that gap by building a knowledge graph from your documents first, then answering questions by walking nodes and edges. The README states the position plainly: "Traditional RAG guesses based on similarity. VeritasGraph reasons based on structure."

The audience is narrower than the topic list suggests. This is for teams with documents they are not allowed to send to a hosted model, and with questions that need more than one hop to answer. The repository ships worked examples for clinical knowledge graphs, a municipality incident chatbot, and a signal reference set, which points at regulated or public-sector settings rather than general chat. If your retrieval problem is a single well-formed query against a clean corpus, a vector index is cheaper and simpler. The graph only pays for itself when relationships between entities carry the answer.

How the graph pipeline and the agent pipeline fit together

There are two distinct systems in this repository, and conflating them is the most common way to misread the project.

The first is the retrieval pipeline. Documents are ingested, entities and relationships are extracted, and the result is a graph that can be queried with citations. Answers carry source attribution in the form of `[doc#chunk]` markers, which is what makes the output checkable rather than merely plausible. Storage is split: the requirements file lists `graphrag`, `lancedb` and `networkx`, so the graph structure and the vector index are separate components with separate configuration. The `.env.example` file points `GRAPHRAG_INPUT_DIR`, `GRAPHRAG_OUTPUT_DIR` and `LANCEDB_URI` at a `graphrag-ollama-config` directory, which tells you the intended layout is file-based by default, with Neo4j reserved for the full mode.

The second system is Studio, a FastAPI application with a single-page interface. Its per-turn pipeline runs in a fixed order: guardrails, then memory, then the knowledge graph, then a context budget step the README calls headroom, then tools, then a data log. Every stage is visible in a trace. That ordering is the design decision worth noticing. Guardrails run before retrieval, so PII redaction happens before text reaches the model, not after. Memory is consulted before the graph, which means a follow-up question can be answered from conversation state without a graph lookup. If you have used agent frameworks where the tool loop is opaque, this trace is the feature you are buying.

Installing VeritasGraph and running the first demo

The README gives a two-line quick start that needs no GPU and no local models. It uses a cloud API key, so it is the fastest way to confirm the package installs and the CLI responds.

pip install veritasgraph
veritasgraph demo --mode=lite

Before that second command, export a key. The README shows the OpenAI variable, and the `.env.example` template also lists `OPENAI_API_BASE`, `OPENAI_MODEL` and `OPENAI_EMBEDDING_MODEL` if you are pointing at an OpenAI-compatible endpoint.

export OPENAI_API_KEY="sk-..."
veritasgraph demo --mode=lite

For a fully offline run, the README specifies Ollama with 8GB of RAM and a model flag. The environment template defaults `OLLAMA_BASE_URL` to `http://localhost:11434` and the embedding model to `nomic-embed-text`.

veritasgraph demo --mode=local --model=llama3.2

The third mode is the one that needs infrastructure. The README's own table lists Docker plus Neo4j as the requirement for `--mode=full`, and the command is `veritasgraph start --mode=full`.

veritasgraph start --mode=full

Studio is installed differently, from the repository rather than from PyPI. The README's commands are below. Note that the data directory is passed as an environment variable at launch, and the UI is served under a path, not at the root.

pip install -r requirements.txt
ollama serve & ollama pull qwen3:latest
STUDIO_DATA_DIR="$PWD/studio_api/data" \
  uvicorn studio_api.main:app --host 127.0.0.1 --port 8200 --log-level warning

After that, the Studio interface is at `http://localhost:8200/studio` and the API documentation is at `/docs`. There is also a single end-to-end demo script that the README says builds a graph and drives a wired agent through graph reasoning, memory recall, PII redaction and a guardrail block.

python3 demos/agent-studio/sample_pipeline.py --model qwen3:latest

That script is the best first test, because it exercises the orchestration order described above in one run rather than making you assemble it.

Where VeritasGraph will disappoint you

The repository has no retrieved releases. That matters more than it sounds. There is no changelog, no version history, and no way to tell what changed between the package on PyPI and the code on the default branch, which is named `restored-main` rather than `main`. Anyone planning an upgrade needs to read commits, not release notes.

The licence situation is inconsistent in the repository. The README carries an MIT badge and links to opensource.org, and `pyproject.toml` declares `license = { text = "MIT" }` for the `veritasgraph-mcp` distribution. The repository metadata itself lists the licence as unknown. The two package names differ as well: the PyPI install is `veritasgraph`, while `pyproject.toml` in the repository root names the project `veritasgraph-mcp` at version 0.1.2 and describes it as an MCP server, with a `veritasgraph-mcp` console script. A reader should not assume the `pip install veritasgraph` package and the repository's `pyproject.toml` describe the same distribution.

The full mode is the weakest documented path. The README's table says Docker plus Neo4j, and stops there. There is no compose file named in the repository, no connection configuration beyond the file-based variables in `.env.example`, and no rollback procedure. If your deployment depends on Neo4j, you are reading source code to find out how it connects.

Finally, the guardrail story is described as PII redaction and policy blocking with visible counters. That is a mechanism, not a compliance certification. Redaction that runs before the model call is a reasonable design, but the repository does not state which entity types are covered or how false negatives are handled.

How it differs from FastGraphRAG, nano-graphrag and the FalkorDB stack

The related searches around this project cluster on GraphRAG variants, so the comparison is worth making concrete.

FastGraphRAG and nano-graphrag are retrieval libraries. You call them, you get an answer, and the surrounding application is yours to write. VeritasGraph bundles a retrieval pipeline and an agent runtime in the same repository, with a defined turn order of guardrails, memory, graph, context budget, tools and logging. If you already have an agent loop you like, that bundle is overhead, and a smaller library will fit better. If you do not, the bundle is the reason to look.

The FalkorDB and Neo4j options differ at the storage layer. VeritasGraph's default configuration is file-based, with `LANCEDB_URI` pointing at a directory and `networkx` in the dependency list for graph operations. Neo4j appears only as a requirement for full mode. A team already running FalkorDB or Neo4j for other workloads gains graph query tooling and operational familiarity by staying there; VeritasGraph's advantage is the opposite, that the lite and local modes need no database server at all.

The MCP angle is the other real difference. The repository contains a `veritasgraph_mcp` package with a `veritasgraph-mcp` entry point, and Studio lists MCP bridge connectors with health-aware probing. If your tooling already speaks the Model Context Protocol, that is a shorter integration path than wrapping a retrieval library by hand.

Maintenance, upgrade cost and licence implications

The repository is not archived, and the last push was on 2026-09-10. That is recent enough that the code is moving, but the absence of releases means the movement is only visible in commits. Treat the default branch as the source of truth and pin the version you install.

Upgrade cost concentrates in two places. The first is `requirements.txt`, which pins lower bounds rather than exact versions across `graphrag>=0.5.0`, `lancedb>=0.13.0`, `openai>=1.40.0`, `anthropic>=0.34.0` and `ollama>=0.3.0`. A fresh install months from now will resolve to different versions than today's, and the graph and vector layers are the ones most likely to break. The second is the `graphrag-ollama-config` directory layout, because `GRAPHRAG_INPUT_DIR`, `GRAPHRAG_OUTPUT_DIR` and `LANCEDB_URI` all point into it. Rebuilding the index after an upgrade is the realistic migration step.

On licensing, the repository points to MIT in two places and lists the repository licence as unknown. MIT is permissive and imposes no source-disclosure obligation on your own code, but this is a description of what the files say, not legal advice. If your organisation needs a signed licence statement, the repository does not currently provide one.

Editorial conclusion

Adopt VeritasGraph if you need knowledge-graph retrieval and agent orchestration that can run entirely on your own machines, and if you are willing to read the repository rather than rely on a stable API contract. Do not adopt it if you need a published release history, a documented upgrade path, or a supported Neo4j deployment, because none of those appear in the repository. Verify three things before you commit: that the MIT licence in pyproject.toml and the README badge match the terms you need, that studio_api.main:app starts on port 8200 in your environment, and that the veritasgraph-mcp entry point resolves after installation.

Frequently asked questions

Official sources

1. bibinprathap/VeritasGraph on GitHub
2. Issues
3. Project website
4. README