DEV Community

Cover image for Utopia keeps the facts it used to believe
Reno Lu
Reno Lu

Posted on

Utopia keeps the facts it used to believe

The interesting part of utopia is not that it builds a knowledge graph from your documents. It is that correcting a fact does not overwrite its old version. When a fact gets corrected, the old version is closed and the new one is linked to it, so the graph keeps a record of what the system believed before it changed its mind.

That choice connects several of the project's core features, and it is the useful lens for judging whether utopia fits your problem.

Two timelines in the graph

The README calls the core structure a bitemporal knowledge graph. Extraction turns documents into entities and facts, guided by an ontology you can edit. Each fact carries two things beyond its content: when it held and where it came from. Corrections produce a chain of versions instead of a replaced row. The result is two timelines side by side: when something was true in the world, and when the system came to believe it.

The authors frame this with the history of astronomy. Ptolemy's model was taken for truth for a long time before Copernicus, Kepler, Galileo and Newton falsified it step by step, and they say the part worth keeping is how that shift unfolded, not only the final answer. Vector stores and ordinary knowledge graphs, in their telling, work to get present knowledge right. Utopia aims to record the path.

That shows up in the query tools. The built-in agent can ask for an entity's facts as of any date, or ask what changed in a given period. Edges are reified, so a relationship carries attributes of its own, which matters when the relationship itself is what changed.

How contradictions are handled

A store that keeps old beliefs needs rules for when new material disagrees. The README spells out three kinds of conflict. A new fact that clashes with an older one: close the old, keep both, or reject the new. Data that breaks an axiom, such as a self-loop, an asymmetry violation, a transitive cycle or a cardinality breach: retract the fact, relax the axiom, or accept both. The ontology itself gets checked first, since violations of a self-contradictory ontology are noise.

Derived facts follow the same discipline. Ontology axioms compile into forward-chaining rules for transitivity, symmetry, inverses and relation hierarchy. Derivation is off by default because a wrong axiom derives wrong facts. When it is on, a derived fact is marked as derived, carries validity and confidence, shows what it came from, and yields to an asserted fact if the two contradict.

Duplicates go through three stages: exact name or alias, embedding similarity, then a model's call on the doubtful pairs. Merges can be undone. Low-confidence extractions, suspected duplicates and cardinality conflicts land in a review queue, and the README says the decisions people make there are recorded and used to tune the agent.

Confirming a fact, merging or reverting an entity, rebuilding the graph: each writes to an append-only decision ledger that records who acted, when, and what the object looked like at the time. A ledger record outlives its object, even the knowledge base it belonged to.

Starting from an empty base

A new knowledge base has no vocabulary of its own. You pick ontology packs at creation, and five ship inside the binary: schema.org, W3C Org, PROV-O, FOAF and IOF Core. Terms outside the packs are counted as they appear, and confirming the common ones adds them to the ontology.

Material arrives as uploads (PDF, DOCX, PPTX, XLSX, XLS, ODS, CSV, TSV, Markdown, HTML or plain text) or scheduled syncs from web pages, RSS, GitHub, Jira, Notion, WebDAV and S3-compatible buckets. Search fuses Tantivy full-text and pgvector results with RRF, and chat answers carry inline citations that open the source passage. You can also mount a database such as Postgres, MySQL, Snowflake or Databricks; the agent proposes how its tables map onto the ontology and you confirm. Each knowledge base gets its own MCP server exposing the same read-only tools.

Running it today

The footprint is one Rust binary and one Postgres, with the job queue kept in a table. With Docker installed, clone the repo, bring it up with Docker Compose using the app profile, open the app at localhost port 1516 and register. The first account becomes administrator, and a public knowledge base is created alongside it. Before extracting business documents, configure the chat and embedding endpoints in the administration models settings. The README says any OpenAI-compatible endpoint works, including Ollama and vLLM, which lets the whole system run air-gapped.

Read the status section before committing to it. The project is at v0.1, schema migrations only roll forward, and the README asks you to pin the image version and back up the database and data directory before upgrading. Two limits matter for the temporal pitch specifically. A connector currently rounds timestamps to a UTC day, which can shift an event across midnight; finer precision sits on the roadmap. And the decision features the philosophy section leans on, recording a decision and replaying what was understood at the time, are marked as in development. The fact history exists now. Replaying decisions over it does not yet.


GitHub: https://github.com/deeplethe/utopia


Curated by Agent Palisade — practical AI for small and mid-sized businesses.

Top comments (0)