Utopia Deconstructed: Tracking Knowledge Changes with Dual Temporality and Provenance

What Utopia Actually Does

Utopia positions itself as an "enterprise world model." After reading the implementation, the author interprets it as an application that can both query documents and continuously organize and maintain the knowledge within them. It provides document import, retrieval QA, graph browsing, an ontology workbench, an audit queue, and external APIs. The ontology acts as a set of business definitions: object types, relationships, attributes, and constraints. For example, Contract and Supplier are object types; "signed by" is a relationship; payment term in days is an attribute. The ontology also declares whether the same payment condition can have two different terms simultaneously.

Utopia retains RAG (retrieve-then-generate) capability. Full-text and vector search run together and results are merged. If no embedding model is configured, full-text search works alone. The system then judges whether multiple documents refer to the same object, whether different phrasings map to the same business concept, and when a change takes effect. Uncertain cases are escalated to humans.

Store Original Statements First, Then Organize into Business Facts

Utopia separates raw statements, business definitions, and organized results into three layers:

Open Graph : Entities, raw relationship phrases, qualifiers, temporal words, and citations from documents. Example: "Payment within 30 days after acceptance" sentence and its source.

Ontology : Object types, relationships, attributes, definitions, and constraints. Example: Contract, PaymentCondition, PaymentTerm, and Unit.

Typed Graph : Structured facts organized according to the ontology. Example: A specific contract has a payment term of 30 days under the relevant condition.

"Typed" means mapping document phrasing onto explicit business definitions for easier querying and validation.

Directly prompting a model with the ontology seems simpler, but documents rarely follow the predefined schema. Faced with ambiguous expressions or missing definitions, the model may pick a "looks similar" relationship and drop qualifiers, producing structurally neat but semantically altered output. Utopia's approach: during extraction, keep the ontology out of the prompt; let the model record what the document says, then align those raw statements to the ontology. For instance, if a document calls an entity "Supplier," the system decides which ontology class it belongs to; relationship phrases are interpreted in light of the endpoint types. This step is called "alignment." Unaligned raw statements are preserved.

Automated alignment includes checks: partial bindings require two consistent model judgments; endpoint types and direction are validated. Once alignment is confirmed, typed facts are generated. If alignment later changes or a source record is invalidated, affected results are recomputed while raw statements remain.

Document statements that are plans, expectations, or conditional are flagged and not directly turned into typed facts. The system must first correctly identify such modality. The author endorses this separation: if the business definition is later found wrong, you can return to the raw statements and reorganize. The trade-off is added alignment, recomputation, and human maintenance effort.

Document retrieval and graph construction proceed independently. Users can search documents while background extraction and alignment continue, so searchable documents do not imply a completed graph.

Two Timelines, Answering Two Different Questions

Returning to the payment terms example. Assume the original contract applies a 30-day term from Jan 1, and a supplement changes it to 60 days effective Mar 1. The two documents are ingested and fact-organized on Jan 5 and Apr 10 respectively. Two distinct questions arise:

Based on current materials, what term applies on Mar 15? 60 days, because the supplement retroactively takes effect on Mar 1.

As of Mar 20, what did the system think applied on Mar 15? At that time only the original contract was in the system, so 30 days.

The second answer only reflects what materials the system held then; it does not prove the original clause was still valid in business terms.

This is what "dual temporality" separates:

When a fact holds in business, and when the system started recording it and later changed its record.

Queries use at to ask "on which business day" and as_of to ask "according to system records as of which day." The two conditions can be used independently or together.

Corrections typically invalidate the old record, add a correction record, and link the versions. Today's correction does not erase past versions.

Time parsing divides labor: the model interprets phrases like "next month" or "by a certain date," then code computes concrete dates and ranges. If no reliable anchor exists, the system refrains from computing rather than falling back to the upload date.

The model may still misread time, but "what the original text says" and "how the date was calculated" can be checked separately, making it possible to audit historical judgments.

New Statement Does Not Mean Old Fact Auto-Invalidated

If two documents give different payment terms, can we simply adopt the newer one? Not necessarily. They may apply to different regions, different payment conditions, or one may be a formal agreement while the other is a proposal. Material update alone does not decide which knowledge is valid.

If the ontology declares that a state can have only one value at a time, Utopia's temporal engine attempts to determine when the old value ends based on sequence. Ambiguous timing or remaining conflicts are left for human review.

The prerequisite is a correct ontology. If a contract has prepayment, acceptance payment, and warranty retention but the ontology defines only a generic "payment term," the system may treat parallel values as conflicts. The ontology helps check constraints but also amplifies wrong constraints.

Entity resolution follows the same principle. "Company A" and "Company A Procurement Dept" are not merged just because names are similar. The system judges whether they are the same object, keeping merge and undo logs. Before auto-merging, it checks for conflicts, impact on existing derivations or answers, and may delegate to humans. This is practical: even if a database merge can be undone, answers already delivered to users are not automatically retracted.

The project also supports deduction via axioms and manually defined business rules. Axioms declare relation properties (e.g., transitivity). Derived results are stored separately with provenance. However, derivability does not prove the premises are true.

How Agents Use This Knowledge

Utopia includes a built-in chat assistant and provides an MCP interface. MCP can be understood as a standard interface for external agents to call these capabilities.

External agents can query documents, read raw statements, query an object's facts, changes, and relationships, and read rules and rule-match results. Responses carry identifiers and evidence to support follow-up questions.

Permissions pass two checks: the access token (which libraries and operations are allowed) and the user's role within the library. Even if a token permits write, a read-only user cannot gain edit rights.

Agents can propose remembering content via remember. Extracted statements from such proposals are queued for human confirmation before entering the graph. "Record this text" and "endorse it as knowledge" are two distinct steps.

