The MUSV Protest and the Question of What the Navy Is Evaluating

Establish the procurement and legal facts separately

The Navy's May 29, 2026 announcement identified seven companies' entries selected to advance to at-sea testing in the Medium Unmanned Surface Vessel marketplace. Selection for a demonstration stage is distinct from a completed evaluation or a production award.

The Court of Federal Claims docket reproduced by Justia identifies Blue Water Autonomy and Saildrone as plaintiffs in the consolidated proceeding, case 26-936. Blue Water's case was filed June 29, 2026. The public docket snapshot reviewed for this September update extends through August 26 and lists litigation filings; it is not a merits decision or a complete current account of the case.

The dispute should therefore be discussed as a challenge to a procurement, with allegations assessed through the legal record. It does not by itself demonstrate bias against software-focused firms or establish that the Navy must adopt a particular architecture. Those are separate questions that require their own evidence.

The marketplace also continues to evolve. The Navy's July 7 notice for a high-capacity MUSV opening shows another stated requirement within the family-of-systems approach. Vendors should distinguish the terms of each opportunity instead of assuming that qualification or selection transfers automatically between them.

The hull and software are part of the same delivery problem

A vessel's autonomy depends on its sensors, actuators, communications, power and mechanical behavior. The software may be a major differentiator, but the delivered product cannot be evaluated as software alone. Nor does a successful hull demonstration establish that the autonomous functions meet the intended operating requirement.

This creates a source-selection challenge: how to compare integrated systems while preserving the ability to improve or replace components later. The evaluation needs to make the relevant tradeoffs visible. A supplier with substantial operational data should know how that evidence will be considered. A supplier offering a new integration should know which claims must be demonstrated and which can be supported through other evidence.

Clear criteria help both sides. They connect what the government intends to buy with what the vendor must prove, reducing room for assumptions about how a proposal will be judged.

Make modularity an enforceable delivery term

Separating platform, payload and autonomy interfaces can support competition and reduce the cost of later changes. That is an architectural option to evaluate, rather than an inevitable legal outcome of the protest. Government ownership of every interface is also not the only arrangement that can support interoperability; usable documentation and appropriate rights matter.

A practical integration agreement should identify:

• The interface: messages, timing, error handling and version compatibility.
• The rights: what the customer and future integrators may inspect, use or modify.
• The evidence: tests demonstrating that independently supplied components work together.
• The owner: who resolves failures at the boundary between products.
• The change process: how updates are approved, tested and introduced into the accepted configuration.

Without those terms, “open” can remain a proposal adjective. With them, the customer can assess the actual cost and risk of adding another payload or changing software suppliers.

Build evidence that survives a competition

Vendors should organize technical evidence around the solicitation rather than assume that a strong demonstration speaks for itself. A result becomes more useful when its configuration, conditions, limitations and relationship to the requirement are documented.

1. Map each evaluated requirement to a specific claim and supporting artifact.
2. Distinguish completed demonstrations from planned work and design intent.
3. Identify operator involvement, maintenance and external support required for the result.
4. Explain how interfaces and data rights support the proposed integration.
5. Retain a consistent record of clarifications, configuration changes and acceptance evidence.

This discipline also improves the program after selection. The same records can support integration, training, sustainment and later upgrades. Portable evidence is valuable even when a particular procurement changes course.

The enduring lesson is about execution: a competitive autonomy market needs clear requirements, credible demonstrations and maintainable integration boundaries. Procurement structure and technical architecture should reinforce one another without prejudging the outcome of a legal challenge.

Sources and further reading

• U.S. Navy: seven MUSV entries advance to at-sea demonstrations
• Court of Federal Claims docket, case 26-936, reproduced by Justia
• Navy MUSV high-capacity marketplace notice

Spartan X's program execution and engineering practices connect evaluation criteria to demonstrable capability, with the interface records and sustainment responsibilities needed to carry an autonomous system beyond selection.