The Fork in Enterprise Ontology: An Analytical Semantic Layer, or a Software Execution Platform?

When an enterprise architect says, "We're going to build an ontology," what do they mean? This seemingly simple question has produced two nearly unrelated answers over the past decade or so: on one side, an analytical semantic layer that makes data and metrics explainable and correctly computed; on the other, an operational ontology that lets business objects be safely read and written by software and drives state change. Both are called "ontology," yet the former grew into the foundation of BI and data analytics, while the latter grew into a software development and runtime platform. Understanding this divide matters more than memorizing any vendor's product list.

1. What Ontology Originally Meant: Making Machines Reason, Not Query

Ontology in computer science and knowledge engineering is descended from philosophical ontology, but it took on a highly technical character as information systems adopted it. Tom Gruber's classic definition is that an ontology is "an explicit specification of a conceptualization." A "conceptualization" here means a systematic abstraction of the entities assumed in a domain, their properties, the relations among them, and the axioms that logically constrain them.

Through the 1990s and 2000s, the W3C's Semantic Web vision formalized this into RDF, RDFS, and OWL. In this lineage, ontology has two core capabilities. The first is deductive inference grounded in description logics: automatically deriving new logical truths and classifications from a formalized knowledge structure. The second is the open-world assumption: information that is not described is treated not as "false" but as "unknown." In other words, the goal was never to retrieve data, but to place knowledge into a system that can reason over it automatically.

2. After It Entered the Enterprise: Why Strict Axioms Never Reach Production

Academic research pursues strong reasoning and universal knowledge sharing; industrial enterprise IT has to pay for availability. Applying OWL's strict axiom system wholesale to a real corporate data foundation produces three direct consequences: a surge in computational cost, degraded transaction performance, and a rigid schema that is hard to evolve. The ideal is complete, but the price is unaffordable.

So "ontology" in enterprise information systems was reinterpreted and split into two major currents.

The first current is the analytical semantic layer that emerged from the evolution of business intelligence (BI), data warehouses, and data lakehouses. It hides the join relationships of physical relational tables and distributed storage behind the scenes, and centrally manages the calculation logic and dimensions of business metrics (KPIs), projecting a consistent "meaning" onto analysts and reporting tools. It answers the question, "How exactly is this number computed, and is the definition consistent across the company?"

The second current is the operational ontology, whose main purpose is executing business operations and building custom applications. It abstracts real-world business entities into digital objects with behavior, treating state transitions, transactional consistency, and bidirectional write-back to external systems as one whole, and serves as the backend for software development. It answers the question, "Can this business action be executed safely, how is it persisted afterward, and how is it written back to other systems?"

On the evolutionary axis of the former sit the data platforms of Databricks, Google Cloud, and Microsoft; the representative of the latter is Palantir. These two paths are not shallow and deep versions of the same thing; they are a divergence in design goals.

3. Palantir: Turning Ontology into a Distributed Object Runtime

The Ontology offered by Palantir (Foundry and AIP) is fundamentally different from the semantic layer provided by ordinary data warehouses or BI tools. In the official architecture it is defined as the "Operational Layer for the organization." In the words of the company's 10-K and design specifications, where a conventional ontology stops at "systematic contextual mapping of data," its own Ontology "integrates the data, logic, and actions involved in decisions into a foundational representation of the enterprise."

Its design intent is to build a dynamic digital twin of the enterprise. It sits above physical datasets, virtual tables, and machine learning models, and reifies real-world entities—production lines, aircraft, maintenance parts, customers, suppliers—as "objects." For Palantir, then, ontology is not a static graph for visualizing data but a dynamic execution environment for "making decisions and feeding the results back into the business."

Nouns and Verbs: Static Semantics and Dynamic Behavior

The internal structure of the Palantir Ontology is organized as a model analogous to "nouns" and "verbs" in natural language. This maps onto the conceptual structure of object-oriented programming (OOP) and domain-driven design (DDD) in software engineering.

