Palantir has spent two decades building this AI "hand"

Ontology, a language created for the enterprise world.

This term has been talked about so widely that anyone who follows enterprise AI or FDE can hardly avoid it. However, most people interpret it by looking backward from the present day.

To grasp it thoroughly, we need to shift our perspective and go back to the starting point more than 20 years ago.

01

The problems it was built to solve back then are everywhere in modern enterprises: the same customer is labeled as "XXX Co., Ltd." in the CRM system, "XXX Joint Stock" in the ERP system, and "XXX Group" in the warehouse system.

Different systems use their own naming conventions, which lead to mismatched statistics once data is aggregated. A more common scenario happens in meetings: the "customer" mentioned by the marketing department does not refer to the same entity as the "customer" mentioned by the finance department.

Both sides have their own reports, and neither side is wrong, but no progress can be made after the meeting.

Real entities that exist in enterprises are visible to humans but invisible to software, which only recognizes tables and fields that operate independently. This is exactly the problem ontology is designed to solve.

Their solution is to create a dedicated language for the enterprise world.

There are only three types of terms in this language: nouns refer to objects, such as customers, orders, well locations, and aircraft, all real-world entities that need to be registered; prepositions refer to connections; verbs refer to actions.

Abstract, right? To put it simply, we can just call them nouns, prepositions and verbs.

Creating a language is not a typical job for a Silicon Valley company. The CEO of Palantir, Karp, studied philosophy and obtained a doctorate, and the phrase "jargon" appeared in his dissertation title.

Let's start with nouns, that is, objects.

Open the software, and you will see dozens of tables with 100 rows of data. Ontology converts these 100 rows of data into 100 independent customer entities, each associated with its own orders and equipment.

This step seems trivial, but it is essentially a translation process. Computers store data in rows and columns, while the human brain perceives the world through individual objects and the relationships between them. This mismatch is named "impedance mismatch" by developers.

Ontology is designed to bridge this mismatch, so that software can re-register the world in the way humans perceive it.

The next part is prepositions, namely connections.

Nouns alone cannot form a coherent world. What is the relationship between a customer and its order? On which aircraft is a specific part installed? Which process should be followed to trace the root cause of an accident? None of these can be clarified without connections. Connections are in charge of defining which entity belongs to another and which entity depends on another.

Once this layer is established, the enterprise will become a traversable graph. When you query a part, you can trace its path all the way to the corresponding aircraft, supplier, and the alarm record generated the day before.

Nouns and prepositions make the world perceptible. The real watershed lies in the last type of term: verbs.

Many people have tried to model enterprises through different approaches such as knowledge graphs, indicator systems and semantic layers, which share similar end goals: to present the world for human observation.

A knowledge graph can tell you that a customer is associated with a company, which is further associated with its directors. But there is no follow-up action, the query stops here, and all these designs only go as far as the noun level.

Palantir took an extra step: it created verbs.

An action like "assigning an order to a driver" can be defined, triggered, and held accountable. When the action is executed, it will trigger a series of associated changes: when the warehouse receives the goods, it will affect inventory records, vouchers, and the production scheduling plan for the next day.

The significance of this statement can be better understood with another expression: you cannot model the action of "assigning an order to a driver" at the metric layer. There is a more direct sentence in the official documentation:

Ontology is not a semantic layer. It does not stop at making the data in reports consistent, but also ensures that tasks are completed effectively.

The most ambitious attempt of the previous generation was the Semantic Web, which aimed to integrate all the world's knowledge into one model to enable machine reasoning.

After more than ten years of development, it failed to gain widespread adoption. The most costly failure was IBM's Watson, which tried to expand into the healthcare and financial sectors but failed to gain a foothold. A consensus was reached in the post-mortem review: all these models can only be used for observation, not for actual operation.

There is another lesson to learn: the knowledge imported into the system does not match the actual workflow of medical workers.

The implementation of verbs comes at a cost: when you click a button on the model, a vehicle will set off in the real world, an order will be modified, and a production line will reduce its load. The operator needs to take full responsibility for these changes.

This is why many solutions only stay at the "observation" stage. If you want the system to perform actual operations, you must first answer a series of questions: who has the authority to operate? Who is responsible if an error occurs? Without clear answers, verbs cannot be implemented.

