Utopia: A Bitemporal Knowledge Graph That Treats Time as a First-Class Citizen

What Utopia Actually Solves

Most knowledge graphs and vector stores capture a snapshot of the present. Utopia starts from a different premise: an enterprise needs to know not only what is true, but when it became true, when the system learned it, and how that understanding changed over time. The README calls this a bitemporal knowledge graph, and it is the project's core differentiator. When a decision is reviewed later, the system can show the full course of reasoning and the grounds it rested on. That matters for regulated industries, internal audits, and any agent whose decisions must be explainable after the fact. Utopia is not a library or a plugin; it is a complete application with a web UI, an ontology workbench, and a graph browser. The intended user is an enterprise that wants a self-hosted knowledge foundation on hardware it controls, not a developer looking for a component to embed.

The Bitemporal Mechanism

Utopia's design centers on two timelines. The first records when a fact was true in the world. The second records when the system came to believe it. The README explains that correcting a fact closes the old version and links the new one to it rather than overwriting. This is the opposite of the typical update-in-place approach in relational or graph databases. Every fact carries a validity interval and a provenance source. The consequence is that the graph never forgets a previous belief, which is exactly what you want for auditing an AI's decision trail. The ontology is not an afterthought; it sits in the base layer. Axioms such as transitivity, symmetry, and inverse relations compile into forward-chaining rules that derive new facts. Derivation is off by default because a wrong axiom produces wrong facts, a sensible safety choice. Derived facts are marked as such, carry confidence values, and show their derivation chain. When a derived fact contradicts an asserted one, the asserted fact wins, though the README is cut off before explaining the exact conflict resolution logic.

Architecture: One Binary, One Postgres

The deployment model is deliberately minimal. One Rust binary and one Postgres instance. Full-text search is embedded in the binary via Tantivy, vectors go into pgvector, and the job queue is a regular database table. There is no separate search engine, vector database, or message broker to operate. That is a strong operational advantage for a self-hosted system. The data flow starts with ingestion: files like PDF, DOCX, PPTX, XLSX, CSV, Markdown, and HTML are uploaded, with legacy encodings detected on the way in. Web pages, RSS, GitHub, Jira, Notion, WebDAV, and S3-compatible buckets sync on a schedule. Everything else comes through the API. Extraction then turns documents into entities and facts, guided by an ontology you can edit. The system console, graph browser, and ontology workbench live in one web UI, so an administrator can manage the whole pipeline without leaving the browser.

Getting It Running: Commands and Config

The README does not include a full quick-start command sequence, but it does state that the system is distributed as a container on GHCR under deeplethe/utopia. The badge suggests you can pull that image and run it. The project is built with Rust and uses Postgres as its only external dependency. You will need a Postgres instance with pgvector enabled, since vectors are stored there. The web UI is served by the binary itself, so after starting the container and pointing it at a database, you access the console through a browser. The official site is utopia.bi, which likely hosts the detailed quick start. The README mentions that any OpenAI-compatible endpoint works for chat and reasoning, including DeepSeek, Qwen, GLM, Ollama, and vLLM. That means you can configure an endpoint URL and API key, and the system will use it for extraction, entity resolution, and agentic RAG. The entire system can run air-gapped if you point it at a local model server like Ollama or vLLM.

Ontology Packs and Cold Start

A new knowledge base starts with no vocabulary of its own. Utopia addresses this with ontology packs you pick at creation. Five ship inside the binary: schema.org, W3C Org, PROV-O, FOAF, and IOF Core. These cover general entities, organizations, provenance, people, and manufacturing or industrial concepts. Terms outside the packs are counted as they appear in documents, and you can confirm the common ones to add them to the ontology. This is a pragmatic cold-start strategy: rather than forcing you to define every class and relation from scratch, the system proposes terms based on frequency, and you curate them. The limitation is obvious. If your domain is niche, such as maritime insurance or clinical trial data, the bundled packs will not cover it, and you will spend significant time building your own ontology. The README invites users to request new industry packs via GitHub issues, but that is a slow path for a production deployment.

