Attachment to FA8750-23-S-7006 Technical Areas.docx

Attachment to FA8750-23-S-7006 Technical Areas

The Air Force Research Laboratory is soliciting white papers under this Broad Agency Announcement for research, development, integration, test and evaluation of technologies/techniques to support research in the following focus areas:

Technical Area 1. Command & Control of AI Systems to Achieve Mission Tailored AI

OPERATIONAL CONTEXT FOR PROJECT “BATTLE MANAGEMENT OF AI”

The Air Force Research Laboratory is soliciting white papers under Technical Area 1 for research, development, integration, test, and evaluation of technologies/techniques that augment battle management systems with novel control processes for adapting behavior of artificial intelligence (AI) capabilities during mission execution. The resultant “Battle Management of AI” will enable operators to reason through a complex space of competing design factors and mission dependencies to select and deploy AI components that are compatible with mission tactics and evolving battlefield conditions. This capability will provide AF tactical operations with an improved level of agility and responsiveness that is paramount for safe and effective utilization of AI-based warfighting systems.

Modern warfare has become increasingly dependent on AI-based warfighting systems that use trained models to perform tasks at speed and scales beyond human capacity. These AI-based systems can support a variety of functions such as classification of targets for ISR and control of autonomous vehicles for combat. Because models are trained a priori on data (and simulations) in an anticipatory fashion, AI-based systems encounter situations in the real world that are incompatible with training feature distributions and parameterization of employed algorithms. The result is degradation to model performance that can negatively impact mission effectiveness and safety. Therefore, the Air Force requires new battle management processes to monitor performance of AI-based systems and update incumbent models in response to changing battlespace conditions. In the trivial case, operators will simply repurpose a pretrained model that fortuitously fulfills unanticipated mission requirements. In the extreme case, operators will coordinate a distributed workflow, known as an AI COA, to retrain, test, and deploy new models in line with mission execution, so that dependent systems can continue to function as intended with minimal loss of service. This process to detect shifts in performance of AI-based systems and adapt models for new environments is analogous to traditional battle management during conflict, where assets are provisioned and dynamically revectored to prosecute new targets in short order.

Figure 1 demonstrates how our AI control functions for “Battle Management of AI” could be applied to an ISR use case. A new kind of battle manager within the forward tent, deemed the AI Interface Officer, monitors the performance of computer vision models hosted on UAVs and looks for cases of “AI drift” – unexpected behavior caused when the domain of the learned function is no longer compatible with input data. In this case, an object detection model is no longer performant with live sensor data due to significant changes from a weather event. The AI Safety officer must evaluate the risk to mission success posed by continued employment of the model. If the risk is deemed too high, the AI Safety Officer will coordinate with remote operators via cloud-based services to determine the root cause of the drift and propose new AI adaptation strategies (e.g., replace model, fine tune, transfer learn, etc.) and deployment options (e.g., “use uplink to replace model on UAV at 1500 hours”) that accommodate the environment while also adhering to imposed mission timelines. In order to select the most appropriate response option, we expect that operators will rely on a host of information including model drift severity, available algorithms and data, computing power, and available time windows for when UAVs can be serviced with new models, etc. Each response option has a cost in terms of time, resource utilization, and expected benefit. Our AI control processes must help guide operators toward the best solution given the circumstances at hand. Once a new AI deployment solution is selected, the task force can instantiate and execute a workflow to deploy the new AI capability in an expedient manner: in this case, a new object detector that has been refined to handle low luminosity and noisy images resulting from inclement weather.

Figure 1: Battle Management of AI concept. A forward-facing AI Safety officer observes a drift event during an ISR mission and issues a request for a new object detection model that accommodates the new environment – a rain event obfuscating red targets in EO range.

Although Figure 1 highlights a remote sensing use case, the monitor-adapt-deploy pattern generalizes to other classes of AI-enabled missions beyond perceptual learning for ISR. For example, operators could update control policies onboard autonomous collaborative platforms (ACPs) with improved skills to evade adversary forces or provide cover fire. Some alert mechanism, perhaps triggered by unacceptable platform attrition rates or poor mission performance, should help operators decide when and how to update the autonomy. For the ACPs, operators face the challenge to select the right combination of behavioral policies and perceptive capabilities (e.g., “eyes” and “ears”) that are compatible for the motor characteristics of the platform and mission tactics. Once operators converge on the most appropriate configuration, some test and evaluation, perhaps using simulation, will provide evidence that the new platform behavior is safe, effective, and appropriate given the field conditions.

In contrast to the workflow presented in Figure 1, much of the DoD’s AI is currently designed and built by data scientists in pristine “lab-like” environments with low-stress settings, where compute resources are plentiful, environments are static, and response timelines are akin to those in academia and industry. In these settings, there are few competing factors that engineers must reconcile – the mantra is always “the more, the merrier” with regards to data, GPUs, epochs, and performance. In contrast, battle managers of AI must operate in austere environments with limited resources. The team must quickly analyze a complex trade space of engineering options to balance model performance with available power, compute cycles, policy restrictions, and response deadlines. For example, operators might choose to train smaller models with less parameters in order accommodate short timelines at the expense of robustness and generality.

