Palantir & AI operating systems
Understand the role of a shared business-object model in operational AI.
An ontology represents business entities, relationships, processes, and actions in a form applications and AI can use consistently.
Introduction
AI ontology for business in practice.
Every business already has an ontology. It is written down in six places, three of them spreadsheets, and the versions disagree. Someone in finance knows that "active customer" excludes accounts in their trial month; someone in support does not; the two numbers have never matched and everyone has stopped mentioning it.
The practical version of ontology work is not a modeling project. It is writing down what your shared terms already mean, agreeing the exceptions out loud, and pointing your software at the result. A company with a dozen employees can do the first useful pass in an afternoon.
This page is the vendor-neutral, do-it-yourself version: what the artifact actually is, how to produce one without a data team, how to tell whether it is working, and when the effort genuinely is not worth it. For what Palantir specifically means by Ontology as a product capability, that is a different question and a different page.
Common failure modes
- Model the business concepts that multiple workflows need to share.
- Point tools that separate data, applications, and actions
- AI initiatives that stop at answers instead of operational outcomes
The problem
Why the current approach stops scaling.
The cost of an undocumented definition is not confusion — people navigate that fine for years. The cost appears the moment you automate on top of it. A human reading a customer list applies the unwritten exception without noticing. A workflow does not, and it emails the accounts everyone knew to leave alone.
The second cost is that the knowledge is load-bearing and undocumented. The person who knows why the revenue figure excludes two account types is one resignation away from taking that with them, and the definition will then be reconstructed by guesswork from whatever the last report happened to do.
The third is quieter: because nobody has written the definitions down, every new tool arrives with its own. Each integration adds another interpretation, and the reconciliation work grows with the tool count rather than the business.
You're likely here because
- A number is regularly explained rather than trusted
- One person is the authority on what a core term means
- Each new tool arrives with its own version of the same entity
Workflow
How the work actually runs, step by step.
Step 01
List the nouns in your own sentences
Write down how you actually describe the business out loud — we send quotes to leads, jobs get scheduled, invoices go out. The recurring nouns are your entities, and there are usually five or six.
Step 02
Write one sentence per noun
A definition anyone in the company would recognise, in their words rather than a schema. If it takes a paragraph, the term is doing two jobs and should be split.
Step 03
Write the exceptions down, especially the embarrassing ones
The carve-outs are the whole point. "Active customer excludes the two legacy accounts we never migrated" is the sentence that stops an automation doing something stupid.
Step 04
Name an owner for each definition
One person who gets asked before it changes. Unowned definitions do not stay accurate; they drift silently and take the numbers with them.
Step 05
Point one workflow at it and watch
Pick a single automation, make it use the written definition, and treat every disagreement it produces as a defect in the definition rather than a bug in the tool.
Architecture
The layers underneath the workflow.
Step 01
A written document
Genuinely a document — a page per entity with the definition, the exceptions, and the owner. Not a database, not a graph, not a product you buy. Most companies never need more than this.
Step 02
A source mapping
For each entity, which system holds the authoritative record. This is the line that resolves arguments about which number is right.
Step 03
Permission notes
Who may see and change each entity, recorded next to the definition so any tool reading it inherits the same rules rather than inventing its own.
Step 04
Whatever reads it
Reports, automations, and AI workflows all pointed at the same page. The consistency comes from the shared reference, not from the format it is stored in.
Implementation path
What implementation looks like.
- 01
Book ninety minutes with the two or three people who argue about definitions most. That meeting is the project.
- 02
Write five entities, one sentence each, and stop. A first pass with fifty entities does not get maintained.
- 03
Record every exception someone raises verbally, including the ones that sound too specific to matter. Those are the ones automation gets wrong.
- 04
Put the authoritative source system next to each entity before anyone leaves the room.
- 05
Review it the first time a number is disputed, and treat that dispute as the review trigger rather than scheduling a quarterly ceremony nobody attends.
Controls
Controls that matter.
Control 01
One named owner per definition, with changes announced rather than made quietly.
Control 02
Exceptions recorded in the definition itself, not in the head of whoever wrote the workflow.
Control 03
A dated change history, so a number that moved can be explained by a definition change rather than investigated as a data problem.
Examples
Worked examples.
The ninety-minute version
A twenty-person services firm wrote six definitions in one meeting. The argument about what counted as a closed job took forty minutes of it and turned out to be the entire reason two dashboards had never agreed.
The exception that mattered
A written carve-out for accounts on a legacy plan stopped a renewal automation contacting customers who had been promised they would never be upsold. Nobody had thought to mention it because everybody already knew.
Naming things is the expensive part
The technical work of modelling an object is small. Getting three teams to agree what it means, who owns it, and which system is authoritative for it is the project — and it is a governance exercise wearing a data-modelling costume.
Limitations and considerations
Limitations and considerations.
- This is a writing and agreement exercise, and it fails for organisational reasons rather than technical ones. If two teams will not agree, no format resolves it.
- A definition document does not improve the underlying data. It makes wrong data consistently wrong, which is more useful than it sounds but is not a fix.
- Below roughly five people sharing a system, the overhead usually exceeds the benefit — the definitions live in one head and that head is available.
- Written definitions decay. Without an owner and a trigger to review them, the document becomes another stale artifact contradicting the live systems.
- A shared model is only worth what the agreement behind it is worth. Where teams genuinely need different definitions, forcing one produces shadow spreadsheets.
- Ontology work has no natural end. Without a first workflow constraining it, it expands indefinitely and delivers nothing observable.
FAQ
Questions people ask.
Why does AI benefit from an ontology?
A shared model gives AI consistent context about business objects, relationships, permissions, and allowed actions instead of forcing every workflow to reinterpret raw data.
Do we need special software for this?
No. A shared document with one page per entity is enough for most companies, and is what the first useful version looks like regardless of what you buy later.
How many entities should we start with?
Five or six — the nouns that appear in more than one workflow. A larger first pass reliably goes unmaintained.
Who should own the definitions?
The person who is already asked when a number looks wrong. Formalising what is happening anyway works better than assigning it to whoever has capacity.
When is this genuinely not worth doing?
When one person runs everything and no automation depends on the terms. The value appears when definitions are shared between people or consumed by software.
How much modelling is enough to start?
Enough for one workflow. A model grown outward from working software stays connected to reality; one grown from a whiteboard tends not to.
What is the most common mistake?
Modelling the organisation chart rather than the work. Objects that mirror departments produce a model that has to be rewritten the next time the company reorganises.
Product path
Where this runs inside UbiVibe.
ARIA holds the operating context, Launch turns the requirement into working software, and Grow carries the commercial execution against the same connected records.
Build with Launch
Turn the operating requirement into working software.
- • Object-based apps
- • Operational tools
- • Agent context
Operate with Grow
Keep the workflow connected after the interface exists.
- • Connect CRM, email, calendar, and pipeline context
- • Turn recommendations into bounded revenue actions
- • Keep outreach, meetings, pipeline, and attribution in one operating context
Connected context
Keep systems of record. Fix the gaps between them.
These are representative connections. UbiGrowth supports 700+ connections across business systems. Connection availability and permissions depend on workspace configuration.
Test the business case with your own operating assumptions.
Use the ROI calculator to model lead volume, close rate, deal value, and manual workload rather than relying on a generic outcome claim.
Open the ROI calculator →Start with ARIA
Put it to work on your own data.
Describe the outcome you want. ARIA establishes the operating context, selects the capabilities it needs, and runs the execution against the systems you already use.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Put ai ontology for business to work on your own data.
Start with ARIA to establish the operating context, then build the surface and run the execution against the systems you already use.