What the Air Force's Cislunar AI Deadline Is Actually Filtering For

Two Notices, One Architecture

On November 2, the Department of the Air Force posted the Request for Information for a Cislunar Space System (Notice 10302026-01), seeking market research for up to five space vehicles operating throughout cislunar space, notionally to meet mission needs in late calendar year 2029. Responses are due November 24. The notice describes the vehicles as possible "seed vehicles" for a future proliferated cislunar constellation and says the government intends to award up to five firm-fixed-price preliminary design study contracts.

A week later, on November 9, the Air Force posted Special Notice 110926-2, "Request for Information (RFI) on Artificial Intelligence (AI) Uses for Cislunar Space Vehicle Operations". It seeks market research on AI and machine learning software for autonomous cislunar operations, and refers to AI as "Super Intelligence (SI)," the term Executive Order 14434, "Inaugurating the Era of Super Intelligence", signed September 29, 2026, directs executive agencies to use. White papers are due December 4.

The Cislunar Space System notice covers the platform: spacecraft bus, accommodation of a government-provided payload, integration and test, ground segment, launch integration, and operations and maintenance. The AI notice's memorandum covers software, which respondents should assume would be integrated into "Government furnished SV hardware developed on a separate effort." The AI notice does not name the Cislunar Space System as that hardware. The two share points of contact, though, and the spacecraft notice's own text asks bus respondents about their experience "using Super Intelligence (SI) to manage autonomous SV operations over extended durations" and the on-board compute and storage that requires. Our reading is that the two notices describe complementary layers of one emerging architecture.

Together, the notices pose a force design question: what does a persistent military presence in cislunar space take when distance and domain volume make continuous ground control impractical?

In March 2026, Tom Ainsworth, then performing the duties of the Air Force assistant secretary for space acquisition and integration, told the McAleese Defense Programs Conference that the service was "serious" about integrating cislunar capability and would be "standing up leadership positions and integration points" to bring those technologies in. The November notices are the formal market research that follows those remarks. They do not themselves show which positions have been filled.

Why 90 Days Is a Policy Decision, Not a Schedule

The AI notice sets schedule objectives rather than contract requirements, since it is market research. Those objectives are initial delivery within 90 days of Authority to Proceed and fully qualified flight software by ATP plus 18 months. "Initial delivery" is defined narrowly: the respondent's existing executable software baseline, validated in a software-in-the-loop environment. Platform integration and flight qualification follow within the 18 months. The notice prefers commercial off-the-shelf or near-commercial software "that would require no new model development and minimal training or adaptation," and states that the government "is not interested in investing in a cislunar SI research and development program."

That is the filter. A 90-day window to hand over a working, validated baseline is only achievable for software that already exists and has run somewhere analogous: autonomous navigation, fault management, onboard inference. Prior cislunar flight heritage is "desirable but not required"; heritage in other orbital regimes counts if the respondent shows it applies to cislunar dynamics.

The filter has a cost. When the Air Force buys commercial software adapted for a new environment, it takes on the burden of verifying behavior against conditions that cannot be fully reproduced before flight. The 90-day objective buys a baseline; the 18-month qualification period is where the gap between a vendor's demonstration and the government's operational need has to close. If that gap proves wider than 18 months, the program has a choice between accepting narrower autonomy at launch or funding the development it said it did not want.

The notice defines five technical focus areas: Autonomous Mission Management, Predictive Maintenance and Fault Isolation, On-board Trajectory Optimization, On-board Computer Vision, and other operationally relevant areas. In our assessment, the likeliest sources are vendors whose autonomy, fault-management or maneuver-planning software already runs on near-Earth spacecraft. The difficulty is that cislunar trajectories fall in what the notice calls "non-Keplerian regimes." Near the Moon, both Earth's and the Moon's gravity shape motion, so the two-body assumptions behind most near-Earth tools no longer hold. Applicability, not heritage alone, is what a respondent has to show.