Additionally, AI is usually sandwiched within software stacks or embedded within complex hardware systems. Although end users may have direct access to AI inferences (output), such as bounding boxes for object detection and blobs of natural language in large language models, the underlying models are not typically available for inspection or replacement. Therefore, battle management of AI requires a new kind of software architecture that embraces portability and composability of AI models. Operators need white-box visibility into AI-based systems and new software interfaces to query, publish, and deploy ad-hoc models onto platforms during mission execution. With the right user training, interfaces, and control processes that provide white-box insight for both operators and engineers, we propose that AI can be managed much like other physical assets.

Note that we are not soliciting proposals related to communications hardware or communications networks to address the orchestration of Battle Management of AI processes. There is an overall assumption that current communications networks and hardware are sufficient to support the concept. Additionally, we are not soliciting proposals for the design and implementation of AI development frameworks – this market is already saturated with contributions from both open source and industry. We do, however, seek innovation for how to connect existing AI development frameworks within battle management control stations and workflows to configure the behavior of AI as described in Figure 1. Although heavy compute is generally needed for training modern AI, we are soliciting neither hardware nor server farms – the government has portable HPCs with enough GPU processing power to support a variety of different AI training regimes and access to these resources will be provided to offerors.

TECHNICAL CHALLENGES:

Fundamentally, TA1 will enable operators to command and control the application of AI to suit specific mission objectives and environmental conditions. AI adaptation and deployment must look and feel like warfighting – operators should have command of AI behaviors (TA 1-1), control of AI manufacturing and deployment processes (TA 1-2), and situational awareness of AI-enabled assets in the battlespace (TA 1-3). Figure 2 presents these requirements in the form of three technical subareas, which are organized according to different phases of our battle management process. Note that grey components of the diagram, although critical to the end-to-end process, are not solicited by this TA1 and serve only to inform the design of software interfaces for future integration. Additionally, offerors may propose solutions for individual components or the complete end-to-end process.

Overall, the three technical areas form an AI manufacturing feedback loop, where military doctrine and battlefield conditions work in tandem to inform the design and deployment of mission-tailored AI. The manufacturing process begins with TA 1-1, which consumes mission state information in order to derive model specifications, known as AI COAs. The primary challenge for TA-1 is to translate “mission speak” devoid of explicit AI requirements into technical specifications that are realizable and sufficiently detailed to guide the AI adaptation and deployment process. TA 1-2 consumes AI COAs and instantiates workflows to manufacture and deploy the requested AI capability onto host platforms. The primary challenge for TA 1-2 is to coordinate tasks among distributed agents (human and automated) that perform traditional AI development activities, such as model training, synthetic data generation, and simulation runs for testing. Finally, TA 1-3 monitors the behavior of AI-driven platforms and outputs alerts to TA 1-1 when performance falls below certain effectiveness thresholds. The primary challenge for TA 1-3 is to understand which conditions cause AI to underperform (drift) and to capture relevant system state and data samples for consideration in TA 1-1 and TA 1-2 during the next cycle of design, manufacture, and deployment. The following sections provide further details about each technical area.

Figure 2: TA1 project structure organized according to phase within the battle management of AI process. White graphics depict technical areas and interfaces that are solicited by this BAA. Grey portions depict technologies and capabilities that will either be provided to offerors or modeled (stubbed in) by the government in order to exercise the full end-to-end process. The gradient on the “Deploy” arrow indicates that offerors may rely on mock platforms in cases when access to real platforms is cost prohibitive.

TA 1-1: AI COA Design: will enable battle managers to efficiently explore a complex space of (possibly competing) AI deployment options, known as AI COAs. The technology should derive a trade space of functional and non-functional requirements that specify the behavior and deployment of mission-tailored AI. The technology must consider mission artifacts, such as ATOs, ACOs, ISR sync matrices, and field reports, to ensure that output AI requirements are both valid and feasible. For example, a sync matrix will contain available time windows for when an AI model can be uploaded to a robot, which bounds training and evaluation completion times, whereas the Size, Weight, and Power (SWaP) of host platforms will dictate attributes like model size and inference rates.

Figure 3 illustrates a small hypothetical AI COA space. When an automatic target capability (ATR) exhibits aberrant behavior, an operator must choose the best adaptation and deployment options to resolve the drift. Because each step has a local cost, the technology should help operators understand the overall compounded cost as it pertains to fulfillment of mission requirements and resource availability. The system must provide the right kind of information for operators to reason about the merits of each option. For example, the system could communicate tradeoffs in terms of model accuracy versus deployment readiness, assuming better models take longer to train and evaluate. Ultimately, the key challenge is to help operators assess the risks associated with each AI COA as it pertains to mission success. This is especially difficult for novel COAs that lack a precedent or other historical data that could provide an empirical basis for comparison.

