Production awards and experimentation share the calendar
On June 17, 2026, the Air Force announced contracts for General Atomics' FQ-42 and Anduril's FQ-44, four months ahead of schedule. Secretary Troy Meink described a path to procure more than 150 combat-capable CCAs by the end of the decade, with an overall objective near 1,000. The separate mission-autonomy arrangement includes a six-vendor pool and initial competitive options for Anduril, RTX Collins Aerospace, and Shield AI. Air Force contract announcement
The service's September 14 naming announcement subsequently described June's Increment 1 production as covering 150 Vengeance and Fury aircraft. That supports the first-150 production discussion; it does not by itself establish a contractual ceiling or mean those aircraft have already been delivered. Air Force naming announcement
Air and Space Forces Magazine reported a $996.5 million FY2027 request to begin Increment 1 procurement; a budget request is distinct from an appropriation, an award, or accepted aircraft. Air and Space Forces Magazine
Moving from prototype activity into production contracts while experimentation continues puts several kinds of evidence on the acquisition agenda at once. The June announcement presents the aircraft as ready for full-scale manufacturing. That stated judgment should be distinguished from a conclusion that every later operational question has already been resolved. The program must track which findings support production, which support a particular configuration, and which remain part of ongoing assessment.
The live-fire test: what it validated and what it didn't
In its July 15, 2026 announcement, the Air Force described the first live-fire test of a Collaborative Combat Aircraft, firing an AIM-120 missile from the YFQ-44A Fury at a digital target in secluded airspace over the Mojave Desert. Gen. Dale White, the Air Force's direct reporting portfolio manager for Critical Major Weapon Systems, stated that the test validated digital integration models with actual data and demonstrated that the CCA could "execute the weapon employment sequence autonomously within pilot-defined parameters." AFMC, July 15, 2026
The account describes a bounded test and retains human authority over weapon release. Its accompanying image identifies the event as July 10; July 15 is the announcement date. The Air Force has been consistent that CCAs will not autonomously employ weapons — a human operator retains authority over the decision to fire. The official account describes earlier simulated data-link validation and the live-fire event as evidence supporting integration models. It does not publish a complete operational qualification record. Broader conclusions about performance or authorization would require evidence beyond this announcement. Official DVIDS republication
The test followed a deliberate sequence: inert captive-carry evaluations described in February 2026, followed by the live-fire announcement in July. Air Force, February 2026 announcement That sequence distinguishes stages of integration work. The public record should not be treated as a complete inventory of what has or has not been assessed; the acquisition question is which documented findings support the next release and fielding decision.
Program offices and contractors interpreting the AIM-120 test as proof of operational readiness are reading it too broadly. It is a genuine weapons integration milestone. The announcement alone does not establish a cleared operational capability.
ACE exercise: testing the logistics model
On July 20, 2026, the Air Force ran an Agile Combat Employment exercise at Creech AFB using the YFQ-44A Fury. The official caption says the exercise provided information necessary to validate generation and operation from a reduced forward logistics footprint — the basing model that the Air Force's distributed Pacific posture requires. The caption describes an effort to gather evidence for the support concept, rather than a complete fleet-readiness finding. DVIDS, 432d Wing, July 2026
The ACE concept is central to the strategic case for attritable systems. Expected attrition adds replacement capacity and manufacturing responsiveness to the support discussion. It does not eliminate the value of reliability, repair, spares, or availability measures. The program needs an economically and operationally justified balance between repairing an asset and replacing it. That balance can differ across components and circumstances.
Useful questions include the personnel and equipment needed to generate aircraft, the recurring maintenance burden, and the support required away from a main operating base. An exercise can inform those questions without proving every part of the intended logistics model.
The dual-source issue is also a support question. Two air-vehicle designs may introduce different equipment, training, and configuration requirements. The buyer should establish which resources can be shared and which remain platform-specific, rather than assume either complete commonality or unavoidable duplication.
Operational experimentation and a separate software marketplace
General Atomics' September 21 account describes delivery of Vengeance to Creech on September 18 and formation flight with an F-35A and F-15E. It describes preparation for collaborative-control operations. Those are meaningful developments, not evidence that every aspect of joint control or operational qualification has been completed. General Atomics account
September reporting also describes Anduril's disclosure of earlier Fury flights alongside F-35s at Creech. That remains an attributed report, with no assumption here that formation flight alone establishes full operational readiness. Contemporary reporting
The Air Force formally named the aircraft Vengeance and Fury on September 14. Its own announcement provides the naming record; the central acquisition issue is how the supported configurations evolve after these public milestones.
The June contracts make it inappropriate to assume each airframe will permanently carry a single supplier's mission-autonomy stack. The government-owned Autonomy Government Reference Architecture is intended to separate mission software from physical aircraft, and the service plans further software competition. Actual portability and compatibility must still be established for the relevant configuration. The management challenge is to know which combinations are supported, what evidence applies to them, and who authorizes a change.
Four acquisition challenges the program now owns
Mission-autonomy software lifecycle contracting. The Air Force structured CCA to separate the mission-autonomy software from the airframe, enabling competitive upgrades without replacing the aircraft. Realizing that advantage requires contract vehicles that support iterative software release, version control across a multi-aircraft fleet, and rollback procedures for software that produces unintended behavior in operational conditions. Contract terms should support those recurring responsibilities; fixed-price arrangements are not categorically unsuitable. DoDI 5000.87 establishes departmental policy for the Software Acquisition Pathway under applicable statutory authority. It is an instruction, not itself a statute, and does not alone resolve CCA's specific contracting choices.
Dual-source version management. Multiple aircraft and software providers create a configuration-management obligation. The program should identify common interfaces, platform-specific constraints, supported combinations, and the authority to approve updates. Evidence should follow the configuration rather than a supplier name alone.
Attritable O&S planning. Manufacturing surge and replenishment belong alongside maintenance, repair, and upgrade planning. The customer needs to compare these costs and capacity constraints instead of assuming an attritable fleet requires no depot or component support. Planning for an eventual larger fleet should preserve these alternatives while identifying resources needed for the initial deliveries.
Autonomy assurance for iterated software. Fielding autonomous aircraft carrying weapons requires demonstrable evidence that the autonomy software behaves as intended across the range of conditions it will encounter. The challenge is that for a software-defined fleet, "as intended" is a moving target across software versions. The test and evaluation infrastructure — hardware in the loop, scenario injection, regression testing across versions — needs to be designed as part of the program's ongoing architecture, not a one-time certification event. Each software update that changes decision-making behavior needs its own bounded verification before fielding. That recurring assessment is a cost acquisition leaders should identify explicitly; the public milestones alone do not establish whether current funding is sufficient.
Ask for a configuration record before a fleet total
A fleet count tells leadership how many aircraft exist or are planned. It does not show which software and support combinations can be accepted together. A useful program review should link each planned delivery group to its supported configuration, outstanding evidence, training material, and responsible support organization.
For a non-flight illustration, consider a shared maintenance application used by two equipment fleets. An update improves record handling for one fleet but requires a data-field change the other supplier has not yet supported. The buyer could retain the current release, approve a limited rollout, or fund the compatibility work before proceeding. The right choice depends on the value of the improvement and the burden of maintaining separate versions. It cannot be settled by calling the application open or portable.
That hypothetical exposes a practical contracting issue: someone must own the cross-supplier integration work. If every supplier has met its individual deliverable while the combined service remains unusable, the program needs an accountable integration owner and an agreement covering the missing work. Assigning that responsibility before delivery is less disruptive than negotiating it during acceptance.
For the next acquisition review, request three connected records:
- The delivery plan: aircraft or services expected, their dates, and the distinction between contracted, funded, delivered, and accepted quantities.
- The supported configuration: relevant versions, compatibility evidence, unresolved conditions, and release authority.
- The continuing support plan: personnel, training, spares, software assessment, and the funding responsible for keeping the configuration usable.
The review should allow a narrower delivery when it provides useful capability within an accepted scope, while making deferred work explicit. It should also allow a pause when a missing dependency prevents meaningful acceptance. Neither speed nor caution is the objective by itself; the objective is a delivery decision that the evidence and support arrangements can sustain.
Connecting these records makes delivery commitments easier to assess. CCA's compressed development and production schedule creates opportunity, but fleet totals alone cannot show whether the government can manage the resulting capability through subsequent changes.
Sources and further reading
- Air Force Materiel Command, "Air Force conducts live-fire test for Collaborative Combat Aircraft program," July 15, 2026: afmc.af.mil
- Defense News, "US Air Force awards first CCA production contracts to General Atomics, Anduril," June 18, 2026: defensenews.com
- Air and Space Forces Magazine, "Air Force Wants Nearly $1 Billion to Start Buying CCAs in 2027": airandspaceforces.com
- Air Combat Command, "Collaborative Combat Aircraft program progresses through deliberate weapons integration testing," February 23, 2026: acc.af.mil
- DVIDS, "YFQ-44A Fury Conducts Agile Combat Employment Operations at Creech AFB," July 2026: dvidshub.net
- The Aviationist, "FQ-42 Vengeance CCA Flies Alongside F-35 Lightning II and F-15E Strike Eagle," September 21, 2026: theaviationist.com
- DoDI 5000.87, "Operation of the Software Acquisition Pathway," October 2, 2020
Spartan X's AI assurance, systems engineering, and acquisition knowledge help connect technical findings with configuration, release, and support decisions. That connection is valuable when a program must preserve development speed while keeping the basis for each decision clear.