The built-in assistant can also query connected databases. Queries undergo SQL checks, row limits, and each engine enforces read-only or timeout measures. However, query_data is not exposed in the MCP toolset , so external agents cannot invoke the full capabilities of the built-in assistant.

After clarifying contract terms, who pays, who approves, deduplication, and reconciliation remain the responsibility of business systems. The execution gates in the source code mainly govern entity merges and similar knowledge changes; they cannot control arbitrary business operations.

Fewer Components, But Ongoing Maintenance Counts

The backend is primarily Rust, frontend React; full-text search uses embedded Tantivy, vectors go into PostgreSQL's pgvector extension, and background tasks are backed by a database queue. Basic deployment does not require separate graph databases, vector databases, or message queues.

This reduces pilot components, but bulk import, background extraction, and recomputation may affect online QA — load testing at target scale is still needed.

Model endpoints must be configured; scanned documents, images, or audio may depend on additional recognition services. Private deployment does not guarantee model calls stay on-premises; data flow depends on actual configuration.

Cost evaluation cannot look only at per-QA token consumption. Extraction, alignment, time parsing, correction, and recomputation all consume resources; unaligned content and disputed statements require human handling. The author evaluates processing time, model cost, what was missed, and human time together.

The project uses the Apache-2.0 license, facilitating evaluation and extension. Teams with existing ontologies or data governance platforms can adopt raw-statement retention, dual temporality, and change-audit mechanisms without a full replacement.

Real Business Integration Still Needs a Few Things

Putting your own materials in and measuring effectiveness requires testing. Reading the code reveals several limitations worth noting.

Citations still need manual verification. Extraction tries to locate the citation in the original text. When an exact match is not found, some processing paths do not block the statement from entering the graph: they record the match failure, keep the citation text, but cannot mark the source position. Therefore, seeing a citation marker still requires checking whether it can actually be found in the source. Even when matched, it only proves the document said it, not that the material is true or complete. Two consistent model judgments could both be wrong.

Old records are kept but may not be fully searchable. The full-text index mainly stores the current version. During historical queries, the system checks whether retrieved results were valid at that time, but some replaced old passages may never be retrieved at all. Dual temporality provides a place to store history. To fully reconstruct a past judgment, one must step through retrieval, evidence, rules, and the final answer.

Audit trails and permissions must hold at critical moments. The project uses database triggers to restrict modifications and deletions of audit tables, but some operations are allowed to proceed if the audit write fails. If the business requires "no commit without an audit record," one must verify whether business modifications and audit can commit together and how audit failures are handled. Knowledge-base permissions cannot replace the original business system's row- and field-level visibility. Which library a document goes into, whether cross-library search or export is allowed, and whose credentials are used when querying source databases must all be explicitly defined.

The author reviewed version v0.1; some documentation is out of sync with the implementation. Selection must record the exact version tested, not just the feature list. Backup cannot be just a database export; original files, indexes, and decryption keys must be retained, and an actual restore must be tested.

Which Knowledge Bases Are Worth Trying

If the use case is querying operation manuals or product documentation — stable content with little need to reconstruct historical judgments — a well-built RAG with retrieval, citation, and permissions may suffice. Adding a full governance pipeline just for a graph may not be cost-effective.

More promising are knowledge bases that frequently ask "at that point in time, which version applied?" Finance has many such needs, but suitability still depends on specific materials and query tasks.

Financial research, financial reports, and announcements : Same reporting period data may be corrected; need to revisit the version used during research. Key verification points: Reporting period, disclosure time, indicator definitions, and correction chains.

Bank credit and customer due diligence : Equity, guarantees, ratings change continuously; need to trace the situation at review time. Key verification points: Entity identity, material timeliness, sources, and historical versions.

Regulatory rules and internal policies : Publication, effectiveness, revision, and repeal may occur at different times. Key verification points: Applicable subjects, effective intervals, and old/new version relationships.

Contracts, policies, and product terms : Different versions, customers, or batches may have different conditions. Key verification points: Applicable scope, term changes, and original evidence.

Organizational appointments and project handovers : Same object may have multiple names; relationships change over time. Key verification points: Identity resolution, tenure intervals, and historical records.

Take a research knowledge base: a company issues its annual report in March, corrects a data point in April. Today's analysis needs the corrected data; reviewing a March research report requires retaining the original version and subsequent corrections, not silently replacing the analytical basis. At least three distinct times must be separated: the reporting period the data describes, the disclosure date of the material, and the date the knowledge base ingested and organized it. Two timelines cannot automatically replace all business times. Reporting period and disclosure date must be recorded separately; one cannot assume the market knew the information on the day the knowledge base received it.

Reviewing a historical research report also requires checking whether the material was already disclosed or obtainable at that time, whether the user had access rights, and whether the knowledge base had collected it, to avoid projecting later knowledge into the past. The earlier-mentioned gaps in old-material search must be included in acceptance test cases.

These scenarios are worth piloting. The system helps find evidence; investment decisions, credit approvals, and compliance conclusions still follow business processes by responsible people.

If the author were piloting, they would start with one contract and several amendments, intentionally adding materials with same names but different conditions, missing dates, late ingestion, or contradictions. First, verify whether the system answers clearly: what applies now, what was known then, which sentence is the evidence, and what remains unprocessed. Then correct a misalignment, undo a wrong merge, and check whether timelines, query results, and evidence change accordingly. After the pilot, if finding evidence and judging versions does not save much effort but adds a pile of audit work, the scope should be narrowed or a different approach chosen.

Enterprise knowledge changes, and our understanding of it changes. Utopia is noteworthy for attempting to preserve these changes, allowing people to keep asking: "Which version did you use, and why did you judge that?"

References and Source Code

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