Your company already has an ontology.

Ask an agent at a mortgage company how many clients went quiet last month. It will answer in about four seconds, with a number, formatted well. The question is whether it counted borrowers or brokers. Both are called clients. Nothing in the system is broken, nothing gets flagged, and the only person who can catch the error is someone who already knew the answer.

That failure has nothing to do with the model. It is a failure of definition, and it is the one that shows up everywhere once a company starts to actually rely on this technology rather than experiment with it.

Palantir has a name for the thing that is missing. They call it the ontology, and one of their forward deployed architects, Chad Wahlquist, defines it without much ceremony: the nouns and verbs of your business. The nouns are the things that exist — loans, borrowers, brokers, warehouses, exceptions. The verbs are what can be done to them. Written down, in a form software can read.

It is worth being precise here, because three words get used interchangeably and are not the same. A taxonomy is a hierarchy. A schema is tables and columns. An ontology is meaning, relationships, and rules together. Keith Helfrich, writing on this recently, called it a semantic contract rather than documentation, which is the right distinction. Documentation describes. A contract binds.

The reason this suddenly matters is narrow and specific. The models were not trained on your business. They were trained on the internet. They are extraordinary at language and they have no idea what your company means by “locked,” “escalated,” “client,” or “exception.” Worse, they are built to produce a plausible answer rather than to refuse. Helfrich puts the mismatch cleanly: models operate in a world of likelihoods, ontologies operate in a world of constraints. Fluency without grounding is not a small problem to clean up later. It is the thing that makes the output untrustworthy at exactly the moment you start trusting it.

Here is the part most operators miss, and it is the reason we are writing this one down.

You already have an ontology. Every company does. Yours is just not written anywhere. It lives in three people’s heads, in an unsearchable email folder, and in a spreadsheet called FINAL_Customer_Listv8.xlsx. And every time someone opens a chat window to get useful work out of an AI tool, they re-type a piece of it by hand — who the client is, which overlay applies, what the threshold is, why this one is an exception. They paste in the context, then judge whether the answer respected it.

That is the AI-Assisted trap, described precisely. A person is being the ontology. Manually, per prompt, at human speed, slightly differently every time. It feels like progress because the drafts come back faster. The business runs exactly as it did before, because the only thing that knows how the business works is still a person, and there is still only one of them.

AI-Native is the other side of that. The model of the business gets written down once, and the agents read it.

What gets written down is three things. The data, which is the current state of the business — what exists right now and how those things connect. The logic, which is how the company thinks about that state: the overlays, the pricing exceptions, the approval thresholds, the rules that decide what is normal and what needs a human. And the actions, which are what the system is permitted to do about it — write back to the loan origination system, open the exception, queue the outreach, escalate to the person who owns the call. Data, logic, actions. Wahlquist’s framing, and it holds up in every company we have worked inside.

Wahlquist also names the discipline that makes it work, and it is the part that is easy to get wrong: model how the business actually operates, not how the existing systems need it structured so they can function. Most data projects do the opposite. They inherit the shape of whatever software was purchased in 2014, and then everyone spends a decade explaining to new hires why the field is named that.

The failures worth avoiding are unglamorous and they compound quietly. Is a client the borrower or the broker. Is a loan “locked” the same thing in the pricing engine and in the LOS. When an underwriting overlay and a pricing exception disagree, which wins, and who is allowed to approve the override. None of these are hard questions. Every one of them has an answer that somebody at the company knows. But if the answer is not written down, every agent, every report, and every new employee is guessing — and they will each guess consistently enough to look right.

Palantir sells this as a platform. It is a good platform, and for the Fortune 500 the price is rational. For the operating companies we work with, it is not, and it should not have to be. The idea is not proprietary. You do not need to rent someone else’s platform to have a model of your own business.

This is what Cognition Mapping produces. We go department by department and get it out of people’s heads: the decision frameworks, the operational rules, the definitions nobody has ever had to say out loud because everyone in the room already knew. We structure it, we make it legible to agents, and we build it into your systems. It is documented, it is versioned, and you own it. When we leave, it stays, and every agent built after us reads from it.

Most companies are still asking which model to use. The model is the part you can swap out in an afternoon. The ontology is the part that takes real work, and it is the part your competitors cannot copy.

If you are trying to work out what this looks like inside your company, that is a thirty-minute conversation with one of the partners.