Atch 3 - DASH Statement of Objectives.pdf

BAA No. FA2384-26-S-B004, Joint All-Domain Transformational Model II Solicitation No. FA2384-26-S-B006, Decision Advantage Sprint for Human Machine Teaming (DASH) Event

Attachment 3

STATEMENT OF OBJECTIVES (SOO)

Decision Advantage Sprint for Human Machine Teaming (DASH) Event

Posture and Sustain Assets (PSA) Decision Function

1.0 OBJECTIVE

The Joint All Domain Persistent Adaptive Collaborative Technologies (JADPACT) Project seeks to develop Human-Machine Teaming (HMT) concepts that leverage AI/Automation capabilities to support Battle Managers. C2 Decision Advantage events provide support for the ABMS Transformational Model decision functions and an opportunity to learn about and explore many different AI/automation approaches for Battle Management. Furthermore, the events and R&D aim to ensure warfighter involvement in the development of AI/autonomy and further identify areas where autonomy would support Battle Managers. The goal is to include industry to ensure work being done to develop and adapt the latest, cutting-edge AI/automation approaches can be leveraged and adapted to the needs of Battle Managers. This will be accomplished by seeking unique and innovative solutions to accomplish the defined technical requirements.

2.0 SCOPE

The Combined Joint All-Domain Command and Control (CJADC2) Campaign Plan 2030 defines decision advantage as the ability to consistently make better, timelier decisions than the adversary. Current DAF command and control (C2) systems and processes are optimized for low intensity conflict and do not address decision advantage over the pacing challenge. Deriving effective C2 capability development toward decision advantage requires a clear understanding of what C2 decisions are. The DAF Advanced Battle Management System (ABMS) Cross Functional Team (CFT) provides a quantitative model for the Joint Warfighting Function of C2 as the Command, Plan, and Battle Management decision domains. Each of these decision domains are decomposed in the Transformational Model for Decision Advantage (TM-DA) using model-based systems engineering which bring these C2 decisions to light in a detailed manner.

2.1 TRANSFORMATION MODEL

The TM describes military decisions being made within a human-machine team (HMT), including specific choices within these domains and the battlespace information needed to inform said choices. Therefore, the TM provides foundational requirements for C2 decision-making that are universal (agnostic to time epoch, process, geography, organization, doctrine, among others).

Additional information on the TMs can be found at: SAM.gov

The Transformational Model – Battle Management (TM-BM) is comprised of 13 distinct and orthogonal subfunctions (Figure 1) deduced from the following operational environment (OE) assumptions/axioms:

• No entities exist in identical states simultaneously.

• Capability distributions in the OE are not uniform.

• The OE evolves over time.

• Information is incomplete and uncertain.

• Missions are difficult and resources are constrained.

https://sam.gov/opp/a6f8e78859cd45d294a8df70906c90f5/view

Attachment 3

Figure 1: Transformational Model – Battle Management Subfunctions.

In OEs where these assumptions apply (which will be the case for the pacing challenge), the TM-BM subfunctions explain the comprehensive set of battlespace information elements and decisions an HMT must make to battle manage the battlespace. Consequently, TM-BM reveals measures of performance and give structure to a design of experiments (DOE) that best characterize a battle management HMT. The resulting analysis delivers C2 decision advantage requirements to military capability developers and acquisition professionals through rigorous defensible analysis.

2.2 POSTURE AND SUSTAIN ASSETS

Posture & Sustain Assets (PSA) is how a Battle Manager readies assets they control to seize unpredictable opportunities in combat. PSA is the complement to Sequence BattleCOAs (SBC). Battle Managers perform these two types of thinking (a.k.a., cognitive behaviors the TM-DA calls Decision Functions) to determine what to do with assets ("BattleAssets") in an unfolding complex and chaotic battle. While SBC chooses what action to take with a BattleAsset now or in the very near future to achieve some active goal, PSA considers likely goals and actions a BattleAsset might be needed for and situates BattleAssets as optimally as possible for those potential but as-yet-unimplemented actions. Posturing and sustaining includes choosing locations, readiness states, and operational configurations. Examples of PSA location choices include: positioning on-call airborne Close Air Support (CAS) assets or Defensive Counter Air (DCA) assets so they can quickly respond to ground emergencies or air attacks respectively, even though there are no on-going emergencies or attacks yet; embedding inactive hacking code in a server for possible future use; and forward pre-positioning logistical supplies to various transit hubs for quick deployment even though requests for those supplies have yet to be issued. An example of a PSA readiness state choice is alert states for fighters at airbases, i.e., how quickly they can get airborne based on whether the pilots are in their cockpits or in the ops building, where the aircraft is on the flight line, and whether the engines are already running, etc. An example of a PSA operational configuration choice is the mode of operations for a surface-to-air missile system, i.e., are its sensors, algorithms, etc.

