Utopia’s Real Product Is Accountable Change

Utopia is an open-source enterprise knowledge substrate: a system that turns documents and other sources into searchable, time-aware, reviewable knowledge. This chapter asks what distinguishes that ambition from building a larger search index or adding a chat interface to a knowledge graph. The answer matters because enterprise knowledge is not static. A policy is revised, an organization changes, an extraction is corrected, and a decision made last quarter may need to be reconstructed from the evidence available at the time. This series follows how Utopia handles those changes, and what its design can—and cannot—make trustworthy.

The problem is not merely finding a plausible answer

Most knowledge systems are optimized for the present. A vector store retrieves passages that resemble a question. A knowledge graph organizes entities and relations that are believed to be current. Those capabilities are useful, but they tend to hide the path by which a statement became accepted and later changed. If a company asks who owned a project in 2024, “the current owner” is not a sufficient answer. If an auditor asks why a recommendation was made before a correction arrived, a clean graph of today’s facts is not enough either.

Utopia’s founding idea is therefore historical as much as computational. Its documentation uses the history of astronomy as a reference point: a model can be treated as true for a long time, then revised step by step as observations and interpretations change. The valuable record is not only the final model. It is the course of changing understanding. In software terms, that becomes a bitemporal knowledge graph: one timeline describes when something held in the world, and another describes when the system held that belief. A later correction is not a silent replacement. The previous assertion remains part of the record, linked to what superseded it.

Consider an ordinary operational change. A memo says that one team has taken responsibility for a project, while an older ticket names a different team. A current-only graph may retain the latest edge and discard the older one, leaving a future reader unable to tell whether the old assignment was once correct, misread, or simply superseded. Utopia’s model asks several separate questions instead: which source version contained each statement, how the sentence was interpreted, which entities the names identified, when the assignment held, and when the system learned of the change. Those questions are not extra annotations applied after the “real” graph is built. They determine what the graph is.

This changes the meaning of “trust.” Trust is not a confidence number attached to a model response. It is the ability to answer several questions about a claim: Where did it come from? Which vocabulary gave it meaning? Which entity did the system think the words referred to? When did the claim hold, and when did the system believe it? Was it asserted, proposed, or derived? Who accepted, rejected, merged, or corrected it? Utopia’s distinctive proposal is to keep those questions connected instead of handing them to separate tools.

The result is not an autonomous oracle. It is a system for making knowledge evolve without erasing the evidence of evolution.

One product, several responsibilities

Utopia is built as a complete application rather than a library assembled from independent services: one Rust binary and one Postgres database provide the core, with full-text search embedded in the binary, vectors stored through pgvector, and a table-backed job queue. That compact deployment shape matters, especially for organizations that need an offline or air-gapped knowledge foundation. But the important architectural point is not the number of processes. It is the relationship among responsibilities.

Sources supply material. Files can be uploaded, while web pages, feeds, GitHub, Jira, Notion, WebDAV, and object storage can be synchronized. Integration interfaces use stable identities so a changed item updates the same document and preserves earlier versions. A deletion is initially a marker rather than an irreversible disappearance. These choices give later extraction something more durable than the latest snapshot.

The ontology supplies the system’s working vocabulary. It tells extraction which classes, attributes, and relations are available, and can provide signatures that make the direction of a relation machine-checkable. A knowledge base can begin from an imported vocabulary pack, a user-provided ontology, or no vocabulary at all. Terms that do not fit are not automatically disguised as familiar concepts; they can remain visible as source wording or become proposals for later adoption.

The graph stores entities and facts with evidence and time. It is where a sentence becomes reusable structure, but not every observed sentence has the same status. A fact can have a recognized predicate, an unresolved predicate, a literal value, or a relation whose interpretation needs review. The graph also preserves corrections, merges, and reversions rather than treating them as housekeeping outside the knowledge model.

People govern the uncertain transitions. They can review low-confidence extraction, possible duplicate entities, ontology proposals, conflicts, and rule definitions. Reasoning operates over the resulting graph, but it is separated from the assertions it derives. Agents and external tools can search, inspect entities, ask temporal questions, and read changes through controlled interfaces. Auditors can export statements with their lineage. External databases can be queried alongside documents, but their mappings are configuration rather than claims about the world.