What Autonomous Cislunar Operations Actually Require

The AI notice frames the core problem in one sentence: "Communication latencies that result from the increase in volume may mean that traditional, ground-based, command and control and mission planning systems are no longer scalable on operationally relevant timelines."

The latency at any single link is modest. NASA puts the Moon's average distance at about 384,400 kilometers, which works out to roughly 1.3 seconds of one-way light travel time. The notice's point is about scale. It cites the "orders of magnitude increase in the cislunar domain volume" relative to LEO, MEO and GEO. More volume means more distance, fewer sensors and relays per object, and more operator workload per vehicle. Autonomous mission management is not a single decision. It is a continuous loop of trajectory updates, sensor tasking and fault monitoring that, at constellation scale, ground crews cannot run step by step.

The companion spacecraft notice sets an operating objective of "Autonomous operation for at least 72 hours," alongside safe-mode capability, delta-V for orbit maintenance, and end-of-life disposal compliant with orbital debris mitigation standard practices. If the AI notice's software ends up on those vehicles, it would be what manages that 72-hour window, and potentially longer ones if communication is degraded or contested.

The demands are concrete in the AI notice itself. It asks respondents to describe processor architecture, peak compute performance, volatile and non-volatile memory, average and peak power, inference runtime, model size and quantization, parameter count and inference power draw. It also asks how a model would be updated, retrained or rolled back on orbit, and what happens when an updated model fails onboard validation. In our assessment, the navigation environment adds difficulty. Tracking infrastructure and object catalogs in cislunar space are far less mature than near Earth, and AFRL's Oracle program exists precisely to develop techniques for discovering and maintaining custody of objects there. Edge inference at these distances is a hardware-constraint problem as much as a software problem.

The notice also asks respondents to "identify any functions that assume ground reach-back or off-board processing, and describe the concept's behavior when those communication links are unavailable." A system that performs well with a continuous connection is not what this notice is screening for.

Oracle: The Near-Term Testbed

The Air Force Research Laboratory's Oracle family is the closest operational context for what the November 9 notice is asking. According to AFRL, Oracle-Mobility (Oracle-M) will focus on "operating and demonstrating mobility in cislunar space" and experiment with tracking known cislunar objects. Oracle-Prime (Oracle-P) is "a dedicated SSA experiment to detect and track both known and unknown objects," and AFRL plans to use onboard image processing to reduce downlink volume. Space Systems Command and AFRL completed Oracle-M's hot fire test at Edwards Air Force Base on March 16–21, 2025.

Oracle-M's launch has moved. Space Systems Command told Air & Space Forces Magazine that the payload stack including Oracle-M was moved from the Vulcan-launched USSF-112 mission to USSF-63, a Falcon Heavy mission, after Vulcan was grounded following a February 12 solid rocket booster anomaly. Aviation Week then reported on November 6 that the mission is now expected to launch in mid-2027 following the provider swap. Advanced Space, Oracle-Prime's prime contractor, says the spacecraft is on track for delivery in 2027, following a preliminary design review in December 2025.

The AI notice does not ask for Oracle-specific software. It asks whether commercial vendors can already supply an autonomy layer of the kind a future proliferated constellation would need. The Oracle missions will test how AFRL's navigation and tracking assumptions hold in practice; the December 4 white papers will tell the Air Force how close existing commercial software is to meeting them. Oracle-M's slip into 2027 means some of that flight evidence will arrive after the Air Force has already read industry's answers.

The Governance Layer That Isn't Keeping Up

The technical acquisition is moving. The authority framework for what an autonomous military spacecraft in cislunar space may decide on its own is moving more slowly.

Hypothetical example. A cislunar spacecraft executing routine orbit maintenance detects an uncharacterized object on an anomalous approach. Ground contact is interrupted. The onboard software must assess the approach, estimate collision risk, and decide whether to maneuver, a decision that could carry strategic weight if the object belongs to an adversary. We have not found a public U.S. government document that specifies what authority a spacecraft holds for that decision in that situation.