Although Figure 3 illustrates COA dependencies as a graph, Visual Analytics has proven that large node-link diagrams are ineffective communication mediums. Thus, we seek novel presentation approaches that make the AI COA selection process look and feel like a declarative specification (what we want) rather than a prescriptive process definition (how to build it). The actual instantiation and execution AI COAs is reserved for TA 1-2 below.

Figure 3: AI Deployment Search Space. Each option to build and deploy mission-compatible AI has associated benefits and limitations with regard to the specific mission at hand. Operators must choose the best options that satisfy objective AI behaviors and which meet delivery timelines.

In summary, TA 1-1 must address the following technical challenges:

· COA Ranking - trade-off analyses for different AI adaptation and deployment options in terms of mission compatibility, risk, model robustness, and projected delivery timelines. The system should team with battle managers to help determine which composition of AI resources are most compatible with mission rules, regulations, platform allocations, and scheduling.

· COA Selection – an interface that enables battle managers to explore the information generated by COA Ranking. Battle managers will review and refine COA options until a satisfactory solution is achieved. When battle managers make a final selection, the COA information must be shipped off in a form that can guide workflow instantiation and execution in TA 1-2.

· Resource Inventory (baseline provided by the Government) - a metadata management system that provides operators with an “AI inventory”, such as available datasets (and synthetic data generators), algorithms, models, and host platforms. The metadata should be current and rich enough for operators (or algorithms) to compose AI COAs that are both realizable and compatible with mission objectives. The COA Ranking system will use the AI resource metadata as input for trade-off analyses. The Government will make available the GOTS “AI Passport” federation system as a technology baseline that manages access control for different classes of distributed AI resources.

TA 1-2: AI Model Production: will execute AI COAs that control the manufacture and deployment of mission-tailored AI in accordance with specifications from TA 1-1. The technology will instantiate mixed-initiative workflows to compose AI resources, such as training sets, algorithms, and platforms, that are distributed across local HPCs and remote cloud services. Operators must be able to coordinate workflow execution from within next-generation battle management stations, such as those supported by the Tactical Operations Center (TOC) family of systems. Therefore, TA 1-2 is largely an integration effort that will repurpose existing battle management concepts to control the “traditional” DevSecOps cycle. Operators will use command and control (C2) message sets (e.g., UCI and UC2) and routing infrastructure to coordinate activities for data gathering, training, evaluation, and model upload.

For automated tasks, such as model training and evaluation, the system can rely on both local and cloud-based resources, if available. The computing environment will depend largely upon specific mission use cases, which are open for discussion. For manual tasks, such as labeling data or approving the final deployment onto a platform, the technology should inform operators about specific work requirements and delivery deadlines through some tasking system. For example, prior to model deployment onto a platform, the system could provide risk assessment reports (input) to the operator, who in turn must make the final decision (output) for whether to “hit the deploy button”.

Once a newly manufactured AI model is approved and ready for deployment, the system should post model updates onto the host platforms, perhaps while in motion assuming sufficient comms. Platforms should expose software interfaces that enable operators to dynamically read, update, and delete models, much like standard Create-Read-Update-Delete (CRUD) operations for databases. For platforms (e.g., collaborative combat aircraft) that may be cost prohibitive to instrument with our required AI management interface, offerors can use surrogate platforms and stub interfaces that simulate upload or provide other evidence that a model meets the host platform SWaP requirements. Although TA1 is not soliciting procurement of new platforms, we expect offerors for TA 1-2 to develop adaptors and processes around open platform interfaces when provided by the Government.

The agents (human and automated) working various pieces of TA 1-2 will be distributed across both tactical and enterprise locations, thus making the execution process vulnerable to contested communications. However, for the sake of this TA, the offeror may assume adequate network and comms to support distributed workflow orchestration and execution. Although TA 1-2 is decentralized, the supporting technology should provide a centralized view of workflow execution status that provides forward operators in TA 1-3 with projected completion timelines.

In summary, TA 1-2 must address the following technical challenges:

· AI COA Execution – mixed-initiative workflow middleware that will manufacture, test, and deploy AI capabilities onto host platforms in accordance with AI COAs from TA 1-1. The system should support distributed environments and scale to service multiple requests in parallel while maintaining awareness about resource allocation and utilization. The system should also seize opportunities to reuse intermediate products, when possible, to preempt lengthy development pipelines. For scenarios that require access to data across different security classifications, the government will provide GOTs tools, such as Phoenix Prime and AI Passport, to mitigate the need for offerors to build guards and access controls.

· C2 of AI Messaging – an extension to existing command and control message formats (e.g., UCI and UC2) and routing infrastructure that enables battle managers to coordinate the execution of distributed AI manufacturing workflows. The messages should describe inputs and outputs for specific tasks as well as expected response deadlines. The messaging infrastructure should also allow operators using TA 1-3 to subscribe to key events for overall status tracking of process execution.

