Palantir Use Cases: What Companies Build on Foundry and AIP

Most Palantir use cases have the same shape. Data from several systems of record is joined in Foundry, modeled as an ontology of business objects, and put in front of the people who make an operational decision, in an application where they can act on it. AIP adds language models that recommend or draft the action, with a person approving it. The use cases that hold up share three traits: they start from one decision someone makes every day, they need data from more than one system, and their result can be measured in weeks. This article walks through three builds delivered by Andersen Consulting's AI and Advanced Analytics practice, which BD Emerson works with as part of Andersen Consulting, and then sets out how to tell a good first use case from a bad one.

What makes something a Palantir use case?

Foundry is the wrong tool for some data problems. A dashboard over one clean database does not need it. Foundry earns its cost when three conditions hold together.

The first is that the decision crosses systems. A planner needs the work order from the maintenance system and the vibration reading from the sensor platform at the same moment. The second is that someone has to act, and the action has to be recorded: approve, reassign, order, escalate. Palantir's documentation describes the ontology as an operational layer for the organization, with action types that capture decisions alongside the data. The third is that the decision repeats often enough for a faster or better one to add up.

Foundry and AIP play different parts in that shape. Foundry does the integration, the ontology, the security model, and the applications. AIP puts language models to work on top of the ontology, so a model reads the same governed objects a user would and proposes an action that a person approves. A use case can be valuable with no language model in it at all, and the first of the three builds below is an example.

Finance operations: contract approvals across SAP and Coupa

A global reinsurer managed thousands of active contracts across finance and procurement. SAP held the financials and Coupa held spend and supplier data, and approvals moved between them by email and manual reconciliation. The build put both sources into one governed model of the contract on Foundry, added rules that route a contract for extra review when it exceeds a financial threshold or departs from standard terms, and gave both teams one application for status, approval history, and required actions.

The build reached deployment readiness in about four weeks. Neither system of record was replaced. The contract operations case study has the detail, and our guide to Palantir and SAP explains the integration pattern.

Manufacturing: predictive facility maintenance

An industrial manufacturer planned maintenance for hundreds of critical assets from manual logs and fixed inspection schedules. The ontology joined seven objects: asset, facility, work order, inspection, sensor stream, part, and bill of materials item. Predictive models use work order history and live sensor data to forecast failure risk. When vibration and temperature readings cross set thresholds, the system recommends an inspection window and generates a prioritized work order with the parts it needs. Technicians get the recommendation on a mobile application at the machine.

The system was delivered in eight weeks, and unplanned downtime for critical equipment fell by a double-digit percentage during the pilot. The facility maintenance case study covers the build.

Logistics: shift coverage and workforce allocation

A global logistics operator staffed thousands of frontline employees from handwritten attendance logs and separate HR systems, with unplanned absenteeism regularly above 8 percent on critical shifts. The ontology joined HR, time and attendance, training records, and Microsoft 365 data. When a certified operator reports an absence, AIP ranks qualified backfill candidates by proximity, recent shift load, and compliance constraints, and the supervisor commits the assignment.

The build went from kickoff to production at pilot sites in eight weeks. Staffing decisions that took 15 to 30 minutes now take under two, and supervisor time on reconciliation and coordination fell by more than 30 percent. The workforce allocation case study has the rest.

What do the three builds have in common?

Three things stand out. Each build started from a decision, and the data model followed from it. Each kept a person in the approval seat, with the system supplying the recommendation and the reasoning. And each was explainable by design, because a finance approval, a safety-related work order, and a staffing decision under labor rules all have to be defended later. In Foundry, logic of this kind can be built in AIP Logic, which Palantir documents as a no-code environment for LLM-powered functions that can stage their edits for human review, and users work in Workshop applications built on the object layer.

What other use cases follow the same pattern?

The shape repeats across industries. Insurers apply it to underwriting and customer service, where the decision crosses policy administration, claims, and third-party data. Hospitals apply it to capacity and staffing on top of the electronic health record. Energy and industrial companies apply it to asset operations. We have written up two of these in more depth: Palantir in insurance underwriting and Palantir in hospital operations. The same test applies in each one. If the decision sits inside one system and that system already supports it well, improve that system. If the decision needs three systems and a person in the middle with a spreadsheet, it is a candidate.

How do you pick a first use case?

Score each candidate against five questions.

• Does one named person or role make this decision, and do they want it fixed?
• Does it need data from at least two systems that are hard to see together today?
• Can you state the metric, its baseline, and the target before the build starts?
• Can the result show up within one quarter of go-live?
• Is there a second use case that would reuse the same objects?

The fifth question decides whether Foundry pays for itself. A maintenance ontology that already holds assets, parts, and work orders makes the next use case, such as spare parts planning, much cheaper to build. A first use case that shares nothing with the second is an expensive application.

What does a use case need before the build starts?

Four things should be in place on day one. The first is an operational owner with the authority to change how the decision gets made, because the application will change someone's daily routine. The second is access to the source systems, including the security review that lets data leave them. In the workforce build that meant role-based access controls on employee data from the start. The third is the metric and its baseline, measured before anything is built. The fourth is the group of real users who will run the first release for a few weeks and say what is wrong with it.

BD Emerson planning range for a first use case with those four in place: 4 to 10 weeks to a working build, driven by the number of source systems, the quality of their data, and whether the application writes back to a system of record. The three builds above landed at four, eight, and eight weeks.

Where do Palantir use cases fail?

The common failures are organizational. A use case chosen by the data team with no operational owner produces an application nobody opens. A use case scoped as "integrate all the data first" spends its budget before anyone makes a better decision. A use case with no agreed metric cannot defend its license at renewal. Our article on a Palantir proof of value describes how to test a use case against a metric before committing to the platform.

BD Emerson is part of Andersen Consulting and builds on Palantir Foundry and AIP as an implementation team. If you have a decision that crosses systems and want to know whether it is a Foundry use case, our Palantir consulting team can work through it with you.