What the Navy is asking industry to explore
NAVAIR's public notice describes an affordable, risk-tolerant, weaponized unmanned aircraft with extended range, carrier launch and recovery capability, and collaboration with crewed aircraft. It emphasizes modular open standards, rapid prototyping, reduced deck footprint, and integration with existing carrier infrastructure. The government is considering one or more prototype other transaction agreements through the Naval Air Systems Consortium. Official CCA Increment 1 RFI
The notice is explicit about its status: responses are information rather than offers, and the government makes no commitment to award. The listed response date was September 18. A September 18 update, which replaced the original RFI PDF, postponed the planned September 22 Industry Day without extending the response deadline, and the notice was archived on October 3. NAVAIR's RFI FAQ says a Request for White Papers containing the final Statement of Need will follow Industry Day.
The September 18 version of the RFI sets out a demanding baseline. It asks about two prototype air vehicles that achieve shore-based carrier certification within three years of award, with first flight no later than 24 months after award. The air vehicles would carry four external weapons of up to 2,500 pounds each, have a spot factor no larger than existing 4th-generation fighters, operate up to Sea State 5, and be maintained by existing air-wing personnel using their current skills. The RFI also cites an affordability goal of $30 million per unit. These are RFI attributes, not contract terms. NAVAIR's September 14 FAQ says that weapons-carriage configurations, target unit flyaway cost scope and autonomy boundary definitions will be fully defined in the Statement of Need, to be released with a later Request for White Papers.
This is still an important signal. The Navy is seeking a recoverable combat capability designed for its existing carriers, with technical risk reduction built into the prototype effort. The question for industry is how to make the whole carrier aviation system work with a new kind of aircraft.
Carrier compatibility is a system requirement
A land-based and a carrier-based aircraft face different operating constraints. Carrier launch and recovery, deck movement, storage, maintenance access, the maritime environment, and the interaction with existing equipment all affect the design and its support concept. These factors make carrier compatibility a distinct engineering problem; they do not make land-based autonomy simple.
The RFI's emphasis on minimizing deck footprint and using established infrastructure is especially significant. A prototype that performs well in flight can still create unacceptable burdens if it obstructs deck operations, needs incompatible support equipment, or demands more maintenance resources than the ship can provide.
Program reviews should therefore evaluate several connected questions:
- Aircraft suitability: what evidence demonstrates compatibility with the intended operating environment?
- Deck integration: can the aircraft be moved, parked, serviced, and managed within approved shipboard practices?
- Supportability: are personnel, tools, spares, and maintenance arrangements included in the delivery plan?
- Control integration: can the aircraft exchange the necessary information through approved interfaces and control systems?
- Human responsibilities: do operators and supervisors have clear roles, training, and usable indications of system state?
These are acquisition and assurance questions. They need to mature alongside the air vehicle rather than appear as late additions to an otherwise finished design.
The Navy already has relevant demonstrations to build on
The X-47B demonstrated an arrested carrier landing in July 2013. It was a technology demonstrator under the Navy UCAS program rather than an operational combat aircraft. Its history provides useful evidence about unmanned carrier aviation without making the new CCA effort a direct restart of the same program. Navy account of the X-47B landing
MQ-25 work adds a different set of lessons. During a December 2021 carrier demonstration aboard USS George H.W. Bush, deck operators used a control device while working alongside Navy taxi directors. The evaluation included aircraft movement and other deck-handling activities. That was a demonstration supporting development, not evidence of an operational fleet already routinely conducting those missions. NAVAIR MQ-25 carrier demonstration
The distinction matters because successful demonstrations establish particular capabilities under particular conditions. They can reduce risk for later programs, but the evidence must be matched to the new aircraft, configuration, and intended use.
Common control infrastructure deserves serious attention
NAVAIR's May 2022 account identifies the MQ-25 air vehicle, MD-5 ground control station, and carrier modifications as connected elements of an integration effort led by the government. It describes early laboratory integration as a way to reduce risk and check connectivity between development environments. NAVAIR MQ-25 and MD-5 integration
That experience supports a broader architectural lesson: investment in reusable control infrastructure and clear interfaces can benefit more than one air vehicle. It can reduce duplicated integration work and make operator training and support more coherent. The CCA RFI already points in this direction. Performers may use their own ground control stations during development, but the prototype is expected to demonstrate compatibility for integration with the MD-5 Unmanned Carrier Aviation Mission Control System, and the government will furnish MD-5 interface control documents. The RFI also asks how CCA control can be added to that system without disrupting MQ-25 operations or modifying the MQ-25 air vehicle. Detailed requirements will be defined in the Statement of Need; binding terms would come only in any resulting agreement.
Commonality also needs careful boundaries. Two aircraft may share an interface while having different performance limits, support needs, or approved functions. The objective should be a usable, maintainable architecture with explicit differences, rather than superficial uniformity that hides those differences from operators.
Autonomy demonstrations answer a different question
NAVAIR's January 2026 account describes a December 11, 2025 demonstration at Point Mugu Sea Range in which two BQM-177A targets, flown by Shield AI's Hivemind software, operated in a live, virtual, and constructive environment with a virtual F/A-18 as mission lead and two simulated adversary aircraft. The work involved Shield AI, Kratos, and CTSI and focused on coordinated autonomy. It is relevant progress toward collaborative aviation; it is not carrier qualification for a future CCA. NAVAIR autonomy demonstration
The acquisition challenge is to combine these different bodies of evidence. Flight behavior, shipboard handling, control integration, and operator performance each answer a different part of the readiness question. A successful result in one area should not be used to imply that the other areas are complete.
Payload and price need complete definitions
Payload capacity, compatible stores, and certified mission configurations are distinct claims. A weight allowance does not establish that any particular weapon can be carried or used. Similarly, an aircraft price without its quantity, support content, development treatment, and configuration is an incomplete comparison.
Affordability should be assessed across acquisition and sustainment. A lower air-vehicle price can be offset by integration, support equipment, software maintenance, or personnel demands. Risk tolerance also does not mean an aircraft can dispense with safety or compatibility requirements around a crewed carrier.
Industry proposals should make assumptions visible and show where evidence already exists, where it is transferable, and where new testing is required. That makes tradeoffs reviewable without pretending that every desired feature can be delivered at once.
Reuse evidence with its conditions attached
The history of unmanned carrier aviation is valuable because it supplies concrete work to build on. The risk is treating that history as a general qualification that moves intact to a new aircraft. A prior result becomes useful when the program can identify the function demonstrated, the configuration involved, and the assumptions that still hold.
A prototype proposal should make that comparison explicit. Some facilities, interface knowledge, and evaluation methods may be reusable. Other evidence may require a new assessment because the air vehicle, support equipment, software, or personnel responsibilities differ. This is ordinary engineering discipline, not a reason to discard earlier investment.
The program can then concentrate new work on the differences that matter. An unexplained assertion of commonality hides effort; a documented account of what transfers can reduce it. That distinction is especially important when several organizations supply different parts of the prototype.
Include shipboard support in the prototype decision
A proposal may describe an aircraft that fits aboard a carrier while leaving the support system largely unspecified. The customer still needs to understand who maintains the delivered equipment, which resources are assumed available, and which support functions require additional arrangements.
These assumptions should be visible before the program treats a prototype schedule as a path to usable capability. A demonstration supported by specialists can be a sound development step. A receiving organization needs a separate plan for the skills, documentation, and services required after that demonstration team departs.
The next review should therefore consider the air vehicle and its support package together. Identify which elements are part of the proposed delivery, which are government responsibilities, and which remain unresolved. An early, bounded prototype may deliberately leave some work for later; the decision should say so and identify the evidence needed before expanding its use.
That approach gives the Navy a clearer comparison among proposals. It also allows suppliers to show the value of mature support arrangements alongside their aircraft technology, without assuming that a familiar airframe or an impressive flight event answers the complete integration question.
The RFI makes this concrete. It asks respondents to rely primarily on existing shipboard logistics capabilities, maximize use of Common Support Equipment, minimize peculiar support equipment, and handle maintenance and launch-and-recovery crewing with existing air-wing personnel during scheduled operational maintenance periods.
Authority and assurance must develop with the aircraft
A control station provides an interface. It does not, by itself, define who may authorize an action, which decisions require human approval, or how the system should behave when information or connectivity is unavailable. Those responsibilities must be established by the applicable policy, approved concept of operation, and system requirements.
The prototype program must include the people and procedures around the aircraft. Operator understanding, reviewable decisions, and validated behavior within approved limits belong in the acceptance plan alongside physical compatibility. Requirements should identify the applicable authority and the evidence needed to demonstrate compliance.
The Navy's CCA effort will be judged by the capability it can safely integrate and sustain aboard existing ships. The airframe is central, but the delivery obligation extends to the control architecture, deck personnel, maintainers, and program authorities who make it usable.
Sources and further reading
- NAVAIR CCA Increment 1 RFI
- NAVAIR CCA RFI FAQ (September 14, 2026)
- Navy: X-47B arrested landing
- NAVAIR: MQ-25 carrier demonstration
- NAVAIR: MQ-25 and MD-5 integration
- NAVAIR: collaborative autonomy demonstration
Spartan X's engineering, AI, and logistics expertise connects these parts of the delivery problem: credible technical evidence, workable integration, and the people and support arrangements required to sustain a new capability.
