AIP's Context Graph: Palantir's Decision Architecture
Most enterprise AI programs measure themselves by how much data they have indexed. That is the wrong scoreboard once agents start taking action on your behalf, because an index tells you what a system knows, not why it acted. Palantir’s AI Platform, AIP, is built around a different unit of value: a context graph that captures the reasoning behind a decision, not just the data that fed it.
If you are evaluating AIP, or trying to replicate its approach on another stack, the architecture is worth understanding on its own terms.
What is a context graph, in one sentence
A context graph is a decision aware layer that sits on top of an enterprise’s data model and records the inputs, policies, and outcomes behind every action an agent or operator takes, so that later decisions can be grounded in verified precedent instead of a fresh guess. It answers “why did we do this” in a form a machine can query, not just a form a human can read after the fact.
The ontology is the foundation, not the feature
A context graph has nothing to reason over until the enterprise’s systems share a common vocabulary. Palantir builds that vocabulary through the Foundry ontology, a semantic and operational model of the business rather than a data catalog.
- The semantic layer. Tools such as HyperAuto map data from source systems, SAP and Oracle among them, into objects, properties, and links that mirror real entities: an aircraft, a patient, a supply chain node. This is what lets a person or an agent reason about “the aircraft due for maintenance” instead of a join across four tables.
- The kinetic layer. The ontology also defines action types and functions, the governed write paths back into source systems. This is the detail that separates an ontology from a semantic layer that only reads: every object can be acted on, and every action is typed and auditable.
This distinction matters for architecture decisions, not just terminology. A read only semantic layer can support search and summarization. A model with governed write actions can support agents that actually change system state, provided the write path itself is constrained and logged. That constraint is what the context graph is built to capture.
Decision traces: how reasoning becomes data
The ontology captures what is true right now. The context graph captures why an action was taken. The mechanism connecting the two is what Palantir calls a decision trace: a structured record written every time a human, an agent, or a combination of the two takes an action inside AIP.
A decision trace typically holds:
- The specific inputs referenced at decision time.
- The policies and constraints that were evaluated against the action.
- Any human override or exception that was granted, and by whom.
- The observed outcome once the action played out.
Treating this as first class, queryable data is the actual innovation. Most platforms log actions as an audit trail meant for compliance review after an incident. AIP treats the same record as an input to the next decision: a searchable body of precedent that an agent can retrieve before acting, not only a forensic record inspected after something goes wrong.
Ontology augmented generation: grounding the model in operations
Standard retrieval augmented generation grounds a language model in document chunks. That helps a model answer questions about text, but it does nothing to help a model act correctly inside a business process, because a document chunk cannot tell you whether a proposed action violates a constraint.
Palantir’s answer is what it calls ontology augmented generation, OAG. AIP Logic equips the language model with deterministic ontology tools, forecasting models, optimizers, and the action types described above, rather than asking the model to reason about a problem from raw text. If an agent needs to resolve a parts shortage, it does not compose a plausible sounding answer. It calls a verified forecasting or optimization tool inside the ontology, and the result is what the model reasons over next.
This is the practical difference between a model that produces a fluent answer and a model whose answer is checkable against the same systems of record the business already trusts. For any enterprise weighing an agent deployment against a compliance or safety bar, that distinction is usually the deciding factor, not the model’s raw capability.
The stack, layer by layer
Read bottom to top, each layer is what makes the one above it trustworthy. Source systems have to exist before HyperAuto can map anything. The mapped semantic layer has to exist before the kinetic layer has objects worth acting on. Decision traces cannot accumulate until actions are actually being taken, and a learning loop has nothing to learn from until traces exist. Only then does AIP Logic have precedent to reason over, and only a human review gate turns that reasoning into an approved, governed action.
Two things stand out once the stack is drawn this way. First, the ontology is really two layers, not one: a semantic layer that names the business’s objects, and a kinetic layer that defines what can be done to them. Second, the context graph is also two layers: decision traces are the raw record, and the learning loop is the separate mechanism that turns that record into something an agent can retrieve as precedent. Collapsing either pair into a single box, which most vendor diagrams do, hides the part of the architecture that actually does the governance work.
How the pieces fit together
The loop closes on itself. Source systems feed the ontology. The ontology gives AIP Logic tools to ground a decision. The decision produces a trace. Traces accumulate into the context graph. The context graph, in turn, becomes an input the next decision can query as precedent. That closed loop, not any single component, is what makes the architecture durable: it keeps producing structured reasoning data as a byproduct of normal operation, rather than requiring a separate effort to capture it.
Provenance and the learning loop
Grounding a decision in tools is necessary but not sufficient. An operator still has to be able to audit what an agent did and why, especially before extending it more autonomy. AIP provides this through analysis provenance, a directed graph showing every step an agent took to reach a conclusion. This is what lets a reviewer trace a recommendation back to the ontology objects and functions it actually used, rather than trusting a summary the model wrote about itself.
As decision traces accumulate, they form what Palantir describes as a learning loop. Because the traces capture human overrides and the rationale behind them, they preserve a form of tribal knowledge that would otherwise live only in the heads of a few senior operators. When a similar case recurs, the agent can retrieve the earlier trace, including the override, rather than proposing the same action a human already rejected. Over time, this is the mechanism that lets more of a workflow move from human review to automated execution, on a case by case basis rather than a wholesale switch.
What this means for an enterprise architecture
None of this is free. An ontology of this depth requires real investment in data mapping and governance before an agent produces its first useful answer, and the write back action layer needs the same change control discipline you would apply to any system that can alter production state. The trade off is a context graph that gets more valuable as it accumulates traces, rather than a chatbot that resets its usefulness with every session.
For architects weighing this against a simpler retrieval augmented generation stack, the decision criteria come down to three questions.
| Question | Favors a plain RAG stack | Favors an ontology and context graph approach |
|---|---|---|
| Does the agent need to take governed actions, not just answer questions | No | Yes |
| Does the business need an auditable record of why a decision was made | Occasionally | Consistently, for compliance or safety |
| Is there an existing semantic model of the business to build on | Not yet | Foundry ontology or equivalent already exists |
A narrow question answering assistant over a document set does not need this architecture. An agent authorized to reallocate inventory, adjust a schedule, or recommend a clinical next step does, because the cost of an ungrounded or unexplainable action in those settings is not a bad answer. It is an operational or safety incident.
Key questions
Q1) What is the difference between the Foundry ontology and a context graph?
The ontology is the semantic and operational model of the business: objects, properties, links, and the governed actions that can change them. The context graph is built on top of the ontology and records the reasoning behind decisions, through decision traces, so that precedent can be searched and reused.
Q2) How is ontology augmented generation different from retrieval augmented generation?
Retrieval augmented generation grounds a language model in retrieved document chunks. Ontology augmented generation grounds the model in deterministic tools, forecasting models, optimizers, and action types defined in the ontology, so the model’s output is checkable against the systems of record rather than being a synthesis of retrieved text.
Q3) Do we need a full ontology before we can use decision traces?
Decision traces depend on having typed objects and governed actions to reason over, so a minimal ontology needs to exist first. It does not need to cover the entire enterprise before it is useful. Most AIP deployments start with the objects and actions for one workflow and expand the ontology as more workflows are onboarded.
The broader shift here is from model centric AI, where the answer’s quality depends on prompt engineering and model choice, to context centric AI, where the answer’s quality depends on how well the surrounding system captures operational truth and precedent. Palantir’s context graph is one way to build that system. Whether you adopt AIP itself or build an equivalent on your own stack, the underlying architecture question is the same: can your agents point to why they did what they did, in a form you can query, and not only a form you can read after something has already gone wrong.
If you are working through a similar architecture decision, I would be glad to compare notes on where the ontology investment paid off and where it did not.