The nouns—the static semantic elements—come in four kinds. Object types are schema definitions for real-world entities or events; properties define their attributes. Link types hold one-to-one, one-to-many, and many-to-many relationships between objects as a graph structure. Interfaces are an abstraction layer that enforces a common behavior and data shape across multiple different object types—essentially the interface pattern from software design.

The verbs—the kinetic elements—consist of action types and functions. Functions are calculation logic written in TypeScript or Python that take objects or object sets as input and compute derived values or perform validation. And it is the action type that lifts Palantir from a pure data foundation into a software development platform.

Actions, Transaction Boundaries, and Side-Effect Control

In Palantir, an action is defined as "a single transaction that changes the properties of one or more objects based on user-defined logic." An action type tightly binds four components:

• Parameters: typed input values; an object itself can also be received as a parameter.
• Rules: specify the basic operations of creating an object, modifying an existing object, deleting, and creating or deleting links; complex logic calls a function.
• Submission criteria: business validation performed before the action runs, blocking illegal state changes that violate business policy before the transaction even begins.
• Side effects: external integration processing executed when the action commits, such as sending a notification or calling a webhook.

Its transaction boundary and data persistence approach are distinctive. When a user runs an action, the change is not written directly back to the source dataset backing the object. The change command first enters a queuing and indexing service called the "Object Data Funnel," then is recorded with low latency into the index and writeback dataset within the object database (Object Storage v2 or Phonograph). This guarantees millisecond reads and writes at the object layer without contaminating the source data used for analytics.

To keep consistency with external core systems, "writeback webhooks" run before the object change inside the Ontology. Only after the API call to an ERP such as SAP or a CRM such as Salesforce succeeds is the object update inside Foundry committed, maintaining a practical form of distributed transactional consistency between the external system and Foundry. By contrast, "side-effect webhooks" handle best-effort processing asynchronously after the action runs, allowing fault-tolerance design to match business requirements.

OSDK: Making Foundry a Headless BaaS

The decisive reason Palantir is seen as a development platform is the existence of the Ontology SDK (OSDK). OSDK extracts the type definitions needed by a particular application boundary from the centrally modeled Ontology and auto-generates fully type-safe client SDKs for TypeScript, Python, and Java.

In traditional enterprise development, developers had to configure database connections, set up an ORM, write SQL/REST wrappers, and implement access control separately. In an architecture that adopts OSDK, Foundry itself acts as a headless BaaS: frontend developers simply call the generated type-safe APIs, while authentication, authorization, row- and column-level security, transaction validation, and audit logging are applied behind the scenes.

Above that, everything from Workshop for low-code business apps, to Automate for event-driven workflow automation, to AIP Logic for connecting LLMs directly to typed objects and actions, uses the Ontology as a shared runtime object model. In other words, Palantir's Ontology is not the endpoint of analytics but a "distributed object-oriented operating system" for assembling enterprise software quickly and robustly.

4. The Three Big Clouds: Where Ontology Lives Today

If you do not count the "analytical semantic layer" as ontology, you will misread the cloud vendors' products. Their ontology capabilities point almost entirely toward analytics and grounding.

Databricks: Unity Catalog Semantics and Genie Ontology

Databricks' path starts from governance metadata on a lakehouse architecture and extends it toward natural-language analytics and agent grounding. At the core are Unity Catalog Semantics and Genie Ontology.

Unity Catalog Semantics adds human-centered business logic to the tables and views in the catalog. Metric views define KPIs (aggregate values and analytical axes) as reusable SQL objects and expand the SQL dynamically at query time, ensuring that different analytics tools produce identical results. Domains logically group data assets by business organization or purpose; Pages record authoritative definitions of business terms, becoming the correct context that AI tools reference; certification and deprecation flags make explicit which data assets the organization officially vouches for.

Built on top of this human-modeled layer is Genie Ontology. It is a unified context resolution engine that supplies business context to Databricks Genie (the natural-language analytics agent). It is not merely a static dictionary: it dynamically infers and weights context from actual usage—query logs, join history between tables, usage frequency—using an algorithm called Ontorank.

But Databricks' ontology is essentially a semantic foundation for "advanced read-only analytics" and "improving Text-to-SQL accuracy." Primary and foreign key constraints managed by Unity Catalog often remain informational only, and no application execution layer for transactional action execution, side-effect control, or data write-back—as in Palantir—is built in.

