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 extends through August 26, 2026 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 described another stated requirement within the family-of-systems approach. A September 8 update states that the notice is no longer active; it should be read as procurement history rather than a currently open invitation. 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.
A demonstration and an evaluation record serve different purposes
A convincing demonstration shows observers that something worked. An evaluation record must also explain how the result relates to the requirement and the proposed delivery. Those purposes overlap, but they are not interchangeable.
A vendor should make the relationship explicit before the event. Identify the configuration, the work performed by supplier personnel, and any difference between the demonstration equipment and the offered system. Where prior operating experience supports the proposal, explain which conditions transfer and which do not. The evaluator should not have to infer those boundaries from a broad claim of maturity.
The same discipline helps when the government asks for clarification. An answer should resolve the actual ambiguity and remain consistent with the offered configuration and support commitment. This is a recommendation for sound proposal records, not a conclusion about any party's conduct in the MUSV proceeding.
The result is useful beyond the competition. If selected, the receiving program can trace the promises it must now accept and sustain. If the procurement changes, the supplier retains evidence that can be assessed against another requirement without claiming automatic qualification.
Price the transition between components
Modularity creates an option to change suppliers; exercising that option still takes work. A replacement component may require interface verification, updated training, maintenance changes, and a new support arrangement. The customer needs to understand those costs before using the possibility of substitution as an affordability argument.
A practical proposal can describe one representative change at a suitable level: what documentation is available, who can perform the integration, and what acceptance work remains. This does not require publishing proprietary implementation details. It requires enough information for an authorized customer to assess the commercial and engineering commitment.
A tightly integrated product may be a reasonable choice where its performance and support advantages outweigh switching costs. A more modular arrangement may be preferable where future changes are central to the requirement. Clear evaluation criteria should make that choice reviewable rather than assume one architecture is always superior.
The immediate task for competitors is to connect each claimed advantage to evidence the buyer can use. That keeps attention on the delivered capability and preserves a sound distinction between a procurement dispute, an architectural preference, and the actual work of supporting a vessel.
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.
- Map each evaluated requirement to a specific claim and supporting artifact.
- Distinguish completed demonstrations from planned work and design intent.
- Identify operator involvement, maintenance and external support required for the result.
- Explain how interfaces and data rights support the proposed integration.
- 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.