Therefore, rules must be established before verbs can be put into use.

Every action is bound to permissions: who can perform it? Under what conditions can it be performed? Every operation is also fully logged: who triggered it, at what time, so that it can be traced later.

There is another most critical rule: it reserves a position for human beings. The Cleveland Clinic in the United States uses it to schedule hospital beds across the whole campus. The system only outputs suggestions, and the final decision-making power rests with humans. The action will be executed only after human confirmation.

There is a half-joking saying in the industry: executives dare not take responsibility for AI's suggestions, let alone sign off on AI's automatic execution. This design is made to reverse this situation.

It does not rush to make decisions instead of humans, which on the contrary makes it safe enough to be applied in the most error-sensitive scenarios, such as hospitals, factories, and the Pentagon, where a single mistake may cost human lives or hundreds of millions of dollars. It has successfully taken root in these scenarios.

02

This language has been developed incrementally, with content added to it continuously, and the development process is still ongoing today.

Let me tell you a story:

In 2006, the company was only 3 years old, and it would take another 2 years to launch its first official product. A patent application was submitted in advance, with the term "dynamic ontology" in its title.

The name was established first. Naming seems like a trivial thing, but it actually sets a clear direction for the work of the next 20 years.

So what exactly is written in this patent? In plain terms, it aims to make the enterprise data model more flexible. Traditional enterprise software in the past had fixed table structures, which meant that the model had to be completely rebuilt once the business changed.

This patent states: We will adopt a new development method, where objects, attributes and relationships can be added or modified at any time without major overhauls.

At that time, the industry convention was the opposite: the model had to be fully designed at one time, and any modification would lead to huge engineering workload. Ontology took a completely different path: the system evolves synchronously as new business scenarios emerge.

The inventor list includes three names: Gettings, Jain, and McGrew. The first one is the co-founder of the company, and this application later became the foundation of all the company's products.

Later, some people checked the patent records and found that this patent family has been continuously extended, and new versions were still being authorized as of 2025. A dictionary has been compiled for nearly 20 years, with its first page written in 2006, when few people knew about this term.

But a well-defined term that no one uses is nothing more than a piece of paper. How to solve this problem? To solve this problem, you must go to the front line, to the actual business scenarios, right?

In 2010, a team of engineers was sent to a classified computer room. You can regard this as the most rigorous early assessment for the company. What did they do? They demonstrated this set of technologies to intelligence analysts.

The originally scheduled 2-week assessment turned into 14 consecutive working days, with 19 hours of work per day. They modified functions according to analysts' requirements during the day, and sent feedback back to the headquarters at night. No hands-free calls were allowed in the computer room.

The team leader, Sankar, tied the phone to his head with a rubber band, typing code with one hand, listening to on-site feedback with one ear, and listening to instructions from the headquarters with the other ear.

Two weeks later, the analysts said the system was useful. Sankar called the headquarters and said "This is not feasible, the workload is too heavy, we can't keep up". On the other end of the call, Karp laughed and said "Not feasible? Then what other way can it work?"

Alright, don't be impatient, the story has only just begun.

In the same year, another team was deployed to Balad Air Base in Iraq. They adjusted their work schedule to match the patrol teams. Soldiers took field laptops installed with this software when they went out on missions during the day, and submitted feedback after returning at night. While the soldiers slept, the engineers wrote code.

The next day when soldiers went out on missions again, the software had become a little more usable.

When they first arrived, some people in the camp murmured: Who are these kids? Why should we allocate beds for them? Two weeks later, the public opinion changed, and everyone said these people are as precious as gold.

A general recalled later that this team helped them map out the network for the first time, and they could clearly see how people, funds, weapons and drugs flow through the network.

What exactly was added to the dictionary? First, human entities: who is active where, and who they have talked to. Then physical entities: vehicles, weapons, funds. Then event entities: what time, what place, what happened. The entries are not fancy, but they are practical.

Believe it or not, the entries are compiled bit by bit in this way. A few years later, the dictionary went beyond the battlefield and entered industrial factories.