Microsoft: From Azure Digital Twins DTDL to Fabric IQ Ontology

Microsoft's ontology work is a fusion of two lineages: one from IoT and spatial modeling, the other from data analytics centered on Power BI and Fabric.

Historically, it centered on DTDL (Digital Twins Definition Language), created for IoT and smart buildings, and modeled the relationships and telemetry of physical assets on Azure Digital Twins. DTDL can define not only telemetry, properties, and relationships but also commands, giving it a partly operational character from the standpoint of IoT device control.

The latest enterprise data platform strategy now rests on the "ontology (Ontology item, preview)" in Microsoft Fabric IQ. Fabric IQ is a workload for building a semantic model of the business on OneLake: it defines entity types, properties, and relationships separately from physical tables, and enables reuse through inheritance and namespaces. The ontology definition itself holds no data; it is virtually bound to a Lakehouse, Warehouse, or Eventhouse in OneLake, or to a Power BI semantic model. It can directly inherit DAX measures defined in an existing Power BI semantic model as ontology metrics, and when multi-hop path exploration is needed, it projects the query to the Fabric Graph execution engine.

Through integration with Fabric Activator, the Fabric IQ ontology can define some operations-leaning actions, such as firing alerts based on condition checks. But as an overall system architecture, it is overwhelmingly "a layer that provides business context for analytics and visualization engines and Data Agents." Physical data persistence and transaction processing are left to lower-level storage; the ontology itself does not directly serve as a stateful backend for custom applications.

Google Cloud: LookML, Knowledge Catalog, and Spanner / BigQuery Graph

GCP's ontology-like approach does not ship a single unified product called "Ontology"; it is composed of a loosely coupled combination of an analytical semantic layer, metadata governance, and native graph database technology.

The centerpiece of the analytical semantic layer is Looker's LookML. It declares dimensions, measures, and relationships as code and dynamically generates SQL—the original semantic layer—and is positioned as the control foundation for grounding generative AI such as Gemini in business metrics.

On the governance side, the former Dataplex has evolved into Google Knowledge Catalog, handling unified management of technical metadata, a business glossary, data quality rules, and lineage.

More advanced relationship modeling is provided by Spanner Graph and BigQuery Graph. They support the ISO GQL international standard (Graph Query Language) and can apply a property graph model directly to relational data. One notable design pattern, proposed in advanced cases such as Yahoo, is a dual structure: use Spanner Graph to record operational truth, and use BigQuery Graph as the context graph that accumulates decision history and audit lineage.

So GCP provides extremely solid infrastructure components—a distributed transaction engine, a data warehouse, semantic BI—but there is no application-layer ontology framework that unifies the "behavior of business objects" and "write-back transactions." Integration is left to each adopting company's own development.

5. A Structural Comparison of the Two Ontologies

Laying the vendors' concepts side by side reveals a philosophical fault line running through the foundations of data architecture between the analytical and operational ontology.

An analytical ontology gives meaning to "data at rest" in a data warehouse or data lake. Its concern is consistency of calculation logic (making the definition of "revenue" the same across the company) and the efficiency of query generation. Data flow is essentially one-directional—from storage to dashboards, or as prompt context for an LLM—and read-only by assumption.

An operational ontology, by contrast, targets "state mutation" in the business and closed-loop control of workflows. It integrates the aggregate data held by the data warehouse and the transactional data held by core business systems such as ERP and CRM into objects, immediately reflects the decisions (actions) made by users or agents as state, and writes them back to external systems.

The difference in data flow is plain. An analytical ontology places a virtual semantic layer over physical data stores, dynamically expands it into SQL at query time, and is consumed one-directionally by BI, reports, and LLMs. An operational ontology is different: data is not only synced from core systems and physical stores into the object layer; when an application or AI agent executes a transaction against the action layer, it is immediately reflected in the object layer through the Funnel service and simultaneously written back bidirectionally to external core systems via webhooks, forming a closed loop.

CQRS and the Persistence of Decisions