optimized for air threat detection and tracking or for ballistic missile threat response. To perform PSA with decision advantage, Battle Managers must account for and weight various uses that might be applied to BattleAssets and consider how the operational environment (OE) will react to any changes made by PSA, including enemy reactions. For this reason, PSA is where Game Theory figures into Battle Management most visibly, as there are costs and consequences for shifting BattleAssets before you use them in as much as there are benefits for optimal responsiveness.

2.2.1 The Core Information Transformations of PSA

A successful product for PSA must demonstrate the ability to continuously process three primary information categories.

Input Data (What the software receives)

The Transformation (What the software must do)

Output Data (What the software produces)

Anticipated Futures & Current States:

Gap Analysis & Mapping:

The system must map current

Posture Demand Signals:

Identifications of where

Attachment 3

Probabilistic models of what might happen (from the Improve Situational Understanding (ISU) Decision Function) + the current location, configuration, and readiness of uncommitted assets.

asset states against the requirements of multiple hypothetical, overlapping future scenarios to identify readiness shortfalls.

assets are out of position, in the wrong operational mode, or at an insufficient readiness tier to handle anticipated events.

Proposed State Changes & Resource Limits:

The posture demand signals + logistical constraints (e.g., fuel burn rates, transit times, maintenance cycles).

Trade-off Evaluation:

The system must evaluate the costs of changing an asset's state now (e.g., burning fuel to move, wearing down components, creating coverage gaps elsewhere) against the benefit of being perfectly postured for a potential future.

Cost/Benefit Valuations:

Quantified options representing the value of shifting an asset into a new readiness, location, or configuration state before it is actively tasked.

Valued Posture Options & Threat Models:

The proposed state changes + data on adversary collection capabilities and behaviors.

Counter-Move Assessment (Game Theory):

The system must assess how the adversary or the Operational

Environment (OE) will react to the act of re-posturing itself (e.g., will moving a radar to a new mode alert the adversary to our anticipation of their attack?).

Risk-Adjusted Posture Directives:

Finalized options for locations, readiness states, and operational configurations that balance future responsiveness against the risk of exposing intent or resources.

2.2.2 Required Functional Capabilities

To achieve the necessary information transformations for PSA, the system must handle three distinct categories of asset management. Contractors must demonstrate how their software service models and manipulates the following variables:

1. Location & Positioning Processing:

• The software service evaluates physical, logical, or network positioning for assets that are not currently executing an active strike/mission.

• Example Application: Moving airborne assets into specific orbits, pushing logistics to forward hubs, or pre-positioning cyber payloads in a dormant state.

2. Readiness State Management:

• The software service calculates the temporal distance between an asset's current dormant state and full mission capability.

• Example Application: Managing alert tiers (e.g., 5-minute vs. 15-minute alert) based on the likelihood of an impending threat, balancing crew fatigue and maintenance needs against response times.

3. Operational Configuration Shifting:

• The software service evaluates the hardware/software modes of an asset to ensure it is tuned for the correct anticipated threat.

• Example Application: Directing a multi-function sensor to shift from an optimal air-breathing threat configuration to a ballistic missile defense configuration based on shifting OE probabilities.

Attachment 3

2.2.3 Boundaries

The following functional boundaries must be considered:

• PSA is NOT a Scheduler: Software solution must not focus on routing assets to prosecute current, active targets. If the software is assigning a fighter to shoot down a known incoming missile, it has crossed into SBC. PSA's job is over once the active task begins.

