DON26BZ05-NV074 TITLE: Automated Post-Mission De-Brief and Re-Planning for Collaborative Combat Aircraft (CCA) Missions
OUSW (R&E) CRITICAL TECHNOLOGY AREA(S): Applied Artificial Intelligence (AAI)
COMPONENT TECHNOLOGY PRIORITY AREA(S): Advanced Computing and Software
PROJECTED CMMC LEVEL REQUIREMENT: Level 2 (Self)
The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), 22 CFR Parts 120-130, which controls the export and import of defense-related material and services, including export of sensitive technical data, or the Export Administration Regulation (EAR), 15 CFR Parts 730-774, which controls dual use items. Offerors must disclose any proposed use of foreign nationals (FNs), their country(ies) of origin, the type of visa or work permit possessed, and the statement of work (SOW) tasks intended for accomplishment by the FN(s) in accordance with the Announcement. Offerors are advised foreign nationals proposed to perform on this topic may be restricted due to the technical data under US Export Control Laws.
OBJECTIVE: Develop automated capabilities for post-mission debriefs that enable rapid re-planning for future missions. By leveraging advanced analytics, diagnostics, and algorithms, this program aims to enhance mission effectiveness and adaptability of Autonomous Combat Platform (ACP) operations in contested environments by utilizing advanced analytics, diagnostics, and algorithms.
DESCRIPTION: Modern naval operations require the ability to adapt swiftly to evolving threats, especially during multi-day missions involving ACP. Current post-mission analysis is resource-intensive and often too slow to provide timely, actionable insights for subsequent engagements. This program aims to automate the post-mission debrief and re-planning process for ACP missions to enable faster, more informed decision-making.
The primary objective is to develop automated capabilities for post-mission debriefing that facilitate rapid re-planning for subsequent missions. By leveraging advanced analytics, diagnostics, and algorithms, this program seeks to enhance the mission effectiveness and adaptability of ACP operations in contested environments. The solution must deliver actionable insights from mission data to inform re-planning decisions, optimizing tactics and operational parameters in real-time for the next engagement.
The solution will concentrate on developing algorithms and tools to analyze mission data, identify key performance metrics, characterize uncertainty, and generate explainable recommendations for subsequent mission planning. The main areas of emphasis include:
• Blue Force Optimization: Refining the operational parameters, autonomy behaviors, algorithms, task allocation, routing, tactics, and employment concepts of collaborative combat aircraft based on mission outcomes. Recommendations should identify expected mission benefits, survivability implications, operational constraints, and confidence in the projected result.
• Red Force Modeling: Improving mission planning and execution through analysis of adversary tactics, capabilities, threat profiles, observed behaviors, and likely future course of action. The solution should identify uncertainty in Red Force assessments and provide alternative threat interpretations where the available evidence does not support a single high-confidence conclusion.
• Autonomous Re-Planning: Use machine learning, data analytics, optimization and decision-support methods to generate and compare potential follow-on mission plans based on real world outcomes and lessons learned. The solution should recommend multiple feasible courses of action, identify associated confidence levels and operational tradeoffs, and provide traceable rationale to support operator review and approval.
This effort will also seek to answer the following critical questions:
• What data points are most crucial for effective post-mission analysis and re-planning?
• How can systems be designed to enable rapid, iterative updates to mission plans?
• What mechanisms are most effective for selecting and adapting algorithms in real-time based on the available data?
By tackling these challenges, the program aims to create a framework that streamlines post-mission analysis and enables rapid, intelligent re-planning for ACP missions. This will ultimately enhance the effectiveness and survivability of naval assets in high-stakes environments.
Work produced in Phase II may become classified. Note: The prospective contractor(s) must be U.S. owned and operated with no foreign influence as defined by 32 U.S.C. § 2004.20 et seq., National Industrial Security Program Executive Agent and Operating Manual, unless acceptable mitigating procedures can and have been implemented and approved by the Defense Counterintelligence and Security Agency (DCSA) formerly Defense Security Service (DSS). The selected contractor and/or subcontractor must be able to acquire and maintain a secret level facility and Personnel Security Clearances. This will allow contractor personnel to perform on advanced phases of this project as set forth by DCSA and NAVAIR in order to gain access to classified information pertaining to the national defense of the United States and its allies; this will be an inherent requirement. The selected company will be required to safeguard classified material during the advanced phases of this contract IAW the National Industrial Security Program Operating Manual (NISPOM), which can be found at Title 32, Part 2004.20 of the Code of Federal Regulations.
PHASE I: Outline the strategy for tackling the post-mission debriefing and re-planning challenges unique to ACP missions. This process involves choosing suitable artificial intelligence (AI) or machine learning algorithms, supported by a comprehensive review of existing literature and prior research.
The Phase I effort will include prototype plans to be developed under Phase II.
PHASE II: Develop the automated debrief and re-planning tools. Performers will implement their selected approach within a Navy-approved simulation environment, where they will demonstrate its effectiveness using multi-day mission simulations. The resulting solution must integrate seamlessly with existing ACP systems and include clear documentation for operational use.
Work in Phase II may become classified. Please see note in Description paragraph.
PHASE III DUAL USE APPLICATIONS: Transition the technology into operational systems supporting ACP and autonomous mission systems. It will be integrated with mission planning environments and autonomy framework to support the fleet.
Since industry leverages AI-driven solutions, it could easily adopt similar frameworks to improve commercial systems in the private/civilian sectors.
REFERENCES:
KEYWORDS: CCA; Autonomous Mission Planning; Post Mission; Blue/Red Force Modeling; AI Decision Support; Multi-Agent Autonomy
| 9/4/26 | Q. | When the post-mission data are insufficient to support a single re-planning recommendation, does the requirement to characterize uncertainty include withholding a recommendation and stating why, or must the system always return a ranked set of courses of action with confidence values attached? |
| A. | This is a great question - what level of confidence is sufficient for a mission commander’s interest? 95%? 80%? 50%? Should a tool allow mission commanders to configure a minimum level of confidence for responses? Should a tool decide this on its own? Should a tool always report a recommendation, even if it’s 5%?
We always want analysis – even if there is no current mitigation for a problem, we want the problem described in detail. As a toolset is refined, it should probably allow mission commanders to configure a minimum level of confidence for responses. Note that this is not a hard requirement; if the proposed design has a better way of providing useful information without confusing the mission commander with an overload of options, that design is of interest. We do not want the range space to be flooded with low-confidence responses, either. How can we serve our mission commanders without overburdening them with noise? We are leaving the details of this for our performers to research and figure out. |
|
| 9/4/26 | Q. | 1. The Q&A states that everything must be transferable to a secure system prior to running Government data, and that running Government data will be a requirement for Phase II. To design the Phase I architecture for that transfer, can the Government characterize the anticipated Phase II hosting environment — for example, a Government-hosted enclave (and, if so, its impact level or classification), a DCSA-authorized classified information system at the performer's cleared facility, or an air-gapped standalone system? Should performers plan to obtain an authorization to operate or interim authorization to test under a Government authorizing official, or to deliver containerized software for Government installation and accreditation?
2. For the LVC demonstration data that may be made available to Phase I performers, can the Government indicate: (a) the mission type represented (for example, combat air patrol/suppression, close air support, or maritime strike); (b) the data formats (for example, A-GRA-profile UCI messages, DIS/HLA recordings, IRIG-106 Chapter 10 files, or platform-native telemetry and logs); (c) the approximate scale (number of missions, mission duration, number of autonomous platforms); (d) its marking (CUI or unclassified) and any handling requirements for performers; and (e) whether schema documentation or a sample will be provided at award for the data set described as close to A-GRA but not compliant? 3. For performers planning Phase II implementation in AFSIM and/or NGTS, will the sponsoring program support the access paperwork — for example, by serving as the Government sponsor for an AFRL Information Transfer Agreement for AFSIM, and by furnishing the NGTS distribution, software development kit, Analysis and Reporting Tool, and standard user training as Government-furnished information, as has been done on prior NAVAIR topics? What lead time should performers plan for between award and access? 4. The public A-GRA specification includes a Mission Debrief (MD) interface volume alongside the mission-plan and mission-execution volumes. Should performers treat the MD interface volume as the reference for debrief-related data exchange with ACP systems, and do the Government's LVC data sets include MD-volume messages, or only mission-execution message families and platform telemetry? |
| A. | 1. Performers are expected to specify the system requirements for their design. Bear in mind, the final system must be able to operate on a ship. A minimum available capability would be an over-powered laptop. However, a system with significant demonstrable capability might be able to justify a larger physical presence and power requirements.
2. If we can provide the data by the end of Phase 1: (a) the mission type represented: CAP (b) the data formats: as noted in the source answer, non-compliant A-GRA with some platform-native logs (c) the approximate scale: 2 25-35 minute flights (d) its marking: CUI; performers must be trained to handle CUI data (e) whether schema documentation or a sample will be provided at award for the data set described as close to A-GRA but not compliant? We may be able to provide a schema – we’ll need to check data rights on that. However, the concern is over-reliance on a specific data format; the proposed system must be able to handle a variety of formats. If the design proposal can show automated or other simplified means of ingesting schemas, this may be of interest (assuming data rights can be provided). However, if inclusion of a schema requires software rework on top of data rights procurement, this becomes of less interest due to the sustainment issues. -Contrast this to inclusion of a tool that can begin analysis with the canonical A-GRA message standard and determine where there are deviations; issues such as data rights and schema integration become far less relevant. 3) Facility and access sponsorship happens on contract write-up via DD254. No set timeline is available, however past experience suggests a 30-90 day lead. 4) The MD interface in the ASK 5.0 ICD is defined as “debrief-relevant data sent on the ASB.” Given the loose definition, the implementation of this package will likely trail the mission execution messaging on fielded platforms. Where it is thoroughly implemented, it may be very useful; however, the MD interface might be dutifully reported to on some platforms, minimally reported on some, and completely ignored on others; in contrast, the vehicle, weapons and mission interfaces will always have data – a platform can’t do anything without those. A successful design will consider all available data. |
|
| 8/31/26 | Q. | 1 What hardware requirements should a performer consider for hosting this software aboard a carrier and for airborne incorporation? And what computing resources would be available in each case, and are they Government furnished?
2. Is there a required maximum elapsed time from mission completion to availability of re-planning output? If so, please state it as an objective and a threshold. 3. Will this deliverable have to take Level of Rigor into account and comply with sections of MIL-STD-882E? If so, what software safety level does the Government anticipate for this function? |
| A. | 1. Carrier: A carrier can host a powerful compute system if the need is significant enough to justify the cost, use of limited space and use of limited power. However, no “cloud” resources will be available; any proposed system must be deployable as stand-alone to be seriously considered. With regard to specifics, we are looking to your team to specify this – within the above constraints, what will work? Something that runs on an over-powered laptop is much easier to justify, but only if it produces demonstrable results. Would a mini-network with Jetson Thors tied to a controlling laptop work better for inference? Does your solution require a stack of blade servers and high-end NVIDIA cards? Your team needs to estimate this as a part of your research and let us know in the proposals.
Airborne: Airborne integration is out-of-scope for this request. GFE: Performers are expected to provide their own compute resources for project development. 2. We're looking at “sitting on the deck, prepping for the next flight" mission adaptations. Ideally, we would like to see results output and reviewed in minutes - the time it takes to refuel and relaunch the next flight group. However, that's probably not realistic right now: we understand that turn-around may be up to an hour or more for at least the next few years as the Fleet and industry work together to solve this problem. 3. With regard to Phase 1 deliverables, algorithm selection and a well-documented plan describing a solution that addresses all of the issues in the request should be considered the minimum deliverable for Phase 1. High-level design for the overall system and activity diagrams for algorithms are desirable. Note that a modest demonstration of prototype capability, while not a part of the minimum requirement, lends confidence in the ability of the performer to deliver a working system. We do not expect performers to conform to software safety for any optional Phase 1 prototypes. A final product (Phase 2 deliverable) that is used by a human operator will need the same software quality assurance that any Navy ground software system requires – the software must operate reliably and provide reliable results – but not to the level of a fully automated system. |
|
| 8/31/26 | Q. | 1. Who are the intended end users of the tool, and what will they use it on?
2. Are there other consumers of the data the tool produces who will not use the tool themselves? If so, who are they, and how will they use that data? 3. Will performers have access to the end users to learn about their needs? |
| A. | 1. Mission Commanders and Mission Planning personnel. Assistance from platform subject matter experts is assumed. Ideally, any above-normal (i.e., more than a powerful laptop) compute resource estimates should be included with the proposal design as noted in other questions.
2. Anyone doing analysis on the performance of the ACPs would likely be interested in the tool’s outputs, but the primary users will be mission planners and mission commanders. 3. Not for Phase 1 – mission commanders are hard to get a hold of. For Phase 2, it may be possible to set up meetings as the proposal’s concept and utility is proven. |
|
| 8/31/26 | Q. | 1. Where in the mission cycle is this capability intended to sit? Specifically, is the scope the post-mission debrief alone, the debrief feeding the next mission plan, or the full cycle through to readiness for the next sortie?
2. Is there a machine-readable record of what an aircraft was tasked to do, what it actually did, and the basis on which it made its own decisions? And separately, can a Phase I or Phase II performer access that record for missions already flown, or only for missions flown during the period of performance? 3. Is the intended scope unmanned platforms, manned platforms, or both? A manned aircraft produces no machine record of its own decision-making, so the available sources differ substantially between the two cases. 4. What manned-aircraft mission data is available, including debrief material and instrumented training range data, and is any of it reachable by a Phase I or Phase II performer? |
| A. | 1. Debrief feeding the next mission plan. As noted with other questions, we're looking at “sitting on the deck, prepping for the next flight".
2. “Machine-readable”: for autonomous systems, this would mean the A-GRA mission plan messages sent to the aircraft. That is received on the ASB and should be a part of the mission L1 logs, either through the C2, Peer or MP interfaces. As far as the mission intent, that possibly (not certain) could be made available – as written English. A proposal that requires previous mission records should note this requirement in the design; a proposal that can operate without previous mission results but whose performance would be enhanced by inclusion of such data should note this in the design, along with a clear explanation as to how this data would be utilized. 3. Collaborative Combat Aircraft and Autonomous Collaborative Aircraft as described in the DON26BZ05-NV074 request are all unmanned. 4. Manned aircraft mission data would not seem to be relevant to this request; its availability has not been planned. A proposal that requires manned data for its development should show how this data is used in its design to create a more successful solution. |
|
| 8/24/26 | Q. | 1. Of the three emphasis areas (Blue Force optimization, Red Force modeling, autonomous re-planning), should Phase I treat all three with equal depth, or is one considered the priority for this effort?
2. Is A-GRA format documentation (specification or ICD) releasable to offerors prior to award, or should Phase I designs be based on publicly available information and stated assumptions? During Phase I execution, does the government prefer periodic interim reviews or demonstrations with the TPOC, or a final report and prototype plan as the primary touchpoints? |
| A. | 1. All capabilities should be addressed; however, as a solution is designed and developed, it may be that one area can be developed more quickly. We certainly need a full set of capabilities, but that should not hinder your team from moving forward with a capability that works.
2. Offerors can see the latest version now. As noted in other question answers, it is at: Autonomy Government Reference Architecture (A-GRA) https://gitlab.com/open-arsenal/a-gra/standard Agile Mission Systems Government Reference Architecture (AMS-GRA) https://gitlab.com/open-arsenal/ams-gra/standard Note that overdependence on any standard will cause the solution to fail. 3. As long as minimum reporting requirements are met, a review schedule is left to the performer. |
|
| 8/24/26 | Q. | For the Phase I effort, should offerors assume post-mission data arrives as structured telemetry and mission logs in defined formats, or is a substantial part of the problem ingesting heterogeneous and partly unstructured debrief artifacts, so that data normalization itself should be treated as a Phase I research task rather than an interface assumption? |
| A. | The latter represents a reasonable statement of the problem to be solved. As an example, although our standard is A-GRA, already one of our existing data sets is not compliant; the mission debrief system should be able to ingest and analyze the non-standard data as well as the available telemetry from the onboard system. As noted with other answers, overdependence on any standard will cause the solution to fail - we expect to receive non-standard messaging. The mission debrief system should be able to ingest and analyze the non-standard data as well as the available telemetry and logs from the onboard system.
Data should normally be structured, but that structure is expected to vary significantly between platforms. |
|
| 8/21/26 | Q. | 1. What mission-data formats and interfaces will Phase II provide?
2. Which Navy-approved simulation environment is anticipated? 3. Is PMA-281's mission-planning environment the expected integration target? 4. Will CAMP capabilities/interfaces be Government Furnished Information/Equipment? 5. Which portions of A-GRA will be accessible to the performer? 6. What is the expected post-mission-to-next-mission planning timeline—minutes, hours, or sortie-cycle? 7. What level of autonomy modification is permitted: parameter tuning, behavior selection, model selection, or policy retraining? 8.Are weapons-employment recommendations within scope? |
| A. | 1. We expect to have data from several CUI autonomous systems Live Virtual Construct (LVC) demonstrations available. (LVC is live plus simulated assets). One of the data sets is close to A-GRA but it is not compliant; the mission debrief system should be able to ingest and analyze the non-standard data as well as the available telemetry from the onboard system. As noted with other answers, overdependence on any standard will cause the solution to fail - we expect to receive non-standard messaging. The mission debrief system should be able to ingest and analyze the non-standard data as well as the available telemetry and logs from the onboard system. Requirements such as an ICD should be clarified in the write-up. If the system is capable of performing a blind analysis (no ICD), an explanation as to how the data is interpreted should be provided as part of the strategy.
2. AFSIM and/or NGTS. Note that performers using these tools must be able to obtain the appropriate paperwork for access to the simulation environments. 3. the DON26BZ05-NV074 topic is on mission debrief for mission planning, it is unrealistic to expect performers to be familiar with mission planning standards that are both changing and often classified. On delivery, project output should be something that can be both understood by humans and easily adapted to a final format later in development. Human interpretation is critical; support for conclusions provided by the solution should be transparent. 4. No. CAMP is not associated with or relevant to this SBIR; information on that contract and/or capability will not be available. 5. Autonomy Government Reference Architecture (A-GRA) https://gitlab.com/open-arsenal/a-gra/standard Agile Mission Systems Government Reference Architecture (AMS-GRA) https://gitlab.com/open-arsenal/ams-gra/standard 6 Ideally, we would like to see results output and reviewed in minutes - the time it takes to refuel and relaunch the next flight group. However, that's probably not realistic right now: we understand that turn-around may be up to an hour or more for at least the next few years as the Fleet and industry work together to solve this problem. 7. Given the expected turnaround time, parameters and behavior selection are reasonable areas for immediate solution suggestions. However, it is acknowledged that many scenarios will require more extensive changes to an autonomous system’s capabilities to ensure success. While retraining, model selection changes and behavioral software updates should be recommended where appropriate, that action probably doesn’t help the immediate problem of how to survive the next group flight. Ideally, a solution should inform the major changes needed to properly solve the problem while still providing immediate solutions to the issue at hand. Note that those partial, stop-gap answers should come with transparency – mission commanders must understand both the immediate need and long-term solutions. 8. Yes, if the information is available. Note that other solutions should also be provided; mission commanders may not be able to change weapons pairing due to availability or rules of engagement. The proposed solution should provide that ideal answer, and then backups in case the preferred answer cannot be used. |
|
| 8/19/26 | Q. | A-GRA material: Is an unclassified A-GRA specification, schema, interface description, or representative example dataset available to Phase I offerors for development and demonstration purposes? |
| A. | The A-GRA is available on gitlab (note the specification linked elsewhere in this topic’s questions); however, overdependence on that standard will cause the solution to fail - we expect to receive non-standard messaging. The mission debrief system should be able to ingest and analyze the non-standard data as well as the available telemetry and logs from the onboard system. | |
| 8/19/26 | Q. | Must we build all the specialized algorithms? Would a common post-mission analysis and replanning framework be considered responsive if Blue Force optimization, Red Force modeling, and autonomous replanning are implemented as modular analytic components within the architecture, with the core platform providing data ingestion, outcome analysis, uncertainty characterization, COA comparison, traceable rationale, and operator approval? Or must the offeror independently develop all underlying optimization and threat-modeling algorithms? |
| A. | The framework as described in the question is a good summary of the requested solution. If a performer’s design requires threat modeling or other capabilities for development, they are responsible for this effort but are encouraged to use what their team is familiar with, including existing partnerships. | |
| 8/13/26 | Q. | 1. Phase I mission data and scenarios -
For Phase I development and evaluation, should performers assume they will create representative synthetic Collaborative Combat Aircraft mission scenarios using publicly available information and stated assumptions, or will the Government provide representative mission scenarios, mission data, mission assumptions, data formats, or other test material? If Government-provided material will be available during Phase I, what should performers assume will be provided and when?
2. Phase II mission data and simulation environment - For Phase II development and evaluation, should performers assume the Government will provide or make available the representative mission scenarios, mission data, mission assumptions, data formats, and Navy-approved simulation environment needed for multi-day mission testing? If not, which of these should the contractor plan to develop or obtain? 3. Commercial artificial intelligence use during Phase I - For Phase I development and evaluation using only public or synthetic mission information, may performers use a commercially available large language model or artificial intelligence application programming interface and then transition to a Navy-approved model or hosting environment for Phase II work involving Navy-provided mission information? If so, are there restrictions on the commercial artificial intelligence models, services, or hosting environments that may be used during Phase I? |
| A. | 1. A-GRA should be considered the baseline data format. For Phase 1, performers may use their own frameworks and scenarios for design and development; preferred missions are combat air patrol/suppression and maritime strike. Possibly for Phase 1 (depending on performer needs) and certainly for Phase 2, the government expects to have data from several CUI autonomous systems Live Virtual Construct (LVC) demonstrations available. (LVC is live plus simulated assets). One of the data sets is close to A-GRA but it is not compliant; the mission debrief system should be able to ingest and analyze the non-standard data as well as the available telemetry from the onboard system. Requirements such as an ICD should be clarified in the write-up. If the system is capable of performing a blind analysis (no ICD), an explanation as to how the data is interpreted should be provided as part of the strategy. Note that while a data set should come with an expected mission objective, a mission may deviate significantly from the original objective, especially if problems are encountered. A proposed analysis system should recognize and successfully adapt to such deviations and provide meaningful results.
2. A-GRA should be considered the baseline data format. For Phase 2, the government expects to have data from several CUI autonomous systems Live Virtual Construct (LVC) demonstrations available. (LVC is live plus simulated assets). One of the data sets is close to A-GRA but it is not compliant; the mission debrief system should be able to ingest and analyze the non-standard data as well as the available telemetry from the onboard system. 3. The performer may use whatever they have available with the understanding that everything must be transferable to a secure system prior to running government data; running government data will be a requirement for Phase 2. A designs that relies on components with known security issues or that cannot be run independently does not represent a useful solution to the problem. It should be noted that with regard to Phase 1 deliverables, algorithm selection and a well-documented plan describing a solution that addresses all of the issues in the request should be considered the minimum deliverable for Phase 1. High-level design for the overall system and activity diagrams for algorithms are desirable. A modest demonstration of prototype capability as suggested by the questions presented, while not a part of the minimum requirement, lends confidence in the ability of the performer to deliver a working system. |
** TOPIC NOTICE ** |
The Navy Topic above is an "unofficial" copy from the Navy Topics in the DoW FY-26 Release 5 SBIR BAA. Please see the official DoW Topic website at www.dodsbirsttr.mil/submissions/solicitation-documents/active-solicitations for any updates. The DoW issued its Navy FY-26 Release 5 SBIR Topics pre-release on August 5, 2026 which opens to receive proposals on August 26, 2026, and closes September 23, 2026 (12:00pm ET). Direct Contact with Topic Authors: During the pre-release period (August 5, through August 25, 2026) proposing firms have an opportunity to directly contact the Technical Point of Contact (TPOC) to ask technical questions about the specific BAA topic. The TPOC contact information is listed in each topic description. Once DoW begins accepting proposals on August 26, 2026 no further direct contact between proposers and topic authors is allowed unless the Topic Author is responding to a question submitted during the Pre-release period. DoD On-line Q&A System: After the pre-release period, until September 9, 2026, at 12:00 PM ET, proposers may submit written questions through the DoW On-line Topic Q&A at https://www.dodsbirsttr.mil/submissions/login/ by logging in and following instructions. In the Topic Q&A system, the questioner and respondent remain anonymous but all questions and answers are posted for general viewing.
DoW Topics Search Tool: Visit the DoW Topic Search Tool at www.dodsbirsttr.mil/topics-app/ to find topics by keyword across all DoW Components participating in this BAA.
|