Overview

The Knowledge Graph is Fontana’s agent-native knowledge engine: you store, version, and govern the operational knowledge your agents need (firm rules, mappings, approval criteria, exception history, process documentation) and agents retrieve approved, cited context on each turn instead of re-stating the same logic in every chat. You organise documents in namespaces and folders, assign each agent the corpora it may search, and Fontana builds a graph that combines full-text search, structural document outlines, a typed entity graph, and vector similarity, all in one governed store per namespace.

What is the Knowledge Graph?

A namespace-scoped knowledge engine for operational context: your source documents live on the workspace filesystem, and Fontana derives a governed graph (chunks, outlines, typed entities, embeddings) that agents query through hybrid search, outline tree-walk, or entity navigation, always with path citations back to source.

Knowledge Graph

Build a knowledge graph to model your firm's standards, rules, and decisions.

How Fontana Knowledge Graph compares

The table below compares Fontana Knowledge Graph against widely used GraphRAG engines and frameworks on the dimensions that matter for governed, agent-facing retrieval. Competitor rows describe published capabilities as of this writing; Fontana rows describe what you get in your workspace today.

Dimension	Fontana KG	Graphiti (Zep)	PageIndex	Microsoft GraphRAG	LightRAG	LlamaIndex property graph	Neo4j GraphRAG
Graph overlays	Lexical, structural (PageIndex-style outline), domain (typed entities), and vector overlays on one graph per namespace	Temporal entity graph with vector and full-text search; no structural outline overlay	Structural outline tree only; vectorless by design, no entity graph	Entity graph plus hierarchical community summaries and vector embeddings; no structural outline	Entity graph with vector embeddings in a dual-level retrieval design; no structural outline	Property graph with optional vector embeddings you attach yourself; no built-in structural outline	Property graph with vector and full-text indexes you configure yourself; no built-in structural outline
Ontology governance	strict / log / evolve policies you choose per namespace, plus bring-your-own ontology import (LinkML, SKOS, mapped OWL subset)	Prescribed and learned Pydantic entity types; no named off-schema policy modes	No typed ontology	Open-ended LLM entity and relationship extraction; no formal schema import	Open-ended LLM entity and relationship extraction; no formal schema import	SchemaLLMPathExtractor supports strict or permissive schemas in code; no standards-based import	Schema-guided extraction pipelines you configure in code; no standards-based import
Provenance / citations	Quote-span evidence on every mention, plus path citations (namespace/path › Section › Subsection, pages)	Facts carry provenance to their source episode	Tree node and page-range citations from the outline	Community and text-unit references; not quote-span level	Chunk-linked evidence for extracted entities and relations	Relations link back to source chunks	Retrievers return chunks or paths from Cypher queries
Cost governance	Pre-parse and post-parse cost and time forecasts, with per-namespace budget caps that hard-stop metered lanes	Not published	Not published	Community tooling can estimate tokens; no built-in pre-spend forecast, and exhaustive extraction is reported at 20 to 100 times vector-RAG indexing cost	Not published	Not published	Not published
Temporal / as-of	Document effective dates, relation validity windows, and first-class collections with as-of retrieval and conflict policies	Bi-temporal fact validity (valid_at / invalid_at) is a headline feature	Not applicable; no fact typing	Not native	Not native	Not native	Not native
MCP surface	First-party /mcp server on the engine, namespace-ACL enforced and fail-closed	First-party MCP server (episode, entity, and search tools)	First-party MCP server	Not published by the core project	Not published (REST and Ollama-compatible API instead)	Not first-party; you wrap retrieval as an agent tool yourself	Community MCP servers exist; not shipped by the core package
Incremental per-file reprocess	Content-hash reprocess per file, extract-stale marking when ontology changes, chunk-hash extraction dedupe	Continuous episode ingestion without a full rebuild	Not documented for multi-document corpora	update / append command; can still trigger community re-summarization	Native incremental update with selective deletion	Library-level; you implement incremental logic	Library-level; you implement incremental logic
Deployment model	Per-tenant in-cluster pod (kg-engine) with per-tenant FalkorDB; one deployment per workspace	Self-hosted (Docker with Neo4j or FalkorDB) or Zep’s managed cloud	Self-hosted CLI/library, hosted API, or private and on-premises	Self-hosted library/CLI against your own compute and graph store	Self-hosted server (Docker) with pluggable storage backends	Embedded library inside your own application	Embedded library against your own Neo4j instance
UI	KG Studio: Structural Graph, Document Graph, Domain Graph, Document Similarity Graph, Ontology Graph, document tree, and reader	Zep offers a managed console; the open-source project ships no UI	Hosted chat platform UI; the open-source project is CLI/library only	None built in	Web UI with graph visualization included	None built in	None built in

This is not a claim that every competitor lacks value: Graphiti and LightRAG in particular ship real incremental-update and temporal capabilities worth studying. Fontana’s position is combining structural, lexical, domain, and vector overlays with ontology governance, quote-span provenance, pre-spend cost control, and a namespace-ACL MCP server in one governed workspace, rather than requiring you to assemble and operate those pieces yourself.

What you get

• Namespace boundaries keep regulated corpora segregated; each agent searches only the namespaces you assign it, so retrieval stays least-privilege and focused on the domain you intend.
• Fast partial ingest: a file becomes keyword and outline searchable in seconds, hybrid vector searchable within the embedding lane’s throughput, and typed-graph complete only as far as your extraction budget goes. See Processing lanes.
• One graph, four overlays: lexical, structural, domain, and vector views over the same Falkor property graph, not four separate databases. See Graph overlays.
• Governed retrieval: hybrid search, outline tree-walk, and entity navigation, all with path citations and per-agent injection modes. See Retrieval.
• Ontology you control: bring your own schema or let Fontana propose one from your corpus, with strict, log, or evolve policies for anything outside it. See Ontology.
• KG Studio: linked views for the Structural Graph, Document Graph, Domain Graph, Document Similarity Graph, Ontology Graph, document outline, and reader. See KG Studio.
• An MCP server: agents and future external clients reach Knowledge Graph retrieval through a namespace-scoped Model Context Protocol server. See MCP.
• Collections and temporal scoping: regulated, versioned corpora stay separated with effective dates and as-of retrieval. See Collections and temporal.
• Domain extractor modules: content types with exploitable structure, such as code, get algorithmic graph extraction instead of paying for LLM calls. See Code and mixed corpora.

Architecture at a glance

Knowledge Graph splits into a control plane (Convex: your source files, jobs, preferences, and ontology) and a data plane (kg-engine: parsing, indexing, embedding, extraction, and retrieval against a per-tenant FalkorDB). Convex never runs Knowledge Graph processing, so your workspace stays responsive at any corpus size. See Architecture for the full picture.

Knowledge Graph namespaces

Knowledge Graph documents are organised in three levels: a namespace (top-level corpus boundary), a slash-path folder within that namespace, and individual documents addressed by path. In Flow at Knowledge Graph, you create, rename, and delete namespaces from the sidebar. The memory namespace and platform-source namespaces (agents, threads, tools, mcp, workflows, skills) are system-managed and cannot be renamed or deleted.

KG and Skills share the same workspace filesystem explorer in Flow (upload, rename, move, download, drag-and-drop). Knowledge Graph uses an amber accent; Skills uses sky. File bytes live in one classified store; Knowledge Graph processing metadata overlays Knowledge Graph sources.