· CRUD for AI – APIs to control reads, updates, and deletion of AI models onboard weapons platforms from ground stations. The APIs can be tailored for specific platforms, data formats, and model implementations, such as ONNX for deep learning – the Government is not soliciting solutions that attempt to standardize AI datasets or models. If an offeror has access to weapons platforms, the Government will work with the offeror to establish the appropriate set of requirements to interface with onboard hardware.

TA 1-3 AI Common Operating Picture (COP) – provides situational awareness about the health, status, and location of deployed AI assets. Operators need to know when models begin to drift and understand what environmental conditions had the most impact on mission performance. Therefore, we anticipate the need for an AI Common Operating Picture (or AI COP) that provides information about a model’s hosting platform, physical location, historical performance, and provenance about model owner and training strategy.

The system should rely on both notifications from model drift detectors and field reports from operators who have had first-hand observations of AI’s performance. Because drift detection research is still in its infancy, TA 1-3 solicits frameworks to integrate existing (possibly rudimentary) drift detection methods as opposed to development of new state-of-the-art algorithms. The framework should have access to model provenance from TA 1-2 in order to support out-of-distribution detection algorithms that rely on a model’s training dataset. Also, the framework should define software interfaces to establish I/O requirements for different kinds of detection algorithms (e.g., MITRE’s Menelaus and SEI’s Auger) and enable plug-and-play functionality. Ultimately, the framework should aggregate reports from multiple detectors and operator feedback in order to trigger drift events when the system reaches consensus.

TA 1-3 also seeks to understand which kinds of diagnostic data from AI-enabled platforms is most important for drift detection and establishing behavioral requirements for subsequent AI adaptation cycles. For example, flight telemetry data from collaborative combat aircraft (CCA) in conjunction with field observations about adversary responses could help operators understand the environmental factors that caused the autonomy to behave poorly, which will influence the selection of AI COAs.

In summary, TA 1-3 must address the following technical challenges:

· AI Capability Tracker – combines traditional position-location information (PLI) for mobile weapons platforms with AI metadata for resident models, such as class of algorithm, model owner, drift reports, etc. The system should present this information using existing visualization frameworks and metaphors that are familiar to battle managers, who will determine whether incumbent AI should be replaced based on the performance of models and mission success. Once operators determine the need to update a model and trigger the next cycle of manufacture, the tracker should provide status information from TA 1-2 regarding productivity and expected delivery times.

· AI Monitoring – enables plug-and-play integration of drift detection algorithms and live performance feedback (i.e., ground truth) from operators. We anticipate that model drift may be passively detected through data analyses that run silently in the background or through active reporting from warfighters who are dissatisfied with the performance of deployed AI. The framework should output drift assessments to the AI Capability Tracker and, upon detection, gather drift evidence (e.g., data samples from ground station feeds) to help operators in TA 1-1 establish new AI requirements that accommodate new battlefield states. Additionally, operators and engineers working TA 1-2 can use offending data samples gathered from TA 1-3 as training or evaluation data to assess the performance of new models.

TA1 PROGRAM EXECUTION AND EVALUATION:

Due to lack of relevant simulation environments and/or virtual labs that can exercise the kinds of battle management processes required for TA1, the Government will conduct live experiments to assess completion of technical milestones on-site at different military exercises. Thus, offerors must be prepared to accompany the Government at exercises and demonstrations throughout the period of performance. The different exercises will each provide a unique environment that is relevant for testing some component of the battle management of AI process. For example, Project Convergence will afford offerors with a chance to test how well the system can respond to ad-hoc ISR requests in desert settings using small UAS, whereas Valiant Shield will provide opportunities to test adaptation of autonomy for larger platforms in maritime settings.

Figure 4: Progression of battle management of AI from a centralized team of S&Es supporting a single mission to a federation of S&Es and warfighters across enterprise and forward tactical positions supporting multiple missions. For each experiment we will subject our Task Force to varying degrees of stressors, such as workload, operator expertise, and available resources, and use observable measures, such as productivity, adaptability, and team elasticity to assess the utility of our underlying AI development framework.

Figure 4 shows how TA1 will use demonstrations to mature our battle management of AI concept from a baseline of S&Es conducting AI adaptation in a centralized location to our objective end state, where monitoring, adaptation, and deployment processes are controlled primarily by uniformed personnel across different stations. Each exercise will allow the Government to assess whether milestones have improved our initial set of KPPs, which are open for refinement and additions from offerors. The table below provides some high-level candidate metrics as examples of the sort of information that the Government is interested in measuring throughout the life of the program.

The Government may provide Government Furnished Software (GFS) for this technical area and subareas of the AI toolbox for related efforts.

Technical Points of Contact:

Dr. Nicholas Del Rio

AFRL/RISC

525 Brooks Rd Rome, NY 13441-4505 Telephone: (315) 330-3117 Email: nicholas.del_rio@us.af.mil

