Read the notice for what it is
NAVAIR's August 31, 2026 sources-sought notice, N00019-27-RFI-PMA228-CCA, seeks feedback for Increment 1 prototype development and demonstration. Its public description calls for an affordable, risk-tolerant, carrier-capable, weaponized autonomous aircraft able to deploy from and recover to Ford- and Nimitz-class carriers. The notice listed a September 18 response date and described possible prototype other-transaction awards.
An RFI is market research. It does not establish a production award, a selected competitor or a final acquisition baseline. Detailed cost, payload and schedule figures should be checked against the controlling notice and attachments, including amendments, before they become bid assumptions. The publicly indexed record lists a September 18 replacement PDF and marks the original attachment deleted. The replacement PDF was not independently inspected here; the public description alone does not verify every detailed requirement.
The market signal is still clear: the Navy is exploring combat autonomy within the carrier air wing, where launch, recovery, deck movement and shipboard support shape the aircraft from the beginning.
The carrier changes the engineering problem
A runway demonstration cannot establish carrier suitability. Catapult launch and arrested recovery impose structural and control requirements; a moving deck, salt exposure, constrained parking and maintenance access add other demands. Ford- and Nimitz-class integration also requires attention to their different launch and recovery equipment.
These constraints interact. A change in landing gear or wing folding affects weight and maintenance. A deck-control interface affects crew workload and movement procedures. Power, communications and mission-system integration can consume margins that appeared comfortable in an early airframe demonstration.
Affordability therefore needs a whole-system definition. A recoverable aircraft must support repeated missions, repair, spares and training. Low acquisition cost is useful only if the carrier can generate the required sorties without an unsustainable support burden. Likewise, describing a platform as risk-tolerant does not mean its loss, replacement or embarked support is costless.
Teaming must be demonstrated at the right level
There is a useful Navy starting point. In its January 12, 2026 account, NAVAIR described a December demonstration with two BQM-177A targets flying autonomously, connected to a live-virtual-constructive environment that included a virtual F/A-18 and simulated adversaries. Shield AI, Kratos and CTSI contributed different parts of the integration.
That is evidence of developmental multi-platform coordination. It is not a demonstration that a combat CCA has completed carrier qualification. The distinction helps buyers ask a better question: which parts of the intended mission have been demonstrated on real hardware, which were simulated, and which remain assumptions?
For a future carrier team, the important interfaces extend beyond aircraft-to-aircraft messages. Mission planning, operator authority, track quality, communications loss and the return-to-ship process must fit into an air wing's procedures. A system that cooperates well in a controlled scenario may still impose excessive supervision when the network is degraded or the mission changes.
MQ-25 provides lessons, not automatic qualification
The Navy has already done relevant work with the MQ-25. Its December 2021 carrier demonstration evaluated taxiing, parking, catapult connection and clearing the landing area aboard USS George H.W. Bush. Deck operators used a control device while working with the ship's taxi directors.
Those tests provide a concrete example of how an unmanned aircraft enters a human flight-deck workflow. They do not prove that autonomous carrier operations have already been fielded at scale, nor do they transfer a qualification from a tanker to a different combat aircraft. Competitors should identify what procedures, interface knowledge and test infrastructure can be reused, and what their own design must demonstrate anew.
Boeing's MQ-25 experience is relevant to that discussion. Other aircraft and autonomy suppliers bring different experience. A defensible comparison examines evidence for the proposed configuration rather than ranking firms by a broad claim about naval heritage or software speed.
Share useful interfaces without forcing identical aircraft
The Air Force and Navy face overlapping autonomy questions, but distinct operating environments. Shared data definitions, evaluation scenarios and well-specified mission-software interfaces could reduce duplicated work while allowing different airframes and qualification paths. That is an architectural opportunity, not proof that the programs already share a software stack.
The acquisition team should identify where commonality reduces integration cost and where it creates a dependency on another program's schedule. An apparently common autonomy component can still require different assurance evidence when its sensors, operator interface or recovery constraints change.
Make the response useful to the requirement writer
Market research is an opportunity to explain where an intended requirement is feasible, costly, immature, or dependent on another program. A response that only promises compliance loses that opportunity. The government needs to understand which assumptions drive the proposed approach and what changes would materially affect it.
A supplier can organize its response around a few explicit distinctions: capability already demonstrated, evidence transferable from prior work, development still required, and information needed from the government. These categories help the customer compare maturity without confusing a future commitment with a completed result.
Where the public notice leaves a detail unresolved, state the working assumption rather than present it as a requirement. The response can explain the effect of a different assumption on integration, support, or schedule. This produces useful market information while avoiding premature investment around a specification that has not been established.
Plan a prototype that teaches the next decision
A prototype should reduce a defined uncertainty. If its purpose is unclear, a successful event can still leave the buyer unable to choose the next step. The program should know what evidence would justify continued development, a changed approach, or a narrower initial scope.
For carrier integration, the development plan should connect the different bodies of evidence already discussed: air-vehicle suitability, human workflow, interfaces, and support. Their individual results should remain distinguishable so that progress in one area does not obscure unresolved work in another.
This also improves schedule credibility. A plan that identifies the necessary facilities, government information, supplier contributions, and review decisions lets the parties see what must be ready for the next event. Merely assigning a date to the aircraft demonstration does not establish those dependencies.
Before the prototype decision, ask what the receiving program will know afterward that it does not know now. If the answer is only that the aircraft flew, the event may be too narrow for the decision being made. A well-scoped demonstration can remain modest while producing evidence directly relevant to the next investment.
Questions for a credible prototype response
- Define the configuration. Show the aircraft, shipboard interfaces and mission systems included in each demonstration.
- Separate evidence from plans. Label completed flight tests, simulated results and proposed carrier-suitability work distinctly.
- Expose margins. Track weight, power, cooling, structural and maintenance assumptions as the design matures.
- Demonstrate the human workflow. Include deck handling, operator handoffs, failure recovery and representative crew workload.
- Cost the operating system. Include support equipment, software sustainment, spares, training and integration alongside the aircraft.
The strongest response will explain how the Navy gets from a promising demonstration to repeatable shipboard operations. That path is where schedule credibility and long-term affordability are established.
Sources and further reading
- Navy CCA Increment 1 RFI record — market-research scope and notice history
- NAVAIR multi-platform autonomy demonstration — developmental evidence and participants
- MQ-25 carrier demonstration — deck handling and control workflow
Spartan X's engineering, logistics and program-execution disciplines address the work between a flight demonstration and an operating capability: interfaces that fit, support assumptions that hold and milestones tied to evidence.