PSA software must focus entirely on the pre-commitment phase.

• PSA is NOT a Sensor Fusion Engine: The software solution’s primary focus should be how our assets should be configured to meet forecasts. (Note: in an absence of an Improve Situational Understanding (ISU) service, contractor solutions will have to perform or account for parts of the ISU function pertaining to predictions of operational environment and adversary reactions to various posturing choices.)

• PSA is a Risk/Reward Engine: A core utility the software service provides is the ability to mathematically or logically justify the "costs and consequences" of shifting assets before they are used.

• PSA looks for broken symmetries: PSA decision opportunities emerge in the presence of the first three assumptions/axioms (from paragraph 2.1) in an OE. Consider a square-shaped area of operations (AO), with friendly and adversary forces evenly spread throughout, and where the probability of an engagement resulting in a call for CAS and maritime air support is also uniformly distributed throughout the AO. Since response time and duration of support are both heavily weighted in the value that CAS delivers to land and maritime forces, an optimal posture in this simplistic (and unrealistic) situation for two CAS-capable aircraft is in the center of this AO (location), together as a 2-ship for maximum mutual support (configuration), and ready to take off (mode of operations). This AO, so far, largely violates those three axiomatic assumptions because it is very symmetrical, so PSA doesn't have much to say versus the mathematically calculable "central-is-best" execution. However, if a battle manager receives information that a situation in the northwest corner of the AO is rapidly deteriorating for friendly forces, is that centrally-located, maximum-duration posture as ideal anymore even though the friendly forces in the northwest have not yet called for CAS? When battle management matters, there are no right answers. PSA considers the gamble of offsetting or inducing a deliberate bias based on what battle managers can infer about their AO before particular trigger actions occur. Consider the options the battle managers have to adjust the posture of their CAS assets:

• Both on the ground ready to take off, or both airborne, or one on the ground and one airborne

• Together as a 2-ship formation or separate locations and single-ships

• Various location options for ground (main operating bases, forward air refueling points) and airborne postures

There are tradeoffs with each permutation: airborne translates to quicker responses but shorter duration times since they'll have already burned fuel before being tasked; ground alert means longer response times but arriving with more playtime; split operations provide the ability to respond to more than one situation but elevates risk with the loss of mutual support. Now consider enemy reactions: launching (any) aircraft may trigger defensive action against the CAS assets; biasing support toward the situation in the

Attachment 3 northwest "shows our hand" in terms of friendly force understanding and may result in an unpredictable adversary pivot. Every proactive action in a battle is a gamble--that is not unique to battle management--however, battle managers are obligated to take rational gambles with PSA or the forces they control will miss fleeting opportunities to gain an edge over the adversary in unpredictable battles.

2.3 Scenario Context for PSA: The Contested Maritime Chokepoint Imagine a highly chaotic, experimental battlespace in a contested maritime chokepoint where adversary tactics are shifting unpredictably, and sensor data is heavily degraded by intermittent electronic warfare. A PSA software service is aware there is a 40% chance of a low-altitude drone swarm within the hour, a 35% chance of an imminent ballistic missile launch, and a 25% chance that the adversary is merely feinting to map our radar frequencies. An operator controls a pool of uncommitted assets: a loitering flight of fighters nearing their critical fuel state, a dormant cyber-defense node, and a surface combatant whose multi-function radar is currently optimized for air-breathing threats. The software service should continuously calculate the hidden costs and game-theoretic consequences of every proposed state change. If the system commands the fighters to aerial refuel now, it incurs a temporary 15-minute coverage gap; if it commands the ship to shift its radar to ballistic missile defense, it exposes a new electromagnetic signature to the adversary and becomes blind to the drone threat. In this volatile environment, the system is not scheduling active weapon strikes—it is operating as a continuous risk-engine, calculating the mathematical razor’s edge between preserving resources, masking intent, and posturing the force to survive whichever probabilistic future actually materializes.

3.0 TECHNICAL REQUIREMENTS

