A Common Software Backbone to Make the Undersea AI Market Contestable

On October 2, 2026, the Department of the Navy issued a call for a classified industry day, set for November 18 in Alexandria, Virginia, with registration due by October 16. The purpose: gather concepts for a Common Computing Environment — a shared computing and software backbone across future US submarine classes, including the objectives of the next-generation SSN(X) program.

On the surface, this is just another call for ideas in the Navy's acquisition cycle. But the choice to standardize the computing environment — rather than letting each submarine class carry forward a proprietary architecture inherited from its prime contractor — touches a structural question: who, today, has the economic right to integrate AI or autonomy software onboard a US submarine, and at what cost?

Military naval shipbuilding is a textbook case of a market locked up by vertical integration. Historically, a small number of prime contractors control the hardware, the middleware, and the software interfaces of each vessel class. A third-party AI vendor — sonar signal processing, sensor fusion, autonomous mission planning — must, to gain entry, negotiate a costly, platform-specific bilateral integration, often with limited access to interface documentation. The entry cost here is not regulatory; it is architectural.

This is exactly what contestable-markets theory, formalized by William Baumol, John Panzar and Robert Willig in 1982, lets us name precisely. Their central insight: a market can remain competitive — in the sense that incumbents are forced to behave competitively — without a large number of actual competitors, provided entry and, above all, exit costs (sunk costs) are low enough that rapid entry followed by costless withdrawal if the venture fails (the 'hit-and-run entry' mechanism) stays credible. In a perfectly contestable market, it is the threat of entry, not entry itself, that disciplines incumbents' prices and pace of innovation.

Applied here: the historical proprietary architecture of US submarines keeps entry and exit costs high for any software vendor — which makes the market non-contestable, regardless of how many competitors exist on paper. By imposing a Common Computing Environment shared across classes, the Navy changes nothing about who builds the hull and propulsion — but it mechanically lowers the cost of software integration, and therefore the entry and exit cost for AI/autonomy layers. The onboard software market becomes, for the first time, structurally contestable — even if it remains, in practice, dominated by a handful of players.

This reading carries a direct, quantifiable implication for industry: the registration window for the November 18 industry day (closing October 16, a 15-day window from the announcement) has real option value, in the sense of the literature on investment under uncertainty. Positioning early, before first responders capture the very definition of the standard — its interfaces, protocols, certifications — is structurally cheaper than waiting for the architecture to be locked in through collective design between the Navy and a small group of already-engaged primes. An open standard, once set by its first contributors, quickly regains the properties of a non-contestable market.

For industrial vendors — notably French and European defense-AI players, who remain structurally outside the inner circle of US naval programs — the signal should be read as a call to document now how their AI/autonomy building blocks interoperate with open onboard-computing standards (containerization, hardware abstraction, modular interfaces). This is not a sufficient condition for access to the US market, but it becomes a necessary condition for visibility at the moment the reference architecture is being decided.

One major caveat remains: nothing guarantees, at this stage, that the final Common Computing Environment will stay genuinely open once the process concludes — the history of defense standards shows that capture by first movers (through the technical definition of the standard itself) is a structural risk, not a textbook hypothesis. Contestability institutionalized through a call for proposals is never guaranteed; it will be measured, a year or two from now, by the real conditions of access new entrants actually get once the Common Computing Environment is specified.