In Toulouse, the headquarters of Airbus, an A350 aircraft has 5 million parts, managed by hundreds of teams across 8 factories in 4 countries. Engineers first registered aircraft, parts, workstations, and teams into the dictionary one by one, enabling these teams to use the same unified language for the first time.

After that, the aircraft manufacturing speed increased by more than 30%. The system was also deployed in hospitals, where a set of systems ran internally for a full year to ensure stability before being publicly announced.

Run the system stably first, and then make it public. This is their consistent style, as well as the style of this dictionary.

Up to now, this dictionary has not been fully completed. For a period of time, it was called the semantic layer, and then the official definition was updated several times. The latest version is called "the decision-making hub for human-machine teams".

Last year, they added a new version of the dictionary that can be installed on mobile phones, and can be carried by drones and robots.

In September this year, it further cooperated with NVIDIA, applying this language to the AI supply chain, where decisions and results are all recorded back to the dictionary to become the input for the next iteration.

The dictionary is getting thicker and thicker, and the team responsible for writing entries has changed several generations. It only keeps growing and will never be fully published.

It has now been deployed in more than 50 industries, and it became a highly sought-after asset worldwide in 2023.

03

Why? Because AI emerged. Then people found that AI can talk about almost anything, but it gets stuck when it comes to actual work. Where is the problem?

The problem is that AI does not understand the jargon in specific businesses, nor does it understand the unwritten rules in the workflow.

It has little to do with how smart the model is. It knows the literal meaning of the word "customer", but does not know your specific customers. It has read hundreds of millions of documents, but has never seen the warehouse receipt in your warehouse today.

Some people imported the real enterprise database into the top large model, which contains tables with thousands of columns and hundreds of business questions. How many of the results are correct? Only 30%. For the remaining 70% of the results, the model can generate answers, but can you safely use them?

There are also more hidden problems: even if the model gives a correct answer, it only presents the result to you, and you still need to manually copy the result to the system for execution. The model only stays at the "talking" stage and cannot reach the "doing" stage.

Therefore, a powerful brain alone is not enough. AI lacks a hand between its brain and your systems. This hand must know what entities exist in your company, how entities are connected to each other, and what will happen after an operation is triggered.

For example:

You say "transfer this batch of goods to the out-of-stock stores first". After hearing this sentence, humans know which system to access, which document to find, and who to ask for approval.

AI will be confused after hearing this: it does not know which specific object "this batch of goods" refers to, what the standard for "out of stock" is, and what the specific action of "transfer" corresponds to.

What will happen if you force the model to execute? It will only generate a paragraph of text, and you still need to manually translate the text into system operations. Errors will inevitably occur during the translation process. If the translation cannot be done, the model cannot perform any actual operation.

This language is designed to solve exactly this problem. Karp once said that:

There are two most profitable business segments right now: one is computing power, and the other is the "application layer" he mentioned.

The application layer does three things: make large models safe, useful, and accurate. He has led his team to develop this system for nearly half of his life.

It is the "Intelligent Hub" of the enterprise world.

Interestingly, he is not the only one who holds this view.

After 2023, the entire industry has realized this. Microsoft launched its own operating ontology, and Snowflake and Databricks are also rushing to develop semantic layers. This has evolved from a unique technology of one company to a standard industry practice. This change indicates that the whole industry has recognized this path.

In the past year, the track has developed rapidly. Some companies embed the semantic layer into the data warehouse, some bundle it into office suites, and others even hire consulting companies to deploy the system for each customer one by one. The industry is extremely lively.

If you take a closer look, most solutions can understand the real world, but very few can actually operate the systems. Karp said on TV a while ago that everyone is copying this technology now.

In fact, from a deeper perspective, this is not just a matter for a single company.

Every company has its own "language problem". Looking back at the three different names for the same customer mentioned at the beginning of the article, you are very likely to encounter similar situations around you.

When these terms are inconsistent, machines cannot work properly, and neither can humans. Half of the meeting time is spent arguing about the definition of terms.

The "cost reduction" mentioned by the boss and the "cost reduction" mentioned by the procurement department refer to two different sets of actions; the "fault" mentioned by the production line and the "fault" mentioned by the after-sales department refer to two different severity levels.

Every company has hundreds of such terms, scattered in the minds of employees, without formal unified definitions