From Ghost Fleet to Procurement: What Changed
The Navy's unmanned surface capability development moved through two distinct phases. Ghost Fleet Overlord, initiated by the Strategic Capabilities Office in 2018 and transferred to PEO Unmanned and Small Combatants in 2022, tested purpose-built technology demonstrators—Nomad (Prototype 1) and Ranger (Prototype 2)—on extended autonomous ocean transits. Those vessels traveled 28,982 nautical miles in autonomous mode during the program, including over 3,200 nautical miles of COLREGs-compliant operations. They demonstrated basic open-ocean autonomous navigation, some limited payload integration, and initial command and control concepts for operating unmanned vessels with a small remote control team. They operated in relatively permissive environments: available GPS, reasonable satellite communications, and no adversary attempting to deny, degrade, or spoof their sensors. [Strategic Capabilities Office / NAVSEA Ghost Fleet Overlord program reporting]
The LUSV program takes the next step. The Navy envisions LUSVs as 200 to 300 feet in length with full-load displacements of 1,000 to 2,000 tons—corvette-sized platforms configured for anti-surface warfare and strike payloads, including vertical launch systems. The FY2025 budget includes approximately $54 million in R&D funding for the LUSV program, with first production procurement programmed for FY2027. PEO Unmanned and Small Combatants holds the LUSV program alongside the Medium Unmanned Surface Vessel, and both are intended to extend the sensing and strike reach of the fleet under the Distributed Maritime Operations (DMO) concept. While described as unmanned, LUSVs may carry small crews in early deliveries as the Navy validates enabling technologies—the Navy has described them as potentially "optionally or lightly manned" in the near term. [CRS R45757; Navy FY2025 Budget Justification; PEO Unmanned and Small Combatants program page]
The commitment to a production trajectory makes integration architecture decisions binding. GAO-22-104567, *Uncrewed Maritime Systems: Navy Should Improve Its Approach to Maximize Early Investments* (April 2022), found that the Navy's plan to spend more than $4 billion on uncrewed systems did not account for the full costs of operations, sustainment, and the digital infrastructure required to operate the vehicles. The assessment also found the Navy had not established a management approach that oriented its individual uncrewed efforts toward measurable strategic objectives, or criteria for evaluating prototypes. Congress has applied scrutiny through the HASC and SASC markup process, conditioning some LUSV funding on demonstrated capability milestones.
Those institutional concerns reflect a real technical problem: the Ghost Fleet experiments established that the vessels could navigate, not that they could fight.
The Three Structural Integration Challenges
Communications Architecture Under Contested Conditions
Distributed Maritime Operations is explicitly designed for contested environments. The operational concept, as described in CNO Navigation Plan 2022 and supported by the Surface Force's DMO doctrine, assumes an adversary that can degrade satellite communications, jam tactical data links, and attempt to disrupt or exploit adversarial C2 networks. Navigation Plan 2022 identifies "distributed maritime operations" as the Navy's foundational operating concept and enumerates force design imperatives including expanded distance and assured delivery that presuppose contested environments. [CNO Navigation Plan 2022, July 2022]
An LUSV operating under continuous connectivity to a command ship is not survivable in that environment, and it is not the vision in the Navy's concept documents. The vessel has to be capable of extended autonomous operation—navigating, sensing, and potentially employing weapons—during periods when communications are unavailable, with the autonomy architecture making locally bounded decisions and resynchronizing with the fleet when communications windows open.
This creates a design requirement that most maritime autonomy programs have not been tested against. The standard autonomy test regime involves an operator in the loop over a functioning data link. Building an autonomy stack that behaves correctly in both permissive and communications-denied modes, and that records its decision rationale for post-resynchronization review, requires a fundamentally different design than a system that assumes connectivity. The test strategy for the program has to include comms-denied conditions from developmental testing onward—not as an adversarial edge case but as a design-required operating mode.
Kill Chain Authorization and DoDD 3000.09
DoD Directive 3000.09, Autonomous Weapons Systems, requires that lethal force by autonomous systems be subject to appropriate levels of human judgment. The January 2023 update to DoDD 3000.09 preserved that requirement and added clarification on applying the DoD AI Ethical Principles and Responsible AI strategy to autonomous weapons, and mandated senior-level review and approval for certain categories of autonomous weapons capabilities. [DoDD 3000.09, Autonomous Weapons Systems, January 2023]
For an LUSV with a surface warfare or strike payload, this creates a design constraint with no fully resolved answer in the Navy's current program documentation. The two endpoints of the design space are both problematic: a system that holds fire until it receives explicit authorization from a human operator over a data link will not be employable in a comms-denied environment; a system that applies lethal effects on algorithmic decision alone creates legal and policy exposure that DoDD 3000.09 is specifically designed to address.
The actual solution space lies somewhere between those endpoints, involving pre-mission authorization frameworks, fire control rules tied to specific mission profiles, and time-limited engagement envelopes that allow autonomous action within defined parameters. The Navy is working through this in its acquisition documents, but the approved framework has not been publicly specified at the program level. Suppliers building autonomy architectures for this program need to account for this ambiguity in their design—and be prepared to adjust when the Navy does specify the approach.
The T&E implications are significant. The Test and Evaluation Master Plan for any LUSV configuration will need to include test events that demonstrate and document how the human judgment requirement is met across the range of operating conditions, including degraded communications. That evidence has to exist before the acquisition executive will sign off on a production decision.
Data Link Integration With the Fleet
The Navy's fleet combat management systems—including AEGIS, Cooperative Engagement Capability (CEC), and the Consolidated Afloat Networks and Enterprise Services (CANES) architecture—were designed around crewed platforms with dedicated operators managing data link transactions. An LUSV is a sensor node and, in some configurations, a weapons platform; it needs to produce sensor data in formats the fleet can use and receive targeting information from the fleet's fire control network.
CEC, which provides the Navy's most capable cooperative engagement architecture, has its own interface requirements and data formatting standards. CANES defines how networks are organized aboard ship and between ships. Tactical data link interfaces—Link 16, TTNT—have their own throughput and latency constraints that affect what autonomous systems can receive and transmit in a given time window.
None of these were designed with unmanned producers in mind. The LUSV integration requires the government to specify the exact data interfaces between the vessel's autonomy stack and these fleet systems—and those specifications need to be completed before competing vendors commit their architectures. A source selection that doesn't specify the interface allows vendors to implement it differently, resulting in a multi-vendor unmanned fleet where each vessel integrates differently with the same combat management system. That is not a manageable sustainment situation.
GAO-22-104567 found that the Navy had not established criteria for evaluating prototypes—a gap that directly affects whether data-link and interface requirements are verified against fleet systems before production decisions. Programs that proceed into procurement without resolved interface documentation tend to discover integration failures during fleet exercises, where changes to autonomy software and network configurations on production hardware are significantly more costly than architecture decisions made earlier.
What the Ghost Fleet Experiments Did Not Establish
The Ghost Fleet Overlord prototypes—Nomad and Ranger—traveled 28,982 nautical miles in autonomous mode and demonstrated the ability to complete ocean transits without crew intervention, to avoid collision with commercial and naval traffic, and to operate for extended periods at sea. This is genuine capability.
What the Ghost Fleet experiments did not establish, because they were not designed to test these things:
- Performance in an environment where GPS is degraded or spoofed
- Integration with a carrier strike group's combat management system during a realistic exercise
- The behavior of the autonomy software over an extended deployment—weeks to months—without routine maintenance access to the vessel
- Resilience of the C2 architecture to electronic warfare targeting the data links
- How weapons-release authorization would be exercised under the DoDD 3000.09 framework in an actual engagement scenario
These are not edge cases. Under the Distributed Maritime Operations employment concept, the environments where GPS is degraded, data links are jammed, and an adversary is actively trying to disrupt C2 are the primary employment scenarios. A vessel that works only in permissive environments is not a DMO asset.
The implication for suppliers: a technology demonstration that shows your autonomy software navigating correctly under favorable conditions is a starting point for the program's T&E record, not a finishing point. The operational test record that an acquisition executive needs to sign off on a production decision requires data from realistic conditions, and that data has to be collected in the right kind of test facilities with the right adversarial stimulation.
Acquisition Architecture and the OTA Risk Profile
LUSV has proceeded partly through Other Transaction Agreements, which give the Navy flexibility to move quickly and to work with non-traditional defense contractors. OTA procurement removes some of the formal milestone review requirements that create visibility into technology maturity earlier in the program. That flexibility is useful for learning, but it places T&E discipline on program leadership rather than on the acquisition process itself.
For suppliers, the OTA structure means the program office's expectations for autonomy software maturity, cybersecurity assessment, interface documentation, and the T&E record may not be fully specified in a contract's Statement of Work. The Navy may hold to conventional acquisition standards at the point of transition from OTA prototyping to a formal shipbuilding contract—and programs that have not been building that evidence base throughout the OTA phase will find that transition difficult.
The competing-vendor structure of LUSV concept development also creates an interoperability coordination problem: if each vendor implements the fleet data link interface differently, the integration work falls on the Navy during fleet integration rather than on vendors during development. The government needs to specify the interface, not leave it to each vendor, and suppliers should be pushing for that specification rather than waiting for it.
Decision Questions for Program Teams
Before committing to an LUSV or maritime autonomy integration architecture, program managers and system architects should be able to answer:
- Does the autonomy specification distinguish between comms-available and comms-denied operating modes, with test cases for both?
- What is the approach to human supervisory control for weapons-release decisions, and has it been reviewed against DoDD 3000.09 and the Navy's current program documentation?
- Have the data link interfaces been specified against the actual fleet combat management system standards—CANES, CEC, Link 16—rather than a notional architecture?
- Does the T&E plan include adversarial conditions: GPS denial, EW environment, spoofing of sensor inputs?
- What is the plan for maintaining and validating autonomy software over extended deployments in fully uncrewed configuration?
- At what point in development does the program produce operationally representative data (not just laboratory or permissive-environment data)?
- Has the program identified which Type Commander will be responsible for integrating the LUSV into fleet exercises, and what that coordination requires?
If more than two of these are unanswered at the design review stage, the program is carrying integration risk that the Navy will discover at a point when architecture changes are expensive.
Sources and further reading
- Navy PEO Unmanned and Small Combatants
- CNO Navigation Plan 2022
- DoDD 3000.09, Autonomous Weapons Systems (January 2023)
- GAO-22-104567, *Uncrewed Maritime Systems: Navy Should Improve Its Approach to Maximize Early Investments* (April 2022)
- Navy FY2025 Budget Justification (R&D, BA4)
- CANES program description, PEO C4I PMW 160
Spartan X works directly in unmanned maritime systems design—building autonomous surface platforms and the edge-compute architectures that allow them to operate and make bounded decisions when the data link to the fleet is intermittent or absent. The integration challenges in LUSV are the same class of problem Spartan X's Wraith program addresses: defining the behavior envelope for an unmanned vessel that has to work in both connected and disconnected states, specifying how that behavior is documented for the acquisition authority, and integrating sensor output into the formats the naval network actually uses. The LUSV integration requirements are not a future problem. They are the current design space.
