The Enterprise Doesn't Have One Ontology

The Enterprise Doesn't Have One Ontology

August 14, 2026Jeremy Fand

Everyone suddenly wants an enterprise ontology, and it makes sense. AI needs more than access to data. It needs to understand what the data represents, how things relate to one another and enough about the business to reason across it. Knowledge graphs, semantic layers and ontologies are rapidly becoming part of the enterprise AI architecture for exactly this reason. But there is a problem with the idea of the enterprise ontology: the enterprise doesn't have one ontology. It has hundreds of them.

A well is a geological object to one person, a producing asset to another, a regulatory entity to someone else and a financial investment to another. A distribution center looks completely different depending on whether you work in logistics, inventory, real estate, risk or finance. None of these representations is wrong. They are different views of the same world, created for different purposes, and large organizations are full of them.

For decades, people have quietly connected these worlds for us. Experienced employees know that something in one system is the same physical thing described differently somewhere else. They know which source to trust, which definition applies to a particular question, where the exceptions are and who to call when a problem crosses domains. A remarkable amount of enterprise knowledge lives in those connections rather than in the data itself. AI doesn't inherit any of that simply because we connect it to more data.

This is where we think enterprise AI architecture needs to evolve. Instead of trying to force an entire organization into one canonical model of reality, different domains should be able to maintain their own models while we connect the meaning between them. At SeerAI, we think of this as a graph of graphs.

Imagine a distribution center represented simultaneously in a facility graph, a transportation graph, an inventory graph, an asset graph, a weather graph and a financial graph. Each knows something important about the same physical place, but no single graph contains everything we might need to know. Now imagine a storm approaching. The weather graph knows the storm and the facility graph knows the distribution center. They may have been created by completely different organizations, use different schemas and have no explicit relationship at all, but they suddenly become related because they occupy the same place at the same time.

From that intersection we can move into the transportation graph and find the trucks headed toward the facility, then into inventory and the products they are carrying, then to the customers waiting for those products, alternative routes through the network and ultimately the financial consequences of a disruption. A question that begins as "Which facilities are at risk from this storm?" quickly becomes "What depends on those facilities, who will be affected, what alternatives do we have and what should we do?" No individual database or graph was designed to answer that entire question. The intelligence emerges in the edges between the graphs.

Enterprise technology has spent decades getting better at federating data. We can query across databases, connect APIs, virtualize datasets and increasingly access information without continually copying it into another giant repository. That solves an important problem: where is the information and how do I get to it? AI introduces another problem: what does the information mean, and how does that meaning change as I move from one domain to another?

A graph of graphs can represent what something is, how it relates to other things, which systems know about it and where the underlying evidence can be found. The actual imagery, sensor history, transactions, documents and operational records don't have to move into the graph; they can remain in the systems built to manage them. The graph carries the context necessary to find and interpret that information when it is needed.

This is an important distinction in how we built Geodesic. The knowledge graph doesn't need to become another copy of the enterprise's data. It can point through to the data while preserving the context around it. When multiple graphs describe different parts or different interpretations of the same world, Geodesic can preserve those representations rather than forcing all of them into one enormous schema. The problem becomes understanding how those representations connect. That is what we mean by federating meaning.

There is another part of this architecture that becomes increasingly important as AI moves into the physical world: almost everything happens somewhere and sometime. Factories, wells, stores and distribution centers have locations. Shipments move. Equipment changes state. Weather develops. Satellites observe places at particular moments. Supply chains are constantly moving through physical networks.

Space and time therefore create relationships between information that may never have been explicitly connected. The weather system doesn't need to know anything about the supply-chain ontology to discover that a storm is approaching a distribution center. Location and time create that edge. Once it exists, AI can traverse through the other graphs to understand what that intersection means for the business, moving from weather to facilities to assets to shipments to customers and ultimately to operational or financial consequences.

This is why we don't think of geospatial intelligence as a separate category of enterprise data. Space and time are often how different representations of the world discover each other. That becomes especially powerful when the questions haven't been anticipated in advance, because the relationships required to answer them may not exist explicitly in any source system.

Large AI models are already remarkably capable at reasoning over the context we give them. The enterprise problem is increasingly deciding what that context should be. As agents move beyond searching documents and generating summaries toward reasoning about operations, infrastructure and the physical world, they need a way to navigate the organization's understanding of reality. They need to move from a facility to an asset, from the asset to its history, from the facility to the environment around it, from a disruption to a shipment and from that shipment to the customer waiting for it.

We don't believe that requires creating one perfect ontology of the enterprise. It requires making the organization's many representations of reality interoperable while preserving where they came from, what they mean and the underlying data that supports them. That is increasingly how we think about Geodesic at SeerAI: a representation layer capable of connecting graphs, ontologies and underlying data across an organization while preserving the different ways its people and systems understand the world.

We have spent decades learning how to federate data. The next challenge is learning how to federate meaning.

Enterprise AIKnowledge GraphOntologyGeodesicAI InfrastructureContext LayerData FederationSpatiotemporalDecision Intelligence

Ready to transform how you work with data?

Book a demo or explore our technology to see SeerAI in action.

A monthly newsletter for people building at the edge

We cover emerging tech, global dynamics, and strategic systems — no filler, just signal.