Build it with AI
Use the operating-system idea without pretending every company needs the same enterprise stack.
Translate the core idea—connected business context, decision surfaces, governed actions, and traceability—into focused software built around your company.
Introduction
What a Palantir-style operating system has to hold.
Most teams end up with a Palantir-style operating system the same way: a proposal for a data platform, and no agreement on the first decision it would improve. Dashboards over a warehouse are adequate while insight is the goal. They stop being adequate when the goal is action, because a chart has no idea what a customer is and cannot do anything to one.
The programme is scoped around unifying data rather than around a decision, so success has no definition. There is no model of the business entities and their relationships, no way to take an action against one from where it is observed, and no trace connecting an action to the state that prompted it.
What follows covers building a Palantir-style operating system: the records it holds (the entities the business reasons about, their relationships, and the decisions taken against them), the systems it reads (Business APIs and CRM), and what it does not fix.
The problem
The idea is right and the enterprise stack is not the point.
Warehouses model rows and columns and deliberately hold no semantics. BI tools chart what is loaded. Neither can express that this account is at risk, is owned by this person, and has these three actions available — which is what an ontology is for.
The records are the entities the business reasons about, their relationships, and the decisions taken against them, and the authoritative copy of most of them already lives in Business APIs or CRM. The warehouse table and the operational system agree until somebody acts in the operational system, at which point the analysis is describing a state that no longer exists.
The cost is not the inconvenience: a quarter of integration work delivers a model nobody has yet used to decide anything.
You're likely here because
- Analysis ends in a slide rather than in an action
- The programme is scoped around unifying data rather than around a decision, so success has no definition.
- When it is wrong, a quarter of integration work delivers a model nobody has yet used to decide anything
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Context-driven apps
- • Decision dashboards
- • Operational workflows
Operated through Grow
- • Revenue execution
- • Notifications
- • Follow-up
Systems it reads
- • Business APIs
- • CRM
- • Collaboration tools
The record model
What an ontology has to express.
- Entity with its relationships
- Not a table. The statement that these three accounts belong to one group, and that risk on one implicates the others, is what a schema cannot express.
- Available actions per entity
- Attached to the entity where it is observed. An ontology without actions is a data model with better documentation.
- Action precondition
- Defined on the entity and enforced, so an action cannot be taken against a state that does not permit it.
- Action trace
- Actor, state observed, downstream effect. This is what separates a governed action from an integration, and it is the basis of any governance claim.
- Permission derived from source
- Rather than granted afresh, so consolidating context cannot widen access as a side effect.
- Write-back path
- Explicit, because every write is a production change with a blast radius and should be designed as one.
- Scope boundary
- One entity, modelled properly. Ontology projects fail by scope, and they fail late and expensively.
How it runs
From data platform to an ontology you can act on.
Step 01
Describe what a Palantir-style operating system has to do
Model the entities, their relationships, and the actions available against each. That is the ontology, and it is what distinguishes this from a reporting project.
Step 02
Connect the systems of record
Operational systems supply the entity state and receive the actions. The ontology reads them and writes back through governed paths rather than holding a parallel copy.
Step 03
Build the operating surface
Decision surfaces over the modelled entities, with the available actions attached and every action traced to the state that prompted it.
Step 04
Start narrow
One entity, its relationships, and one action available from the surface where it is observed. The full ontology is what these programmes drown in.
Step 05
Route the exceptions
An action that falls outside its defined preconditions is refused with the reason, rather than executed and audited afterwards.
Step 06
Measure time from question to decision on that one workflow
Measure the share of analysis sessions that end in an action taken rather than a slide produced. It is the honest measure of whether this is an operating system or a reporting tool.
Implementation path
Taking the useful part without the programme.
- 01
Model one entity properly rather than the business broadly. Ontology projects fail by scope, and they fail late and expensively.
- 02
Baseline how many analytical outputs currently result in an action within a week. The number is usually small and is the argument for the approach.
- 03
Attach actions to the entity from the first version. An ontology without actions is a data model with better documentation.
- 04
Trace every action to the state that prompted it. Traceability is the property that makes governed action possible, and retrofitting it is much harder than building it in.
- 05
Build the narrowest useful version first: one decision, the data it genuinely requires, and nothing else.
- 06
Modelling one entity with its relationships and one action is three to four weeks and is the right first increment. Traceability has to be built in from the first action rather than retrofitted. Resist modelling the business — that ambition is what turns this into a programme that consumes years and delivers a model nobody has acted through.
- 07
Once one entity has actions attached and traced, add the second entity and the relationship between them. That relationship is where the approach starts paying back beyond what a good dashboard would have done.
Controls
Controls that matter.
Control 01
Action preconditions defined on the entity and enforced, so an action cannot be taken against a state that does not permit it
Control 02
Every action traced to its actor, the state observed, and the downstream effect, since this is what separates a governed action from an integration
Control 03
Permissions derived from the source systems rather than granted afresh, so the ontology cannot widen access as a side effect of consolidating it
Examples
Three things the ontology makes possible.
The analysis that ended in a slide
Attaching the available actions to the entity where it is observed removes the gap between noticing and doing, which is where most analytical value is currently lost.
The relationship nobody modelled
Modelling that these three accounts belong to one group, and that a risk on one implicates the others, is the kind of statement an ontology makes and a table cannot.
Why was this action taken?
A trace from an action back to the state that prompted it answers a question that is otherwise reconstructed from logs and recollection, and it is the basis of any real governance claim.
How it goes wrong
Three ways ontology projects drown.
The scope is the business rather than one entity, and the model arrives after the sponsor has left.
One entity, properly. Ontology work expands without discipline, and the expansion is always locally justified and collectively fatal.
A warehouse is built first, and what emerges is a reporting project with an ontology label.
Model by reading the operational systems directly. A warehouse is useful for history and scale later, and starting there produces analysis rather than action.
Write-back is added without preconditions, and an action is taken against a state that should have refused it.
Preconditions on the entity, enforced. Every write is a production change, and the discipline that makes writing back defensible cannot be added afterwards.
Limitations and considerations
What the comparison genuinely does not carry.
- The comparison carries the idea, not the scale. Most companies need one modelled entity with actions attached, and adopting the full programme shape is how the idea gets discredited internally.
- Ontology modelling is genuinely hard and expands without discipline. The failure mode is a beautiful model of the whole business that arrives after the sponsor has left.
- Governed action means every write is a production change with a blast radius. The traceability and the preconditions are not optional extras; they are what makes writing back defensible.
- If analysis already ends in action because one person does both, the ceremony adds nothing. If the appeal is the reference rather than the problem, that is a reason to be careful — the idea is worth copying and the programme shape is not.
- Connector coverage varies: Business APIs, CRM, Collaboration tools are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build a Palantir-style operating system: common questions.
What is actually worth copying from this approach?
Three things: modelling business entities rather than tables, attaching available actions to those entities, and tracing every action to the state that prompted it. The platform scale, the programme, and the price are not part of the idea.
How is an ontology different from a data model?
A data model describes structure. An ontology describes entities, their relationships, and what may be done to them — which is why it supports action and a schema does not.
Does an ontology require a warehouse underneath it?
No, and starting there tends to produce a reporting project. Model one entity by reading the operational systems directly; a warehouse becomes useful for history and scale later.
What is the most common way this fails?
Scope. Modelling the business rather than one entity produces a programme that consumes years and delivers a model nobody has yet acted through.
What should the first version contain?
One decision, the data it genuinely requires, and nothing else. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure time from question to decision on that one workflow against the baseline taken before anything changed.
Related pages
Keep exploring
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- 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
Build a Palantir-style operating system around the process you actually run.
Model one entity with its actions attached, trace every action to the state that prompted it, and leave the programme scale behind.