When the Knowledge Base Meets the Outside World
Utopia’s trust model is tested most sharply at its boundaries: when a database supplies data, when an agent asks for knowledge, or when an auditor takes the record elsewhere. This chapter examines those interfaces as different kinds of authority. It explains why a schema mapping is configuration rather than a world fact, why an agent token can narrow but never widen a person’s rights, why memory writes wait for a human nod, and why an export preserves lineage without claiming to be a complete compliance archive.
External data needs alignment, not a new kind of fact
A mounted database does not speak the same language as a document-derived graph. Its tables and columns describe storage, while the ontology describes classes, attributes, and relations that Utopia can use across sources. The tempting shortcut is to represent a mapping as an ordinary fact: a concept is “mapped to” a table or expression. That shortcut makes the relationship visible quickly, but it gives configuration the wrong status. It places a database calculation in the ontology, exposes it to ordinary extraction, and invites readers to mistake an editable implementation choice for an assertion about the world.
Utopia separates the mapping into its own configuration and revision flow. A mapping can be listed, revised, confirmed, and audited without entering the fact ledger. The distinction is practical. A person may change how a business measure is computed because a table was renamed, a unit was corrected, or a definition was clarified. That change is not a new historical event involving the business entity. It is a change in the way this deployment reads its data source, and it needs a revision history suited to configuration rather than bitemporal world knowledge.
The newer exploration design, documented but not fully implemented, makes the boundary more explicit. Instead of creating generic entities called “Metric” or “Dimension” for column names, exploration proposes an alignment for each table. It asks what class the table represents, which columns are attributes or relations, and what conversion turns a source column into the corresponding ontology value. A wide table may contain order attributes, customer attributes, shop attributes, and foreign-key relationships all flattened together. Alignment is the act of putting those columns back into their semantic owners.
A schema document can remain searchable so that chat and exploration can retrieve its descriptions. It should not be extracted like an ordinary business document, because then column names can become graph entities and the graph can fill with objects that stand for no real-world thing. This is a useful separation of paths: the same schema material can inform a query without being asserted as a set of people, organizations, or concepts.
In the documented target design, the proposed alignment would be adopted as a unit. Accepting a table’s class while rejecting every attribute and relation would not represent a meaningful business decision; the table is useful only through the structure that makes its columns interpretable. The alignment would be able to introduce new ontology terms through the existing proposal and adoption path, but it would not silently write the ontology merely because a model found a plausible name. A person remains the authority for the semantic change.
In that design, conversions belong inside the alignment as structured expression trees. A source amount might need a unit conversion, a coded channel might need a case expression, and a timestamp might need truncation to a reporting period.