Palantir in Defence: Platforms, Ontologies and Deployment

The usual way to describe Palantir is as a data platform. That description is accurate and almost completely useless, because it tells you nothing about why defence organisations keep buying it after decades of failed data programmes. The more honest answer is that Palantir sells a particular opinion about how large institutions should work with their own information, and that opinion happens to suit the way military organisations actually operate.

The opinion is this: do not try to clean up your data estate before you build anything useful on top of it. You will fail, because the estate is forty years of systems built by different people for different reasons under different procurement rules, and nobody alive understands all of it. Instead, build a model of what your organisation actually deals with, aircraft, people, parts, sorties, locations, orders, and map the messy sources onto that model. Then build applications against the model rather than against the sources.

The ontology is the product

In Foundry this model is called the ontology, and it is the part most buyers underestimate. An ontology defines objects, their properties, the links between them and the actions that can be taken against them. A Typhoon is an object. It has a tail number, a configuration state, a maintenance history and a location. It links to the squadron that operates it, the parts fitted to it, the engineers qualified to work on it and the sorties it has flown.

Once that exists, a question like “which aircraft at this station can be made available in seventy-two hours, and what is the constraint in each case” becomes answerable. Without it, that question requires three teams, two spreadsheets and a week. The value is not the analytics. The value is that the question can be asked at all, by someone who is not a data engineer.

This is also why ontology work is slow and politically difficult. Agreeing what an object is forces an organisation to agree on definitions it has spent years avoiding. Two commands that count readiness differently will discover that during ontology design, not after. Most of the hard work in a Palantir deployment is that conversation, and no amount of software shortens it.

Three products, often confused

Gotham is the older intelligence-facing product, built around investigation, entity resolution and link analysis. Foundry is the broader operational platform, built around the ontology, pipelines and applications. Apollo is the delivery system that pushes software updates into environments that cannot reach the internet, which matters enormously for classified and deployed estates and which almost nobody discusses. AIP is the newer layer that puts language models inside the ontology with logic controlling what they are allowed to touch.

Confusing these leads to bad procurement. A requirement that is really about investigative tradecraft is not solved by Foundry pipelines. A requirement that is really about sustainment analytics is not solved by Gotham. And a programme that specifies either without accounting for how software will be deployed and updated inside an accredited enclave will discover Apollo-shaped problems late and expensively.

Forward deployment, and why it works

Palantir embeds its own engineers alongside the users. It is a commercially expensive way to sell software and it exists because the company concluded early that defence requirements documents do not describe what people actually need. Sitting with a sustainment cell for six weeks produces a better specification than any amount of requirements capture, because the engineer sees the workaround spreadsheet that nobody mentioned in the workshop.

The side effect is dependency. Once the engineers who understand your deployment work for the vendor, the cost of leaving is not the licence, it is the institutional knowledge. France and Germany have both pushed for alternatives on precisely that basis, and the UK debate about sovereign capability sits in the same territory. If you buy this model, put your own engineers in the room from day one, not as a later phase.

Where deployments fail

The common failure is scope. An organisation buys the platform as an enterprise data strategy, assembles a programme board, and spends eighteen months migrating sources with no user-facing output. The deployments that work start with one cell that has a real problem and a deadline, deliver something they use daily within weeks, and expand from there because other teams ask for it.

The second failure is treating the ontology as an IT artefact. It is a statement of how the organisation understands itself, and it needs an owner with authority to settle disputes about definitions. Left to a technical team, it becomes a schema that nobody trusts and everyone works around.

The third is assuming the platform resolves governance. It gives you the mechanism for granular access control and audit, and it makes policy enforceable in a way spreadsheets never could. It does not tell you what the policy should be. That remains an institutional decision, and the platform will enforce a bad policy just as faithfully as a good one.

How AIC approaches it

We build on Foundry and AIP for customers who have already made the platform decision, and our interest is in the layer above: domain ontologies, the applications operators actually touch, and the integration work that connects the platform to systems it was never designed to meet. Our PAL.NET SDK exists because .NET teams needed a typed, supported way to reach Foundry and their own ontology without hand-writing HTTP clients that rot.

If you are weighing up a Foundry deployment, or trying to recover one that stalled, we are happy to talk through what we have seen work.