The important consequence is that each boundary has an owner. The source side owns document identity and versions. The ontology owns the vocabulary and declarations that extraction may use. The graph owns evidence-bearing assertions and their temporal life. Review owns decisions about uncertainty; the reasoning layer owns conditional conclusions; access interfaces own what a person or agent is allowed to read or propose. When these responsibilities are separated, a correction has somewhere to go. When they are collapsed, a model score or a mutable row ends up standing in for provenance, policy, and authority all at once.

The architecture can be summarized like this:

flowchart LR S["Sources and documents"] --> X["Ontology-guided extraction"] O["Ontology"] --> X X --> G["Bitemporal graph and evidence"] G --> H["Human review and governance"] H --> O G --> R["Consistency checks and derivation"] R --> G G --> A["Agents and search"] G --> D["External data and mappings"] G --> E["Auditor export and decision ledger"]

This is a map of dependencies, not a promise that every path is equally mature. A document may be searchable before its graph facts are extracted. An ontology may guide a model without being correct in every detail. A derived conclusion may be useful while remaining subordinate to an asserted fact. An agent may read a base without receiving permission to change it. The system’s meaning lies in these distinctions.

Trust is a chain, not a score

The design repeatedly chooses an explicit incomplete state over a confident fiction. When an extraction model encounters a literal that does not fit the known vocabulary, Utopia keeps the value and the original wording. When it encounters an entity relation with no accepted predicate, the predicate can remain empty rather than becoming a generic “related to” edge. The empty field is not a failure to model reality; it is an honest statement that the system has not yet earned a name for the relationship.

That choice also makes later improvement possible. A phrase that recurs across documents can become an ontology proposal, and a person can decide whether it deserves a relation and whether similar phrasings mean the same thing. The earlier observation is not thrown away while the vocabulary catches up. Conversely, a relation that was accepted under a mistaken interpretation can be corrected through an append-only path, leaving both the prior belief and the correction available to review. Change is treated as information about the system, not as an embarrassment to hide.

The same principle appears in identity resolution. Similar names do not automatically mean the same entity. Clear matches can attach to an existing entity, while ambiguous matches create a separate entity and enter review. The system prefers an extra node to a wrong merge because a merge moves facts together and can contaminate later answers. When people decide, their action can be recorded with a rationale and later used as precedent. Automation may still be held back when a merge would affect a contradiction, a derivation, or an answer already given. The goal is not to eliminate human judgment but to make the boundary around it legible.

Time adds another part of the chain. “When was this true?” and “What did we believe before the correction?” are different questions, so Utopia keeps world time and record time separate. Evidence, precision, and predicate semantics determine how a fact is read. A statement about an event is not automatically an interval that continues forever; an incidental date in a timeless relation should not become a false start date. These details are deferred to a later explanation, but their purpose is already clear: a claim that has the wrong temporal scope is not trustworthy merely because its text and entity names look plausible.

Reasoning follows the same discipline. The system checks the ontology and existing facts before materializing inferences. Derived facts live apart from asserted facts, carry their premises, and do not override them. If an inference conflicts with an assertion, it can be blocked and exposed as a clue about stale knowledge, a misread sentence, a wrong merge, or an over-strict ontology. A proof that leads back to source passages is more useful than a bare statement that a rule fired.

There are real limits. The repository identifies Utopia as v0.1. Incremental reasoning, complete historical full-text recall, historical proof snapshots, richer schema alignment, some connectors, and several agent or action capabilities remain open or partial. Some external engines have protocol-replay tests but still await a real-cluster run. The README’s broader decision-intelligence promise is still described as being in development, even as later decision records document substantial reasoning and governance work. The responsible reading is neither dismissal nor promotion: the project has implemented a coherent set of safeguards, but those safeguards do not remove the need to measure extraction quality, retrieval recall, ontology fit, permissions, backups, and operational scale in a real deployment.

That is the question this series carries forward. If a document is the beginning of a knowledge claim, how does Utopia let that claim become useful without pretending that its first interpretation is final? The next step is to follow the document itself—from ingestion and search readiness to background extraction, evidence, and the places where information is deliberately allowed to stop.

References