Mr. Milvio Franco

AFRL/RISC

525 Brooks Rd Rome, NY 13441-4505 Telephone: (315) 330-4541 Email: milvio.franco@us.af.mil

Technical Area 2. Federated, Composable Autonomy & AI Toolbox

The federated deployment and management of Artificial Intelligence (AI) holds vast importance for the United States and partners. The collaboration across AI tools and platforms is challenging due to the lack of common DOD and partner standards, classification boundaries, and the use of a diverse set of AI tools. The goal of this TA is to combine the technical expertise, resources, to develop tools, data, and suitable procedures to demonstrate the advanced federated deployment, and lifecycle management of AI capabilities to include but not limited to, development of common standards for data, algorithm, model, evaluation, and deployment of AI/ML capabilities, development and testing toolkits to enable third party development of AI/ML components and interoperability across a diverse set of AI/ML components, and workflow engine to facilitate orchestration, coordination, and composition of AI/ML components to form novel pipelines based on mission need. The underlying framework should be allow for federation of information and capability between new and existing AI/ML pipelines to include tracking of all metadata, data, and AI/ML sharing.

The emphases here, is on the development of collaborative federated AI tools (toolbox) and procedures that enable sharing of information, and raw data while in pursuit of common goal, while also ensuring the full compliance of policies and procedures of each federated partner. The AI toolbox should define the requisite interfaces and standards to allow third party to develop and contribute AI/ML components that encompasses all the stages, from data to AI capability, and incorporates communication and federation tools to support data and AI solutions. In essence, the toolbox must enable the composition of a wide variety of AI capability that can be stitched together to support diverse mission threads while not redeveloping or prescribing a single underlying AI/ML platform or tool.

Specific areas of interest for this TA include: (1) Shareable ML Models, and data representation, (2) Adaptable ML models, such as Low-shot & Interactive Learning (IL). The ability to adapt and train robust ML models in the presence of limited, incomplete, and dynamic data and operating environments is critical to all countries. (3) The federated, tailored, AI Common Operating Picture (AI-COP) to provide a shared view of all data, algorithms, and models resident with the joint toolbox. The COP provides warfighters with a comprehensive understanding of the tactical AI environment and helps the team to track capabilities, gaps, and productivity. (4) AI Management/Analysis that enables teams to optimize the time and resources used during ML data preparation, tagging, and training. (5) Federation and sharing of AI models, data, and tools that allows the best of AI resources across the federated environments.

The Government may provide Government Furnished Software (GFS) for this technical area of the AI toolbox for related efforts.

Technical Points of Contact:

Primary:

Lt. Andrew Porter

AFRL/RISB

525 Brooks Road Telephone: (315) 330-2290 Email: andrew.porter.13@us.af.mil

Seconardy:

Mr. Patrick Fisher

AFRL/RISC

525 Brooks Rd Rome, NY 13441-4505 Telephone: (315) 330-7424 Email: patrick.fisher.6@us.af.mil

Technical Area 3. Advanced Wargaming Agents

TA3 is removed as of Amendment No. 11 to the BAA and white papers are no longer accepted under it.

Technical Area 4. Interactive Learning for C4I

DoD faces significant data and human oversight challenges when attempting to employ AI/ML approaches to solving command, control, communications, computers and intelligence (C4I) problems. Interactive Learning (IL) is a data efficient ML approach that uses human in or on the loop to quickly train a model to make inferences. This approach is of interest to AFRL/RI in any situation where a user’s preference or intuition is required to solve a problem, and specifically encoding all necessary context to analytically solve the problem is infeasible.

As an example, AFRL/RI has implemented an IL approach that allows the users to interact with existing planning tools in a natural way via pairwise comparison of plan options. An AI agent observes the user’s interaction with the planning system and learns the user’s preferences for generating a “reasonable plan” that a user would accept. Essentially, the interactive learning agent asks the planning tool to generate a set of plans, using various planner input configurations or nudges, and presents the results to the use for ranking. This is akin to digital map giving the user two or three routes from start to destination and allowing the user to select which they prefer. This selection triggers the interactive learning agent to prompt the auto-planner to generate more plans in accordance with the users’ indicated preference, and then allow the user to evaluate those plans. This iterative process fits naturally into the iterative planning process, allows the user to focus on planning and not the mechanics of generating plans, allows the user to use their own experience and preference to obtain a good plan in accordance with their expectation, and leverages the speed of the machine. In addition to tactical planning, operational and strategic planning may be considered as well.

Planning is not the only area of interest for IL applications. Other applications may include but are not limited to intelligence tipping and queuing, course of action generation, image or spectrum analysis, hyper-parameter tuning, acceleration of high-fidelity modeling and simulation environments, and any DAF application of interest where human perception can be augmented via learning.

Submissions to this TA should include explanation of the query strategy (how you will solicit labels from the “oracle”) and the data efficiency of the approach (how your application will know which data to label).

