Ghost Shark’s production deal buys a support system as well as underwater vehicles

An underwater robot removes the need to put people inside the vehicle. It does not remove the people who prepare missions, service batteries, interpret faults and decide when the machine is ready to sail again. For a navy operating across long distances, those activities determine whether an autonomous fleet is a dependable capability or a collection of occasional demonstrations.

Australia’s September 10, 2025 Ghost Shark announcement committed A$1.7 billion over five years to vehicles, maintenance and continued development. Breaking Defense covered the agreement. Its scope joins buying hardware to keeping the capability usable. It is not a public demonstration of every mission or a disclosed per-vehicle operating cost.

A fleet has a cycle, not just a range

A vehicle can have an attractive maximum range yet spend much of its life awaiting inspection, spare parts or a software correction. Conversely, a less ambitious vehicle might provide more useful days if its turnaround is predictable. The procurement question is how long a complete cycle takes: prepare, launch, perform the task, recover, check the machine and return it to readiness.

Underwater operation makes diagnosis particularly important. Radio communication is limited beneath the surface, so a support team cannot treat every mission as a continuously connected service call. A useful mission record would preserve enough information to distinguish an environmental problem from a hardware fault or an inappropriate software decision. That is an operational implication we infer from the setting, not a result published for Ghost Shark.

Continued development can add capability, but it can also change behaviour an operator had learned to trust. A vehicle receiving a new navigation or mission build should be connected to the tests supporting that build. Otherwise the fleet’s apparent commonality can conceal several different combinations of hardware, software and accepted operating conditions. Counting them all as identical machines would hide an important support burden.

Support can create dependence

A long-term agreement could be valuable because the customer does not yet know every maintenance burden. It gives the supplier a role in correcting problems rather than treating delivery as the end of responsibility. The countercase is dependence: if only one supplier can diagnose faults or approve changes, the navy may gain hardware without much freedom to maintain it independently.

An informative comparison would separate scheduled maintenance from unexpected work, identify tasks needing supplier specialists, and report turnaround after representative missions. It would include remote operating sites rather than only the home facility. Those measures would expose whether local production and support translate into operational availability. They are proposed measures; the acquisition announcement does not supply that record.

Price comparisons must respect the package being purchased. Dividing the headline contract by an assumed fleet size silently allocates development and maintenance to each hull as though they were manufacturing costs. Even an accurate unit count would not make that arithmetic comparable with a vehicle-only agreement. The scope of support has to travel with any cost claim.

There is a procurement consequence as well. The customer needs a way to recognise useful improvement without rewarding endless revisions. Acceptance should be connected to a repeatable mission and readiness standard. That lets the navy distinguish a change that reduces support work from one that merely adds another attractive capability to the demonstration list.

From delivered hulls to available missions

Consider two hypothetical fleets with the same number of hulls. One can prepare another mission as soon as a vehicle returns; the other must wait for a specialist to arrive. Their nominal inventory is identical, but their useful coverage is different. That is why the support agreement belongs in a discussion of autonomy itself: it governs how often the independent machine can actually work. This comparison illustrates a purchasing question, not a reported result for either fleet.

The contract also gives the customer an opportunity to define what information stays with the navy. A maintenance history that records the fault, corrective action and software version is more useful than a simple statement that a repair was completed. It allows later problems to be compared with earlier ones and helps a new team understand the vehicle it inherits. Asking for that continuity would turn support into institutional learning rather than a recurring purchase of supplier attention.

For readers, the central distinction is between a delivered object and an available service. The first can be photographed at a handover. The second needs a record across successive missions, including days when the vehicle is unavailable.