Shift to the lens of software design theory, and Palantir's distinguishing feature is that it implements enterprise-scale CQRS (Command Query Responsibility Segregation) at the platform layer.

The analytical semantic layer handles only the optimization of the "query (read model)" side of CQRS. Palantir separates queries (low-latency search and aggregation via the Object Set Service) from commands (writes and side-effect execution via the Actions Service and Funnel) completely, assigning each an optimized storage and validation pipeline.

Even more striking is its idea of "decision capture / decision lineage." In a traditional data foundation, a person looks at an analytics dashboard, makes a judgment, communicates it by email or manually keys it into a core system, and the contextual information—"what data context was this decision based on?"—is lost. In an operational ontology, every action goes through the Ontology, so the decision's parameters, the actor, the version of the objects referenced, and the resulting state change are recorded as an inseparable audit log (the Action Log) and accumulate as a data asset for retraining.

6. In the Age of Generative AI and Agents: Scaffolding for Cognition and Safe Hands

The rise of generative AI and autonomous agents has actually expanded the reason for ontology to exist. A standalone LLM cannot understand business context (it hallucinates), nor does it have a safe means of exerting side effects on the outside world. In this context, the analytical and operational ontologies play complementary but distinct roles for agents.

The analytical ontology (such as Databricks Genie Ontology or Fabric IQ) serves as the agent's "scaffolding for cognition and reasoning" (grounding context). When an agent receives a business question, Unity Catalog's metric views and Pages intervene, so that instead of fabricating inaccurate SQL on its own, it can generate an accurate answer using formulas and join conditions the organization endorses.

The operational ontology (such as Palantir AIP) provides the agent's "safe hands" (tool use / action space). If an agent is to decide autonomously—say, to place an additional order with a supplier to prevent a stockout—allowing it to issue UPDATE statements against the raw database or call APIs without limit carries catastrophic system risk. In an operational ontology, what is exposed to the agent is only an action type with preconditions, type definitions, authorization checks, and approval policies built in. The agent can do nothing but fill in the action's parameters and submit, so safety is structurally guaranteed.

Progress in Interconnection via MCP

As standard open protocols such as Anthropic's MCP (Model Context Protocol) spread, efforts to connect each platform's ontology to agents are advancing. Palantir officially offers "Palantir MCP," letting local development environments (IDEs) and AI agents call Ontology object search and action execution as tools through OSDK. Microsoft has likewise introduced "Fabric IQ Ontology MCP," aiming for an architecture in which Microsoft Copilot Studio or external agents can reference ontology definitions across OneLake. In enterprise systems, the decoupling of the upper agent runtime from the lower semantic/action foundation is accelerating.

An Architecture Selection Matrix for Enterprises

When an enterprise designs its data and AI foundation, which ontology to adopt—or how to combine them—depends strongly on the organization's problem domain and target system requirements.

7. Conclusion

That the ontologies offered by Databricks, Microsoft, and Google Cloud look like data analytics, while Palantir's looks like a software development platform, accurately captures the difference in system design philosophy and target domain behind each foundation.

The cloud vendors' ontologies are essentially an extension of the "analytical semantic layer." Their role is to give a unified semantics (dimensions, measures, relationships) to the data in siloed, massive data warehouses and lakehouses, and to support—read-only—SQL generation, standardization of BI reports, and contextual grounding for LLM reasoning.

Palantir's Ontology, by contrast, goes beyond concept definition. It fuses state-change transactions, precondition validation, writeback webhooks to external core systems, and a type-safe code generation toolchain (OSDK) into an "operational ontology" that is effectively an enterprise application execution platform. It is not a static lens for "looking at" data but a distributed runtime for "driving" business objects from software.

In enterprise systems where generative AI and autonomous agents are becoming established, the boundary between the two is being partially bridged through standardization such as MCP, but the core functional difference—static query optimization versus dynamic transaction execution—remains clear. What enterprise architects must do is distinguish between "an ontology for aligning the meaning of words and supporting analysis and reasoning" and "an ontology for safely assembling the software that runs the business"—two different design intents—and choose the architecture that matches their requirements.