Technical Point of Contact:

Daniel Carpenter

AFRL/RISA

525 Brooks Rd Rome, NY 13441-4505 Telephone: (315) 330-7121 Email: daniel.carpenter.5@us.af.mil

Technical Area 5. C2 Complexity Dominance

Challenges to fully realizing the DoD’s JADC2 vision include the inherent complexity in joint all-domain operations. While characteristics of modern warfare such as tempo, scale of operations, interdependency, and command structures all contribute to decision complexity encountered by the DoD, adversaries also experience complexity when engaging with DoD forces in a Joint All-Domain environment.

The C2 Complexity Dominance technical area is focused on research to exploit operational complexity. By judiciously enhancing the complexity encountered by adversary forces through non-cyber means, DoD forces can shape the adversary’s understanding of the battlespace and their ultimate decisions and actions to the DoD’s advantage. In particular, this technical area is interested in approaches to develop, model, deploy, and assess techniques to impose complexity on both human and AI agents on the adversary’s side, in order to ultimately shape the adversary’s decisions and actions.

Dr. Nathaniel Gemelli

AFRL/RISC

525 Brooks Rd Rome, NY 13441-4505 Telephone: (315) 330-3252 Email: nathaniel.gemelli@us.af.mil

Technical Area 6. Generative AI C4I

With advancements of large language models and generative AI, it is now possible able to generate answers as if curated by human, write poems & documents that are contextual, to writing executable code, and generating useful web pages. These advancements are already having disruptions across fields like education (i.e., students use ChatGPT to write essays), code development, natural language web search and other areas. Some of the drawbacks of commercial solutions are the generated results could be constrained due to policies, or inability to fine-tune models.

The interest of this TA is to explore potential advantages of utilizing generative artificial Intelligence (GAI) in the domain of C4I and DAF application through prototyping relevant use-cases hosted in IL 6> environments, guided by successful applications of GAI in academia and industry. More specifically, this TA is interested in the following areas: (1) Aggregate: Utilize unstructured data by exploiting latent embedding space learned by latest Generative Transformer architectures (ChatGPT). (2) Reason: Develop a mapping capability between learned concepts in the NLP domain to actionable plans expressed in temporal causal logic (scenarios generated in predefined markup [*] represented as event flow models). (3) Assess: Train GPT style models to aggregate IL>6 information to allow objective conditional probabilities (in contrast to probabilities of token occurrence) to be extracted from unstructured data. (4) React: Fill gaps in operational data through plausible generative sampling constrained by learned distributions (Stable Diffusion). In addition, this TA is interested in identifying novel DAF C4I generative use cases and rapidly exploring and assessing their efficacy on DAF data and environment.

Dr. Edward Verenich

AFRL/RISC

525 Brooks Rd Rome, NY 13441-4505 Telephone: (315) 330-2766 Email: edward.verenich.2@us.af.mil

Technical Area 7. Software Defined Distributed C2

Future contested fights with a near peer adversary will demand the need to command and control (C2) an increasingly dynamic set of time sensitive missions that are highly dependent on adversary, environment, and mission conditions. The evolving peer threat has created an operational reality that the Air Force (AF) must contend with; connected austere C2 nodes can be threatened and that communications avenues can be contested and degraded. This reality is driving the creation and adoption of Agile Combat Employment (ACE) Concepts of Operations (CONOPS) that are both agile and survivable by employing various adaptive basing strategies. These CONOPS have emphasized this inherent tradeoff between efficiency and resiliency in order to meet process execution timelines, balance resource utilization, and account for the capacity of distributed C2 functions.

The Software Defined Distributed C2 technical area is focused on research to optimize and orchestrate distributed C2 nodes with the associates C2 processes, functions, and resources that are distributed across the theater. By distributing C2 functions and resources through ACE CONOPS, the AF will increase the available resources and survivability of these resources. The challenge is fully realizing the AF’s vision of increasing capacity and resiliency through ACE. This technical area is interested in approaches to develop, model, and assess techniques of an orchestration logic to replace the manual lift of coordinating the execution of AF planning and operational processes across the distributed C2 nodes.

Another challenge is the expected contested operational environment that ACE is preparing for. A dynamically changing set of external factors like environment and intent of mission threads will require an approach that can orchestrate processes in execution, manage the complexity of shared resources and maximize the capacity and resiliency of the distributed C2 functions. This tech area is interested in technical concepts or proposed approaches that account for dynamic changes across the C2 nodes and apply a priority of process execution to enable the AF to efficiently utilize the distributed resources available in a contested environment.

Mr. Ryan Hilliard

AFRL/RISB

525 Brooks Rd Rome, NY 13441-4505 Telephone: (315) 330-2571 Email: ryan.hilliard.3@us.af.mil

Technical Area 8. Tactical AI