Emerging C2 solutions focus on decision support (i.e., system interoperability, information exchange, and information presentations, i.e., battlespace awareness/display) and do not directly address decision advantage (i.e., software that machine-assists/automates battle management decision-making). To win against a peer adversary, the joint force must achieve decision advantage by equipping C2 HMTs with automation to sort through complex and high-volume battle management decisions with faster tempo and improved decision quality.

3.1 DECISION ADVANTAGE SPRINT FOR HUMAN-MACHINE TEAMING (DASH) EVENT FOR

POSTURE AND SUSTAIN ASSETS (PSA) DECISION FUNCTION

The ABMS CFT (AF/A57RB) and Air Force Research Laboratory, 711 Human Performance Wing (711 HPW) will host a series of events. These events will conduct Research and Development surrounding the Transformational Model – Battle Management (Figure 1), with the function(s) varying for each event. For the upcoming DASH event, the focus will be on Posture and Sustain Assets (PSA) Decision function of the Transformational Model Battle Management.

The event is seeking the following from vendor’s proposals: 1) demonstrated understanding of the Transformational Model 2) alignment with the Transformational Model 3) technical feasibility and fit of software services that completes the Posture and Sustain Assets (PSA) decision function (see section 2.2).

During these events the contractor shall accomplish the following: Participating software development teams will travel to attend the event 13-23 July 2026 in Las Vegas, NV. The teams will witness a battle management crew making battle management decisions in a simulated combat environment for the specified decision function. The participating software developers will then

Attachment 3 apply the Transformational Model (the functional description of the decision function) and their creativity in applying a software service that helps the humans make faster and higher quality battle management decisions. Battle management warfighters will be teamed with coders to provide operational perspective and feedback. As part of the event, each team will have the opportunity to demonstrate how their software affects overall human-machine team decision making during culminating battle management scenarios. During these scenarios, each team will have opportunities to run their software addressing the specified decision function. Software solutions will be measured based on the number, speed and quality of decisions made by the Human Machine Team (HMT), alignment to transformational model, and depth/completeness. The software solutions shall utilize varied, structured and unstructured data streams, including but not limited to text chat, entity state streams and scenario data to inform their software solution. The contractor will be required to provide outputs specific to the decision function to the AFRL Digital Orchestrator via a defined REST API. The AFRL Digital Orchestrator output schema will be provided to notified selected contractors prior to the event. The contractor shall not be required to connect directly to other contractors’ services/software. Evaluation results and the list of participants will be shared with government stakeholders. Invited participants will retain their intellectual property (IP), including any changes made over the course of the week. Government stakeholders reserve the right to analyze all collected sprint data (including software performance and technical integration insights) to derive, refine and mature functional and technical C2 software requirements.

Crucially, offerors must describe their plan and technical approach for achieving a live, functional demonstration of their PSA software service during the DASH event. Proposals must explicitly detail how their solution is designed to:

1. Fit the requirements of the PSA decision function (as defined in section 2.2).

2. Process dynamic inputs: Ingest real-time, streaming data from the government's simulation environment.

3. Provide an output from the PSA service to a government provided API using government defined messaging schema.

The principal output of PSA is a set of posturing directions to alter/sustain asset locations, operating modes, and configurations. Contractors may approach this as a fully automated process, i.e., where the machine provides a single optimized answer for implementation, or a teaming process where the vendor's software presents posturing options in varying degrees of coherence for the battle managers to choose from. Contractors are responsible for providing UI tools for any such human-machine interactions. The primary goal is to demonstrate the offeror's readiness to function in a live, government-hosted ecosystem, not to deliver a final, static codebase for government acceptance at the conclusion of the event.

Prior to the event, the Government will Host an “Ask Me Anything” for the selected notified contractors to attend at their discretion. The pre-event meeting will be held virtually and will provide additional details on event logistics and provide the AFRL Digital Orchestrator output schema.

During the DASH event additional software development support may be provided virtually from remote locations, however access to live data from the event will not be available for remote support. In person participation is encouraged. Contractors can rotate or substitute on-site staff during the event if needed.

3.1.1 EXPECTED OUTCOMES

The government is not procuring a final software deliverable through this DASH event. Instead, participation will be evaluated based on the offeror's ability to successfully demonstrate the following key outcomes within the two-week event window:

Attachment 3

1. Demonstrated Functional Relevance: The tool demonstrably processes dynamic scenario data and provides outputs that are relevant to the targeted Decision Function

(PSA).

2. Contribution to Human-Machine Team Performance: The demonstrated outputs of the tool contribute to the overarching goal of enabling the human operator to make better, faster decisions. The tool should help the user process and make sense of a complex environment rather than simply presenting more raw data.

At the conclusion of the DASH, government assessors will record the outputs of each contractor’s solution and measure performance during a simulated run during which warfighters will complete a complex battle management scenario while using the solution. This record of demonstrated capability and a final outbriefing provided by the contractor will serve as the primary output of the event. No transfer of intellectual property or final code delivery is required under this agreement.

3.2 REPORTING

At the conclusion of each event, the Contractor shall compile findings within and deliver a presentation that includes a summary of the work that was conducted, any relevant metrics, and lessons learned, via a Test Scientific and Technical reports (CDRL A001)

4.0 DELIVERABLES

4.1 In addition to the reporting and data deliverables identified in the previous section 3.2 the Contractor shall deliver the following:

4.2 Software deliverables & schedule

During the event the contractor will be required to adhere to the government owned messaging standard and provide outputs to the Government Software System API. All messaging outputs will be recorded and available for future Government use.

5.0 OTHER REQUIREMENTS

5.1 SECURITY AND OPSEC

5.1.1 General Operations Security (OPSEC) procedures, policies and awareness are required in an effort to reduce program vulnerability from successful adversary collection and exploitation of critical information. OPSEC will be applied throughout the life cycle of the contract. The Critical Information and Indicator List (CIIL) and the 711th HPW OPSEC Plan will be provided upon request by AFRL/711HPW Information Protection Office. While working on the government installation, OPSEC guidance and OPSEC training will be provided by AFRL/711HPW Information Protection Office. This training will ensure contractors are familiar with 711th HPW’s CIIL and OPSEC Plan as it pertains to their contract. The contractor shall apply OPSEC in their management of their current program IAW AFI 10-701 Operations Security.

5.1.2 All contractor personnel require a minimum of a Tier 1 background check (T1)/SF85 for any position that requires access to the internet, use of automated information systems to cover standalone computers or unescorted entry into restricted or controlled areas prior to reporting for duty in support of any requirement. The investigation is not for a security clearance; it is for a position of trust. This is a mandatory requirement set forth in DoDM 5200.02_AFMAN 16-1405, Air Force Personnel Security Program. All documentation required for security certification shall

Attachment 3 be the responsibility of the contractor. (T1 required for CUI access, not for Public Releasable information).

5.1.3 All documents, including papers, abstracts and posters shall be cleared by AF prior to public release.

5.1.4 Highest Security Classification [Unclassified]

5.2 SAFETY REQUIREMENTS

5.2.1 The Contractor shall comply with all applicable federal, state, and local safety, occupational health and environmental regulations.

6.0 AFRL POLICY ON EMPLOYMENT OF NON-US CITIZEN CONTRACTORS

6.1 Contractor employees requiring access to USAF bases, AFRL facilities, and/or access to U.S.

Government Information Technology networks in connection with the work on this contract must be U.S. citizens. Possession of a permanent resident card (“Green Card”) does not equate to U.S.

citizenship. This requirement does not apply to foreign nationals approved by the U.S. Department of Defense or U.S. State Department under international personnel exchange agreements with foreign governments. Any waivers to this requirement must be granted in writing by the Contracting Officer prior to providing access. The above requirements are in addition to any other contract requirements related to obtaining a Common Access Card (CAC).

7.0 FEDERAL HOLIDAYS

7.1 The prices / costs in Section B of the contract include holiday observance; accordingly, the Government shall not be billed for such holidays, except when services are required by the Government and are actually performed on a holiday. The following days are contract holidays: New Year’s Day, Birthday of Martin Luther King, Jr., Washington’s Birthday, Memorial Day, Juneteenth, Independence Day, Labor Day, Columbus Day, Veterans Day, Thanksgiving Day, and Christmas Day.