The policy that does exist points the right way without reaching this case. The Department of War's January 2026 Artificial Intelligence Strategy established "Agent Network," a pace-setting project for "AI enabled battle management and decision support, from campaign planning to kill chain execution." National Security Presidential Memorandum 11, signed June 5, 2026, directed the Secretary of War to update DoD Directive 3000.09 on Autonomy in Weapon Systems within 90 days, "to ensure the deliberate adoption of AI systems that respect the chain of command and operational authorities." In its September 28 report to the Senate Armed Services Committee, the Department described itself as still "updating the 3000.09 policy" as directed. Even once it is issued, Directive 3000.09 governs weapon systems. A space-domain-awareness spacecraft choosing whether to maneuver near an unknown object may fall outside it. Neither document, as published, addresses the case where communication limits make the authorization chain itself the operational problem.

This is not a reason to slow the acquisition. It is a reason for the acquisition team to treat AI qualification criteria as more than a performance specification. The qualification process should set, explicitly and in writing, the boundary between autonomous safety-of-flight decisions (collision avoidance, orbit maintenance, sensor management) and autonomous responses in contested situations where the spacecraft cannot confirm authorization. That boundary will shape test requirements, data rights and contractual liability. Setting it after the hardware is in orbit is a harder problem than setting it before contract award.

The credible alternative is to field the software in an advisory or tightly bounded closed-loop mode first, autonomous for navigation safety only, with contested-scenario decisions held for ground confirmation. The notice already distinguishes "advisory or closed-loop" operation when it asks about prior demonstrations. That approach makes sense if relay coverage proves adequate during the 72-hour windows or if on-orbit trust evidence is thin. It stops making sense when communication gaps grow longer than the threat timelines the spacecraft must respond to. Expect the Oracle flight data and early seed-vehicle experience to show which condition holds.

What a Strong December 4 Response Addresses

Vendors deciding whether to respond should answer four questions the notice actually asks:

What has the software demonstrated, and where? The notice asks for each prior demonstration's product and version, deployment or customer, orbital regime, processor and sensor interfaces, and whether operation was advisory or closed-loop. It says the government "intends to focus further engagement with respondents that demonstrate a mature approach using existing, flight-proven software." Architecture plans without demonstrated behavior are unlikely to advance.
What does it demand of government-furnished compute? Respondents are not asked to design hardware, but they are asked to state the processor, memory, power and model-scale load their software places on it. Treat this as a central section, not a footnote. A capability demonstrated at those constraints will compare better than a projected future optimized version.
How does it fail safely? The notice asks about safety bounds on model outputs, fallback when a trusted output cannot be produced, behavior under sensor dropout, runtime monitoring, and robustness to adversarial inputs. A response that answers these concretely is also answering the authority question above.
What is the data rights posture? The notice asks about "any anticipated data rights considerations" and about on-orbit model update and rollback. The government will likely want to validate, retrain and audit the software over its life. Intellectual property terms that make that hard will create friction in qualification even if they do not block an initial award.

The cislunar effort is in the phase where requirements form around what industry can demonstrate. The AI notice says the information "may be used to inform the potential development of DAF requirements," and the spacecraft notice warns that not responding may cost a firm the ability to take part in later acquisition. What vendors prove they can do, and what they acknowledge they cannot, will shape the requirements that follow.

The two problems at the center of this notice, inference that keeps working when the link drops and oversight that keeps an autonomous system within its permitted limits, are the same two Spartan X works on in other domains: BRIC, our edge platform for intelligence processing in contested, disconnected environments, and Arbiter, our AI assurance capability in development for monitoring behavior against configured expectations and escalating what falls outside them. The cislunar setting raises the stakes on both, and we expect the authority boundary to become a qualification issue well before it becomes a policy one.