An adjuster logs in on a Monday morning and sees a queue: twelve open claims, sorted by severity, three of them flagged with a note - "possible pattern across this claimant's last four claims, review before approving." She opens the flagged one, sees the claimant, the policy, the related claims, the reasoning behind the flag, and takes an action. Ten minutes, maybe less.
That screen is the only part of the build she'll ever see. Everything underneath it - where the data came from, what it got turned into, what logic ran, where AI reasoning entered the picture - is invisible, and it got built in a rough dependency order that has nothing to do with how effortless the queue makes it look. The screen isn't the system. It's the surface of the system. I've rebuilt that shape enough times on Palantir Foundry as a Palantir Certified Engineer that this article is less about the layers themselves and more about how I actually decompose a problem into them.
Last time, I left that placement question open - a fact sitting in the data, a deterministic rule, an action a user takes, or something that has to reason its way there. This is what actually answering it looks like, one layer at a time.
Two ways to look at the same system
When a business problem shows up, it never arrives pre-shaped as a data model. It arrives as something like "adjusters are missing repeat claimants" or "underwriters spend too long re-checking policies by hand." On any platform, turning that sentence into something real means the same handful of moves: get the underlying data trustworthy, build a representation of the real-world things it describes, add the logic and actions that operate on that representation, and expose a workflow a user can act on. Foundry gives that generic idea one concrete, opinionated shape: Pipeline → Ontology → Functions / Actions → AIP Logic → Application, with the ontology sitting at the center of that chain rather than at one end of it.
Pipeline is what makes the data trustworthy. Ontology is the representation - but unlike a table you join on the fly in a typical stack, it's a persistent object graph, not a step you pass through once: Functions, Actions, and AIP Logic all read and write through it, and other pipelines and other applications depend on that same graph. That's why it sits in the middle as a hub rather than a link in a chain, and it's the reason Foundry rewards thinking in this shape instead of five separate products.
That arrow order is a dependency order, not a build order - I loop back through all five constantly, but the direction of what depends on what never changes.
Coming from traditional application engineering, the instinct is to think in screens, APIs, database tables, services. On Foundry that instinct is backwards: the screen is the last expression of the model, not the starting point, which is exactly why the ontology - not the application - sits at the center.
Five questions, one decomposition
Given that, here's the pass I actually make through a requirement, layer by layer. I'm keeping each of these brief on purpose - each one is a full article of its own later in this series, and the point here isn't to teach any of them, it's to show how they fit.
Pipeline - can I trust the data? Connect to the source systems (a claims intake export, the policy administration system, an adjuster's notes system - built with something like Pipeline Builder), and get raw rows clean enough to model: deduplicated, normalized, with "missing" and "genuinely zero" disambiguated. Every downstream layer inherits whatever mess is left here.
Ontology - what does this represent? Instead of a "policies" table and a "claims" table joined by foreign keys, define object types - Policy, Claim, Claimant, Adjuster - linked to each other:
Claim
├── filed by → Claimant
├── covered by → Policy
└── assigned to → Adjuster
The mistake I see most often is modeling the data as it sits in source systems instead of the real-world things those systems describe. Model what the business cares about, not the tables that happen to exist.
Functions and Actions - what can actually change? A Function is deterministic logic that computes a value - Claim.severity from the claim amount, policy limit, and claimant history. An Action is a defined, auditable change - approving a claim, reassigning an adjuster. Most of an operational build lives here, and most of it needs no AI at all.
AIP Logic - reasoning over context that already exists. Easy to mischaracterize as "the AI layer," but the LLM inside a Logic function isn't discovering the claims business from scratch - the ontology already told it what a Claimant is and how it links to a Claim. Logic's job is to reason over context the layers underneath already assembled: Claimant → related Claim objects → a pattern worth flagging. It's genuinely optional - plenty of claims never need it.
Application - the surface of the system. By the time you reach Workshop, the claim already exists as an object, its relationships already exist, the severity function already ran, and Logic may have already flagged it. The application just puts that model in an adjuster's hands. It's the only layer most stakeholders judge you on - which is exactly why it's risky to build first.
Following one claim through the system
Take the specific claim from the opening: a claimant with four prior claims, the fourth just filed. The pipeline brought it in and matched it to the existing Claimant record instead of creating a duplicate. The ontology already had that claimant's other three claims linked from earlier runs. A Function computed this claim's severity from its amount and the policy limit. AIP Logic looked across the Claimant → Claim link, noticed four claims in a short window, and wrote a review flag onto the object. The application surfaced all of it - severity, flag, history - in one queue entry, and the adjuster's action fed straight back into the ontology when she was done.
No layer did another layer's job. The pipeline didn't try to spot the pattern; the ontology didn't compute a severity score; AIP Logic didn't invent the claimant's history, it just read a link that already existed. That's the decomposition working as intended - each layer answering only the question it owns.
I don't build these layers as sequential phases in practice, and you shouldn't either. An application requirement routinely reveals a missing ontology relationship. A business rule you assumed was simple turns out to need a new Action. An AI requirement exposes missing context in the ontology.
The work loops back constantly. What doesn't change is the dependency direction: Pipeline → Ontology → Functions / Actions → AIP Logic → Application. Build application-first the way you might in typical product engineering, and on Foundry it backfires specifically because the ontology is shared infrastructure - reshape it to fix one screen, and you may be reshaping something other pipelines and applications already depend on.
Deciding where a problem belongs
This is the question I actually ask, every time a new requirement shows up - not "which Foundry product handles this" but "which question is this, really":
That's the same fact-versus-rule-versus-action-versus-judgment split from last time, just named by the layer that owns it instead of by the shape of the decision. And the last row is the one I come back to most: when an application feels hard to build, the real problem is almost always one layer down.
Where this series goes next
Once you start thinking this way, a Foundry project stops looking like a collection of products and starts looking like one system, decomposed into questions that each have a layer where they belong.
The rest of this series is about zooming into each part: how the pipeline is actually built, how the ontology models a business in more depth, how Functions and Actions make it operational, where AIP Logic's mechanics actually fit, and how an application finally brings all of it together for the person who has to use it on a Monday morning.