Airmen are shaping the operating model
In its April 16, 2026 account of an Experimental Operations Unit exercise, the Air Force described EOU personnel working with the 412th Test Wing at Edwards on YFQ-44A sorties. The event combined operational and test authorities to develop procedures for deploying and sustaining CCA in contested conditions.
The operational contribution was substantial: Airmen generated and controlled prototype sorties and worked through practical procedures, including maintenance and preflight activity. Industry remained involved. The official imagery explicitly shows Anduril technicians working alongside EOU personnel, so operator-led experimentation should not be confused with a demonstrated absence of contractor support.
The Air Force called CCA a pathfinder for its Warfighting Acquisition System. The useful change is a tighter connection among operators, developers, testers, and acquisition teams. It allows a usability or sustainment problem to influence development before it becomes embedded in a fielded configuration.
For a forward operating concept, questions about setup, tasking, maintenance, and recovery matter as much as airborne performance. The operator should be able to recognize system state, understand limits, and perform the assigned task with the training and support actually available.
A later contract decision makes the software strategy explicit
A June 17 Air Force announcement, issued after this article’s original date, provides a concrete acquisition update. It describes engineering, manufacturing-development, and production contracts for General Atomics and Anduril air vehicles, alongside a separate six-vendor mission-autonomy pool.
The software pool comprises Anduril, General Atomics, Lockheed Martin, Northrop Grumman, RTX Collins Aerospace, and Shield AI. The service announced initial competitive production options for Anduril, RTX Collins Aerospace, and Shield AI, with further evaluation and a primary Increment 1 mission-autonomy selection planned for summer 2027. Those are distinct stages; a place in the pool is not the same as winning every subsequent option.
The Air Force also described a government-owned Autonomy Government Reference Architecture, with continuing compliance required for participating software vendors. Its stated purpose is to separate mission software from physical aircraft and support updates and portability. The announcement links licensing payments to delivered capability and operator feedback.
This gives the open-architecture discussion a tangible basis. A government-owned reference architecture can create room for competition, but actual portability still needs to be demonstrated on the relevant aircraft and configuration.
Interfaces and rights determine how fast lessons become changes
An operator may discover a better workflow or a missing function in one sortie. Delivering the change can involve mission software, flight controls, communications, sensors, and human interfaces. A well-defined boundary helps the team determine which elements need modification and which evidence must be renewed.
The customer should understand:
- Who controls each interface and its version history.
- What technical data and software rights support integration and sustainment.
- Which tools and test environments another authorized integrator can use.
- How compatibility and performance are checked after a change.
- Who accepts the residual risk and authorizes the resulting release.
Open architecture does not necessarily convey unrestricted rights to modify every proprietary component. Those rights and responsibilities must be established in the applicable agreements. Otherwise a nominally portable application can remain dependent on unavailable tooling or a single supplier’s release schedule.
Flight control and mission autonomy need separate evidence
General Atomics’ May 21 account of the YFQ-42A return to flight testing attributed the April 6 loss to an autopilot calculation involving aircraft weight and center of gravity. It described software remediation and a joint review before flight testing resumed. That supplier account concerns a specific flight-control failure; it does not establish that mission AI caused the mishap or that all software risk was resolved.
The distinction is useful. Airworthiness, vehicle control, mission planning, and adaptive behavior interact, but they require different evidence. A mission-autonomy system may follow a task correctly while relying on an invalid vehicle-state estimate. A flight-control system may behave as designed while the higher-level task is inappropriate for the operating conditions.
Evaluation should therefore trace the chain from human intent through task interpretation, system state, planned behavior, and observable outcome. It should also test what happens when one layer rejects a request or reports uncertainty.
Keep the feedback loop controlled
A practical release loop begins with a documented operator observation and ends with evidence that the change solved the problem without introducing unacceptable effects elsewhere.
- Capture the scenario, configuration, operator intent, and observed behavior.
- Identify whether the cause lies in software, interfaces, training, procedures, or hardware.
- Reproduce the issue in a suitable test environment.
- Evaluate the proposed change against both the original scenario and relevant regression cases.
- Record approval, deployment, monitoring, and rollback arrangements.
This approach makes experimentation cumulative. Teams can reuse knowledge across releases and distinguish a new failure from a known limitation. Independent challenge and adversarial testing add value where automated behavior may depart from intent, but agreement among several models is not by itself proof of correctness.
The wider market reinforces the need for this discipline. Rheinmetall’s June 2026 Ghost Bat presentation described a modular aircraft and a planned German adaptation with Boeing. Different platforms and national operating needs will place different demands on integration and support. Airframes remain consequential; reusable, well-assured software creates additional room to adapt them.
CCA’s acquisition experiment is valuable because it connects the operating concept to the product while both are still changing. The industrial advantage belongs to teams that can turn that learning into dependable capability at a repeatable pace.
Sources and further reading
- Air Force: operator-driven CCA exercise
- Air Force: June 17 CCA air-vehicle and mission-autonomy contracts
- General Atomics: YFQ-42A return to flight testing
- Rheinmetall: Ghost Bat at ILA 2026
Spartan X’s AI verification and systems engineering capabilities connect operational feedback with traceable software decisions. That work helps a program preserve the speed of experimentation while maintaining the evidence needed to integrate, release, and support autonomy.
