An enterprise knowledge graph stores company knowledge as typed nodes connected by typed edges, instead of as flat documents or a bare vector store. That structure lets AI retrieve by meaning, by exact term and by relationship at once — and return answers that carry provenance back to the source note. Fleece's graph stays plain markdown on disk and is queryable by any AI through MCP.
Flat docs and bare vectors lose the structure.
Dump everything into a folder and search is fuzzy: a keyword index finds the word but not the meaning, and a vector store finds the meaning but forgets exact names, IDs and how things connect. Neither knows that this decision overrode that one, or that this person owns that project.
The relationships are the knowledge. When retrieval flattens a typed structure into chunks of text, your AI gets plausible-sounding context with no way to traverse from a customer to its tickets to the engineer who fixed them.
Typed nodes, typed edges, optional fields.
Every note is a node with a type — person, project, decision, meeting, customer — and edges that say how nodes relate. Fields are Tana-style and optional: add a status, an owner or a due date when it matters, leave it off when it doesn't.
The schema is yours and it's enforced without locking you in. On disk it's still 100% markdown: YAML frontmatter for fields, [[wikilinks]] for edges, fully Obsidian-compatible. The graph is an index over your files, never a cage around them.
- +Typed nodes carry a schema — not anonymous text chunks
- +Edges are first-class: traverse relationships, don't guess them
- +Optional fields per node — structure where you want it
Three retrievers, one ranking, every answer sourced.
A query runs three ways in parallel: BM25 keyword over FTS5 for exact terms, vector similarity over sqlite-vec embeddings for meaning, and breadth-first graph traversal for related nodes. The results are fused into one ranked list, not stitched together by hand.
Because the hits are real nodes, every answer comes back with provenance — the note it came from and the path it was reached by. Median recall lands around 34 ms, and indexing 1,000 nodes takes about 4.2 seconds.
A Rust core: FTS5, sqlite-vec, redb, CRDT.
The graph runs on a compact Rust engine — roughly a 9.7 MB binary. FTS5 handles keyword, sqlite-vec handles embeddings, a redb store holds the graph for fast traversal, and yrs/CRDT keeps a conflict-free version history so the graph can grow from many writers without clobbering itself.
Agents query and extend the graph through MCP — ten tools, from brain_recall and brain_traverse to brain_connect, brain_schema and brain_diff. They read, write and reshape the same structure, so the graph compounds instead of going stale.
What makes the knowledge graph fast and trustworthy.
Typed graph schema
Tana-style nodes and edges with optional fields. Model people, projects and decisions as real types — not undifferentiated chunks of text.
Hybrid retrieval, ranked
Keyword (BM25/FTS5) + semantic (sqlite-vec) + graph BFS traversal, fused into one ranking. Exact terms, meaning and relationships in a single query.
Provenance by construction
Hits are real nodes, so every answer links to its source note and the traversal path it was reached by. No invented context.
Rust retrieval engine
FTS5, sqlite-vec and a redb graph store in a ~9.7 MB binary. ~34 ms median recall; 1,000 nodes indexed in ~4.2 s.
CRDT version history
yrs/CRDT gives conflict-free history, so many agents and people can grow the same graph concurrently without overwrites.
Queryable & growable via MCP
Ten tools — brain_remember, brain_recall, brain_traverse, brain_connect, brain_schema, brain_diff and more — let any AI read and extend the graph.
Technical questions about the knowledge graph.
What is an enterprise knowledge graph?+
It's a store of company knowledge modeled as typed nodes (people, projects, decisions, customers) connected by typed edges that capture how they relate. AI retrieves over the structure — by term, by meaning and by relationship — instead of over flat documents, so answers reflect connections, not just nearby text.
Why a graph instead of a vector database?+
A bare vector store ranks chunks by embedding similarity and loses exact identifiers and relationships. A knowledge graph keeps typed edges, so you can traverse from a node to its neighbours, and it runs vector search alongside keyword search and graph traversal in one fused ranking — semantic recall plus exact matches plus structure.
How does hybrid retrieval actually work?+
Three retrievers run in parallel: BM25 keyword over FTS5, vector similarity over sqlite-vec embeddings, and breadth-first traversal across the graph. Their results are merged into a single ranked list with provenance, with median recall around 34 ms. Semantic search optionally uses an embedding key, and the model is swappable.
Where is the graph stored and what's the engine?+
On disk it's 100% plain markdown — YAML frontmatter for fields, [[wikilinks]] for edges, Obsidian-compatible. The index runs on a Rust engine of about 9.7 MB using FTS5, sqlite-vec and a redb graph store, with yrs/CRDT for conflict-free version history. It indexes 1,000 nodes in roughly 4.2 seconds.
How do AI agents query and grow the graph?+
Through MCP, with ten tools: brain_remember, brain_recall, brain_read, brain_list, brain_connect, brain_traverse, brain_forget, brain_diff, brain_schema and brain_export. Agents recall context, traverse edges, add nodes and connections, and inspect the schema — so the graph keeps growing as they work. Local-first, with optional end-to-end encrypted cloud sync.
Stop searching chunks. Traverse knowledge.
Give your AI a typed graph with hybrid retrieval and provenance — built on markdown you own. Solo €12, Pro €24, Teams €49. 14-day trial, no card.