Secondary sensors distributed on the battlefield have untapped potential for DoD operations. The Air Force is heavily reliant on radiofrequency (RF) signal connectivity critical mission functions across all domains, creating a need for technologies to detect, reason over, and ultimately mitigate sources of interference. The Global Positioning System (GPS), for instance, is particularly susceptible to environmental occlusion, signal loss from multipath propagation effects, and intentional jamming and spoofing by an adversary. Mobile end-user devices already deployed and in operational use have sophisticated sensing capabilities that can be harnessed via the TAK ecosystem (Android Tactical Assault Kit (ATAK) and TAK Server) towards the detection and localization of signals of interest such as Global Navigation Satellite System (GNSS) jammers/spoofers, cellular jammers, gunshots, Wi-Fi, tactical radios, and civilian UAS.

The goal of this technical area is to develop, demonstrate, and assess the scalability of efficient command and control protocols and intelligent central control processes to enable distributed signal detection and geolocation. Approaches should consider factors such as client sensing duty cycle, proximity to other sensors, status of nearby devices, battery, performance optimizations, threat levels/posture, and reporting schedules. Scalability is a primary consideration, with application deployment environments ranging from the tactical level (tens to hundreds of devices joined by a TAK server) to the civil level (leveraging government-issued and managed devices numbering in the millions). Proposals considering AI/ML may employ TAK-ML, a machine learning framework designed to facilitate data collection, training, execution, inference, and deployment of ML capabilities in the TAK ecosystem, Sunshine Stacy

AFRL/RISC

525 Brooks Rd Rome, NY 13441-4505 Telephone: (315) 330-2537 Email: sunshine.stacy@us.af.mil

Technical Area 9. Mission Planning for Autonomous Collaborative Platforms (ACP) Operational Context for Project “Autonomous Aerial Mission Manager (A2M2)” The Air Force Research Laboratory (AFRL) is soliciting white papers under Technical Area 9 for research, development, and evaluation of technologies that enable re-tasking of Autonomous Collaborative Platforms (ACP) during missions in response to dynamic events, such as attrition of team members. ACPs include uncrewed, jet-powered aircraft that are designed to be semi-autonomous.[footnoteRef:1] They may leverage optimization, machine learning (ML), artificial intelligence (AI) and other techniques to perform a variety of missions, such as air-to-air and air-to-surface combat, electronic warfare, and intelligence, surveillance, and reconnaissance (ISR). Many current approaches envision that ACPs will operate alongside manned aerial platforms.[footnoteRef:2],[footnoteRef:3] Under these approaches, piloted aircraft will be responsible for the tactical command and control (C2) of ACPs.[footnoteRef:4] [1: Although the scenario discussed herein considers jet powered platforms, it could equivalently apply to small Unmanned Aircraft Systems (UAS), such as drones. See, for example, Borsari, F, “Rising Spider: Israel and Ukraine Change Warfare,” Center for European Policy Analysis, 16 June 2025.] [2: Gunzinger, MA, Stutzreim, LA, Sweetman, B., 2024, “The Need for Collaborative Combat Aircraft for Disruptive Air Warfare”, Mitchell Institute for Aerospace Studies.] [3: Penney, HR, 2022, “Beyond Pixie Dust: A Framework for Understanding and Developing Autonomy in Unmanned Aircraft,” Mitchell Institute for Aerospace Studies.] [4: Finnerty, Ryan, 8 July 2025, “F-15E and F-16C Fighters Control Four XQ-58s in US Air Force Tests”, FlightGlobal, F-15E and F-16C fighters control four XQ-58s in US Air Force tests | News | Flight Global]

However, some missions may pose extreme risk to pilots and high value airborne assets (HVAA) – the very resources charged with the tactical C2 of ACPs. For example, anti-access / area denial (A2/AD) zones may present denied, degraded, intermittent and limited (DDIL) operating environments (OE) that prevent contact with traditional C2 nodes. A2 / AD zones may also contain a proliferation of lethal and advanced adversary weapon systems that present high risks to piloted aircraft. Furthermore, highly contested environments may contain a multitude of threats, which require speed and scale to keep pace with an adversary’s Observe, Orient, Decide, and Act (OODA) loop.

ACPs may need to perform dangerous missions in limited geographic areas for a limited amount of time, with disrupted or non-continuous contact with C2 authorities. In these environments, there is a need to re-task ACPs due to team member attrition, in accordance with the last C2 guidance received and mission parameters provided by commanders. ACP attrition may be caused by the mechanical failure or attrition of ACPs, which requires the re-tasking of other ACP team members to perform high priority mission tasks that were originally assigned to the attrited members.

Autonomous Aerial Mission Manager (A2M2) We refer to a software system that is capable of on-board, autonomous re-tasking of a team of ACPs as an Autonomous Aerial Mission Manager (A2M2). The A2M2 will exist on-board ACPs and perform mission level C2 in response to dynamic events and in conformity with the last C2 directives for a limited geographic area and time window. The A2M2 will not perform flight control or path planning itself, however, it must be capable of interaction with, and provide input to, such on-board systems. The A2M2 will be located on-board each ACP team member, such that re-tasking decisions are made in a decentralized fashion to promote mission robustness in highly contested OE. See Figure 1 for a notional A2M2 OV-1.

