From Data to Decisions: Palantir in the Battlespace

Decision superiority is one of those phrases that has been repeated until it stopped meaning anything. Stripped back, the claim is simple: if you can observe, understand and act faster than an adversary, you will usually win, even with less capable equipment. The interesting question is not whether that is true. It is where the time actually goes.

In most headquarters the answer is not sensing and not deciding. It is the middle. Material arrives in incompatible formats from systems that do not speak to each other, staff officers reconcile it by hand, and the commander receives a picture that was accurate ninety minutes ago. The bottleneck is clerical, and clerical bottlenecks are the kind software can genuinely remove.

What the ontology does to a targeting cycle

Consider a dynamic targeting problem. A sensor reports a contact. To do anything with it you need to know what it is, what is near it, whether it matches an existing track, what collateral concerns apply, which assets could engage it, what their status is, and what the current rules of engagement permit. Each of those answers lives in a different system.

If those systems have been mapped onto a shared model, the contact arrives as an object that already has those relationships attached. The staff officer is not assembling the picture, they are interrogating one. That is the whole argument for an ontology in an operational setting, and it is why Foundry deployments in command environments tend to be judged on how quickly a question can be answered rather than on how much data was ingested.

The honest caveat is that the model has to be built before the operation, not during it. Ontology design under time pressure produces a model that encodes whatever assumptions were convenient that week, and those assumptions then quietly shape every decision taken against it.

Lessons from Ukraine

Ukraine has been the most significant real-world test of commercial data platforms in combat, and the lesson most frequently drawn is the wrong one. The achievement was not advanced analytics. It was integration speed: connecting commercial satellite imagery, open-source reporting, drone feeds and military reporting into a single usable picture in weeks rather than years.

That speed was possible partly because the constraints were different. Accreditation timelines, competing stakeholder requirements and peacetime procurement were not in the way. Western forces trying to replicate the outcome inside normal governance should be clear-eyed that the governance, not the technology, is the limiting factor.

Automation and the human in the loop

There is an unresolved tension here. Compressing the decision cycle means removing human steps, and the steps that are easiest to remove are often the ones that exist for legal or ethical reasons. Project Maven and comparable efforts have consistently found that the defensible position is machine-assisted perception with human judgement on effects, which is slower than full automation and considerably easier to defend afterwards.

The practical design question is where the human sits. Reviewing every detection does not scale. Reviewing nothing is indefensible. The workable pattern is for the system to narrow and prioritise, present the evidence behind each recommendation, and require a human decision at the point where an effect is authorised, with that decision recorded against the evidence that supported it.

This is also where AIP-style language model integration earns its keep or becomes a liability. Summarising a hundred reports into a briefing is useful. Doing so without the ability to trace each sentence back to its source turns the summary into an unverifiable assertion, and in a command environment that is worse than no summary.

Measuring the right thing

Programmes in this space are routinely measured on data volume ingested, dashboards built or users trained. None of those tell you whether decisions improved. More useful measures are the time from a contact report to an actionable assessment, the proportion of assessments that can be traced to source material, and how often the picture a commander holds turns out to have been wrong.

Those are harder to collect and far less flattering, which is precisely why they are worth collecting. A programme that cannot answer them is reporting activity rather than effect.

AIC builds the operator-facing layer on Foundry and AIP, and our PAL.NET SDK gives .NET teams a typed route into the platform and their own ontology. If you are working on a command and control integration problem, we are glad to compare notes.