Ontology: A Modeling Mindset for Machine-Understandable Business Semantics

Recent hype around "ontology" in Chinese tech circles is largely driven by Palantir's AIP launch and its 2025 revenue of $4.475 billion (56% growth). However, Palantir did not invent ontology, and its success cannot be attributed solely to ontology. The real insight is that enterprises need an intermediate layer connecting LLM conversation to deterministic business action—handling business objects, rules, data permissions, system write-backs, and action accountability.

Data Already Aggregated, Why Agents Still Cannot Act

Traditional systems (data warehouses, data lakes, BI) solve data production, aggregation, and computation for human decision-making, not for AI understanding and execution. AI can read data but does not equal business understanding; it requires explicit semantics: objects, relationships, states, events, rules, actions, and permissions. Tables and fields carry information but rarely express them in a unified, linked way.

Example: contract review. Even with contract tables, customer APIs, approval logs, and policy docs integrated, an agent may not know which policy applies, what evidence supports a conclusion, or which actions require approval.

Without unified semantics , agents see fragmented tables, APIs, and documents; object relationships, rule applicability, and action boundaries must be inferred ad hoc. With unified semantics , agents can traverse "current contract → related customer → target clause → applicable policy → risk level → approval action" and retain data, rule, and evidence provenance.

The difference is not more data, but whether data can be understood and used within an explicit business semantic space.

Three Contexts of "Ontology" in Market Discourse

Current discussions mix three distinct contexts:

1. Philosophical & Computer Science context. Philosophical ontology questions existence, entities, categories. Computer ontology defines concepts, relations, attributes, constraints, rules within a domain. Semantic Web standards (RDF, OWL) focus on knowledge representation, sharing, logical reasoning—not business transaction or action execution.

2. Engineering product context. Palantir's Ontology maps underlying data to business objects and relationships, then connects actions, permissions, applications, and workflows. It is not a static knowledge graph but a productized combination of ontology thinking, data platform, and execution mechanism.

3. Marketing context. If a system merely adds business names to fields or renames knowledge graphs, master data, or metric platforms without object identity, relationship constraints, rule boundaries, action contracts, permissions, and version governance, the "Ontology" label does not make it an executable ontology platform.

Taxonomies, vocabularies, triples form semantic expression foundations; knowledge graphs carry entity relations. But to support agents, the semantic model must also connect state, rules, actions, permissions, and versions. These capabilities need not all live in the ontology model, but workflow engines, permission systems, and Agent Runtime must collaborate through unified business semantics.

Three Shifts in Modeling Mindset

From Existing Data to Business World

Traditional projects start with existing tables, fields, APIs, documents. Ontology thinking starts with what exists in the business world. Contract review requires defining relationships among contract, party, clause, obligation, risk, policy first, then identifying which data proves those business facts. Tables and fields become evidence for business objects and relations, not the modeling starting point. This is a shift from "explaining existing data" to "define business first, then map data back."

From Natural Language to Explicit Semantics

Policies and expert experience contain vague expressions: "major customer," "high-risk clause," "in principle not allowed," "special case escalation." Humans rely on context; machines need explicit definitions:

How concepts are defined;

How objects are identified;

Under what conditions rules take effect;

What preconditions and permissions actions require.

Natural language suits communication; for stable reuse by systems and agents, key semantics must become structured definitions and verifiable constraints.

From Human Default Understanding to Machine-Usable

"Machine-understandable" does not mean machine consciousness. It means the machine can operate within a clearly defined semantic space: identify business objects, link events/states/evidence, validate against rules, select permitted tools, and retain provenance for conclusions and actions. This is an engineering notion of understanding: not letting the machine freely interpret the world, but providing a controlled business coordinate system for machine operation.

How It Changes Data, Knowledge, and Agents

Ontology thinking creates continuous value in three directions:

Data governance shifts from managing tables/fields to governing business semantics, making data evidence of business facts;

Knowledge management shifts from storing documents to structuring knowledge, binding policies and experience to objects, conditions, and actions;

AI agents shift from generating answers to executing tasks within business semantics, constrained by rules, permissions, and action contracts.

Summarized as:

Data governance gives data semantics; knowledge management structures experience; AI agents turn semantics and knowledge into action.

From an enterprise AI architecture view, three layers:

Bottom: Data & Knowledge Sources → Middle: Business Semantic Layer → Top: Agents & Business Applications

The business semantic layer maps fragmented data to business objects/relations downward, and upward provides rules, context, and action constraints via semantic services and tool interfaces.

Ontology, OPM, and MBSE Are Not the Same

Once ontology is seen as a modeling mindset, its relation to MBSE and OPM in systems engineering arises:

MBSE emphasizes model-driven requirements, design, analysis, verification across complex systems;

OPM is a conceptual modeling method/language for MBSE, expressing objects, processes, and state changes;

Ontology modeling formalizes validated business knowledge into semantic assets.

Ontology modeling cannot replace full business/system modeling or handle all complex system modeling tasks alone. Other suitable modeling methods can be chosen. The key is to first clarify business objects, processes, states, rules, boundaries, then decide how to formalize and publish.

Ontology Modeling Cannot Be Detached from Business Scenarios

Ontology thinking does not mean building an enterprise-wide "grand ontology" upfront. A feasible path: start from concrete business scenarios—clarify task goals, study real processes, build business models, extract objects/relations/states/rules needing unification, map data/knowledge/tools, publish as agent-usable semantic services.

Models must be continuously validated in use. Rule changes, data adjustments, agent execution failures, human corrections expose model gaps, requiring version updates and regression testing. LLMs can assist concept/relation extraction but cannot replace domain expert validation.

Summary

Ontology is not a new technology born in the LLM era, nor merely knowledge graphs, triples, or ontology editors. It represents a modeling mindset: first define objects, relations, processes, states, rules, actions in the business world, then let data, knowledge, systems, and agents collaborate in the same semantic space.

This mindset can be summarized as: structured, formalized, computable.

The real change it brings is not adding another diagram, but moving software engineering from "business descriptions humans can read" to "business models both humans and machines can use."