Figure 1: Prior to entering a Red highly contested DDIL OE, the A2M2 receives C2 directives and tactical C2 guidance. It also receives an initial tasking. The A2M2 then enters a Red highly contested DDIL OE with intermittent input from tactical C2. The A2M2 re-tasks ACPs in response to ACP attrition in an assigned sector, as defined by C2 directives and guidance. After performing its mission and after comms are re-established, the A2M2 provides a mission debrief to C2.

The A2M2 will interface with a number of components. The final version of the A2M2 produced by this effort should be compatible with the Autonomy Government Reference Architecture (A-GRA), which standardizes autonomy interfaces for ACPs. The A2M2 will interface with the following:

· On-board sensor feeds

· Vehicle status inputs (e.g., remaining fuel and weapons, etc.)

· C2 guidance and directives (e.g., priority targets, acceptable attrition levels or ALRs, an assigned sector, time on target, etc.)

· Peer-2-Peer (P2P) messages

· Flight autonomy

· Path planning

· Mission de-brief Performers will develop:

· the A2M2 software (see below)

· code to enable simulations

· interfaces based on the above list

· messages that are compatible with A-GRA

· software that integrates the A2M2 with the M&S environment and A-GRA.

We seek innovative techniques that enable autonomous re-tasking of ACPs in response to dynamic events during missions. In this BAA, we are not soliciting white papers related to path planning, ACP flight control, formation control, evasive maneuvering, sensor orchestration, or control methods to manage contingencies related to on-board ACP system failures. However, the A2M2 must be capable of interacting with such on-board autonomy systems via A-GRA compatible interfaces.

The Government may provide Government Furnished Software (GFS) related to the Autonomy Government Reference Architecture (A-GRA) for related efforts.

TECHNICAL CHALLENGES:

There are a number of technical challenges involved in developing the A2M2. The challenges stem from the A2M2 design objectives and the OE in which the A2M2 will likely conduct its activities. The A2M2 will have three basic functions: (1) determine the need to re-task ACPs, (2) re-task ACPs, and (3) assess re-tasking performance. The functions correspond to three technical areas (TA), as described below.

TA 9.1: Determine the Need to Re-Task ACPs TA1 will produce three software interfaces / modules:

· an initial weapons-target assigner,

· an encoder (the Mission Encoder),

· a mission deviation identifier.

The A2M2 will generate an initial ACP tasking (i.e., a weapons-target assignment or WTA). The assignment will be on a 1:1 basis (i.e., one ACP per target). Performers can generate this tasking with centralized software algorithms. The government will provide key WTA parameters, constraints and the expected time available for the assigner to output a WTA. See Project Execution and Evaluation.

The A2M2 will also receive other input prior to initiating a mission. This information will include a prioritized target list, time on target, area of operation, number and composition of ACP team members, etc. Performers will encode this information into a common representation which is consistent with sensor feeds and messages received during a mission. This software module / interface is referred to as the Mission Encoder.

The mission deviation identifier will have two functions. First, it will identify ACP team member attrition and the emergence of dynamic threats. Dynamic threats include Red aerial platforms that were not detected or identified in time to be incorporated into a given day’s tasking order. This functionality will involve a continuous monitor of sensor feeds, C2 messages and P2P messages, and vehicle status inputs (a mission monitor).

Second, it will determine whether identified mission deviations (e.g., attrition or dynamic targets) require re-tasking. This decision is made in accordance with C2 guidance, constraints, and directives. For example, an ACP’s sensor feeds may inform it that a Red aerial platform exists within its assigned sector and time window. However, if the Red platform does not match a mission priority target list, then it may not require mission level re-tasking.

The Government may provide Government Furnished Information (GFI) for this Technical Area for related efforts.

TA 9.2: Re-Task TA 9.2 will produce two software modules / interfaces that generate P2P messages and a decentralized re-tasking algorithm.

The core of TA 9.2 will be decentralized re-tasking software that resides within the A2M2 on all ACP team members. The re-assignment must be free of scheduling conflicts and subject to C2 constraints (e.g., prioritized target list, time on target, area of operation, number and composition of ACP team members).

The decentralized re-tasking will be accomplished via P2P messaging between ACPs. The contested environment in which ACPs will operate will likely introduce communication latencies and imperfect information. These factors affect the number of platforms that can be managed by the A2M2, as well as the pace at which decentralized re-tasking algorithms converge to consensus. See the Key Performance Parameters under Project Execution and Evaluation.

The Government may provide Government Furnished Information (GFI) for this Technical Area for related efforts.

TA 9.3: Assessment TA3 will produce software / interfaces that provide feedback to TA 9.1 and TA 9.2. The assessment software must quantitatively determine if a revised plan is more effective than the original tasking, as impacted by dynamic events.