Palantir will build Mercury Systems’ digital twin: whose ontology is it?

On 3 August 2026 Mercury Systems (NASDAQ: MRCY) and Palantir Technologies announced, in a GlobeNewswire release timed 08:30 ET, “a strategic agreement to enhance the automation of material planning and factory operations to accelerate the delivery of processing technologies for U.S. military programs.” One sentence, further down the same text, carries the rest of the piece: “Palantir will also help Mercury build an enterprise ontology that serves as a digital twin of the company’s operations and business practices.” This is not a story about a piece of software being sold. It is a story about who builds, and on whose behalf, the model of how a listed defence manufacturer actually works.

Two public statements, two workflows

The release frames the agreement around “two initial workflows”: Mercury will use Palantir’s AI to “streamline material planning, reduce manual workloads, and improve the ability to deliver at increased capacity across its factories.” Bill Ballhaus, Mercury’s Chairman and CEO: “Partnering with Palantir will enable Mercury to further drive automation and efficiency in our supply chain and manufacturing operations.” Mike Gallagher, Palantir’s Head of Defense: “By integrating numerous data sources within a shared operational layer, Mercury will be positioned to deliver vital processing technologies.” And one sentence in the release makes clear that Mercury is not an isolated case: “In support of the U.S. Department of War, Palantir is working with key U.S. defense industrial base suppliers to increase throughput and reduce delivery timelines” — Palantir is working with key suppliers across the American defence industrial base to raise output and shorten delivery times. Not a deal, then: a way of operating. (“Department of War” is the name the Department uses in its own releases, on war.gov, alongside the Department of Defense still current in acts of Congress.) No financial value, no duration, no stated scope: not here, not anywhere else in the release.

The ontology is not the software, it is the model of the company

What, precisely, is an “enterprise ontology”? It is the schema by which a system represents how a company actually does its business: what counts as an order, a batch, a supplier, a production line, a delay — and how these things relate to one another. It is not the data: how many units, which supplier, which delay remain, obviously, Mercury’s own. It is the structure that says how the data connects — and it is this structure, not an installed programme, that functions as a “digital twin”: a formal representation of how the company genuinely works, not a dashboard describing it from the outside. Building it means teaching the system the company’s entire operating grammar — its processes, its constraints, its exceptions: work done jointly, not a product delivered turnkey. That is exactly why the question of who ends up owning it is not an idle one.

The questions to ask before signing

These are the questions an operations director or a CIO should ask before signing an agreement of this kind — and this is where the value of this piece lies, not in the press release.

Whose ontology is it? The data stays with the customer, as near-universal practice. But the schema — entities, relationships, rules, learned by working alongside the supplier — is a jointly built work. Does the contract say explicitly who owns it, or does the question get lost where know-how protections so often go untested?

Where does it run, and who can read it? A faithful model of a defence supplier’s operations is, by its nature, sensitive information: it shows where the bottlenecks are and who you depend on.

What is left if you switch suppliers? Can the ontology be exported in a format another plant can read and run, or do you start again from zero?

How long does it last, and what does it cost? The release does not say. Nor does the one public filing that ought to follow an announcement of this scale — because that filing, quite simply, does not exist.

An agreement, not a reportable event

Here is the verifiable fact. Mercury Systems files with the SEC under CIK 0001049521. Checked today against data.sec.gov/submissions/CIK0001049521.json, the most recent filings are: a Schedule 13G dated 31 July 2026, a 13G/A dated 29 July, and a Form 4 dated 20 July. No 8-K appears after the 3 August announcement: the last one on file remains dated 5 May 2026. This is not an accusation: it is a measurement. An 8-K must be filed within four business days for events the issuer itself judges material to investor disclosure. An agreement told through a press release and not through an 8-K is an agreement Mercury has not, to date, treated as such — not necessarily a judgement on its industrial importance. This is the same method we used to read another European defence partnership announcement: separating what is signed from what is only announced.

The Tradewind Prototype Agreement: what can actually be said

The release closes with a technical line: “Effort sponsored by the U.S. Government under the Tradewind Prototype Agreement.” Tradewind is an initiative of the U.S. Department of Defense’s Chief Digital and Artificial Intelligence Office (CDAO), launched in 2021 through an other-transaction agreement with the organisation now known as the Applied Research Institute to, according to an official publication of the U.S. Army Acquisition Support Center, “set up and manage a prototype business process that streamlines rapid procurement and agile delivery of AI capabilities.” In practice: an Other Transaction Authority instrument — the route the Pentagon uses for rapid prototyping agreements outside the ordinary Federal Acquisition Regulation, faster and with lighter competitive requirements, but also fewer of the procedural safeguards of a standard FAR contract. We could not find, on a primary .mil or .gov source, the exact phrase “Tradewind Prototype Agreement” as a distinct formal category: we report it because it appears in the release, not because we have verified it as such.

The other side, as it should be told

This is not a criticism of Mercury or of Palantir. A listed defence manufacturer handing the automation of its material planning to an outside supplier is behaving prudently and ordinarily: it uses a public rapid-prototyping instrument, puts the names of the executives involved on the record, and does not promise results it cannot yet measure. If anything, it is the sharpest demonstration of this piece’s thesis: when a listed company has a third party build its own digital twin, the value never sat in the vendor’s software — it sat, and sits, in the company’s own ontology, its own data, its own processes. The agreement itself proves it better than any claim we could make.

The operational lesson

Write the ontology’s ownership into the contract, not just the data’s: schema, rules, relationships — who holds them if the relationship ends.
Ask for a verified export format, not a promised one: test it before signing, not after the first invoice.
Keep a log of who has seen and changed the model — when, with what effect — exportable and ready to show at an inspection: for anyone working in the defence supply chain, this is already, in effect, a requirement.
Open the filing, not just the press release: an agreement with no 8-K, no duration, no stated scope is an understanding to reread every quarter, not a settled fact.

A company’s ontology — plant, suppliers, batches, delays, in a single model — is exactly what Mercury is buying from an outside supplier. It is also exactly what we build with our own clients in manufacturing and defence, with one difference: who holds the key. A log of who has seen and changed the ontology, with date and effect, is the control we put into operation — ready to show at an inspection, not a one-off audit filed away. And it is the same multi-model system that brings the rest of an organisation’s scattered data — archives, business systems, sensors, documents — into a single operating model, on which AI agents execute decisions with a human operator in command, for large enterprises, defence, government and healthcare: the ontology stays yours, even if one day you change us. On-premise, on autonomous machines that require no deep integration into your network, or on a dedicated cloud with a data centre in Italy — always with shared administration.

Want to know who would hold the key to your company’s digital twin, before signing anything like this? Half an hour with one of our engineers.