Entity Resolution and Review Queue

Duplicate entities are a classic problem in knowledge graphs. Utopia resolves them in three stages: exact match on name or alias, then embedding similarity, then a model's judgment on doubtful pairs. Every merge can be undone, which is a good safety property. Uncertain cases go to a review queue, which includes low-confidence extractions, suspected duplicates, and cardinality conflicts. The review queue is a human-in-the-loop mechanism, meaning the system does not claim full automation. A human must periodically work through the queue to keep the graph clean. The README does not specify how the queue scales or whether there are batch operations. This is a genuine operational cost. For an enterprise with high document volume, the queue could become a bottleneck. The system's ability to handle this depends on the quality of the extraction model and the threshold settings, which are not documented in the available material.

Limitations and Failure Modes

Utopia is at version 0.1.0-rc5, which means it is pre-release software. The README itself notes that derivation is off by default because a wrong axiom derives wrong facts. That caution extends to the whole system: if your ontology is poorly designed, the bitemporal graph will faithfully record your mistakes. Another limitation is the dependency on a model for extraction and entity resolution. While the system can run with local models, the quality of the knowledge graph depends heavily on the model's performance. The README does not mention any benchmarking or accuracy numbers, so you cannot predict how well it will extract facts from your specific documents. A further constraint is the absence of a homepage in the repository metadata, though the official site is utopia.bi. The README is truncated, so details on conflict resolution, API endpoints, and the agent harness are incomplete. For a project that aims at enterprise trust, this documentation gap is a real barrier to adoption.

Alternatives and the Palantir Comparison

The README explicitly asks not to frame Utopia as an open-source Palantir, yet the comparison is inevitable. Palantir's Foundry is a closed-source platform that also handles ontology, knowledge graphs, and decision support. The key difference is that Utopia is open source under Apache-2.0 and deploys entirely on your own hardware, whereas Foundry is a commercial SaaS or on-prem product with a different licensing and cost model. Another alternative is a combination of a vector database like pgvector with a graph database like Neo4j, plus a standard RAG pipeline. That approach gives you flexibility but requires you to build the bitemporal layer yourself. Utopia's advantage is that bitemporality is baked into the storage and query layer, not added as an afterthought. A third alternative is using a time-series database for temporal facts, but that would not give you the ontology or the entity resolution. For teams that only need semantic search over documents, a plain vector store is simpler and cheaper; Utopia's complexity is only justified if you need the full temporal and ontological model.

Maintenance, License, and Upgrade Cost

The project is licensed under Apache-2.0, which is permissive for commercial use and modification. The repository is not archived, and the last push was on 2026-09-09, with release candidates coming out every few days in early September 2026. That cadence suggests active development, but it also means the API and data model may change between release candidates. Upgrading from rc3 to rc4 to rc5 might require migration steps, though the README does not document them. The project is written in Rust, which has a steep learning curve if you need to modify the source. The operational cost is low because there is only one binary and one Postgres, but you must maintain the database schema and run the review queue. The documentation is thin, so you will likely need to read the source code or ask questions in the GitHub discussions. The official site utopia.bi may contain more, but it is not linked in the repository metadata. For a production deployment, you should plan for a learning period and budget time for contributing fixes upstream if you hit bugs.

Editorial conclusion

Adopt Utopia if your organization needs a self-hosted, ontology-driven knowledge base that can reconstruct the history of its own beliefs for audit or compliance, and if you can tolerate early-release roughness. Do not adopt it if you need a mature, battle-tested platform or if your team lacks Rust and Postgres expertise. Before committing, verify the current state of the review queue, the completeness of the ontology packs beyond the five shipped, and whether the bitemporal model meets your specific audit requirements. The project's last push and release cadence show active development, but v0.1.0-rc5 is not a final release; treat it as a prototype with a promising core.

Official sources

1. deeplethe/utopia on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases