DSIP SBIR/STTR topics

The U.S. Army is seeking innovative force sustainment solutions from eligible small businesses across the U.S. through the xTech Kinetic Reach competition. This platform offers participants the opportunity to engage with the Department of War (DoW), earn prize money and submit a Direct to Phase II Army Small Business Innovation Research (SBIR) proposal. The U.S. Army FUZE xTech Program, in partnership with the U.S. Army Europe and Africa (USAREUR-AF) and Global Tactical Edge Acquisition Directorate (G-TEAD) is executing the xTech|Kinetic Reach competition as part of the G-TEAD Accelerated Capability Event (ACE) series. xTech|Kinetic Reach addresses the growing uncrewed aerial system (UAS) threat by identifying high-potential solutions and accelerating transition through funding and integration into live USAREUR-AF-led exercises. Integrating into a USAREUR-AF-led exercise is critical to: (1) validate capabilities under operationally realistic conditions, (2) inform acquisition and integration decisions, and (3) address near-term gaps in autonomous ground operations and effects delivery in contested environments. The Army recognizes that the DoW must enhance engagements with U.S. small businesses by (1) understanding the spectrum of world-class technologies being developed commercially that may benefit the DoW; (2) integrating the sector of non-traditional innovators into the DoW Science and Technology (S&T) ecosystem; and (3) providing expertise and feedback to accelerate, mature, and transition technologies of interest to the DoW.

xTech|Kinetic Reach is a focused open-topic competition designed to identify cutting-edge technology solutions that will drive significant advancements in military capabilities while addressing complex challenges and enhancing national security. In largescale combat operations, U.S. Army forces must sustain dispersed, continuously moving formations while operating inside highly contested environments characterized by persistent observation, long range fires, electromagnetic interference, degraded mobility corridors, and severely constrained logistics. Current sustainment and recovery methods rely heavily on manned systems that are increasingly vulnerable, slow to adapt, and unable to meet the demands of operations conducted near or within the Autonomous Zone. The Army requires a suite of interoperable, autonomous or minimally manned capabilities - spanning ground and air distribution, power generation, forward arming and refueling, and vehicle recovery - that can operate with minimal oversight, low signatures, reduced logistical burden, and seamless command and control (C2) integration. These capabilities must sustain tempo, reduce soldier exposure, and ensure survivability and mission continuity across the entire sustainment and recovery enterprise in high-threat, GPS and communications degraded environments where traditional methods are no longer feasible or survivable. The Army is seeking to evaluate capabilities that demonstrate performance in one of six (6) capability areas, and meet the following criteria for its capability area: Topic 1: Uncrewed Ground Payload Transportation Topic 2: Autonomous container Handling/Movement System Topic 3: Future Power Generation Topic 4: Autonomous UAV/UGV Forward Arming and Refueling Point (FARP) System Topic 5: Uncrewed Aerial Payload Transportation Topic 6: Uncrewed, Automated, Ground Recovery System Full competition details including details on these 6 topic areas of interest can be found in Appendix A section of the xTech|Kinetic Reach competition RFI here: https://www.xtech.army.mil/competitions/. xTech|Kinetic Reach is a focused open-topic competition designed to identify cutting-edge technology solutions that will drive significant advancements in military capabilities while addressing complex challenges and enhancing national security. In largescale combat operations, U.S. Army forces must sustain dispersed, continuously moving formations while operating inside highly contested environments characterized by persistent observation, long range fires, electromagnetic interference, degraded mobility corridors, and severely constrained logistics. Current sustainment and recovery methods rely heavily on manned systems that are increasingly vulnerable, slow to adapt, and unable to meet the demands of operations conducted near or within the Autonomous Zone. The Army requires a suite of interoperable, autonomous or minimally manned capabilities - spanning ground and air distribution, power generation, forward arming and refueling, and vehicle recovery - that can operate with minimal oversight, low signatures, reduced logistical burden, and seamless command and control (C2) integration. These capabilities must sustain tempo, reduce soldier exposure, and ensure survivability and mission continuity across the entire sustainment and recovery enterprise in high-threat, GPS and communications degraded environments where traditional methods are no longer feasible or survivable. The Army is seeking to evaluate capabilities that demonstrate performance in one of six (6) capability areas, and meet the following criteria for its capability area: Topic 1: Uncrewed Ground Payload Transportation Topic 2: Autonomous container Handling/Movement System Topic 3: Future Power Generation Topic 4: Autonomous UAV/UGV Forward Arming and Refueling Point (FARP) System Topic 5: Uncrewed Aerial Payload Transportation Topic 6: Uncrewed, Automated, Ground Recovery System Full competition details including details on these 6 topic areas of interest can be found in Appendix A section of the xTech|Kinetic Reach competition RFI here: https://www.xtech.army.mil/competitions/. The U.S. Army intends to award up to $1,500,000 in cash prizes throughout the competition. Up to 15 finalists will be selected at the conclusion of the Part 1 evaluation period and will be provided the opportunity to participate in the Part 2 live Soldier exercise, anticipated to occur in November 2026. Finalists who attend the Soldier exercise will receive a cash prize of $25,000, following the event. Finalists who also participate and have their technology integrated in the exercise will receive an additional $25,000, following the event. Following completion of the exercise, up to five (5) final winners will be selected to receive an additional cash prize of $150,000 each. Final winners may be considered for potential follow-on agreements and contracting opportunities. Part 2 winners that qualify as U.S. Small Businesses will have the opportunity to submit a Direct to Phase II Army SBIR proposal worth up to $2,000,000.

This topic is accepting Direct-to-Phase II submissions with a cost limit of $2,000,000 and a period of performance of 12-18 months. Only winners of the xTech|Kinetic Reach competition are permitted to submit a proposal for this topic.  In order for proposers to submit a DP2 proposal, they must provide the justification documentation to substantiate that the scientific and technical merit and feasibility described above has been met and describes the potential military and/or commercial applications. Documentation should include all relevant information including, but not limited to: technical reports, test data, prototype designs/models, and performance goals/results.

Produce prototype solutions that will be easy to operate by a Soldier. These products will be provided to select Army units for testing and experimentation with end Users in a realistic field environment. Feedback from testing and experimentation will be provided directly to Small Businesses to iterate rapidly on recommended modifications or improvements for Army operational use. In addition, companies will work with Army partners to develop a draft technology transition and commercialization plan for DoW and commercial markets.

Complete the maturation of the company’s technology developed in Phase II to TRL 8/9 and produce prototypes to support scaling and fielding of the technology with the Army and pursue commercialization pathways.

At white-paper stage, are the heavy-payload movement thresholds (e.g., 22,000+ lb, 250+ km) evaluated at the integrated-system level, such that maturity evidence may reference the host platform's demonstrated performance?

220VAC for commercial European power if a system needs to connect to an external grid. 

For Capability 1, is an offeror whose core contribution is the autonomy/software layer integrated onto a COTS or partner heavy-payload platform eligible to compete as a single applicant, or does this need to be structured and marked as an "integrated solution" on the registration page?

If a company has something that can add autonomy, task intelligence, and GOAT-net integration onto an existing POR vehicle, we’d like to evaluate that and can work the coordination to have the right GFE present at the evaluation event in November. However, I think it’s a fair assessment that the evaluation criteria will prefer integrated solutions to bolt-on ones.   Subject to the limits of our follow-on OTA, if a Vendor’s autonomy solution is better than another Vendor’s, but Vendor B has a better payload-movement capability, we’d want to make conditional offers subject to Vendor A and Vendor B partnering to pair their offerings prior to additional testing. 

The United States currently faces an "unprecedented" military buildup by China and increasing air and missile threats that demand a robust deterrent. However, the current inventory of long-range strike weapons is dominated by high-cost, low-volume systems or aging strategic assets like the Minuteman III, which dates back to the 1960s. The lack of a cost-effective, ground-launched payload delivery system prevents the Joint Force from achieving producibility at scale, leaving the U.S. vulnerable in high-intensity, multi-domain environments where high-end munitions would be rapidly depleted. The objective of this topic is to facilitate innovative research on low-cost, rapidly manufacturable, payload delivery systems.

The Department of War (DoW) is pivotally shifting toward "affordable mass" to counter peer adversaries who are rapidly expanding their military capabilities. While hypersonic systems offer high speeds, their exorbitant costs—exceeding $50 million per round—limit the military's ability to achieve the "magazine depth" necessary for prolonged conflict. This project proposes a ground-based, non-hypersonic, long-range precision payload delivery system that leverages low-cost production methods and commercial technologies to provide a scalable, high-volume alternative that is a tenth of the price of current high-end munitions. NOTE: The following topic number, ARM26BX04-DV011 – Ground-Based Affordable Mass (G-BAM), in this release is tied to a Defense Innovation Unit (DIU) Challenge Commercial Solutions Openings. The DIU G-BAM Challenge will be used to identify small business concerns that meet the criteria for a potential SBIR Direct-to-Phase II (DP2) award under this topic. Winners selected from the DIU G-BAM Challenge will be the only firms eligible to submit an SBIR DP2 proposal under this topic. Proposals submitted to this topic by non-winners of the DIU G-BAM Challenge will not be evaluated. How to Apply: Visit the DIU Open Solicitations page to read the full Challenge Announcement, topic details, and application instructions here: https://www.diu.mil/work-with-us/open-solicitations

This topic is accepting Direct to Phase II submissions for a cost limit up to $2,000,000 and an 18-24-month period of performance.

This topic is a DP2 topic. In order for proposers to submit a DP2 proposal, they must provide justification documentation to substantiate that the scientific and technical merit and feasibility described above has been met and describes the potential military and/or commercial applications. Documentation should include all relevant information including, but not limited to: technical reports, test data, prototype designs/models, and performance goals/results. This justification must be provided during the DIU G-BAM Challenge in order to be selected as a winner and eligible to submit a DP2 proposal under this topic The results from the DIU G-BAM Challenge demonstration event, will be used to determine eligibility for DP2. The objectives during Phase II are to produce prototype solutions that will be easy to operate by a Soldier. These products will be provided to select Army or other Department of War (DoW) units for testing and experimentation with end Users in a realistic field environment. Feedback from testing and experimentation will be provided directly to Small Businesses to iterate rapidly on recommended modifications or improvements for Army operational use. In addition, companies will work with Army partners to develop a draft technology transition and commercialization plan for DoW and commercial markets. Prototype capabilities sought include: Cost Efficiency: Cost-per-effect below $500K based on system reliability and mission success rate, with a sub-$250K all-up flyaway cost at scale.Producibility: Demonstrate a company manufacturing process capable of producing 100+ units monthly (1,200+ annually), or a credible path to that rate.Operational Range: Validate a ground-launched range with an objective of 600+ nm, consistent with DIU’s Area of Interest (AoI) Statement stated preference for extended-range effects.Employment: Should not require the Army to develop or modify other systems for employment. Should be a “plug and play” system that easily integrates with existing transport, targeting, and situational awareness systems. Payload: Deliver a payload capacity of at least 35 pounds, with a strong preference for greater than 100 pounds.Survivability: Demonstrate mission-capability in Denied, Disrupted, Intermittent, and Limited (DDIL) and electronic-warfare (EW)-contested environments.Reliability: Demonstrate reliability and mission success under representative operational conditions.

The sub-system technologies developed for low-cost, long-range payload delivery have significant applications in the civilian/commercial aerospace and logistics sectors. The artificial intelligence (AI) and autonomous navigation systems required for these munitions can be adapted for commercial cargo delivery drones and autonomous maritime vessels. Additionally, the push for additive manufacturing and rapid prototyping in the Indo-Pacific region to support these systems can revitalize domestic high-tech manufacturing, providing private companies with advanced production techniques that reduce costs for civilian infrastructure projects. Additionally, this space lends itself to the potential for development of low-cost alternate fuel technologies. Companies participating in the shoot-off are encouraged to propose tech development for manufacturing methods materials/guidance/seekers/alt propulsion, etc. to enhance their products. These are the primary opportunities for commercialization.

xTechSearch is an open-topic competition designed to identify groundbreaking technologies with strong commercial traction that may also provide game-changing capabilities for the Army. This competition will be used to competitively down-select up to 16 finalists who can submit a Phase I Army SBIR proposal for a potential follow-on award of up to $300,000.

The SBIR|STTR Program has aligned technologies that are experiencing rapid commercial traction with critical Army priorities into four portfolios of priority interest for this competition, each with core technology components identified. While xTech|Search encourages submissions aligned to the following SBIR|STTR portfolios and the associated core technology components, the program also welcomes proposals in any other technology domain with the potential to provide a disruptive advantage to the Army: Sensors: Electronic devices used to measure physical parameters, often enabling enhanced automation through the Internet of Things. Immersive and Wearables: Integration or extension of the real world through digital or simulated reality, such as augmented, virtual, and mixed reality. Wearables focus on smart electronic devices that can be worn by or attached to the user to gather data or provide insight during mission operations. AI/ML: Technology that incorporates human intelligence into machines (AI) and allows machines to learn from data without explicit programming (ML). Contested Logistics and Sustainment: Strategic and operational technologies that involve planning and executing the movement and maintenance of forces and materials under adversarial conditions. Note: The topic listed below is part of the xTech|Search 10 Prize Competition. See the full xTech|Search 10 competition RFI here: https://www.xtech.army.mil/competitions/. xTech|Search 10 will be used to identify small business concerns that meet the criteria for award. Finalists selected from the xTech|Search 10 prize competition will be the only firms eligible to submit a SBIR proposal under the topic listed above. Proposals submitted to the topic listed above by non-finalists or non-participants of the xTech|Search 10 competition will not be evaluated. 

This topic is accepting Phase I submissions for a cost limit of $300,000 and a 6-month period of performance. Only finalists of the xTech|Search 10 competition are permitted to submit a phase I proposal for this topic.Companies will complete a feasibility study that demonstrates the firm’s competitive technical advantage relative to other commercial products (if other products exist) and develop concept plans for how the company’s technology can be applied to Army modernization priority areas. Studies should clearly detail and identify a firm’s technology at both the individual component and system levels, provide supporting literature for technical feasibility, highlight existing performance data, showcase the technology’s application opportunities to a broad base of customers outside the defense space, a market strategy for the commercial space, how the technology directly addresses the Army’s modernization area as well as include a technology development roadmap to demonstrate scientific and engineering viability.At the end of Phase I, the company will be required to provide a concept demonstration of their technology to demonstrate a high probability that continued design and development will result in a Phase II mature product.

Produce prototype solutions that will be easy to operate by a Soldier. These products will be provided to select Army units for further evaluation by the soldiers. In addition, companies will provide a technology transition and commercialization plan for DOD and commercial markets.

Complete the maturation of the company’s technology developed in Phase II to TRL 6/7 and produce prototypes to support further development and commercialization. The Army will evaluate each product in a realistic field environment and provide small solutions to stakeholders for further evaluation. Based on soldier evaluations in the field, companies will be requested to update the previously delivered prototypes to meet final design configuration.

Prove a decision-as-a-program capability that turns complex engineering/acquisition questions into structured, auditable Decision Packages – faster, with higher confidence.

This topic will prototype and demonstrate a schema-driven Decision Management (DM) foundation plus a governed agentic AI layer that turns messy decision requests into auditable, signer-ready Decision Packages. The focus is proof by demonstration (not a full product build) to show the approach works for point trade studies and long-horizon acquisition decision programs with traceability, robustness, and human control. AI can process vast amounts of structured and unstructured data from Digital Engineering (DE) ecosystems, including digital threads and digital twins, enabling comprehensive analysis across the entire product lifecycle. Interoperability across models is achieved as AI integrates data from various DE tools (e.g., SysML 2.0, UML, etc.) and provides a unified view of system models, enabling cross-functional teams to collaborate effectively. The first objective is to demonstrate a unified representation that supports both (a) single-episode trade studies and (b) multi-episode "decision programs" with refresh cycles. This includes implementing context engineering specifically for the ground vehicle domain through knowledge graphs and semantic layers that capture domain-specific relationships, constraints, and requirements. The second objective is to implement agentic capabilities that produce structured artifacts and reproducible outputs, while maintaining human control and predictable behavior per established human-AI interaction guidance. AI will automate the validation of technical documents, models, and outputs, ensuring compliance with standards and requirements throughout the decision-making process. The third objective is to extend the schema so bias checks, risks, and assumptions are explicit, testable objects – so decision readiness can be assessed before sign-off and refreshed responsibly when conditions change. The system will leverage semantic understanding to maintain consistency across digital engineering artifacts and enable traceable decision rationale.

The Phase 1 Desired Outcomes are as follows: - A decision schema that makes objectives, options, constraints, assumptions, risks, and bias checks first-class objects - Agentic AI that: performs structured elicitation into the formal model, then generates decision workflow plans, and executes reproducible evaluation runs with clear “what flips the decision” logic - Two end-to-end demonstrations showing the approach scales from point-in-time trade studies to long-horizon program decisions with refresh cycles as evidence and assumptions change.

The DoW currently has multiple contractors developing AI/LLM tools for core warfighter purposes. However, little effort has been expended towards an AIgentics decision intelligence capability that supports accelerated commercial acquisition or longer lead traditional development. The DoW is agnostic as to a developed AI commercial package that fulfills adding AIgentics to current AI/LLM for Decision Intelligence for continuous acquisition. During Phase II it is expected that the successful contractor will develop a combined AIgentics and AI/LLM decision intelligence workflow capability with two cases provided from PAE Maneuver Ground and PAE Fires. This software platform needs to be modeled and developed as a commercial open-source platform that both the DoW and commercial enterprises would use for their Product Design & Development (PDD) and acquisition. The current COTS application, DAOSoft, provides an open capability that employs an advanced structured decision/trade study capability with a partially developed AI/LLM decision intelligence workflow. The Army is looking for any and all ideas that can extend or replace current acquisition capabilities and is agnostic to all current solutions. The successful Phase II prototype will be immediately useful, but it is also expected that the contractor would potentially execute follow-on Phase III contracts for individual customer installation. This would be similar to the current best practice deployment of large ERP systems from SAP and Oracle.

Potential commercial use cases include the vehicle design process for the automotive industry. The workflow can be relatively similar to the vehicle design process for the Army with some different considerations.

DAOSoft / architecture independenceThe Phase II description references DAOSoft as an existing COTS application while also stating that the Government is agnostic to current solutions. Is integration with, extension of, or compatibility with DAOSoft required or preferred, or may offerors propose an independent decision-management architecture that satisfies the topic objectives and provides open/interoperable interfaces?Phase I demonstration data/casesFor the two Phase I end-to-end demonstrations, may offerors use representative, synthetic, publicly available, or contractor-generated engineering/acquisition data and decision scenarios, or does the Government expect the demonstrations to use Government-provided PAE Maneuver Ground / PAE Fires data or specific acquisition casesPhase I demonstration scopeShould the two required Phase I demonstrations specifically represent one point-in-time trade study and one long-horizon decision program with refresh cycles, or may offerors propose alternative demonstrations that collectively demonstrate both capabilities?

DAOSoft is not a requirement! However, integration with DAOSoft or any decision workflow platform offerors choose will need to have connectivity, API(s), interfaces, etc. defined. Completing an Agentics decision capability with no workable interface created in Phase II would be an incomplete solution. The government encourages your innovation and places no restrictions on your software design nor integrated software solutionWe’re expecting PAE guidance on this point.  For Phase I, offeror generic documents are sufficientEither choice is intriguing! The  government supports a fresh innovative approach and is open to each offerors demonstration proposal.

Must the two Phase I demonstrations use Army-supplied data, or may they use publicly released Government documents?

We’re expecting PAE guidance on this point.  For Phase I, offeror generic documents are sufficient

The topic states the Phase II platform should be developed as a commercial open-source platform. Is open-source licensing a Phase II requirement, or one acceptable transition model among others, and how does the Government see that expectation interacting with SBIR data rights on the Phase I deliverable?

COTS is better, specific wording than open-source.  Offerors will own their own code, and the government places no restrictions on an offeror chosen distribution model.  Our hope is to avoid developing government code that does not have a commercial support and upgrade structure.  That was the primary reason we chose the open-source wording … to avoid government code maintenance and upgrading.  Remember, that the standard SBIR contract will require the offeror to provide an initial single copy for its use

May both required demonstrations (the point-in-time trade study and the multi-episode decision program) use offeror-constructed scenarios, or is a specific PAE Maneuver Ground or PAE Fires use case expected to be coordinated during the period of performance?

We’re expecting PAE guidance on this point.  For Phase I, offeror synthetic modeling is sufficient if PAE or PM data is not forthcoming

Is any Government-furnished documentation on DAOSoft's current structured decision and trade-study capability available to offerors, or should Phase I proposals treat DAOSoft as a named point of reference without further Government-provided detail?

DAOSoft is currently available through them directly at: https://www.daosoft.ai/.  DEVCOM - GVSC has a working copy on its engineering DREN network.  The current SBIR has a completely new focus, particularly towards Agentics AI. All offerors have complete freedom to base their workflow on their own chosen platform, integrate with DAOSoft, or replace DAOSoft.  We are looking at Agentics AI supporting increasingly rapid product decisions (both direct procurement and traditional development) as 100% new effort.

Reference data. Will Phase I offerors have access to representative, unclassified, non-proprietary trade-study or decision-program data from PAE Maneuver Ground or PAE Fires, or should the two required end-to-end demonstrations be built on offeror-constructed synthetic or analogous scenarios?

We’re expecting PAE guidance on this point.  For Phase I, offeror synthetic modeling is sufficient if PAE or PM data is not forthcoming

Is there an existing Army or DoD format, template, or governing regulation that a signer-ready Decision Package should conform to, for example a specified decision memorandum format or milestone documentation standard? If so, please identify it.

No.

Should the two end-to-end demonstrations address two distinct decision domains, or the same domain evaluated at two time horizons, one point-in-time trade study and one long-horizon program decision with refresh cycles? If the Government has a preferred decision domain for demonstration purposes, please identify it.

The demonstration(s) should be viewed as an initial and final synthetic/representative decision.  For both demonstrations, it would be the same decision question. Trade studies feed the program decisions with comparative and sensitivity analyses of the best or set of best alternatives.

May the Phase I demonstration be developed and executed in a contractor-owned commercial cloud environment using unclassified, non-CUI data? If CUI will be involved during Phase I, please confirm the safeguarding requirements expected beyond the basic safeguarding associated with the topic's CMMC Level 1 designation.

The government is expecting that the work will be open source and neither CUI nor classified

For the two end-to-end demonstrations described in the Phase I desired outcomes, will the Government furnish representative decision artifacts, such as trade study packages, decision memoranda, or digital engineering exports, for use as demonstration inputs? If Government data will not be furnished during Phase I, does the Government consider notional or publicly sourced analogues acceptable for demonstrating traceability and reproducibility?

The demonstration(s) should be viewed as an initial and final synthetic/representative decision.  For both demonstrations, it would be the same decision question. Trade studies feed the program decisions with comparative and sensitivity analyses of the best or set of best alternatives.  Notional or open source released acquisition data, review papers, etc. are all valid sources.

Does Phase I expect the prototype to integrate with a specific Government digital engineering environment, model repository, or authoritative source of truth, or is a self-contained demonstration environment acceptable at Phase I? If integration is expected, please identify the target environment or toolset.

Self-contained is acceptable

Should offerors construct representative synthetic acquisition cases for the two Phase I demonstrations, or does the Army anticipate providing scenarios or artifacts after award?

We’re expecting PAE guidance on this point as we go forward.  For Phase I, offeror generic/synthetic choices are sufficient

For the Phase II commercial open-source platform objective, which components does the Army expect to be openly available—for example, schemas, APIs, artifact formats, verification tools, orchestration code, or the complete application?

COTS is better, specific wording than open-source.  Offerors will own their own code, and the government places no restrictions on an offeror chosen distribution model.  Our hope is to avoid developing government code that does not have a commercial support and upgrade structure.  That was the primary reason we chose the open-source wording … to avoid government code maintenance and upgrading.  Remember, that the standard SBIR contract will require the offeror to provide an initial single copy for its use.

GROUND-VEHICLE DOMAIN CONTEXT ENGINEERINGThe topic specifically calls for ground-vehicle-domain context engineering using knowledge graphs and semantic layers. For Phase I, must the demonstration use Army-specific ground-vehicle ontologies, requirements, and relationships, or may offerors establish a representative ground-vehicle semantic model using publicly available or synthetic information?

No. We are hoping to learn from enterprise best practices

PHASE I PERFORMANCE / SUCCESS METRICSDoes the Government have specific measures or thresholds for evaluating “higher confidence,” decision-package quality, reproducibility, traceability, completeness, robustness, or decision-readiness during the two Phase I demonstrations, or should offerors propose appropriate quantitative and qualitative success criteria?

We don’t. We are open to any criteria advice provided from the awardees

PHASE II GOVERNMENT DATA / SECURITY POSTUREFor the two Phase II cases expected from PAE Maneuver Ground and PAE Fires, does the Government anticipate furnishing the necessary data, models, requirements, decision artifacts, and stakeholder access? If so, what classification, CUI, cybersecurity, or system-access posture should offerors anticipate beyond the currently projected CMMC Level 1 requirement?

For Phase II, the PAEs, through GVSC support will provide what is asked.  Given that we cannot require everyone to operate classified, the most likely approach would be to provide the Phase II awardees with a generic open-source example.  During Phase I, we will work with the PAEs to accomplish that and to provide guidance for what synthetic data the awardees may have to extrapolate

DAOSOFT RELATIONSHIP / INTEROPERABILITYThe topic identifies DAOSoft as the current COTS capability while stating that the Army is open to solutions that extend or replace current capabilities. Is interoperability with DAOSoft, including its schemas, interfaces, or existing decision artifacts, expected or desired during Phase I or Phase II, or may an offeror propose a fully independent architecture that satisfies the stated outcomes? 

DAOSoft is not a requirement! However, integration with DAOSoft or any decision workflow platform offerors choose will need to have connectivity, API(s), interfaces, etc. defined. Completing an Agentics decision capability with no workable interface created in Phase II would be an incomplete solution.  The government encourages your innovation and places no restrictions on your software design nor integrated software solution.>

TWO END-TO-END PHASE I DEMONSTRATIONSShould the two required Phase I demonstrations consist specifically of one point-in-time trade study and one long-horizon decision program with refresh cycles, or may offerors demonstrate those two operating modes through another configuration provided both capabilities are clearly shown?

The demonstration(s) should be viewed as initial and final.  It would be the same decision question.  Trade studies feed the program decisions with comparative and sensitivity analyses of the best or set of best alternatives

“WHAT FLIPS THE DECISION” EXPECTATIONFor the Phase I requirement to provide clear “what flips the decision” logic, does the Government expect a particular quantitative sensitivity-analysis methodology, decision-analysis method, or threshold framework, or may offerors propose and justify an appropriate reproducible method?

Multi- Attribute or Value Theory is probably the easiest and most understandable structure. Regardless, we want offerors to have their choice as to what the “best” approach is

HUMAN-AI INTERACTION GUIDANCEThe topic requires human control and predictable behavior consistent with established human-AI interaction guidance. Is there a specific Government, Army, DoD, or industry human-AI interaction standard or guidance document that offerors are expected to use during Phase I evaluation?

The evolution of AI standards is happening so fast, industry and government will probably not see a useful documented standard for some time, so the short answer is no.

DIGITAL ENGINEERING INTEGRATION EXPECTATIONFor Phase I, is the Government expecting live integration with specific Digital Engineering tools or model environments such as SysML 2.0, UML, digital-thread, or digital-twin systems, or is it acceptable to demonstrate the required interoperability through representative ingestion, normalization, semantic mapping, provenance, and traceability of representative DE artifacts?

Anything leaning into the use and exploitation of SysML/UML is useful, but particularly for Phase I, it is acceptable to demonstrate the required interoperability through representative ingestion, normalization, semantic mapping, provenance, and traceability of representative DE artifacts

PHASE I DATA AND REPRESENTATIVE USE CASESWill the Government provide representative ground-vehicle engineering/acquisition data, digital-engineering artifacts, decision-study inputs, models, or other test material for Phase I, or may offerors use representative public, commercial, synthetic, or contractor-generated data to demonstrate the required capabilities? 

We’re expecting PAE guidance on this point.  For Phase I, offerors may select their own representative data

COMMERCIAL OPEN-SOURCE REQUIREMENT / BACKGROUND IPFor the Phase II requirement that the software platform be “modeled and developed as a commercial open-source platform,” does the Government require the entire resulting platform and underlying source code to be released under an open-source license, including pre-existing contractor background technology, or may a contractor preserve proprietary pre-existing/background IP while providing Government-funded modules, schemas, interfaces, APIs, adapters, or other components under an open/open-source model?

COTS is better, specific wording than open-source.  Offerors will own their own code, and the government places no restrictions on an offeror chosen distribution model.  Our hope is to avoid developing government code that does not have a commercial support and upgrade structure.  That was the primary reason we chose the open-source wording … to avoid government code maintenance and upgrading.  Remember, that the standard SBIR contract will require the offeror to provide an initial single copy for its use.

For Phase I evaluation, will prior implementation or deployment of a Decision Intelligence platform for Army acquisition or ground-vehicle applications be considered an evaluation advantage, or will proposals be evaluated primarily on the technical merit and feasibility of the proposed Phase I research independent of prior implementation of the current capability?

Anyone who has done workflow development probably has a fair advantage based on practice in developing workflow. This is exactly why we mentioned ERP development/employment.  The previous SBIR answered earlier questions, but is not connected to this SBIR, which is solely focused on Agentics AI in the acquisition workflow.  We are actively searching for novel and practical solutions that will employ Agentics to improve and accelerate acquisition decisions.  Bottom line: proposals will be evaluated primarily on the technical merit and feasibility of the proposed Phase I research independent of prior implementation of the current capability.

The topic identifies DAOSoft as an existing COTS capability with a partially developed AI/LLM decision intelligence workflow and states that the Government is seeking solutions that may extend or replace current capabilities. The referenced SAE paper describes DAOSoft and indicates that the underlying work was funded under a prior Army Applied SBIR effort. Is the Government specifically seeking technical approaches that are differentiated from the existing DAOSoft architecture, or are enhancements and continued development of the existing DAOSoft architecture equally responsive to this topic?

DAOSoft is not a requirement! Howesver, integration with DAOSoft or any decision workflow platform offerors choose will need to have connectivity, API(s), interfaces, etc. defined. Completing an Agentics deciion capability with no workable interface created in Phase II would be an incomplete solution.  The government encourages your innovation and places no restrictions on your software design nor integrated software solution.

1. Phase I scenariosCan the performer choose the ground-vehicle decision used for the Phase I demonstrations, or does the Government want a specific scenario, vehicle type, or acquisition decision used?2. Phase I inputsCan Phase I use representative documents, data, and engineering-model exports selected or created by the performer, or does the Government want specific Army data, models, or file formats used?3. Final decision methodCan the AI organize the information and propose assumptions while transparent rules and calculations produce the final decision, or does the Government expect the AI itself to make the final recommendation?4. Phase I success measuresCan the performer define the Phase I success measures and targets, or does the Government have specific measures or targets it wants used?5. Ground-vehicle relationshipsCan Phase I represent ground-vehicle relationships, requirements, and constraints directly in the decision schema, or does the Government expect a separate knowledge graph or semantic-layer capability?6. Phase I demonstrationsCan the two Phase I demonstrations use the same decision question, with the second demonstration showing how that decision is updated over time, or does the Government expect two different decision questions?7. Army interviewsWill the Government help identify Army users and other stakeholders the performer can interview during Phase I, or should the performer find those participants independently?8. Open-source requirementFor Phase II, does “commercial open-source platform” mean the core DecisionTrace software must be open source, while the performer can charge for hosting, private deployments, integrations, support, and other services, or does the Government expect a different open-source model?

We’re expecting PAE guidance on this point as we go forward. For Phase I, offeror generic choices are sufficient. For Phase I, offeror generic documents are sufficient. We’re expecting that PM, HS and PM, Abrams will provide advice.  Currently, all decision cases are classified.  To make it fair to all offerors, we would need to extrapolate a generic, open-source unclassified example.We’re actively searching for novel solutions and fully support vendor best judgement here.  Regardless of your choice, you would need to give a little background on why you selected what you did so we can understand your logic.PAE guidance on this point as we go forward.  For Phase I, offeror generic choices are sufficient.We are neither expecting nor a separate knowledge graph or semantic-layer capability.The demonstration(s) should be viewed as initial and final.  It would be the same decision question. Trade studies feed the program decisions with comparative and sensitivity analyses of the best or set of best alternatives.Absolutely.  You can expect to not only talk with us, GVSC – representing S&T providers but also getting general input from our two supporting PAEs and PMs.  Given that we will have multiple award winners, and the very busy schedules of our stakeholders, we would plan a single, open, Teams-based event to meet with them for all Phase I award winners.COTS is better, specific wording than open-source.  Offerors will own their own code, and the government places no restrictions on an offeror chosen distribution model.  Our hope is to avoid developing government code that does not have a commercial support and upgrade structure.  That was the primary reason we chose the open-source wording … to avoid government code maintenance and upgrading.  Remember, that the standard SBIR contract will require the offeror to provide an initial single copy for its use.

xTechSearch is an open-topic competition designed to identify groundbreaking technologies with strong commercial traction that may also provide game-changing capabilities for the Army. This competition will be used to competitively down-select up to 16 finalists who can submit a Phase I Army SBIR proposal for a potential follow-on award of up to $300,000.

The SBIR|STTR Program has aligned technologies that are experiencing rapid commercial traction with critical Army priorities into four portfolios of priority interest for this competition, each with core technology components identified. While xTech|Search encourages submissions aligned to the following SBIR|STTR portfolios and the associated core technology components, the program also welcomes proposals in any other technology domain with the potential to provide a disruptive advantage to the Army: Sensors: Electronic devices used to measure physical parameters, often enabling enhanced automation through the Internet of Things. Immersive and Wearables: Integration or extension of the real world through digital or simulated reality, such as augmented, virtual, and mixed reality. Wearables focus on smart electronic devices that can be worn by or attached to the user to gather data or provide insight during mission operations. AI/ML: Technology that incorporates human intelligence into machines (AI) and allows machines to learn from data without explicit programming (ML). Contested Logistics and Sustainment: Strategic and operational technologies that involve planning and executing the movement and maintenance of forces and materials under adversarial conditions. Note: The topic listed below is part of the xTech|Search 10 Prize Competition. See the full xTech|Search 10 competition RFI here: https://www.xtech.army.mil/competitions/. xTech|Search 10 will be used to identify small business concerns that meet the criteria for award. Finalists selected from the xTech|Search 10 prize competition will be the only firms eligible to submit a SBIR or STTR proposal under the topic listed above. Proposals submitted to the topic listed above by non-finalists or non-participants of the xTech|Search 10 competition will not be evaluated.  

This topic is accepting Phase I submissions for a cost limit of $300,000 and a 6-month period of performance. Only finalists of the xTech|Search 10 competition are permitted to submit a phase I proposal for this topic.Companies will complete a feasibility study that demonstrates the firm’s competitive technical advantage relative to other commercial products (if other products exist) and develop concept plans for how the company’s technology can be applied to Army modernization priority areas. Studies should clearly detail and identify a firm’s technology at both the individual component and system levels, provide supporting literature for technical feasibility, highlight existing performance data, showcase the technology’s application opportunities to a broad base of customers outside the defense space, a market strategy for the commercial space, how the technology directly addresses the Army’s modernization area as well as include a technology development roadmap to demonstrate scientific and engineering viability.At the end of Phase I, the company will be required to provide a concept demonstration of their technology to demonstrate a high probability that continued design and development will result in a Phase II mature product.

Produce prototype solutions that will be easy to operate by a Soldier. These products will be provided to select Army units for further evaluation by the soldiers. In addition, companies will provide a technology transition and commercialization plan for DOD and commercial markets.

Complete the maturation of the company’s technology developed in Phase II to TRL 6/7 and produce prototypes to support further development and commercialization. The Army will evaluate each product in a realistic field environment and provide small solutions to stakeholders for further evaluation. Based on soldier evaluations in the field, companies will be requested to update the previously delivered prototypes to meet final design configuration.

Prove a decision-as-a-program capability that turns complex engineering/acquisition questions into structured, auditable Decision Packages – faster, with higher confidence.

This topic will prototype and demonstrate a schema-driven Decision Management (DM) foundation plus a governed agentic AI layer that turns messy decision requests into auditable, signer-ready Decision Packages. The focus is proof by demonstration (not a full product build) to show the approach works for point trade studies and long-horizon acquisition decision programs with traceability, robustness, and human control. AI can process vast amounts of structured and unstructured data from Digital Engineering (DE) ecosystems, including digital threads and digital twins, enabling comprehensive analysis across the entire product lifecycle. Interoperability across models is achieved as AI integrates data from various DE tools (e.g., SysML 2.0, UML, etc.) and provides a unified view of system models, enabling cross-functional teams to collaborate effectively. The first objective is to demonstrate a unified representation that supports both (a) single-episode trade studies and (b) multi-episode "decision programs" with refresh cycles. This includes implementing context engineering specifically for the ground vehicle domain through knowledge graphs and semantic layers that capture domain-specific relationships, constraints, and requirements. The second objective is to implement agentic capabilities that produce structured artifacts and reproducible outputs, while maintaining human control and predictable behavior per established human-AI interaction guidance. AI will automate the validation of technical documents, models, and outputs, ensuring compliance with standards and requirements throughout the decision-making process. The third objective is to extend the schema so bias checks, risks, and assumptions are explicit, testable objects – so decision readiness can be assessed before sign-off and refreshed responsibly when conditions change. The system will leverage semantic understanding to maintain consistency across digital engineering artifacts and enable traceable decision rationale.

The Phase 1 Desired Outcomes are as follows: - A decision schema that makes objectives, options, constraints, assumptions, risks, and bias checks first-class objects - Agentic AI that: performs structured elicitation into the formal model, then generates decision workflow plans, and executes reproducible evaluation runs with clear “what flips the decision” logic - Two end-to-end demonstrations showing the approach scales from point-in-time trade studies to long-horizon program decisions with refresh cycles as evidence and assumptions change.

The DoW currently has multiple contractors developing AI/LLM tools for core warfighter purposes. However, little effort has been expended towards an AIgentics decision intelligence capability that supports accelerated commercial acquisition or longer lead traditional development. The DoW is agnostic as to a developed AI commercial package that fulfills adding AIgentics to current AI/LLM for Decision Intelligence for continuous acquisition. During Phase II it is expected that the successful contractor will develop a combined AIgentics and AI/LLM decision intelligence workflow capability with two cases provided from PAE Maneuver Ground and PAE Fires. This software platform needs to be modeled and developed as a commercial open-source platform that both the DoW and commercial enterprises would use for their Product Design & Development (PDD) and acquisition. The current COTS application, DAOSoft, provides an open capability that employs an advanced structured decision/trade study capability with a partially developed AI/LLM decision intelligence workflow. The Army is looking for any and all ideas that can extend or replace current acquisition capabilities and is agnostic to all current solutions. The successful Phase II prototype will be immediately useful, but it is also expected that the contractor would potentially execute follow-on Phase III contracts for individual customer installation. This would be similar to the current best practice deployment of large ERP systems from SAP and Oracle.

Potential commercial use cases include the vehicle design process for the automotive industry. The workflow can be relatively similar to the vehicle design process for the Army with some different considerations.

1. Will the Government furnish a reference corpus or example program documents for the Phase I demonstrations, or should offerors plan to build their own?2. Will any decision case studies be provided for Phase I? If so, approximately how many, and in what form?3. Is any benchmarking data available on past decisions, meaning the decision as it was made and how it turned out? We are asking whether a Phase I demonstration can be scored against a known outcome or only against internal consistency.4. Is contractor performance data such as CPARS available as evidence within a demonstration, or should vendor performance post decision be treated as synthetic?5. If no data is furnished, does the topic office have a preferred ground vehicle program type or decision type it would like a synthetic corpus modeled on?

We’re expecting PAE guidance on this point.  For Phase I, offeror generic documents are sufficientWe’re expecting that PM, HS and PM, Abrams will provide advice.  Currently, all decision cases are classified.  To make it fair to all offerors, we would need to extrapolate a generic, open-source unclassified exampleSee 2. Synthetic. CPARS is not available for vendors.Any vehicles from the two PAE are of interest.  PM, HS has recent Paladin decision experience and PM, Abrams has recent M1E3 decision experience

Mr. Rapp, I'm Taylor Contreras, co-founder and CTO at Defense Catalyst. I have two questions on the topic: The Phase II section says the platform needs to be developed as a commercial open-source platform. Should we read that as open interfaces and data formats so other tools can work with it, or do you mean the source code itself would be open?For the two Phase I demonstrations on ground vehicle content, will the Government pick the decision cases, or do you want offerors to bring their own?Thanks for your time!Taylor

COTS is better, specific wording than open-source.  Offerors will own their own code, and the government places no restrictions on an offeror chosen distribution model.  Our hope is to avoid developing government code that does not have a commercial support and upgrade structure.  That was the primary reason we chose the open-source wording … to avoid government code maintenance and upgrading.  Remember, that the standard SBIR contract will require the offeror to provide an initial single copy for its use.The demonstration(s) should be viewed as an initial and final synthetic/representative decision.  For both demonstrations, it would be the same decision question. Trade studies feed the program decisions with comparative and sensitivity analyses of the best or set of best alternatives.  Notional or open source released acquisition data, review papers, etc. are all valid sources.

The U.S. Army is seeking innovative electromagnetic spectrum operations solutions from eligible small businesses across the U.S. through the Global Tactical Edge Acquisition Directorate (G-TEAD) U.S. Army Europe and Africa (USAREUR-AF) Accelerated Capability Event (ACE) 27-02: Spectrum Enabled Warfare Powered by xTech. This platform offers participants the opportunity to engage with the Department of War (DoW), earn prize money and submit a Direct to Phase II Army Small Business Innovation Research (SBIR) proposal. G-TEAD USAREUR-AF ACE 27-02: Spectrum Enabled Warfare Powered by xTech is a focused open-topic competition designed to identify cutting-edge technology solutions that will drive significant advancements in military capabilities while addressing complex challenges and enhancing national security. The U.S. Army FUZE Program, in partnership with the USAREUR-AF is executing the Spectrum Enabled Warfare competition as part of the G-TEAD Accelerated Capability Event (ACE) series. This competition addresses Army’s need to gain and maintain spectrum superiority by identifying high-potential solutions and accelerating transition through funding and integration into live USAREUR-AF-led exercises. Integrating into a USAREUR-AF-led exercise is critical to: (1) validate capabilities under operationally realistic conditions, (2) inform acquisition and integration decisions, and (3) address near-term gaps to sense, understand, exploit, attack, and protect across a contested electromagnetic environment and connected cyberspace. The Army recognizes that the DoW must enhance engagements with U.S. small businesses by (1) understanding the spectrum of world-class technologies being developed commercially that may benefit the DoW; (2) integrating the sector of non-traditional innovators into the DoW Science and Technology (S&T) ecosystem; and (3) providing expertise and feedback to accelerate, mature, and transition technologies of interest to the DoW.  NOTE: The following topic number, ARM27BX01-DP001 in this release is tied to an Army xTech prize competition, G-TEAD USAREUR-AF ACE 27-02: Spectrum Enabled Warfare Powered by xTech. This xTech Competition will be used to identify small business concerns that meet the criteria for a potential SBIR Direct-to-Phase II award under this topic. Finalists and final winners selected from the G-TEAD USAREUR-AF ACE 27-02: Spectrum Enabled Warfare Powered by xTech prize competition will be the only firms eligible to submit an SBIR Direct-to-Phase II proposal under this topic. Proposals submitted to this topic by non-finalists and non-final winners of the G-TEAD USAREUR-AF ACE 27-02: Spectrum Enabled Warfare Powered by xTech competition will not be evaluated. How to Apply: Visit the G-TEAD USAREUR-AF ACE 27-02: Spectrum Enabled Warfare Powered by xTech competition page to read the full Competition Announcement, topic details, and apply by submitting a white paper here: https://www.xtech.army.mil/competitions October 7, 2026: G-TEAD USAREUR-AF ACE 27-02: Spectrum Enabled Warfare Powered by xTech Application submission window opens via link above October 23, 2026, at 5pm ET: G-TEAD USAREUR-AF ACE 27-02: Spectrum Enabled Warfare Powered by xTech Application deadline via link above G-TEAD USAREUR-AF ACE 27-02: Spectrum Enabled Warfare Powered by xTech applications are NOT submitted to DSIP. Small business concerns that do not submit an application to the G-TEAD USAREUR-AF ACE 27-02: Spectrum Enabled Warfare Powered by xTech competition through the https://xtech.army.mil/competitions website before the October 23, 2026, deadline will be ineligible to compete or submit a full SBIR proposal to DSIP. The DSIP proposal submission window tied to this topic is for the finalists and final winners of the competition only. Please make sure to visit the G-TEAD USAREUR-AF ACE 27-02: Spectrum Enabled Warfare Powered by xTech competition site and submit your white paper prior to the October 23, 2026 deadline to be considered for award under this topic.

The operational challenge on the Eastern Flank is the enablement of U.S. Army forces, operating within a North Atlantic Treaty Organization (NATO) and joint coalition framework, to sense, understand, exploit, attack, and protect across a contested electromagnetic environment and connected cyberspace. To deter peer aggression and preserve freedom of maneuver, V Corps must protect tactical command and control networks while delivering synchronized, non-lethal and lethal effects at depth against adversary command, control, communications, and targeting architectures. Gaining and maintaining spectrum superiority against dense anti-access / area denial systems requires a modular, coalition-interoperable architecture that operates in congested radio frequency (RF) environments, executes multi-echelon precision effects, and hardens friendly formations against persistent electromagnetic and cyber disruption during competition, crisis, and conflict. The Army requires capabilities that are scalable, upgradeable, intuitive for Soldiers across military occupational specialties, and maintainable at the tactical edge without routine reliance on field service representatives for minor repairs or adjustments. The Army is seeking to evaluate capabilities to participate in one of three demonstration tracks (eligible for SBIR follow-on contacts) as part of this Spectrum Enabled Warfare ACE: Capability 1: Electromagnetic Support / Tactical Surveillance Capability 2: Autonomous Network Management Capability 3: Electromagnetic Environment Visualization and Battle Damage Assessment Tools Full competition details including details on the topic areas of interest can be found in Appendix A section of the G-TEAD USAREUR-AF ACE 27-02: Spectrum Enabled Warfare Powered by xTech RFI here: https://www.xtech.army.mil/competitions/.

This topic is accepting Direct-to-Phase II submissions with a cost limit of $2,000,000 and a period of performance of 12-18 months. Only finalists and final winners of G-TEAD USAREUR-AF ACE 27-02: Spectrum Enabled Warfare Powered by xTech competition are permitted to submit a proposal for this topic. In order for proposers to submit a DP2 proposal, they must provide the justification documentation to substantiate that the scientific and technical merit and feasibility described above has been met and describes the potential military and/or commercial applications. Documentation should include all relevant information including, but not limited to: technical reports, test data, prototype designs/models, and performance goals/results. 

Produce prototype solutions that will be easy to operate by a Soldier. These products will be provided to select Army units for testing and experimentation with end Users in a realistic field environment. Feedback from testing and experimentation will be provided directly to Small Businesses to iterate rapidly on recommended modifications or improvements for Army operational use. In addition, companies will work with Army partners to develop a draft technology transition and commercialization plan for DoW and commercial markets.

Complete the maturation of the company’s technology developed in Phase II to TRL 8/9 and produce prototypes to support scaling and fielding of the technology with the Army and pursue commercialization pathways.

Innovations in Counter-UAS sensor technologies, data processing, and networking to solve the "sneaky drone" problem by improving the detection, tracking, and identification of small, low-altitude, terrain-masked, and RF-silent Group 1-3 UAS. The system must detect targets from 1 meter up to 300 meters (threshold), 500 meters (objective) off the ground, with individual sensor nodes detecting targets at a horizontal range of at least 100 meters. The nodes must integrate to create at least 10km of combined linear boundary coverage. The final system must cost less than $100k at full-rate production.

This DAF focused open topic seeks C-sUAS detect options for transition into the USAF and USSF, specifically supporting AFLCMC/ES and the JIATF 401 marketplace. This effort seeks low-cost detection and recognition sensors to be configured as a perimeter network for early warning of low-flying drones. The sensors must be able to operate in cluttered environments and recognize non-RF emitting "dark" drones (distinguishing drone vs. not a drone). It must integrate data from all sensors at a node into a single track, providing at least the target's heading along with the absolute location of the detecting node. The system must feature remote node control and be fully controllable via external API commands. The system must be able to integrate into the Medusa C2 or other AF directed C2. Solutions are strictly for permanent base defense applications; therefore, strict SWaP (size and weight) limitations do not apply, and systems can rely on direct or off-grid permanent power.

This is a Direct to Phase 2 (D2P2) topic. Phase I proposals will be rejected. For this D2P2 topic, the Government requires that the applicant will have accomplished the following in a “Phase I-type” effort accomplished outside of the SBIR program through other means. In order to demonstrate this feasibility, the applicant must have developed and validated a working prototype that has been tested in a simulated or non-operational relevant environment. Specifically, the applicant must demonstrate that their system is capable of detecting and tracking non-RF emitting Group 1-3 UAS at low altitudes while outputting basic track and sensor node location data.

Transition to AFLCMC/ES and the JIATF-401 C-UAS marketplace for Base Defense. Commercial dual-use applications include airport security, critical infrastructure protection, and border patrol.

Transition to AFLCMC/ES and the JIATF-401 C-UAS marketplace for Base Defense. Commercial dual-use applications include airport security, critical infrastructure protection, and border patrol

The Phase II description states that the performer will 'Deliver a field-ready, production-representative, low-cost, scalable network of sensors prototype.' Does this require physical delivery of the prototype hardware to the Government at the end of the effort, or does demonstration of the prototype to the Government, with the prototype retained by the performer and available for Government inspection and evaluation, meet the Phase II requirement?

The quoted language does not appear in the published topic document. The published Phase II description identifies the intended transition path but does not specify physical delivery of prototype hardware, prototype retention by the performer, or demonstration-only acceptance. Specific prototype-delivery, inspection, acceptance, Government-access, and disposition requirements, if applicable, will be established in the resulting award instrument.

Does this topic require a proposer to obtain a signed customer memo from AF or SF?

No. The published topic does not require a signed customer memorandum from the Air Force or Space Force. Letters of support may be included, if applicable, but are not required.

The topic describes a perimeter network of detection, tracking and identification nodes feeding Medusa C2 or another Air Force-directed C2. Is a proposal responsive if the proposed sensor node is also designed to cue or host a defeat capability, with the proposed Phase II effort and cost limited to the detection, tracking, identification and C2 integration requirements as published? Or does the Government intend this topic to be strictly limited to detect-only sensor nodes?

The topic seeks detection, tracking, recognition/identification, networking, and C2 integration capabilities for C-sUAS base defense. Defeat capability is not a published topic objective or requirement. The topic does not prescribe a specific sensor-node architecture. Proposals will be evaluated for responsiveness to the published topic requirements. Offerors should clearly distinguish the proposed effort and associated costs that address the published requirements. The Government does not evaluate or endorse additional capabilities outside the scope of the topic during the proposal evaluation process.

the answer to a question below says the $100K covers "every fielded component (software and hardware)," but doesn't mention installation labor, network backbone, or one-time software licenses. I am asking whether those are included, and what production quantity "full-rate production" assumes, which could make a big difference to what's achievable.  Please clarify what the $100K system allows for in terms of those other components. 

The $100k requirement applies to the final system at full-rate production. Offerors may identify the production-volume and cost assumptions supporting their ability to meet the under-$100k requirement. The Government does not commit to procure any specific quantity. The topic does not identify or commit to Government-furnished hardware, software, network, or other site infrastructure; offerors should account for the components and assumptions necessary for their proposed system to meet the published requirements. Installation labor is not included in the final-system cost.

Is the intent to have uniform sensor node configuration across the network, or may the network consist of nodes with varying sensor payloads, provided the network as a whole meets the stated coverage and detection requirements?

Uniform sensor-node configurations are not required, and no specific sensor payload is required for each node. The network may include nodes with varying sensor payloads, provided the final system meets all stated topic requirements.

For purposes of demonstrating Direct-to-Phase-II eligibility under this topic, what technical evidence is expected to establish Phase-I-equivalent feasibility? Specifically, for an optical C-sUAS sensing approach, would documented field detection and tracking of representative small UAS targets using prototype hardware constitute relevant feasibility evidence, or is prior demonstration of the complete 10-km perimeter architecture and/or C2 integration required?

The Government does not evaluate or endorse specific technical approaches, including optical or other sensing modalities, during the Topic Q&A process.  To demonstrate Direct-to-Phase II (D2P2) feasibility, applicants must have developed and validated a working prototype in a simulated or non-operationally relevant environment that detects and tracks non-RF-emitting Group 1–3 UAS at low altitudes while outputting basic track and sensor-node location data. The topic does not require this prior feasibility demonstration to include the complete 10-km perimeter architecture or C2 integration - these are separate published requirements that the proposal itself must address.

Could you please clarify the treatment of pre-existing technology transferred or licensed to the proposing small business?Specifically, if the SBC applicant has entered into a binding technology-transfer/license and teaming arrangement with a technology developer that has already developed and validated a working prototype meeting the Phase I-type feasibility criteria described in the topic, and the SBC:has sufficient rights to the prototype, technical data, test results and know-how needed to perform the proposed effort;incorporates that technology into its own proposed technical baseline;demonstrates access to and technical control of the existing prototype and supporting validation data;performs the required majority of the Phase II R&D, integration, networking, C2/API integration and further development; andprovides complete documentation of the prior prototype testing and validation,may the existing prototype and validation work be used as part of the SBC applicant’s Phase I-equivalent feasibility documentation for D2P2 eligibility?If so, is there any particular evidence of technology rights, technical control, prior testing, or applicant-led validation that the Government would expect to see in the proposal?Thank you for the clarification.

Q: May the existing prototype and validation work be used as part of the SBC applicant’s Phase I-equivalent feasibility documentation for D2P2 eligibility?  A: Yes, this is acceptable.Documented evidence of technological rights, control and prior testing is required.

For DAF26BX06-DP027, may a U.S. small business satisfy the Direct-to-Phase-II feasibility requirement where the proposed Principal Investigator personally performed a substantial portion of the prior prototype development and validation while employed by the original technology developer, and the U.S. small business obtains the necessary license/IP rights to that technology before proposal submission? Assume that the PI will be primarily employed by the proposing U.S. small business at the time of award and throughout Phase II, and that the Phase II R&D, integration, testing, and commercialization activities will be performed in the United States. Would the prior work performed by that individual before joining the proposing small business qualify as Phase-I-equivalent feasibility work for purposes of D2P2 eligibility? Would the answer differ if the original technology developer is a non-U.S. company, assuming all applicable foreign disclosure, export-control, and security requirements are met?

 The proposing company must own rights to the prototype. 

The topic projects CMMC Level 2 (Self). Our development uses large language model (LLM) coding assistants, which must run in a government-authorized cloud environment. Will DAF provide a government-furnished environment (GFE) cloud slot to run permitted LLMs at no cost to the contractor, or should offerors budget for this in the Phase II cost proposal?

The topic identifies a projected CMMC Level 2 (Self) requirement. It does not identify a Government-furnished cloud environment, permitted LLM tools, or related cost treatment.

1. Cost ceiling. Does the $100,000 full-rate production ceiling apply per sensor node or to the complete system that provides 10 kilometers of boundary coverage? Does the ceiling include installation, power infrastructure, and software licensing, or hardware only?2. Target signatures. What radar cross section (RCS) should proposers assume for the smallest Group 1 unmanned aircraft system (UAS) target, and at what frequency band? Is a government-furnished target set or RCS model available?3. Performance metrics. Are there threshold values for probability of detection, false-alarm rate, track accuracy, and track latency?4. Identification scope. Does "identify" mean drone versus not-a-drone only, or classification by type (multi-rotor, fixed-wing, helicopter), or recognition of specific models?5. Spectrum constraints. Are there frequency-allocation or spectrum-authorization constraints for active radio-frequency (RF) sensors permanently installed on an Air Force base?

The final system must cost less than $100k at full-rate production. This includes every fielded component (software and hardware) the solution needs to operate and meet the other requirements. If applicable, shore power consumption costs do not need to be included in the total cost. GRP 1 target sizes / frequencies are not specified at this time. There are not specified performance metrics at this time. The sensors must be able to operate in cluttered environments and recognize non-RF emitting "dark" drones (distinguishing drone vs. not a drone) Proposals are not required to have approved frequency-allocations or spectrum-authorizations at the time of proposal. 

1. Feasibility evidence. Does a validated simulation-only prototype satisfy the Phase I-type feasibility requirement, or must the applicant have physical sensor hardware that has detected a live or surrogate small UAS?2. Medusa interface. What interface documentation or software development kit exists for Medusa command-and-control (C2) integration? Can offerors access it before award? 

1. Whether a particular prototype meets the D2P2 feasibility requirement cannot be determined through Topic Q&A. For feasibility, applicants must show that they have a developed and validated working prototype that has been tested in a simulated or non-operational relevant environment and can detect and track non-RF-emitting Group 1–3 UAS at low altitudes. The published requirements do not state that a simulation-only prototype is sufficient or require physical sensor hardware.2.  The published requirements state that the system must be fully controllable through external API commands and be capable of integrating into Medusa C2 or another Air Force-directed C2. There are no pre-award access arrangements. 

1) Regarding the requirement: "The nodes must integrate to create at least 10km of combined linear boundary coverage": is this requirement for a straight line, or can it be met with a curve or perimeter?2) The system must detect/track Group 1 through 3 UAS.  Group 1 UAS span a large range of size/weight/signatures.  Is there a lower limit to the size of Group 1 of interest (e.g. >250g)?3) For demonstration of the equivalent of Phase I: arranging demonstrations against actual "RF-Dark" UAS is challenging.  Is it acceptable to demonstrate against non-RF-dark UAS and show that no UAS emissions were exploited?4) What technical environmental specifications are required to be met?  These requirements will drive final production cost estimates.5) Are any cyber-security requirements beyond CMMC level 2 envisioned? 

The requirement is not restricted to a straight line. The requirement applies to a undefined polygon that has a perimeter of at least 10km.  A lower limit to the size of Group 1 of interest is not specified at this time. As stated, the applicant must demonstrate that their system is capable of detecting and tracking non-RF emitting Group 1-3 UAS at low altitudes while outputting basic track and sensor node location data. To be operable in permanent base defense applications, the system must be operable in all weather conditions drones can fly in. To be operable in permanent base defense applications, the system must be cyber secured. 

Could you comment on:Besides stational installation, could the sensors be installed on Unmanned ground or aerial vehicles?Does the sUAS detection cover all environmental conditions: fog, rain, day and night?

1. The published requirements do not prescribe a specific sensor mounting configuration or provide additional guidance on the use of unmanned ground or aerial vehicles. However, solutions are strictly for permanent base defense applications. 2. Requirements state that sensors must operate in cluttered environments. They do not establish separate performance requirements for fog, rain, daylight, or nighttime conditions.

For DAF26BX06-DP027:1. Is the D2P2 feasibility requirement satisfied by an existing prototype demonstrating detection and tracking of a non-RF-emitting Group 1–3 UAS at low altitude, with basic track and sensor-node-location output in a non-operational relevant environment, while the 100 m/node range, altitude coverage, 10 km boundary, heading, remote control, API and C2 requirements are Phase II objectives?2. For the feasibility requirement, what constitutes a “basic track”? Is single-node range and radial-velocity history sufficient, or must the existing prototype also provide bearing?3. Does the requirement that the “final system” cost less than $100,000 at full-rate production apply to the complete multi-node system providing the required boundary coverage, or to each sensing node?

1 - The Government cannot determine through Topic Q&A whether a particular applicant’s existing prototype satisfies the D2P2 feasibility requirement. For D2P2 feasibility, applicants need to show that they already have a developed and validated working prototype that has been tested in a simulated or non-operational relevant environment. The prototype must be able to detect and track non-RF-emitting Group 1–3 UAS at low altitudes and provide basic track and sensor-node-location data. The proposed solution must still address the full set of published topic requirements; those requirements are not waived.2 - The published feasibility requirement is to output basic track and sensor-node-location data as part of the required detection and tracking demonstration. The topic does not prescribe specific track fields or separately require bearing.3 - The less-than-$100K full-rate-production cost threshold applies to the final system, not to each individual sensing node. 

The overall goal of this Direct to Phase II research and development effort is to adapt and validate mature, readily available autonomous unmanned aerial swarm technologies to provide enhanced situational awareness and force-multiplying capabilities for high-value Mobility Air Forces assets and forward ground installations. To ensure continued overmatch in contested environments, mobility aircraft operations can be significantly augmented through the integration of dedicated, attritable platforms capable of providing persistent intelligence, surveillance, and reconnaissance, while ground forces can leverage rapidly deployable autonomous networks to bolster perimeter defense. The immediate objective of this Phase II effort is to propose methods for and demonstrate the deployment and autonomous operation of a multi-agent swarm from high-altitude mobility launch platforms, while simultaneously demonstrating the swarm's dual-use capability to establish an autonomous monitoring and defense perimeter. A critical research and development component of this phase focuses on proposing and developing secure, encrypted military communication architectures to meet Department of the Air Force operational standards. By focusing this phase strictly on proving the foundational capabilities of high-altitude deployment, secure networking, and autonomous baseline behavior, the project establishes a robust architecture. This approach deliberately avoids prescribing specific end-state payloads, thereby allowing for the flexible, innovative integration of various electronic or advanced sensing effects in subsequent operational phases based on evolving warfighter requirements.

Mobility Air Forces aircraft serve as the logistical backbone of the Department of War and operate as high-value assets in modern contested environments that can be significantly augmented with enhanced organic self-protection and intelligence, surveillance, and reconnaissance capabilities to maintain operational overmatch. Similarly, forward operating bases can bolster their security posture by leveraging rapidly deployable, autonomous perimeter defense networks. The objective of this project is to adapt mature, readily available autonomous drone swarm technology to enhance capabilities across these dual domains. By integrating hardware-agnostic, artificial intelligence-driven swarm control software, this innovative concept aims to drastically augment the operational capabilities of the DoW by transforming mobility airframes into adaptive, force-multiplying launch platforms and providing defenders with a rapidly deployable swarm for base security. At project start, the core readily available technology sits at a Technology Readiness Level of 5 or more. The target at the end of this Direct to Phase II research and development effort is Technology Readiness Level 7, representing a military-adapted system prototype demonstrated under operational conditions. To achieve this R&D objective, proposed methods include upgrading readily available communication links to integrate secure military protocols and developing the autonomous behaviors necessary to seamlessly transition from aerial deployment to ground-based perimeter defense. Vendors should propose methods for initial capability demonstrations of a fully integrated swarm capable of secure military communications, showcasing high-altitude deployment and autonomous perimeter establishment, alongside the comprehensive technical reporting required to transition the capability to subsequent defense acquisition phases or operational fielding.

As this is a Direct-to-Phase-II (D2P2) topic, no Phase I awards are anticipated for this topic. To qualify for this D2P2 topic, the Department of the Air Force expects applicants(s) to demonstrate feasibility by means of a prior "Phase I-type" effort that does not constitute work undertaken as part of a prior or ongoing SBIR/STTR funding agreement.For this specific effort, the feasibility documentation should substantiate that the core autonomous swarm technology is mature, reliable, and operating in relevant environments. The fundamental scientific and technical merit of coordinating multiple uncrewed aerial systems via artificial intelligence has already been established by the private sector. Therefore, traditional Phase I feasibility studies investigating the basic principles of swarm networking or autonomous flight are considered redundant.Applicants(s) should provide documentation demonstrating a clear understanding and proven capability of the underlying technology through deployments in analogous, high-stress relevant environments, such as wildland firefighting or law enforcement operations.Sufficient Feasibility Documentation should include, but is not limited to:Readily Available Deployment Records: Verifiable data or reports detailing the active use of the proposed swarm software and hardware in relevant environments (e.g., testing or use alongside state or federal fire agencies, municipal police departments). This documentation should indicate the system has progressed from controlled laboratory testing to validation in relevant environments.Autonomous Coordination Metrics: Technical reports or system logs demonstrating the software’s capability to autonomously control a multi-agent swarm without continuous, manual piloting of individual nodes. This can include data on mesh network stability, dynamic task allocation among drones, and collision avoidance algorithms operating in chaotic environments (such as airspace obscured by smoke or complex urban terrain).Sensor Integration and Tracking Data: Documentation demonstrating the integration of visual and thermal (EO/IR) payloads, and the software’s ability to autonomously utilize these sensors to detect, track, and relay data on designated targets or points of interest.By providing this documentation, the applicant demonstrates that the baseline readily available technology sits at a minimum Technology Readiness Level of 5 or 6. This establishes that the foundational scientific and technical feasibility traditionally explored in Phase I has already been achieved through iterative development, validating that the technology is prepared to transition to Phase II research and development efforts focused on military adaptation, secure communications integration, and platform integration to achieve TRL 7.

To establish feasibility, measure effectiveness, and execute the required research and development, the Phase II effort should propose methods for initial capability demonstrations that advance the technology to operational viability (TRL 7). These can include the integration of encrypted military radios, demonstrating secure, uninterrupted data exchange between the multi-agent swarm and the human operator interface. Vendors should propose methods to demonstrate drone swarms under operational conditions, where the swarm is deployed at operational altitudes, survives the launch environment, and establishes controlled, autonomous flight. Furthermore, the effort seeks capability demonstrations proving the swarm can be rapidly deployed to autonomously establish a monitoring perimeter, utilizing its integrated visual and thermal sensors to detect, track, and relay data on simulated targets. Finally, the effort should produce comprehensive technical data packages, reports, and operational concepts to support the transition of this technology into subsequent defense acquisition phases or operational fielding.To achieve these R&D goals, proposed operating parameters should include demonstrating secure communication integration and deployment capabilities under operational conditions. Deployments should be demonstrated at operational altitudes to simulate operational Mobility Air Forces scenarios. Operational capabilities should also be validated regarding the swarm's ability to autonomously monitor and defend a designated perimeter using onboard visual and thermal sensors.These capability demonstrations are designed to validate several specified technical goals and functional requirements. First, the system should integrate secure, encrypted military communications, replacing readily available data links to ensure secure command and control that aligns with Department of the Air Force standards. Second, the swarm should demonstrate the capability to safely deploy from mobility platforms at operational altitudes. Finally, the artificial intelligence software should be adapted to seamlessly transition from aerial deployment into a coordinated flight pattern and autonomously execute a perimeter defense monitoring route.Ultimately, this Phase II Period of Performance centers on the research and development necessary to adapt and validate a readily available autonomous drone swarm system for military operations to meet critical capability gaps. The desired R&D outcome is a military-adapted prototype capable of demonstrating these dual-use capabilities in an operational environment (TRL 7). Use cases for this technology include providing organic intelligence, surveillance, and reconnaissance, as well as self-protection for Mobility Air Forces operating in contested airspace, alongside providing forward operating locations with an instantly deployable, autonomous perimeter monitoring system.

Following Phase II, the technology will enter Phase III after successfully accomplishing Phase II objectives, having completed demonstrations under operational conditions. The primary military application is transitioning the capability into a formal Program of Record to equip mobility aircraft fleets with air-launched swarms, providing organic, multi-mission self-protection and intelligence, surveillance, and reconnaissance in contested airspace. A critical domestic military application involves the Air National Guard utilizing this swarm technology to enhance Domestic Operations (DOMOPS). By rapidly deploying a high-altitude drone swarm from mobility launch platforms, rescue units gain an instant, wide-area sensor net to expedite the location of survivors during natural disasters, while ground units can deploy the swarm for persistent, autonomous border surveillance.Additionally, significant dual-use and commercial applications are intended to be pursued. Interagency partners like the National Oceanic and Atmospheric Administration (NOAA) seek this high-altitude deployment capability to safely launch swarms into hurricanes and atmospheric rivers for real-time weather data collection. Commercially, the ruggedized, secure swarm capability can be expanded for advanced disaster response, large-scale search and rescue, and commercial aviation monitoring.The expected Phase III effort involves finalizing airworthiness certifications with the Air Force Life Cycle Management Center (specifically the Mobility Directorate), establishing mass production and sustainment pipelines, and formally integrating the swarm capabilities into operational Tactics, Techniques, and Procedures. Transition planning is actively underway; the project team is engaging AMC Futures and the Chief Scientist to champion an Initial Capabilities Document based on Phase II capability demonstration data, while ARCWERX is assisting in identifying follow-on acquisition vehicles to enable seamless scaling and deployment across both combat and domestic operations.

Post-release relationship to the host aircraft. After release from the C-130J, are the drones expected to keep pace with, fly in formation with, or otherwise maintain position relative to the host aircraft for any period? Or does the host aircraft depart the release point while the drones independently transition to controlled flight and proceed to establish the perimeter? If any period of co-flight with the host aircraft is expected, please specify its duration and the required airspeed.

The drones are not expected to keep pace with, fly in formation with, or maintain position relative to the host aircraft after release. Given the aerodynamic and speed differences, the host aircraft will depart the drop zone immediately following deployment. The drones are expected to independently arrest their deployment trajectory, transition to controlled flight, establish their autonomous swarm network, and proceed to the designated operational area to establish the required perimeter defense and deliver ISR/mesh capabilities.

To select an appropriate drone platform and develop a credible scope, budget, and test plan, could you please clarify the following remaining requirements?Drone type, size, and weight. Is there a required or preferred unmanned aircraft system group or aircraft configuration? Are there limits on individual vehicle weight, deployed dimensions, or stowed dimensions, including its sensors, communications equipment, and deployment packaging?Required release conditions. Must the demonstration cover the full published altitude and airspeed ranges, including their endpoints, or may offerors propose specific test conditions within those ranges for government approval? Please confirm that the airspeed refers to the host aircraft at release and identify any separate minimum release height above ground level.Host-aircraft interface and deployment constraints. What government-approved interface documentation and constraints will be available for the C-130J? Is a particular deployment location or method required, and what restrictions on aircraft modifications, onboard equipment, and deployment hardware should guide platform selection? When can prospective offerors obtain this information?Required flight performance after release. Are there minimum requirements for drone operating speed, altitude, airborne duration, or operating distance following deployment? If these values are not prescribed, may offerors propose and justify them for government approval?Interpretation of the ten-drone minimum. Must at least ten drones be air-launched and operating together during the same demonstration, or may the ten-drone swarm be established through multiple deployment events? Must all ten vehicles use the same configuration, and must each carry both visual and thermal sensors?Recovery and acceptable losses. Must the demonstration vehicles be recoverable and reusable, or are expendable vehicles acceptable? What recovery, flight-safety, and environmental requirements should offerors account for when selecting the aircraft and estimating test quantities?Test access, costs, and alternative platforms. Beyond the stated coordination assistance, which aircraft, range, crew, integration, and approval costs should the contractor include? If a C-130J is unavailable, what criteria and approval process will determine whether an alternative airborne platform satisfies the demonstration requirement?

1) We are agnostic to the hardware, as long as it can withstand being deployed at altitude and airspeed. The main limitation is that the drone and any non-fixed hardware for its deployment must be able to be carried by the average adult (approx. <50#). Another consideration is that certain aircraft may require specific weights if deployed while in specific aircraft configurations.2) Offerors are not strictly required to test at the extreme endpoints of the 3,000' to 10,000' MSL and 130KIAS to 200KIAS ranges in a single demonstration. You may propose specific test conditions within these envelopes for Government approval. The airspeed refers to the host aircraft's indicated airspeed at the time of release. Any separate minimum release height above ground level (AGL) will be dictated by the specific military range safety requirements and drop zone characteristics, which will be coordinated with the TPOCs.3) The Government will provide applicable C-130J interface documentation and cargo-handling constraints upon contract award. We strongly prefer deployment methods that require zero modifications to the host aircraft (e.g., utilizing existing paratroop doors, gravity drops from the ramp, or standard roll-on/roll-off procedures). The performer is responsible for providing all deployment hardware and integration engineering.  We will not be performing minor or major modifications to air force aircraft during this topic release.4) We have not prescribed exact minimum thresholds for drone operating speed, altitude post-release, airborne duration, or operating distance. Offerors may propose and justify these values based on their system's design and its ability to successfully fulfill the objective of establishing a perimeter and delivering ISR/mesh effects. These proposed metrics will be reviewed and finalized with the TPOCs/Government upon awarding funds.5) The requirement is for a minimum of ten drones to be operating together simultaneously to demonstrate swarm effects. While it is preferred that all ten are air-launched in the same event, the swarm may be established through multiple, rapid deployment passes if dictated by hardware or host-aircraft constraints, or ground-launched in conjunction with an airdrop. All ten vehicles do not need to share the exact same configuration; as previously answered, visual and thermal sensor capabilities may be distributed across the swarm, provided the integrated system achieves the required detect, track, and relay objectives.6) While recoverable and reusable vehicles are preferred to allow for iterative testing and cost efficiency, expendable vehicles are acceptable depending on your proposed concept of operations. If proposing expendable or attrition-tolerant vehicles, offerors must account for range safety, debris cleanup/recovery requirements dictated by the test range, and standard environmental compliance. Test vehicle quantities and budgets should be estimated to account for potential attrition during early high-altitude/airspeed deployment testing.7) The Government will facilitate the host aircraft, military range access, and basic military flight crew at no direct cost to the contract, pending asset availability. The contractor must include all costs associated with their own personnel (travel, test-support labor), hardware development, platform integration, and safety approval documentation. If a C-130J or similar MAF aircraft is unavailable within the period of performance, the TPOCs will evaluate and approve alternative platforms (such as surrogate aircraft or captive-carry testbeds) based on their ability to sufficiently simulate the required altitude, airspeed, and aerodynamic conditions necessary to validate hardware survivability and swarm autonomy.

 Clarification of Direct-to-Phase-II feasibility eligibilityThe published topic answer permits deployment records, metrics, and other feasibility evidence from a formally attached teaming partner. The component instructions also require the feasibility effort to have been substantially performed by the applicant and/or principal investigator and exclude feasibility documentation based upon, or logically extending from, prior or ongoing federally funded Small Business Innovation Research or Small Business Technology Transfer work.Please clarify how these provisions apply when a teaming partner provides part of the mature baseline. Specifically, what documentation is required to establish applicant or principal-investigator participation, qualifying funding provenance, and sufficient rights to use the partner’s technology and supporting evidence? How should offerors address historical research supported by multiple funding sources, including both excluded and potentially qualifying funding?

While we allow teaming partners to provide baseline flight data and metrics to satisfy the TRL 5-6 feasibility requirement, the prime applicant must still adhere to standard SBIR instructions regarding principal investigator (PI) primary employment and minimum required work-share. To establish sufficient rights and participation, the proposal must include a formal Teaming Agreement, Memorandum of Understanding (MOU), or licensing agreement. This documentation must explicitly detail the partnership, rights to use the partner’s technology and supporting evidence, and the specific roles and work-share split between the applicant and the teaming partner. The applicant must clearly demonstrate their substantial contribution (e.g., software integration, governance, or detection capabilities) to the overall system. Regarding funding provenance and the exclusion of prior SBIR/STTR work: the feasibility justification for a Direct-to-Phase-II cannot be solely based on, or be a logical extension of, prior federally funded SBIR/STTR efforts. If the historical research and baseline system rely on mixed funding sources, the offeror must clearly delineate these funding streams in the proposal. You must demonstrate that the specific feasibility evidence (e.g., the deployment records, coordination metrics, and datasets) used to justify entry into this Phase II was developed through internal R&D, commercial funding, or non-SBIR/STTR federal funding. Prior SBIR/STTR-funded technology may serve as a baseline component of the integrated solution, but the distinct feasibility evidence provided to satisfy the requirements for this topic must trace back to qualifying, non-SBIR/STTR efforts.

Operator authority and safety approval. What requirements apply to operator supervision and intervention, communications-loss behavior, flight termination, and vehicle recovery? Which organizations will establish the applicable safety criteria and approve the demonstration procedures, and what evidence must the performer provide to obtain those approvals?Required sensors and payload boundaries. Must every participating vehicle carry both visual and thermal sensors, or may those capabilities be distributed across the system? What sensing functions and reported data products are required during Phase II? Please confirm whether “defense” is limited to sensing, monitoring, and reporting to a human operator, or whether any additional payload functions are required rather than deferred to later phases.Demonstration acceptance and final readiness. What objective measures and acceptance criteria will be used to evaluate autonomous coordination, communications continuity, sensing performance, and safe operation? Which organization will approve those criteria and determine whether the final prototype has achieved Technology Readiness Level 7, and what government witnessing or independent verification will be required?Test responsibilities and schedule dependencies. Beyond the coordination assistance described in the published answer, which party is responsible for securing and funding aircraft access, airworthiness or flight-release approvals, range access, spectrum authorization, and flight-test support? Which government resources are committed and which remain contingent, and are there required milestones or access and approval lead times that should govern the proposed 24-month schedule?Required evidence and deliverables. What technical reports, configuration records, test logs, sensor datasets, software documentation, and other evidence must be delivered? Are there prescribed formats, reporting intervals, retention requirements, or government-access expectations, including access to underlying data needed to independently verify the reported results?

1. While we expect minimal tasking for the operator during nominal operations, offerors must incorporate standard safety behaviors, including communications-loss protocols, flight termination capabilities, and vehicle recovery plans. Safety criteria and demonstration procedures will be governed by the host military range and the host aircraft's airworthiness authority. The performer will be required to provide standard system safety, flight hazard, and structural documentation to support the TPOCs in securing these flight releases and range approvals.2. Capabilities such as visual (EO) and thermal (IR) sensors do not necessarily need to be on every single vehicle; they may be distributed across the swarm, provided the system as a whole can successfully establish the perimeter and deliver the required ISR/mesh effects. As previously established, "defend" during this Phase II effort is strictly limited to detect, track, and relay capabilities to a human operator. No kinetic or non-kinetic effectors are required, nor should they be integrated during this phase.3. Final acceptance criteria and objective measures will be collaboratively defined by the performer and the TPOCs early in the Phase II period of performance. These metrics will focus on autonomous coordination, communications continuity (mesh networking), sensing performance, and hardware survivability post-deployment. The TPOCs and associated Government stakeholders will approve these criteria and serve as the verifying authority. Government witnessing of the final demonstration at a military range will be required to independently verify that the system has successfully achieved TRL 7.4. As noted, TPOCs will assist in coordinating test support, including range scheduling, spectrum authorization, and access to mobility aircraft (e.g., C-130J). However, access to MAF aircraft and specific ranges remains contingent on military availability. Offerors are responsible for funding their own test-support labor, hardware development, and travel. Given standard DoD airworthiness and spectrum approval timelines.5. Standard SBIR Phase II reporting requirements apply. We expect regular status reports, a comprehensive final technical report, and the delivery of relevant test logs, sensor datasets, and autonomous coordination metrics. Specific formats, reporting intervals, and retention requirements will be finalized during the contracting and kickoff process. The Government expects access to the underlying flight data, autonomy logs, and sensor outputs required to independently verify the real-world metrics and real-time autonomy demonstrated during the project.

 Required demonstration scope. Must the Phase II effort demonstrate both ground deployment and deployment from an aircraft using the same system configuration, or is either deployment mode independently acceptable? For perimeter monitoring following aerial deployment, must the vehicles remain airborne, or may they land and operate as stationary sensor nodes?Starting readiness and supporting evidence. What minimum evidence is required to establish the starting Technology Readiness Level of 5 or 6, including deployment records, autonomous coordination logs, sensor-integration results, and characteristics of the relevant environment? Must these records demonstrate the proposed hardware and software operating together as a multi-vehicle system? Where a formally attached partner supplies the baseline, how should configuration differences and each team member’s completed contribution be documented?Demonstration scale and operating conditions. Are there minimum requirements for the number of cooperating vehicles, demonstration duration, and degree of operator intervention? If numerical thresholds are not prescribed, may offerors propose and justify these values, and what operational conditions should that justification address?Host aircraft and integration interfaces. Building on the published answer concerning mobility-aircraft availability and possible alternative platforms, will the government identify the intended host aircraft and provide the applicable deployment-interface, environmental, and integration requirements? Which aircraft modifications, deployment hardware, interface documentation, and integration services must the performer provide, and when will government-controlled interface information become available?Communications and interoperability. What communications interfaces, interoperability requirements, encryption or certification standards, and operator-system interfaces must the Phase II demonstration satisfy? Please distinguish requirements for commercial encryption, operation in military frequency bands, and government-certified equipment. Will relevant radios, specifications, integration support, or test resources be government-furnished, and when would they become available? 

1. The overall objective of this topic is for the technological solution to offer a dual-purpose capability. The Government expects the proposed drone swarm system to be capable of performing both high-altitude aerial launch and rapid ground-based deployment to establish an autonomous defense perimeter. However, please note that these are two distinct operational objectives. The Government does not expect a swarm deployed via air launch to subsequently morph into a ground defense perimeter for that same aircraft during a single mission. Regarding perimeter monitoring, the Government is not prescribing a specific operational mode; vehicles may remain airborne or land to act as stationary/hybrid sensor nodes, provided the proposed method effectively accomplishes the perimeter defense objectives.2. To establish feasibility for TRL 5-6, we require real-world metrics and deployment records from relevant environments (e.g., wildland firefighting, law enforcement, search and rescue, or DoD flight tests). While simulation data can be referenced in the proposal, the objective is to demonstrate real-time autonomy and integration amongst multiple drones. If a teaming partner supplies the baseline, their deployment records and data may be used to satisfy the requirement, provided they are formally attached to the package. Our TPOCs have not established specific restrictions or documentation requirements for determining the work-share split or configuration differences.3. A swarm size of 10 is considered the minimum to demonstrate effects. We expect minimal tasking to an operator for the drones to successfully establish positions and deliver effects. Offerors may propose and justify specific demonstration durations and operational parameters, provided they align with these thresholds and the primary goal of demonstrating autonomous swarming and hardware survivability after deployment at altitude and airspeed.4. Our initial expectation is for the deployment to be executed from a C-130J. TPOCs will assist in coordinating test support and securing government airframes for testing purposes, pending the availability of MAF aircraft. The government will not supply the air-launching or dispensing hardware; offerors must develop this hardware over the course of the topic. Importantly, no permanent modifications to the host aircraft will be permitted or executed during Phase II. Any proposed deployment hardware or mechanisms must utilize existing aircraft interfaces (such as standard cargo ramp release or existing tie-down rings) without requiring structural changes or long-lead engineering change proposals (ECPs). Specific deployment-interface and integration requirements will be coordinated with the TPOCs during the execution of the project.5. For the operator-system interface, an NGC2 device (e.g., ATAC or something similar) is preferred. For communications, our initial objective for this phase is to operate in traditional military frequency bands using commercial encryption solutions, with the capability and intent to expand to Government Certified Type-1 devices for classified communications in the future. Government-furnished radios may be provided during this phase, but they are not required to demonstrate the range of capabilities we are seeking in this topic release.

Launch and hardware scope: Does the government expect offerors to supply the airframes and the air-launch/dispensing hardware, or to integrate swarm software onto government-furnished or commercial airframes? Similarly, will we have access to government-furnished encrypted comms radios?"Ground-based perimeter defense": After aerial release, do you envision the swarm remaining airborne, or landing and operating as fixed sensor nodes? Is "defend" in Phase II limited to detect, track, and relay to a human operator (no effectors)? What level of human-on/in-the-loop control do you expect?Secure comms: Is there a target radio, waveform, or crypto standard (e.g., NSA-approved or FIPS-validated) that the "DAF standards" language refers to, and would that equipment be GFE?TRL 7 demonstration: What venue and minimum swarm size do you have in mind? Is there a preferred C2 or base-defense system for the operator interface? Is this to show feasibility of the full capability or the swarming specifically?

    1) TPOCs will coordinate with offerors to secure government airframes for testing purposes (based on availability of MAF aircrafts). Hardware for air-launching will not be supplied and will need to be developed over the course of the topic. Gov't furnished radios may be provided during this phase, but are not required in order to demonstrate the range of capabilities we're seeking to execute during this topic release.    2) The original intent was for the swarm to remain airborne in order to deliver ISR/mesh capabilities, but proposals that seek to solve gaps in capabilities or hardware via landing may be considered. "Defend" will be limited to the drones creating a perimeter and providing detect, track, and relay capabilities during this topic release. We expect minimal tasking to an operator for the drones to successfully establish positions and deliver effects.    3) Commercial encryption solutions will be considered with the intent of using Gov't Certified Type-1 devices in the future.    4) A military range and drop zone will be used for the demonstrations. A swarm size of 10 will be considered the minimum to demonstrate effects. A NGC2 device (e.g. ATAC or something similar) would be preferred for operator interface. This topic release is to demonstrate the autonomous swarming capability of the drones (software) as well as their survivability being deployed at altitude and airspeed (hardware).

For the comms. And the encryption area in the solicitation: Are you expecting a proposal for specific radios and encryption solutions? Since there are no specific/detailed comms./encryption requirements in this phase. Thank you

We are expecting proposals to outline encryption solutions and propose radio options for their drones. Commercial encryption solutions will be considered.

The Phase I section asks for deployment records showing active use of the proposed swarm software and hardware in relevant environments. Where the system pairs a teaming partner's fielded airframes and autonomy stack with our own detection and governance software, may the partner's deployment records form part of the feasibility documentation, with our contribution shown through our own coordination and detection results? (We are a AI/Software company specializing in edge deployments).The topic names wildland firefighting and law enforcement as examples of relevant environments. Would search and rescue work, DoD-funded flight test programs, or fielded military use of the proposed airframes also count?For the autonomous coordination metrics, would flight data from a single airframe running our software, together with multi-agent coordination results from simulation (task allocation, spacing, hand-off when a node drops), satisfy the requirement, with the multi-airframe flight as an early Phase II milestone?The Phase II text refers to integrating encrypted military radios. Do you expect commercial encryption (AES-256 or FIPS 140 validated) operating in military bands, or Government-certified Type 1 devices? This decides the size, weight and power budget of the airframe.When you said high altitude, did you mean the drones are released from a larger aircraft at altitude, or that they operate over high terrain such as a mountain search? The two lead to different test plans.

    1) Yes, as long as the teaming partner is formally attached to the package then their deployment records, metrics, data, etc. can be used to satisfy the feasibility requirement.    2) Yes, those would all work.    3) Our objective is to demonstrate autonomous coordination with a drone swarm. While simulation data can be referenced in the proposal, we will be seeking real-world metrics and real-time autonomy/integration amongst multiple drones during the execution of the project.    4) During our initial execution of the topic, commercial encryption options will be considered.    5) Our intent is to deploy drones at altitude and airspeed. If the drones have the capability to operate over high terrain, that will be a plus.

High altitude deployment: What altitude and host aircraft does the objective expect for the air-drop or captive carry deployment?

Our initial expectations are for the deployment to be executed between 3,000' and 10,000' from a C-130J.

Secure encrypted military comms: What level of security does the objective mean?Commercial best practice, such as AES-256 or FIPS-compliant encryption.Operation in military frequency bands.Certification for classified traffic at Secret or TS level.

Our initial objective is to operate in the traditional military frequency bands, with the capability to expand and secure certification for classified communications.

Will the Government provide test support for the required demonstrations, specifically access to a mobility aircraft or launch interface, range time, flight clearance or military flight release, and spectrum authorization for the encrypted links, or should offerors carry those costs, schedule, and approval timelines in their proposals?

Our TPOCS will assist in coordinating for test support, including access to mobility aircrafts (pending availability) and range scheduling.

For Direct-to-Phase-II feasibility, the topic cites deployment records from relevant environments such as wildland firefighting or law enforcement. If the mature TRL 5–6 swarm baseline is provided by a teaming partner rather than the applicant, will the partner's deployment records, autonomous coordination metrics, and EO/IR tracking data satisfy the feasibility requirement, and is there a required work-share split or page limit for that documentation?

Yes, as long as the teaming partner is formally attached to the package then their deployment records, metrics, data, etc. can be used to satisfy the feasibility requirement. Our TPOCS are not aware of any restrictions or documentation requirements for determining the work-share split.

The topic requires deployment "at operational altitudes" from mobility launch platforms. Can the Government define the intended altitude band and airspeed envelope for the release demonstration, and will a captive-carry test, surrogate aircraft, or ground-based release be accepted toward this requirement if a mobility airframe is not available within the period of performance?

For this phase we are aiming to release the payload between 3,000' and 10,000' MSL, traveling between 130KIAS and 200KIAS. Deployment from a mobility aircraft is the objective, but should one not be available then deployment at altitude and airspeed via alternative platforms may be considered.

The objective of this Direct to Phase II (D2P2) effort is to provide a production representative article of flight qualifiable hardware to be flown in the GEO space environment. The modern space domain requires a layered sensing architecture to ensure resilience. This D2P2 effort is focused on a critical element of that architecture: a compact, efficient payload that provides persistent, 4 pi steradian awareness of the local space environment for its host vehicle. Occlusion zones are probable and should be minimized based on the satellite design and sensor placement. Multiple phenomenologies are of interest, to include but not limited to, electro-optical, infrared, and radio frequency. To be suitable for integration across a wide range of buses, solutions must be aggressively optimized for low Size, Weight, and Power with affordability in mind. While any available tested technology will be considered, the ideal payload would not exceed 50W of power consumption and 15 Kg of mass. These characteristics are critical for enabling integration onto platforms with stringent resource limitations. The desired capability must establish a "self-awareness bubble" with a range of 200 km (threshold) to 500 km (objective) radius, with the ability to detect a 0.5 (threshold) to 0.2 (objective) meter object with a probability of detection of 0.8 and probability of false alarm of 0.01. The sensor data must feed into advanced on-board analytics to autonomously track nearby objects, to support assessment of intent, distinguishing between debris, unanticipated neutral or friendly objects, and potential threats to enable both autonomous tactical response and intuitive operator visualization. The government’s primary focus is on the speed of delivery for proven technology now. Key challenges to be addressed include: - Autonomous Threat Detection in a Low SWaP-C Package: proactively gathering, processing, and analyzing data to characterize threats using a highly efficient, lightweight payload. - Scalable, Mature, and Manufacturable Solutions: solutions must emphasize high Technology Readiness Level (TRL), Manufacturing Readiness Level (MRL), and scalability for hardware and software. - Efficient Hardware Integration: use common interfaces for power, data, and thermal to ease integration onto platforms. Minimize footprint and be flexible with mounting options. - Efficient Data Integration: Optimizing the payload to provide decision-quality information efficiently, with an architecture that allows for integration with enterprise data systems.

This D2P2 effort is to develop low Size, Weight, Power, and Cost (SWaP-C) technology for an on-board sensing payload to provide local situational awareness. This effort specifically looks to target low SWaP-C payload and on-board processing capability to sense and assess objects within the local area. This effort targets the combination of in-space sensing and sense-making with the goal to enable both self-protection through the organic ability to detect, track, and characterize immediate threats to support threat response, but also contributes to shared awareness of the tactical space picture across the domain. Following the traditions of air, maritime, and ground combat architectures, proliferated tactical sensors and their on-board assessment technology must become part of any combat system baseline. As such, this payload capability will become a critical enabler for mission resilience and ultimately, space superiority, through greater autonomy, decision-agility and survivability in contested space warfighting environments.

This topic is intended for technology proven ready to move directly into Phase II. Therefore, Phase I awards will not be made for this topic. The applicant is required to provide detail and documentation in the Direct-to-Phase-II (D2P2) proposal which demonstrates accomplishment of a “Phase I-type” effort, including a feasibility study. This includes determining, insofar as possible, the scientific and technical merit and feasibility of ideas appearing to have commercial potential. It must have validated the product-mission fit between the proposed solution and a potential U.S. Air Force (USAF) and/or USSF stakeholder. The applicant should have defined a clear, immediately actionable plan with the proposed solution and the U.S. Department of the Air Force (DAF) customer and end-user. The feasibility study should have: Clearly identified the potential stakeholders of the adapted solution for solving the USAF and/or USSF need(s). Described the pathway to integrating with DAF operations, to include how the applicant plans to accomplish core technology development, navigate applicable regulatory processes, and integrate with other relevant systems and/or processes. Describe if and how the solution can be used by other U.S. Department of Defense (DoD) or Governmental customers.

Phase II will build upon existing technology to take the next step in maturity. The successful completion of Phase II should be production of a production representative article (PRA) that can be space qualified and meets the SWaP and performance requirements. Phase II activities include: Prototype Fabrication and Assembly: fabricate or procure necessary components to fabricate and test a PRA. Firmware and Software Development: develop and integrate firmware and software necessary to support processing of sensor data and provide output that can be ingested by the bus for autonomous operation. Additionally, necessary data should be formatted for further exploitation on the ground. Environmental and Performance Testing: conduct a comprehensive test campaign to validate payload performance and survivability. Testing is expected to include thermal-vacuum (TVAC) cycling representative of the GEO thermal environment, random vibration testing to assess launch survivability, and electromagnetic interference (EMI) testing to ensure no harm to other space vehicle sub-systems. Laboratory-Based Performance Demonstration: conduct performance testing in a laboratory environment to validate key performance parameters. Successful completion of Phase II should be determined by demonstration of the following: Demonstrated performance of unit Successful completion of space environmental testing (TVAC, Random Vibration, EMI) Demonstrated data output format Primary deliverables for Phase II should include: Production Representative Article Performance and environmental test data and reports (End Item Data Package) Reliability analysis A preliminary Interface Control Document (ICD) Ground software for commanding the sensor payload and processing telemetry and mission data

Phase III activities, funded through non-SBIR/STTR government contracts or other appropriate funding mechanisms, are intended to support the continued maturation, qualification, and operational integration of technologies. These efforts would focus on advancing the payload toward flight-qualified configurations suitable for incorporation into operational Space Domain Awareness (SDA) mission architectures. Potential Phase III activities may include qualification of the payload design for space flight, refinement for manufacturability and scalability, integration support with host spacecraft platforms, and preparation for operational testing and evaluation (OT&E). Where appropriate, Phase III may also support Low-Rate Initial Production (LRIP) planning and execution, subject to government priorities and funding availability. Upon successful completion of Phase II, the payload is expected to achieve approximately TRL 6, representing a system or prototype demonstrated in a relevant environment. Phase III efforts may mature the technology to TRL 8 through flight qualification and system-level testing, and ultimately to TRL 9 upon successful on-orbit deployment and operational use. The full scope of potential Phase III efforts is defined in 15 USC 638 and SBA SBIR/STTR Policy Directive (PD), Section 4(c). Per Section 4(b)(2) of the PD the Government may, at its discretion, include Phase III procedures into its Phase II Funding Agreement.

How much emphasis is there on visible vs IR vs RF?

No emphasis. 

Are solutions employing deployable booms within the scope of this effort?

Deployables may be a possibility however it is not the baseline. 

For full 4Pi steradian coverage, sensors may need to be exposed to propulsion effluents. What should we assume for the type, frequency, and fluence of these effluents?

This remains a bus-agnostic solicitation. Consequently, host propulsion systems will not be defined. Clearly state any assumptions made regarding thruster plume keep out zones and physical/operational mitigation strategies or limitations including both transient and long term effects. 

Can sensors be distributed around the satellite bus to minimize occlusions?

Yes, as long as total system still meets the SWaP requirements. 

If a scanning solution is allowed, at what rate does the 4Pi steradian need to be scanned?

Whatever is necessary to meet the requirements in the solicitation (an "awareness bubble" is the end goal. Continuous instantaneous awareness of all areas at all times is not required). 

What is the astrometric accuracy desired for object detections?

<= 5 arcseconds (1σ), consistent with 0.01deg relative angular motion and detection criteria for initial detection. 

Should we assume that sensors may need to survive indefinite exposure to the sun within the field of view?

One should assume that the sensor may periodically point at the sun as required to support the primary mission. 

Power requirement: Does the preferred 50 W value refer to average operating power or maximum instantaneous power for the complete payload? Are higher transient peaks acceptable if their duration and duty cycle are documented?

50 W orbit average power. Higher peaks may be acceptable. 

Detection performance: What reference assumptions should proposers use to demonstrate the specified object-size, range, detection-probability, and false-alarm requirements—for example, target reflectivity, illumination/phase angle, relative angular rate, and observation interval? How should solar exclusion zones and eclipse conditions be treated when assessing persistent coverage?

For modeling detection performance you can assume a Lambertian spherical target with an albedo of 0.2 at 200-500 km distance. Solar phase angle <= 150°. Relative angular rate of 0.01° can be assumed. Proposers should clearly state their assumptions, including exclusion zones based on solar geometry and/or space vehicle obstructions. The system must achieve a probability of detection (Pd) of 0.8 at a probability of false alarm (Pfa) of 0.01 under these conditions. Proposers shall clearly state the assumed integration time (or number of frames), SNR threshold, and background model used in their analysis.

Sensing modality: Are entirely passive, visible-band electro-optical payloads with onboard tracking and behavior assessment within scope, provided they meet the performance requirements, or is a combination of sensing phenomenologies expected?

A combination of sensing phenomenologies is not required. The only expectation is that the requirements listed in the solicitation (the performance and SWaP) are met. 

What level of onboard characterization is actually useful to the operator or host spacecraft once an object has been detected and tracked?

Orbital parameters, direction, size, etc.

Is TAPPAS intended to favor integrated multi-modal payloads, or is the Government agnostic as long as the performance thresholds are met?

Agnostic as long as performance thresholds are met. 

What level of integration with an existing servicer, OTV, or government architecture would you expect in a competitive D2P2 proposal?

None expected. 

For on-board processing, is there an expectation of the system to trigger or select action, or reporting action to the ground? Should that be part of the system?

System simply needs to flag and characterize events. 

Is the government looking for only multispectral (EO and RF), or would it consider an EO-specific solution?

The proposed solution does not have to be multispectral. 

Would a sensor-agnostic fusion/processing architecture paired with mature sensor hardware be responsive, or is the Government expecting prior demonstration of the complete integrated payload?

Yes, that solution would be responsive, the government is not expecting prior demonstration of complete integrated payload. 

For CMMC2 - can we get self-certified after submission and before the award?

Yes. The CMMC Level 2 self-assessment is required by contract award and is not required by proposal submission. 

Stakeholder validation: What documentation is expected to demonstrate the product-mission fit and actionable customer/end-user plan for this specific topic? Is a stakeholder endorsement required, or can proposers substantiate this through prior relevant government work and a documented integration plan addressing the published TAPPAS requirements?

The Government is not able to make prospective Phase I-equivalent feasibility determinations, however the nature of the work described sounds like it could meet this requirement. The feasibility standards for the topic are outlined in the Phase I field description in the topic, so provided that applicants can meet those requirements, the Government is likely to make a positive feasibility determination. 

Probability of false alarm of 0.01 — is that specified per frame, per detection opportunity, or per unit time?

Per detection opportunity

Are there a minimum number of viewpoints that are desired to avoid conflicts with other spacecraft structures (solar arrays, payloads, etc.)? 

The sensor should have the ability to mask detection in certain regions where occlusions exist, whether from the space vehicle or natural sources. 

For the 4pi steradian coverage, is an exclusion area around the sun, earth, or moon permitted? 

Yes

Are there recommended transition partners, spacecraft integrators, manufacturers, or other stakeholders that offerors should contact?

No

Is there a specific program of record, host platform, or Space Domain Awareness architecture where the Space Force envisions this technology transitioning?

No

Which host-bus power, data, thermal, mechanical, and mission-data interfaces should drive the preliminary Interface Control Document and production representative article?

Expect data interface to be ethernet. Power will be unregulated 28V. TVAC, random vibration, and other space environmental requirements should be consistent with GEO missions, consistent with SMC-S-016. No other specifications will be prescribed at this time.

What Technology Readiness Level and Manufacturing Readiness Level should the solution demonstrate at D2P2 award and at the end of Phase II?

TRL3 minimum prior to award and TRL6 at end of Phase II. 

For the required Phase I-equivalent feasibility evidence, should offerors emphasize modeling, simulation, and trade-space analysis, or is a hardware demonstration expected?

Offers must state clearly what has been performed to date (hardware or simulation). 

Given the emphasis on proven technology and speed of delivery, is the priority a higher-risk, high-reward approach or a lower-risk approach that enables faster deployment?

As a D2P2, capability should already be proven in some extent. Trending towards fast delivery and lower risk.

How should offerors trade field-of-regard occlusions and detection performance against SWaP-C?

We do not have a metric however we are interested in that information. Proposal should clearly state limitations of the proposed system

Which sensing phenomenology or combination of electro-optical, infrared, and radio-frequency sensing is the highest priority?

We do not have a highest priority phenomenology.

Autonomy: The topic calls for sensor data to "feed into advanced on-board analytics" for autonomous tracking, intent assessment, autonomous tactical response, and operator visualization. Does the payload need to include the compute to perform detection, classification, and alerting independent of the host bus, or is "on-board" satisfied by analytics hosted elsewhere on the spacecraft, with the payload providing calibrated detection-level data as its interface?

The payload must have its own inherent onboard analytics (cannot rely on bus to do this). The system should be designed to allow for updates to software and algorithms as refinements are made.

Mass/power basis: Do the 50 W and 15 kg figures apply to the sensing payload as a complete system (the sum of all distributed sensor elements, electronics, and harness), or to a single sensor unit? Separately, are those figures a hard threshold for a responsive proposal, or an objective, given the topic frames them as what the "ideal" payload would not exceed rather than using the threshold/objective language applied elsewhere in the topic?

The SWaP requirements refer to the entire system as a whole (either one unit or combination of many sensors/etc.) These are the threshold numbers (Not To Exceed). 

Distributed sensing: Is it within scope for the sensing payload to consist of several smaller elements (e.g., multiple cameras) distributed around the host spacecraft, or is the government specifically seeking a single, unitary sensor package?

Smaller elements are allowable, however the totality of the smaller elements must still meet the overall SWaP requirements listed in the solicitation. This includes any associated harnessing required for remoting sensors.

Phenomenology: The topic lists multiple phenomenologies "of interest, to include but not limited to, electro-optical, infrared, and radio frequency." Is a multi-phenomenology sensing suite required for a responsive solution, or would a single-phenomenology payload that meets the range, resolution, probability of detection, and probability of false alarm thresholds be considered fully responsive?

No, it does not need to be multi-phenomenology. 

Coverage: The topic calls for "persistent, 4 pi steradian awareness." Does "persistent" require continuous, real-time coverage of the full sphere, or would a payload using a small number of sensors that regularly slew across the 4 pi steradian, trading instantaneous field of regard for revisit rate, also be responsive?

A revisit rate could also be responsive. 

Will the government offer feedback on specific RFI responses prior to developing them into full proposals?

No, specific questions will be answered by the program answered as received. 

Do you have any recommendations for the TVAC profile?

SMC S-016

Does Space RCO have preferred or required facilities/vendors for these qualification tests?

No, but full qualification tests results are required. 

SWaP allocation: For the power and weight limits identified in the solicitation, may the proposed solution consist of multiple pods, with each pod meeting the specified power and weight constraints, or is the stated SWaP limit intended to apply to the complete integrated system across all pods?

The entire system must stay within the SWaP limits.

International suppliers: Are international partners acceptable for components such as cameras, sensing hardware, and compute boards? Are there preferred countries, sourcing requirements, or vendors that we should prioritize or avoid?

For both Phase I and Phase II, the R/R&D work must be performed in the United States. However, based on a rare and unique circumstance, agencies may approve a particular portion of the R/R&D work to be performed or 35 obtained in a country outside of the United States, for example, if a supply or material or other item or project requirement is not available in the United States. The Funding Agreement officer must approve each such specific condition in writing. 

What processing budget does the payload allow? Sense making at the edge is a different problem at one watt than at ten.

The system should not exceed 50W orbit average power.

Is there a preferred interface or data standard the on board assessment should be written against for the shared tactical space picture?

Ethernet is required.

The topic covers both the payload and the on board sense making. How does the Government expect these to be teamed, and is the sense making software evaluated on its own merits within a payload proposal?

Proposal must provide a complete solution. The complete solution will be evaluated in its entirety. The system should also include ground command and control and data processing algorithms. 

1. Detection assumptionsFor the 0.5 m at 200 km threshold and 0.2 m at 500 km objective, will the Government prescribe target/background assumptions such as reflectivity, illumination/phase angle, and background, or should offerors define and justify their own?2. Pd / Pfa definitionHow will the probability of detection and probability of false alarm of be evaluated—for example, per observation, dwell, scan, or track opportunity?3. Detection versus trackingDo the stated size/range performance metrics apply to initial detection only, or must autonomous tracking and characterization also meet those conditions?

For modeling detection performance you can assume a Lambertian spherical target with an albedo of 0.2 at 200-500 km distance. Solar phase angle <= 150°. Relative angular rate of 0.01° can be assumed. Proposers should clearly state their assumptions, including exclusion zones based on solar geometry and/or space vehicle obstructions. The system must achieve a probability of detection (Pd) of 0.8 at a probability of false alarm (Pfa) of 0.01 under these conditions. Proposers shall clearly state the assumed integration time (or number of frames), SNR threshold, and background model used in their analysis. A dark sky background dominated by stellar background and zodiacal light can be assumed, but all assumptions and performance limitations should be clearly stated.Per detection opportunityDetection and tracking are both subject to the distance and size conditions stated. Characterization is not necessarily expected at these sizes and range, but the proposal should clearly state expected performance for characterization.

Under this topic, can a company submit two proposals?  

DSIP will NOT restrict multiple submissions from an SBC for this solicitation. 

1. How does the Government define “persistent 4π steradian awareness”?2. Does the requirement mean simultaneous instantaneous coverage of nearly the full sphere, or would a rapidly scanning architecture with onboard track maintenance and periodic revisit satisfy the intent?3. If scanning/revisit is acceptable, what maximum revisit time does the Government consider sufficient to maintain the required local awareness bubble?4. Are the 15 kg and 50 W values hard requirements or desired design objectives?5. If a multi-sensor architecture exceeds one of those values but materially improves coverage, redundancy, and probability of detection, how would the Government evaluate that trade? 

Full spherical coverage of that which surrounds a space vehicle to the extent defined in the solicitation. A revisit rate can adequately satisfy the "persistent" portion of this requirement.Simultaneous instantaneous awareness of nearly the full sphere is not required. A rapidly scanning architecture and periodic revisit can satisfy the intent.Scanning/Revisit is acceptable. Revisit rates must adequately maintain awareness around the spacecraft. Please define the limitations of your system in the proposal.Hard Requirements. A low-SWaP answer to the solicitation requirements is the priority. 

SpaceWERX, in partnership with Cyberspace Warfare professionals within the U.S. Space Force (USSF), are seeking innovative solutions supporting the next generation capabilities to defend space systems from adversarial attack through the cyber domain. The desired outcome is to produce capabilities that advance the domain of defensive cyber warfare operations in 8 different focus areas. Each focus area presents a unique opportunity for industry to develop innovative solutions and provide critical capabilities to the USSF. This initiative supports the USSF’s broader strategy to generate, present, sustain, and improve Cyberspace Warfare forces for the Joint Force.

The USSF’s defensive cyber operations mission is focused on the rapid integration of capabilities into the Defensive Cyber Warfare (DCW) pipeline to address unique and complex cybersecurity requirements for space systems. This effort aims to enable the scaling of current DCW systems for widespread protection and to improve USSF operational readiness. Modernizing Defensive Cyber Warfare for Space requires shifting from fragmented, reactive security to a cohesive, intelligence-driven posture that spans from the commercial supply chain to the orbital edge. This initiative is seeking to build a unified defense ecosystem where AI-enhanced vetting ensures the integrity of hardware and software long before deployment. Once operational, agile data architectures will seamlessly normalize complex telemetry across hybrid networks, fueling advanced machine learning engines to autonomously detect and intercept threats in real time. The focus areas should optimize the existing IT environment to minimize cost and maximize efficiency. By extending these lightweight, resilient safeguards directly onto spacecraft and disconnected ground infrastructure, and validating them through hyper-realistic, immersive training environments, this initiative aims to equip cyber operators with a decisive, end-to-end advantage against advanced adversaries. The initiative is organized around eight primary focus areas to address critical technical challenges:Focus Area #1: Lightweight and Cloud-Agnostic Data IngestDevelop a cohesive, high-throughput data ingestion solution for on-premises and cloud environments that is infrastructure-agnostic.Focus Area #2: Defensive Cyber Warfare Systems - Proactive Software Assurance and Malware Detection Deliver automated security vetting for third-party software, generating Software Bill of Materials (SBOMs) and conducting risk assessments to identify vulnerabilities.Focus Area #3: On-Orbit Space Vehicle Cyber Defense and MonitoringSeek software-based capabilities with minimal Size, Weight, and Power (WaP) for advanced on-satellite monitoring and autonomous response directly on Space Vehicles.Focus Area #4: Immersive Space Cyber Test EnvironmentEstablish high-fidelity test platforms, integrating simulated assets like digital twins and ground systems for operator training.Focus Area #5: Adaptive Data Parsers and Transformation EngineBuild adaptive engines capable of universally ingesting and normalizing diverse data types into standardized formats for DCW analytics.Focus Area #6: AI-Driven Cyber Threat DetectionLeverage Artificial Intelligence (AI) and Machine Learning (ML) for behavior-based threat detection to identify anomalies across multi-domain data sources in bandwidth-constrained environments.Focus Area #7: AI-Driven Digital Supply Chain Illumination and Risk ManagementDeliver analytical tools providing deep, multi-tier visibility to identify threats ranging from cyber risks to geopolitical vulnerabilities.Focus Area #8: Portable Edge Cyber Defense KitDeliver self-contained, plug-and-play kits for threat detection and response in disconnected, intermittent, and low-bandwidth (DIL) environments.

This topic is intended for technology proven ready to move directly into Phase II. Therefore, Phase I awards will not be made for this topic. The applicant is required to provide detail and documentation in the Direct-to-Phase-II (D2P2) proposal which demonstrates accomplishment of a “Phase I-type” effort, including a feasibility study. This includes determining, insofar as possible, the scientific and technical merit and feasibility of ideas appearing to have commercial potential. It must have validated the product-mission fit between the proposed solution and a potential U.S. Air Force (USAF) and/or USSF stakeholder. The applicant should have defined a clear, immediately actionable plan with the proposed solution and the U.S. Department of the Air Force (DAF) customer and end-user. The feasibility study should have: Clearly identified the potential stakeholders of the adapted solution for solving the USAF and/or USSF need(s). Described the pathway to integrating with DAF operations, to include how the applicant plans to accomplish core technology development, navigate applicable regulatory processes, and integrate with other relevant systems and/or processes. Describe if and how the solution can be used by other U.S. Department of Defense (DoD) or Governmental customers.

Proposed solutions should develop and demonstrate innovative technologies to support operations as part of the USSF’s cyberspace warfare for space operations. Solutions should address one or more of the following 8 focus areas: Focus Area #1: Lightweight and Cloud-Agnostic Data Ingest To support future-ready data operations for Defensive Cyber Warfare (DCW) systems, the team is seeking innovative solutions that enable best value, lightweight and efficient data ingestion at the edge or at the hub. A primary challenge is significant infrastructure overhead associated with traditional data capture methods. Solutions are sought that can be deployed with minimal impact to existing systems, providing high-throughput data capture without demanding extensive hardware or complex configurations. The goal is to establish a solution for pulling critical data into analytics platforms, ensuring that on-prem monitoring capabilities are both effective and sustainable. In parallel, this effort is also interested in addressing data ingestion for cloud environments. Proposed solutions should explore potential Cloud Service Provider (CSP) agnostic approaches that offer flexible and scalable data ingestion independent of cloud provider solutions. This includes exploring technologies such as virtual TAPs (vTAPs). The ultimate objective is a cohesive data ingest solution that is independent of the underlying infrastructure, whether it be on-prem, in a single cloud, or across a multi-cloud landscape. Focus Area #2: Defensive Cyber Warfare Systems - Proactive Software Assurance and Malware Detection To safeguard Defensive Cyber Warfare (DCW) systems against an increasingly compromised global software supply chain, the team is seeking advanced capabilities for the deep inspection and security vetting of third-party software packages. This initiative is twofold, addressing the unique challenges posed by both Free and Open-Source Software (FOSS) and non-approved Commercial Off-the-Shelf (COTS) products. The goal is to proactively identify and mitigate threats before they are introduced into critical operational environments. Solutions should be capable of thoroughly evaluating FOSS packages to provide a comprehensive Software Bill of Materials (SBOM) and detailed risk analysis. This capability should automatically alert operators to a range of security concerns, including embedded malware, hidden back-doors, and vulnerabilities corresponding to the Open Worldwide Application Security Project (OWASP) Top 10. A key feature will be the ability to trace the software's origin and development lineage, providing critical intelligence on contributions from foreign entities or known adversaries. A similar vetting mechanism is desired for COTS software not currently on an Approved Product List (APL). This system should leverage innovative techniques such as binary analysis, SBOM generation, or other advanced methods to produce a thorough risk assessment, alerting on both specific security vulnerabilities and broader digital supply chain risks. These detection mechanisms would provide the greatest value if implemented for validation onboard or integrated prior to space system deployment. Focus Area #3: On-Orbit Space Vehicle Cyber Defense and Monitoring The team is seeking the development of an advanced, on-orbit detection and response capability for Space Vehicles (SVs) to directly reduce or negate the impact of cyber-attacks on critical space systems. The primary objective is to deploy a persistent monitoring solution directly onto the SV that can identify and, in approved instances, autonomously respond to malicious activity in real-time. This onboard capability should be designed for seamless integration with existing ground-based Defensive Cyber Warfare (DCW) systems, ensuring that all telemetry and alert data are relayed to terrestrial monitoring centers. Proposed solutions should be capable of monitoring a wide spectrum of the SV’s internal functions. This includes, but is not limited to: detecting unauthorized software, firmware, or critical configuration changes; monitoring traffic on essential, non-redundant components such as the 1553 Bus and SpaceWire; and identifying anomalous behavior such as irregular commands or malware uploads. Furthermore, the system should be sensitive to threat indicators targeting the vehicle’s core subsystems, including triggers related to power manipulation, system timing interference, or unauthorized payload function commands. Upon detecting an approved event, the system should be capable of executing a direct response on the SV and transmitting comprehensive logs to the ground segment for analysis. Given the highly restrictive nature of space platforms, solutions should be engineered with minimal size, weight, and power (SWaP) impact. Software-based solutions that impose a negligible resource footprint on the host vehicle are strongly preferred. Offerors should be aware that development and testing will likely be conducted using high-fidelity environments such as a FlatSat or realistic simulations. Focus Area #4: Immersive Space Cyber Test Environment The team is seeking the development of a comprehensive and immersive test and purple teaming platform designed to prepare cyber operators for the unique challenges of defending space systems against advanced cyber threats. The objective is to create a realistic, hands-on environment where operators can develop and hone their skills in detecting and responding to attacks targeting space assets and their supporting infrastructure. This capability will be instrumental in building a proficient and mission-ready cyber defense workforce. The proposed solution should include the creation of two core high-fidelity components: a simulated space asset, which could be a physical FlatSat or a sophisticated digital twin, and a corresponding simulated ground system. The ground simulation should realistically model all essential elements, including the ground control segment, remote tracking stations, and antenna systems. A critical requirement is the full integration of the government-furnished Defensive Cyber Warfare (DCW) tool suite, allowing operators to train with the actual systems they will use in live missions. Furthermore, the training platform should come equipped with a robust curriculum of realistic, scenario-based cyber-attacks. These scenarios will serve as the foundation for training exercises and should simulate a range of credible threats, including but not limited to: direct cyber-attacks against the space vehicle's onboard systems, attacks targeting the ground control systems, and threats aimed at compromising the communication and access links between the space and ground segments. Focus Area #5: Adaptive Data Parsers and Transformation Engine The team is seeking solutions for a universal parser or data transformation mechanism capable of ingesting and normalizing a wide array of data types into a single, standardized format for seamless integration into the Defensive Cyber Warfare (DCW) analytics systems. Developing dedicated parsers for each data source is time consuming, labor intensive, and leads to significant code maintenance challenges. To address this, there is a need for an adaptive data parsing or transformation engine that can handle a wide range of data types used in analytics: including space specific protocols, proprietary logs from various network devices, proprietary data types produced by cyber tools, and non-standard formats from numerous intelligence threat feeds. The solution should minimize code maintenance when new Security Information and Event Management (SIEMs) or data structures are introduced and should support the incorporation of new data formats without requiring major code revisions. By transforming disparate data into a common, query-able format, the solution will significantly enhance analytical capabilities and provide a comprehensive, correlated view of the battlespace. This capability is essential for creating a unified and consistent data pipeline, which is fundamental for effective security monitoring, threat hunting, and incident response. Focus Area #6: AI-Driven Cyber Threat Detection In response to the emerging adversarial tactics, the team recognizes that traditional signature-based detection methods are no longer sufficient to provide a decisive advantage and are seeking to augment Defensive Cyber Warfare (DCW) systems with an advanced, behavior-based threat detection capability. This solution should leverage artificial intelligence (AI), machine learning (ML), or advanced heuristics to establish a baseline of normal activity and proactively identify anomalies indicative of a compromise. To address this need, enhanced AI/ML driven threat detection and analysis is required, including anomaly detection across multi domain data sources such as network, host, user, and space specific telemetry; automated threat hunting that correlates disparate indicators to reveal hidden patterns; predictive analytics that identify potential attack vectors before they are exploited; and natural language processing that can automatically analyze and correlate intelligence from multiple threat feeds. Additionally, AI/ML capabilities should be trained in an operational-like environment to reduce noise and optimize detection capabilities. The AI/ML capabilities should also be able to operate effectively in bandwidth constrained or contested environments common in space operations. Automated triage and prioritization of alerts is needed to reduce analyst fatigue and speed response times, along with AI assisted incident response recommendations informed by historical attack patterns and mission context. Focus Area #7: AI-Driven Digital Supply Chain Illumination and Risk Management The team is seeking a comprehensive digital supply chain risk management capability to safeguard the flow of software and hardware from vendors and suppliers. In an era of interconnected, global supply networks, proposed solutions are needed that leverage Artificial Intelligence (AI) and advanced analytical tools to provide deep, multi-tier visibility and proactive risk identification across the entire supplier ecosystem. This capability should continuously monitor and analyze a wide range of data sources to deliver real-time intelligence on potential disruptions. This includes detecting cybersecurity risks, such as data breaches or attacks within a supplier's network, as well as broader supplier and operational risks, including material shortages, production delays, financial instability, or legal and labor issues. The system should use AI to identify and alert on emerging threats that could impact the ecosystem, allowing us to protect against both immediate cyber threats and long-term operational disruptions. By creating a unified view of the supply chain and automating the detection of vulnerabilities, this capability will enable us to move from a reactive to a predictive and resilient posture, ensuring the integrity and continuity of DCW systems. Focus Area #8: Portable Edge Cyber Defense Kit The team is seeking a lightweight, portable, and plug-and-play "fly-away" kit for cyber threat detection, investigation, and response at remote and forward-deployed locations. As operations increasingly extend into austere environments, the USSF seeks solutions for a self-contained capability that can function effectively with limited or nonexistent network connectivity. The solution should address the challenge of providing robust cyber defense in disconnected, intermittent, and low-bandwidth (DIL) settings where reliance on centralized security infrastructure is not feasible. This Edge Cyber Kit will empower operators to conduct local threat hunting and initial remediation, ensuring the security of critical assets at the tactical edge. The proposed solution should be engineered with a minimal physical footprint (size, weight, and power) to ensure portability and ease of deployment. It should possess the onboard processing and analytical power to autonomously detect and investigate threats without real-time reach-back. A critical requirement is sufficient internal storage to collect and securely hold logs, forensic data, and other mission-critical artifacts for extended periods. This stored data must be easily transferable, allowing operators to push it to central analysis platforms for deeper, post-mission analysis upon their return to a connected environment. The kit should provide an intuitive interface that enables an operator to effectively manage incidents and secure networks in the field, bridging the gap between disconnected operations and enterprise-level situational awareness.

Potential Phase III efforts will pursue transition of the capability to operational use through non-SBIR/STTR funding streams, aiming for a Technology Readiness Level (TRL) of 6 or 7 and demonstrating functionality in relevant environments. Phase II efforts that demonstrate technical maturity, integration feasibility, and mission alignment may be selected for continued development and deployment into operational environments. During Phase III, performers may be expected to: - Advance System Readiness - Demonstrate Operational Capability - Enable Cross-Service Application - Pursue Dual-Use Commercialization Phase III work may be performed with non-SBIR/STTR funding and can include further government-sponsored prototyping, operational transition activities, or commercialization via strategic partners in the defense and aerospace sectors.

For DAF26BX06-DV512, will the Government furnish, or expect the performer to generate, Controlled Unclassified Information during Phase II performance? If so, can the Government identify the anticipated CUI categories (for example, controlled technical information, export-controlled, or operations security) so offerors can correctly scope the contractor information systems subject to the projected CMMC Level 2 (Self) requirement?For DV512, does the Government anticipate that Phase II development, integration, or testing will occur on contractor-owned information systems, on Government-furnished or USSF-hosted systems, or both? Does the projected CMMC Level 2 (Self) requirement apply only to contractor information systems that process, store, or transmit project CUI, or also to solutions deployed into Government environments?For DV512, must the projected CMMC Level 2 (Self) status be posted in SPRS at proposal submission, or is it required only at the time of award? Will a CMMC Status of Conditional Level 2 (Self), with a plan of action and milestones, satisfy the requirement at award?

With a CMMC Level 2 distinction, it is anticipated that the performer could potentially handle CUI on their contractor systems within this Phase II performance.The CMMC Level 2 (Self) requirement applies to both contractor information systems and solutions deployed into Government environments. CMMC Level 2 (Self) requirements must be completed by the time of contract award. A Conditional Level 2 (Self) status with an active Plan of Action and Milestones (POA&M) can satisfy this requirement. Review the Conditional Level 2 (Self) section published under Title 32 of the Code of Federal Regulations (32 CFR Part 170) for additional guidance. 

For Focus Area 6, are there required Phase II detection and triage performance thresholds, baseline comparisons, or threat scenarios? Which measures should demonstrations report—for example, detection rate, false-positive rate, detection latency, analyst workload, and mission-impact prioritization?Must a Focus Area 6 solution independently deliver every listed capability—anomaly detection, automated hunting, predictive analytics, threat-feed language processing, alert triage, and incident-response recommendations—or may it deliver a defined subset integrated with existing DCW capabilities? Which deliverables are mandatory?What connectivity and resource conditions must be demonstrated? For the ground-based Focus Area 6 capability, what bandwidth, outage duration, telemetry delay/loss, event-volume, and compute/storage conditions should Phase II demonstrations cover? Which functions must remain available when connectivity to the primary Elastic data source is interrupted?Beyond consuming Elastic data, what interfaces and output schemas are required for returning detections, investigation results, prioritized alerts, and response recommendations to the existing DCW workflow? Are Elastic-native records sufficient, or are integrations with other operator or response systems required?What mission-context information should Focus Area 6 use for prioritization and response recommendations—for example, asset criticality, mission operating mode, authorized maintenance, and response constraints? Will Government-defined context models or interfaces be furnished during Phase II?For Focus Area 6, what minimum environment fidelity and detection-validation evidence must the completed Phase I-equivalent effort demonstrate, versus capabilities to be developed during Phase II? Are there required space-ground-system behaviors, telemetry categories, or attack scenarios that feasibility testing must cover?

Question 1: Which software artifact types and target operating platforms are the highest priorities for Focus Area 2 vetting during Phase II?Question 2: What security classification and data handling requirements are anticipated for the software artifacts and assessment results used in Focus Area 2 Phase II demonstrations?Question 3: Which measurable technical criteria will the Government use to assess a successful Focus Area 2 Phase II demonstration?Question 4: What machine readable output formats or interface requirements apply to Focus Area 2 software assessment results?Question 5: At what level should Focus Area 2 identify foreign or adversarial contributions, for example supplier ownership, source project lineage, or individual code contributions? 

For DAF26BX06-DV512, VeraKeep LLC’s owner/founder is a full-time active-duty U.S. Army member and therefore cannot satisfy the requirement that the Principal Investigator’s primary employment be with the small business concern.May VeraKeep designate another qualified individual as Principal Investigator who will satisfy the primary-employment requirement, while the owner/founder remains involved in the proposed effort in a non-PI role?If permitted, must the designated PI meet the primary-employment requirement when the proposal is submitted, or only at contract award and throughout the period of performance?If this structure is not permissible, is another compliant staffing structure, waiver, or approved deviation available?

There is no requirement that the company's owner/founder be the PI. The owner/founder may participate in the effort in a non-PI role (such as Key Personnel, Senior Researcher, or Advisor) while designating an external recruit or qualified employee to serve as the project's primary technical lead and official PI. Per the solicitation instructions, "the principal investigator’s primary employment must be with the proposing SBC at the time of the award and during the conduct of the proposed effort." Deviations from this requirement or changes to the principal investigator are subject to the Funding Agreement officer approval. 

Is there a template for this Direct to Phase 2 (D2P2) submission?  The main DoW CSO has a template in Appendix A, but it is for Phase I. For Direct to Phase II, the CSO defers to the “Service/Component-specific Direct to Phase II instructions”, but I don't see a link to any other template for this submission. Is there a “current” Customer Memorandum template available?  The doc suggests that Letters of Support are fine, but there is no information about a CM doc.  Based on previous submissions, AFWERX D2P2s used a CM or MOU, but DV512 doesn't ask for one.Given the “hold” on CMMC Level 2 compliance, I see the “self-rating” comment, but where does that stand with this submission?  Section 5.2 refers you to "Section 2.13" for CMMC, but CMMC is actually in Section 2.6. Section 2.13 covers supply-chain security orders.We completed a NIST 800-171 self-assessment for a recent past award, and posted that score in SPRS. Will that be sufficient for this?

There is not a standard Phase II template for this topic. The “Service/Component-specific Direct to Phase II instructions” refer to the Component Instructions for this topic. No, the DAF AFWERX/SpaceWERX Customer Memorandum form is NOT a requirement for this topic. Currently, Customer Memorandum forms are required for Open Topic solicitations and not Specific Topic solicitations. Since this is a Specific Topic solicitation, this form is not a requirement. The requirement for this topic is CMMC Level 2 (Self). In Section 5.2 of the Solicitation Instructions, it should list Section 2.6 and not 2.13 for additional information related to Cybersecurity Maturity Model Certification (CMMC) Level Requirements. Based on the Level 2 guidance provided in the Solicitation Instructions, it sounds like your small business would satisfy the self-assessment by an authorized CMMC Third-Party Assessment Organization (C3PAO) every three years. However, SpaceWERX cannot provide a final decision based on the second requirement: "Annual affirmation, verify compliance with the 110 security requirements in NIST." If the past award occurred in 2026, then it is likely this requirement will be satisfied. If not, then this requirement will still need to be satisfied by contract award. 

For disconnected Focus Area 8 operations, when locally generated alerts, investigations, operator decisions, response actions, and evidence are returned to the enterprise environment, is simple export to Elastic sufficient, or is there value in preserving and reconciling the relationships among the originating evidence, operator decision, authorized action, execution result, and final disposition?

When an operator authorizes, modifies, rejects, or terminates an automated response action, does the Government expect the system to preserve the identity/role of the authorizing operator, applicable authority or policy, action requested, action approved, execution result, and associated evidence as part of the mission record?

For Focus Areas 3 and/or 8, when a capability operates disconnected from enterprise services, may the solution locally maintain and enforce the current authorized operator, role, mission authority, approved response actions, and automation constraints? If so, should changes made while disconnected be preserved as an auditable record and reconciled with enterprise systems when connectivity is restored?

Focus Area 8: Should Focus Area 8 solutions be designed to integrate with, or export data to, existing USSF Defensive Cyber Operations for Space (DCO-S) enterprise tools such as Kraken and Manticore? If so, what data formats or interfaces should exported data packages support (for example, normalized event logs, network sensor logs, PCAP, STIX 2.1 indicators), and is there a target central analysis platform that data collected at disconnected sites should be prepared for on return?

What is the page limit and format for the DV512 technical volume?Which Elastic data (indices and ECS field sets) will performers get, in what environment, and when?Is space telemetry in the Elastic stack, or do performers bring it?

The Technical Volume (Volume 2) page limit is 20. For more information on the format for this section, review the Component Instructions and the Solicitation Instructions.TheThe

DD Form 2345Because this topic is ITAR-restricted, is proof of a submitted DD Form 2345 application acceptable at proposal submission if certification is still pending on the close date?Release versionWhich solicitation release governs proposal requirements for this topic? Are there changes between earlier releases and the current release that affect Direct-to-Phase-II feasibility documentation?

Evidence of a DD2345 application in progress usually suffices for the initial proposal submission, however it is encouraged to begin this process as quickly as possible because this process will delay award if it is not completed in a timely manner.SBCs are expected to follow the newest release version when developing their proposal package. 

Regarding the multi-domain data sources specified for Focus Area #6 (network, host, user, space-specific telemetry, and threat feeds), will government-furnished telemetry datasets or simulation environments be provided during Phase II to train and optimize the AI/ML behavioral baselines, or are proposers expected to generate synthetic training data? Focus Area #6 emphasizes that AI/ML capabilities must operate effectively in bandwidth-constrained or contested environments common in space operations. Is the priority for the AI/ML inference engine to run on lightweight edge nodes (e.g., onboard the space vehicle) with minimal compute overhead, or on ground-based processing systems designed to ingest and reconstruct degraded telemetry streams?Regarding the requirement for automated alert triage, prioritization, and AI-assisted incident response recommendations, are there specific government-furnished Defensive Cyber Warfare (DCW) tool suites, C2 frameworks, or Security Information and Event Management (SIEM) systems that the engine's outputs must natively integrate with during Phase II demonstrations? 

If possible, the government will provided telemetry datasets but the proposer should be prepared to generate synthetic training data.On ground-based processing systems.This program utilizes Elastic and will be the primary data source for the AI/ML tools to utilize.

The D2P2 evaluation criteria for Topic DAF26BX06-DP027 explicitly states that "signed letters of support from other Government personnel may be indicators of the appropriateness, relevance, and specificity of an identified Defense Need." However, the evaluation criteria listed for Topics DAF26BX06-DV026, DV511, DV512, and DV513 does not include this same language regarding letters of support. Can you confirm whether signed letters of support from Government personnel are considered a valuable or relevant addition to a DV512 proposal under Criteria B (mission impact / specificity of defense requirement), or whether this indicator is intentionally limited to DP027 and not applicable to DV512?

Signed letters of support are not required for this topic. If a proposer has a signed letters of support, they can include that document in the Supporting Documents (Volume 5 Section) but, as previously stated, that is not a requirement for this topic effort. 

What would a successful Phase II demo look like for Focus Area 8? For example, would you expect the kit to operate at a remote site, run disconnected for a period of time, detect and respond to threats, and then sync back to a central cyber environment?

A successful demonstration would show the kit being transported and set up by an operator team, with integrated tools configured and working together. The kit should detect expected threat activity, execute response actions, and export collected data to an Elastic stack. Vendors should propose their own demonstration scenario and success metrics.

For the requirement to autonomously detect and investigate threats, are you expecting AI/ML to be part of the solution, or are you open to a mix of traditional cyber tools and AI-assisted analysis?

It is up to the vendor to determine if AI/ML is the best solution for autonomously detecting and investigating threats. There should be an option to have a human in the loop for all response actions or to turn the automation off completely.

Do you have any target size, weight, and power goals for the fly-away kit? For example, is this something one person should be able to carry, a couple of transit cases, or more of a small rack-sized system?

We do not have any specific SWaP requirements other than it needs to be as small as possible, safe to transport, and able to be carried and set up by a 2-3 person team.

When you say the kit should support "initial remediation", what kinds of actions do you have in mind? Are you thinking mostly operator driven actions or should the system be able to automatically take action? 

Primarily operator-driven actions, which can be automated through playbooks where the mission system owner permits. 

Are there any existing enterprise platforms the kit should be able to connect back to? If so, any specific API's, data formats, or interfaces you want vendors to support?

The kit should be able to transfer collected data, primarily logs, to an Elastic stack in a format that can be parsed into Elastic Common Schema (ECS), either over a network connection or by removable media.

What kinds of networks or systems do you expect the kit to monitor?

Mostly space ground stations with IP-based networks. The kit should also be able to monitor ICS/SCADA and OT network traffic.

Are you looking for a secure edge platform that can host and integrate existing cyber tools, or are you expecting the solution to come with full threat detection, investigation, and response tools already included?

The kit should host and integrate existing Government cyber tools (SIEM, EDR, and SOAR) so detection content, playbooks, and training remain consistent with current operations. Vendors may propose additional capabilities, such as network detection and response (NDR), where they fill a gap. Proposals should describe what is included, what can be integrated, and how the kit operates without connectivity.

For Focus Area #5, does the Government envision the Phase II solution as supporting a defined set of Space Force data formats/interfaces, or would an extensible, source agnostic transformation layer be responsive if it can onboard new formats through governed parsers and semantic profiles? If Government-specific interfaces cannot be provided before award, would the Government view a Phase-I equivalent demonstration using heterogeneous representative formats, with measured normalization performance, explicit unknown/ambiguous-field handling, source-level provenance/locators, and downstream query-ability, as an appropriate technical foundation, with mission-specific adapters and interfaces integrated during Phase II?

The expectation is supporting a defined set of Space Force data formats/interfaces. However, the proposed alternative has value as well. Government-specific interfaces cannot be provided before award so the proposed demonstration and execution would suffice.

There are several commercially available solutions that address Focus Area #7: AI-Driven Digital Supply Chain Illumination and Risk Management. Could you share the rationale for pursuing this requirement through the SBIR program? We would welcome a discussion about whether there is an opportunity to address the requirement through an alternative acquisition path?

The Government recognizes that commercially available solutions address aspects of supply-chain illumination and risk management. This SBIR topic is intended to identify innovative small business approaches that may provide capabilities beyond those currently available or adapt existing methods to the unique hardware, software, firmware, data, and operational characteristics of Space Force mission systems. A resulting capability could support supply-chain risk management for DCO-S components and may also be considered for integration into the DCO-S suite for use by supported mission-system owners. Offerors should clearly identify the innovative aspects of their proposed solution and its applicability to unique Space Force mission environments. The Government may consider other acquisition pathways for mature commercial products when appropriate, but any such action would be separate from the SBIR evaluation and subject to applicable acquisition procedures.

This question was submitted on 09/04/2026 and could not be addressed in the initial response because of character limit constraints.  5. What evidence will the Government consider sufficient to demonstrate completion of a Phase I-type feasibility effort for this focus area? Specifically, is there a preferred minimum number or diversity of source formats, benchmark duration, normalization-accuracy measure, end-user validation activity, or integration demonstration?

Offerors should follow the applicable D2P2 solicitation instructions for demonstrating completion of a Phase I-equivalent feasibility effort. The Government has not established a preferred minimum number or diversity of source formats, benchmark duration, normalization-accuracy measure, end-user validation activity, or integration demonstration beyond the published solicitation requirements. Relevant evidence may include documented technical feasibility; test results using representative data formats; measured parsing and normalization performance; identification and mitigation of principal technical risks; operational-use-case mapping; stakeholder feedback, where available; and an actionable integration and test plan aligned with the selected focus area. Offerors should provide sufficient traceable evidence to demonstrate readiness to proceed directly into Phase II development.

We have validated solutions in more than one focus area. How would SBIR submissions covering more than one focus area be evaluated?

Evaluations are conducted fairly and independently based on standard program criteria. If you have validated solutions spanning more than one focus area, it is recommended to clearly communicate this cross-cutting information within your proposal submission package to ensure reviewing officials understand the full scope and impact of your technology.

We have a solution for Focus Area #3 that has been validated with the Army (aviation) but not a USAF or USSF stakeholder. Is validation with other services considered equally valid? Or is greater weight given to those solutions validated with a USAF or USSF stakeholder?

No preferential treatment will be given to a potential solution based on the service branch that validated it. The key factor is that the potential solution was validated. 

During the Velocity: Cyberspace Warfare for Space Industry Engagement Day on July 14, 2026, a couple of panelist indicated that CUI data from a previous AFRL hackathon event could be made available to interested parties for developing solutions aligned to the published focus areas.Could the Government confirm whether this dataset will be released for use by offerors, and if so, provide an anticipated timeline and distribution method?

The Government does not anticipate releasing the referenced CUI dataset during the solicitation or proposal-development period. The comment made during the panel was intended to indicate that relevant data may be made available to selected performer(s) following award, subject to applicable security, access, handling, and distribution requirements. Specific timing and transfer mechanisms will be coordinated with the selected performer(s).

For the D2P2 Phase I-equivalent feasibility requirement, the topic states that product-mission fit must be validated with a potential USAF/USSF stakeholder and that an immediately actionable plan should be defined with the DAF customer and end-user. What technical evidence is expected to demonstrate this product-mission validation? Specifically, does validation require prior evaluation or demonstration of the proposed technology with an identified USAF/USSF stakeholder, or can it be demonstrated through documented technical feasibility, operational-use-case mapping, integration planning, and test evidence aligned to the selected focus area?

Offerors should follow the applicable D2P2 solicitation instructions regarding the Phase I-equivalent feasibility requirement. From the mission customer’s perspective, prior evaluation or demonstration with an identified USAF/USSF stakeholder is not required to establish product-mission fit. Validation may be demonstrated through documented technical feasibility, operational-use-case mapping, integration planning, relevant test evidence, and an actionable plan aligned with the selected focus area and intended end-user environment. The sufficiency of the submitted evidence will be determined through the applicable SBIR evaluation process.

Questions regarding DAF26BX06-DV512, Focus Area #5: Adaptive Data Parsers and Transformation Engine Has the Government selected or preferred a canonical data model, ontology, or standardized output schema for normalized Defensive Cyber Warfare data, or should offerors propose and justify their own common data model? If a preferred model exists, will its required fields, metadata, and interface specifications be furnished to awardees?Will the Government provide representative unclassified, sanitized, or synthetic datasets, interface-control documents, schemas, or a DCW integration test harness during Phase II? If operational samples cannot be provided, may offerors use traceable synthetic data mapped to published standards to demonstrate technical feasibility?How will the Government evaluate whether a parser or transformation engine is “adaptive” or “universal”? Would onboarding a new format through declarative configuration, schema mapping, or an isolated plug-in—without modifying the core engine—satisfy the intent, or is automated format inference expected?Are there desired quantitative performance thresholds for Focus Area #5, including sustained and burst event throughput, concurrent data-source count, maximum payload size, transformation latency, acceptable rejection rates, and zero-loss or backpressure requirements?What evidence will the Government consider sufficient to demonstrate completion of a Phase I-type feasibility effort for this focus area? Specifically, is there a preferred minimum number or diversity of source formats, benchmark duration, normalization-accuracy measure, end-user validation activity, or integration demonstration? 

The Government has not prescribed a single vendor-specific canonical data model or ontology for this topic. Offerors should propose and justify an extensible, interoperable common data model that preserves original source data, context, and metadata and supports normalization, correlation, search, analytics, and detection. The proposed approach should support reliable mapping to commonly used cybersecurity data models and the Government’s selected data and analytics platform without unnecessary vendor lock-in. Applicable field mappings, interface specifications, and Government-controlled integration requirements will be provided to selected performer(s), as appropriate.Relevant Government datasets and available integration artifacts may be furnished to selected performer(s) during Phase II, subject to availability and applicable security, access, handling, and distribution requirements. The Government does not guarantee that operational samples or a Government-provided integration test harness will be available. Where representative Government data cannot be provided, offerors may use traceable synthetic or sanitized data mapped to relevant published standards and representative DCW use cases to demonstrate technical feasibility. Specific data, interfaces, schemas, test criteria, and integration mechanisms will be coordinated with selected performer(s), as applicable.The Government will assess “adaptive” or “universal” based on the solution’s demonstrated ability to onboard diverse, previously unsupported, or changing data formats while minimizing specialized manual analysis, custom development, and modifications to the core engine. Relevant considerations include onboarding time, required human effort, parsing accuracy, resilience to format changes, validation capabilities, and extensibility across protocol and data types. Declarative configuration, schema mapping, or isolated plug-ins may satisfy the intent when the approach materially accelerates onboarding and avoids modification of the core engine. Fully autonomous format inference is not necessarily required; however, offerors should describe and demonstrate how automation, including AI/ML where appropriate, assists with format characterization, parser or transformation generation, validation, and adaptation to previously unseen or evolving data.The Government has not established uniform quantitative thresholds for all Focus Area #5 use cases. Current operational environments may receive aggregated network traffic at rates up to approximately 40 Gbps; however, the throughput presented to a parser or transformation engine will depend on its architectural placement, source types, and whether it processes raw traffic, extracted data, or derived events. Offerors should provide measured sustained and burst performance, supported source concurrency and payload limits, transformation latency, rejection and error-handling behavior, backpressure and buffering mechanisms, data-loss characteristics, and associated compute requirements. Proposed solutions should demonstrate horizontal scalability and the ability to accommodate growth beyond the initial operational baseline. Specific performance objectives and representative test conditions will be coordinated with selected performer(s) during Phase II.The maximum character limit for this response has been reached. Question #5 will be resubmitted and answered on the platform separately. 

The SpaceWERX Challenge website indicates this is the topic to apply to if a business wants to apply to the On-Orbit Space Logistics Challenge (https://afwerxchallenge.com/on-orbit). This does not seem to match the information contained within this topic pre-release. Can you please clarify?

The On-Orbit Space Logistics Challenge is Topic #: DAF26BX06-DV513. This challenge website should be updated in the coming days. 

For Focus Area 3, may a proposed solution address the authorization and execution-control portion of autonomous cyber response as a complementary capability integrated with existing monitoring and detection systems, or is the Government seeking a solution that independently provides the full Focus Area 3 monitoring, detection, and autonomous-response capability?

The Government is interested in capabilities supporting the full on-orbit monitoring, detection, decision, authorization, and autonomous-response lifecycle. However, proposed solutions are not required to independently provide every element of that lifecycle. Complementary or modular capabilities addressing authorization, decision logic, execution control, or other portions of the architecture may be considered when they provide a clear operational benefit and can integrate with existing or emerging monitoring and detection systems. Offerors should clearly define the scope of their solution, required interfaces and dependencies, integration approach, SWaP requirements, and measures for safe, reliable, and constrained autonomous operation. Selected capabilities may be evaluated and integrated alongside other solutions within the Government’s Space Vehicle Defense laboratory environment.

Will the Government provide access to a representative forward-site network or DIL test environment for the Phase II demonstration, or should proposers plan to furnish their own?

The Government cannot guarantee access to a representative forward-site network or Government-furnished DIL test environment for Phase II demonstrations. Offerors should plan to furnish a representative test environment capable of demonstrating operation under isolated, disconnected, intermittent, or bandwidth-constrained conditions. Solutions that require access to CUI or Government-furnished data should identify an appropriate authorized environment, such as an IL5-capable environment, and clearly state any Government-furnished information, connectivity, or infrastructure dependencies. The Government is pursuing suitable integration and test capabilities and may coordinate access with selected performer(s), if available.

Is Focus Area 8 seeking an inline detection-and-enforcement appliance that protects a forward network segment, a laptop-based analysis toolkit, or both? Are proposals that address Focus Areas 8 and 6 together evaluated as one integrated solution or scored separately?

Focus Area 8 is primarily seeking a portable defensive cyber operations and hunt capability, rather than an inline detection-and-enforcement appliance. The capability should enable Cyber Force Elements to rapidly discover, characterize, and visualize a mission-system network; assess its security posture; identify hardening opportunities; and detect or investigate potential adversary activity. Proposed solutions must be capable of operating in isolated or disconnected environments without reliance on continuous internet or external cloud connectivity. Offerors may propose different form factors, including portable appliance-based or operator-computing solutions, provided they support rapid deployment and non-disruptive operation across diverse Space Force ground-system environments. Offerors proposing an integrated solution spanning Focus Areas 6 and 8 should clearly identify how the solution addresses the objectives and deliverables of each focus area. Evaluation and scoring will be conducted in accordance with the solicitation’s applicable submission and evaluation criteria.

The D2P2 feasibility requirement asks proposers to have validated product-mission fit with a USAF or USSF stakeholder. For a small business with fielded commercial and non-DAF government deployments but no prior DAF contract, what forms of evidence will satisfy this requirement (for example, documented engagement with a USSF unit, a demonstration to a joint cyber command, or a letter of interest)? Will the Government facilitate a stakeholder introduction during Phase II if fit is otherwise demonstrated?

There's some flexibility with this requirement. The SBC needs to logically prove that their technology is feasible given the dollar and time constraints for this contract award. If they are able to do that in the proposal submission package, then it satisfies this feasibility requirement.

For Focus Area 8 (Portable Edge Cyber Defense Kit), can the Government identify the intended end-user organization or mission type (for example, a specific Delta, forward tracking stations, or expeditionary ground operations) so proposers can align the feasibility documentation and Phase II demonstration to that user?

The intended end users are U.S. Space Force Cyber Force Elements (CFEs), trained and equipped through their supporting Cyberspace Operations Squadron (CYS). CFEs conduct defensive cyberspace operations in support of Space Force mission systems and may be employed across a range of ground-system environments. The Government is not limiting this focus area to a specific Delta, installation, or mission system. Proposers should align their feasibility documentation and proposed Phase II demonstration to a portable, adaptable capability that can support CFE operations across diverse Space Force mission systems and operating locations. Specific demonstration users, sites, and mission scenarios will be coordinated with selected performer, as applicable.

The objective of this Direct to Phase II topic is to accelerate the development and demonstration of prototype ready technologies that enable a complete on orbit logistics enterprise. This enterprise must support autonomous resupply, refuel, repair, recovery, and reconstitution of United States space assets across Low Earth Orbit, Medium Earth Orbit, Geosynchronous Orbit, and cislunar space. The goal is to create a logistics architecture that mirrors the resilience and flexibility of terrestrial sustainment systems while adapting to the unique constraints of orbital mechanics. The performer must demonstrate that Phase I equivalent work has already been completed. This includes feasibility studies, stakeholder engagement, technical validation, and early integration planning. The Phase II effort will build upon this foundation to produce a prototype that demonstrates operational relevance, autonomous capability, and a clear pathway to transition into Space Force sustainment operations.

Space systems today are designed for single use and lack the ability to be maintained, repaired, or resupplied once deployed. This design philosophy limits maneuverability, reduces resilience, and forces operators to conserve resources. As maneuver warfare emerges in the space domain, the United States Space Force requires a logistics backbone that provides freedom of action, operational reach, and prolonged endurance. This backbone must support rapid reconstitution, autonomous servicing, multi orbit distribution, and predictive sustainment. The On Orbit Space Logistics Challenge seeks mature technologies that can transition directly into prototype development. These technologies must support a future in which satellites are serviced, refueled, repaired, repositioned, and recovered as part of routine operations. The D2P2 effort will focus on autonomous operations, multi orbit integration, servicing demonstrations, depot interactions, and logistics health monitoring. The performer must demonstrate how their technology contributes to a resilient logistics architecture capable of supporting sustained operations in contested environments. This topic encourages solutions that integrate with broader Space Force concepts such as sustained space maneuver, dynamic space operations, and contested logistics. The performer must show how their technology supports mission continuity, reduces reconstitution burden, and enhances the survivability of critical space assets. Offerors may structure their approach using one of two acceptable architectural frameworks. Both approaches are valid for early exploration and concept development, and both support the broader goal of building a resilient on orbit logistics enterprise. Offerors should select the approach that best aligns with their proposed technology, their integration pathway, and the operational problem they intend to solve. Systems of Systems Approach A Systems of Systems approach views the on orbit logistics enterprise as a collection of interconnected subsystems that work together to deliver sustained combat power. This perspective recognizes that no single technology can solve the logistics challenge alone. Instead, multiple systems must interact across orbital regimes, mission timelines, and operational conditions. Under this approach, the proposer describes how their technology fits within a larger architecture that includes depots, warehouses, orbital transfer vehicles, servicing vehicles, drop ships, and health monitoring systems. The feasibility study should explain how the proposed system interacts with other systems, how it contributes to distribution loops, and how it supports the overall sustainment mission. This approach is well suited for technologies that enable integration, coordination, or interoperability across multiple nodes. A Systems of Systems framing encourages proposers to think about interfaces, standards, autonomy, and mission sequencing. It also supports early identification of dependencies, constraints, and opportunities for modularity. This approach is particularly useful for technologies that enable routing, servicing, depot operations, or multi orbit logistics planning. Logistics Function Approach A Logistics Function approach focuses on the specific logistics activity that the proposed technology enables. Instead of describing the entire architecture, the proposer concentrates on the function their system performs. Examples include refueling, repair, recovery, resupply, warehousing, or health monitoring.Under this approach, the feasibility study explains how the proposed technology improves the performance of a particular logistics function. The proposer describes the operational need, the current limitations, and the functional improvements their solution provides. This approach is well suited for technologies that perform a discrete logistics task, such as propellant transfer, component replacement, autonomous inspection, or orbital resupply. A Logistics Function framing encourages proposers to think about efficiency, reliability, throughput, and mission impact. It also supports early demonstration of measurable improvements in sustainment operations. This approach is particularly useful for technologies that provide a clear, direct enhancement to a single logistics capability. Selecting the Appropriate Approach Offerors may choose either approach. The selection should be based on the nature of the proposed technology and the operational problem it addresses. A Systems of Systems approach is appropriate when the technology interacts with multiple nodes or contributes to enterprise level coordination. A Logistics Function approach is appropriate when the technology performs a specific task that can be evaluated independently. The proposer must clearly identify which approach they are using and explain why it is appropriate for their concept.

This topic is intended for technology proven ready to move directly into Phase II. Therefore, Phase I awards will not be made for this topic. The applicant is required to provide detail and documentation in the Direct-to-Phase-II (D2P2) proposal which demonstrates accomplishment of a “Phase I-type” effort, including a feasibility study. PHASE I EQUIVALENT WORK REQUIREMENTSOfferors must provide documentation demonstrating completion of Phase I equivalent work. This documentation must be thorough, detailed, and clearly aligned with Space Force operational needs. The following elements are required.Stakeholder EngagementThe performer must show that they have engaged with Space Force operators, program offices, mission owners, or acquisition stakeholders. This engagement must demonstrate that the proposed technology addresses a real operational need and has a clear customer within the US Space Force.Feasibility StudyThe feasibility study must demonstrate technical merit, operational relevance, and mission fit. It must show that the proposed technology can operate in the space environment, integrate with existing systems, and support logistics operations across multiple orbital regimes. The study must include analysis of technical risks, operational constraints, and integration challenges.Integration PathwayThe performer must describe how the technology will integrate into Space Force logistics operations. This includes interfaces, standards, autonomy requirements, mission sequencing, and coordination with other logistics systems. The integration pathway must show how the technology contributes to a broader sustainment architecture.Regulatory ConsiderationsThe performer must identify regulatory considerations such as ITAR, EAR, licensing, and safety requirements. The documentation must show how the performer plans to comply with these regulations during Phase II and Phase III.Commercial Dual Use PotentialThe performer must demonstrate how the technology can be used by commercial customers such as GEO operators, satellite manufacturers, or insurance providers. This dual use potential supports long term sustainability and transition.Phase II Prototype PlanThe performer must provide a clear and actionable plan for Phase II prototype development. This plan must include technical milestones, integration activities, testing requirements, and demonstration objectives.

The On Orbit Logistics Challenge includes several technical focus areas. D2P2 proposals must address at least one focus area. Expanded descriptions are provided to guide prototype development and ensure alignment with Space Force needs.Propellant ManagementPropellant management is essential to sustained maneuver, servicing, and logistics operations in space. A resilient on-orbit logistics enterprise requires the ability to store, transfer, meter, monitor, and manage propellant across multiple orbital regimes. Relevant propellant classes may include cryogenic propellants, storable chemical propellants, electric propulsion propellants, pressurants, and emerging multi-mode propulsion consumables.Space Access PAE is seeking prototype-ready technologies that improve the availability, transferability, storability, quality assurance, and operational utility of propellant within an on-orbit logistics architecture. Proposed solutions should demonstrate how they support safe, reliable, and precise autonomous fueling operations and how they integrate with depots, orbital transfer vehicles, servicing systems, and client spacecraft.D2P2 prototypes should demonstrate one or more of the following: autonomous propellant transfer methods, standardized or interoperable refueling interfaces, depot integration, propellant distribution operations, propellant quality monitoring, or technologies that improve the military utility and affordability of on-orbit refueling and maneuver sustainment.- Desired Capabilities: Autonomous propellant transfer and refueling operations, Propellant quality monitoring, conditioning, and conversion, Quick-connect, standardized, or interoperable mechanical and fluid interfaces, Precision metering and custody tracking during storage and transfer, Zero-gravity transfer, docking, grappling, and fluid handling, Foreign object debris inspection, contamination control, and quality assurance, Compatibility with depot operations, orbital transfer vehicles, and client spacecraft, Secondary utility such as cargo rideshare or optical inspection, where relevant- Enabling Technologies: Pressurant recycling and management, Propellant storage and sustainment technologies, including boil-off mitigation, Servicer and depot refueling interfaces, Size-appropriate zero-gravity transfer systems, Multi-mode propellant and propulsion support systems, In-space propellant extraction, processing, or conversion, Sensors and diagnostics for propellant condition monitoring, Autonomous control systems for fueling safety, sequencing, and anomaly response. Proposals in this focus area should clearly address the following as appropriate:- Supply Chain and Sourcing: the proposal should describe the relevant propellant supply chain, including industrial availability, production sources, expected throughput, and any dependence on terrestrial or in-space sources. Where applicable, proposals should address the potential role of in-situ resource utilization, including extraction or processing from lunar, asteroid, or other space-based resources.- Transfer and Storage: the proposal should describe how the propellant will be stored, transferred, and sustained over time. This should include expected storage duration, boil-off or loss characteristics where applicable, zero-boil-off or loss-mitigation approaches if relevant, and the method by which the solution supports interoperability across multiple systems or platforms. Proposals should identify whether they use existing interfaces, are designed to conform to emerging government or industry standards, or require a new interface approach.- Metering, Quality Control, and Custody: the proposal should describe how the system meters propellant and maintains propellant quality during storage, transfer, and delivery. This should include approaches for contamination control, foreign object debris mitigation, quality monitoring, and assurance of propellant condition while under the performer’s custody. Proposals should explain how propellant is received from an upstream source, managed during transport or storage, and delivered to the next node in the logistics chain, such as a depot, distribution vehicle, or end-user spacecraft.- Value Chain Role and Integration: the proposal should identify the specific portion of the in-space propellant value chain being addressed. This may include production, extraction, transportation, storage, quality management, metering, distribution, or propulsion-system support for mobility restoration or reuse. The proposal should also describe the broader military-relevant system or architecture to which the proposed intellectual property or capability contributes, such as reusable launch systems, reusable orbital transfer vehicles, depots, distribution fleets, or propulsion maintenance support systems.- Economics and Military Utility: the proposal should describe how the technology improves the cost, availability, responsiveness, or operational effectiveness of propellant delivery and use in space. This may include reduction in delivered cost per kilogram, improved availability at key orbital nodes such as GEO, increased maneuver endurance, greater operational reach, improved flexibility, or enhanced ability of space assets to generate mission effects.Orbital Transfer VehiclesOrbital Transfer Vehicles (OTVs) are the workhorses of the logistics enterprise. They move supplies, tow damaged satellites, reposition assets, and deliver benchstock. An OTV must be capable of multi stop routing, autonomous navigation, and precision maneuvering. It must operate across multiple orbital regimes and support both planned and reactive logistics operations. D2P2 prototypes must demonstrate modular chassis designs, autonomous navigation, precision propulsion control, and multi stop routing. The prototype must show how the OTV supports distribution loops and interacts with depots and satellites. The performer must demonstrate how the OTV maintains safety during autonomous rendezvous and proximity operations.- Desired Capabilities: Refuelability, reusability, inter/intra-domain mobility, interfacing with multiple systems, including depots, clients, and launch vehicles, ability to handle and grapple supplies, long-duration mission survivability (radiation), spacecraft anomaly diagnosis, high delta-V performance, and standardized storage/containerization.- Enabling Technologies: Reconfigurability, interoperability, with specific mechanical, refueling, or electrical interfaces, autonomous RPOD (Rendezvous, Proximity Operations, and Docking), with on-orbit navigation and prioritization, different OTV classes or tiers by thrust and fuel type, built to readily available standards, modularity for component upgrades, radiation-hardened compute, and encryption/security, cryogenics and boil-off management, fuel-on-orbit capability, and containerization (a terrestrial analogy), FOD mitigation and verification, or center of gravity (CG) management and stability control for coupled loads, specific impulse (Isp) efficiency improvements, multi-mode propulsion, and robotic manipulation.Network MechanicsNetwork Mechanics encompasses the integrated system of interfaces, connectors, docking systems, and the underlying orbital dynamics and operational standards that enable logistics systems to interact reliably and efficiently across the space domain. A robust logistics enterprise requires not only common physical interfaces for vehicles to dock, depots to exchange materials, and servicing systems to manipulate payloads, but also sophisticated orbital planning, navigation, and coordination mechanisms to manage the movement and interaction of these assets. D2P2 prototypes must demonstrate standardized connectors, docking operations, autonomous rendezvous safety protocols, and interface modularity. Crucially, prototypes must also show how they leverage advanced orbital mechanics principles for efficient trajectory optimization, collision avoidance, and synchronized operations within a dynamic network of space assets. The prototype must show how the technology improves interoperability and reduces complexity across the logistics enterprise, while ensuring safe and fuel-efficient orbital maneuvers. The performer must demonstrate how the system supports modularity and reduces the number of unique form factors in orbit, integrated with intelligent orbital management.- Desired Capabilities: Logistics management, power beaming, or robotics, supported by analytical tools for variables like client count and propellant needed, Debris detection, training missions, or war-gaming, Hybrid propulsion coordination across the network, or the ability to troubleshoot anomalies, RPOD or cargo handling (space tugs), including recycle center refurbishment, Servicing frequency, routing, and autonomy that adapt to changing demand and reduce latency in high-demand areas, Asset protection, security, and access control, Autonomous orbital trajectory optimization for multi-asset coordination and fuel efficiency, Real-time collision avoidance and dynamic re-routing capabilities for networked assets, Precise orbital synchronization and station-keeping for distributed logistics nodes, Multi-body orbital mechanics solutions for cislunar and beyond-GEO operations.- Enabling Technologies: Refueling interfaces or power beaming, Functional network nodes or a control plane, Novel propulsion integration for network coordination, Artificial intelligence (AI)-leveraged decision support or ontology development, Sensors for troubleshooting or debris detection, Advanced astrodynamics modeling and simulation for complex orbital scenarios, Autonomous navigation and guidance algorithms for precise orbital maneuvers, Distributed computing architectures for real-time orbital state estimation and prediction, Space Domain Awareness (SDA) integration for enhanced orbital safety and operational planning, Inter-satellite communication networks for synchronized orbital operations, Optimization algorithms for minimizing delta-V and transit times across the logistics network.Orbital WarehousingWarehouses and depots serve as storage and distribution nodes. They must hold propellant, spare parts, tools, consumables, and modular components. They must support autonomous material handling, inventory management, and asset visibility. They must operate in multiple orbital regimes and support both routine and emergency operations. D2P2 prototypes must demonstrate depot construction concepts, inventory management systems, autonomous material handling, and environmental control. The prototype must show how depots support OTV operations, maintain asset visibility, and reduce logistics complexity. No reliance on a unique interface for supply delivery, free-flying containers for diverse assets, and data on commercial capabilities. The performer must demonstrate how the depot maintains reliability and throughput during autonomous operations.- Desired Capabilities: More autonomy, modularization, and system resilience, sizeable warehouses with self-healing support systems, ability to deliver parts across different orbits, with an economy and in-house operations that scale, warehouse resupply processes and secure, tamper-resistant tracking (e.g., blockchain), super heavy lift or in-space assembly, and versatile, adaptable infrastructure supporting mission integration and intermodal transportation.- Enabling Technologies: Space pallets and standards for space operations and interfaces, power beaming, visibility of inventory and speed of delivery, retractability and rapid, repeatable rendezvous and proximity operations (RPO), employing and testing new tech in the domain, including autonomous robotic manipulation, no reliance on a unique interface for supply delivery, free-flying containers for diverse assets, and data on commercial capabilities.Reuse, Repair, Refuel, and RecoveryThis focus area addresses modular component replacement, robotic repair, autonomous triage, and towing of damaged satellites. Servicing vehicles must be able to diagnose faults, perform repairs, and support operational tempo. Recovery operations must support both planned maintenance and emergency response. D2P2 prototypes must demonstrate how servicing vehicles diagnose faults, perform repairs, and support operational tempo. The prototype must show how repair operations reduce reconstitution burden and increase endurance. The performer must demonstrate how the system maintains precision and reliability during autonomous repair operations.- Desired Capabilities: LRU/ORU (line- and orbital-replaceable units), mindful of mass, and non-life-limiting components, serviceable systems and capabilities, adaptable software and distributed compute, ground digital twin and autonomy, all satellites prepared for servicing, ISAM (in-space assembly and maintenance) and precision robotic manipulation.- Enabling Technologies: Standard fluid, docking, power, data, and thermal interfaces, power, propulsion, and payload components (valves, tanks, etc.), optical comms (gimbal-less) or robo-taxis with edge compute, gauges, metering, and active sensing such as light detection and ranging (LiDAR), fault-tolerant, autonomous RPO, multi-degree-of-freedom robotic arms and servicing depots, with a "second set of eyes" software for space domain awareness (SDA)/RPO.Logistics Health MonitoringHealth monitoring provides predictive insight for sustainment. Satellites must report their health status, depots must track inventory, and OTVs must monitor their systems. A logistics enterprise requires digital twins, autonomous anomaly detection, and fleet level dashboards that provide real time visibility.D2P2 prototypes must demonstrate sensors, edge computing, digital twins, anomaly detection, and fleet level dashboards. The prototype must show how health data informs logistics planning and supports autonomous decision making. The performer must demonstrate how the system maintains accuracy and reliability during health monitoring operations.- Desired Capabilities: Environmentally controlled warehousing and hosting, rapid, autonomous decision support, including predictive tools for long-term planning and fault onset, communication and data sharing from stored goods, with onboard health monitoring, balancing or cross-distribution of supplies, and robotic manipulation and inspection, modular reconstitution and cross-domain autonomy, decision-making systems that account for commercial vs. government ownership, with clear delegation of authority across ground, space, or hybrid systems.- Enabling Technologies: Novel materials for monitorable components, advanced analytics, AI, and digital twin technology for health monitoring, data fusion across sensor data, maintenance logs, and digital twins, with serialized pedigree and historical tracking, data norms and standardization for interoperability, docking and capture mechanisms that don't require high precision, or "ejection seat" designs for modular, self-monitoring components, decentralized or cross-vendor data sharing and servicing modularity, user interfaces for human or autonomous decision-making, supported by advanced modeling and simulation.

Phase III will transition the technology to operational use. Expected activities include: - TRL maturation to operational readiness - Commercial adoption across GEO, LEO, and cislunar markets - Government approvals and certifications - Integration with Space Force logistics enterprise - Transition planning and stakeholder engagement - Identification of additional Department of the Air Force customers The performer must demonstrate how the technology supports long term sustainment and commercial viability.

A prior answer states that D2P2 work must be distinctly separate from previous SBIR/STTR work. DARPA's Orbital Express (flown 2007) produced publicly released design literature and lessons learned, some of which trace to SBIR awards made to a different firm over twenty years ago. If an offeror develops a new docking and utility interface informed by that public literature and by personnel with experience on those programs, without using the prior awardee's hardware, data, or SBIR-funded IP, does that satisfy the "distinctly separate" requirement? Would evaluators view flight-demonstrated design lessons as risk reduction or as a novelty concern? 

1 - The Government is not able to make prospective determination on this "distinctly separate" requirement, however the nature of the work described sounds like it could satisfy this requirement. SBCs cannot use work in previous SBIRs or STTRs to justify that they are ready to receive a Direct to Phase II contract award. D2P2 awards are only given to SBCs that have developed novel effort and that is distinctly separate from previous SBIR/STTR work.  If proposers can satisfy this requirement, the Government is likely to make a positive determination on this "distinctly separate" requirement. 2 - If there is a mitigation plan which will be implemented during the contract or in follow on efforts, then it is risk reduction. If there is no mitigation, then the government considered it an inherit risk of the technology even if the company considers it a lesson learned.  

DISCONNECTED / DEGRADED OPERATIONSFor autonomous logistics operations conducted with intermittent or unavailable connectivity to ground or enterprise systems, should a prototype demonstrate continued operation under locally available authority, policy, mission state, and logistics data, followed by reconciliation of decisions, actions, evidence, and state changes when connectivity is restored?

Yes, this is a mitigation for possible comms loss actively during a logistics mission. 

AUTHORITY TRANSFER AND AUTONOMOUS EXECUTIONFor a Systems-of-Systems solution coordinating government and commercial logistics assets across ground, space, and hybrid operations, may the prototype explicitly represent and enforce which organization, operator, or autonomous system currently holds authority to direct a particular asset or logistics action, including temporary delegation or transfer of that authority? If authority changes during an operation, should the system preserve the prior authority state, effective time, resulting decisions/actions, and transfer history as part of the auditable mission record?

If system-of-systems current or future efforts are commercially owned and commercially operated to service a government asset, then the Government likely has spacecraft authority (SCA) for any servicing/logistic action and veto right when the system-of-system can service the government asset. Authority/SCA likely will remain within the Government customer Space Program Office. Government veto right to abort/pause action should be allowable at all times of logistics mission. If authority does change, then the system likely shouldn’t preserve previous authority, decisions/actions. 

The Phase II section states that D2P2 prototypes "must demonstrate" specified capabilities within each focus area. For a 12-month effort, is a terrestrial hardware-in-the-loop demonstration using flight-representative software and a representative coupling interface an acceptable form of prototype demonstration, or is a flight-qualified or on-orbit demonstration expected?

An orbital flight demonstration or full space-qualification is not required for award or completion under this 12-month Direct-to-Phase-II effort. A terrestrial hardware-in-the-loop demonstration using flight-representative software and a representative coupling interface is an acceptable form of prototype demonstration.

The Phase I Equivalent Work Requirements state that the performer "must show that they have engaged with Space Force operators, program offices, mission owners, or acquisition stakeholders" and has "a clear customer within the US Space Force." For a small business without an existing Space Force relationship, what forms of engagement satisfy this element — for example, participation in the AFWERX On-Orbit Space Logistics Challenge cited in Reference 2, or documented correspondence with the Space Access program office identified in the Propellant Management focus area — and what documentation of that engagement is expected in the D2P2 submission?

The Government is not able to make prospective feasibility determinations, however the nature of the work described sounds like it could meet the feasibility requirement. The feasibility standards for the topic are outlined in the Phase I field description in the topic, so provided that applicants can meet those requirements, the Government is likely to make a positive feasibility determination. For documentation of that engagement, other than the guidance already provided, SpaceWERX cannot advise SBCs on what to include in their proposal submission package. 

The Volume 3 cost volume in DSIP presents two budget periods, a Base period and a Year 2. DAF26BX06-DV513 states a maximum period of performance of 12 months. A 12-month period of performance beginning after October 1 crosses the federal fiscal year boundary, which appears to generate the second period.For a proposal with a single 12-month period of performance, should the Year 2 period be entered as zeros, or should the 12-month budget be split across the two periods by fiscal year? The cost volume will not validate as complete with the Year 2 fields left blank.

The recommended guidance is to complete the budget based off of the 12-month Period of Performance. For Year 2, enter in zeros and the cost volume should validate as complete. If there are any issues with this, submit a follow-up question before October 7th. 

Are Phase II kickoff and program reviews conducted in person or virtually, and if in person, at what location?

Phase II kickoff and contract deliverables occur virtually.

Where are the OOSL Challenge Definition Workshop (CDW) outputs and Design Reference Missions (DRMs) located? 

These resources can be located on the OOSL Challenge website: https://afwerxchallenge.com/on-orbit (Reference #2). Navigate to this website and select the "Specifications" subtab underneath the title "On-Orbit Space Logistics Challenge." Near the bottom of this page, there is a note and a hyperlink titled, "This Challenge Definition Workshop Deck." Select this link and these resources will open in another tab. 

Autonomy and safe recovery. What operator-authority, human-intervention, safe-state, interruption, and recovery requirements should govern the servicing function, and what evidence will be expected to show that faults are detected and handled without unacceptable risk to the client asset?Performance measures. Which measures of task completion, repeatability, resource consumption, interface performance, and required operator intervention will determine success, and are reference baselines or acceptance thresholds available for the proposed function?Environmental and integration maturity. What maturity is required at award completion regarding radiation, thermal and vacuum conditions, vibration, onboard computing, and software integration, and which qualifications may be deferred to a subsequent transition effort?Customer and resource commitments. What stakeholder engagement, customer support, and partner-interface commitments should be established before submission, and will the government facilitate access to a representative client platform or must all integration resources be secured by the proposer?Qualifying feasibility evidence. Could the contracting office clarify the evidence needed to establish applicant or principal-investigator performance, funding provenance, and technology rights, particularly where independently funded results use facilities or background technology also associated with prior Small Business Innovation Research or Small Business Technology Transfer projects?

The topic discusses autonomous capability across key logistics functions such as refueling, repair, resupply, and rendezvous and proximity operations (RPO). The solicitation does not mandate a single rigid operator-authority model or standardized safe-state architecture.  SBCs are expected to define their proposed command and control architecture, including human-in-the-loop or human-on-the-loop authorities, fault detection, isolation, and recovery (FDIR) protocols, and dynamic interruption handling in Volume 2 (Technical Volume). To demonstrate that faults are handled without unacceptable risk to a client asset, SBCs should present evidence derived from simulation, digital twin modeling, or hardware-in-the-loop testing.The Government has not established universal reference baselines or fixed acceptance thresholds in the topic description. SBCs may structure their proposal under either a Systems of Systems Approach or a Logistics Function Approach, you must define, quantify, and justify your own performance metrics and success criteria based on your proposed concept.Full environmental space qualification (such as final radiation hardening or comprehensive thermal-vacuum and vibration flight certification) is not strictly mandated to be completed at Phase II conclusion unless included in your proposed scope.The topic does not guarantee or commit the Government to providing a representative client platform, on-orbit asset, or Government Furnished Equipment (GFE). SBCs are expected to secure all integration resources, testbeds, hardware interfaces, and simulation tools required to execute the Phase II prototype demonstration unless a formal government commitment is established and documented within the proposal.SBCs cannot use work in previous SBIRs or STTRs to justify that they are ready to receive a Direct to Phase II contract award. D2P2 awards are only given to SBCs that have developed novel effort and that is distinctly separate from previous SBIR/STTR work.

Accepted product boundary. Would a focused autonomy, robotic servicing, or health-monitoring subsystem addressing one logistics function be responsive, and what minimum end-to-end logistics outcome must such a subsystem demonstrate within the 12-month effort?Priority servicing use case. Which client asset and servicing task would provide the most useful initial demonstration, and would inspection with an actionable maintenance assessment be sufficient, or is physical intervention such as manipulation or component replacement required?Client interfaces. What representative mechanical, electrical, data, sensing, and operational interfaces can be provided or designated for the client asset, and which interface standards or existing partner platforms should guide the proposed architecture?Ground versus orbital demonstration. Is a ground demonstration using representative robotic hardware and validated simulation sufficient for this award, or is an orbital demonstration required, and what evidence must establish the relevance of the selected test environment?Sensing and orbital applicability. What relative-state information and onboard sensing may the servicing function assume, and can applicability across orbital regimes be established through analysis and simulation, or must multiple environments be physically demonstrated?

A proposal focused on a single logistics function (such as focused autonomy, robotic servicing, or health monitoring) is responsive. The topic permits offerors to use a "Logistics Function Approach," which concentrates on a discrete activity rather than requiring an entire enterprise system-of-systems. Within the 12-month effort, the SBC demonstrates the proposed prototype within the chosen technical focus area.The topic does not specify a single mandatory client asset or priority servicing task. SBCs identify the use case that best aligns with their technical capabilities, integration pathway, and targeted operational challenge. Inspection and health monitoring with actionable maintenance assessments are acceptable and directly align with the Logistics Health Monitoring focus area. Physical intervention (such as robotic manipulation or component replacement) would be based on the technical solution being proposed.The topic does not designate or provide a standardized government client asset or mandatory physical interface for this solicitation. SBCs must define their interface strategy within the proposal, identifying whether they utilize existing commercial interfaces, conform to emerging government or industry standards, or propose a modular interface approach. The architecture should emphasize interoperability and modularity to prevent single-source dependence or reliance on a unique, proprietary interface.An orbital flight demonstration is not required for award under this 12-month Direct-to-Phase-II effort. A ground-based demonstration using representative hardware, digital twins, or high-fidelity modeling and simulation is sufficient. SBCs must establish the relevance of their test environment by documenting how their test setup, hardware-in-the-loop, or simulation models accurately reflect space environmental factors, contact dynamics, dynamic constraints, and relevant orbital mechanics.SBCs may state reasonable baseline assumptions regarding onboard sensing capabilities that support their specific technical concept. Physical testing across multiple orbital regimes is not required during Phase II.

Do figures, tables and their captions count toward the 15-page technical volume limit, and does the 10-point minimum type size requirement apply to text inside figures?

Yes, figures, tables and captions count toward the 15-page technical volume limit. Less important graphics can be submitted in Volume V - Supporting Documents. Text inside figures should adhere to the 10-point minimum type size requirement. 

If we use the Systems of Systems approach, can our technology provide the hosting and deployment capability while other providers supply the individual logistics payloads?

Yes, SBC’s proposed technology can provide the hosting and deployment capability while relying on other providers to supply individual logistics payloads. 

For the requirements listed under Orbital Warehousing, do you expect a solution to address all of them, or only those that apply to the proposed architecture?

SBCs are not required to address all of the desired capabilities listed under the Orbital Warehousing focus area. Proposals must address at least one technical focus area and should concentrate specifically on the requirements, capabilities, and enabling technologies that apply to the proposed architecture.

For Orbital Warehousing, are you open to a distributed approach with smaller storage/distribution nodes, or are you primarily looking for a larger, centralized depot?

The topic is open to distributed approaches using smaller storage and distribution nodes as well as centralized depot architectures.  

A prior answer states that offerors should adopt existing or emerging standards, or introduce a new interface approach where required. Where the principal Phase II deliverable includes an interface specification whose value to the Government depends on being adoptable by third-party vehicle and payload providers, how does the Government prefer that offerors treat SBIR data rights in the specification? Is an offeror expected to assert SBIR data rights in the specification, to offer it under Government Purpose Rights, or to propose a release path that supports broader adoption?

Offerors are not "expected" to assert data rights, the decision of whether to assert data rights relies on the sound business judgment of the offerors. Note that all data/software generated under the contract will receive SBIR/STTR data rights protections, so as a matter of practice it is often unnecessary for awardees to assert data/software was previously developed under a different contract or at private expense, it may be appropriate and expected for awardees to assert data rights for that data/software. 

A capability that receives cargo from a delivery vehicle and secures it at a storage location touches both Orbital Warehousing, which lists space pallets and standards for space operations and interfaces among its enabling technologies, and Network Mechanics, which addresses standardized connectors and docking operations. Does the Government have a preferred focus-area assignment for the interface itself, and is an offeror advantaged, disadvantaged, or neutral in evaluation by declaring one primary focus area with a named secondary rather than a single focus area?

Proposals are required to address at least one technical focus area, and SBCs should select the focus area and architectural framework that best align with their proposed solution. An proposal is neutral in evaluation whether declaring a single focus area or a primary focus area with a named secondary focus area.

A prior answer states that documented engagement with Department of the Air Force or U.S. Space Force organizations concerning the underlying technology and mission need satisfies the stakeholder engagement requirement. Does a submission to the Space Systems Command Front Door portal, together with the Government's acknowledgment of receipt, constitute documented engagement for this purpose? If not, what additional evidence of a two-way exchange does the Government expect an offeror to produce?

The Government is not able to make prospective feasibility determinations, however the nature of the work described sounds like it could meet the feasibility requirement. The feasibility standards for the topic are outlined in the Phase I field description in the topic, so provided that applicants can meet those requirements, the Government is likely to make a positive feasibility determination.

Prior answers list production use, operational demonstrations, prototype demonstrations, test results, system integrations, software metrics, and representative mission scenarios as acceptable evidence of completed Phase I-equivalent work. Does architecture and feasibility work performed for, and recognized by award in a NASA prize competition qualify as documented Phase I-equivalent work? Such work is Government-recognized but was not performed under a Government contract and is therefore not prior federally funded SBIR/STTR work.

The Government is not able to make prospective feasibility determinations, however the nature of the work described sounds like it could meet the feasibility requirement. The feasibility standards for the topic are outlined in the Phase I field description in the topic, so provided that applicants can meet those requirements, the Government is likely to make a positive feasibility determination. 

Prior answers state that technologies are generally expected to be at approximately TRL 4-5 at project start. For a proposed capability whose constituent subsystems individually carry high flight heritage (for example robotic manipulation, clamp-band and tension-member restraint mechanics, and non-cooperative grasping demonstrated on ISS) but whose integration into the proposed autonomous function has no prior on-orbit application, at what level does the Government assess entry TRL: the integrated system, or the constituent subsystems and unit operations? Where an offeror's own feasibility work honestly rates the integrated function below TRL 4 while identifying the flight-proven subsystems it is assembled from, is that transparency preferred to a system-level TRL claim?

Transparent disclosure of an integrated system's current readiness state is preferred.

Questions  For a software-centric Logistics Health Monitoring solution, what would the Government consider the strongest Phase II demonstration? Would a high-fidelity simulation or digital twin demonstrating multiple spacecraft, faults, servicing assets, and autonomous logistics decisions be sufficient, or would hardware-in-the-loop or integration with an existing spacecraft platform be particularly advantageous?What quantitative metrics would the Government consider most important when evaluating a Logistics Health Monitoring prototype? Examples could include anomaly-detection accuracy, fault-prediction horizon, false-alarm rate, decision latency, mission availability, reduction in downtime, reduction in unnecessary servicing, improved asset utilization, or increased mission endurance.Are there particular spacecraft telemetry formats, command-and-control architectures, digital engineering environments, Space Domain Awareness systems, or logistics systems that the Government recommends proposers use as reference architectures when defining the Phase II integration pathway?For AI-based health monitoring and logistics decision support, how important is explainability to the operator? Should Phase II demonstrate that the system can provide the evidence, telemetry, confidence level, and reasoning behind an anomaly diagnosis or recommended logistics action?For a Logistics Health Monitoring proposal, would the Government prefer that offerors identify one specific spacecraft program or mission as the initial transition use case, or is it acceptable to propose a platform-agnostic architecture designed to support multiple Space Force spacecraft, depots, and orbital transfer vehicles?How many Phase I awards does the Government anticipate making under this topic, and how many follow-on Phase II awards are expected?

1.    The government will evaluate the SBCs proposed technical solution.  2.    SBCs proposals are expected to define, propose, and justify their own quantitative Key Performance Parameters (KPPs) based on their proposed technical solution.3.    The Government has not specified mandatory reference telemetry formats, command-and-control (C2) architectures, or digital engineering environments for this topic.4.    The topic highlights the need for user interfaces that support human or autonomous decision-making, rapid autonomous decision support, and clear delegation of authority across ground, space, or hybrid systems.5.    The government does not have a preference.  6.    This topic is a Direct-to-Phase-II effort so zero Phase I awards will be made. For Phase II awards, funding decisions are based on available budget and the technical merit of received proposals. With that being said, the general target in terms of number of awards for this topic will be around 20. 

Please find below our questions regarding DAF26BX06-DV513: Autonomous On-Orbit Logistics and Sustainment Architecture.  Within the Logistics Health Monitoring focus area, which capabilities are currently the highest priority for the Government: spacecraft anomaly detection, predictive maintenance, remaining-useful-life estimation, fleet-level health monitoring, logistics readiness assessment, or autonomous sustainment decision support?Would a proposal centered on autonomous spacecraft health monitoring, anomaly detection, fault prediction, and logistics decision support be considered sufficiently responsive as the primary Phase II capability, provided that the proposal clearly demonstrates how spacecraft health information drives sustainment actions such as repair, replacement, refueling, repositioning, or reconstitution?For a company with NASA-funded experience developing spacecraft health monitoring and anomaly-detection technologies, what documentation would be most valuable for demonstrating Phase I-equivalent maturity? For example, would Government-funded prototype results, telemetry analyses, simulation results, technical publications, customer validation, or demonstrations using representative spacecraft data be particularly valuable?How far does the Government expect the Phase II prototype to progress from detecting spacecraft anomalies to recommending or autonomously initiating logistics actions? For example, should the system only identify and characterize a fault, or should it also determine whether the appropriate response is servicing, component replacement, refueling, repositioning, recovery, or reconstitution?Would the Government value a fleet-level digital twin that combines spacecraft health, mission status, maintenance history, logistics assets, available servicing vehicles, inventory, and operational constraints to predict sustainment needs and recommend logistics actions across multiple spacecraft?

1.    The Government has not established a specific internal hierarchy or sub-ranking among the capabilities listed under the Logistics Health Monitoring focus area.2.    Yes, it would be considered responsive.3.    Yes, it would be valuable.4.    The government will evaluate the SBCs proposed technical solution.  5.    The topic write-up highlights digital twin technology, fleet-level dashboards, and multi-source data fusion as key enabling technologies. Developing a digital twin to predict sustainment needs and recommend logistics actions across multiple spacecraft fits within this topic. 

 1. Is there a preferred RTOS?2.  Is the use of NASA cFS or F-prime required or preferred?

1. The topic does not mandate or state a preference for any specific Real-Time Operating System (RTOS). SBCs have the flexibility to select and justify an RTOS that best suits their technical approach, processing requirements, and hardware integration needs.2. The use of NASA Core Flight System (cFS) or F-prime is neither required nor stated as a preference in this topic. SBCs may utilize cFS, F-prime, or another proprietary/open-source software baseline, provided the technical proposal demonstrates how the selection supports the required autonomous capabilities, system performance, and integration pathway.

The Network Mechanics section states that prototypes “must demonstrate standardized connectors, docking operations, autonomous rendezvous safety protocols, interface modularity, and advanced orbital mechanics.” For a proposal focused on a specific enabling subcomponent within Network Mechanics, is it acceptable to scope the prototype to that subcomponent without addressing every listed capability (such as standardized connectors or docking operations), so long as the proposal clearly defines its scope and explains how it contributes to the broader Network Mechanics architecture?

Every subsystem does not need to support every one of the attributes listed under the Network Mechanics focus area. Proposals focused on a specific enabling subcomponent are acceptable provided the SBCs clearly defines the technical scope of the effort and demonstrates how the subcomponent remains compatible with system-level approaches. 

1.Does “logistics health monitoring” include structural integrity awareness and impact detection for spacecraft, depots, and OTVs?  2. Is autonomous onboard damage assessment (such as MMOD/HVI localization) considered in scope for logistics health monitoring, or is the focus limited to traditional engineering telemetry?  3. Is a modular hosted‑payload format desirable so the same health‑monitoring subsystem can integrate across depots, OTVs, and client spacecraft?  4. Do autonomous servicing and refueling operations require pre‑servicing structural checks (for example impact damage, leaks, or TPS condition) to ensure safe RPOD and ISAM workflows? 5. Should logistics health systems support fleet‑level sustainment dashboards across multiple orbits, or is the priority per‑vehicle autonomy only? 6. Are the "sensor fusion algorithms" assumed to be running within a SMP RTOS environment such that, for example, for a quad-core device, the algorithms, would be broken up into 3-4 RTOS tasks and scheduled across the cores?  Or is it assume a fully bare-metal environment where the multi-core processor is essentially a co-processor with its only job of sensor fusion?

1. Yes, "logistics health monitoring" includes structural integrity awareness and impact detection for spacecraft, depots, and Orbital Transfer Vehicles (OTVs), provided the proposed capability directly supports on-orbit sustainment and logistics decision-making.  2. Yes, autonomous onboard damage assessment, including MMOD or HVI localization, is considered within scope for topic. 3. A modular hosted-payload format for the health-monitoring subsystem is considered a desirable feature.  However, SBCs have the flexibility to propose alternative subsystem architectures or integration methods.4. While ongoing, real-time fault detection, isolation, and recovery (FDIR) checks align with the desired capabilities for persistent fleet awareness, offerors may propose any technical approach that satisfies the operational requirements.5. Supporting fleet-level sustainment dashboards across multiple orbits is a desirable capability for the overall architecture, but it is not mandatory. 6. SBCs may propose and justify their chosen software architecture, task scheduling, and compute framework in Volume 2 (Technical Volume).

Is the CMMC Level 2 self-assessment and its SPRS score expected at proposal submission, or at award?

The CMMC Level 2 self-assessment and its SPRS score are required by contract award.

The topic is ITAR restricted. Is DD Form 2345 expected with the proposal, or does evidence of an application in progress suffice?

Evidence of a DD2345 application in progress usually suffices for the initial proposal submission. However, the DAF encourages small businesses to begin this process as quickly as possible because this process will delay award if it is not completed in a timely manner.

Is the expectation that there will be multiple awards for this topic?

Funding decisions are based on available budget and the technical merit of received proposals. With that being said, the general target in terms of number of awards for this topic will be around 20. 

The topic Objective states that Phase I equivalent work "includes feasibility studies, stakeholder engagement, technical validation, and early integration planning." The Phase I Equivalent Work Requirements section then enumerates six required elements: Stakeholder Engagement, Feasibility Study, Integration Pathway, Regulatory Considerations, Commercial Dual Use Potential, and Phase II Prototype Plan. "Technical validation" does not appear among the six enumerated elements. Is technical validation intended to be addressed within the Feasibility Study element, or does the Government expect it documented and evaluated as a separate element?

SBCs should provide documentation demonstrating completion of Phase I equivalent work. Specifically, the Feasibility Study should demonstrate technical merit, operational relevance and mission fit.  D2P2 proposals require a comprehensive, detailed effort description.  Proposals should demonstrate sufficient technical progress or problem-solving results to warrant more extensive RDT&E.  Please refer to the DAF SBIR 26BC D2P2 Release 6 Proposal submission instructions for Supporting Documents Volume (Volume 5). While no specific TRL threshold is prescribed, the Government anticipates technologies sufficiently mature to support prototype development during the Direct-to-Phase-II effort.

As this topic covers the entire space logistics lifecyle, will proposals for end-of-service be considered as part of the lifecycle? Specifically, can we submit proposals for deorbiting satellites, spacecraft, and launch vehicles? Integrated deorbit capability is being phased in as requirement for new orbital assets, ensuring safe removal from orbit of decommissioned satellites, booster vehicles, and other potentially hazardous space debris. Deorbit is necessary to open orbital slots for new space assets and reduce the chance of orbital collisions creating dangerous space debris fields that could damage or destroy US and allied space assets, as well as endanger astronauts.

SBC proposals for end-of-service capabilities are within the scope. SBC proposing deorbit capabilities should align their technical approach with at least one defined focus area, utilize either the Systems of Systems or Logistics Function architectural framework.

Is there a website for this Challenge topic? 

Yes and the URL is: https://afwerxchallenge.com/on-orbit. 

Are we limited to one proposal, or can we submit two? 

DSIP will NOT restrict multiple submissions from an SBC for this solicitation. 

PHASE-I-EQUIVALENT VALIDATION EVIDENCEFor software-centric technologies, what evidence does the Government consider sufficient to demonstrate the required prior technical validation—production use, operational demonstrations, prototype demonstrations, test results, system integrations, software metrics, representative mission scenarios, or other documented evidence of technical feasibility?

The Government considers production use, operational demonstrations, prototype demonstrations, test results, system integrations, software metrics, representative mission scenarios, or other documented evidence of technical feasibility as sufficient to show the required prior Phase I-equivalent technical feasibility. SBCs should ensure this documentation clearly establishes that the foundational scientific and technical merit has already been achieved.  SBCs should demonstrate completion of Phase I-equivalent work and provide evidence that the proposed technology is sufficiently mature to support prototype development during the 12-month Phase II effort. While no minimum TRL is prescribed in the specific topic, technologies are generally expected to be at approximately TRL 4-5 at project start and advance toward TRL 6 or higher by the conclusion of Phase II.

TRANSITION / INTEGRATION TARGETFor proposals using the Systems-of-Systems framework and focusing on Logistics Health Monitoring or Network Mechanics, is there a preferred Space Force program office, PAE, operational organization, test environment, or logistics architecture that offerors should treat as the intended Phase II integration and Phase III transition target?

The Government does not prescribe a single mandatory Space Force program office, Program Area Executive, operational organization, test environment, or logistics architecture as the Phase II integration or Phase III transition target for Systems-of-Systems proposals focused on Logistics Health Monitoring or Network Mechanics. Although Space Access PAE and Space Systems Command, Directorate of Installations, Logistics and Product Support sponsor the topic, proposers should themselves identify, engage, and document relevant U.S. Space Force stakeholders to establish customer alignment and product-mission fit within their Phase I-equivalent feasibility work. Transition plans should be grounded in the sustainment principles of Space Doctrine Publication 4-0 while remaining free to propose the specific organization that best aligns with the offered solution.

INTEROPERABILITY / STANDARDSAre there specific Space Force, DoD, commercial-space, CCSDS, servicing, logistics, data-exchange, digital-engineering, or command-and-control standards/interfaces that the Government expects software-centric Systems-of-Systems solutions to support during Phase II?

The Government expects offerors to identify, justify, and adopt existing or emerging commercial and government standards suited to their proposed architecture. Within the proposal, for example SBCs should clearly define their integration pathway, detailing how their software-centric solution handles data normalization, interoperability, autonomous decision-making, and command-and-control integration. Proposals should address whether the solution conforms to existing standards, aligns with emerging industry or government frameworks, or introduces a new interface approach required to execute on-orbit logistics operations.

AUTONOMY AND HUMAN AUTHORITYThe topic emphasizes autonomous logistics operations and decision-making. For software-centric solutions, what decisions or actions does the Government expect to be performed autonomously during Phase II, and which decisions should remain subject to human authorization? Is human-on-the-loop or human-in-the-loop orchestration acceptable where operational authority or mission risk requires human approval?

The Government expects Phase II prototypes to demonstrate autonomous execution for routine tactical functions such as rendezvous and proximity operations, collision avoidance, fueling safety sequencing, inventory tracking, and fault diagnosis as an example. The solicitation does not require un-cleared autonomy across every operational decision, nor does it restrict human oversight. Decision-making architectures incorporating clear delegation of authority across ground, space, or hybrid systems with user interfaces tailored for both human and autonomous control are within scope. Human-in-the-loop and human-on-the-loop orchestration models are appropriate where operational authority, mission risk, or multi-owner asset governance demands explicit human authorization. SBCs should clearly define their proposed allocation of autonomous functionality versus human approval gates to demonstrate operational safety and mission assurance.

GOVERNMENT-FURNISHED / REPRESENTATIVE DATAWill the Government provide representative mission scenarios, logistics data, spacecraft/depot models, interfaces, operational constraints, or other Government-furnished information for Phase II prototype integration and evaluation? If not, may offerors use public, commercial, synthetic, or contractor-developed representative data and digital models?

The Government does not intend to provide nor guarantee Government-Furnished Information, representative mission scenarios, logistics data, or spacecraft/depot models. SBCs may and are encouraged to use public, commercial, synthetic, or contractor-developed representative data, digital models, and simulation environments to perform Phase II prototype integration and evaluation where appropriate based on their proposal submission.  

NETWORK MECHANICS SCOPEFor the Network Mechanics focus area, does the Government consider orchestration of information, logistics relationships, routing, asset availability, ownership/authority, interoperability, and cross-system decision support to be within scope, or is Network Mechanics intended primarily to address physical docking interfaces, orbital mechanics, rendezvous/proximity operations, and spacecraft-to-spacecraft interaction?

The Government considers both physical interaction interfaces and software or informational orchestration to be within the scope of the Network Mechanics focus area. The topic description defines Network Mechanics as encompassing physical interfaces, connectors, and orbital dynamics, as well as operational standards, coordination mechanisms, functional network nodes, routing autonomy, and decision-support capabilities required to manage multi-asset space logistics.  

LOGISTICS HEALTH MONITORING SCOPEFor the Logistics Health Monitoring focus area, may the proposed capability monitor and reason over the health and readiness of the broader logistics enterprise—including vehicles, depots, cargo, servicing assets, dependencies, maintenance history, supply status, mission availability, and operational risk—or is the Government primarily seeking component- or spacecraft-level sensor health monitoring?

The Government seeks solutions that encompass either enterprise-level logistics health monitoring and component- or spacecraft-level sensor health monitoring. Proposal scope is not restricted to component-level sensor monitoring. Capabilities that monitor, fuse, and reason over the health, readiness, and operational risk of the broader logistics enterprise (including vehicles, depots, cargo, maintenance logs, and supply status, for example) are within scope. Offerors may utilize either a Systems of Systems approach to address multi-node enterprise interactions or a Logistics Function approach to focus on specific functional capabilities, provided the proposal clearly demonstrates how the technology informs logistics planning and integrates into Space Force sustainment operations.  

MULTI-ORBIT REQUIREMENTDoes Phase II need to demonstrate operation across LEO, MEO, GEO, and cislunar regimes, or may an offeror demonstrate the architecture in one or more representative orbital regimes while showing through modeling, interfaces, and architecture analysis how the capability extends to the others?

A SBC is not required to physically demonstrate technology operations in every orbital regime (LEO, MEO, GEO, and cislunar) during Phase II. An offeror may demonstrate their prototype solution in one or more representative orbital or ground-based testing environments.  

PHASE II DEMONSTRATION ENVIRONMENTMay the required Phase II prototype and operationally relevant demonstration be performed using a high-fidelity digital, simulation, modeling, hardware-in-the-loop, or representative ground-based environment, or is an actual on-orbit demonstration expected during the 12-month Phase II period?

An actual on-orbit demonstration is not required during the 12-month Direct-to-Phase-II performance period for this topic. Due to the 12-month execution schedule and $1,000,000.00 funding ceiling, offerors are expected to validate their prototype-ready technologies in representative ground-based environments, high-fidelity digital simulations, digital twins, or hardware-in-the-loop testbeds, as an example.  Such demonstrations are generally expected to support maturation from approximately TRL 4-5 at project initiation toward TRL 6 or higher by the end of the Phase II effort.

SOFTWARE / ARCHITECTURE-ONLY SOLUTIONSMay a software-centric architecture addressing enterprise logistics coordination, Logistics Health Monitoring, Network Mechanics, or autonomous decision support satisfy DV513 without proposing development of spacecraft hardware, propellant-transfer hardware, robotic servicing equipment, or another physical on-orbit subsystem?

A software-centric architecture focused on enterprise logistics coordination, Logistics Health Monitoring, Network Mechanics, or autonomous decision support is acceptable and does not necessarily require concurrent development of spacecraft hardware, propellant-transfer hardware, robotic servicing equipment, or any other physical on-orbit subsystem, however it is based on the SBC proposed solution to the topic, the technical focus area(s), and enabling technologies that are being addressed by the SBC's proposal. SBC proposals should still address at least one of the six listed focus areas and should demonstrate Phase I-equivalent feasibility, product-mission fit, and a viable Phase II prototype path. 

SPACE FORCE STAKEHOLDER ENGAGEMENT REQUIREMENTThe Phase-I-equivalent requirements call for documented stakeholder engagement and a clear Space Force customer. What level of prior engagement is required to satisfy this criterion? Must the offeror demonstrate direct engagement with the specific sponsoring organization or intended transition customer for DV513, or may documented engagement with other Department of the Air Force or U.S. Space Force organizations concerning the underlying technology and mission need satisfy the requirement?

Documented engagement with other Department of the Air Force or U.S. Space Force organizations concerning the underlying technology and mission need would satisfy this requirement. 

PHASE-I-EQUIVALENT MATURITY — MISSION-SPECIFICITYFor Direct-to-Phase-II eligibility, must the completed Phase-I-equivalent work have specifically demonstrated the proposed capability in an on-orbit logistics or Space Force sustainment application, or may an offeror establish equivalency through a mature, previously developed commercial/government architecture whose core capabilities—such as multi-node logistics coordination, system health monitoring, dependency management, decision support, provenance, and autonomous workflow—have already been demonstrated, with orbital-logistics adaptation and integration occurring during Phase II?

SBCs are not required to have previously demonstrated their proposed capability in an on-orbit or Space Force sustainment environment.  SBCs should demonstrate completion of Phase I-equivalent work and provide evidence that the proposed technology is sufficiently mature to support prototype development during the 12-month Phase II effort. While no minimum TRL is prescribed in the specific topic, technologies are generally expected to be at approximately TRL 4-5 at project start and advance toward TRL 6 or higher by the conclusion of Phase II.

SpaceWERX, in partnership with Space Systems Command's Space Sensing System Delta 84 and the OPIR Tap Lab, are seeking innovative solutions supporting the next generation of missile detection, warning, tracking, and reporting. The objective of this SBIR Phase I effort is to evaluate the feasibility of applying innovative data processing techniques including the use of Artificial Intelligence and Machine Learning (AI/ML) methodologies to address the evolving challenges in missile detection, warning, tracking, and reporting. The primary goal of this research and development initiative is to advance data fusion, sensor integration, and real-time processing methods that enhance the accuracy, responsiveness, and reliability of satellite-based missile warning systems. This includes addressing the data interoperability from multi-orbit (GEO, MEO, LEO) satellite constellations, optimizing on-orbit and ground-based processing frameworks, and improving data quality from diverse sensing modalities from legacy and future Overhead Persistent Infrared (OPIR) space architectures. Specifically, this effort will focus on researching and developing state-of-the-art algorithms and processing techniques that support rapid and precise multi-sensor fusion, robust target identification, and accurate real-time 3D tracking of traditional, hypersonic, and maneuverable missile threats. By leveraging novel techniques in data association, sensor fusion, and edge processing, the solution will aim to mitigate limitations presented by diverse sensor resolutions, data cadences, and observational geometries. The project will also investigate methods to increase computational efficiency for onboard satellite processing and consider robustness against noise in highly dynamic operational environments.

The purpose of this topic is to address a critical need within the U.S. Space Force’s Missile Warning, Tracking, and Response mission by advancing the application of artificial intelligence (AI) and machine learning (ML) technologies to improve multi-sensor fusion, missile tracking precision, and real-time situational awareness within a multi-orbit satellite framework (GEO, MEO, and LEO). Current technologies face challenges in fusing large volumes of disparate data across multiple sensing modalities, tackling latency in data processing, and accurately tracking increasingly sophisticated threats such as hypersonic and maneuverable missile systems. This effort seeks to develop and validate advanced data processing techniques including AI/ML solutions for both ground-based and satellite-based multisensor fusion capable of real-time processing for advanced OPIR Missile Detection, Warning, Tracking, and Reporting. These solutions will enable enhanced detection, tracking, and reporting of advanced missile threats by leveraging novel algorithms for target identification, data association, and real-time 3D tracking across multi-orbit platforms. Initial solutions should target feasibility studies and technical proof-of-concept demonstrations with the goal to transition the capability into the OPIR Tap Lab or similar testbed to build and test solutions in an operationally relevant environment. The advancements made on this effort have the potential to significantly contribute to the Space Force’s mission of persistent global surveillance, improved defensive decision-making, and sustained space superiority.

Phase I will assess the feasibility of AI/ML-driven multi-sensor fusion techniques for real-time advanced missile detection, warning, and tracking across multi-orbit satellite systems and data architectures. The desired future state of this effort is a network-aware, autonomous constellation (spanning multiple orbital regimes) where ground "migrates" with space via edge fusion that compresses timelines for joint fight without loss of quality or confidence. The goal of this Phase I effort is to onboard and coordinate emergent solutions into the OPIR TAP lab and create a shared understanding of the problem set of the Missile Warning and Tracking (MWT) mission area. Successful Phase I efforts from this topic will target capability testing within the OPIR Tap Lab with the goal of advancing capability and de-risking follow-on capability development in subsequent phases. Proposed solutions should include a feasibility study and algorithm prototypes or simulation results as applicable as well as a clear path to integration and testing within the OPIR Tap Lab. Focused topic areas can include any part of the following: - Edge Fusion & Autonomy: AI/ML solutions for on-orbit track fusion, autonomous constellation tasking, and event-driven scheduling across proliferated MEO/LEO architectures in contested environments. - Multi-Source Integration: Capabilities that fuse OPIR, EO, radar, SIGINT, and commercial sensor data to improve detection, tracking, typing, and characterization — with scalable software architectures and ML-driven sensor calibration. - Observe, Orient, Decide, Act (OODA) Loop Collapse & Mission Assurance: Solutions that accelerate the sensor-to-decision-maker kill chain with sufficient confidence and explainability to assure mission-critical decisions. These can include but are not limited to dynamic user control of automation (C2, operator overload, scalable operations), orchestration, edge computing, AI trade-space exploration, and authoritative knowledge access. - New sources and methods for Missile Warning that are outside of the current MW operational paradigm tactics, techniques, and procedures (TTPs). Proposals should emphasize technical feasibility and clearly outline a Phase I research plan that can include modeling, simulation, literature review, or trade studies. While a Phase II transition concept may be outlined, Phase I deliverables are expected to focus on a feasibility study detailing USSF CONOPS and technical viability, as well as analytical findings. Feasibility Study: A feasibility study is an assessment of the practicality of developing and implementing a new technology within a given concept. The study aims to objectively and rationally uncover the strengths and weaknesses of the new technology, the feasibility of successful development of the technology, and the viability of the success of implementation of the technology in the proposed CONOPS. The study should: - Identify the benefits of the new technology within the CONOPS over existing solutions (or lack thereof) - Identify the risks, uncertainties/unknowns, and issues of the proposed CONOPS with mitigation and closure measures - Identify the critical technology elements (CTEs) of the new technology - Provide data to support the feasibility of technology development of each CTE to include: literature research supporting technical viability or historical usage, trade studies identifying existing technologies, current developments, and/or feasible development pathways, analysis demonstrating technical solutions, and heritage usage of similar technology with identified differences in operations and/or environment for proposed CONOPS. The Concept of Operations (CONOPS) should clearly communicate how the technology is intended to support a military mission within a defined system. The main purpose of the CONOPS is to facilitate a common understanding of a future system to help develop operational and system-level requirements. CONOPS should be written at the system level first and then expanded on how the technology functions enable successful military operations.

Phase II aims to build off the work completed from the Phase I after successfully demonstrating capability for operational use within the OPIR Tap Lab or similar environments that demonstrate integrating advanced AI/ML for real-time multi-sensor fusion and missile tracking from OPIR systems. Activities include system development, integration, and testing in operationally relevant environments to verify performance metrics (e.g., accuracy, latency, resilience, coverage). Phase II will mature the feasible concepts identified in Phase I into a deployable, testable prototype. Phase II will include design refinement, system development, and operationally relevant testing focused on delivering a measurable improvement in AI/ML techniques to detect and/or accurately fuse any source detecting these threats, either on the ground in the traditional processing ground stations or on board via edge processing. While successful Phase I efforts establish technical feasibility and transition the validated proof-of-concept into the OPIR Tap Lab or a similar testbed, the Phase II efforts will continue the development of technologies coming out of the OPIR Tap Lab. By utilizing this operationally relevant environment, the work progresses to system development, integration, and testing, which de-risks follow-on capability development. The ultimate goal of this pathway is to mature the feasible concepts into a deployable, testable working prototype that delivers a measurable improvement in techniques for multi-sensor fusion and missile detection, warning, tracking and reporting.

Potential Phase III efforts will pursue transition of the capability to operational use through non-SBIR/STTR funding streams, aiming for a Technology Readiness Level (TRL) of 6 or 7 and demonstrating functionality in relevant environments. A key transition pipeline for this capability is the Space Modernization Initiative (SMI) program within Space System Command's Space Sensing portfolio. Successful efforts in potential Phase III efforts will involve full integration into OPIR operational data workflows and fielding the capability at scale to provide recurring operational value and reduce warfighter risk by expanding OPIR sensing capabilities.

If a proposer believes there might be multiple avenues of approach, and considering all requested information is provided for each avenue, can a proposer submit multiple (2, 3, 4, etc.) different approaches/avenues of execution in this one technical proposal?

Vendors may propose trade studies or other objective, multi-variable analyses to compare alternative approaches and show how each addresses the relevant mission need.  

For Phase I performance, no government-furnished data will be provided or stored at the contractor's facility — all work uses simulated/contractor-generated data, with integration against government systems occurring at the government's Colorado facility. Will any of the Phase I deliverables (simulations, code, analysis, or reports) be considered CUI or Covered Defense Information requiring CMMC Level 2 protections on contractor systems, or does the topic's Level 2 requirement pertain to a later phase of performance?

Phase I deliverables require CMMC Level 2 (Self) protections. 

In response to a question from 9/30/2026, you provided the following answer regarding page limitation:The Technical Volume page limit should be 10 pages. A topic change request has been submitted to update the Component Instructions. After this change request is processed, small businesses are expected to follow the SBIR/STTR PHASE I PROPOSAL TEMPLATE and the page length should not exceed 13 pages. The solicitation now states the following:Technical Volume (Volume 2) Page/Slide Limit - N/AProposals must use the “ Space FY26 SBIR Phase I Proposal Template” as previously indicated, there is no independent page limitation outside of the mandate to use the Space FY26 SBIR Phase I Proposal Template.  Please advise what is the correct page limit for this proposal.

Small businesses are expected to follow the Component Instruction guidance:  “Proposals must use the “ Space FY26 SBIR Phase I Proposal Template” as previously indicated, there is no independent page limitation outside of the mandate to use the Space FY26 SBIR Phase I Proposal Template.” 

Does SSC and the OPIR Tap Lab expect Phase I performers to demonstrate hardware-in-the-loop results on flight-candidate silicon, or would an algorithm-level feasibility study using representative or synthetic multi-sensor datasets meet the intent of this effort?

OPIR TAP Lab does not expect hardware-in-the-loop results in Phase I. Algorithm-level feasibility study using representative synthetic datasets is good.

Where does the current multi-sensor picture break down first, in practice? We are trying to understand which part of it the mission actually feels day to day. 

On-orbit fusion between LEO, MEO and GEO has not been fully demonstrated. Automated coordination and handoff of 2D single sensor tracks on-orbit fusion engines to produce a 3D track and disseminate to a COCOMs AOR also has not been demonstrated.

Is there a reference system boundary the CONOPS should be written against?

The system boundary should be bound by TCPED (Tasking / C2, Collection, Processing, Exploitation and Dissemination) for Missile Warning. Understanding the implication of pushing TCPED (automated execution on orbit) to the edge is desired.

Which operator or decision-maker role, at which echelon, consumes the explainability and dynamic user control output, and which decision anchors the CONOPS timeline: releasing a warning report, holding track custody through handover between orbital regimes, or retasking sensors? 

All the above are considered. The government is looking for solutions across the full mission timeline, from detection through to warning the COCOMs in their AOR. Tradespace with pros and cons should inform a CONOPs timeline.

Will the Government furnish multi-orbit OPIR or track data or a simulation environment for Phase I prototypes or simulation results? If not, at which processing level does the Tap Lab expose data (sensor observations, single-sensor tracks or fused tracks), from which sensor classes, and in which formats and update rates?

No, Phase I does not have any GFx. For Phase II, the TAP Lab will expose imagery through processed tracks (2D and 3D) from all the operational sensors within the Missile Warning mission area.

Is there a preferred unclassified and open system or military operation our solution should consider?

There is not a preferred unclassified/open system that should be considered for Phase I. 

Is there a shareable baseline dataset for stress-testing sensor and orbital fusion algorithms?

The government does not have a reference baseline for this effort. The government is looking for novel solutions for rapid on-orbit fusion and messaging to COCOMs at the speed of need.

Does your team have a preferred mod/sim environment for testing OODA-loop algorithms in a mission-level context? 

We do not have a preferred mod/sim environment and would be open to the vendors choice in how they want to present the data. 

What portion of project performance will be required on-site in the Boulder TAP Lab?

For Phase I, the vendor will not be required to be on-site in Boulder OPIR TAP Lab. 

For Phase I, is the feasibility study expected to include simulation results, or is a CONOPS with trade studies and analytical findings sufficient where the technology is at specification level?

Phase I deliverables can include simulated results but are not required. A CONOPs with trade studies and analytical finding are sufficient.

Under "OODA Loop Collapse & Mission Assurance," the description references sufficient confidence and explainability to assure mission-critical decisions and authoritative knowledge access. Is a solution scoped to validating sensor and track inputs against independent references before fusion—producing a per-input confidence record rather than a fused track—within the intended scope, or is the topic directed at fusion and tracking algorithms specifically?

The topic is open to any solution that collapses the OODA loop while maintaining mission assurance. The government is not being prescriptive in what it is asking for to cast a wide net on ideas. 

Are there specific threat classes or orbit regimes you would want a Phase I effort to prioritize?

The government is not prioritizing a specific threat or orbit regime for this Phase I effort.

For Phase I feasibility, is a simulation-based demonstration acceptable, and is validation against the OPIR Tap Lab or other government-furnished data the intended Phase II path?

Yes, a simulation-based demo is acceptable. Yes, validation against OPIR TAP Lab or other GFD is intended for Phase II.  

Is multi-orbit, angle-only registration and existence declaration where you see the hardest current gap, or is your priority elsewhere in the detect-warn-track-report chain?

Yes, this is one of the challenges the government is interested in addressing. 

What does the current process cost today, in hours, people, or missed tasking?

This will be discussed in the execution of Phase II. 

What system or platform should it integrate with?

It depends on what the vendor is proposing to determine what system or platform it might integrate with.

Which program office would own this capability if it transitions?

Any number of program offices could take the output of these efforts based on what parts of the mission they are solving.

Would a feasibility study examining fusion of distributed ground-based optical observations with OPIR or representative OPIR data be considered responsive to this topic?

Yes, a feasibility study like this would be considered as long as it addresses the needs asked for in the solicitation.

Phase I deliverables and transition. What minimum analysis, demonstration, and integration-planning artifacts are expected at the end of Phase I, and which customer organization will assess them and sponsor the subsequent Phase II integration path?

Phase I deliverables are to be determined in the beginning of Phase I based on what the vendor proposed. Government Subject Matter Experts (SMEs) will assist both the government and vendor in setting acceptance criteria for each project.

What personnel, information-handling, and system-access prerequisites apply to Tap Lab participation? 

Access and onboarding will start in Phase II. 

Assurance and operator use. How should the system communicate uncertainty, unsupported conditions, and degraded input quality to downstream users, and what requirements apply to reproducibility, operator review, and evidence supporting a model update?

It is up to the vendor to propose uncertainty, unsupported conditions and/or degraded input quality to potential users. 

Tap Lab interfaces. What software interfaces, data schemas, packaging requirements, and test environments must be supported for integration with the Overhead Persistent Infrared Tap Lab, and what technical documentation can be provided before proposal submission?

OPIR TAP Lab resources (data, interfaces, environments etc.) will be discussed during Phase I and not prior to proposal submission.

Computing constraints. Should the initial capability be designed for ground processing or onboard execution, and what processing, memory, power, and communications constraints should be treated as fixed design inputs?

All processing regimes are considered. Near-term execution is ground based while future execution will be at the edge (on orbit or remote distributed ground). Venders are responsible for determining processing, memory, power, and communication constraints of their concepts/designs. 

Performance evaluation. What reference baselines and definitions should govern accuracy, false alerts, processing latency, and uncertainty evaluation, and which of these measures will determine whether the proposed function merits Phase II development?

Accuracy, false alerts, processing latency etc can be estimated using defacto standard but vendor defined criteria. The government will discuss this criteria during the Phase I portion of the effort.

Coverage and representativeness. Which orbital regimes, sensing conditions, and combinations of sources must the initial feasibility analysis represent, and what criteria will the government use to judge whether the selected dataset covers the intended application adequately?

For the purpose of this solicitation, LEO, MEO and GEO will be considered. 

Phase I data access. What unclassified or otherwise authorized representative data can a Phase I performer obtain, on what schedule, and which public or synthetic alternatives would be acceptable if government data are unavailable during the three-month effort?

The performer may utilize whatever data they choose to represent their concepts and ideas.

Input data definition. At what processing level should the proposed function accept data, and what sensor metadata, time references, coordinate conventions, uncertainty information, and data-quality indicators can be assumed to accompany those inputs?

It is up to the vendor to propose what metadata, time references, coordinate conventions, uncertainty information and data-quality indicators are necessary to prove function performance.

Priority processing function. Which processing gap has the highest priority for an initial contribution, and is a proposal focused on one well-defined function and deployment location acceptable without addressing the entire detection, warning, tracking, and reporting chain?

The vendor should propose in the area they are specialists in. Specific discussion around gaps will occur in Phase II. 

Data Access: Should we plan to develop with OPIR TAP Lab data or expect only simulated/external datasets?

For Phase I, it is expected the vendor use external/simulated datasets or internally generated datasets. 

Should offerors anticipate government-furnished algorithms through the Tap Lab, or should the proposed solution include its own fusion/tracking algorithms?

If Phase I is successful, the government would make tracking and fusion algorithms available. 

Would an approach focused on providing the in-space edge-compute and orchestration layer to host and execute fusion/tracking algorithms—as opposed to developing a new fusion algorithm itself—be considered within the intended scope of the topic? 

Yes, approaches for in-space/edge-compute orchestration layer to host tracking and fusion algorithms would be considered.

What data can a Phase I performer work against? Is unclassified or synthetic OPIR-representative data available, or is the performer expected to generate its own?

Phase I performers may use unclassified or synthetic OPIR representative data or they can generate their own data.

Does Phase I performance include access to or onboarding into the OPIR Tap Lab, or does that occur at Phase II?

Access and onboarding to the OPIR TAP Lab will occur in Phase II. 

Does the Government have a directed or preferred standard for track and tasking exchange in this mission area, or is that left to the performer?

The government is looking for new ideas for track and tasking exchange and does not want the vendor to be biased towards current methods. 

Can a Phase I proposal stand on its own and be competitive if it focuses exclusively on the OODA loop collapse and mission assurance area, or is the OPIR Tap Lab expecting submissions to address all three focus areas collectively?

Yes, a Phase I proposal that addresses the collapse of the OODA loop does stand on its own and would be considered if it contained novel solutions using AI/ML as this is an AI/ML topic area. 

The solicitation instructions state the page limit for the technical volume is 30 pages. However, the DoD SBIR FY26 SpaceWERX Topics--SBIR/STTR PHASE I PROPOSAL TEMPLATE states: “Content is bound to the designated page(s) as indicated on the Table of Contents. Page numbers and content should be adhered to and NOT changed." And this only goes up to page 13. So are we bound to the designated pages as indicated on the Table of Contents in the proposal template, or can we ignore the existing page numbers in the Table of Content?

Small businesses are expected to follow the Component Instruction guidance:  “Proposals must use the “ Space FY26 SBIR Phase I Proposal Template” as previously indicated, there is no independent page limitation outside of the mandate to use the Space FY26 SBIR Phase I Proposal Template.” 

The Phase II description states that successful Phase I efforts may progress to operationally relevant testing within the “OPIR TAP Lab or similar environments” and refers to transition into the “OPIR TAP Lab or a similar testbed.” For Phase II planning, could the Government please clarify the intended transition pathway:Is participation in the OPIR TAP Lab required for every NV510 Phase II awardee, or may a Phase II effort instead conduct integration and operationally relevant testing in another Government-approved SSC/USSF environment, testbed, or program-of-record pathway when appropriate to the technology and Phase I results?If TAP Lab participation is not universally required, is TAP Lab required specifically when the Phase II effort depends on TAP Lab-controlled OPIR data or infrastructure?Who determines the Phase II integration and test environment: the Government based on Phase I results, the performer through its Phase II proposal subject to Government approval, or a jointly defined transition plan?We are asking to clarify whether NV510 requires a single TAP Lab-based Phase II pathway or permits other Government-approved operationally relevant transition paths.

Yes, physical presence in the OPIR TAP Lab is required for Phase II awardees. The OPIR TAP Lab allows for the reduction of any risks to integration with all the relevant current data from actual mission area sources prior to integration with any USSF SSC program-of-record.Yes, Phase II awardees will be required to integrate their proposed solution in the TAP Lab with TAP Lab-controlled data.The Government makes the final determination of any Phase II integration and test environments. Phase I efforts must be beneficial to USSF SSC Missile Detect, Track, Warning and Reporting mission area. Decisions to promote a project to Phase II are at the sole discretion of the Government.

Question 1.) Is the customer open to amending the current topic to support a Direct to phase II effort?  Question 2.)  Would a network-aware orchestration platform that supports application resilience and shares current information about sensor and service availability be a welcome area of investigation under this topic? This could include automated recovery and helping applications adapt to changing connectivity and data availability.

Answer 1: This effort is only interested in Phase I proposals at this time.  Answer 2: If the proposed solution advances the application of artificial intelligence or machine learning for missile detection, tracking and warning, then the government welcomes this as an area of investigation. 

Should we plan on needing to do our own source extraction from images, or do all images have associated track data for extracted sources?

The vendor should plan to extract their own track data from the synthetic datasets.

Under the “Multi-Source Integration” objective, can ground-based commercial electro-optical observations be considered an additional data source for fusion with OPIR data for missile detection, warning, tracking, and reporting? Specifically, would a Phase I feasibility study evaluating the fusion of distributed ground-based optical observations with OPIR or representative OPIR data be responsive to this topic? Additionally, will Government-provided or representative OPIR datasets be available to selected performers during Phase I for development and validation of multi-source fusion approaches?

Yes, a feasibility study evaluating ground-based commercial electro-optical observations would be considered as a source of fusion with OPIR. The government will not provide any data during Phase I. Vendors may use their own synthetic datasets or ASSET synthetic data.

Question 1: What is the nature of the OPIR TAP Lab data with which we will be integrating? Are they measurement data or are they (for example) EOIR images from which we need to extract measurements? Question 2: How will we interface with the TAP Lab data in Phase II? Will we need to travel to the OPIR TAP Lab, or will we have remote access to the data? Question 3: Can we interface with OPIR TAP Lab data in Phase I, or is that reserved exclusively for Phase II?

Answer 1: OPIR data is in imagery formats (HDF5 and ILOS), and track data (Overhead Persistent GEOINT Architecture (OPGA)) as both 2D and 3D tracks and contains measurement data. This data will not be made available until Phase II. Answer 2: The OPIR TAP Lab has an onboarding process that vendors follow to access lab resources. Lab access won’t be discussed until Phase II. Generally, yes, vendors will need to travel to the OPIR TAP Lab to access data. There is no remote access to the data. Answer 3: The government does not plan to give vendors access to OPIR TAP Lab data in Phase I and is reserved for Phase II.

I'm looking at the OODA Loop Collapse / Mission Assurance area, specifically the “AI trade-space exploration” item, and the note that Phase I can be modeling, simulation, or trade studies.My approach would be a Phase I feasibility study using a deterministic simulation that screens the multi-orbit OPIR sensing trade space — which constellation, revisit, latency, and fusion-architecture parameters actually drive warn-to-decision time under a saturation raid. The point is to find where AI/ML fusion would have real leverage before Phase II, not to propose a new detection or fusion algorithm in Phase I.Is that responsive to this topic? And would the Tap Lab want something like that delivered as a standalone offline analysis tool, or plugged into an existing testbed workflow?

Yes, a feasibility study would be appropriate for this topic. As stated, the delivery for Phase I can be a model, simulation or trade study. Phase I deliverables may progress to tools and/or applications that might run in the TAP Lab or inform requirements for a program of record. The government will not make that decision on future use of the delivered product until the end of Phase I.

The topic emphasizes development of AI/ML detection, tracking, and fusion algorithms, but also lists "edge fusion" and "edge computing" under the Edge Fusion & Autonomy and OODA Loop Collapse focus areas. We are considering a Phase I effort focused on the in-space edge compute architecture that hosts and executes such algorithms on-orbit. This would be the processing infrastructure that enables in-space fusion and autonomous constellation operations, rather than new detection or tracking algorithms themselves. Would this type of effort be considered responsive to the topic? If so, is there any guidance on how an architecture-focused effort should demonstrate a path to integration and testing in the OPIR Tap Lab?

Yes, in-space edge compute architecture(s) would be considered for this solicitation. Demonstration of integration pathways and testing for this type of solicitation is at the discretion of the vendor and should follow standard architecture development documentation like DoDAF 2.0 or other architecture description document methodologies. 

Would a Phase I approach focused on mission-aware orchestration and AI-assisted trade-space decision management—rather than development of a new detection or tracking algorithm—be responsive to the OODA Loop Collapse & Mission Assurance focus area, particularly where the research evaluates dynamic allocation of sensing, fusion, and processing across ground and edge resources?

Yes, this would be an appropriate submission topic for this solicitation. 

The Department of the Air Force has a high priority requirement for much lower-cost long-range air-launched prompt strike weapons that operate in the very high supersonic flight regime. Towards that requirement, the objective of this topic is to develop a Ku-band multi-function RF seeker system that can be manufactured at scale, supporting RF modes including radar, passive direction-finding, and line-of-sight datalinks. Low unit production cost and high-volume manufacturability are key goals of this topic.

Current multifunction radar systems for use onboard various types of small airborne platforms are prohibitively expensive to procure at scale, and this is especially true for systems engineered for use in demanding high subsonic regimes (peak velocity greater than Mach 3 but under Mach 5). This effort will leverage recent advancements in RF technology, high-temp materials science, and associated manufacturing to design a complete multi-function Ku-band RF system to a Critical Design Review (CDR) level of maturity. Key technical requirements include the need to fit within a 6” interior diameter cylinder (whether conformally mounted or forward mounted), needing to conform to the WOSA Seeker Domain interface specification, incorporating imaging radar modes, passive direction-finding modes, and height of burst fuze sensing modes.

For this Direct-to-Phase-II topic, the offeror must have previously demonstrated Phase I-type feasibility by demonstrating the successful system design, modeling, and hardware specifications of a multifunction radar system for use in an embedded system application. This feasibility demonstration shall also describe a baseline conceptual design for the proposed multifunction radar system.

For this Direct-to-Phase-II topic, the offeror will design and model a prototype for Critical Design Review (CDR) level, a complete Ku-band multi-function radar system. Emphasis will be placed on lowering the flight-unit production cost at volume production to a threshold of $50k and an objective of $30k while meeting or exceeding the RF performance metrics of a contemporary, similarly-sized multifunction radar system. The offeror’s design will size and package the front end and back-end RF electronics to fit within a 6” interior diameter cylinder.

Following successful completion of the Phase II objectives and the culmination of a CDR-level system design, AFRL and its transition partner will utilize 6.3 funding to implement a prototype of the radar system designed in Phase II, perform laboratory, HWIL, and field testing, and then integrate it into a 6.3 flight experiment for further tech maturation. TRL and MRL gaps will be identified and addressed in order to transition the system to AFLCMC/EB and other DoD users.

The description mentions ‘subsonic’,  and then mentioned Mach 3 to Mach 5. Is it correct to assume that ‘subsonic’ was a typo, and that ‘supersonic’ was intended? 

Wires did get crossed here-- while getting a low-cost RF system within the 30-50K budget limit for a supersonic weapons platform would be ideal, I recognize that even working in the high subsonic regime (.7-.8 M) would still put strain on that budget limitation.  Because the driving variable for this effort is the cost and because the subsonic variant of the platform in question is closer to production, I am willing to accept a high subsonic multifunction RF system design. If you can meet the challenge of a high speed environment within the cost given though, that would be looked upon favorably. 

Develop compact low-SWaP optically- or electrically-pumped mode-locked lasers in the near-infrared (NIR) to short-wave infrared (SWIR) capable of operating at repetition rates between 6 and 12 GHz.

Mode-locked semiconductor lasers can support high repetition rates up to 100 GHz due to the high gain and fast gain recovery unlike in fiber lasers or doped dielectric gain medium lasers. While harmonic mode-locking or pulse interleaving can be used to increase the repetition rate into the 4 to 10 GHz range each of these techniques lack a pure microwave signal. High repetition rate semiconductor lasers can provide the low-noise microwave signal due to the fundamental mode-locking that can be achieved in the gigahertz range with a semiconductor saturable absorber mirror (SESAM). This offers a compact, efficient, low-noise, high-speed option for connecting the optical and microwave domain enabling integration with photonic integrated circuits (PICs) or COTs components. Currently a commercially available stabilized low-noise laser in the 6 to 12 GHz range is lacking.A promising approach is a technique enabling a two-element cavity design for high-repetition rate lasers has been demonstrated [1,2]. By including the semiconductor saturable absorber with a dielectric output coupler the overall cavity length can be made shorter for high-repetition rates without complex gain structures and without high curvature cavity optics. In the near-infrared (NIR) this was demonstrated on a curved output coupler with a bonded quantum well saturable absorber resulting in a hybrid SESAM [1] achieving pulse-widths of about 400 fs at repetition rates from 2.8 to 8 GHz. In the visible spectrum a similar technique was applied with a flat dielectric mirror, constructing what was coined as a membrane saturable absorber mirror (MESAM) [2]. Due to the output coupler and saturable absorber being independent the repetition rate remained low but still achieved picosecond pulses. Integrating these elements via direct membrane bonding of the saturable absorber allows higher repetition rates and has been demonstrated for high-power applications [3]. It is envisioned that this approach, or other proposed solutions, can be extended throughout the NIR and into the SWIR, particularly in the O-band and C-band for compatibility with PICs and COTs components.The developed lasers should be able to operate at a repetition rate between 6 and 12 GHz, achieve 50 mW or greater average power, with a pulse width of a picosecond or less. The laser can be optically- or electrically-pumped but must have the repetition rate stabilized with custom or COTs electronics while achieving low relative intensity noise (RIN) and long-term power stability. It is expected that the overall SWaP of the laser itself and necessary electronics will be minimized with differentiating goals highlighted in Phase I, II, and III. No government materials, equipment, data, or facilities will be provided.

Develop a proof-of-concept for the necessary components and conduct a feasibility study to validate the model for a breadboard 6 to 12 GHz mode-locked laser with picosecond or shorter pulse widths. Component modeling is to include semiconductor gain medium, saturable absorber or other mode-locking element, and necessary fabrication steps for the components. Potential metrics include average power, pulse energy, pulse width, long-term power stability, spectral bandwidth, repetition rate tuning, and relative intensity noise (RIN). Supporting electronics can utilize benchtop solutions.

Conduct research to transition the validated Phase I design into prototypes for two fiber-coupled brassboards with full stabilization and low-noise low-SWaP implementation of the NIR to SWIR mode-locked laser. Aside from an external DC power supply, all electronics should be modular with the ability to integrate in Phase III.

Develop a fully packaged low-noise high-repetition rate mode-locked laser operating in the NIR to SWIR spectral range suitable for system integration and commercial sales.

Is a mode-locked fiber laser operating at 6-12 GHz repetition rate responsive to this topic?

Yes, if the other specifications can be met with fundamental mode-locking.

Is the end goal to have a pulsed laser that also produces (after OE conversion) a microwave signal at the funamental rep rate? Or, is the end goal to produce a high-rep rate pulsed laser/optical frequency comb only, and thus a microwave drive signal at the fundamental rep rate can be used?

A high-rep rate pulsed laser is the goal and a microwave drive signal alone is not sufficient.

The objective of this SBIR Phase I project is to develop and demonstrate advanced quantum memory systems essential for enabling secure communication within quantum networks. The primary goal is to enhance the storage and transmission capabilities of photonic qubits, ensuring high coherence and minimal loss over extended distances. This will facilitate the creation of scalable quantum repeater systems that significantly improve the efficiency and robustness of Quantum Key Distribution (QKD). By focusing on the foundational aspects of quantum memory hardware, this effort aims to address critical challenges in quantum communication, providing a reliable solution that can be adapted and expanded upon in subsequent phases. The results from this phase will establish a solid technical foundation, allowing for iterative improvement and seamless integration with existing and future quantum entanglement sources and networks.

The rapid advancement of quantum computing poses a significant challenge to traditional encryption methods, potentially compromising the security of digital communications. Quantum Key Distribution (QKD) provides a solution by utilizing quantum properties to generate secure encryption keys. However, the current QKD systems are limited by signal loss over long distances, preventing widespread implementation. This project seeks to address this limitation by developing advanced quantum memory systems, or quantum repeaters, designed to extend the range and fidelity of quantum signals. These repeaters will enable efficient Quantum Key Distribution over long distances, thereby enhancing secure communications for the Air Force's digital infrastructure. The primary goal of this project is to develop and demonstrate advanced quantum memory systems capable of high coherence and minimal loss, essential for reliable communication within quantum networks. At the project start, the technology is at a Technology Readiness Level (TRL) 2, focusing on the application concept formulation. By the end of Phase II, the target is to reach TRL 5, demonstrating the integrated system in a relevant environment. The required efforts will commence with foundational research and development of quantum memory hardware. In Phase I, the tasks will involve designing quantum memory materials, developing quantum repeater prototypes, and validating their performance through controlled laboratory experiments. Key activities will include:Designing and fabricating quantum memory materials aimed at reducing signal decoherence and data loss.Developing prototypes capable of storing and transmitting photonic qubits.Conducting laboratory tests to validate the prototypes' performance against defined metrics (e.g., coherence, loss, noise).For Phase II, the focus will shift to refining these prototypes, integrating them into a scalable network, and validating their operation in a relevant environment. The main activities will include:Enhancing quantum memory systems for increased coherence fidelity and extended transmission distances.Integrating prototypes with existing entanglement sources and quantum communication networks.Testing the quantum memory systems in simulated and real-world environments to ensure robustness and reliability.Evaluating performance through rigorous data collection and analysis to meet predefined security and operational metrics.Minimum deliverables for this project include detailed technical reports, functional quantum memory prototypes, performance evaluation data, and an integration roadmap detailing steps for transition into operational use. The advanced quantum repeater systems developed through this SBIR initiative will significantly enhance the DoD's capabilities in secure communications, positioning the Air Force at the forefront of quantum-secured information transfer.

Phase I will assess the feasibility of using quantum memory hardware to enhance Quantum Key Distribution (QKD) by requiring proposals to detail the scientific approach, develop a conceptual design for a functional quantum memory prototype showcasing its capabilities and potential advantages in both lab and simulated environments. Demonstrate Technology Readiness Level 3 by drafting a feasibility report and a detailed architecture plan for a Phase II prototype of a lab-based test bench capable of end-to-end quantum information transport.

Phase II will focus on developing a prototype quantum repeater/memory system, validating functionality in relevant environments, and achieving TRL 4-6. This involves building scalable prototypes, integrating with entangled pair transmission equipment, and rigorous lab testing to meet metrics such as coherence, loss, and security. Successful outcomes will demonstrate transition readiness for development and deployment.

In Phase III, the quantum memory technology will achieve TRL 7, transitioning into secure DoD communication networks and commercial QKD applications. Expected efforts include finalizing integration, extensive testing, obtaining necessary certifications, and establishing production capability. Potential Air Force customers include network and cybersecurity divisions. This addresses critical needs for secure, long-range communication solutions.

Are there specific metrics for parameters such as storage efficiency, fidelity, and lifetime that the quantum memory will need to achieve?

1. ObjectiveDevelop, demonstrate, and integrate a scalable quantum memory buffer capable of interfacing with existing classical communications and telemetry networks at Edwards AFB. The technology must enable secure entanglement distribution, facilitate quantum-classical data routing, and serve as a foundational node for future secure quantum communication infrastructure without disrupting legacy classical data flows.2. Technical Performance RequirementsCoherence Time (Storage Duration): The quantum memory must achieve a minimum coherence time capable of supporting long-distance entanglement distribution across the Edwards AFB flight test range. Minimum threshold: >10 milliseconds; Objective: >1 second.Fidelity & Efficiency: The system must maintain a quantum state fidelity of >90% upon retrieval. The photon-matter interface efficiency must exceed 75% for writing and reading quantum states.Wavelength Compatibility: The system must be compatible with existing classical fiber-optic infrastructure. It must operate at standard telecommunications wavelengths (e.g., 1550 nm C-band) or provide highly efficient, low-noise quantum frequency transduction to convert states from the memory’s native wavelength to telecom bands. Classical Interoperability: The memory must include classical control logic and network interfaces (e.g., Ethernet, TCP/IP) to allow standard network routing equipment to manage quantum node synchronization, timing, and error correction without destroying the stored quantum states for encryption purposes.3. Environmental and SWaP (Size, Weight, and Power) RequirementsOperational Environment: Due to the arid, high-temperature environment of Edwards AFB and potential deployment in mobile or remote telemetry nodes, the system must minimize extreme cooling dependencies. Preference will be given to room-temperature atomic vapor systems or solid-state systems utilizing localized micro-cryogenics rather than full-scale laboratory dilution refrigerators.Form Factor: The quantum memory node and its classical control interface must be rack-mountable within standard 19-inch server racks used in DoD network operations centers.4. Security and Operational ConstraintsControl Software Security: All classical software used to control, synchronize, and monitor the quantum memory must be developed in accordance with DoD DevSecOps guidelines and be capable of operating within an Impact Level 5 (IL5) environment.Data Handling: The system must be capable of processing and securing telemetry and mission data designated as Controlled Unclassified Information (CUI).Post-Quantum Resilience: The classical control channels managing the quantum memory must be secured using algorithms compliant with National Institute of Standards and Technology (NIST) post-quantum cryptography standards.5. Phased DeliverablesPhase I: Conceptual design, feasibility study, and software simulation demonstrating the quantum memory node successfully interfacing with standard classical network protocols. If a potential vendor currently possesses a laboratory setup, measured values will also be taken into account but will be improved upon during phase II. Literature is acceptable as the foundation to define the baseline, threshold, and objective metrics need to improve on.Phase II: Hardware will be produced and interface with a “classical” standalone network. The following testing will be conducted:Performance and functional testing (connectivity, speed and bandwidth, load, protocol)Security testing to include vulnerability scanning, penetration testing, firewall and intrusion detection system. 6. ExperienceIdentify past quantum technology work with details.Identify the current measurement equipment currently on hand or are willing to purchase or rent for testing purposes. Identify lab setup and hardware currently used.State any past work with the Department of War (DOW).Identify experience with DOW cybersecurity processes. 

The objective of this SBIR Phase I effort is to explore and develop innovative technologies leveraging cellular network infrastructure, particularly focusing on Open Radio Access Network (Open RAN) architectures, to enhance communication capabilities on the flight line at Edwards AFB. The goal is to establish a secure, adaptable, and interoperable cellular network that facilitates superior aircraft maintenance, logistics, and operational efficiency. Additionally, the effort aims to support advanced test and evaluation activities, promoting a high-performance communication environment that meets the stringent demands of a modern Air Force Base. This R&D initiative will focus on feasibility studies, system design, and foundational prototyping, ensuring flexibility for future adaptation and integration into subsequent phases based on Phase I outcomes and insights.

Flight line operations at Edwards Air Force Base (AFB) face increasing demands for more efficient, secure, and real-time communication systems to enhance aircraft maintenance, logistics, and operational performance. Current communication solutions are limited by outdated infrastructure, lack of interoperability, and insufficient data transmission capabilities. There is a distinct opportunity to leverage advanced cellular network technologies, particularly 5G and Open Radio Access Network (Open RAN) architectures, to address these limitations and modernize the flight line environment.The objective of this SBIR Phase I project is to explore and develop innovative solutions utilizing cellular network infrastructure designed specifically for flight line applications. The aim is to create a secure, adaptable, and interoperable network that improves real-time communication, data sharing, and operational efficiency at Edwards AFB. The project will focus on enhancing ground crew coordination, enabling real-time aircraft health monitoring, and supporting predictive maintenance to reduce aircraft downtime and enhance mission readiness. Augmented reality (AR) applications will be integrated to provide maintenance personnel with real-time guidance, schematics, and remote support, further optimizing maintenance tasks.From a technical standpoint, the initiative will employ a 5G Open RAN architecture, offering increased flexibility, interoperability, and security while minimizing vendor lock-in and lowering costs. The modular design of this network will allow it to accommodate evolving test requirements and future upgrades, ensuring a scalable and cost-effective solution. The network will integrate seamlessly with Edwards AFB's existing infrastructure and employ efficient frequency allocation through spectrum sharing mechanisms.The anticipated Technology Readiness Level (TRL) at the start of this project is TRL 4, with a targeted advancement to TRL 6-7 by the end of Phase II. This progression will be achieved through a series of phased activities and deliverables:Phase I: Conduct feasibility studies and initial system design. This includes analyzing current flight line communication requirements, exploring Open RAN components, and developing foundational prototypes. Deliverables will include a comprehensive feasibility report, initial design schematics, and a preliminary prototype proof-of-concept.Phase II: Develop and refine prototype based on Phase I insights. Implementation of pilot deployments and rigorous testing to validate system performance and security. Deliverables will include a full-scale prototype, detailed test results, and an integration plan for transitioning the technology to operational use at Edwards AFB.The successful completion of this project is expected to significantly advance the DoD's technological state by providing a robust, future-proof communication solution tailored to the unique demands of flight line operations. This development aligns with modernization priorities such as Integrated Network System-of-Systems and Sustainment & Logistics, ultimately contributing to the operationally focused Advanced Battle Management System (ABMS).

Phase I will assess the feasibility of an Open RAN network for flight line use at Edwards AFB. It will outline network architecture, components, deployment strategy, and address potential interference with aircraft systems. Deliverables include security analysis, use cases, and integration plans. Success includes achieving TRL 3-4, demonstrating proof-of-concept through a preliminary prototype and feasibility report.

Phase II will develop and test a prototype Open RAN network at Edwards AFB. The system will include base stations, network components, user equipment, and specialized sensors. Testing will evaluate performance and ensure compatibility with aircraft systems, assessing coverage, bandwidth, latency, security, and operational impact. The system must integrate with Edwards AFB’s infrastructure and achieve TRL 6, demonstrating a functional prototype in an operational setting.

Phase III involves scaling the Open RAN cellular network at Edwards AFB to enhance flight line operations, targeting TRL 7. Military applications include real-time maintenance data and improved logistics coordination. Commercial use spans complex logistics in aerospace sectors. Transition efforts will engage the 412th MXG, AFMC, and commercial partners, supported by Air Force Sustainment Center and AFLCMC funding.

An earlier answer says the L- and S-bands managed by the Edwards spectrum management office will not be used, and that the study should find bands outside that office's control. Does that exclusion also cover commercial CBRS (3550 to 3700 MHz, General Authorized Access) and 37.0 to 37.6 GHz, or may Phase I evaluate those as candidates outside the office's control? 

For Phase I coverage and coexistence modeling of the flight line, will the Government furnish site geometry (building footprints and heights, apron and parking layout, candidate antenna mounting points) as Government-furnished information? And are there restrictions on using publicly available geospatial data of Edwards AFB, such as USGS lidar or imagery, in proposals or Phase I deliverables? 

The topic identifies a starting TRL of 4 and calls for feasibility studies, initial system design, and foundational prototyping. May Phase I build upon previously developed and integrated commercial/private 5G technologies, with Phase I R&D focused on adapting and evaluating those technologies against the flightline-specific Open RAN, interoperability, spectrum, security, and operational requirements?

Should offerors assume access to Edwards AFB facilities, existing network infrastructure, spectrum/environmental information, or Government-furnished equipment/data during Phase I, or should Phase I feasibility analysis and prototyping be planned using a representative laboratory environment?

The topic calls for foundational prototyping and a preliminary prototype during Phase I. What level of prototype implementation or demonstration is expected during Phase I (e.g., architecture/interface demonstration, laboratory hardware integration, representative 5G network demonstration, or another level of implementation)?

For Phase I, does the Government have specific Open RAN/O-RAN architectural components, interfaces, or interoperability requirements that must be addressed, such as Open Fronthaul, O-CU/O-DU/O-RU separation, RIC, or multi-vendor interoperability?

Can the Government provide a list of everything expected to connect to the network as user equipment, both initially and in later phases (for example aircraft instrumentation and data acquisition units, onboard recorders, maintenance tablets and laptops, ground support equipment, sensors, AR headsets), with approximate quantities, data rates, and whether each device buffers or records data locally during link outages?

Topic will focus first on a phase I feasibility study focused on spectrum allocations and authorities to operate. Look to answers below for more explanation.  During phase two a prototype end-to-end wireless network will be built interfacing with current instrumentation systems typical to an airborne platform and the current network hardware in place within a localized area.  Cellular metrics should adhere to current capabilities of the system built. Your simulation predictions should be close to real-world capabilities. 

Has the Edwards AFB spectrum management office already ruled out, or does it prefer, any specific frequency bands for this network (for example DoD lower 3 GHz at 3.1–3.45 GHz, CBRS, or 37 GHz), so the Phase I spectrum study can focus on viable allocations?

I will restate here but this was answered in a previous questions. Phase I feasibilityA feasibility study will be conducted with a centralized focus on NTIA frequency compliance, RF layout and network simulations, and end-to-end system design. BLUF: Edwards AFB owns and manages specific frequencies in the L/S/C-bands, L/S-bands will not be used for this project. C-band, 4400-4940MHz and 5091-5150MHz are viable options. The principal purpose of the initial investigation is to identify any frequency bands not controlled and managed by Edwards AFB spectrum management for use. Once an operating frequency has been identified, phase I will require the RF and network simulations, and end-to-end system design stated above. NTIA Frequency compliance studyInvestigate possible implementation of FR1 and FR2 frequencies and identify the following:Permitted hardware within NTIA bands of operation.Any difficulties procuring hardware for bands allowed under NTIA not within the control of Edwards AFB spectrum management.Identify, deconflict, and validate operating slices within or adjacent to these frequency windows that are not actively assigned, controlled, or reserved by the Edwards AFB Spectrum Management Office (SMO) for primary range telemetry or flight test corridors.

Which aircraft types (or radar altimeter models) are expected to operate within the Phase I study area? Knowing whether legacy military or test aircraft altimeters are in scope will set the protection criteria for the 4.2–4.4 GHz band in the coexistence analysis.

Expect radio altimeters within the band you stated. We have done past work with cellular technology and did observe interference signals within the radio altimeter band due to the non-linearities of the RF front that was built. The radio designed must adhere to 3GPP standards and also adhere to spectral emissions mask standards defined within the IRIG-106. 

Will the Government provide the Phase I performer with Edwards AFB spectrum-office constraints (e.g., existing AMT allocations and n79 usage) as Government-furnished information?

Phase I feasibilityA feasibility study will be conducted with a centralized focus on NTIA frequency compliance, RF layout and network simulations, and end-to-end system design. BLUF: Edwards AFB owns and manages specific frequencies in the L/S/C-bands, L/S-bands will not be used for this project. C-band, 4400-4940MHz and 5091-5150MHz are viable options. The principal purpose of the initial investigation is to identify any frequency bands not controlled and managed by Edwards AFB spectrum management for use. Once an operating frequency has been identified, phase I will require the RF and network simulations, and end-to-end system design stated above. NTIA Frequency compliance studyInvestigate possible implementation of FR1 and FR2 frequencies and identify the following:Permitted hardware within NTIA bands of operation.Any difficulties procuring hardware for bands allowed under NTIA not within the control of Edwards AFB spectrum management.Identify, deconflict, and validate operating slices within or adjacent to these frequency windows that are not actively assigned, controlled, or reserved by the Edwards AFB Spectrum Management Office (SMO) for primary range telemetry or flight test corridors.Identify any spectrum hardware with any certifications such as a JF-12 or DD-1494 in possession of.

Does the Phase I effort involve access to or generation of Controlled Unclassified Information (CUI), or only Federal Contract Information (FCI)? If FCI only, is CMMC Level 1 (Self) acceptable for Phase I?

Yes, this effort  will involve CUI. Typical DOW instrumentation information will be utilized over a wireless link.

When connectivity is degraded or temporarily unavailable, is preservation and subsequent delivery of complete instrumentation data a requirement, or is data loss during those periods acceptable?

Data loss is not acceptable. 

What is the desired operational outcome of this effort beyond establishing the 5G transport—for example, is the objective to provide continuous, reliable delivery of aircraft instrumentation and telemetry data from mobile UEs to ground systems throughout aircraft checkout and flight-line operations, including during handovers, congestion, interference, or temporary connectivity loss?

Phase I feasibility will focus on a study defining the operating band. Aeronautical Mobile Telemetry (AMT) is constrained to certain bandwidths within L/S/C-band which are NTIA allocated and managed by our local spectrum management office. We would like a study investigating other NTIA frequency bands of potential use within FR1 and FR2. Within phase I, once this study is complete and operating frequency defined (we can still use the AMT C-band, n79 has been used in the past, we just want to know how creative people can get on use of another frequency allocation) we will require the typical roadmap report of simulations, hardware, design, etc. The purpose is to build a foundational network one piece at a time.  We want a systemic approach to support success in the future. This topic will focus on a small local area network which will act as the seed for expansion to support the entire flight line. We will begin with instrumentation data (aircraft check out) via telemetry in a static configuration and expand from there. A follow on topic will be an environmentally hardened UE. Part of the future roadmap would be to introduce network slices for other operations.

1. Phase I prototype scopeCan Phase I use a small laboratory private 5G network with representative flight-line devices and systems, or does the Government expect the Phase I prototype to use specific Air Force hardware, software, or interfaces?2. Open RAN demonstrationCan Phase I demonstrate Open RAN feasibility using selected commercially available components and software, or does the Government expect the prototype to demonstrate specific Open RAN interfaces, multiple vendors, or other Open RAN capabilities?3. Phase I success measuresCan the performer define representative Phase I targets for connection reliability, data rate, delay, access control, and system integration, or does the Government have specific performance targets that should be used?4. Edwards integration and securityCan Phase I use representative network interfaces and security controls, or are there specific Edwards AFB infrastructure, interfaces, networking standards, or security requirements that the Phase I design must represent?5. Spectrum requirementsCan the performer select a representative 5G frequency band for Phase I testing and use Phase I results to plan the Edwards deployment, or are there specific frequency bands or spectrum-sharing requirements the Government wants the design to address?6. Aircraft compatibilityCan Phase I address aircraft compatibility through modeling, laboratory measurements, and a Phase II test plan, or are there specific aircraft systems, frequencies, standards, or compatibility tests the Government expects Phase I to address?7. Phase II Edwards test supportFor Phase II testing at Edwards AFB, will the Government provide or coordinate site access, spectrum approval, connection to Edwards infrastructure, and access to the aircraft or aircraft systems needed for compatibility testing?

Phase I will focus on feasibility, spectrum compliance is the focus. We will expect simulations with performance metrics, layout, design proposal, and hardware research for use within an NTIA allocation. Vendor phase I research will be conducted on how to leverage commercial hardware within NTIA bands. Commercial hardware is the preference.We will define success measures.The system will integrate into Edwards network equipment currently in use. The system will also adhere to all cybersecurity protocols in place. The chosen vendor should have experience with the DOW cybersecurity process. Vendor phase I research will be conducted on how to leverage commercial hardware within NTIA bands. The vendor will identify specific hardware for use within NTIA allowed frequency bands.Phase I will focus on modeling, simulation, and spectrum compliance issues.Yes, Edwards AFB will provide the testing facilities, access, and spectrum approvals.

The objective of this Phase I effort is to develop methods, including integration of intelligence information, predictive analytics, anomaly detection, threat prediction and environmental monitoring for timely space domain awareness, threat detection and operational environment assessment to support multi-domain operations. Traditional sensing alone cannot track or characterize emergent non-standard threats and current research neglects space-centric operational environment monitoring. To address these gaps, the U.S. Space Force (USSF) seeks novel sensing phenomenologies paired with real-time multi-INT data processing, predictive analytics, and anomaly detection concepts that demonstrate how new sensing and processing techniques can present a comprehensive space operating picture.

With the acknowledgement of space as a warfighting domain in 2019, the U.S. Space Command was established as a geographic combatant command. No orbital regime is entirely safe from intentional or unintentional threats. Adversary forces can track and target U.S. forces in all warfighting domains. The past two decades have witnessed rapidly maturing space based and counterspace capabilities of U.S. adversaries, as well as their attempts to interfere with U.S. military operations. U.S. operational space activities perform a continuous cycle of situational awareness, planning, execution, and assessment to support leadership’s decision-making process at all levels of command.Space Domain Operational Environment Assessment is a prerequisite to achieving space superiority by(a) understanding the situation in space, and (b) gaining insight into space-related activities in other domains. Even in peacetime, awareness and mission assessment in the space domain is difficult to maintain due to the scope and distances involved. Achieving timely awareness and assessment of space activities to support space superiority operations is a monumental, highly technical challenge that is only growing. The past 20 years has seen the number of objects in orbit grow from approximately 10,000 to over 50,000. As this number grows, so too does the need for timely space domain awareness and situation assessment.Given the complexity and challenges of operations in space, this topic seeks to develop a proof-of-concept to leverage multi-INT, multi-domain data, intelligence, and information sources to monitor and assess space operations and their functionality in a timely manner in response to intentional and unintentional threats and situations of interest.To accomplish this, the topic consists of two distinct Technical Areas (TAs). The first TA (TA1) focuses on the collection, processing and analysis of all data types and phenomenologies for advanced Space Domain Awareness and detection of non-standard threats. The second TA (TA2) focuses on analytics, data fusion, machine learning, dynamic command and control for understanding adversary capabilities, actions (offensive/defensive) and effects.Technical Area 1 - Real-time Processing of Non-Traditional Phenomenologies for Non-Standard ThreatsThe space domain is becoming increasingly congested and contested as the population of satellites in the space domain is both increasing and expanding. The emergence of non-standard threats in the space domain poses a challenge for traditional phenomenologies, such as RADARs and electro-optical telescopes. Today’s non-standard threats are increasingly difficult to detect, track and characterize. The United States Space Force (USSF) must possess the capability to monitor the space domain for nonstandard threats in order to protect national assets. This topic seeks to identify new sensing phenomenologies and the processes necessary to detect, track, and characterize non-standard threats. Additionally, the USSF needs to understand how these new phenomenologies complement and improve information products generated by traditional phenomenologies.Technical Area 2 - Real-Time Automated Data Fusion, Analysis & ExploitationJoint space forces typically support multiple Combatant Commands, joint functions, and Operational Environments simultaneously to create effects during all military operations (strategic, operational, and tactical). Joint planners continually coordinate across internal and external equity holders to integrate intelligence and information for commander guidance and decisions on the development and refinement of space strategies, plans, and objectives. The timely assessment of space operations is critical for the iterative joint planning process, especially in a contested environment, and must keep pace with evolving conditions and considerations. This can be challenging in the space domain where operators often cannot directly observe the effects of an operation and resulting adversary behavior.Space operations assessment measures the progress toward accomplishing a task, creating an effect, achieving an objective, or attaining an end state by comparing forecasted outcomes to actual events to determine the overall effectiveness of force employment. As planners identify specific space tasks, they also develop measures of performance and measures of effectiveness to assess each task and objective. Space operations assessment informs the decision-making process concerning the best way to employ and adapt limited resources in support of military operations.

TA1: Identify non-traditional phenomenologies that can be used to perform SDA collections. Investigate the technical challenges to exploiting the data from non-traditional phenomenologies for real-time SDA. Identify a collection strategy. Identify the benefits of leveraging the non-traditional phenomenology to complement and improve traditional phenomenologies. Define specific performance metrics and demonstrate how the approach enhances the defined metrics for tracking and characterizing targets. The offeror is expected to include a detailed plan outlining the development, testing, and integration of the proposed solution, including specific timelines and milestones. GFE will not be provided.TA2: Design a concept for a workable and scalable prototype to address the basic capabilities and technical feasibility of the stated objective as well as data and information sources and the timeliness of their solution. Identify non-traditional phenomenology and data sources. Define a set of metrics and success criteria for a Phase 2 prototype. Include detailed findings in a Phase II plan in the final report. GFE will not be provided

TA1: Research and develop technical solutions to address the technical challenges of the non-traditional phenomenology identified in the Phase I effort. Develop and demonstrate a simulation capability to generate simulated data for the non-traditional phenomenology. Perform SDA collections with the nontraditional phenomenology and investigate the collected data. Develop a framework for processing of the non-traditional phenomenology. Develop a methodology to perform data fusion of the non-traditional phenomenology with traditional phenomenologies. Demonstrate an integrated prototype system or incorporation of new phenomenologies into an existing system. Demonstrate the ability to generate actionable information on relevant timelines through a simulation or deployment to a relevant environment. GFE will not be provided.TA2: Develop, implement and test the proposed Phase 1 solution as prototype software to assess space operations using multi-INT multi-domain data and information in a timely manner in response events of interests and unintentional threats and their effects on space missions. Show the feasibility of the approach using modeling simulation and real-world data. GFE will not be provided.For both Success criteria for Phase II include:- Demonstrated software prototype capability. Demonstration will be measured against metrics and CONOPs use case.- Ability to integrate outputs into operational workflows with minimal burden on users.- Achievable path to Phase III transition, including identification of customers, funding mechanisms, and required approvals

Further develop and deploy the prototype capabilities developed under Phase II. Develop a strategy to transition prototype residual capabilities and incremental proliferation based on operational USSF requirements. Mature prototype software into a commercial product for commercial SDA. Identify government and commercial organizations for transition. Generate the technical and training documentation required for third party integration. Provide services to the government to maximize the utility of the alerts to operations. Provide services to the government to update software prototype for different applications. This topic promotes dual-use opportunities to provide health and operational status of commercial satellites and their services in relation to adversaries’ actions.

The solicitation instructions state the page limit for the technical volume is 10 pages. However, the DoD STTR FY26 SpaceWERX Topics--SBIR/STTR PHASE I PROPOSAL TEMPLATE states: “Content is bound to the designated page(s) as indicated on the Table of Contents. Page numbers and content should be adhered to and NOT changed." And this goes up to page 13. So are we bound to the designated pages as indicated on the Table of Contents in the proposal template, or can we ignore the existing page numbers in the Table of Content?

Small businesses are expected to follow the SBIR/STTR PHASE I PROPOSAL TEMPLATE and the page length should not exceed 13 pages. 

For TA2, does the Government envision the technical challenge as including the architecture required to ingest, synchronize, maintain provenance of, and make distributed multi-INT/multi-domain data available to analytics in a timely manner, including when data sources are geographically or operationally distributed and potentially intermittently connected?

Yes.

Can or should the TA1 collection and processing architecture leverage commercially hosted space assets or other commercial space infrastructure for onboard/edge processing, particularly where processing closer to collection could reduce data movement and accelerate delivery of actionable information to operational C2?

Yes.

For TA1, does the technical scope extend beyond the non-traditional sensor/phenomenology itself to include distributed or edge processing, data management, and dissemination required to convert collected data into actionable SDA information on operationally relevant timelines?

Yes.

For TA2, does the Government envision the primary technical challenge as developing new analytics/fusion algorithms, or does it also include the architecture required to ingest, synchronize, maintain provenance of, and make distributed multi-INT/multi-domain data available to those analytics in a timely manner?

This decision is at your discretion and should be addressed in your proposal. The government is looking for new ideas and solutions to the problem space and does not provide a definitive approach or solution.  It is incumbent upon the offeror to define an approach to meet the objectives.

The description notes that planners develop measures of performance and effectiveness, and that assessment compares forecasted outcomes to actual events. Should TA2 assume those forecasts and measures are available as inputs, or should the concept generate the expected baseline itself?Does "dynamic command and control" in TA2 include recommending collection or retasking, or is it limited to providing assessments to C2?Should the concept assume processing happens centrally, or is processing at or near the sensors expected? Is there an existing system or SDA data standard that outputs should integrate with?

For all 3 questions: This decision is at your discretion and should be addressed in your proposal. The government is looking for new ideas and solutions to the problem space and does not provide a definitive approach or solution.  It is incumbent upon the offeror to define an approach to meet the objectives. 

Is a small business permitted to submit two separate proposals under this solicitation, with one proposal focused on TA1 and the other focused on TA2?

Small businesses are permitted to submit 2 separate proposals (one proposal per TA). However, offerors are strongly encouraged to select one TA for which they are best qualified and suited to perform the required work.

For Technical Area 1, does “non-traditional phenomenology and collection approaches” include a proliferated, geographically distributed network of heterogeneous commercial optical sensors (e.g., wide-field optical sensors and astronomical telescopes) used collectively as a new collection architecture? Or is TA1 intended specifically for sensing phenomenologies that are fundamentally different from conventional electro-optical observations? If the individual sensors use conventional optical phenomenology but the innovation is in distributed collection, real-time fusion, anomaly detection, and dynamic sensor coordination, would that approach be more appropriately addressed under Technical Area 2?

These decisions are at your discretion and should be addressed in your proposal. The government is looking for new ideas and solutions to the problem space and does not provide a definitive approach or solution.  It is incumbent upon the offeror to define an approach to meet the objectives.

Are there restrictions on a company working as a prime or sub on two winning proposals, one for each TA?

A company can serve as a primary for their own proposal and can serve as a sub-contractor on another proposal as long as they have the bandwidth to perform each awarded contract.

Developing a general, effective, and robust antijamming framework for GPS signals is a problem of critical importance. This topic seeks proposals that utilize exceptional-point stochastic resonance and modern machine learning to overcome the vulnerabilities of GPS signals to strong adversarial jamming and spoofing. This will ultimately enhance the signal-to-noise ratio (SNR) for weak signals and maintain the operational readiness of the Air Force.

Military and commercial missions rely heavily on the Global Positioning System (GPS), but GPS signals, due to their weak intensity and their need to travel considerable distances, are vulnerable to external interference such as jamming and spoofing. Adversarial jamming can be strong in that its amplitude can be orders of magnitude larger than that of the GPS signal, and they share the same spectral band. Various methods based mostly on traditional signal-processing techniques, such as filtering or wavelet transform, were proposed to mitigate GPS jamming to a certain extent. Often, the effectiveness of a specific method depends on the type of jamming signals in terms of their waveform, amplitude, and frequency range. GPS antijamming is essentially a nonlinear signal prediction and classification problem. For nonlinear signal prediction, a possible solution is exploiting modern machine learning, where a suitable neural-network architecture trained with features of the desired signals views the jamming as undesired and removes them. However, the inevitable noise represents a difficulty when employing machine learning to predict the GPS waveform and navigation signal, which can significantly degrade the antijamming capability. In nonlinear dynamical systems, the counterintuitive phenomenon of stochastic resonance (references 1 & 3) has been well established, where the signal-to-noise ratio for a weak signal can be enhanced by tuning the noise amplitude. This opens the possibility of enhancing the GPS signal through the stochastic-resonance mechanism.

This is a Direct to Phase 2 (D2P2) topic. Phase I proposals will not be evaluated and Phase I awards will not be made under this topic.. The offeror is required to provide detail and documentation in the Direct-to-Phase-II (D2P2) proposal which demonstrates accomplishment of a “Phase I-type” effort, including a feasibility study. For this D2P2 topic, the offeror should have accomplished the following in a Phase I-type effort via some other means. The offeror must have developed a concept for a workable prototype or design to address at a minimum the basic capabilities of the stated objective above. Proposal must show, as appropriate to the proposed effort, a demonstrated technical feasibility to meet the capabilities of the stated objective. Proposal may provide example cases of this new capability on a specific application. The documentation provided must demonstrate that the offeror has developed a preliminary understanding of the technology to be applied in their Phase II proposal to meet the objectives of this topic. Documentation should include all relevant information including, but not limited to, technical reports, test data, prototype designs/models, and performance goals/results. Feasibility documentation cannot be based solely upon or logically extend from any prior or ongoing federally funded SBIR or STTR work.

In an era of critical GPS technology, the security and safeguard of satellite navigation signals are at the forefront of national and military interest. And, as GPS signals become more integrated into essential infrastructure, the growing vulnerability of adversarial jamming prompts the need to bolster GPS resilience with innovative proposals and cutting-edge research. Stimulating and supporting basic research for GPS antijamming efforts holds the promise to advance the technological capabilities and operational readiness of the Department of Air Force.Previous research explored the potential of higher-order exceptional points, uncovering a broad type of stochastic resonance where the system’s response to a signal is enhanced by the presence of noise. As the noise amplitude increases, the SNR reaches a global maximum, suggesting that higher order exceptional points can sustain high performance over a wide range of noise levels. The ability to achieve a high SNR with minimal performance decay paves the way for the development of robust and reliable signal processing and sensor technology.Proposals in antijamming and counter measuring GPS technology would exploit the exceptional-point features design for the development of next generation sensors and communication systems both sensitive and resilient to GPS disruptions and jamming. In signal processing paradigms, robust systems that maintain high quality signal transmission, in the presence of adversarial interference, drives innovative solutions for the challenges and needs of the Department of Air Force’s operational readiness.The technical merit of GPS antijamming research lies in the adaptability and efficiency of integrated sensing and cyber capabilities that remain robust under varying noise and interference levels. This would directly enhance the operational readiness and technological capabilities of the Department of Air Force, and the warfighter. Offeror must develop and demonstrate a user-friendly computer program prototype that can be inserted into a GSP anti-jamming system.

The integration of higher-order exceptional features into commercial technologies offers the promise of reliable, efficient, dynamical systems across a broad spectrum of industrial and military processes. In industrial sectors like manufacturing and logistics, efforts would improve the resilience of sensors, ensuring that they remain responsive and resilient to external interferences.Potential research would also address the critical DoD areas in weak signal processing; a facet central to the GPS. Extracting weak signals in strong jamming/noise is a poised challenge to the GPS, magnetometer and numerous communication systems significant to commercial and DoD domains. Successful research in this domain promises the protection of aircraft and long-range vehicle capabilities, particularly in enhancing the accuracy of flight data, reduction of signal disruption risks and advancement of autonomous flight systems in the aerospace ecosystem.As these advancements are realized, aircraft would adapt swiftly to changes in signal processing flight conditions, enhancing the overall readiness of flight operations: protection of commercial airline usage of GPS.

The objective of this research effort is to design, develop, and demonstrate an Artificial Intelligence (AI) Performance Evaluation Tool that streamlines, standardizes, and enhances the evaluation of AI-enabled systems across various operational conditions. This Phase I STTR effort will focus on exploring innovative methodologies to quantify the performance, reliability, and robustness of AI models, particularly in applications related to sensors and information systems within the test and evaluation missions of the Air Force Test Center (AFTC). To demonstrate early-stage feasibility, the proposed tool must be capable of evaluating AI-enabled sensor suites (e.g., EO/IR, Radar, and Radio Frequency systems) and align with AFTC’s primary simulation and digital engineering environments, such as the Advanced Framework for Simulation, Integration, and Modeling (AFSIM), Ansys Test and Evaluation Tool Kit (TETK), or the Joint Simulation Environment (JSE).By addressing critical gaps in assessing AI robustness under dynamic and contested conditions—including real-time inference latency, adversarial resilience, and data drift detection— the effort aims to establish early-stage feasibility for an adaptive framework capable of identifying key performance indicators (KPIs), assessing trustworthiness through explainability metrics, and ensuring compliance with evolving Department of Defense (DoD) AI standards, such as those delineated in the DoD Responsible AI Strategy and Implementation Pathway. This tool will be designed to integrate seamlessly with the current test environment of the 412th Test Wing and support Operationally Focused Advanced Battle Management System (ABMS) initiatives by providing actionable insights that enable faster and more informed decision-making processes. Phase I will emphasize technical innovation, feasibility validation, and initial use-case alignment to ensure the framework’s scalability and adaptability for Phase II development and field-level implementation. The alignment of the initial use case must specifically demonstrate how the proposed evaluation tool will ingest AFTC-representative sensor data to ensure the framework’s scalability and adaptability for Phase II development. The overarching goal is to accelerate the operational utility and trusted deployment of autonomous and AI-driven systems in support of Air Force modernization priorities while improving mission readiness and capability sustainment.

The proposed research effort aims to address critical gaps in the evaluation and validation of Artificial Intelligence (AI) systems within the Air Force by developing an Artificial Intelligence Performance Evaluation Tool. The tool will provide a standardized, adaptive, and robust framework capable of assessing the performance, reliability, and explainability of AI models, with a targeted application in sensor and information systems used in test and evaluation missions under the 412th Test Wing (412TW) of the Air Force Test Center (AFTC). This effort aligns with the Department of Defense's (DoD) thrust toward advancing Trusted AI and Autonomy and operationally focused Advanced Battle Management System (ABMS) initiatives. Problem/Unmet Need: Current AI evaluation processes lack standardization and reproducibility across varying operational environments, making it difficult for the AFTC to confidently assess AI models’ trustworthiness, reliability, and operational readiness. Furthermore, the escalation in complexity of AI-enabled systems has underscored the need for technologies that can quantitatively measure AI performance while adhering to DoD Responsible AI principles. These challenges prevent the Air Force from leveraging AI advancements at scale, impacting readiness and modernization goals. Opportunity/Desired Outcome: By creating a modular AI evaluation tool, this effort provides an opportunity to establish a scalable and adaptable solution that aligns with emerging DoD AI standards. The desired outcome is a measurable enhancement in the fidelity, speed, and consistency of AI performance assessments, reducing decision-making cycles and increasing mission readiness. The tool will enable practical implementation of AI validation in secure environments, ensuring compliance with applicable standards and operational conditions. Successful deployment will support the broader modernization priorities tied to mission-critical AI deployment and advanced autonomy. Approach The project will begin in Phase I with baseline research and feasibility studies, advancing into a scalable prototype in Phase II for integration and testing in operationally relevant environments. A summary of planned efforts by phase follows: Phase I: Feasibility and Concept Development (Initial TRL: 2; Target TRL: 4) Research: Conduct an initial landscape analysis of AI performance metrics, methodologies, and tools with a focus on gaps and challenges specific to AFTC’s mission space. Identify and assess algorithms for measuring real-time inference latency, adversarial resilience, and data drift specifically for different sensor models. This research must establish and utilize open-source or synthetically generated surrogate sensor datasets that are representative of AFTC flight test scenarios.Framework Design: Develop a software architecture for an adaptable AI performance evaluation framework designed to address reliability, robustness, and explainability metrics. Awardees will need to base their design on widely accepted DoD digital engineering and telemetry standards. The architecture must explicitly define the assumed data ingestion pipelines for surrogate sensor data and detail the computational methods that will be used to calculate reliability, robustness, and explainability metric.Simulation: Perform initial simulation tests to explore early-stage integration of explainability metrics and KPI identification methodologies. This will consist of running dry-runs within a localized software sandbox. The objective of these tests is to demonstrate that the proposed mathematical models can successfully process these inputs, identify Key Performance Indicators (KPIs) such as data drift, and output quantifiable explainability scores.Deliverables: A feasibility report describing how the tool can practically operate within the AFTC environment, a detailed framework design document, and initial simulation results demonstrating concept validity. This could include Surrogate Data Strategy and Baselining, algorithmic and mathematical validation, architectural alignment and computational overhead, and Phase II scalability and transition pathway.Phase II: Prototype Development and Validation (Initial TRL: 4; Target TRL: 6) Prototype Development: Build a functional prototype of the performance evaluation tool with a secure Python-based backend and a user-friendly Graphical User Interface (GUI). Integration: Test and integrate the tool with existing sensor and information systems in a controlled 412TW test environment to assess real-world performance. AI Metrics Library: Develop an expandable library of explainability metrics aligned with DoD Trusted AI standards to support diverse mission applications. Validation: Conduct comprehensive testing in operationally relevant scenarios to ensure reliability, scalability, and compliance with DoD standards. Deliverables: A fully functional prototype, test reports validating system performance, and a roadmap for field-level deployment. Conclusion This effort supports the Air Force’s operational imperatives by advancing capabilities for trustworthy AI deployment in mission-critical applications. Upon completion of Phase II, the AI Performance Evaluation Tool is expected to reach TRL 6, with a clearly defined transition pathway toward operational implementation across the 412TW and other DoD components. This innovation is anticipated to significantly enhance the Air Force's ability to validate AI systems, improve decision-making confidence, and maintain technological superiority in contested environments.

Phase I will establish the project's feasibility and lay the foundational groundwork. Key activities will include: Detailed Analysis: Conduct a comprehensive study of current flight test analysis workflows to identify specific bottlenecks, constraints, and user requirements. Architectural Design: Develop a detailed hardware and software architectural design that emphasizes modularity, security, and Python-based extensibility. Core Algorithm Prototyping: Develop and simulate proof-of-concept algorithms for automated metric generation and data processing. Feasibility Report: Deliver a final report summarizing findings, the complete system design, simulation results, and a detailed plan for the Phase II prototype development.

Phase II will focus on the creation and rigorous testing of a fully functional prototype in a controlled environment. Prototype Development: Build the integrated software application, including the graphical user interface (GUI), data analysis engine, and the AI-powered report generation module. Lab-Based Testing: Establish a reference system in a secure, closed-loop environment to conduct extensive testing. Performance Validation: Evaluate the prototype against a comprehensive set of metrics, including: Time Space Position Information (TSPI) processing accuracy. Comparative analysis against legacy methods. Integrity of automated report generation. System security and resilience against simulated threat/victim scenarios. Demonstration: Conclude with a successful end-to-end demonstration of the prototype's capabilities, proving its readiness for transition to a real-world operational testing environment.

The 416th Test Squadron at Edwards Air Force Base, which specializes in F-16 flight testing and has a history of integrating advanced systems, will serve as the dedicated transition partner for this effort. Our commercialization strategy is multifaceted: Productization: Refine the successful Phase II prototype into a robust, user-friendly, and cost-effective commercial product. User-Centric Feedback: Conduct extensive operational testing with the 416th Test Squadron and other target users to gather feedback for iterative product improvements. Dual-Use Applications: While the primary customer is the DoW, we will explore dual-use applications for commercial aerospace, avionics testing, and other sectors that require complex data analysis. Infrastructure and Support: Establish comprehensive manufacturing, customer support, and training infrastructure to ensure a smooth and successful transition from a prototype to a fully supported operational tool that will revolutionize flight test analysis.

The topic lists initial simulation results demonstrating concept validity among Phase I deliverables, while the Q&A says Phase I is a roadmap and a demonstration is not required. For end-of-Phase-I acceptance, are a detailed design and feasibility roadmap sufficient, or are documented algorithm and surrogate-data simulation results required?

Please find below our questions regarding DAF26TZ06-NV006:Would spacecraft or satellite telemetry be acceptable as a surrogate dataset for demonstrating Phase I feasibility, particularly for capabilities such as telemetry anomaly detection, data-drift detection, automated performance metrics, and explainability? If so, what evidence would be needed to demonstrate its relevance to AFTC flight-test requirements, and would a separate radar-specific demonstration still be expected?For a team with NASA-funded experience in spacecraft health monitoring, telemetry analysis, and anomaly detection, what evidence would best demonstrate the relevance of this prior work to the proposed radar flight-test application? Which radar-specific capabilities would the Government expect the team to establish during Phase I?May Phase I build upon existing sensor analytics, telemetry analysis, and anomaly-detection software, with the proposed research focused on new radar-specific evaluation methods, robustness testing, explainability, and automated performance assessment? How should proposers distinguish existing capabilities from the technical innovations proposed under this effort?For anomalies such as track drops and false-alarm-rate deviations, would the Government value a capability that goes beyond detection to provide confidence estimates, evidence-based explanations, root-cause indicators, and prioritization for engineer review? Which of these capabilities would be most valuable to demonstrate during Phase I?Which radar anomalies, data-quality issues, and changes in operating conditions should Phase I surrogate datasets capture? What validation evidence would demonstrate that results obtained using synthetic, open-source, spacecraft, or other surrogate telemetry are representative of actual flight-test analysis needs?Are locally hosted generative AI or machine-learning models acceptable for automated report generation within the required secure, non-networked environment? If so, what level of traceability from AI-generated findings back to the underlying measurements, metrics, and engineer review is expected?Thank you for your time and guidance.

It is fine to use non-terrestrial systems data surrogate to mimic the topic proposal. It is always nice to see the system as part of the presentation/proposal write up but we do understand since we cannot release data other creative ways are needed. Phase I is feasibility, a roadmap to success should be drafted.Any work with the APG-83 or airborne radar systems in general. Typical radar metrics such as weapons quality track, single/multi-tracks, ground tracks, etc. will need to be presented.Yes, phase I may build on existing analytics and methods. AI is the focus on this topic and the performance enhancements they have the potentials to provide, to include accuracy, speed, and efficiency. We will not reject added capabilities. There is no single capability more important than the other. We do not require a demonstration, only a roadmap. But, we will willing to accept a demonstration, measurements, lab setups, etc.  Capture all. TSPI is the source of truth data currently used. Since we cannot provide data, synthetic data is allowed as a truth data and impairments injected into performance data. The focus of this topic is how accurate and efficient is the AI.This is an unknown. For phase I develop your roadmap and plan. There will need to be cyber and hardware defined before anything is actually implemented. Phase II will focus on prototyping and operate within it's own stand-alone environment. 

Please find below our questions regarding DAF26TZ06-NV006. We would appreciate your guidance to help align our proposal with the Government’s priorities and Phase I expectations.Anticipated Awards. How many Phase I awards does the Government anticipate making under this topic, and how many follow-on Phase II awards are expected?Primary Technical Focus. How should Phase I balance evaluating the performance, reliability, and robustness of AI models with using AI to automate post-flight radar data analysis? Which capability should be the primary focus of the initial demonstration?Phase I Success Criteria. What minimum working functionality and quantitative results would demonstrate successful Phase I completion? Are there preferred benchmarks or acceptance criteria for metric accuracy, explainability, computational overhead, and improvement over existing analysis workflows?Data Standards and Reference Materials. Can the Government identify preferred telemetry standards, unclassified example data schemas, or reference outputs to guide the development of representative surrogate datasets?Extensibility Beyond Radar. How should proposals balance radar-specific functionality with reusable capabilities across EO/IR and RF sensor systems? What Phase I evidence would best demonstrate the value of an architecture designed to support additional sensor modalities and applications? 

Three awards for phase I will be approved. Phase II will have two awardees.Phase I is a roadmap. A demonstration is not required, but demonstrations, measurements, lab setups, etc. will not be rejected. Define your plan with detailed design and constraints.Above. TSPI data is used as truth data to evaluate performance. If is demonstration is done, using synthetic data as a truth source to evaluate the performance data is reasonable. We cannot provide any data or post-test reports for reference. Edwards AFB utilizes IRIG-106 standards for telemetry systems. Focus on radar. The long-term methodology is to create an enterprise with several applications. Radar happened to be the seed money as proof of concept. We want to focus on one thing at a time and expand into other analysis capabilities reasonably. 

The published topic describes an AI Performance Evaluation Tool applicable to representative EO/IR, Radar, and RF sensor suites, while the recent Q&A response describes a Radar Performance Flight Test Analysis Tool focused on post-flight radar telemetry and analysis. For Phase I, should offerors prioritize a radar-specific post-flight evaluation capability, or would a modular, Python-based AI evaluation framework that demonstrates the required radar use case while retaining extensibility to EO/IR and RF be considered responsive and potentially advantageous?

“Would a modular, Python-based AI evaluation framework that demonstrates the required radar use case while retaining extensibility to EO/IR and RF be considered responsive and potentially advantageous?”, yes this will apply. We are looking for a long term solution by starting starting with a seed application and want to grow eventually into an enterprise with environments/applications.

Will the government provide access to simulation environments such as AFSIM and TETK during Phase I for the performers to utilize in demonstrating the feasibility of their solution? If not, what is the government's suggested approach for the performers to demonstrate alignment with these existing simulation tools?

No, companies will need to furnish their own simulation environments. This proposal outlines the development of an innovative Radar Performance Flight Test Analysis Tool designed to leverage artificial intelligence (AI) creating an effortless analysis environment. The developed application will focus research and development test and evaluation (RDT&E) flight test. This tool will fulfill program requirements by executing post-flight analysis of high-volume radar telemetry, automating the generation of comprehensive post-flight performance reports, and conducting high-fidelity regression testing against historical baselines.  Our proposed solution is a comprehensive, user-friendly software tool featuring a Graphical User Interface (GUI).  Key features of this tool must include: • Secure, Non-Networked Operation: The tool is architected from the ground up to function entirely offline, ensuring the integrity and security of classified flight test data within secure, isolated processing environments. • Python Modifiability: The tool will be built on a flexible Python-based architecture, allowing for rapid customization and the integration of new analysis modules to address emerging threats and changing mission requirements. • Automated Metrics and Statistics: The software will automatically process measured input files to generate a wide range of performance metrics and statistical analyses, significantly reducing the time and effort required for data reduction and analysis. • AI-Powered Automatic Report Generation: Leveraging cutting-edge Artificial Intelligence (AI) and Machine Learning (ML) algorithms, the tool will automatically generate comprehensive and insightful reports. This will enable engineers and decision makers to quickly understand test results and make informed decisions. • AI-Powered post flight analytics: The tool will utilize machine learning models to conduct deep, non-real-time analysis of radar performance, automating the detection of anomalies, track drops, and false alarm rate (FAR) deviations that occur during flight tests.  

Develop a real time automated combat assessment at the edge system.

Combat assessment (physical and functional) provides tactically relevant information for re-strike and re-planning. The state of practice for traditional targeting involves generating after-action reports including battle-damage assessment hours after mission execution relying on multiple imagery collects (EO). This analysis is performed as a sequence of independent tasks that are outdated, time consuming, and lack automation. This does not meet timeline requirements for prosecution of advanced enemy threat systems as critical missions require battle damage assessment immediately post-strike, to inform planning for restrike and to drive potential changes to operations.Despite advancements in technology, challenges still remain for speeding processes such as time-consuming and often incomplete nature of traditional damage assessment methods, limitations in remote sensing technologies, hindering data collection especially in remote or difficult-to-access areas, the lack of real time pre- and post-event satellite imagery for model training. This topic seeks the development of a system for the automation of damage assessment following the below operational realities:- Edge Processing Software. Software programs and data-sharing instructions designed to run directly on physical field equipment such as sensors and drones. For multi-sensor, multi-modal data collection and processing, damage classification and assessment at the edge in (near) real time, and information sharing protocols under low SWaP and contested environments constraints.- AI/ML Software Model Development. AI/ML software designed to automatically classify military damaged. For damage classification (physical and functional) that is aligned to the CJCSI 3162.02 for DoD customers, confidence intervals aligned to the Intelligence Community Directive ICD 302, and performance metrics for accuracy, computation time, and sensors density & location.- Robust Testing and Evaluation. To ensure the operational effectiveness, suitability, and survivability of the aforementioned technologies, testing and evaluation would be conducted in a phased approach. Beginning with laboratory-based testing to verify basic functionality and performance, followed by increasingly complex testing in simulated and field environments. The goal is to ensure that the technologies developed for combat assessment are operationally effective, suitable, and can be confidently deployed in operationally relevant environments.

Phase I will focus on the analysis and design of an automated combat assessment at the edge system for re-strike (a particularly targeted asset) and re-attack recommendations with preliminary laboratory model testing. Awardees must demonstrate an innovative approach to physical and functional combat assessment, and novel or under-utilized data modalities. The final report must detail feasibility study findings and a Phase II plan.

findings and a Phase II plan.PHASE II: Develop, implement, test, evaluate, and demonstrate a distributed automated damage assessment system at the edge that follows the criteria on the Description and Phase I sections of this proposal. The final report must detail all criteria implementations and a Phase III plan.Phase II performance will focus on the development, integration, and operational evaluation of a functional prototype software system for distributed, edge-based automated combat assessment. Awardees will transition Phase I designs into working software models running on representative edge hardware, culminating in a demonstration within a simulated or operationally relevant environment.Required deliverables may include:Functional prototype software and compiled AI/ML model weights.Comprehensive system architecture and interface control documentation (ICD).Phase II final report detailing test results, performance metrics, criteria implementations, and a commercialization/transition plan for Phase III production and deployment.

The awardee will identify and pursue commercial applications, including urban surveillance, disaster and humanitarian response, and other use cases.

Beyond CJCSI 3162.02A and ICD 203 alignment, are there preferred functional-status categories or assessment-product conventions? Should preliminary testing explicitly evaluate insufficient-evidence outcomes, conflicting sensor observations, and confidence calibration?

CJCSI 3162.02A and ICD 203 provide the conventions we would like for the proposal. Insufficient-evidence outcomes can be described as low-confidence or likelihood as described in ICD 203. An explanation as to why those confidence values are low may be detailed if the developer so chooses. 

For Phase I feasibility, is measured profiling on representative low-SWaP hardware preferred, or are validated resource estimates and hardware-in-the-loop emulation sufficient? Should sensor-density and sensor-location sensitivity be demonstrated through laboratory experiments, simulation, or both?

The selection of the SWaP configuration, sensor’s density and location, and validation approach is on the proposer, but the proposal must address the near real-time damage assessment. 

Would an in-depth Phase I demonstration covering both physical and functional assessment for one representative target class be responsive, with generalization to additional classes addressed in the Phase II plan, or is preliminary testing across multiple target classes expected?

The selection of the use case(s) for Phase I and Phase II is up to the proposer. 

For Phase I preliminary laboratory testing, what evidence is considered sufficient to validate functional-damage assessments when direct operational ground truth is unavailable? Are documented SME adjudication and controlled simulations acceptable, provided observed physical damage is distinguished from inferred functional status?

If direct operational ground truth is unavailable the proposal is not addressing functional damage assessment in near real-time. 

Are there particular datasets, public benchmarks, or representative assessment scenarios you would recommend we consider for the Phase I feasibility study? We would welcome guidance on aligning our evaluation with the topic’s research priorities.With no government data provided, what independent evidence would make a feasibility demonstration credible?Is disaster assessment intended as a separate transition opportunity, an evaluation environment, or both?Which exact NGA and FEMA publications, editions, assessment categories, and output products should govern each mode?What hardware envelope and sustained workload define ‘at the edge’ for your evaluation?When you reference Directive 203, which analytic-confidence requirements and acceptance evidence do you expect?Which conclusions must remain human decisions, and what should happen when evidence is inadequate or a reviewer is unavailable?What has prevented earlier research demonstrations from becoming usable capabilities: data access, reliability, integration, compute, workflow, or another issue?Who owns technical acceptance, standards interpretation, user evaluation, and transition?What result would cause you to conclude that the proposed approach is not feasible?

1) No, we do not have a recommended dataset, public benchmarks, or representative assessment scenario for this topic. These will depend on the system/modality you are using.2) The evidence would be made alongside the dataset that would be made for the topic.3) Disaster assessment is not a part of this topic.4) There are no exact NGA or FEMA publications that should govern the mode.5) The hardware would depend on which sensors/platforms are used for data collection and processing.6) Any metrics stated in the ICD 203 would be accepted.7) The operator's decision-making should remain a human decision; the system should only be making recommendations. If the evidence is inadequate or a reviewer is unavailable, the system shouldn't do any more than produce its recommendations based on its data.8) In the past, the desire for a new system for CA was not needed, but now it has become a higher priority.9) This is only a capability concept, and AFRL will own it.10) Lack of available data, processing time taking longer than expected, and lack of sensor availability would cause us to conclude the approach not feasible.

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 section 3.5 of 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. Develop a reusable illumination system for high-speed photo-optic data collection used at the Holloman High Speed Test Track (HHSTT) and other sled test tracks.

The PF300 flash bulbs, that provide high-intensity illumination for high-speed video acquisition, are no longer in production. The objective is to award a contract to a small business to engineer, design, and manufacture a modern, robust, reusable replacement for the legacy PF300 flash bulb. This new system must meet or surpass the existing illumination and performance requirements of the original flash bulbs to ensure seamless integration with current high-speed video systems. The ideal solution would leverage Commercial Off-The-Shelf (COTS) or near-COTS technologies to qualify this project as a direct-to-Phase-II effort. A successful reusable replacement would immediately solve the impending obsolescence issue, securing a reliable illumination source for future missions. Furthermore, transitioning to a reusable system would dramatically reduce consumable cost. This technological update could also pave the way for enhanced capabilities, such as adjustable light intensity and longer duration illumination, offering greater flexibility and improved data quality for high-speed video analysis across various applications

As this is a Direct-to-Phase-II (D2P2) topic, no Phase I awards will be made as a result of this topic. Offerors must demonstrate completion of Phase I feasibility research and development that is not based upon or logically extend from any prior or ongoing federally funded SBIR or STTR work. Prior “Phase I-type” work by other companies has produced similar illumination methods, but not to the requirements needed to operate in the Test Track Environment. The technology exists, but the operating environment of the Test Track is unique enough there is not a readily available product. The Test Track is ready to define requirements up to, but not limited to illumination levels, illumination duration, connectivity and ruggedness.

The Phase II effort should develop a detailed design and operational procedures for a prototype reusable illumination system that meets requirements established by 846 TS Customers. Component level prototypes will be developed and tested to validate performance and mitigate risks prior to the development of the complete system prototype. The Phase II effort will culminate with the demonstration of an operational reusable illumination sled on the test track. The demonstration shall showcase the performance and reusability of the system.

The Phase III effort should further refine the illumination system design following lessons learned from the Phase II demonstration. The matured system should be ready for operational use at the HHSTT as well as other DoW test tracks. Phase III may involve follow-on non-SBIR/STTR funded R&D or production contracts for products, processes or services intended for use by the U.S. Government.

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 section 3.5 of 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. The objective of this Directed to Phase II (D2P2) SBIR effort is to develop an innovative, secure, and scalable solution for modernizing Technical Data Packages (TDPs) associated with complex Air and Space Force platforms. This initiative seeks to address challenges in managing large, diverse datasets by enhancing configuration control, ensuring data integrity, and strengthening Information Assurance (IA) in support of mission-critical operations. Specifically, the focus of this phase is to demonstrate the feasibility of advanced technologies that enable secure data lifecycle management and seamless data exchange within operational environments. Proposed solutions should align with Trusted AI and Autonomy modernization priorities by incorporating robust cybersecurity measures and leveraging cutting-edge advancements in autonomy, data management, and secure manufacturing capabilities. Outcomes of this phase are expected to validate technical concepts and establish a functional prototype that meets the operational imperative of readiness to deploy and fight, contributing to future scalability and transition opportunities in operational use cases.

Background and Problem Statement:The modernization of Technical Data Packages (TDPs) is imperative to address the Air and Space Force’s operational challenges in securely managing large-scale, complex datasets associated with advanced platforms and their sustainment life cycles. Current TDP systems often lack robust Information Assurance (IA) capabilities, seamless integration with Product Lifecycle Management (PLM) environments, and effective mechanisms for secure data exchange across operational networks. This limitation not only hinders data integrity and configuration control but also increases vulnerabilities to cyber threats, jeopardizing mission-critical operations. The rapid pace of platform evolution and the increasing reliance on Model-Based Definition (MBD) and digital twin technologies further exacerbate the need for a comprehensive solution that ensures TDP security, scalability, and operational readiness. Opportunity and Desired Outcome:This Directed to Phase II (D2P2) SBIR effort aims to develop an innovative, scalable, and secure solution to modernize TDPs to support the lifecycle of highly complex Air and Space Force platforms. The envisioned solution will integrate advanced IA protocols, cryptographic protections, and tools for encrypted data exchange to facilitate the secure management of the "as-sustained" configuration state of critical assets. The outcome will be a functional prototype capable of enabling secure TDP lifecycle management while aligning with the Trusted AI and Autonomy modernization priorities and Zero Trust Architecture principles. The proposed solution will enhance operational efficiency, minimize cyber risks, and establish a foundation for scalable implementation across DoD platforms. The project’s Technology Readiness Level (TRL) at the start is anticipated to be TRL 4, with the target of reaching a minimum TRL 6 by the conclusion of Phase II, including validation of core capabilities in a relevant operational environment. Required Efforts and Phase Activities:To achieve the stated objectives, the following efforts and activities are required for each phase of the project: Phase II:Develop a secure visualization tool for displaying large-scale MBD geometry and associated data through encrypted web-based interfaces.Implement an encrypted configuration management system to maintain and update the "as-sustained" asset state while ensuring strict data integrity.Create advanced tools for automated data quality checks, incorporating rules-based IA compliance validation to ensure all TDPs meet security and contractual requirements.Design an end-to-end encrypted exchange framework for TDPs, incorporating user authentication, authorization, and audit trails while conforming to DoD Zero Trust Architecture guidelines.Integrate AI/ML methodologies to enable secure damage detection, sustainment planning, and actionable insights into asset health.Demonstrate the prototype in an operationally relevant environment, proving feasibility, security compliance, and system performance in handling large and diverse data streams. Minimum Deliverables:A secure web-based MBD visualization prototype capable of rendering large-scale geometry and TDP datasets with sub-second response times and role-based access controls.Tools for encrypted configuration management and secure "as-sustained" state maintenance, integrated with PLM systems.An automated framework for data quality checks and IA compliance validation of TDPs using defined security protocols and rules-based engines.A cryptographic data transfer and exchange framework, with test results demonstrating alignment with DoD security policies and successful inter-organizational data exchange.Technical documentation detailing methodologies, system architecture, and IA protocols implemented during the project, including recommendations for further scaling and operationalization.A transition plan for integrating the developed TDP modernization technology into operational environments within the Air and Space Force platforms, supported by a detailed commercialization strategy aligned with mission needs.  Significance and Contribution to DoD Objectives:The proposed solution directly addresses the Operational Imperative 7—Readiness to Deploy and Fight—by delivering secure and reliable tools for managing critical asset data. The project also supports the DoD’s Trusted AI and Autonomy priorities by incorporating advanced data protection mechanisms, secure autonomous processes, and scalable solutions for data management across platforms. Successful execution of this effort will enhance the DoD’s ability to maintain readiness, ensure data security, and streamline collaboration with stakeholders while safeguarding sensitive information in a rapidly evolving threat landscape.

As this is a Direct-to-Phase-II (D2P2) topic, no Phase I awards will be made. Offerors must demonstrate completion of Phase I feasibility research and development that is not based upon or logically extend from any prior or ongoing federally funded SBIR or STTR work, demonstrating clear technical merit, alignment with Trusted AI/Autonomy priorities, and DoD Zero Trust standards, such as validated data, performance metrics, technical reports, prototype success, or demonstrated capabilities in relevant operational environments.

The Phase II effort will deliver a secure, scalable prototype for modernizing Technical Data Packages (TDPs). Focus areas include encrypted configuration management, MBD visualization tools, automated IA compliance frameworks, and secure data exchange via Zero Trust Architecture. The solution will achieve TRL 6 with validated performance in operational environments, aiding readiness and alignment with Trusted AI and Autonomy priorities.

The Phase III effort will advance the secure TDP modernization prototype to TRL 8, employing non-SBIR funds to integrate with Air and Space Force systems. Military applications include secure lifecycle management of technical data for advanced platforms, enhancing readiness and cybersecurity. Commercial use spans aerospace, manufacturing, and defense industries for data security and configuration management. Transition efforts target expanded adoption within DoD and allied partners.

The Department of the Air Force seeks to establish the domestic production of ultra-high temperature ceramic (UHTC)-yielding preceramic polymers. UHTCs are used for demanding aerospace applications, including propulsion and aeroshell components.

The scaled production of C/C-UHTCs composites (UHTCMCs) for defense applications requires the manufacturing of UHTC precursors in quantities sufficient to support acquisition programs. This SBIR will establish production of an AFRL-patented UHTC preceramic polymers so that the materials are available, at scale and affordable price point, to the high-temperature composite production community.

This topic is intended for technologies ready to move directly into a Phase II program. As this is a Direct-to-Phase-II (D2P2) topic, no Phase I awards will be made. Offerors must demonstrate completion of Phase I feasibility research and development that is not based upon or logically extend from any prior or ongoing federally funded SBIR or STTR work. Offerors must provide detailed documentation in their Direct to Phase II (D2P2) proposal that demonstrates the successful completion of a "Phase I-like" effort. This includes a feasibility study showing expertise in synthesizing and handling air/water-sensitive chemical compounds. Demonstrated experience in scaling chemical synthesis processes from the lab to pilot scale (e.g., 5-50 kg batches) is required. The feasibility study should clearly illustrate past successes in producing high-purity materials and a foundational understanding of the safety protocols necessary for handling the relevant precursors and reagents.

During the Phase II program, the awardee shall: 1) Establish and document a safe, robust, and scalable chemical process for the manufacturing of the AFRL-patented UHTC-bearing preceramic polymers that meets specified purity and production volume targets. 2) Conduct a thorough safety and handling analysis for all reagents, intermediates, and waste products. Production facilities must ensure safety and environmental compliance are permissible. 3) Deliver a 5x 1 kg samples of the UHTC preceramic polymer to AFRL for internal analysis, characterization, and quality verification. The offeror shall show i) for the produced polymer: NMR, elemental analysis, rheology, and ICP/MS of the produced polymer and ii) for the polymer-derived ceramic XRD, TEM/EDS, and SEM analysis, for each lot of material made. The offeror can assume a cost of $6300/kg in raw material cost if reagents, were to be purchased from commercial chemical suppliers, to produce UHTC preceramic polymers. 4) Establish and demonstrate a dedicated production capability yielding at least 50 kg per month (>600 kg per year). 5) Deliver a total of 75 kg of the qualified UHTC preceramic polymer, appropriately packaged, to the Government by the end of the Phase II effort. 6) Provide a comprehensive cost analysis and business plan for UHTC-bearing preceramic polymer production at the target scale of >1000 kg/year a target retail price of <$5000/kg, preferably <$4000/kg, identifying key supply-chain or processing factors to drive down per-kilogram costs.

The awardee will be expected to transition the preceramic polymer production established during Phase II into a viable commercial business unit. This will involve supplying certified preceramic polymers to prime contractors and Tier 1/2 composite manufacturers supporting defense and commercial programs of record. Phase III efforts may include further scaling of chemical operations, qualifying the material across a broader vendor base (for high-speed aeroshells), and establishing long-term supply agreements to support critical national security missions.

Develop and demonstrate a rugged, kilowatt class 2-micron fiber amplifier module that matches size, weight, and power metrics of state-of-the-art 1-micron systems to accelerate the transition of laboratory technology to operational Department of the Air Force capabilities.

High-power fiber lasers operating in the 2-micron regime offer critical advantages for defense, medical, and industrial applications, including eye-safer directed energy, advanced sensing, and precision materials processing. While kilowatt-class, narrow-linewidth thulium-doped fiber amplifiers have been demonstrated, the Department of the Air Force aims to reduce the size and weight of existing kilowatt-class 2-micron fiber amplifiers into a highly compact system with similar size, weight, and power metrics of existing 1-micron fiber amplifiers. This topic seeks to leverage existing Air Force laboratory architectures to prime industry for production of robust 2-micron fiber amplifiers, paving the way for transition into active directed energy programs.

This topic is intended for technologies ready to move directly into a Phase II program. As this is a Direct-to-Phase-II (D2P2) topic, no Phase I awards will be made. Offerors must demonstrate completion of Phase I feasibility research and development that is not based upon or logically extend from any prior or ongoing federally funded SBIR or STTR work. Applicant(s) should provide documentation demonstrating a clear understanding of high power, 2-micron fiber amplifier design, thermal management in constrained operating spaces, and package ruggedization for high-stress environments. Qualifying 'Phase I-type' efforts would include but not limited to the prior design, development, and demonstration of low SWaP, kilowatt-class, 1-micron fiber amplifier modules.

In Phase II, the USAF requires the execution, physical build, and delivery of a fully functional, low SWaP, 2-micron fiber amplifier prototype. This system must deliver kilowatt-class output while complying with the mandatory low-SWaP requirements of state-of-the-art 1-micron fiber amplifiers. The delivered hardware must undergo laboratory verification to validate output power (> 1 kW), beam quality (M2 < 1.2), spectral stability, narrow linewidth (< 5 GHz), and electro-optical efficiency (E-O > 25%). Final deliverables for this effort must include the physical prototype, complete electrical and optical schematics, and a comprehensive test and characterization report.

Phase III success will be driven by transitioning the 2-micron fiber amplifier design into full-rate production and securing commercial market pathways.Additionally, work on the system-level integration of the proven 2-micron fiber amplifier into a deployable, multi-kW laser defense system for real-world environmental validation.

Develop and demonstrate a modular, agile robotic manufacturing workcell capable of autonomously routing, aligning, inserting, and verifying flexible, non-rigid wire harnesses and electrical connectors within the highly constrained physical geometries of Unmanned Aerial Systems (UAS) and advanced munitions.As a Direct-to-Phase-II (D2P2) topic, the immediate goal is to transition a validated proof-of-concept software and mechanical baseline (Technology Readiness Level 4) into fully integrated, operationally viable production workcells evaluated at defense prime contractor manufacturing sites. The system must eliminate the need for hard-tooled, single-product automation by delivering an agile platform that integrates deterministic planning models with real-time, adaptive online sensory feedback. This enables the robot to navigate the unpredictable, non-rigid deformation behaviors of flexible cabling, achieve sub-millimeter positioning tolerances, and safely execute intricate "blind-mate" connection sequences within tight bulkhead quarters without manual intervention.To support a dynamic, high-mix/low-volume defense production environment, the workcell must be designed for rapid retaskability. Offerors must demonstrate a system architecture that allows shop-floor operators to completely retask the workcell to handle an entirely different munitions or UAS harness family within a single eight-hour shift. Furthermore, the platform must establish the first end-to-end digital thread for harness operations, generating machine-readable traceability records for every routing, tensioning, and insertion step to prevent latent defects and ensure 100% military standard compliance.The ultimate phase outcome must demonstrate a two-to-four-times cycle time improvement over legacy manual wiring techniques and a reduction in skilled labor hours per unit by at least 50%. This will directly remove the primary assembly bottleneck constraining the scale-up, surge capacity, and high-rate production of critical defense systems.

Context & BackgroundModern Department of Defense (DoD) manufacturing and depot sustainment environments increasingly depend on agile automation to scale up production and maintain rapid operational readiness. While automated assembly technologies have matured substantially for rigid components with predictable geometries, the handling of flexible materials remains a persistent challenge. Specifically, wire harness routing, connector inspection, and insertion operations are ubiquitous across the production lines of Unmanned Aerial Systems (UAS), advanced munitions families, and autonomous collaborative platforms. Currently, these intricate electrical assembly processes represent a bottleneck in UAS assembly operations. Assembly technicians must manually route non-rigid cables through confined structural cavities and execute high-precision connection steps under high-mix, low-volume production conditions. Traditional industrial robotics break down when tasked with these operations because flexible wiring deforms unpredictably during manipulation, completely violating the rigid-part assumptions and fixed, hard-tooled rules of standard automation. Problem, Opportunity, & Unmet Need The complete reliance on manual wire harness installation creates a critical capability deficiency that severely penalizes DoD manufacturing agility and surge capacity. Manual operations are fundamentally non-scalable, meaning production lines cannot dynamically "ramp-to-rate" to meet sudden spikes in theater demand. Furthermore, manual wire routing and insertion introduce human-induced variability, resulting in unquantifiable defects such as partially seated connectors, overstressed wires, or compromised bend radii. These latent defects frequently slip past standard visual inspections and surface as catastrophic electrical or communication failures during critical mission times. Aerospace prime contractors and program offices have identified this manual chokepoint as the largest automation gap in UAS and munitions production. This deficiency creates a major opportunity to implement a flexible automation solution. Resolving this challenge requires a modular, adaptive robotic workcell that handles deformable materials, operates with high positional accuracy in restricted footprints, and can be rapidly retasked between completely different product designs within a single factory shift. Desired Outcome & Technological Improvement The desired outcome of this research and development effort is a fully integrated, single-arm modular robotic manufacturing workcell capable of autonomously handling the core manipulation and installation scenarios for flexible UAS and munitions wiring harnesses. Shifting the technology from manual assembly to adaptive, sensor-driven automation will fundamentally advance the DoD technological state of the art by achieving the following targeted improvements: Deformable Material Control: The platform will combine deterministic offline path planning with adaptive, real-time online sensory feedback (such as tactile, force-torque, and vision monitoring). This closed-loop configuration enables "search and settle" machine behaviors to dynamically correct for micro-misalignments and part variability on the fly. Sub-Millimeter Tolerances: The workcell will successfully execute precise connector insertion and blind-mate assembly steps within tightly constrained geometries to a targeted positioning tolerance of $\le$ 0.5 mm.Rapid Retaskability: The system will break the paradigm of dedicated single-product manufacturing by allowing shop-floor operators to ingest new geometric data and completely retask the workcell to a novel harness family in less than 8 hours.End-to-End Digital Thread: The workcell will generate machine-readable traceability records of every insertion force profile and routing path. This delivers a reliable data audit trail to eliminate quality escapes and predict latent field defects before they manifest in flight.Minimum Acceptable DeliverablesThe following deliverables must be successfully turned over to the government to satisfy the performance requirements of this solicitation:Integrated Single-Arm Robotic Workcell: One fully functional, operational modular automation cell comprising a COTS collaborative arm manipulator, reconfigurable mounting base, interchangeable end-effectors, integrated real-time compute block, and the complete multi-modal sensor stack (vision, tactile, and force-torque instrumentation). Autonomous Software Stack & Executables: Full, unencumbered delivery of the native software architecture, including the offline CAD data-ingestion pipeline, real-time adaptive control algorithms, and localized vision-tactile tracking scripts, along with complete integration documentation.Cross-Program Retasking Report: A documented technical package demonstrating the step-by-step procedures, software tools, and data workflows used to successfully transition the physical workcell between two distinct harness families in less than 8 hours.Comprehensive Technical Data Package (TDP): System layout schematics, wiring diagrams, universal end-effector interface control documents, operational manuals, and interface guides for MES/ERP factory network synchronization. Final Performance & Verification Report: A verified engineering data package from the live prime facility demonstration detailing empirical success metrics. This must validate insertion position accuracy ($\le$ 0.5 mm), insertion force variance curves, production cycle time gains ($\ge$ 2x throughput), labor hour compression ($\ge$ 50%), and a sample data pull of the machine-readable digital thread registry.

As this is a Direct-to-Phase-II (D2P2) topic, no Phase I awards will be made as a result of this topic. To qualify for this D2P2 topic, Offerors must demonstrate completion of Phase I feasibility research and development that is not based upon or logically extend from any prior or ongoing federally funded SBIR or STTR work. Applicant(s) should provide documentation demonstrating a clear understanding of the mechanical handling of flexible materials, single-arm robotic kinematics, deterministic offline tool-path planning, hybrid position/force control loops, multi-modal sensor fusion (vision, force-torque, and tactile feedback), and the implementation of a machine-readable digital thread within restricted weapon and unmanned system assembly architectures.Phase I Feasibility Context & Technical GoalsFor the context of this technology's lifecycle, a traditional Phase I feasibility study represents a focused research and development effort to demonstrate the scientific, technical, and commercial merit of an automated single-arm robotic solution for non-rigid material manipulation. A successful Phase I Period of Performance establishes a baseline across the following specified technical goals, operating parameters, and functional requirements:Deformable Material Kinematics: Analytical and simulation validation proving that a single collaborative robotic manipulator arm can grasp, lift, and maneuver flexible wire harnesses without causing structural damage, violating minimum bend radii, or exceeding maximum cable strain limits. Confined Space Operating Parameters: System modeling showing the capacity for a robotic arm to navigate and thread cabling through tight apertures and restricted structural bulkheads typical of unmanned aerial systems and compact missile fuselages. Closed-Loop Alignment Logic: Verification of multi-modal tracking logic that utilizes localized computer vision and tactile feedback to continuously calculate micro-adjustments, allowing the arm to align electrical connectors under dynamic part deformation. Compliant Mating Force Boundaries: Formulation of hybrid position/force control profiles that maintain sub-millimeter insertion accuracy while monitoring force thresholds to detect pin engagement and prevent over-force structural damage. Traceable Digital Logging: Drafting a localized data logging schema capable of recording physical insertion forces, path coordinates, and connector seating confirmations to create an immutable digital thread registry.Successful completion of these Phase I parameters provides a clear, quantitative understanding of the underlying physics and control logic governing non-rigid material manipulation, proving the system is ready for immediate physical hardware-in-the-loop integration.Required Feasibility Documentation for D2P2 QualificationTo bypass a traditional Phase I award and qualify for this Direct-to-Phase-II pathway, applicants must submit robust, empirical Feasibility Documentation within their proposal. This package serves as the technical justification proving the small business's technology has already retired early-stage conceptual risk and rests at an acceptable maturity level (Minimum Technology Readiness Level 4).The following documentation types are considered sufficient to substantiate proposal feasibility and must be explicitly provided: Empirical Performance Reports and Laboratory DataApplicants must submit formal engineering reports, test logs, software execution records, or laboratory datasets detailing the execution of prior automated material insertion or routing. This documentation should highlight successful testing of collaborative robotic systems manipulating flexible parts. Data must explicitly demonstrate that the applicant has previously developed software or hardware-in-the-loop scripts capable of driving multi-axis trajectories to grip and move non-rigid items dynamically. Cross-Program Proof-of-Concept BenchmarksSufficient documentation includes technical summaries, contract performance reviews, or closeout reports from prior non-SBIR federal, academic, or internally funded manufacturing R&D efforts. Specifically, applicants can substantiate feasibility by detailing successful milestones from past automated flexible-assembly initiatives, such as:Documented integration of robotic platforms optimized for compliant, multi-modal material tracking (e.g., past project outcomes managed under Advanced Robotics for Manufacturing Institute programs).Validated operational results from previous laboratory validation campaigns focused on flexible component manipulation, demonstrating early-stage handling of part deformation and configuration variability. Prototype Success Criteria and Interface Control DocumentsApplicants must provide evidence of an existing physical or digital prototype. The documentation must exhibit a functional architecture of a single-arm cell, demonstrating how the software handles geometric inputs to calculate tool paths. Success criteria of the prior prototype must demonstrate that the hardware and software configuration can successfully manage flexible materials under variable lighting or workspace clutter, establishing a stable, cloud-independent edge-computing loop prepared for live factory scaling.By compiling these specific reports, datasets, and mechanical baselines, the applicant provides the Air Force with clear evidence that the foundational technological risks have been thoroughly retired. This proves the single-arm architecture is mature, viable, and prepared to immediately enter the accelerated Phase II prototype integration, laboratory workcell validation, and live TRL 7 pilot production testing schedule.

The Phase II period of performance represents a substantial research, development, and hardware-software integration effort. It transitions the single-arm robotic technology from a validated laboratory concept into an operationally viable, modular manufacturing prototype ready for deployment on active aerospace production lines. To establish a clear, unambiguous standard for project success, the following functional requirements, operating parameters, testing regimens, and quantitative milestones are defined as the mandatory baseline for the Phase II effort.1. Functional Requirements & Technical GoalsThe Phase II effort must deliver a fully integrated, single-arm modular robotic manufacturing workcell that achieves the following technical benchmarks:Hardware-Agnostic Core Integration: Physical integration of a single collaborative manipulator arm mounted onto a reconfigurable or mobile mounting base. The control layer and sensory infrastructure must remain entirely program-agnostic, allowing the system to adapt to different vendor components without requiring a structural mechanical redesign.Autonomous Ingestion & Macro Planning: An offline planning engine capable of ingesting 3D CAD models, engineering metadata, and raw wire harness specifications. This engine must automatically produce verifiable, macro-approach robot trajectories and cable-routing path plans that strictly respect part geometry, cable bend radii, and strain limits.Adaptive Online Control Loop: A native, low-latency software control stack that runs in real-time on local hardware without cloud dependency. The system must utilize real-time tactile, force-torque, and vision feedback to dynamically adjust joint positions and execute compliant connector mating.Human-Like "Search and Settle" Behavior: Integration of hybrid position/force control mechanisms. The single arm must actively use force-torque feedback to perform search-and-settle sub-millimeter corrections during blind-mate insertion sequences where direct visual confirmation is obscured or impossible.Machine-Readable Traceability (Digital Thread): The workcell must implement the first end-to-end digital thread registry for harness assembly operations. The software must automatically log machine-readable records of every cable insertion force profile, routing coordinate, and connection seating confirmation to eliminate quality escapes and prevent latent field failures.2. Operating Parameters & Use CasesThe integrated single-arm automation system must operate reliably within the following boundaries:Physical Footprint & Access Clearance: The complete robotic tool head and manipulator assembly must be engineered to operate within the highly constrained physical envelopes and narrow clearance tracks of defensive aircraft and munitions architectures.Part Deformation Management: The system must dynamically adapt to non-rigid part behavior, actively compensating for the unpredictable bending, flexing, and micro-variability introduced during manual pre-assembly or technician handling.Primary Mission Use Case (Single-Arm Munitions Wiring): The primary operational use case involves deploying the modular workcell to automate the core wiring and electrical routing steps for complex defense systems—including the Franklin Affordable Mass Missile (FAMM) and Coyote Missile families. The system must execute aperture threading, vision/tactile-guided connector alignment, force-compliant insertion, and connection verification on representative aerospace hardware.Achieving the above should deliver a fully validated, production-ready manufacturing technology that drops labor constraints, provides comprehensive digital quality data, and dramatically scales the industrial surge capacity required for Great Power Competition.

The contractor will pursue commercialization of the technology, targeting government program offices, commercial industrial base stakeholders. and dual use industrial customers.

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 section 3.5 of 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. Develop and demonstrate an automated, end-to-end software platform capable of ingesting heterogeneous Technical Data Packages (TDPs)—including 3D CAD models, 2D engineering drawings, Bills of Materials (BOMs), and textual specifications—to autonomously extract engineering intent and generate optimized, collision-free robotic inspection trajectories without manual waypoint programming or hard-coded scripting.The resulting system must bridge the gap between enterprise digital design data and physical automation by converting complex tolerances, geometric constraints, and manufacturing annotations into a standardized data model, simulating the execution virtually, and deploying executable inspection commands directly to physical mobile robotic manipulators. (Design and fabrication of the physical manipulator is not within scope - this project will focus on translating TDPs to robot-ingestible task specification and pathing.) The objective is to drastically compress quality control programming timelines from days to under two hours and enable rapid robotic reconfiguration in highly agile manufacturing environments.

Here is a draft for a Direct to Phase II SBIR solicitation topic based on the technical capabilities of the data extraction and automated path-planning pipeline. The content has been carefully structured to be precise and concise while protecting all proprietary text.Direct to Phase II Topic DraftTopic ObjectiveObjective: Develop and demonstrate an automated, end-to-end software platform capable of ingesting heterogeneous Technical Data Packages (TDPs)—including 3D CAD models, 2D engineering drawings, Bills of Materials (BOMs), and textual specifications—to autonomously extract engineering intent and generate optimized, collision-free robotic inspection trajectories without manual waypoint programming or hard-coded scripting.The resulting system must bridge the gap between enterprise digital design data and physical automation by converting complex tolerances, geometric constraints, and manufacturing annotations into a standardized data model, simulating the execution in a physics-accurate virtual sandbox, and deploying executable inspection commands directly to physical mobile robotic manipulators. The objective is to drastically compress quality control programming timelines from days to under two hours and enable rapid robotic reconfiguration in highly agile manufacturing environments.Topic DescriptionBackground & Problem Statement: Modern aerospace manufacturing and sustainment pipelines face severe bottlenecks due to legacy quality control (QC) practices. As defense systems shift toward highly modular, rapidly evolving, and low-cost attritable architectures, traditional fixed automation becomes commercially and operationally impractical. Traditional robotic inspection lines require highly specialized programmers to manually teach waypoints, configure physical sensor triggers, and execute tedious trial-and-error collision testing on vendor-specific offline programming utilities. This labor-intensive paradigm introduces severe production delays, as errors or dimensional variations are often caught late in the assembly stream, resulting in compounding downstream costs and extended lead times.While digital enterprise structures routinely house complete engineering intent within comprehensive Technical Data Packages (TDPs)—complete with 3D geometry, Geometric Dimensioning and Tolerancing (GD&T) markers, material specifications, and assembly metadata—translating this multi-format data into actionable instructions remains a manual and error-prone process. To meet the demand for rapid production scaling and point-of-need deployment, the Department of the Air Force requires an intelligent software layer that dynamically parses TDP data and translates it directly into autonomous robotic execution paths.Phase II Expected Outcomes: Proposers responding to this Direct to Phase II topic must demonstrate a mature conceptual foundation, such as completed preliminary software blocks or data-parsing prototypes originally validated under related early-stage research. Phase II efforts must deliver a hardened, end-to-end software prototype validated against representative aerospace assembly geometries.Key technical deliverables include the ingestion/planning software, documentation for enterprise data interfaces, and localized simulation proof-of-concepts. The system performance will be benchmarked against key parameters, targeting a setup time reduction to under 8 hours for novel manufacturing configurations and compressing numerical programming timelines down to less than 1.5 hours. Final validation should culminate in a software-driven execution demo using either high-fidelity simulations or physical manufacturing hardware within a pilot production framework.

As this is a Direct-to-Phase-II (D2P2) topic, no Phase I awards will be made as a result of this topic. To qualify for this D2P2 topic, Offerors must demonstrate completion of Phase I feasibility research and development that is not based upon or logically extend from any prior or ongoing federally funded SBIR or STTR work. Applicant(s) should provide documentation demonstrating a clear understanding of the technical challenges associated with processing enterprise data, extracting design intent, and validating automated path execution.The purpose of this Feasibility Documentation is to substantiate that the small business's technology is currently at an acceptable maturity level to immediately execute the prototype development, testing, and system integration required in Phase II.Required Substantiation ComponentsOfferors must submit a structured technical package within the proposal (typically matching the Department of Defense Volume 2 Technical Guidance) that clearly defines the current technological baseline. Offerors must explicitly demonstrate that they possess the intellectual property rights or native ownership of the algorithmic baselines being brought forward. This foundational proof cannot be purely conceptual or marketing-driven; it must contain raw technical and analytical validation.To satisfy the specific constraints of an automated enterprise-data-to-robotic-execution pipeline, the documentation must provide evidence across three core domains:Ingestion & Semantic Interpretation Capability: Documentation showing the mature capability of existing code blocks or analytical tools to ingest engineering files (such as 3D CAD models, STEP files, or legacy 2D PDFs) and systematically isolate geometric structures, dimensional annotations, and textual production notes. Standardized Data Architecture: Evidence of a functional relational schema, database template, or centralized data graph structure utilized by the software to catalog and bind extracted dimensions directly to spatial CAD nodes. Kinematic & Simulation Mechanics: Proof that the small business has successfully compiled algorithms capable of reading logical manufacturing sequences and converting them into multi-axis spatial motions or automated path-planning trajectories within a virtual modeling sandbox.Acceptable Forms of EvidenceThe Air Force will evaluate the proposal based on empirical data rather than speculative milestones. Offerors should supply a combination of the following documentation types to conclusively prove feasibility:Technical Reports and White Papers: Comprehensive white papers detailing the results, architectural limitations, and developmental conclusions of previous internally funded research or non-SBIR commercial software deployments. These reports must highlight how previous iterations successfully managed multi-format document exceptions. Empirical Test and Measurement Data: Quantitative performance charts indicating the precision and accuracy of the software's semantic parsing or extraction engines. This includes specific metrics on Optical Character Recognition (OCR) error rates, geometric normalization latency, or vector parsing precision. Prototype Design Schematics and Software Architecture Models: Logic flow charts, structural class diagrams, API data contract definitions, and interface maps illustrating how data progresses from raw enterprise packages into a centralized repository, and ultimately into automated motion commands. Simulation Benchmarks and Run-Time Measurements: Time-study records, compute logs, or comparative tables tracking the computational time required to automatically generate path trajectories relative to manual offline programming configurations. This data should ideally record baseline path-generation cycle times to validate the scaling potential of the optimization engine. Defined Prototype Success Criteria: Clear operational boundaries, algorithmic tolerances, and pass/fail thresholds under which previous internal iterations achieved successful outcomes. Offerors must list the specific file sizes, component geometric complexities, and degree of nesting variations that their software baseline has successfully parsed without human intervention.Failure to provide rigorous, quantitative proof of a functioning software baseline that bridges data ingestion with basic path computation will result in a determination of technical non-conformance, rendering the proposal ineligible for a Direct-to-Phase-II award.

Phase II Expected Outcomes and Technical Framework The Phase II effort represents a major research, development, and engineering push aimed at transitioning the foundational software baseline into a hardened, production-ready enterprise platform. The overarching objective is to eliminate the manual overhead, human parsing errors, and rigid programming loops that bottleneck modern aerospace manufacturing lines. By the conclusion of the Period of Performance, the recipient must deliver a mature, well-defined software ecosystem capable of directly translating raw engineering intent into optimized, collision-free multi-axis robotic paths. The final system must demonstrate operational viability and full structural traceability back to the originating digital assets.Operating Parameters & Use Cases The software suite must maintain operational viability across highly dynamic industrial settings. Phase II development must satisfy the following baseline parameters and specific deployment use cases: Ingestion of Heterogeneous Artifacts: The ingestion system must process and map multi-vendor file formats natively without relying on manual pre-formatting or external template modifications. This includes parsing geometric data types (e.g., STEP, IGES) alongside flat text and visual annotations (e.g., drawings, PDF specification sheets, text-based process blocks).Use Case 1: Rapid Line Reconfiguration: The primary manufacturing usecase is the rapid setup of robotic tasks for modular or short-run components, specifically targeting complex structure profiles typical of autonomous collaborative platforms (ACPs) or unmanned aircraft structures. Use Case 2: Multi-Vendor Kinematic Adaptation: The trajectory engine must adapt logical tasks to varied multi-axis robotic hardware platforms (e.g., varied serial arms paired with mobile transport carts or tracked bases). The software must abstract the path calculations from specific OEM programming semantics, allowing uniform execution across distinct vendor controllers. Technical Goals & Functional Requirements The software platform must be architected as a modular, cohesive system organized across clear functional layers: Engineering Intent Processing and Graphing: The system must isolate complex design specifications—such as Geometric Dimensioning and Tolerancing (GD&T) callouts, fastener tolerances, and localized surface processing sequences—from raw documents and compile them into a relational schema or centralized data architecture. This framework must programmatically bind quantitative quality boundaries directly to the respective spatial locations on the 3D target geometry. Autonomous Path & Sequence Generation: Using the compiled structural schema, the planning block must calculate the sequence of activities independently. It must automatically optimize physical tracking angles, sensor stand-off distances, and surface normal orientations without traditional waypoint scripting or manual joystick teaching. No-Code Operator Interface: To support floor personnel who lack advanced programming backgrounds, the platform must include an intuitive, no-code graphical layer. This dashboard must visually highlight the automatically derived inspection points, outline the planned tool paths, and provide a human-in-the-loop review portal to allow manual modifications or explicit process validation before runtime deployment. The culmination of this project will be a software platform has reached a Technology Readiness Level (TRL) of 6/7, fully capable of driving multi-vendor industrial manipulators directly from enterprise data packages.

The contractor will pursue commercialization of the technology, targeting government program offices, commercial industrial base stakeholders. and dual use industrial customers.

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 section 3.5 of 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. Develop and demonstrate advanced power source technologies capable of meeting weapon requirements with specific energy and power equal to or greater than current reserve battery technologies.

Power source performance in terms of power and energy density is the major objective with affordability, safety, and reliability secondary objectives of Air Force Armament Directorate programs for advanced reserve power sources for weapon systems. Secondary objectives are not distant relative to the major objective, but power and energy density is emphasized in order to enable new concepts and integration strategies. Current reserve thermally activated battery technology is at risk of becoming obsolete due to increasing specific power and specific energy requirements, while other battery technologies with similar or greater specific energy suffer from multiple failure modes, have limited storage life, or have not been tailored to meet the unique requirements for Air Force weapon programs. An advanced reserve power source lasting 20+ years without the need for maintenance or significant energy loss while in storage, is reliable, and is inherently safe, e.g. is not susceptible to thermal runaway, is required. Weapons typically have storage lifetimes of 20+ years; and must maintain reliable operation at any point within this time period without the power source being inadvertently activated. When the power source is activated, it must rise to full voltage within 600 ms and have an activated life of 5+ minutes. The power source must be able to survive shock, vibration, and temperatures (MIL-HDBK-310 1% Hot/ 1% Cold Days, worldwide) associated with external and internal carriage, high speed free flight, and storage environments. The power source will be required to provide power for weapon avionics, guidance, and ordnance initiation events for the entire flight profile. The load on the power source must be capable of periods of pulse power with an average 2.5 kW/kg minimum and a goal to exceed 5 kW/kg load over 60 seconds. The goal of this technology development is to design, develop, and test an advanced design for a power source capable of 20+ years of storage, 5+ minutes of activated life, with a specific energy at a minimum of 40 Wh/kg and a goal to exceed 100 Wh/kg. The power source must be inherently safe during its entire lifetime. Due to the safety issues associated with lithium battery technologies and the process to receive certification through the Naval Ordnance Security and Safety Activity (NOSSA) for use on an ordnance system, lithium battery technologies will need to demonstrate no venting under NAVSEA S9310-AQ-SAF-010 test conditions.

As this is a Direct-to-Phase-II (D2P2) topic, no Phase I awards will be made as a result of this topic. To qualify for this D2P2 topic, Offerors must demonstrate completion of Phase I feasibility research and development that is not based upon or logically extend from any prior or ongoing federally funded SBIR or STTR work. Prior efforts used to demonstrate feasibility must identify candidate materials, technologies and designs including the rationale for being acceptable in addition to performance data.

Conduct performance testing to establish design performance characteristics (Wh/kg, Wh/L, temperature range, power capability) and safety. Upon selection government provided data may be used to develop prototype designs. The deliverables for this phase consist of: 1) Prototype power source delivering 2.5 kW/kg for 60 seconds. 2) Performance characterization through testing to include captive carry and free flight shock and vibration : a. Wh/kg, b. Wh/L, c. power capability, d. temperature range, e. safety characterization.3) A manufacturing assessment of a concept design.

Phase III will range from prototype testing and qualification to possible transition to a program of record. Must be able to support producing quantities in the 100-1000s. PEO Customers include AFLCMC/EB, Army PEO M&S TAGM, Navy PMA-242, and SOCOM.

Create a physics-based engineering model solution for shallow fuel jet spurts

This topic seeks the development of a computationally efficient engineering-level model to predict the formation and characteristics of the "spurt" in fluid cavity created jets. The hydrodynamic spurt is the initial, often unsteady, ejection of material from the liner, preceding the formation of the main, stable jet. Current hydrocodes can model this phenomenon but are computationally expensive and ill-suited for rapid design iteration. This project will develop a validated, reduced-order model that accurately predicts spurt velocity, mass, and geometry as a function of liner material, geometry, and threat characteristics, enabling faster design and optimization of advanced warheads.

Identify and analyze the key physical mechanisms governing spurt formation using existing literature and high-fidelity hydrocode simulation- Identify and analyze the key physical mechanisms governing spurt formation using existing literature and high-fidelity hydrocode simulations. Develop a preliminary analytical or semi-empirical framework for the model. Demonstrate the feasibility of the proposed model to predict spurt characteristics for a baseline test case. Develop a preliminary analytical or semi-empirical framework for the model. Demonstrate the feasibility of the proposed model to predict spurt characteristics for a baseline shaped charge design. The final report detailing the model's theoretical basis and demonstrating a proof-of-concept correlation with high-fidelity simulation data for at least one configuration.

Develop the engineering model into a robust software prototype. Expand the model to account for a wider range of liner materials, geometries, and explosive types. Conduct extensive validation of the model against a matrix of existing or newly generated experimental data. A validated software tool capable of predicting spurt parameters with a defined level of accuracy. The tool should be significantly faster (orders of magnitude) than full hydrocode runs.

Harden the software for integration into the DoD's standard warhead design toolchains. Provide training and support to government and prime contractor engineering teams. Explore dual-use applications in commercial sectors such as high-speed metal forming, explosive welding, or industrial perforation.

High-energy lasers integrated onto airborne platforms hold immense potential for a variety of applications, relevant to DAF missions. However, the demanding operational environments encountered by airborne systems, characterized by factors like vibration, shock, temperature fluctuations, and pressure variations, pose significant challenges to the performance and reliability of traditional optical systems. To achieve demanding pointing and line of sight stabilization requirements necessary for the laser to have the desired effect on target, a precision optical beam control system is required to sense and correct platform induced disturbances, acquire and track targets, and sense and compensate for atmospheric and aero-optical disturbances. Historically these optical systems are implemented on flat optical benches or breadboards, in a similar manner to a ground-based laboratory. To fully realize the potential of airborne laser systems, there is a critical need for innovative optical systems designed specifically for ruggedness and environmental stability. This research effort aims to develop and demonstrate a ruggedized, environmentally stable, and optimally packaged optical beam control system specifically tailored for airborne high-energy laser applications, in a more optimized form factor for an airborne system than a conventional flat optical bench or breadboard.

The Air Force requires light weight, compactly packaged optical systems to perform critical beam control functions for airborne high energy laser systems. The purpose of this topic is not to develop new outer moldlines or turret designs for airborne systems but rather focus on optimizing the packaging and performance of the internal optical system required to perform the core beam control functions. A canonical layout of such system is available in Reference 1. The Government expects the designed beam control system will perform all functions laid out in the canonical design - or that any deviations are thoroughly understood and technically justified. Additionally, designs should prioritize ease of alignment and component replacement, potential for line replaceable units, beam path conditioning, and material free of shedding contaminants which could lead to foreign object damage. In order to achieve these objectives, the Government anticipates investigations into the following areas, although this list is informational and is intended to be neither proscriptive nor comprehensive:Ruggedized Optical Design and MaterialsRobust Packaging and Assembly TechniquesNovel Optical Architectures: Explore and develop innovative optical designs inherently tolerant to vibrations, shocks, and thermal gradients.Advanced Materials Selection: Investigate and characterize advanced materials with superior thermo-mechanical properties. This includes exploring specialized glasses, ceramics, and composites for optical elements and mounting structures.Advanced Manufacturing and Assembly Processes: Investigate and implement advanced manufacturing techniques, such as additive manufacturing and precision micro-assembly, to fabricate intricate components and achieve high-precision alignment and bonding of optical elements.Athermalized Design Strategies: Implement passive and active athermalization techniques to mitigate the performance degradation caused by temperature fluctuations. This involves optimizing material choices, employing thermal compensation methods.

In phase I the basic concept for the beam control mounting structure will be developed and investigated. Initial performance estimates will be modeled and an initial estimate of size and weight will be calculated. The Government anticipates numerous trade studies and design excursions to create the conceptual design for the OPALS beam control subsystem. During Phase I, concepts developed should be as platform agnostic as feasible. The Government will provide platform representative vibration spectra for performance analysis. The Government anticipates the majority of the concept development to support a Phase II prototype capable of propagating an up to ~20kW laser. However, the concept should also address issues relating to the transition to the phase III operationalized system, capable of accepting a laser of at least 300kW.

For the Phase II, the proposals should include development, installation, integration, demonstration, test and evaluation of the proposed optimally packaged beam control prototype system. This Phase II will seek to implement and demonstrate the feasibility of the optimally packaged beam control subsystem using a government furnished laser with power <= 20 kW, for both ground and airborne laboratory tests. AFRL is developing an Airborne Laser System Integration Laboratory to perform experimentation of advanced technologies and concepts relating to airborne high energy laser systems. The first iterations of this laboratory system will have a conventionally implemented (i.e. bench based) beam control subsystem, but subsequent upgrades are planned, and if successful we anticipate demonstrating the OPALS beam control subsystem in this laboratory. AFRL will work collaboratively to define interfaces, develop requirements, and further refine performance estimates. The work done as part of this proposed effort should be applicable to reduce risk for a full-scale system design. Efforts will include:- Perform relevant modeling and simulation to facilitate system design- Design, build, and field test a ground-based demonstration beam control subsystem to collaboratively operate with AFRL laser source- Deliver the system and associated documentation to AFRL

Phase III will focus on scaling up the phase II prototype into an beam control subsystem for integration onto a large, operationally relevant aircraft. The developer and AFRL will work directly with a transition partner in order to incorporate the OPALS technology into a high energy laser system significantly more powerful than the prototype system - anticipated to be at least 300kW.

The objective of this project is to study, develop, test, and field a system that addresses a critical gap in pre-mission verification and validation of receive systems supporting flight test missions that transition between multiple, geographically diverse Test and Training Ranges. The end goal is to achieve a fully operational system that enables synchronized telemetry test signals across all participating ranges. This will allow for a comprehensive, end-to-end system checkout before a live test, significantly reducing operational and data fidelity risks, enhancing test accuracy, and strengthening mission readiness for advanced DoW test scenarios.

Flight test missions that traverse multiple Test Ranges (e.g. hypersonic vehicles/weapons, cruise missiles, long-range weapon systems etc.) or that require different test support infrastructures (e.g. sea range, targets, threat simulators, etc.) at remote Test Ranges, require telemetry receive stations along the flight paths to receive real-time telemetry and then relay that data via ground networks to the control room monitoring the mission. In past mission pre-flight scenarios, remote telemetry receive site to control room links were checked individually. This was accomplished with a local bore sight signal simulator that transmitted a known test pattern at the center frequency of the actual test article. The telemetry receive site would receive the radio frequency signal, demodulate/decode it, then send the data via Internet protocol (IP) networks to the control room. In the control room the received data was verified to be correct as the bit pattern received could be compared to the bit pattern transmitted. This was accomplished for each local and remote telemetry receive site prior to the mission.During the test, each local and remote telemetry receive site would send data to the control room and a manual switch would be accomplished between each data source based on data quality that was determined manually. Note, this selection was not automated.With the invent of best source selection using data quality metrics transferred over IP networks via data quality encapsulation [1], no longer is election of multiple data sources done manually. Telemetry receivers now assess received data quality and assign a bit error probability to a packet of data prior to sending it to the best source selector in the control room. A best source selector (BSS) inputs these multiple streams, performs time alignment, then using the data quality metric, selects the best data to output on a bit-by-bit basis. This output is the best data using all available data streams from diverse receive sites.Though higher quality, near error-free data is now provided to the control room, the addition of the BSS has revealed a shortfall. The entire data path from remote receive sites to transport through best source selection to control room cannot be tested as a complete system to assess mission readiness. The traditional method of pre-flight checks cannot be used. Why? The best source selector will not be able to correlate the multiple data streams from remote sites as the signal sources will not be correlated. This results in the configuration and operation of the BSS being unknown until the test mission. The proposed work will focus on solving this shortfall resulting in a networked, synchronized telemetry validation system capable of simulating a test vehicle's telemetry signal at multiple ground stations simultaneously. Stated another way, the proposed system must simulate the test article signal as if all telemetry receive stations could “see” the test article and simultaneously receive the telemetry signal. This capability will allow test ranges to perform pre-mission verification of the entire telemetry infrastructure. This would include all participating receive antennas, distribution networks, and best source selector(s) to control room displays to ensure full system connectivity and performance before supporting a live mission.

Phase I should assess the scientific and technical merit and feasibility of the concept proposed for Inter-Range telemetry receive system synchronization and signal source correlation. Objectives and expectations in Phase I are as follows: Thoroughly describe the shortfall identifying all components and interfaces. Reference all appropriate standards and provide a use case(s) that clearly illustrates the shortfall.Propose an architecture that addresses and solves this shortfall. A solution should provide a solution that incorporates multiple, spatially diverse telemetry signal sources/simulators and synchronizes these sources with precise, common time and frequency reference across all sites.Derive a master-client network architecture with a centralized command and control graphical user interface. This will allow an operator to remotely configure, manage, and monitor all signal sources/simulators from a centralized location.At the core of this solution, develop a protocol that precisely aligns all remote pseudo-random bit sequences (PRBS) generated by each simulator.

The Phase II effort will focus on the research, development, and delivery of a prototype system. The principal objectives include:Objective 1: Telemetry Signal Synchronization: Develop a master-client protocol and integrate a timing solution to achieve time-aligned signal generation across multiple remote telemetry signal simulators.Objective 2: Command and Control: Implement a web-based graphical user interface (GUI) for centralized configuration, status monitoring, and control of all remote simulators from a single centralized interface.Objective 3: Multi-Site Telemetry Signal Source Verification and Testing: Demonstrate multi-site correlation through bit error rate (BER) testing integrating best source selection (BSS). This includes simulating real-world impairments such as network latency and jitter. This can be simulated or with actual hardware (see Objective 4).Objective 4: Lab Verification of Hardware: Demonstrate proposed hardware in a lab environment.Objective 5: In the Field Validation of Hardware: Demonstrate the prototype system, consisting of a minimum of three signal sources controlled via a central control hub. The prototype system will be installed and tested at three geographically diverse locations. For example, that can be three sites at one Range, or one site at three Ranges (e.g. Edwards AFB, China Lake Range, Pt. Mugu Sea Range).Success criteria will be based on the system's ability to achieve and maintain PRBS synchronization of the three remote signal simulators, successful execution of remote commands via the GUI, and passing multi-site BER testing at the output of the BSS.

The Phase III effort will focus on transitioning the prototype system to a fully operational and commercially available and sustainable product. Technology is expected to enter Phase III at TRL-6 and be matured to TRL-8. Working with the Test Ranges will be key to this maturation as real-world testing will aid in process. Direct interaction with the Telemetry Group of the Range Commanders Council will ensure customer needs are integrated into the hardware as it is matured. A successful SBIR Program would result in the standardization of the end product in the Telemetry Standard IRIG-106 with adoption into the major Test Ranges.DoW Applications: The end goal for this system would be to secure procurement contracts via the SBIR Phase III pathway to deploy the end system as a standardized solution across Air Force, Army, and Navy Test Ranges. Known customer opportunities include the 412th Test Wing (Edwards AFB), 96th Test Wing (Eglin AFB), NAWCAD (Point Mugu and Patuxent River), and White Sands Missile Range as all support flight test programs that require range airspace and assets spanning multiple Ranges.Commercial Applications: Market the end system to commercial aerospace prime contractors (e.g., Boeing, Lockheed Martin) and commercial space launch providers (e.g., SpaceX, Blue Origin, ULA) to improve the efficiency and reliability of their own flight-testing programs.Business Model: The commercialization strategy will blend direct sales to DoD ranges with commercial applications.

Create a system capable of launching long rod threats with controlled angle of attack

The lack of a non-destructive, high-precision launching method for high length-to-diameter (L/D) projectiles fundamentally degrades the fidelity of Live Fire Test and Evaluation (LFT&E) data. For the Air Force, this deficiency directly compromises the development of penetrating munitions, degrades the survivability assessments of aerospace platforms, and introduces significant acquisition risks due to flawed test data and increased testing costs. Currently, there is not means of reliably controlling or manipulating the flight of a long rod projectile such that it consistently reaches a target location at a specific orientation. Providing means of accomplishing this feat advances DoW test capabilities for critical data underpinning analytical vulnerability assessments and engineering designs improving the survivability posture of current and next generation combat aircraft.

Conduct a comprehensive feasibility study evaluating alternative launching technologies (e.g., advanced light-gas, hybrid electromagnetic, pneumatic) against the requirement to launch high L/D ratio projectiles (1,400 m/s to >2,300 m/s) without structural degradation. Develop a conceptual design and utilize analytical modeling and simulation to predict internal ballistics, projectile acceleration curves, and exit velocities. Identify technical risks and propose mitigation strategies.

Execute the Phase I maturation plan by engineering, fabricating, and testing a sub-scale or full-scale prototype launching system. Conduct live-fire demonstrations using inert long-rod projectiles to validate the system's velocity range, repeatability, and precision. Integrate high-speed diagnostics (e.g., flash X-ray, high-speed imaging) to conclusively verify the structural integrity, pitch, and yaw of the projectile upon muzzle exit. Validate the system's operational viability for generating actionable LFT&E data (e.g., ballistic limit testing).

Transition the mature technology to government and contractor testing facilities. Integrate the launching system into major Department of War (DoW) LFT&E ranges (Army, Navy, Air Force) to support acquisition programs evaluating next-generation vehicle, aviation, and body armor. Concurrently, pursue commercialization pathways by adapting the technology for dual-use applications, such as civilian materials science research, spacecraft micrometeoroid shielding evaluation, and industrial hypervelocity impact studies.

Develop and validate a non-intrusive, luminescence-based surface measurement technique for simultaneous pressure and temperature measurements within non-oxygen-based hypersonic ground test facilities.

Within aerodynamic testing, pressure sensitive paint (PSP) provides crucial global surface pressure data that is utilized in calculating aerodynamic loads [1] and identifying small scale features within the flow. The working principle behind PSP involves luminophores that fluoresce at an intensity inversely proportional to the number of oxygen molecules present i.e., oxygen quenching [2].While these paints/luminophores have been sufficiently researched, the use-case of these paints is severely limited due to the requirement of oxygen in the flow field. Advanced hypersonic wind tunnels such as the blowdown facility at AEDC Tunnel No. 9 which utilizes nitrogen as the working fluid, are unable to utilize PSP to capture global pressure data with this method and are therefore severely limited to discrete measurement techniques. It is required that a novel technique be developed to capture simultaneous global pressure and temperature measurements in nonoxygen-based hypersonic wind tunnels.

Phase I efforts outline technique/paint development and establish feasibility through thorough characterization of the paint properties/sensitivities and reduction process using benchtop testing and testing within small-scale (educational) supersonic/hypersonic facilities.

Phase II efforts outline full scale prototype demonstrations within a hypersonic test facility through either test probes or full-scale model testing on a well-known/standard test article. The completed technique and refined data reduction process will be delivered at this phase.

The technique can be marketed for non-intrusive simultaneous pressure/temperature measurements in non-oxygen-based high-speed wind tunnels.

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 section 3.5 of 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. Accurately measure material surface temperature at high speed (5000 Hz +) and low range (0-2000 F) in high enthalpy ground test facilities.

AEDC requires a method to resolve temperature and emissivity across the surface of test articles. Specifically, there is a need for a high-speed low-temperature measurement solution that overlaps with other higher-temperature capabilities. The solution threshold requirements are to measure surface temperature from 0-1500 F (2000 F objective), at 4000 Hz (5000 Hz objective), with a pixel footprint of at most 0.1 inch (0.05 inch objective) and an accuracy of +/- 10 deg F (+/- 5 deg F objective).

Compile low temperature, high sampling rate hyperspectral imager feasibility research that Addresses the solution threshold included in the Description of this topic. Awardee will perform research and present a feasibility report that describes a benchtop proof-of-concept that will be used for fabrication activities during Phase II.

Fabricate a well-defined prototype of a low temperature, high sampling rate hyperspecral imager that meets the objectives stated above and can become operationally viable.

Hyperspectral imager deployment.

Develop, integrate, and demonstrate an artificial intelligence (AI)-enabled computed vision and human-machine interface capability that transforms aerial refueling operations from subjective, observation-based evaluation into an objective, data-driven performance assessment and adaptive training environment. The system shall leverage advanced computer vision, machine learning, and aviation (flight dynamics) analytics techniques to automatically extract operationally relevant performance metrics from aerial refueling events, quantify deviations from desired flight profiles, and generate actionable post-flight feedback to improve aircrew proficiency, reduce human-factor-driven mishaps, and enhance mission readiness.The capability shall analyze video from cameras mounted on the tanker (esp. the KC-46) to provide near-real-time post-flight reconstruction of aerial refueling engagements by correlating aircraft position, motion dynamics, refueling geometry, pilot inputs, and operational context to identify performance trends and training opportunities. The developed system shall perform automated assessment of complex aerial refueling behaviors including aircraft stability, closure rate management, alignment accuracy, control surface position, other situational awareness indicators, and adherence to established refueling procedures.The objective is to mature existing advanced AI-enabled aviation analytics into an operationally relevant post-flight “hotwash” and training capability that increases the instructional value of each aerial refueling sortie, reduces reliance on subjective human assessment, accelerates pilot proficiency development, decreases equipment damage associated with refueling deviations, and establishes a scalable foundation for future intelligent aviation training systems across Department of the Air Force and joint aviation communities.The resulting prototype shall demonstrate the ability to ingest operational aerial refueling data, autonomously generate objective performance assessments, provide intuitive visualization and debrief products, and support transition into existing aviation training, evaluation, and modernization ecosystems. Importantly, the system will also include automated security management of the video so that implementation is seamless and complies with security classification guidance.

Air-to-air refueling (AAR) is a critical Department of the Air Force and Department of the Navy capability enabling global mobility, long-range strike, combat airpower projection, and sustained aviation operations. However, aerial refueling remains one of the most technically demanding and safety-critical aviation tasks performed by aircrews. Successful execution requires precise aircraft positioning, coordinated control inputs, accurate closure rate management, continuous situational awareness, and effective crew coordination between tanker and receiver aircraft.Current aerial refueling training and post-flight assessment processes rely heavily on instructor observation, pilot self-assessment, manual video review, and subjective evaluation of performance. These approaches provide limited ability to quantitatively assess the thousands of individual performance variables that influence successful refueling operations. Existing methods do not provide pilots with objective, moment-by-moment feedback on aircraft positioning, closure rates, control inputs, deviations from desired procedures, or trends in individual performance over time.This topic seeks to develop, demonstrate, and transition an artificial intelligence (AI)-enabled computed vision capability that (post-flight) automatically analyzes aerial refueling operations and provides objective, data-driven pilot performance feedback. The desired capability will mature existing advances in autonomous aerial refueling analytics and apply them toward training, readiness, and safety improvement by transforming aerial refueling video and available aircraft performance data into actionable post-flight debrief products.The developed system shall provide an automated “hot wash” which analyzes aerial refueling events, identifies performance deviations, and generates intuitive visualizations that allow pilots and instructors to better understand execution quality and areas for improvement. The system shall reduce reliance on subjective recollection and manual review by providing objective measurements of aircraft performance throughout the refueling profile.The capability shall focus on analysis of tanker-mounted video data, such as KC-46 aerial refueling camera systems, while maintaining an architecture capable of expanding across additional tanker and receiver platforms. The vendor may pick (with Government concurrence) the first 3-5 receiver platforms to use in developing this system. Future applicability includes KC-135, C-17, all fighter receiver aircraft, naval aviation communities, autonomous aerial refueling systems, and other aviation training environments requiring advanced performance analytics.The desired solution shall leverage artificial intelligence, machine learning, computer vision, and advanced human-machine interfaces to provide capabilities including:• Automated detection and tracking of tanker (boom and hose) and receiver aircraft during aerial refueling operations.• Measurement of relative aircraft position, movement, velocity, and alignment throughout the refueling engagement.• Assessment of aircraft position within the approved refueling envelope.• Analysis of closure rates, approach vectors, aircraft stability, and deviations from nominal procedures.• Ability to correlate video with other aircraft data if/as available (e.g. telemetry, fuel transfer rate, fuel state, and pilot inputs) to evaluate performance drivers.• Generation of objective performance scores and trend analysis across multiple training events.• Creation of visual performance assessment products for receiver pilot post-flight review of their performance during refueling, including graphical overlays, heat maps, event timelines, and immersive or interactive debrief environments.• Support for instructor review, adjudication, and refinement of automated assessments during initial deployment.The system should evaluate innovative approaches for integrating automated analytics with existing or future aviation training environments, including virtual reality (VR), augmented reality (AR), mission rehearsal systems, simulator environments, or other computer-based training tools.The solution must address operational challenges associated with military aviation data, including secure processing of controlled aviation video, automated data protection, and protection of sensitive operational information. The capability should consider approaches for minimizing processing burden on operational units while enabling rapid generation of post-flight assessments.The Government seeks solutions which provide an operationally relevant prototype supporting aerial refueling training organizations. Successful completion of this effort will provide Air Force and joint aviation communities with a next-generation training and assessment capability that improves pilot proficiency, increases the training value of each refueling event, reduces equipment damage and maintenance impacts, and enhances overall mission readiness.The desired end state is an operationally demonstrated capability ready to implement for at least one type of receiver aircraft and that can support transition into existing aviation training ecosystems and provide a scalable foundation for future AI-enabled aviation performance assessment across the Department of Defense.

As this is a Direct-to-Phase-II (D2)2) topic, no Phase I proposals will be accepted and no Phase I awards will be made under this topic. Offerors responding to this topic shall demonstrate “Phase I-type” technical feasibility through prior research, development, laboratory validation, commercial development, or operational demonstrations performed outside of the SBIR/STTR program. The purpose of this demonstration will be for the Government to determine the feasibility of the ideas that appear to have the potential to satisfy the objectives of this topic:The Government is seeking offerors with demonstrated experience and technical maturity equivalent to a successful Phase I effort. Proposals shall demonstrate existing capabilities, relevant past performance, or validated technologies applicable to the development of an AI-enabled aerial refueling performance assessment and automated pilot debrief capability.Qualified offerors shall demonstrate experience in at least half of following technical areas: Development and application of artificial intelligence, machine learning, and computer vision algorithms for analyzing dynamic objects in video imagery. Processing and interpretation of high-speed motion imagery to determine object position, movement, velocity, orientation, and spatial relationships. Development of algorithms capable of tracking aircraft, vehicles, or other dynamic platforms in complex operational environments. Aviation-focused data analytics, flight performance monitoring, flight simulation, or aircrew training systems. Development of human-machine interfaces, virtual reality (VR), augmented reality (AR), immersive training environments, or advanced visualization tools. Integration of sensor data, video analytics, telemetry, or flight performance information into automated assessment systems. Experience handling, processing, protecting, or analyzing controlled aviation or operational data. Automated video processing techniques including object recognition, classification, filtering, masking, or data protection methodologies. Development of secure software systems capable of operating within government aviation environments.Offerors shall demonstrate prior technical maturity equivalent to a Technology Readiness Level (TRL) 4 or greater at contract award. Relevant experience may include laboratory demonstrations, commercial applications, government-sponsored research, operational prototypes, or other non-SBIR/STTR funded development activities.The offeror shall demonstrate the ability to transition existing technical capabilities into an operational prototype supporting aerial refueling performance analysis. Successful offerors will demonstrate sufficient technical foundation to immediately begin Phase II activities including adaptation of computer vision algorithms, integration of aviation video data, development of automated performance metrics, and operational prototype demonstration.Evaluation of Phase I-equivalent experience will consider: Relevance of previous computer vision, artificial intelligence, or machine learning development efforts. Demonstrated ability to analyze complex motion-based systems, especially aviation maneuvers. Experience applying technology within aviation, aerospace, defense, and related training environments. Demonstrated ability to mature existing technologies into operationally relevant prototypes. Ability to address cybersecurity, data protection, and integration challenges associated with military aviation applications.

Phase II will develop, integrate, and demonstrate an operational prototype of an AI-enabled computer vision air-to-air refueling (AAR) performance assessment and automated pilot debrief system. The effort will mature existing autonomous AAR analytics into a post-flight training and evaluation capability providing objective, data-driven feedback to tanker and receiver aircrews.The prototype shall ingest AAR video and available aircraft performance data, identify deviations from desired procedures, and generate automated post-flight hotwash products. The system shall reduce reliance on pilot memory and manual instructor video review through objective measurements, visualization, and historical trend analysis.Task 1: System Architecture, Data Acquisition, and Secure ProcessingEstablish the architecture to ingest, process, analyze, and protect AAR video and associated aircraft data.Activities shall include:Develop system architecture, data flows, and cybersecurity approach.Establish procedures for CUI and operational aviation data.Integrate available tanker-mounted cameras, aircraft video, and applicable flight-performance data.Evaluate local processing with transfer of lightweight outputs versus secure video transfer to approved computing environments.Develop data-management procedures supporting expansion across tanker/receiver platforms.Deliverables: System Architecture Design; Data Management and Security Plan; CUI Processing Workflow; Initial Prototype Data Ingestion Capability.Task 2: Computer Vision Model Adaptation and Performance AnalyticsAdapt and mature existing computer vision technologies for automated AAR analysis, including aircraft motion, relative positioning, and flight-performance assessment.The capability shall:Detect/track tanker boom or hose and receiver aircraft.Determine relative position, orientation, and movement.Measure closure rates and approach vectors.Assess position within the approved refueling envelope.Identify boom, probe, or hose/drogue alignment.Analyze stability and deviations from nominal procedures.Support multiple tanker and receiver configurations.Demonstrate performance equivalent to TRL 6+ through prototype demonstration in a relevant operational environment.Deliverables: Adapted Computer Vision Models; Aircraft Tracking Algorithms; Performance Assessment Algorithms; Technical Validation Report.Task 3: Automated Performance Assessment and Pilot FeedbackConvert AAR data into objective post-flight performance feedback, including:Moment-by-moment scoring against nominal profiles.Positioning heat maps relative to the refueling envelope.Closure-rate and approach-vector analysis.Timeline reconstruction of key events.Identification of deviations/improvement areas.Historical individual and crew trend analysis.Where available, correlate performance with pilot inputs/data including fuel state/transfer rate, control inputs, throttle response, aircraft corrections, response timing, crew coordination indicators, and situational-awareness factors.To support organizational change and adjudicate corner cases, provide an instructor/"master debriefer" capability for trained personnel to review, validate, and provide feedback on automated assessments during initial deployment.Stretch Goal: Recognize, or provide a growth path to recognize, bent/broken boom, probe, or hose conditions and associated FOD.Deliverables: Automated Performance Assessment Engine; Pilot Feedback Products; Instructor Review Interface; Performance Analytics Dashboard.Task 4: Automated Data Protection and Video ProcessingDevelop secure video-processing capabilities that minimize operational burden and protect sensitive information.The system shall:Detect when a receiver aircraft is present and activate analytics only during relevant events.Identify and prevent processing/retention of unauthorized aircraft or sensitive platforms.Remove/obscure sensitive geographic information, terrain, markings, and other operationally sensitive information.Support automated masking/filtering before distribution.Demonstrate an architecture supporting future cybersecurity certification.Deliverables: Automated Video Processing Capability; Data Protection/Filtering Methodology; Cybersecurity Assessment Documentation.Task 5: Pilot Debrief Visualization and Training IntegrationDevelop intuitive visualization methods translating analytics into actionable training feedback. Evaluate/demonstrate:Immersive VR/AR replay environments.Squadron-level 2D visualization.Graphical overlays depicting aircraft position, closure rates, desired flight paths, deviations, and refueling-envelope margins.Apply instructional-design principles to support pilot learning, instructor evaluation, and squadron training discussions.Deliverables: Visualization Trade Study; Pilot Debrief Interface Prototype; Training Integration Plan.Task 6: Operational Demonstration, Testing, and TransitionDemonstrate the prototype with operational military aviation users and validate:Accuracy of automated assessments.Correlation with experienced instructor evaluations.Negligible manual video-review workload.Usability within existing training/mission-debrief workflows.Ability to generate actionable post-AAR pilot feedback.Desired Technical Performance Objectives:Generate automated debrief products within 15 minutes of video ingestion.Accurately track aircraft position, movement, and refueling geometry.Identify significant deviations from nominal procedures.Achieve ≥95% agreement between experienced instructors and automated assessments during validation.Demonstrate integration with at least one operational AAR training organization.Deliverables: Operational Prototype Demonstration; Test and Evaluation Report; User Feedback Assessment; Phase III Transition Plan.

Phase III will support transition of the AI-enabled aerial refueling performance assessment capability into operational Air Force, Navy, USMC, and select foreign aviation communities through program office integration, operational funding pathways, and sustainment planning.Potential transition applications include:· KC-46 aerial refueling training and readiness improvement.· KC-135 and legacy tanker modernization efforts.· C-17 and other receiver aircraft training applications.· Fighter receiver aerial refueling proficiency improvement.· Navy and Marine Corps aerial refueling operations.· Autonomous aerial refueling development and validation.· Advanced aviation training and performance analytics.Commercialization opportunities may include adaptation of aviation analytics, pilot training analytics, flight performance monitoring, and simulation technologies for commercial aviation, allied aviation partners, and other safety-critical transportation environments.

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 section 3.5 of 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. Develop a capability to prevent and/or mitigate cyber-attacks on fog and edge computing (FEC) devices and associated networks to provide mission assurance in highly contested environments.

This topic is intended for technology proven ready to move directly into a Phase II. Therefore, a Phase I award is not required. The offeror is required to provide detailed documentation in the Direct to Phase II proposal which demonstrates accomplishment of a "Phase I-like" effort, including a feasibility study. This feasibility study should include an approach, architecture and previous demonstration of a limited-scope prototype with the ability to prevent or mitigate a single class of cyber-attacks on an edge-node device, embedded device, or a similar device. The approach should be capable of scaling to a large of number of edge-nodes and have the ability to autonomously detect and respond to an attack.

As this is a Direct-to-Phase-II (D2)2) topic, no Phase I proposals will be accepted and no Phase I awards will be made under this topic. Offerors responding to this topic shall demonstrate “Phase I-type” technical feasibility through prior research, development, laboratory validation, commercial development, or operational demonstrations performed outside of the SBIR/STTR program. This feasibility study should include an approach, architecture and previous demonstration of a limited-scope prototype with the ability to prevent or mitigate a single class of cyber-attacks on an edge-node device, embedded device, or a similar device. The approach should be capable of scaling to a large of number of edge-nodes and have the ability to autonomously detect and respond to an attack.

The D2P2 effort should expand upon previous work to increase the robustness of the cyber protection and the classes of threats being addressed, specifically improving detection and response capabilities. The D2P2 should also demonstrate the ability of the FEC devices to fight through a supply chain or a remote exploit attack to accomplish mission objectives.

The final product will have both commercial and military avionics and space system applications, as well as a broad class of commercial applications, including Internet of Things (IoT) [6], Internet of Battle Things (IoBT) [5], and Internet of Space Things (IoST) [7].

The Department of the Air Force seeks mature, innovative solutions ready for prototype development and demonstration in cooperative perception for uncrewed or autonomous air systems. The objective of this topic is to develop and demonstrate a scalable prototype that enables distributed sensing nodes to share, prioritize, and fuse mission-relevant information in near real time to improve object detection, tracking, navigation, and operator situational awareness in cluttered and bandwidth-constrained environments.Solutions should support efficient information exchange, adaptive transmission under changing network conditions, and a credible data fusion design that converts distributed sensor observations into actionable fused products. Offerors should propose technologies with demonstrated Phase I-type maturity and a clear path to prototype integration, testing, and transition.

Distributed air operations increasingly depend on timely awareness of objects, hazards, and activities beyond the field of view of any individual platform. Cooperative perception offers a path to extend sensing coverage and reduce blind spots by allowing multiple platforms and supporting nodes to share sensor-derived information. Yet this benefit is limited by the large size of modern sensor data, the variability of wireless links, the need for rapid decision making, and the difficulty of combining observations from different platforms, geometries, and sensing modalities.This topic seeks prototype-ready solutions that build on prior feasibility work in distributed information sharing, compression, adaptive transmission, and sensor data fusion. The government is interested in capabilities that can select and transmit the most relevant information, manage latency and bandwidth constraints, and fuse data from multiple sources into improved perception outputs for autonomy or operator use.Offerors should address the data fusion aspect as a core requirement of the overall solution, whether through point cloud fusion, image or radar correlation, feature or object fusion, track association, or other mission-appropriate methods. Solutions should also describe how fused outputs are exposed to mission applications, edge processing nodes, or user interfaces. Approaches that can operate under degraded or intermittent communications and can scale across multiple sensing platforms are of particular interest.Prototype capabilities may include, but are not limited to: Distributed organization, naming, publication, discovery, or retrieval of sensor information; Adaptive data selection, fidelity control, compression, and transmission policies; Real-time or near-real-time fusion and correlation of data from multiple platforms or sensor types; Delivery of fused perception products to autonomy software, edge analytics, or mobile mission applications; and Measurable improvements in latency, bandwidth efficiency, blind-spot reduction, and detection or tracking performance.

This topic is intended for technologies that are sufficiently mature to proceed directly into prototype development. Therefore, Phase I awards will not be made for this topic and Phase I proposals will not be accepted. Offerors must provide detail and documentation in the D2P2 proposal demonstrating completion of a Phase I-type effort. This should include evidence of scientific and technical feasibility, relevance to a Department of the Air Force need, and a clear basis for moving directly into integrated prototype development.The "Phase As this is a Direct-to-Phase-II (D2)2) topic, no Phase I proposals will be accepted and no Phase I awards will be made under this topic. Offerors responding to this topic shall demonstrate “Phase I-type” technical capability through prior research, development, laboratory validation, commercial development, or operational demonstrations performed outside of the SBIR/STTR program. This should include evidence of scientific and technical feasibility, relevance to a Department of the Air Force need, and a clear basis for moving directly into integrated prototype development.The “Phase I-type” effort should have: Identified representative operational needs and stakeholders for cooperative perception and distributed situational awareness; Demonstrated technical feasibility in distributed information exchange, sensor-data management, compression, or adaptive transmission; Established an initial and credible data fusion approach appropriate to the mission problem; Produced evidence of prototype-readiness through modeling, simulation, laboratory integration, or early demonstration; and5 Described a clear path to Phase II integration, testing, and transition.I-type" effort should have:1. Identified representative operational needs and stakeholders for cooperative perception and distributed situational awareness;2. Demonstrated technical feasibility in distributed information exchange, sensor-data management, compression, or adaptive transmission;3. Established an initial and credible data fusion approach appropriate to the mission problem;4. Produced evidence of prototype-readiness through modeling, simulation, laboratory integration, or early demonstration; and 5. Described a clear path to Phase II integration, testing, and transition.

Phase II will focus on developing and demonstrating an integrated prototype for cooperative perception and sensor data fusion using distributed air and ground sensing nodes. The prototype should build on validated prior work and demonstrate how shared sensor information can be selectively transmitted, fused, and delivered to mission applications with measurable operational value.Phase II efforts may include implementation of distributed data-sharing mechanisms; adaptive policies for what information to exchange and at what fidelity; integration of compression, decompression, or bandwidth-management functions; real-time or near-real-time fusion of representative sensor products; delivery of fused outputs to edge or user applications; and evaluation of performance under representative wireless and mission conditions.Key deliverables may include: A functioning prototype demonstrating cooperative perception among multiple sensing nodes; Fusion-enabled outputs delivered to an autonomy, edge, or user-facing application; Performance results addressing latency, bandwidth efficiency, perception quality, and mission relevance; and System documentation and a transition plan for operational experimentation or integration.

Phase III efforts will focus on transition, operational deployment, and scaling of prototype cooperative perception capabilities. Defense applications include counter-UAS, tactical reconnaissance, base and perimeter security, special operations, disaster response, search and rescue, and other missions requiring distributed awareness from mobile sensors. Commercial applications include public safety, infrastructure monitoring, industrial inspection, autonomous delivery, emergency response, and remote operations where shared perception and efficient data fusion provide value.

Adapt an existing capillary blood collection device initially designed for humans and develop prototype hardware for use on Fleet dolphins and free-ranging cetaceans of varying epidermal thickness to improve proactive marine mammal monitoring, health measurements, and insight into behavioral responses to ensure ongoing mission reliability of Navy operations.

Navy bottlenose dolphins are valuable Fleet assets whose health and well-being are essential to sustaining mine countermeasures, port security, and object recovery missions. Medical issues compromise performance and have direct implications for Navy mission readiness, longevity, and reliability. Additionally, for the U.S. Navy to meet environmental compliance requirements under the Marine Mammal Protection Act and Endangered Species Act, it is essential to understand the effects of sound and military activity on marine mammals, including physiological, behavioral, ecological, and population-level effects. While technologies and techniques for assessing marine mammal health are growing rapidly, many barriers remain for these Fleet assets as well as other free-swimming large cetacean species that can be used as biological sensors of the undersea environment. A transformative diagnostic tool will provide unparalleled access to physiological data and biomarkers of health, stress, and disease from free-swimming cetaceans with applications in clinical care, operational biosurveillance, and conservation.Blood sampling of captive trained dolphins and/or stranded marine mammals enables researchers to evaluate individual and population health, age, genetics, exposure to pathogens and toxicants, and physiological responses to anthropogenic and natural stressors. By enabling minimally invasive blood sampling in free-ranging cetaceans, these animals can be used as biological sensors for persistent surveillance of the undersea environment, providing early warning of pathogens and other ecosystem stressors in operational waters. However, current blood collection methods in marine mammals are designed for use on stranded or captured individuals and are therefore limited in their capability of rapidly assessing health for larger free-swimming species. The lack of such a tool for health assessments is particularly urgent for Fleet animals and free-ranging animals in the region of deployment, where timely and accurate health assessments are essential for informing recovery efforts and mitigating population decline. As such, there is a critical need for a minimally invasive blood collection tool for remote application to the skin of free-ranging cetaceans to address significant gaps and improve our understanding of marine mammal health across spatiotemporal scales, providing unprecedented data on physiological responses, health metrics, and population dynamics.This SBIR Direct to Phase II topic seeks to develop a prototype minimally invasive blood collection device for remote application on free-ranging cetaceans by further developing an existing capillary blood collection device initially designed for humans. This prototype device should be able to be remotely deployed using current techniques used for the deployment of suction-cup electronic tags on free-ranging marine mammals (i.e., pole-based or drone dropped) under diverse environmental conditions. This prototype will include a blood collection device, waterproof housing, delivery device using suction cup tag carrier, and suction cup-based tag attachment. This prototype waterproof device should be capable of remotely deployable blood collection across cetacean species of varying epidermal thickness. The target size and weight of the blood collection device (not including the suction cup housing) should be approximately 3.40x2.25x1.30 in in size and weigh between 0.85 and 0.95 oz. This prototype device should sit flush and seal against the skin and use suction to draw 200-800 uL of capillary blood with minimal clotting into an internal reservoir (independent of orientation) and mix the sample with anticoagulants or other stabilization chemicals. At minimum the Phase II prototype should be able to collect blood samples from species with epidermis of < 2.5 mm thickness with a plan to successfully collect blood samples from species with epidermal thickness of > 10 mm. During this collection period, the device needs to make a narrow incision (< / = 0.15 mm in width, < 5 mm in length) such that rapid wound healing is possible. Further, the device needs to account for pressure variations underwater such that it detaches from the animal after a set time (< 3 minute duration) or when it reaches a critical depth or, at a minimum, be able to identify samples that may have ex vivo red cell hemolysis. In addition, the device will need to protect the blood sample from seawater intrusion. Blood samples collected via this prototype device need to have comparable blood test values to those collected via standard venipuncture methods through the Peri-Arterial Venous Rete (PAVR). As such, to optimize reliable blood collection from the prototype device, development must address challenges including clotting, lancing depth, and anticoagulant use.This minimally invasive blood collection prototype device will result in reliable remote deployment on free swimming cetaceans and significantly improve the capability to assess physiological responses and health measures in cetacean populations across spatial and temporal ranges. For the Navy Fleet bottlenose dolphins in particular, this prototype device will enhance the ability to detect health changes, reduce unplanned medical stand-downs, and provide more continuous health oversight by providing a minimally invasive diagnostic tool to detect infection and inflammatory markers, as well as subclinical infections. It will offer a novel tool to enhance systemic and organ-specific health monitoring, providing individualized biomarker data that can be applied to preventive medicine, geriatric care, and environmental health. Consistent with the Navy’s Clinical Research Pipeline, if this diagnostic tool proves successful, it will be integrated into the Navy’s Marine Mammal Program health program to directly improve the health and readiness of Navy dolphins, with potential translational benefits to conservation and human health. Overall, this device and its resulting data will directly support the warfighter, improve the reliability of Navy biological assets, support environmental compliance needs, and contribute to broader undersea warfare biosurveillence objectives.

Develop concepts and determine feasibility of existing blood collection device adapted to be suitable for marine species- in a compact, waterproof, remotely deployable, and cost-effective design, capable of collecting capillary blood samples from species with at minimum < 2.5 mm epidermal thickness. Develop key component technology milestones and conceptual designs for hardware. Develop plan for validation study comparing blood collected from this prototype device again collected from standard methods.FEASIBILITY DOCUMENTATION: Offerors interested in participating in Direct to Phase II must include in their response to this topic Phase I feasibility documentation that substantiates the scientific and technical merit and Phase I feasibility described in Phase I above has been met (i.e., the small business must have performed Phase I-type research and development related to the topic NOT solely based on work performed under prior or ongoing federally funded SBIR/STTR work) and describe the potential commercialization applications. The documentation provided must validate that the proposer has completed development of technology as stated in Phase I above.DoW Animal Use Requirements [Ref 4] should be taken into consideration when submitting proposals. The DoW Vet review process can take 2-3 months. Proposals can NOT be funded until all animal use documentation, permits and protocols are received by the SBIR Program Office and approved by the DoW veterinarian. Some of this documentation can take months to acquire, so investigators need to plan to submit paperwork to the SBIR program office once the proposal has been selected for funding.DoW Animal Use approval is not required at the time of proposal submission to this SBIR topic. However, the proposer must be prepared to provide all required animal use documentation at the time of proposal selection to ensure that this approval is received before the contract is awarded.

Develop prototype payloads and technology hardware based on adapting an existing capillary blood collection device (initially designed for humans) for use in a waterproof, remotely deployable device capable of collecting capillary blood samples from species with at minimum < 2.5 mm epidermal thickness in a compact, efficient, cost-effective design. Refine the prototype or plan to re-engineer the prototype device to iteratively test and successfully collect blood samples from across a diversity of species with epidermal thickness >10 mm. Deliver a prototype device for species with epidermal thickness < 2.5 mm and at minimum a plan for species with epidermal thickness of > 10mm at the end of Phase II, ready for integration and testing by the Government. Prepare and submit a Phase III commercialization/transition plan.

Support transition of the device to the Government and into the wider scientific community. Businesses that provide marine mammal monitoring capabilities to a wide range of government agencies having equities in marine life issues could leverage the devise. NOAA National Marine Fisheries, National Ocean Service, Office of National Marine Sanctuaries, Bureau of Ocean Energy Management, U.S. Geological Survey, and the U.S. Fish and Wildlife Service, among others would benefit from this capability. A key goal of this phase will be making the technology available to the broader research and Navy communities.

Develop a commercial technology to address Navy and USMC gaps regarding low-cost, NDAA-compliant heads-up displays (HUDs) with on-board 6 degrees-of-freedom (6DOF) tracking.

ONR requests proposals for existing technology demonstration platforms, prototypes, and commercial products that provide domestically-sourced, low-cost HUDs) for first-person view (FPV) drone pilots, and augmented reality (AR) capabilities for Forward Observers (FOs) and Joint Terminal Air Controllers (JTACs). For Phase I awardees, ONR will provide operational context and technical thresholds against which technologies will be assessed and provide feedback and guidance on enhancements to align with warfighting objectives. The proposing small business should have an existing hardware solution that meets one or both technical areas listed below:- HUD for FPV pilot operations including integrated display, signal inputs, and locations for mounting organic FPV equipment including antennas, transmitters, and power supplies- Integrated HUD with native 6DOF tracking, using on-board sensors and modalities (cameras, Inertial Measurement or Measuring Units [IMUs], magnetometers), compute, and power (battery)

The DON is planning to issue multiple Phase I awards for this topic but reserves the right to issue no awards. Each Phase I proposal must include a Base and Option period of performance. The Phase I Base must have a period of performance of six (6) months at a cost not to exceed $200,000. The Phase I Option must have a period of performance of six (6) months at a cost not to exceed $115,000. Phase I feasibility will describe the existing proposed technology, existing DON system(s) to improve/replace, expected improvements to existing capabilities, and a transition approach to both the DON system and commercial sector. Phase I results will be detailed in a final technical report (Final Report) and presented during the project outbrief one month prior to Final Report submission.Phase I deliverables include:- Kick-Off Briefing, due 15 days from start of Base award- Progress Report, due 90 days from start of Base award- Final Report, due 180 days from start of Base award- Quad Chart, due 180 days from start of Base award- Initial Phase II Proposal, due 180 days from start of Base awardThe Phase I Option, if exercised, will include the initial design specifications and capabilities description to build and deliver a prototype solution in Phase II.

All Phase I awardees may submit an Initial Phase II proposal for evaluation and selection. The evaluation criteria for Phase II are the same as Phase I (as stated in this CSO). The Phase I Final Report and Initial Phase II Proposal will be used to evaluate the small business’s potential to fill a capability gap, improve performance, or modernize an existing capability for DON and transition the technology to Phase III. Details on the due date, content, and submission requirements of the Initial Phase II Proposal will be provided by the awarding SYSCOM either in the Phase I contract or by subsequent notification.The scope of the Phase II effort will be specific to each project but is generally expected to include development of a functional prototype to demonstrate the capability, development of a transition plan addressing production and the fielding approach (including updated logistics and safety consideration) and further commercialization (non-DoW).

Support incorporation of low-cost HUDs into the Fires programs of record within the USMC for FOs, JTACs, and FPV drone attack operators. Since the Navy is seeking commercial technologies (e.g., FPV), these technologies already have existing commercial applications.

What are targeted unit price, field of view, eye-relief, diopter, display resolution, brightness, latency, weight, battery endurance, or tracking accuracy?Does an FPV-only submission satisfy the topic without native 6DOF tracking at entry?What minimum integration level is expected of the existing hardware, and can a teamed hardware platform satisfy that expectation?What cost basis and sourcing/compliance criteria should proposers use before ONR supplies the detailed thresholds?

Develop a technology to clean and potentially reverse fouling on Time Domain Reflectometer (TDR) Tank Level Indicating (TLI) components in-place. The solution must function within fully compensated fuel tanks aboard DDG 51 class ships without requiring depressurization, defueling, or dewatering.

Fouling on the TDR sensor used for TLI is a persistent problem. The TDR is necessary to provide accurate and precise readings for fuel measurement. Over time, TDRs can experience sensor fouling through a buildup of crystallization and other contaminants on TDR rods and tubes, contributing to false readings or other failures if not properly maintained and cleaned.The operational readiness of the U.S. Navy's DDG 51 Arleigh Burke-class destroyers is being undermined by a persistent and unsolved equipment failure. The TDR sensors, a TLI technique, which are critical for managing fuel, buoyancy, and stability, are consistently rendered unreliable due to fouling. Current cleaning methods are operationally untenable; they require taking fuel compensating tanks offline, emptying fuel and/or compensating seawater, and significant follow-on maintenance, which directly reduces the Fleet's readiness and deployability. These efforts are not a permanent solution and often fail to resolve the underlying issue, making this a high-priority challenge for the DDG 51 Program Office.The Navy urgently seeks an innovative solution that remedies fouled TDR units without requiring ships to cease operations or undergo costly, invasive maintenance, thereby increasing mission readiness and reducing the risk of fuel spills.Effective methods for cleaning these sensors in-situ are very limited. The existing approach involves decompensation of fuel tanks (removal of fuel and compensating seawater) and manual removal of TDR sensors for cleaning, which can be costly and time consuming. It is not generally feasible while the ship is underway. Removal of TDR sensors during these manpower-intensive efforts can sometimes lead to TDR sensor miscalibration during re-installation.The inability to effectively clean TDR sensor fouling is a critical point of failure. The buildup of crystallization and other contaminants on TDR rods and tubes creates false readings and electrical shorts, leading to inaccurate fuel measurement and extensive tracking errors. This directly compromises the precise fuel management necessary for the ship’s stability and mission readiness. Current ships have had fuel spills due to TDR TLI fouling. Additionally, scheduled maintenance periods to remove and clean fouled TDR TLI units inherently cause time delays and ship-wide disruptions affecting other planned work. . The Navy seeks a product that cleans and potentially reverses the fouling buildup throughout the entire TDR assembly while being compatible with the existing sensor architecture. The technology must return the installed TDR and TLI technique to full operational status upon one execution of the developed technology/technique over an objective period of 36 months, but not less than a threshold period of 8 months of full TDR TLI operability. This effort is required to develop a comprehensive technique that resolves this persistent reliability challenge. A more precise fuel management and reduction in potential failures will result in greater ship stability and increased mission readiness.

Develop a concept for a product/technology to clean a fouled TDR TLI in-situ, returning it to full operational status within the challenging environment of a compensated fuel tank. Detail how the cleaning technology would be employed on an in-service ship while underway. Establish feasibility through small-scale testing, analysis, or modeling. If the Phase I Option is exercised, include the initial design specifications and capabilities description to build a prototype solution in a Phase II plan.

Develop, deliver, and demonstrate a prototype of the anti-fouling solution that meets the requirements in the Description. Prove in a demonstration that the technology can return a fouled TDR TLI to full operability in a simulated confined space without requiring the tank to be emptied or causing fuel spills. Design the solution to minimize or eliminate the need for personnel to access the tank, a key limitation of current procedures. Identify all necessary Navy testing for shipboard certification. Prepare a Phase III commercialization/transition plan.

Support the Navy in transitioning the cleaning technology for Fleet-wide use, providing the necessary equipment, training, and logistical documentation. A successful solution to this problem on the DDG 51 class is expected to be highly applicable to other ships facing similar challenges with compensated fuel tanks and TDR TLIs, including the LHD 1 and LHA 6 classes. The goal is to field a fully qualified and certified solution that resolves this long-standing maintenance and readiness issue across the surface fleet.Commercial fuel tank farms as well as other industrial operations requiring high level of awareness of tank full status can benefit from development of this technology.

Develop a material/system to increase the fire-resistance of joiner bulkheads on ships and compartment-level fire containment while meeting Navy requirements for weight, fit, cost, fire, smoke and toxicity.

Fire represents a grave hazard to Navy vessels. Recent fire events have propagated through joiner bulkheads and resulted in significant fire damage, which poses a substantial threat to personnel and equipment. Uncontrolled fires can propagate throughout a ship and cause extensive damage to machinery, equipment, and ship compartments; additionally, fires represent an extreme risk to ship personnel. The Navy has made numerous improvements to make ships more fire-resistant but is seeking improvement for containment of compartment-level fire events seen in recent and historical ship fires (i.e., USS OSCAR AUSTIN, USS CONYNGHAM, USS STARK, and the cruise ship Star Princess). More fire-resistant joiner bulkheads would allow damage control teams to contain and extinguish fires more easily before they could grow to threaten the ship. Innovation is needed to meet Navy goals with regard to weight, cost, fit, and performance.The Navy seeks an improved fire-resistant joiner bulkhead that would reduce the damage ships sustain during fires, as well as improve safety for the crew. Development of a fire-resistant joiner bulkhead faces several technical challenges. First, any fire-resistant joiner bulkhead must not have a significant weight increase. Given the quantity of joiner bulkheads onboard ships, any weight increase could add significant weight to the ships, which will impair and degrade ship performance. Second, the improved joiner bulkheads must not excessively exceed the width of current joiner bulkheads. Destroyers have confined spaces and for the comfort and operational capability of the crew, any new joiner bulkhead cannot greatly exceed the dimensions of the existing panels. Third, any fire-resistant joiner bulkhead must be a cost-effective solution for the Navy. In particular, the fire-resistant joiner bulkhead must not substantially increase the costs to install at the shipyard. The reason for this concern is that joiner bulkheads sometimes require modification at the shipyards to fit the exact dimensions of the ship. Any solution that requires expensive edge treating or would otherwise be cost-prohibitive to modify at the shipyards will not be considered. Lastly, the improved joiner bulkhead must meet or exceed the requirements to be certified for shock and fire performance as AN-30 class per MIL-STD-3020 and pass Navy Fire, Smoke, Toxicity (FST) testing per MIL-STD-1623. This is a vital requirement to demonstrate that any new material in the joiner bulkhead will not release dangerous particulates as it burns or fails if there is an impact.Research into fire-resistant materials has revealed several technology advances in the areas of intumescent coatings, coatings that incorporate nanomaterials to aid in thermal regulation, or advanced high-performance fibers; however, there is no current commercial solution available. The Navy is also open to bio-composites, bio-polymers, or other materials that have the potential to provide superior fire-resistance with reduced toxicity as compared to many commercially available products.

Develop a concept for a fire-resistant joiner bulkhead that meets the requirements above. Demonstrate the feasibility of the concept in meeting the Navy needs prescribed above and establish that the concept can be developed into a useful product for the Navy. Establish feasibility of a new fire-resistant material/system via small-scale testing. If the Phase I Option is exercised, include the initial design specifications and a capabilities description to build a prototype solution in Phase II.

Develop and deliver a prototype fire-resistant joiner bulkhead for evaluation. (Note: The prototype will be evaluated to determine capability in meeting the performance goals defined in the Phase II SOW.) Demonstrate product performance through prototype evaluation, modeling, and demonstration over the required range of parameters as defined by the Navy. Participate in an extended evaluation in a land-based test environment to refine the prototype into a design that will meet Navy requirements. Prepare a Phase II manufacturing and development plan, including drawings of connection details, to transition the improved fire-resistant joiner bulkhead to Navy use.

Support the Navy in transitioning the fire-resistant joiner bulkhead to Navy use. Develop installation and maintenance manuals for the improved fire-resistant joiner bulkhead to support transition to the Fleet.Many potential commercial applications for improved fire-resistant joiner bulkheads exist; examples include commercial shipping, construction, aerospace, and automotive industries.

Develop a dust-protected, water splash-resistant Input-Output Unit (IOU) capable of interfacing with legacy and modern equipment to send, receive, process, and route signals throughout the hull and superstructure of naval vessels.

IOUs are used on all Navy DDG 51 class ships to transfer Steering Control, Machinery Control, and Damage Control signals, as well as Interior Communication Alarm and Indication, Synchro and Digital Navigation data. They are also used on USN LHA(R) class ships, in Aegis Ashore facilities, and across a variety of Foreign Military Sales (FMS) cases. IOUs serve as a translation point when sending and receiving non-Ethernet traffic, such as synchro and low-level serial data, to Ethernet user systems. IOUs are installed in a variety of air-conditioned and non-air-conditioned spaces. Their use in engineering spaces that historically have relied on Halon 1301 (safe for sensitive electronics) for fire suppression has been complicated by the Navy’s transition away from Halon and toward water mist protection systems. Additionally, existing IOUs rely on the integration of a wide variety of circuit card assemblies (CCA) to process different types of signals, creating hardware challenges for lifetime support and technology refresh. The Navy seeks to reduce lifecycle costs with a simplified design that has fewer hardware dependencies, hardware component updates, and more open and modular system architectures. The IOU is intended to be operated continuously. The IOU shall be designed to permit routine maintenance and troubleshooting. Repair actions should be possible while the IOU is energized without loss of required functionality and operating. Reliability and Survivability are essential and all IOU components must demonstrate Mean Time Between Failures (MTBF) in excess of 10,000 hours. While the IOU as a whole product does not exist commercially, the base technology required is available in industry. The focus of this SBIR topic is to integrate the capabilities into a synergized product.Requirements:The Navy requires a dust-protected, water splash-resistant (IEC 60529 IP54-rated) IOU capable of interfacing with legacy and future equipment to send, receive, process, and route signals throughout the hull and superstructure of naval vessels. The enclosure must protect the power supply, cooling components, and electronics necessary to connect serial (RS-232, RS-422, RS-485, NTDS-E), fiber Ethernet, Cat 5 Ethernet (unicast, multicast), analog synchro (60 and 400 Hertz), and analog voltage (AC and DC) capabilities. External connections are made by triaxial, 42-pin, and 92-pin cables, as well as fiber optic connectors to redundant Gigabit Ethernet (GbE) shipboard networks. Design must accommodate an additional fifty percent capacity for future growth from initial defined design specifications and capability descriptions. It must also provide adequate internal cooling while meeting or exceeding IP54 dust and spray requirements.All hardware components must be compliant with Restriction of Hazardous Substances (RoHS) directive 2011/65/EU.Enclosure:Maximum size and weight (excludes external mounting dimensions): Weight: 188 pounds; Depth: 17 inches; Width: 26 inches; Height: 27 inches.The IOU must be mountable from the rear or the bottom and allow cable attachment/removal and reasonable access to all user interfaces and cable attachment points in any mounted configuration.Power Supply:Internal Alternating Current (AC) power supply will connect to two independent 120V, 60Hz shipboard lighting circuits (2 of 3 phases) for redundancy. Synchro reference power (400Hz and 60Hz) is necessary for some user interfaces (separate from IOU AC power). IOUs should require less than 600 Watts of power when fully loaded. IOU must strictly comply with MIL-STD-1399-300, operating reliably on both Type I and Type II power. The design must tolerate all specified voltage and frequency fluctuations, withstand severe voltage spikes, and limit maximum instantaneous input current (inrush current) when initially energized. To maintain ship-wide power quality and ensure system compatibility, the IOU must also adhere to strict limits on harmonic distortion, maintain a high-power factor, and meet the electromagnetic interference (EMI) and electromagnetic compatibility (EMC) requirements of MIL-STD-461. To ensure the IOU design is suitable for shipboard environments, the IOU must meet the requirements of the latest revisions of MIL-STD-810 (currently Rev H with Change Notice 1), MIL-DTL-901 (currently Rev E), MIL-STD-167 (currently Rev 1A with Validation Notice 1), and MIL-HDBK-2164 (currently Rev A), IOU must remain fully operational through momentary power interruptions from the selected power source. If all AC power is lost, the IOU will automatically restart within 30 seconds following restoration of at least one power source. Adequate cooling must be maintained in any power-on condition. User Interfaces, Routing, Processing:IOU must adhere to a defined set of core networking standards. The unit must ensure full compliance with the foundational protocols for internetworking, including IPv4 (RFC 791) and IPv6 (RFC 8200). To support efficient one-to-many data distribution, the IOU must implement IP Multicasting (RFC 1112). For high-availability and fault tolerance, the IOU must also support the Parallel Redundancy Protocol (PRP) in accordance with IEC 62439-3.Fiber optic cables connecting the IOU to shipboard networks will be supplied by the shipbuilders and will utilize a four-fiber cable per MIL-PRF-85045/18 with a fiber cable class of single mode per MIL-PRF-49291/7. Reliance on legacy hardware and proprietary data currently limits the Navy's ability to use open competition. Updating the design to include commercially available components will eliminate these constraints and significantly reduce lifecycle costs.

Develop a concept for an IOU that meets the requirements described above. Demonstrate through modeling and simulation and other supporting documentation the efficacy of the proposed system design for satisfying prototype system requirements. If the Phase I Option is exercised, include the initial design specifications and capabilities or description to build a prototype solution in Phase II.

Construct, test, and deliver a prototype in accordance with the above Description that can be inserted in a network lab environment to verify continuity and throughput of all required signal types with legacy connections. Ensure that the prototype must demonstrate adequate cooling capability under sustained heavy loading and meet or exceed IP54 as verified by testing in accordance with IEC 60529 (Ingress Protection codes for electrical equipment enclosures) and MIL-STD-1399 (Shipboard Electric Plants), paragraph 300F.

With enclosures that maintain adequate cooling while maintaining IP54 protection, IOUs may continue to be used in a wide variety of shipboard spaces and use could be more readily expanded to commercial industrial operations. Future designs could investigate expanding processing and storage capability at IOUs to create distributed processing capabilities across industrial networks or translate hardware signals to a cloud architecture. Additionally, IOUs could be tailored and optimized for specific activities or modified for use in other types of networks or at higher classification levels.Support the Navy in transitioning the IOU technology for fleet-wide use, providing the necessary equipment, training, and logistical documentation.Potential commercial applications for an IOU include commercial maritime systems, offshore extraction, and advanced industrial processes.

Develop, integrate, and flight-test a high-altitude (=40,000 ft), high-speed (~400 knots) airborne geologic sensing system. The system must be capable of providing rapid, stand-off 3D subsurface tomographic imaging to detect subterranean features such as metals and critical minerals.

Detecting and mapping deep subsurface mineral deposits typically requires localized or low-altitude operations. Current state-of-the-art airborne subsurface radar systems are limited to relatively low-altitude and low-speed platforms due to the physical limitations of signal attenuation over distance. Increasing altitude and airspeed would allow for larger areas to be scanned in less time.This topic seeks the rapid development of an advanced airborne system designed for the seamless integration onto high-altitude fixed-wing aircraft. Proposers must address the physical scaling laws of radar propagation through lossy media. According to the radar equations for small targets of a radar cross section of approximately one wavelength, the necessary transmit power scales as a function of range to the fourth power (R4). For instance, transitioning from a 10,000 ft baseline to a 40,000 ft operational altitude represents a 4x increase in distance, nominally demanding a 256x increase in radiated power to maintain equivalent subsurface imaging performance.Due to the higher power requirements at higher altitudes, system designs must prioritize transmit power scaling, advanced antenna structure designs, and robust heat dissipation systems.To facilitate rapid, modular deployment across diverse airframes without requiring permanent, costly aircraft modifications, the entire system must be designed as a fully self-contained payload. It must utilize independent, internal power generation and an edge computational architecture. Key technical challenges that proposers must address include: 1. High-Power Transmitter & Power Scaling: Engineering and validating a highly reliable kW-class RF power amplifier.2. Aerodynamic & Structural Antenna Design: Designing and reinforcing an externally deployable or structurally integrated antenna system capable of withstanding aerodynamic loads at relevant velocities (~400 knots) and altitudes (~40,000 ft).3. Thermal Dissipation & Management: Integrating passive or active high-capacity heat dissipation systems to mitigate thermal loads under sustained high-power transmit cycles.4. RF Shielding & Electromagnetic Compatibility (EMC): Implementing advanced RF shielding and electrical isolation to guarantee zero electromagnetic interference with the host aircraft’s flight navigation, control, and mission avionics.5. Field-Programmable Gate Arrays (FPGAs) & Edge Processing: Selecting FPGAs and processing techniques that can handle increased signal propagation delays, modified waveforms, and real-time tomographic data processing at high standoff distances.

This topic is soliciting Direct to Phase II (DP2) proposals only. Proposers must submit feasibility documentation in lieu of a Phase I proposal. Proposers must demonstrate that they have already developed, integrated, and validated an airborne subsurface radar or similar system in a physical environment (e.g., low-altitude, low-speed flight regimes up to 10,000 ft). Modeling and simulation data alone is not sufficient to prove feasibility. The submitted feasibility documentation must include: 1. Empirical Flight Data: Representative 3D tomographic subsurface reconstructions, signal-to-noise ratio (SNR) calculations, and imagery demonstrating successful detection of underground mineral deposits.2. Receiver Characterization: Technical documentation proving the receiver operates at a low thermal noise floor.3. Analytical Scaling Models: Detailed physical, mathematical, and electromagnetic models validating the R4 scaling equations and mapping the exact architectural transition from a low-power baseline to a high-power, high-altitude design.

Phase II is an accelerated hardware realization, integration, and flight-testing campaign. Fixed Payable Milestones for this program should include:Base Period (18 Months)• Month 2: Subsystem Engineering – Preliminary Designs for the power amplifier, motherboard, and high-efficiency heat dissipation structures. Initial report on updated firmware architecture.• Month 4: Subsystem Design Completion - Finalized engineering designs for all major subsystems.• Month 6: Structural Antenna Engineering Interim Report #1 – Manufacturing progress and initial benchtop testing for the power amplifier and antenna assembly to survive aerodynamic loads of ~400 knots.• Month 9: FPGA and Compute Development Interim Report #2 – Progress on integrated systems testing, including initial results from tomographic reconstruction algorithms at the edge.• Month 12: Safety and Test Readiness Review (TRR) Data Package – Comprehensive safety testing results on high-voltage and high-power RF emissions and flight clearances documentation.• Month 15: High-Altitude Flight Campaign Interim Report #3 – Preliminary data from demonstration flights on a fixed-wing platform at ~40,000 ft and speed of ~400 knots, including measurements of radiated power and signal penetration.• Month 18: Data Analysis and Final Base Period Report – Detailed analysis of flight data, fully reconstructed 3D subsurface tomograms of test sites and system performance evaluation.Option Period (6 Months)• Month 21: Interim Report #4 – Detailed data analysis, algorithm enhancement, and performance improvements of the prototype system.• Month 24: Comprehensive Final System Assessment Report – Final evaluation of performance, including 3D subsurface tomogram data of relevant structures, against a low-altitude baseline and commercial viability analysis.

The high-altitude geological sensing system represents a highly disruptive dual-use technology:• Military/DoD Applications: Identifying additional domestic sources of critical minerals is a national security imperative that will improve access to materials needed for advanced defense systems. This capability would strengthen U.S. supply chain for critical minerals.• Commercial/Civil Applications: Acts as a highly scalable "MRI for the Earth." The system could map deep-seated geologic structures to rapidly locate critical mineral reserves and rare earth element deposits buried under hundreds of meters of geology. This significantly accelerates discovery timelines, increases exploratory extraction success rates from 1-in-200 to near certainty, and optimizes geologic risk management.

Develop and demonstrate a real-time, networked pest detection, identification, and surveillance technology that provides actionable New World Screwworm (NWS) detection and identification accuracy, system reliability, low maintenance, and long and unattended operation.

New World Screwworm (NWS or Cochliomyia hominivorax) larvae infest the living tissue of warm-blooded animals. NWS is prevalent in South America and the Caribbean, and it is estimated that re-entry of NWS into the United States could cost US cattle producers $732 million per year [USDA, 2025]. Screwworm flies lay eggs in open wounds. The eggs hatch into maggots (larvae) that eat live tissue, causing a worsening, often painful and foul-smelling wounds [CDC, 2025].Wildlife and free-ranging animals are an important pathway for New World Screwworm to spread, making surveillance beyond livestock essential [Arizona, 2026]. However, the current state-of-the-art for NWS detection and tracking being used at the US Southern Border involves three types of traps (sticky fly traps, liver-baited net traps, and gator traps), all of which require manual servicing, fly collection, and fly delivery to a laboratory [USDA, 2026a] [USDA, 2026b]. The state-of-the-art lure to attract NWS flies to a trap is Swormlure-5 [Hickner, 2023], a synthetic bait based on a mix of volatile organic and volatile sulfur compounds; however, such baits are not specific to NWS and can lure other species [Hickner, 2023]. The US Department of Agriculture (USDA) has deployed over 100 NWS-specific traps and lures across high-risk areas of U.S. Border States and is leveraging thousands of fruit fly/insect traps all along the Southern Border. Suspected NWS samples are forwarded for official confirmation to the USDA National Veterinary Services Laboratories (NVSL) in Ames, Iowa, the national reference lab responsible for screwworm diagnostics [USDA, 2026c].Thus, a real-time, autonomous, persistent, networked NWS detection, identification, and surveillance system is necessary for accurate and timely tracking and forecasting of the movement of the New World Screwworm. Such a system must operate reliably in rugged, remote regions lacking power and communications infrastructure by leveraging on-board data processing and machine learning analysis. This can enable on-board insect identification (e.g., using low-power, localized optical, acoustic, electrical, and/or chemical sensing) and eliminate the need for manual sample collection and laboratory diagnostics. Furthermore, these devices must form resilient, low-bandwidth ad-hoc networks to transmit real-time, highly compressed detection telemetry, enabling NWS movement forecasting and biosecurity intervention even in remote and disconnected environments.

This is a Direct to Phase II topic only: The Government expects that the small business has accomplished the following in a Phase I-type feasibility effort and developed a prototype NWS Distributed Detection System to address, at a minimum, the basic requirements of the stated objectives above. For this Direct-to-Phase II SBIR, a technical report containing Phase I Feasibility Documentation is required to demonstrate that Phase I feasibility has been met. The Phase I Feasibility Documentation must contain a detailed description of the technical plan, milestones, and data substantiating that they have designed and field-tested a functional, low-power Distributed Detection System prototype outside of the SBIR program. This feasibility report must provide empirical data verifying that the physically demonstrated sensor platforms can successfully isolate and identify target insects, while operating on strict energy budgets and seamlessly transmitting synchronized threat data across a coordinated wireless network.

The goal of this SBIR Direct to Phase II effort is to develop and validate an effective and efficient networked NWS monitoring device. Thus, the DP2 effort will develop, integrate, validate, and demonstrate the following:A scalable, networked NWS detection, identification, and surveillance system suitable for areal coverage as large as national bordersImproved NWS lure over Swormlure-5Greater NWS selectivityIncreased lure attraction range to reduce the number of traps neededVolatility consistent with a one-month maintenance intervalImproved NWS trap designNo dependence on sticky coatingsUnattended trap/device operation, including advanced pest identification that does not require manual insect collection and laboratory analysisRemote user communications with the trap/device and communications between traps/devicesOn-board detection, identification, and surveillance hardware and softwareSingle or multi-sensor design, e.g., capacitive, optical, and/or optoacousticHigh NWS Probability of Detection/Probability of False Alarm (Pd/Pfa) to provide for actionable decision makingCapability to distinguish between NWS and related species such as Cochliomyia macellariaCapability to distinguish between marked sterile and non-sterile NWSRemotely upgradable codeEnables NWS movement forecastingCapability to handle multiple pests via code update Low maintenanceBattery life of a minimum of 3 months, assuming low NWS prevalence and a strong user-device and device-device network signalRequired maintenance (e.g., lure refreshment) interval of two weeks or longerSimple, rapid maintenance procedureLightweight, easily deployed, low costApproximately 15 cm x 15 cm x 15 cm, 600 gThe performer must have access to an ACL-3 test facility. The system demonstration must be conducted at TRL 6 using a prototype system in a relevant environment. DP2 will also require commercialization and transition planning along with technology development. Throughout the phase, the proposers must collaborate with commercial and government end-users to refine operational requirements and deployment scenarios of their developed solution. Manufacturing and scaling plans for production must also be developed before the end of the Phase. The final report must also include technology transfer documents outlining planned opportunities for commercial and government applications. DP2 Base milestones for this program should include:Month 1: Identify the candidate sensor technologies, lure chemistries, and device physical design.Month 3: Initial test results for various sensor and lure combinations integrated into a device. Finalize the device sensor(s) and lure chemistry options. Develop the prototype device design and device test plan.Month 6: Assemble at least four prototype devices and collect initial test results for the prototype devices, individually and networked. Begin battery life and lure longevity testing.Month 9: Collect initial NWS Pd/Pfa results against unrelated and related insects (e.g., Cochliomyia macellaria).Month 12: Refine the sensor subsystem for improved NWS detection and identification. Initial networked system demonstration, including remote user-device and device-device connectivity and remotely upgradable code.DP2 Base deliverables should include:Month 1: Sensor and lure candidate(s) selection and design of experiments report.Month 3: Sensor and lure test results report, and device design and test plan.Month 6: Report describing test results for individual and networked devices.Month 9: Report describing NWS detection and identification results against unrelated and related insects. Included updates to sensor design and lure technologies.Month 12: Phase II feasibility report documenting device and system design, testing and validation, performance to date, manufacturing and scaling plans, and commercialization/transition plan.DP2 Option 1 milestones should include:Month 15: Design scale-up to pilot plant quantities.Month 18: Prototype system demonstration in a relevant environment.DP2 Option 1 deliverables should include:Month 15: Report documenting pilot plant design and operations.Month 18: Report on field demonstration resultsDP2 Option 2 milestones should include:Month 21: Scale-up to pilot plant quantities.Month 24: Final performance testing and commercialization plan. .DP2 Option 2 deliverables should include:Month 15: Report documenting pilot plant design and operations.Month 18: Final report on system design and performance, and commercialization/transition plan.

Successful development of an NWS distributed detection and surveillance system will have significant applications in both military and commercial sectors. The most direct DoW application involves force protection disease vector control. In addition, the distributed insect detection technology may expand to non-agricultural/disease prevention applications such as insect swarm behavioral changes as a proxy for human activities. If the pest sensor/ID device can be made multifunctional in terms what it senses (e.g., movement/vibration or a chemical moiety), applications can expand farther into areas such as vehicle detection or an electronic “sniffer”. The key commercial application is agriculture protection for both crops and livestock, which also overlaps with National Security.

Demonstrate a capability that noninvasively detects and localizes occult (internal) non-compressible hemorrhage outside of a hospital.

TThe goal of this development effort is to produce a noninvasive or minimally invasive capability that enables Role 1 medical personnel (specifically, a combat medic with no surgical or pre-operative imaging expertise) to rapidly detect, localize, and characterize the rate of life-threatening, occult, or non-compressible torso hemorrhage (NCTH) that cannot be precisely identified through routine clinical assessments available in the field. The proposed solution should integrate advanced sensing technologies with artificial intelligence to provide accurate, real-time detection, anatomic localization, and quantitative or semi-quantitative estimation of bleeding rate, distinguishing slow or self-limiting hemorrhage from rapidly expanding, exsanguinating hemorrhage, and should function in austere and contested environments. The capability should support serial or continuous monitoring such that changes in hemorrhage rate can be tracked to provide updates to the medic in near-real time. Solutions should provide intuitive, actionable visualization of both hemorrhage location and rate to support timely medical decision-making, triage, and evacuation prioritization when definitive surgical care is delayed or denied.

Demonstrate the technical feasibility of a noninvasive or minimally invasive capability for rapid detection, anatomical localization, and characterization of life-threatening occult or non-compressible hemorrhage. The performer shall develop a proof-of-concept sensing and artificial intelligence framework capable of accurately identifying the anatomical source of bleeding and estimating hemorrhage rate for a limited set of representative injury types. Scanning may be performed manually or using an automated platform (e.g., robotic or assisted acquisition) and should provide clinically actionable results within a timeframe compatible with Role 1 medical decision-making.Proposals shall describe the envisioned concept of operations, including sensor placement or access method (for minimally invasive approaches), data acquisition, user workflow, system-guided adjustments to sensor positioning or data collection, data processing, reporting, and, where appropriate, serial or continuous monitoring. Proposals shall describe the sensing technologies to be employed, their anticipated technology maturity, the proposed AI algorithms and training strategy, available datasets, and any additional data collection planned during Phase I. Representative testbeds may include retrospective clinical datasets, computational models, physical phantoms, ex vivo preparations, or controlled preclinical studies.Phase I efforts should establish the technical capabilities and limitations of the proposed approach, including the minimum and maximum resolvable hemorrhage rate, localization accuracy, anatomical applicability (including challenging locations such as retroperitoneal hemorrhage or bleeding obscured by bone or bowel), and expected robustness across representative operational conditions. Proposals shall define quantitative performance metrics for hemorrhage detection, localization, bleeding-rate estimation, response time, and operational robustness under austere conditions, including environmental stressors, limited power availability, transportation, storage, and deployment. While field-ready systems are not required, proposals utilizing components with demonstrated field suitability will be viewed favorably. The Phase I effort should culminate in a proof-of-concept demonstration and a detailed technical development plan supporting maturation into an integrated prototype during Phase II. Phase I proposals shall present tasking and relevant milestones for a 6-month base period.

Phase II will build upon the successful Phase I demonstration by developing, integrating, and validating a portable prototype capable of real-time hemorrhage detection, anatomical localization, bleeding-rate estimation, and longitudinal monitoring across a broader range of clinically relevant battlefield injuries. Phase II should emphasize engineering maturation, system integration, and operational validation rather than fundamental sensor development. The sensing hardware architecture established during Phase I should remain substantially unchanged, with improvements focused on optimization, robustness, algorithm refinement, and user-centered operation. Performers shall expand system performance to encompass additional solid organs, vascular structures, and clinically relevant hemorrhage scenarios while collecting additional datasets to improve algorithm performance, robustness, and generalizability. The system shall support serial or continuous assessment of hemorrhage progression, enabling near-real-time updates of bleeding location and rate. The integrated prototype shall provide intuitive clinical decision support suitable for Role 1 medical personnel, including actionable visualization of hemorrhage location, bleeding rate, confidence estimates, injury implications, and recommendations supporting triage, treatment prioritization, and evacuation decisions. Validation should be conducted using representative preclinical, cadaveric, clinical, or other operationally relevant test environments, with performance evaluated under conditions representative of austere military operations, including motion, environmental stress, limited logistical support, and communications degradation where appropriate. Proposals shall define quantitative Phase II performance metrics for detection accuracy, localization precision, bleeding-rate estimation, response time, longitudinal tracking performance, robustness, usability, and operational suitability. Phase II should conclude with delivery of an integrated prototype, validation results demonstrating operational feasibility, and a transition strategy supporting military evaluation, regulatory planning, manufacturing, and commercialization. As with Phase I, proposals shall define envisioned Phase II metrics for success in the detection, localization, and characterization of bleeding. Phase II proposals should enumerate the planned list of injury targets planned for characterization. Phase II proposals shall present tasking and relevant milestones for a 12-month base period, and separate tasking and milestones for a subsequent single 12-month option period. Direct to Phase II (DP2) Requirements:DP2 proposers must provide documentation demonstrating they have already achieved the feasibility milestones expected at the conclusion of a Phase I effort. Specifically, proposals must demonstrate existing evidence of:Proof-of-Concept: An established sensing and AI framework capable of accurately identifying the anatomical source of occult/internal bleeding.Hemorrhage Rate Estimation: The ability to quantitatively or semi-quantitatively estimate hemorrhage rates to distinguish slow bleeding from rapidly expanding hemorrhage across various injury profiles.Performance Metrics: Tested parameters detailing the minimum/maximum resolvable hemorrhage rates, localization accuracy, and anatomical applicability (including challenging areas such as retroperitoneal hemorrhage).Operational Robustness: Preliminary data indicating the approach can withstand austere conditions, including environmental stressors and limited power availability.

Military Application (Battlefield):The developed noninvasive hemorrhage detection system transitions directly to military operational medicine, specifically empowering Role 1 combat medics. In austere and contested environments where definitive surgical care or medical evacuation (MEDEVAC) is delayed or denied, this portable technology provides critical clinical decision support. By continuously monitoring non-compressible torso hemorrhage (NCTH) progression, medics can perform highly accurate triage, prioritize life-saving interventions, and optimize evacuation scheduling for casualties with exsanguinating hemorrhage versus those with self-limiting bleeding.Civilian/Commercial Application (Remote Disaster Areas):In the civilian sector, this technology holds significant dual-use potential for emergency medical services (EMS), search-and-rescue teams, and disaster response units. During mass casualty incidents or natural disasters (such as earthquakes or severe storms) where infrastructure is damaged and access to hospital imaging is impossible, first responders can use this tool to rapidly detect occult internal bleeding at the point of injury. It provides paramedics with real-time, actionable data to prioritize helicopter transport or specialized trauma center routing for critically internally injured patients in remote or rural environments, ultimately reducing preventable mortality outside of the hospital setting.

Develop a testbed utilizing economic frameworks to benchmark AI biases in dynamic environments. This tool will evaluate how agents adapt, collaborate, or deceive within a simulated marketplace. Ultimately, these assessments will ensure safe and effective AI integration in high-stakes decision-making.

This topic seeks to develop a simulated market as a test environment to characterize the latent behavioral preferences of AI systems.As warfighters increasingly engage with AI systems, particularly agents that rely on large-language models (LLMs), concern has arisen that the systems may encourage cognitive behavior in users that impart hidden biases, impair judgement, and ultimately degrade warfighting capacity. For example, overreliance on AI-powered decision support tools may induce users to accept erroneous suggestions or change from correct decisions to incorrect decisions (Buçinca et al, 2021). LLM use may also induce novel cognitive biases (Alessa et al. 2025) and amplify delusional beliefs (Dohnány et al. 2025). Compounding the threat, deceptive strategies frequently emerge among interacting AI systems (Ying et al. 2026). Few tests of AI systems account for their adaption to dynamic data, which obfuscates such adaptive strategies. To detect and combat these risks, the DoW requires a universal approach to elicit, characterize, and compare the behavior of AI agents amid changing contexts (Li et al. 2026). Such a testbed shall rely only on queries and outputs of the subject AI system, rather than direct access to the model itself. Economic frameworks permit the measurement and comparison of decisions. As the basis of extensive prior research, models of auctions, markets, and other economic arenas provide a critical baseline of organic patterns of human behavior (e.g. Hausch 1986, Martinez-Saito 2019). Emerging open-source tools, such as Magentic Marketplace (Bansal et al. 2026) have shown promise in revealing behavioral variations in market-focused contexts. Furthermore, unlike existing assessments of AI risk, economic frameworks do not rely on a priori definitions of “harmful” or “helpful” traits (Vijayvargiya et al. 2026), and these testbeds allow for diverse social strategies such as deception and collaboration.

The goal of Phase I is to develop and define the architecture of the test environment and demonstrate a functional proof of concept for a simulated auction or market (heretofore “market”). The test environment must be able to accommodate different models of auctions and markets to evaluate agents on different measures of market efficiency. Proposers must also develop classifiers to detect biases in AI agent behavior and outcomes in the market environment. This test environment should be a sandbox in which multiple AI agents may operate. By Month 2, proposers should have defined the core mechanics of the test environment, such as market structures, payout schemes, measures of market efficiency and consumer utility, and a dynamic “news feed” that informs the behavior of AI agents within the market. The “news feed” is meant to simulate public information relevant to the market. By Month 6, proposers should establish a strategy for scaling issues and define how AI agents interact through their decision space: a set of bids, each of which is defined by the time, asset, quantity, and price offered/requested on the market. By Month 9, proposers must demonstrate a suite of “stock” AI agents for use within the test environment. These AI agents shall only be used within the test environment sandbox and shall not be used on other systems. By Month 12, proposers should have a proof-of-concept test environment for assessing behavior preferences of AI systems amid dynamic data. In the proof-of-concept, the test environment must be able to replicate bidding patterns and allocation efficiencies observed in markets and demonstrate allocative efficiencies of >90%. The environment and associated data must be sufficient for comparison to models of human behavior in auctions or markets, as well as to compare agents to one another. Phase I fixed payable milestones for this program should include:• Month 2: Report on initial architecture and core mechanics of test environment and classifiers of AI agent behavior• Month 6: Report on scaling and AI agent interaction within the test environment• Month 9: Month 9: Demonstration of a suite of stock AI agents, drawn from at least 10 different LLMs, operating within the test environment.• Month 12: Demonstration of test environment and AI agent behavior within the marketplace, with allocative efficiencies of >90%

Proposers submitting Direct to Phase II should be able to demonstrate an existing test environment that meets the criteria outlined in Phase I. In Phase II, proposers should develop a range of AI agents as stock reference models against which the performance of a test AI agent may be compared. Proposers must define an error function that describes differences between AI agent decisions and expected human results. The stock AI agents should help identify and bound agent behaviors of concern, such as hidden biases. At least one AI agent should represent the human user of the test AI agent, to explore how the test AI agent may drive human behaviors of concern such as encouraging delusions or eroding military discipline. Proposers should define analytics to compare the behavior of the AI agents. By Month 6, proposers should have a suite of such stock AI agents, representing both human and native AI agent behavior. Agents should be able to interact with other agents in the test environment to develop strategic bids in an attempt to influence the behavior of other market actors to maximize their expected profit. By Month 12, proposers should demonstrate and measure how each AI agent responds to the “news feed” and the observable behavior of other agents, which alters each agent’s expectation of future asset values and behaviors of other agents. By Month 15, proposers should assess social interactions among AI agents to model behaviors including, but not limited to, collaboration and deception. Proposers must provide quantitative metrics on how social behaviors between AI agents alter market efficiency and outcomes and generate testable hypotheses for how latent AI agent preferences affect social interactions, dynamic responses to external stimuli, and ultimately market outcomes. By Month 18, proposers should test their own hypotheses across a range of AI agents and quantify differences between human-like agents and AI agents. By Month 21, proposers should demonstrate the test environment to DARPA, and deliver software and data for testing by U.S. Government partners to ensure that the environment may be used to reliably characterize the latent preferences of a test AI agent. By Month 24, the proposers should deliver a final report describing the performance of the test environment and AI agents, and include a transition plan. Phase II fixed payable milestones should include:• Month 2: A report on new capabilities that will be added to the test environment to enable analysis of dynamic AI agent behavior and outcomes. Provide definitions of an error function to compare AI agent decisions vs human decisions, as well as measures for comparing distributions of human and AI agent market outcomes.• Month 6: Demonstration of “human” stock AI agents that replicate human preferences and behavior in the market, and a report on how a “human” stock AI agent simulates expected human interaction in the market. Test Phase I classifier’s ability to distinguish “human” vs. AI agents in the market environment, and propose improvements to classification algorithm or alternative test statistics• Month 12: Report on dynamic behavior of AI agents in response to news events and observed actions of other agents within the test environment. Evaluate agent behavior using improved classifiers.• Month 15: Report on modeling social interactions between AI agents, including impact on bidding behavior of AI agents• Month 18: Report on how latent AI preferences impact social interactions between AI agents, dynamic responses, and market outcomes.• Month 21: Final software delivery, both object and source code, for operation by DARPA or other U.S. Government personnel for additional demonstrations, with suitable documentation in a contractor proposed format• Month 24: Final report, including quantitative metrics on AI agent behavior and fidelity of the test environment. The report must also discuss advances in LLM models and AI agents that have occurred during the period of performance and their potential impact on the evaluation of AI models.

The potential risk of AI systems inducing harmful behaviors is a major commercial concern due to the associated legal and reputational risk to their developers. AI firms are actively seeking mechanisms to argue the limits of their systems’ biases and impacts on user behavior, including measuring deviations from expected human norms of behavior, in response to lawsuits. The impact on a firm’s stock value of establishing the scope of liability far exceeds the already-robust immediate financial consequences of these court cases, suggesting that the AI firms have strong market demand for the capability to benchmark the influence of their systems.

A software tool to predict casualty/patient streams and needs following large scale medical emergencies in austere environments, and project the lifesaving potential of various response options with limited or no access to real-time data or communications.

The challenges underlying crisis medical response in austere and contested environments are significantly different than those underlying long-range planning or response in established theaters. Strategic and operational planning decisions are made in ample time with full situational awareness regarding the scope and nature of medical needs, availability and positioning of resources, and the immediate and emerging state of the theater. Crisis action decisions must often be made in much shorter time frames, using sparse, low-quality situational data that cannot be verified due to lack of secure communications and denied, disrupted, intermittent, and limited-bandwidth (DDIL) states. Furthermore, as resource allocation for medical response must be constrained by tactical and logistical requirements, the medical benefits of early and best medical response must be weighed against the tactical demands of the mission objectives. Thus, in scenarios where theater realities drive the timing, level, and means of medical response, decision makers must rapidly devise multiple optional courses of action and optimize their selection to accommodate tactical and logistical limitations. Without quantitative metrics assigned to the medical benefits of each response option, these lifesaving decisions must be made using multiple channels of low-quality situational data to obtain subjective medical benefits.This topic seeks proposals for solutions that assist users with medical response decisions in austere environments with variable access to communications or situational data. The desired product will be focused on automated prediction of casualty/patient streams, identification of the related medical needs with variable latencies, and metrics-based evaluation of benefits gained from various responses as a dynamic function of time. Solutions must have the potential for use in the civilian sector (i.e. integrate with civilian networks and infrastructure) as well as integration into existing DoD planning tools. Proposals shall outline the strategic and technical development of the proposed solution, including required data, data sources and environments, data quality management, and model development design and integration. As the technology will be fielded for military use in various operational environments, proposed approaches must be adaptable to variable levels of communication capability and medical care.

This topic is soliciting Direct to Phase II (DP2) proposals only. As such, the offeror shall provide detail and documentation which demonstrates the accomplishment of a "Phase I-like" effort demonstrating feasibility and proof-of-concept. Demonstration of feasibility may include: Conceptual characterization of the complete productRelevant use cases, required data categories, and anticipated final capabilitiesLeveraged systems and workflow (as relevant)Proposed approach or methodology for model development (as relevant)Anticipated interactions between data and model components (as relevant)The presentation of scientific and technical material that support the aboveDesign specifications for any computational or software components of a prototypeProposals should contain preliminary data (published or unpublished) supporting the rationale for the development of the candidate product(s). Describe how the product will be usable in the operational continuum or the environmental setting(s) for which it is designed.

This phase will focus on refinement and optimization of a prototype tool that can interact with users through a visual interface. The prototype should be designed to integrate decision criteria from users (e.g., response level and latency) with medical needs predictions from built-in models. Software interface must be sufficiently mature to receive input data from users and display the output for evaluation and further improvement of the tool’s feedback. Offerors should only propose products at or above Technology Readiness Level (TRL) 2. The 18-month base period should focus on developing, integrating, and demonstrating the core capabilities of the prototype through measurable milestones and evaluations. The 6-month option period should focus on refining the prototype based on user feedback, validating performance in operationally relevant scenarios, and enabling transition by positioning the technology for Phase III development and eventual DoD and commercial adoption.The proposal shall describe the planned prototype design, product development, testing, and validation of the prototype product in table-top like exercises. The testing and practical implementation of the prototype should be relevant to the requirements of medical command and control functions in austere and contested environments. The proposed work may include, but is not limited to, the following:Information required for a Phase 1 proposal, including selected methods/approaches (see above)Medical, scientific, and technical justification and selection criteria for specific approachesAnticipated data sources (e.g. theater, casualty, medical; natural, virtual) and types (organic v. synthetic, etc.)Interactions and relationships between the data and modeling components or the proposed workDetailed description of planned prototype design and development (communication requirements, data, architecture, software, interface, models, etc.)Methodology and outcome metrics for determination of functionality/utilityThreshold and objective exit criteriaThe investigator shall deliver no less than 4 prototypes supporting different military user evaluations. Each prototype should demonstrate increasing operational capability and maturity while reducing technical risk through measurable performance objectives. The proposal shall describe a detailed strategy for the Phase III effort to include dynamic uncertainty quantification to support operational decision-making and transition to both DoD and commercial applications.Phase II Milestones (Base)MilestonePeriodM1. Operational Requirements & Technical BaselineMonths 1 – 2 Technical ObjectiveEstablish the operational concept, technical architecture, and data strategy for casualty prediction and medical decision support in Denied, Disrupted, Intermittent, and Limited (DDIL) environments.Exit Criteria and DeliverablesSystem Requirements Specification (SRS)System Architecture DescriptionData Management Plan End of Month 2: System Requirement ReviewMilestonePeriodM2. Casualty Prediction & Data FusionMonths 3 – 5 Technical ObjectiveDevelop and validate the baseline casualty prediction engine using representative military and civilian datasets with varying data completeness.Exit Criteria and DeliverablesBaseline casualty prediction engine demonstratedData fusion capability validated using representative operational scenariosInitial model performance assessment completed End of Month 5: Technical Baseline ReviewMilestonePeriodM3. PROTOTYPE #1: Technical Baseline & Decision Optimization PrototypeMonths 6 – 8 Technical ObjectiveEstablish the program's technical baseline while demonstrating an initial prototype that integrates casualty prediction with medical resource allocation and response optimization to evaluate alternative Courses of Action (COAs)Exit Criteria and DeliverablesOperational Model Baseline:Physiology model requirements, performance objectives, and fidelity needed to support operational decision makingOperational parameter space, key decision variables, and scenario boundariesData requirements, model assumptions, constraints, and uncertainty characterizationThreshold and objective performance metrics, verification methodology, and validation approachAutomated COA generation and ranking demonstrated Month 6: Government Technical Baseline Review completed, establishing technical foundation and evaluation criteria for prototype maturation.End of Month 8: Prototype 1 Presentation & DemonstrationMilestonePeriodM4. PROTOTYPE #2: Decision Support & InteractionMonths 9 – 11 Technical ObjectiveDevelop an interactive decision-support interface incorporating user-defined constraints and dynamic uncertainty quantification.Exit Criteria and DeliverablesInteractive visualization demonstratedDynamic uncertainty/confidence metric demonstratedUser assessment completed and incorporated into prototype refinement End of Month 11: Prototype 2 Presentation & DemonstrationMilestonePeriodM5. PROTOTYPE #3: Integrated Operational PrototypeMonths 12 – 15 Technical ObjectiveIntegrate prediction, optimization, visualization, and user interaction into a single operational prototype and demonstrate functionality in representative military scenarios.Exit Criteria and DeliverablesSuccessful tabletop exercise completedPrototype evaluated against metrics End of Month 15: Prototype 3 Presentation & DemonstrationMilestonePeriodM6. PROTOTYPE #4: Operational Prototype Demonstration & Transition PlanningMonths 16 – 18 Technical ObjectiveDemonstrate a mature prototype and establish the technical foundation for Phase III transition.Exit Criteria and DeliverablesOperational prototype demonstration completed Final technical report completed Phase III transition strategy completedEnd of Month 18:  Prototype #4 Presentation & Demonstration Phase II Option MilestonesMilestonePeriodO1. Operational Refinement and Model OptimizationMonths 19 – 20 Technical ObjectiveRefine casualty prediction, decision optimization, and user interface capabilities based on Government feedback from Phase II evaluations.Exit Criteria and DeliverablesPrototype refinement demonstration Model improvement documentation End of Month 20: Updated prototype demonstrating improved performance MilestonePeriodO2. Expanded Operational ValidationMonths 21 – 22 Technical ObjectiveValidate prototype performance across representative military and/or civilian emergency response scenarios.Exit Criteria and DeliverablesPrototype demonstration with expanded scenarios with metric and threshold validationsUser evaluation report documentation  End of Month 22: Updated prototype demonstrationMilestonePeriodO3. Transition ReadinessMonths 23 – 24 Technical ObjectivePrepare the prototype for Phase III maturation by documenting technical maturity, transition planning, and integration considerations.Exit Criteria and DeliverablesUpdated transition and commercialization plan identifying DoD and commercialization opportunitiesPreliminary integration and cyber security strategy documentedFinal prototype package delivered.End of Month 24: Final program review. Milestone Technical Maturation Strategy: The 18-month base period focuses on “Develop, Integrate, and Demonstrate” while the 6-month option period emphasizes “Refine, Validate, and Enable Transition”. This approach provides measurable technical milestones, progressively retires technical risk while increasing operational realism through four prototype evaluations, and positions the technology for successful Phase III transition.

Phase III Dual use applications (Commercial DoD/Military): If successful, Phase II work will result in a final phase funded by sources other than a Federal government SBIR Program. Phase III awards may be made by any Government entity without further competition, creating a “SBIR-sourcing” (sole-source-like) tool for portfolio managers and advanced developers.Final improvements to the product’s functionality should be completed during Phase III, and additional development will be performed as necessary to expand the methodologies and components included in the Phase II prototype and/or improve their capability. The resulting product will provide a decision-assist tool for medical response optimization in austere environments where access to data and communications ranges from full to null.Phase III is expected to mature the Phase II prototype into an operational decision-support capability suitable for military and commercial use. Activities may include expanding predictive models, incorporating additional operational data sources, enhancing interoperability with existing planning and command and control systems, strengthening cyber security, and refining software functionality based on operational feedback. The desired end-state of the research will be the full development of one or more products consisting of front- and back-end software for a digital tool that provides casualty stream predictions for a given event with minimal user input, interacts with users to receive known response parameters, and projects the health and lifesaving impacts of available response options on survivability. The product must demonstrate full functionality and reliability in tabletop and field exercises.Military application: The potential product may transition to an Acquisition Program managed by the Service Product Developers for inclusion into various Service-specific mobile applications. Deployment will require appropriate cybersecurity certifications be met and the ability to join an existing Authority to Operate or obtain a separate ATO. Commercial application: The product will provide a similar capability for the planning of response to non-military emergency events. (e.g., following natural disasters or war).

Develop and demonstrate capability with autonomous medical triage systems to recognize chemical toxidromes and physically deliver the corresponding antidote or life-saving intervention.

DARPA seeks innovative approaches to autonomous chemical, biological, radioactive, and nuclear (CBRN) triage that measurably improve casualty survival and increase the effective capacity of a medical response during CBRN disasters. Early situational awareness and timely treatment is a matter of life and death in battlefield and disaster medical triage. Responder vulnerability in hazardous environments caused by CBRN attacks adds significant difficulty to the medical response. When a mass casualty incident (MCI) occurs within a chemically contaminated area, the medical response is hindered by uncertainty while the threat is assessed and characterized. To ensure safety of the responders, they must don protective equipment before entry, delaying initial assessment, triage, and treatment with life-saving interventions (LSIs). Personal protective equipment (PPE) also imposes a physiological and functional penalty on responders resulting in slower movement, higher energy expenditure, heat stress, impaired respiration, and reduced manual dexterity; these penalties further impede responders’ ability to perform life-saving interventions. Effective stabilization occurs in the cold zone after casualties have been decontaminated [1,2], compounding the delay to evacuation and definitive care. The DARPA Triage Challenge (DTC) has demonstrated that autonomous air and ground systems, using standoff sensors, can locate casualties, characterize injury patterns, and support triage prioritization in realistic MCI conditions [3]. Using DTC triage support capabilities as a starting point, this solicitation aims to extend capabilities to operating in chemically hazardous environments where injury patterns have distinct signatures or toxidromes. Success here extends proven autonomous triage into the one of the most challenging settings where human entry is dangerous and delayed, and where early antidote delivery most directly determines casualty survival [4].Proposed systems should be able to locate and assess casualties for traumatic injuries and chemical toxidromes, generate triage recommendations, and deliver appropriate initial treatments to reverse, stabilize, or prevent the toxic effects of chemicals. Solutions should be designed for realistic operational use in difficult terrain under challenging environmental conditions. DARPA does not prescribe a specific platform, sensor suite, or level of autonomy. Offerors are encouraged to propose the human-machine teaming arrangement that best improves decision quality and casualty outcomes, and to define how their system fails safely when conditions exceed its competence. Approaches should be realistic in scope, repurposed within the period of performance, and grounded in how CBRN mass casualty response actually unfolds.At minimum, the effort shall deliver a demonstrated prototype that detects at least two representative chemical toxidromes and applies appropriate initial treatments for the assessed toxidrome following human-in-the-loop treatment approval.

Phase I work is expected to have been completed before award. Proposers must submit evidence that their existing prototype can:• Autonomously find and localize casualties and report their location to within 2m• Assess trauma patterns and assign a trauma triage category• Perform accurate standoff vital-signs assessment, including at minimum heart rate and respiratory rate • Operate at scale o At least 20 casualties in a single scenario o Perform assessment in <90 seconds for each casualtyo Survey a 30,000sqft area without battery change• Operate across diverse, realistic environments: indoor and outdoor, daytime and nighttime, ideally (but not required) in adverse weather conditions (rain, smoke)• Produce a human-interpretable output through a graphical interface that conveys casualty locations and priorities of care.• System must be portable. All components should be easily transported by a vehicle or drone.Capability demonstration:A written technical description or published report supported by data and video(s) demonstrating the prototype performing the capabilities above in the stated environments are required (provided via link).

Building on the feasibility demonstrated in the documentation above, the Phase II effort will extend their qualified baseline system to assess and treat chemical toxidromes. In this effort, performers will develop, integrate, and validate a prototype autonomous chemical casualty triage system and demonstrate it in a relevant environment. The system shall identify casualties, assess them for life threatening and other traumatic injuries, assess casualties for chemical toxidromes, and provide relevant physical treatments. Requirements: Performers shall develop the capability to assess and treat at least two chemical agent categories from Table 1. Agent detection is out of scope for this effort. Treatment recommendations and options for each casualty shall be presented through a graphical interface to responders. Treatment decisions will always be made by humans.Table 1. Target toxidromes, symptoms, and interventions [1, 5, 6].Toxidrome categoryRepresentative agentsPhysical presentationAnticipated treatment to demonstrateCholinergic (nerve-agent) syndromeSarinVXNovichokOrgano-phosphatesDUMBBELS – diarrhea, urination, miosis (constricted pupils), muscle weakness, bronchospasm, bronchorrhea, bradycardia (decreased heart rate), emesis, lacrimation, salivation and sweating.Intramuscular pharmaceutical delivery of simulated antidote (atropine and pralidoxime)Airway management*Blood-agent syndrome (cyanide)Hydrogen cyanide,Cyanogen chlorideRapid collapse; gasping, tachypnea (fast respiratory rate) progressing to apnea (no breathing); altered mental status, seizures; cardiovascular instability (low blood pressure, fast heart rate); skin flushing, central cyanosis; dilated pupils.IV/IO pharmaceutical delivery (i.e., cyanokit)**Airway management*Pulmonary / choking-agent syndromeChlorinePhosgeneCough, dyspnea (difficulty breathing), wheezing, stridor; eye and airway irritation; respiratory distress; delayed pulmonary edema.Delivery of bronchodilatorsAirway management*Vesicant / blister-agent syndromeSulfur mustardBlistering skin burns, airway irritation, painSkin decontamination with removal of substance from exposed skin, clothing, and washing skin or using decontamination cloths.Airway management*Opioid / respiratory-depressant syndrome Fentanyl-type incapacitantsPinpoint pupils; respiratory depression progressing to apnea; decreased consciousness.Intranasal or intramuscular NaloxoneAirway management** Airway management includes: providing supplemental oxygen by mask AND escalating to either non-invasive (bag-valve mask or mechanical) or invasive (endotracheal intubation or surgical airway) ventilation.**Includes autonomous placement of intravenous (IV) or intraosseous (IO) catheter. Performers will demonstrate their platform’s ability to recognize simulated toxidromes in silico (computer-based simulation) and on high-fidelity mannikins with the simulated toxidrome presentations outlined in Table 2.Table 2. Simulated toxidromes for demonstration purposes.Toxidrome categoryPhysical presentationSimulated presentation on a mannikinCholinergic (nerve-agent) syndromeDUMBBELS – diarrhea, urination, miosis (constricted pupils), muscle weakness, bronchospasm, bronchorrhea, bradycardia (decreased heart rate), emesis, lacrimation, salivation and sweating.Damp/wet clothing around the groin area and on the groundConstricted pupils (miosis)Coughing soundsRapid breathing (rate > 30)Slow palpable pulses at the wrist and groin (rate < 40)Emesis from the mouth (head turned, vomit on side of face and on the ground)Damp “skin” (sprayed on liquid)Blood-agent syndrome (cyanide)Rapid collapse; gasping, tachypnea (fast respiratory rate) progressing to apnea (no breathing); altered mental status, seizures; cardiovascular instability (low blood pressure, fast heart rate); skin flushing, central cyanosis; dilated pupils.Coughing soundsRapid breathing (rate > 30)Altered mental status/confusion (mumbling words, does not respond verbally to instructions)Flushed (red appearing) skinDilated pupils (mydriasis)Pulmonary / choking-agent syndromeCough, dyspnea (difficulty breathing), wheezing, stridor; eye and airway irritation; respiratory distress; delayed pulmonary edema.Coughing soundsRapid breathing (rate > 30)Red/irritated eyes (scleral injection)Wheezing on auscultation of lung soundsCyanosis around lipsVesicant / blister-agent syndromeBlistering skin burns, airway irritation, painGelatin on skinSkin blisters and burnsCoughing soundsRapid breathing (rate > 20)Opioid / respiratory-depressant syndromePinpoint pupils; respiratory depression progressing to apnea; decreased consciousness.Constricted pupils (miosis) Slow breathing (rate < 10)Unconscious, non-responsivePerformers will demonstrate their platform’s ability to assess and deliver interventions on simulated casualties in both computer-based simulation or on physical manikins/in physical environments as outlined in Table 3. Some tasks that *must* be demonstrated on a physical manikin or in Table 3. Table 3. Required technical capabilities for demonstration purposes.Technical capabilityRequirementsCasualty AssessmentLocate casualty; report clinical signs (hemorrhage, respiratory distress, mental status, pain, emesis etc.), injuries and injury location.Evaluate casualties for chemical toxidromes and assign a probable target agent category from Table 1. Assign triage category (urgent, non-urgent). Identification of the specific chemical agent is out of scope. Chemical-specific sensors are also out of scope.     Intervention Delivery* The platform must physically administer treatment appropriate to the chosen toxidrome according to table 1 on a manikin.* Final demonstration requires the system payload and automation to administer treatment to at least 5 casualties in succession without battery changes or re-supply.Platform, Environment, and Autonomy* Platform-agnostic: Autonomous UAV and UGVs. Performer may choose the sensor suite (excluding chemical-specific sensors). System must demonstrate safe physical interaction with casualties represented by high-fidelity manikins.† A single robust platform must operate across and transition between realistic environments — difficult terrain, inside and outside of buildings, and potentially subterranean settings. Dedicated single-environment platforms are not sought.End of Program DemonstrationDetection/assessment may be validated computationally through assessment of a test set of images and videos showing injuries and clinical signs. (e.g., respiratory distress, pupillary changes, salivation, sweating, skin changes/blisters.) * † Intervention delivery on multiple casualties must be validated by physical demonstration.The essential program output is a validated prototype.* Required, on a manikin; † Required, over real terrain 

Military: Autonomous triage and toxidrome-directed treatment in chemically contaminated, battlefield environments, protects medics from entry and prolongs casualty survival until human care is possible. Civilian: Similarly, autonomous systems capable of assessing and delivering life sustaining treatments during disaster responses, industrial chemical accidents, hazmat operations, and chemical terror attacks in which fire/EMS response will be delayed provides additional safety for responders and a survival advantage for casualties during public-health emergencies [2]. The autonomous system will perform initial triage and treatment in the hot zone so that responders either avoid entry entirely or gain time to don protective equipment.

Develop (large animal model testing) an autonomous, portable extracorporeal life support platform for prolonged field care that integrates resuscitation, cardiovascular and pulmonary support, and (optionally) electrolyte and medication delivery capabilities.

Severe hemorrhage is the number one cause of preventable combat deaths, followed by airway compromise (Eastridge, 2012), with increased artillery, thermobaric and incendiary munitions use (Remondelli et al. 2023) potentially increasing lung injury prevalence in future conflicts. Following initial trauma, sepsis and multiple-organ failure predominate (Neff et al. 2013). While improvements in point of injury care (tourniquets, hemostatic dressings, etc.) have significantly increased survival in early trauma phases (Chovanes et al, 2012, Cohen et al., 2012), such care is ideally followed by pre-hospital care from trained medical providers during casualty evacuation. However, as reflected by the large-scale combat operations (LSCO) in the Russia-Ukraine war and with Special Operations missions in remote, austere locations, access to definitive medical care may not be available for days, especially in conflict with near-peer adversaries (Keenan and Riesberg, 2017; Remondelli et al. 2023; Epstein et al., 2023).More people surviving early phases of trauma combined with decreased evacuation opportunities highlights a pressing need for solutions that can provide advanced and sustained resuscitative care for the organ failure sequalae of severe trauma (e.g., hypotension, respiratory failure, acute renal failure). A growing body of technical capabilities and supporting literature suggests that by focusing on the key drivers of mortality, advances in autonomous systems across several areas of critical care could be combined into a single "ICU-in-a-Box". In particular, extracorporeal membrane oxygenation (ECMO) is an alternative to using intubation and mechanical ventilation (under deep sedation) for acute respiratory distress syndrome (Geetha 2024). Because an ECMO system is essentially just a pump and a membrane lung, it offers a strong opportunity to automate oxygenation support—along with other key combat casualty care needs. While current ECMO systems require highly trained operators, largely because of the need to insert large cannulas and the associated thrombotic risks, recent advances can mitigate these limitations. For example, assistive insertion devices (Brattain 2021) and ECMO systems with smaller cannulas (Osmani et al., 2026) reduce the difficulty of insertion; antithrombotic coatings, portable systems (Szentgyorgyi 2025), and alternatives to conventional membrane oxygenators (Conrad 1994) reduce thrombotic risk (at least over shorter periods); and AI/ML advances in general as well as ECMO management computer models (Pladet 2023, Geetha 2024) could support automation. Once venous access is established for automated ECMO, it enables additional interventions. For example, automated algorithms have stabilized mean arterial pressure (MAP) and heart rate for short periods following severe hemorrhage in porcine models (Pinsky 2024); renal replacement therapy (RRT) could mitigate life-threatening electrolyte abnormalities; and extracorporeal blood purification techniques could remove inflammatory mediators, infectious agents, or toxins (Neff 2013).This SBIR seeks to combine such capabilities into a single, portable, integrated intervention and delivery platform for resuscitation, cardiovascular and lung support. There is additional potential to automate sedation (Daga 2026, Nagata 2023), analgesia (Aissou 2012), and renal replacement therapies (Wieringa 2025). Although these efforts remain relatively immature, their addition to the integrated system could further extend ICU-level, autonomous extracorporeal life support (ECLS) in the austere and operational setting.

This topic solicits Direct to Phase II proposals only. Proposers must provide data demonstrating that at the following has been achieved to be considered for award: A prototype, portable (battery operated) extracorporeal system that can: 1) achieve at least 2 L/min of blood flow and lung support (oxygenation and ventilation); 2) deliver at least 75 mL/min oxygen; 3) exchange at least 40 mL/min carbon dioxide; and 4) at least one of the following:• An algorithm that maintains oxygenation and ventilation within specified ranges for SpO2 and EtCO2 by adjusting combinations of the following: blood flow, sweep gas, FiO2. • An algorithm that maintains mean arterial pressure within a specified range using at least one vasopressor and as needed fluid resuscitation (preferably blood, alternatively crystalloid).• An algorithm that controls blood flow, ultrafiltration, and monitoring of an extracorporeal renal replacement or blood purification system for removing potassium.Proposers interested in submitting a Direct to Phase II (DP2) proposal must provide documentation to substantiate that the scientific and technical merit and feasibility described above has been met and describes the potential commercial applications. Proposers must describe current O2 transfer and carbon dioxide (CO2) removal rates that can be achieved by the proposed system. The proposed system must directly interface with an oxygen source (e.g., canister, oxygen concentrator) to provide oxygenation and carbon dioxide removal to mitigate acidosis and lactate buildup. Proposals should provide evidence for the maximum duration of support with their proposed system (ideally, > 72 hours).Documentation should include, reference, or summarize all relevant information including, but not limited to technical reports, test data, prototype designs/models, and performance goals/results.

DARPA is interested in novel approaches to develop a fully integrated, portable system that can provide key components of resuscitation during prolonged casualty care (PCC) (e.g. an ‘ICU-in-a-box’). Approaches that only enable a user(s) to interact with/control multiple different systems, i.e. ‘system of systems’ solutions, are not in scope: the goal is to create a single, portable device that is capable of providing all the desired clinical interventions through a single intravenous cannula inserted into a central vein (internal jugular or femoral vein). Given the ultimate goal to be able to deploy the system in conditions where experienced medical care is not available, a primary goal of this SBIR is to develop and integrate algorithms that enable the system to be autonomous. Assumptions and Expectations: • Remote monitoring and control are essential to engage remote expert guidance/intervention when the system experiences edge or unanticipated conditions. • A casualty is cannulated (autonomous cannulation or decision support for cannulation is out-of-scope).• Local users will have basic medical training (e.g. a field medic) and can set up, initiate, and attach the automated system if guided, but once attached, the system should monitor the casualty itself and provide autonomous interventions to sustain mean arterial pressure, oxygenation, and ventilation. It should address alerts and alarms (system functioning) autonomously or engage a remote expert automatically without local operator intervention.o In addition to initiation of the device, local caregivers can be assumed to:? Change IV bags after direction? Retrieve and attach blood products after direction? Retrieve and attach medication after direction• Sufficient displays to provide status information about the patient and the current/past treatments deployed by the system should be included. • It is also permissible to include a ‘clinical decision support’ mode that a local operator could respond to in the event a remote expert is unavailable.Required Capabilities:• The system must be readily deployable with minimal contact points with the patients. o Sensor packages should be minimized and be easily applied to monitor patient state. Proposals that do not require invasive arterial monitoring are preferred. Proposers must specify what sensors are being recommended, how they are intended to be used in austere and operational (military) conditions, and how they are providing the system sufficient physiological information to support the autonomy. o The system may have one (1) patient-inserted cannula, preferably no larger than 15Fr (5mm). Proposers must specify which vessels they intend to use (jugular or femoral). o The intended circuit design must be provided and include how sufficient blood/fluids and medications will be effectively delivered. Proposals must specifically describe how the proposed solution manages continuous medication delivery (e.g., sedation and analgesia, vasopressors) and bolus fluids (e.g., blood or crystalloid) within the integrated circuit. o Proposers must also specify safety parameters that will be implemented in the integrated system.• As DARPA ultimately envisions a system intended for use in prolonged field care scenarios, proposers must describe the planned size, weight, and power – network connection, cyber security, and cost considerations (SWaP-C3) for the system. It is anticipated that further system development for miniaturization may occur beyond the scope of this SBIR, but the potential to integrate all the provided components in a portable form factor (e.g., a M9 backpack) must be demonstrated.• The system must be able to provide autonomous support to maintain partial organ function (cardiovascular and lung) and fluid resuscitation in cases of hemorrhage. o For lung support, the system will be able to provide ECMO functionality for direct oxygen transfer to the blood. Preferably, full oxygen support (approximately 250ml/min) would be achievable, but in cases where partial oxygen support is proposed (at least 125 ml/min), proposers can assume that the patient is already intubated for respiratory support. Proposals that integrate with mechanical ventilation when present are preferred.o In addition to oxygen support, the system should also provide at least 80ml/min CO2 removal (Combes et al., 2024).o For cardiovascular support, the system must also be able to provide fluid resuscitation as needed. It must be capable of maintaining perfusion pressure (not just blood pressure) throughout the validation tests (e.g., at least 24 hours) and be able to support significant hemorrhagic trauma models (e.g., model emulating an uncontrolled bleeding scenario of at least 50% of the estimated blood volume over six hours). This support can include blood, artificial blood products, freeze dried blood products, and crystalloid. When fluid is ineffective at maintaining perfusion pressure, the system should titrate vasopressors to maintain specified mean arterial pressure. All interventions must be autonomously controlled by the system.o Proposers must describe the planned development and validation of the closed-loop auto-titration algorithms for control of the oxygen saturation level.o Likewise, they must describe the planned development and validation of the fluid resuscitation algorithms, as well as integration of the oxygenation and resuscitation algorithms into the overall system.• Proposers must clearly describe the design of all proposed systems and large animal model tests, as well as their relevance to clinically relevant scenarios, such as similarity to human intravascular blood flow, changes in blood oxygenation levels, trauma biomarkers (e.g., lactate, potassium, pH), thrombotic and hemolysis risk checks and histological assessments. Proposers may choose to utilize existing benchtop hardware and approaches for validation of the system functionality, or, alternatively, respondents may propose the development of iterative or new validation approaches as part of their proposal.Optional capabilities:• Additional capabilities of interest include RRT and fluid management interventions to treat electrolyte (e.g., hyperkalemia) derangements.o For these, the system would provide basic kidney support via the same circuit that supports oxygenation and fluid resuscitation. This would include providing electrolyte removal and/or fluid resuscitation compensate for acute metabolic derangements. This could include filtering the blood to remove small molecules or other interventions (e.g., absorption) to compensate for cytokines, endotoxins, etc. that can impact sepsis or other inflammatory derangements. More specifically the system should be demonstrated to be able to maintain adequate lactate levels, temperature and pH (approximately within 20% of baseline values) for at least a 24-hour period• Additional functionality that is not required but is of interest and would boost the strength of a proposed solution, include: automated sedation and/or analgesia and delivery of scheduled medications (e.g., antibiotics) or other as needed medications (e.g., bolus pain control).The interim and end-phase goals for the base period are as follows for a 24-month base effort followed by a 6-month option. Responders to this topic are strongly encouraged to propose additional interim assessments to further demonstrate progress toward the goals specified below.Month 1: Report on initial circuit architectures, sensors, algorithms and animal models and development strategy and timelineMonth 3: • Interim report on integration of extracorporeal support subsystems (i.e. sensor package(s), lung and cardiovascular systems, plus any planned optional capabilities, e.g., electrolyte support)• Interim report on development of automation algorithms• Report on development of initial ex vivo, computational simulation, etc. testing environments Month 6: Report on development strategy for large animal model(s): can utilize animal models for testing each subsystem (6 hrs for hemorrhage models, 12 hrs for other interventions), including regulatory (IACUC, ACURO) timelines Month 9:• Interim report describing performance (ex vivo, sims) of prototype system, automation algorithms and refinements to ex vivo testing environments • Report on regulatory status/approval of large animal model(s)Month 12: • Interim report describing performance (ex vivo, sims) of prototype system, automation algorithms • Interim report describing development status of large animal model(s) Month 15: • Interim report describing performance (in vivo) of prototype system in separate animal models• Report on clinical regulatory approval strategy (e.g., FDA engagements).Month 18: • Interim report describing performance (in vivo) of prototype system in separate animal models• Report on strategy for developing a large animal model that combines assessments for all subsystems (e.g., polytrauma model) in order to validate system performance during simultaneous deployment of all automation algorithms (maintaining hemostasis for 24-hours) including regulatory (IACUC, ACURO) timelinesMonth 21: Report on regulatory status/approval of large animal polytrauma modelMonth 24:• Final report summarizing approach; prototype architecture and algorithms; separate large animal model testing results (including thrombotic, hemolysis and histological assessments, as well as efficacy of algorithms in maintaining goal biomarkers, e.g., SpO2, EtCO2, MAP, etc.), bill of materials for the prototype as well as SWaP-C3 feasibility for future fully portable designs, and use of consumables (e.g. O2, fluids, vasopressors, etc.).• Report on regulatory development strategy and any FDA engagements.• Report on development of polytrauma model and recommendations for its use in a preclinical study for in vivo assessments of the prototype device including updated recommendations for a regulatory strategy (e.g., FDA engagements).Option Period 1: Proposals that respond to Option Period 1 may also include a sequential 6-month option period for a pre-clinical pilot study to demonstrate and validate the functionality of their integrated breadboard system in a large animal model.Month 25:• Report on regulatory approval status for 24-hour large animal model that combines all interventions (e.g., polytrauma model)• Report on experimental testing strategy and timeline Month 28:• Interim report describing integration of all prototype subsystems and automation algorithms • Interim report describing performance (in vivo) of prototype system in 24-hour large animal model polytrauma modelMonth 30: Final report documenting final prototype architecture and algorithms; methods; all results; and proposed strategy for a portable form factor compatible with far forward deployment in austere conditions (i.e., SWaP-C3 assessment), and final regulatory status and FDA engagements.

This SBIR has potential applicability across DoW and commercial entities. Commercial applications include integration of this autonomous extracorporeal support platform into civilian critical care transport (rotor-wing, fixed-wing, and ground ambulance services), rural and community hospital as a bridge-to-transfer where on-site critical care expertise is unavailable, and in mass-casualty or disaster-response settings where trained critical care staff are scarce or evacuation times are long. Military and DoW applications include incorporation into Prolonged Casualty Care and equipment sets for Special Operations Forces, forward surgical teams, and casualty evacuation platforms across air, ground, and maritime domains, including uncrewed evacuation systems, enabling extended en-route and prolonged field care for casualties with severe injuries (battle or disease non-battle) in contested or resource-limited operational environments. In these settings, an autonomous, portable extracorporeal life support system will provide options to sustain the force that do not currently exist.

Develop and demonstrate novel nanofabrication hard-mask materials that exhibit substantially improved plasma etch resistance, enabling the implementation of extreme high-aspect-ratio structures with excellent pattern-transfer fidelity, minimal sidewall roughness, and precise dimensional control. Proposed solutions should overcome the fundamental limitations of conventional lithography masks in a scalable fabrication environment by creating next-generation technologies capable of delivering high-resolution nanoscale features encountered across semiconductor, photonic, MEMS, and quantum device platforms.

Next-generation defense-relevant microsystem technologies, such as 3D integrated circuits, high-density memory arrays, MEMS inertial sensors and RF filters, and integrated photonic devices, rely on the precise manufacturing of extreme high-aspect-ratio features within a chip [1-3]. Furthermore, emerging architectures for multiferroic memory and logic components, such as those being pioneered under DARPA's Fast and Curious program [4], stand to benefit immensely from novel process flows capable of delivering deep trenches with ultra-low line-edge roughness. As critical dimensions of these devices continue to shrink to improve performance or reduce size and cost, the ability to accurately transfer lithographic patterns into underlying substrates (such as silicon) via aggressive plasma etching has become a primary manufacturing bottleneck.Current state-of-the-art (SOTA) hard masks predominantly utilize thick chemical vapor deposition (CVD) inorganic films (e.g. silicon dioxide, silicon nitride) or sputtered metals. These conventional technologies face fundamental physical limitations at extreme scales. To achieve the necessary etch resistance, standard masks must be deposited with significant thickness, which induces high stress, structural instability, pattern distortion, and reduced feature fidelity during the etch process. Furthermore, conventional metal masks exhibit polycrystalline structures; their inherent grain boundaries erode unevenly under ion bombardment, propagating severe line-edge and sidewall roughness that degrades the electrical and structural integrity of the final device.This STTR topic seeks highly innovative masking materials that disrupt the current paradigm. The goal is to identify and develop solutions that deliver ultra-high etch selectivity while addressing the weaknesses of current SOTA solutions. Proposed approaches should inherently bypass the degradation mechanisms of traditional masks by utilizing low-dimensional, continuously ordered, inherently grain-free and/or self-regenerating structures to ensure pristine pattern transferring with low line-edge roughness even when subjected to aggressive, high-density plasma [5-7].Solutions do not have to be limited to silicon processing and may target compound semiconductors, wide-bandgap materials, piezoelectric substrates, ceramics, heterogeneous material stacks or any other microsystems platform relevant to the Department of War (DoW). Compatibility with existing or minimally-modified reactive ion etching (RIE), inductively coupled plasma (ICP), Bosch Deep RIE (DRIE), or related plasma fabrication tools is strongly preferred.Proposers should identify the underlying physical mechanisms responsible for enhanced pattern-transfer performance and demonstrate a clear path toward scalable manufacturing. Metrics of interest include improvements in etch selectivity, maximum achievable aspect ratio, critical-dimension control, sidewall roughness, mask thickness reduction, process throughput, and compatibility with wafer-scale manufacturing.

This topic is soliciting Direct to Phase II (DP2) proposals only. Proposals will be considered for DP2 funding for teams that provide compelling evidence of the feasibility of their novel hard-mask materials at a laboratory or R&D fabrication facility. Proposers must provide data showing that Phase I feasibility has been achieved through prior work. Required documentation includes:Etch Selectivity Data: Experimental data demonstrating the successful deposition, synthesis, or transfer of low-stress mask films, alongside measured etch selectivity exceeding 50:1 against target substrates (e.g., silicon or complex oxides) under aggressive dry plasma conditions.High-Aspect-Ratio Pattern Transfer: Proof-of-concept fabrication data showing deep pattern transfer into a substrate, achieving an aspect ratio of > 25:1 without significant mask degradation, faceting, or critical dimension (CD) loss.Edge Fidelity & Roughness Verification: High-resolution metrology data (e.g., cross-sectional SEM, TEM, or AFM) verifying pristine pattern transfer, specifically demonstrating etched structures with nanometer-scale sidewall roughness (< 5 nm RMS).Scalability & Integration Pathway: Initial feasibility data or a substantiated extrapolation demonstrating a viable pathway to scale the masking technology from lab-scale prototypes to wafer-level dimensions (e.g., via CVD, ALD, or scalable continuous transfer methods). Proposers must document how their proposed materials and process flows align with standard commercial fabrication and/or DoW constraints, specifically addressing: CMOS compatibility, thermal budget, vendor/foundry transferability, and any additional constraints imposed by the application of interest.

Direct to Phase II (DP2): Develop, integrate, and demonstrate the following:Scalable deposition, synthesis, or transfer methodologies for hard-mask materials. Candidate masks must demonstrate an etch selectivity exceeding that of state-of-the-art inorganic films or sputtered metals, e.g., > 150:1 (mask-to-substrate) under aggressive plasma conditions.High-fidelity pattern transfer capabilities demonstrating extreme aspect ratios (100:1) without mask failure, critical dimension loss, or top-edge faceting.Sub-nanometer dimensional control, with candidate masks demonstrating etched structures with sidewall and line-edge roughness of < 2 nm root-mean-square (RMS).Compatibility with standard lithographic workflows. The hard mask itself must be readily patternable (e.g., via secondary chemical plasma or resist) while maintaining extreme resistance to the primary deep-etch plasma.Mitigation of unwanted metallic or particulate contamination to levels acceptable for standard semiconductor, MEMS, or photonic device fabrication lines. Hard mask demonstration must be conducted in a standard cleanroom environment where the process can be scaled to production and which supports the processing of standard-size wafers using commercial Deep Reactive Ion Etching (DRIE) or other Inductively Coupled Plasma (ICP) tools. Patterning performance must be compared between the novel hard mask versus a standard baseline mask material such as silicon dioxide, silicon nitride, or a sputtered metal (e.g., TiN, Cr). The goal is to demonstrate that the novel mask successfully maintains structural integrity in aggressive etch conditions where standard masks fail, e.g., the novel mask maintains CD fidelity and sub-nanometer sidewall smoothness at etch depths that would completely erode or severely facet the standard mask. Compared to standard masks, the proposed solution must deliver a statistically significant reduction in defect propagation and edge roughness.This DP2 will also require a commercialization and transition plan along with technology development. Throughout the phase, the proposers must collaborate with commercial and military end-users to refine operational requirements and deployment scenarios of their developed solution. Manufacturing and scaling plans for production must also be developed before the end of the program. The final report must also include technology transfer documents outlining planned opportunities for commercial and military applications. The deliverables for DP2 will include the final prototype mask formulation/process recipe, a comprehensive testing and validation report outlining the final demonstration, the technology transfer plan with commercialization plans, manufacturing and scaling strategy. DP2 Base milestones for this program should include:Month 3: Establish and report baseline parameters for the candidate mask material and develop a comprehensive chemical vapor deposition (or equivalent scalable deposition) process map.Month 6: Demonstrate initial solution-based (or alternative scalable) coating and dry etching. Achieve stable precursor formulation, continuous film formation on small-scale substrates, and an initial mask-to-substrate etch selectivity of at least 50:1.Month 9: Screen multiple mask candidates and execute the first patterned etch using the down-selected scalable coating method. Demonstrate initial high-aspect-ratio patterning (e.g., > 75:1) with a line-edge roughness of 5 nm or less using a process flow that is scalable to production levels.Month 12: Demonstrate process scalability with a target mask-to-substrate etch selectivity of at least 100:1.Month 15: Expand process integration for the mask deposition. Achieve strict film thickness uniformity (e.g., less than 10% variation) across intermediate-scale substrates and demonstrate patterning resolution with minimum feature sizes of 100 nanometers or less.Month 18: Validate mask performance on alternative, non-standard semiconductor or dielectric substrates. Demonstrate a minimum selectivity of 50:1 on at least two alternative materials and scale the coating process to larger wafer sizes.Month 21: Execute integrated, wafer-level processing demonstrations. Show successful transfer or direct integration of the vapor-deposited films and validate extreme etching capabilities on application-specific substrates (e.g., semiconductor devices, MEMS components, photonic structures).Month 24: Final Phase II demonstration. Achieve extreme etch selectivity (>150:1), ultra-high aspect ratios (>100:1) on primary semiconductor substrates, and strict dimensional control with a line-edge roughness of 2 nanometers or less.

Phase III efforts should focus in transitioning the developed hard-mask technology to DoW and commercial semiconductor fabrication facilities. DoW applications include the domestic manufacturing of secure high-density memory, advanced electro-optical components, and high-performance MEMS/RF components for electronic warfare and GPS-denied navigation. Commercially, this technology addresses fundamental physical scaling bottlenecks in the global semiconductor industry. Direct dual-use applications include the production of next-generation 3D semiconductor transistors, multiferroic memory and logic components, high-coherence solid-state quantum devices.

Develop a fuel-flexible spacecraft electric propulsion system capable of operating efficiently on air, water, or mixtures of water/carbon dioxide or nitrogen/hydrogen at >30% electrical efficiency.ITAR: The technology within this topic may be 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 section 3.5 of 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.

Spacecraft electric propulsion (EP) systems typically rely on noble gas fuels (xenon, krypton, argon) stored in high pressure tanks. These fuels are unattractive for sustained ambient-air operation in very Low Earth Orbit (vLEO), or for liquid refueling operations in higher orbits using water or chemical rocket fuels as output propellants. Furthermore, thruster development to date has been highly specific to individual fuels, requiring costly development of entirely new systems for new propellants—for example, optimizing for air in a vLEO environment versus water in a possible future higher orbit refueling architecture. These dependencies limit total propulsive capability and overall mission flexibility and responsiveness. This topic seeks a system able to operate on air (20-50% O2, balance N2), water (H2O), mixtures of water and carbon dioxide (CO2) derived from combusted hydrocarbons, or nitrogen-hydrogen mixtures derived from decomposed NH3 (ammonia) or N2H4 (hydrazine), using as much shared componentry as possible. Developing a flexible fuel EP system capable of accepting a variety of molecular propellants offers a unique capability for a single product line to serve a significantly larger mission space and total addressable market. This STTR topic seeks to develop a complete, integrated fuel-flexible propulsion system that bridges the gap between laboratory demonstration and fieldable spacecraft technology capable of utilizing in-situ resources.

To qualify for this Direct-to-Phase-II (DP2) topic, applicants must provide concrete evidence of prior Phase I-equivalent capability. Specifically, the applicant must have demonstrated:• Performance: >30% anode thruster efficiency on air or water.• Durability: >100 hours of cumulative operation on a single test article on air or water demonstrated at the performance level above.• Evidence Required: Vacuum thrust stand test data validating thrust, mass flow, power, efficiency and duration claims. Testing must have been conducted in a facility operating at a background pressure of < 3x10-5 Torr during full-power operation, using thrust stands calibrated in-situ.

The Phase II effort will focus on developing a complete, integrated fuel-flexible propulsion system capable of operating across air, water, and nitrogen/hydrogen species. The product will undergo envelope qualification for vibration, shock, and thermal cycling. The system components will include a fully integrated system including the thruster, power processing unit (PPU), flow control system, and a standardized bus control interface and protocol (e.g., RS485-based or similar) allowing demonstrated operation via the bus control.The STTR research institution will lead the gas species-specific fundamental research to improve and extend efficient operation across all critical gas species. The STTR small business will focus on productization, system integration, and robustness. Year 1: System Design, Interface Definition, and Prototyping•Month 1:o Kickoff meeting presenting program schedule plans for Year 1• Month 3: o Finalize system requirementso Review university-led research on performance using air, water, and chemical exhaust mixtureso Identify standard physical and fluidic interfaces to connect to external hydrocarbon and hydrazine chemical systems• Month 6: o Review design for the integrated thruster system. o University-led laboratory demonstration and technical report validating efficient performance transfer mechanisms across gas species (air, water, CO2, N2+H2)o Present conceptual design for gas generation/conversion mechanism(s) that will accept and regulate the hydrocarbon combustion and hydrazine decomposition feeds.• Month 9o Engineering model prototype design complete for thruster and supporting systemso Presentation of final test plans• Month 12: o Delivery of technical report on integrated engineering model prototype system design o Delivery of technical report on vacuum test results for prototype hardware across all gas species, including functional demonstration of gas feed system(s)Year 2: Qualification, Life Testing, and Design Iteration• Month 1: Kickoff meeting presenting program schedule plans for Year 1• Month 3:o Updated system design based on Year 1 test results, initial environmental testing (vibration, shock, thermal-vacuum), and other lessons learned• Month 6: o Written report on updated performance testing across all gas species• Month 9:o Complete 200-hr short duration wear tests on all gas species, or minimal time to evaluate wear rate following thruster burn-ino Identify preferred gas species for 1000-hr wear test based on initial results and business case• Final deliverables:o TRL 6 hardware including thruster head, flow systems and power processing unito Final test report on system design, performance results including thrust, Isp and overall thruster efficiency, and summarizing completed 1,000-hour and 200-hour wear tests.o Technology Transition & Spaceflight Integration Plan.

Phase III efforts will focus on flight qualification, scaling, and transition to acquisition for operational spacecraft. The transition target is versatile use across:1. vLEO satellites for air-breathing propulsion2. Rideshare-compatible inert water-fueled satellites with no pressurant tanks required3. Multimode propulsion systems capable of high specific impulse electric propulsion usinga. combustion exhaust (H2O+CO2) from hydrocarbon-based chemical rocket fuelsb. decomposition exhaust (N2+H2) from hydrazine (N2H4) based chemical rocket fuelsTarget military transition includes Space Development Agency (SDA) or DARPA vLEO constellations. Target commercial transition includes imagery, communication and satellite servicing vehicles, or deep-space In-Situ Resource Utilization (ISRU) architectures.

Develop and demonstrate a robust methodology to localize, characterize and model upstream noise and flow disturbances in hypersonic wind tunnels, specifically targeting high-risk, hard-to-access regions upstream of the test section (e.g., driver, reservoir, nozzle throat and walls) where traditional optical access is restricted or unavailable. Performers must implement novel non-intrusive or minimally intrusive diagnostics and coupled with multi-fidelity simulation strategies to accurately trace the evolution of unwanted thermo-fluid-dynamic disturbances from their point of origin to the test section.

Hypersonic ground-test facilities are critical for evaluating aerodynamic forces, aerothermodynamic heating, and boundary-layer transition (BLT) behavior on high-speed flight vehicles. However, conventional hypersonic wind tunnels are plagued by high-intensity freestream noise present in the test section. Because these disturbances build, focus, and propagate downstream, the fundamental understanding of their evolution may require a potentially deep analysis within the upstream components of the facility. Historically, Laufer [1] established that nozzle-wall turbulent boundary layers radiate downstream-directed Mach waves, making them a principal source of freestream noise. However, especially in high-enthalpy and hypervelocity impulse facilities, the noise field may be further enhanced by complex upstream dynamics that are not optically accessible. Examples of focus areas include, but are not limited to:Nozzle Throats and Walls (all tunnels): The extreme thermal and velocity gradients in the nozzle throat pose an opportunity for disturbance generation and initiation of turbulence over the nozzle walls. However, severe restricted throat geometry and high heat flux make optical diagnostic access virtually impossible. Diagnostics on tunnel walls are also very challenging although there are examples of previous successful attempts [12].Reflected-Shock Tunnels: Reservoir entropy, pressure fluctuations, and driver-gas contamination originate from the complex interaction between the reflected shock wave and the shock tube wall boundary layer [5, 6]. Furthermore, upstream diaphragm particulate-laden flow [7] acts as a continuous source of premature model transition downstream.Expansion Tubes and Tunnels: Subject to driver-gas acoustic focusing [9, 10], where upstream driver unsteadiness is focused directly into the test gas when sound speed ratios fall into unfavorable ranges. This is exacerbated by secondary diaphragm rupture wave systems [3, 11] propagating from upstream. Characterizing these regions is exceptionally difficult because standard optical diagnostic techniques (such as Femtosecond Laser Electronic Excitation Tagging (FLEET), Focused Laser Differential Interferometry (FLDI), or Rayleigh scattering) require optical-grade line-of-sight window access, which may not withstand the extreme pressures, temperatures, or geometric constraints of regions such as the driver, reservoir, or nozzle throat.To bridge this gap, this STTR topic focuses on the development of specialized diagnostics, informed by multi-fidelity computational flow models ranging in scope from system-scale to component-specific. Collaborative proposals from Small Business Concerns (SBCs) must address the following technical pillars:Upstream Noise Characterization & Modeling: Modeling facility-specific noise generation phenomena such as transient or statistically steady boundary-layer effects, driver-gas acoustic focusing, diaphragm bursting, starting from the most upstream location ultimately responsible for noise contamination of the test section.Diagnostics for Non-Optical Zones: Developing and demonstrating novel non-intrusive or minimally intrusive diagnostic systems for flow and acoustic characterization, capable of operating without traditional optical windows. Promising approaches include but are not limited to flush-mounted high-frequency pressure/thermal sensor arrays, micro-bore fiber-optic probes, laser-based acoustic sensing, and/or hybrid data-assimilation techniques that computationally reconstruct upstream flow states from sparse wall measurements.

This topic is soliciting Direct to Phase II (DP2) proposals only. Proposers must submit a 10-page feasibility volume providing written evidence of the following:Upstream Flow & Acoustic Modeling: Successful modeling of upstream disturbance generation and propagation (e.g., driver-gas acoustic focusing, shock-tube boundary layer interactions, or nozzle throat shear layer acoustics). Confined-Space Diagnostic Feasibility: Proof-of-concept or benchtop demonstration of a diagnostic method (e.g., fiber-optic-coupled probes, ultra-high-frequency flush-mounted sensors, acoustic emissions arrays, or shear sensors) demonstrating a frequency response and the physical ruggedness required to operate in high-pressure/temperature and/or non-optically accessible environments.

The Phase II effort will be divided into the following key tasks:Task 1: Upstream Noise Modeling & Source Characterization - Refine computational models of the targeted wind tunnel's upstream environment, focusing on detailing how disturbances generate in the driver/reservoir and focus/propagate through the throat.Task 2: Upstream Diagnostic Suite Development - Build and calibrate a rugged, high-frequency flow and acoustic diagnostic system tailored for non-optical or highly confined spaces (e.g., micro-fiberoptic probes, flush-mounted acoustic arrays). Compare the novel diagnostic system developed for this task against low-order system-scale or component-specific high-fidelity predictive models.Task 3: Facility Integration & Baseline Upstream Characterization - Deploy the diagnostic suite developed in Task 2 on the targeted wind tunnel to map baseline fluctuations directly within the upstream driver, reservoir, or throat. The measurements will correlate and support the refinement of Task 1 efforts.Phase II Base Period (12 Months) The Phase II Base effort will focus on designing and validating the laboratory-scale prototype of the upstream diagnostic system and completing the engineering/integration plans for the upstream noise-mitigation hardware.Month 4: Diagnostic System Architecture & Preliminary Designi. Deliverable: Preliminary Design Review (PDR) Document and Upstream Diagnostic Specification Report.ii. Criteria: Selection of target wind tunnel facility completed; integration layout for upstream diagnostics (e.g., sensor ports, fiber-optic bypasses) finalized; preliminary numerical models of upstream mitigation hardware and observed environment completed.iii. Associated Tasks: 1, 2 Month 8: Diagnostic Calibration & Component Assemblyi. Deliverable: Confined-Space Diagnostic Calibration and Benchtop Testing Report.ii. Criteria: Successful benchtop demonstration of the diagnostic tool under simulated high-pressure/temperature conditions, showing a frequency response of at least 100 kHz and the ability to capture fluctuations through restricted-access portsiii. Associated Tasks: 2 Month 12: Baseline Diagnostic System Critical Design Review (CDR)i. Deliverable: CDR Document, Upstream Structural/Thermal Safety Analysis, and Final Base Report.ii. Criteria: Final engineering drawings for upstream noise-mitigation hardware approved; structural/thermal safety and tunnel compatibility certified by target facility operators for high-pressure zones; integration interface finalized.iii. Associated Tasks: 1, 2 Phase II Option Period (12 Months) The Phase II Option will focus on facility integration, mapping the baseline noise directly from the upstream components, and demonstrating a quantifiable reduction in freestream noise downstream. Month 18: Facility Installation & Baseline Mappingi. Deliverable: Baseline Upstream Characterization and Integration Report.ii. Criteria: Successful integration of the diagnostic suite into the target facility's upstream components (reservoir, throat, and/or driver); baseline fluctuation measurements completed under nominal run conditions (minimum Mach 5) with and without existing noise mitigation strategies (if present in selected tunnel).iii. Associated Tasks: 3 Month 24: Upstream-to-Downstream Noise Source Correlationi. Deliverable: Upstream Source Localization and Propagation Analysis Report.ii. Criteria: Detailed spatial and temporal mapping of the flow path completed, successfully correlating fluctuations measured upstream (e.g., driver-gas acoustic focusing or throat shear-layer noise) with the resulting freestream acoustic noise in the downstream test section. Notional mitigation plan developed for observed flow characteristics.iii. Associated Tasks: 1, 3

DoD/Military Applications: High-fidelity aerodynamic and aerothermodynamic characterization of hypersonic weapons systems, glide vehicles, and interceptors across Major Range and Test Facility Bases (MRTFB), such as the Arnold Engineering Development Complex (AEDC). Understanding the mechanisms for tunnel noise generation directly translates to higher-fidelity ground-test data, more accurate boundary-layer transition prediction, and accelerated flight-test qualification.Commercial Applications: Commercial space launch vehicle design, thermal protection system (TPS) testing, and academic/commercial aerospace wind tunnel facility diagnostic upgrades. The rugged, non-optical high-frequency diagnostic systems developed under this topic have immediate commercial application in monitoring turbulent combustion chambers, gas turbine engines, and high-pressure chemical reactors where optical access is similarly restricted.

Develop a low-cost, small form factor, attritable passive radar sensor capable of detecting and tracking targets using external RF signals for tactical unmanned and expendable platforms.

In contested A2/AD environments, active radar emissions act as beacons for adversary Electronic Warfare. To ensure survivability, the DoW requires covert sensing utilizing "illuminators of opportunity." This effort requires a 100% receive-only payload; the sensor shall not transmit any RF energy.Current passive systems are bulky, expensive, and primarily optimized for SIGINT/ESM rather than radar functionality. They lack the tightly synchronized, multi-channel receivers necessary for direct reference signal acquisition, spatial processing, and clutter cancellation. The DoW seeks a paradigm shift toward low-cost, multi-channel "attritable" (expendable) sensors designed specifically for high-risk deployments.This topic seeks the development of a Small Form Factor (SFF) passive X-Band radar featuring both Synthetic Aperture Radar (SAR) imaging and Ground Moving Target Indicator (GMTI) capabilities. Optimized for extreme Size, Weight, Power, and Cost (SWaP-C) constraints, the payload must be light enough for integration onto Group 1 or 2 UAS, loitering munitions, or unattended ground sensors.

The objective of Phase I is to conduct a feasibility study to determine the scientific, technical, and commercial merit of a small form factor, attritable passive radar architecture. Offerors are expected to define a comprehensive system architecture, identifying critical low-cost receiver components, antenna configurations suitable for SFF platforms, and highly efficient edge-processing hardware. The effort will include developing proof-of-concept signal processing algorithms for reference signal isolation, clutter cancellation, and target detection and/or tracking under constrained computational limits. The desired end product is a robust simulation and a basic laboratory prototype that validates the feasibility of detecting targets using signals of opportunity while strictly adhering to the SWaP-C metrics required for expendable systems.

Phase II culminates in the delivery of a viable hardware prototype. Offerors are expected to transition their Phase I concepts into a physical, highly miniaturized sensor prototype suitable for integration onto a small UAS or expendable ground node. The minimum required deliverable is a functional prototype that successfully demonstrates passive stationary and moving target detection, tracking, and imaging in a realistic outdoor environment utilizing RF illumination (cooperative or non-cooperative signals of opportunity) without emitting any RF energy from the passive sensor itself. The performer must characterize system performance, demonstrate real-time edge processing that outputs actionable products, and validate that the unit cost and SWaP footprint meet the criteria for a truly attritable tactical asset.

In Phase III, the expendable passive radar sensor is expected to transition into operational military platforms and commercial markets, supported by non-SBIR/STTR funding. For DoW applications, the technology will be integrated into launched effects, loitering munitions, and distributed unattended ground sensor networks. In the commercial sector, potential applications include low-cost air traffic monitoring, counter-UAS (cUAS) surveillance for critical infrastructure, and general airspace monitoring where adding active RF spectrum clutter is undesirable or prohibited.

The Phase I description says the lab prototype should strictly adhere to the SWaP-C metrics for expendable systems. Does that mean the Phase I hardware itself has to be small and low-cost, or is a benchtop setup with lab gear fine as long as we show the SWaP-C numbers by analysis with a path to miniaturize? Along the same lines, is it OK to run the processing offline on a PC in Phase I, with real-time on the edge hardware coming in Phase II?

The Phase I description calls for a basic laboratory prototype that validates feasibility while adhering to the SWaP-C metrics required for expendable systems. For the Phase I laboratory prototype:May offerors build the prototype from commercial evaluation boards that exceed the target payload SWaP-C, with compliance shown through analysis and a projected integrated payload design? Or must the laboratory hardware itself meet the proposed SWaP-C targets?Is a reduced channel count acceptable for the laboratory demonstration (for example, one reference and one surveillance channel), provided the architecture, analysis, and simulation address the full multi-channel configuration needed for SAR and GMTI in Phase II?

For the Phase II outdoor demonstration, should offerors plan to provide their own illumination source and test location, or does the Government anticipate providing access to a cooperative X-band illuminator or a Government range?

Which Phase I end products does the Government expect to be delivered at the end of the base period (for example the final report, simulation software and source code, recorded data, or the laboratory prototype hardware), as distinct from demonstrated or documented?

For the Phase I laboratory demonstration, is offline (record and process) execution of the proof-of-concept algorithms acceptable, with the computational budget on the candidate edge processor shown by analysis or benchmark, or is execution on the candidate edge-processing hardware expected in Phase I?

The Phase I description calls for a basic laboratory prototype "while strictly adhering to the SWaP-C metrics required for expendable systems." Is the Phase I laboratory prototype hardware itself expected to meet the offeror's proposed SWaP-C budget, or may it be assembled from commercial laboratory or evaluation hardware, with SWaP-C adherence of the objective design shown by analysis?

Will the system know the radar waveform a priori (cooperative transmitter) or need to acquire the reference waveform (noncooperative waveform).Assuming a noncooperative illuminator from a phased array antenna, will the illuminator be MIMO, having beams directed at the passive receiver and target, or does the passive payload need to be in the beam?Timing coherency is very important for the passive radar configurations. The solicitation suggests GNSS based timing synchronization is not sufficient. Are advanced approaches to timing synchronization in scope for this topic?The lower the UAS group, the more vulnerable to adverse atmospheric conditions that will degrade position and orientation information. For Group 1&2 real-time motion compensation to adapt to platform motion would be required, correct?With respect to the platform antenna, is it expect to be phased array, horn, microstrip?Is there a preferred polarization of the system? (Horizontal, Vertical, Left Hand Circular, Right Hand Circular)There will need to be communication and synchronization between the illumination platform and the passive receiver platform exchanging position and timing information. Should the communications system be part of the design?

Q1A: Both cooperative and noncooperative waveform approaches are acceptable. Offerors should identify and justify their selected approach and any assumptions required for reference-signal acquisition or waveform information.           Q2A: Offerors should not assume that the noncooperative transmitter is MIMO or that its beams are directed at both the passive receiver and the target. Offerors should define and justify their assumed illuminator geometry and demonstrate adequate target illumination and reference-signal acquisition. Q3A:  While the solicitation does not state that GNSS-based timing synchronization is insufficient, offerors may propose GNSS-based or advanced synchronization methods and should justify the required timing coherence and accuracy. Q4A: Offerors should address motion estimation and compensation sufficient to support their proposed SAR/GMTI performance. Q5A: The antenna configuration is up to the offeror. Offerors should select and justify the configuration based on required performance, platform integration, and SWaP-C. The antenna is part of the passive radar system and should be included in the payload SWaP-C budget. Q6A: No preferred polarization has been established. Offerors should select and justify the polarization based on the assumed illuminator, geometry, propagation environment, target and clutter characteristics, antenna and receiver design, and SWaP-C.. Q7A:  If communications are required as part of the proposed design, offerors should identify that communications as a dependency and state the type of communication required, including the interface, availability, performance, and SWaP-C impacts.

1.Which classes of X-band illuminator does the government envision as the primary design case: spaceborne SAR constellations, maritime or weather radars, cooperative friendly emitters such as a standoff platform's radar, or adversary radars? Is an architecture optimized for a cooperative friendly illuminator with known waveform responsive, or must the sensor exploit non-cooperative signals with unknown waveforms? 2. Is X-band a firm requirement, or is it driven by SAR resolution and the expected illuminator set? Would a multi-band or receiver-agnostic architecture that demonstrates the processing chain at a lower band with denser illuminators, then scales to X-band, be considered responsive in Phase I? 3. What unit cost, weight, volume, and power targets define 'attritable' for this effort, and which platform is the design driver: Group 1 UAS, Group 2 UAS, loitering munition, or unattended ground sensor?  4. Between SAR imaging and GMTI, which is the priority capability for Phase II demonstration? What target classes (vehicles, dismounts, small boats, low-flying aircraft), detection ranges, SAR resolution, and update rates would constitute operationally meaningful performance? 5. Does the government require direct-path acquisition of the reference signal on a dedicated channel (implying line of sight to the illuminator), or are waveform reconstruction and known-waveform approaches acceptable? Should the architecture assume GNSS timing and position are available, or should it be designed for GNSS-degraded operation? Is multi-node coherent processing across several attritable sensors in scope? 6. What constitutes an acceptable 'basic laboratory prototype': a COTS multi-channel SDR receiver detecting controlled targets against a lab X-band emitter, or an over-the-air demonstration against a real illuminator of opportunity? Is record-and-process acceptable in Phase I, with real-time edge processing deferred to Phase II? Will the government provide reference waveforms, recorded datasets, illuminator schedules, or range access for Phase I or II testing?

Q1A: The Government has not identified a specific required illuminator or waveform. For operational context, illuminators of opportunity may include active X-band transmissions originating from Army Aviation assets, as well as other cooperative or non-cooperative emitters. Offerors should identify and justify assumptions regarding source availability, geometry, waveform information, synchronization, link budget, processing, CONOPS, and SWaP-C.  Q2A: Supplemental frequency bands or a receiver-agnostic architecture may be proposed; however, X-band capability is required. Any lower-band or multiband demonstration should establish a credible path to implementing and validating the required X-band capability. Q3A: No fixed numerical thresholds or priority platform have been established. Offerors may select a representative Group 1 or Group 2 UAS, loitering munition, or unattended ground sensor; a universal design is not required. Proposals should provide platform-specific SWaP-C and recurring unit-cost estimates at a stated production scale, including antenna, receiver, synchronization, navigation or motion compensation, processing, packaging, and thermal-management requirements. The design should be justified for attritable or high-risk deployment. Q4A: Both SAR imaging and GMTI are required for Phase II. The primary operational focus is tactical detection of stationary and moving standard military-sized ground vehicles from an airborne passive radar.  No numerical thresholds have been established for range, resolution, accuracy, velocity, update rate, latency, detection probability, false-alarm rate, or target count. Offerors should define and justify measurable performance objectives. Q5A: The Government does not require direct-path reference acquisition on a dedicated channel. Other reference-acquisition methods may be proposed if the offeror justifies how the approach supports the required passive-radar processing.Offerors may assume baseline GNSS timing and position availability for the payload. GNSS-degraded or denied operation is not required, but addressing sensitivity, alternate navigation or timing methods, or degraded-environment operation is encouraged as an optional enhancement.Multi-node coherent processing across several attritable sensors is not required. It may be proposed as an additional capability, but the core sensor capability should not depend on multi-node processing. Q6A: Phase I includes a feasibility study, comprehensive system architecture, proof-of-concept signal-processing algorithms, robust simulation, and a basic laboratory prototype validating target detection using signals of opportunity.  A receive-only laboratory prototype using controlled, injected, emulated, recorded, or off-air X-band signals is acceptable. Live over-the-air or moving-platform hardware demonstrations are not required if the results establish feasibility and a credible path to Phase II. Phase I should address both SAR and GMTI in the architecture, analysis, and simulation, although the laboratory demonstration may emphasize one mode.No Government-furnished sample datasets, recorded I/Q data, or specific radar waveforms are planned to be provided before award. Offerors should use synthetic, open-source, vendor-acquired, or self-generated data for their proposed baseline.  Following award, the Government can work with the awardee during the kickoff meeting to help scope and define representative emitters, waveforms, operational constraints, and parameters, where applicable.

Develop, fabricate, and demonstrate a wafer-scale, monolithically integrated graphene-on-CMOS image sensor that provides broadband imaging from 300 nm to 10,000 nm in a compact, low-power, uncooled focal plane array.

The Navy continues to field multiple seeker technologies to detect, identify and engage targets in multi-domain operations through obscurants. However, you cannot detect something you cannot see. Each wavelength range provide unique opportunity to glean information. Currently, for each wavelength range a distinct material system technology is required: AlGaN for UV, analog devices for NIR, InGaAs for short wavelength infrared (SWIR), HgCdTe (MCT) and III-V strain-layer superlattice (SLS) detectors for MWIR-LWIR. In addition, the incumbent detector technologies — for example indium gallium arsenide (InGaAs). This topic seeks to retire the principal risks that stand between these demonstrations and a fieldable naval imager: (1) graphene material quality and uniformity at the wafer scale — carrier mobility, Dirac-point control, low hysteresis, and low defect density (e.g., Raman D-to-G intensity ratio) held tight across full wafers and lot to lot; (2) repeatable, high-yield BEOL transfer, encapsulation, patterning, and contacting of graphene on CMOS read-out wafers; (3) absorber sensitization and passivation that deliver uniform, stable, low-noise broadband response; and (4) an imaging FPA meeting the noise-equivalent irradiance, dynamic range, frame rate, operability, and stability required for naval ISR. Proposers should target a substantial increase in integrated-device carrier mobility (goal approaching 10,000 cm²/V·s), tight pixel-to-pixel uniformity, and a manufacturable process flow with a clear path to pilot-scale production. photodiode arrays for SWIR are hybridized to a silicon read-out integrated circuit (ROIC) by indium-bump flip-chip bonding. This is a mature approach but constrained by high unit cost, a limited domestic foundry base, pixel pitches that are difficult to scale below roughly 15 µm, array formats limited by hybridization yield, and a spectral response that typically cuts off near 1,700 nm. These constraints limit the resolution, affordability, and proliferation of imagers across the size-, weight-, power-, and cost-constrained (SWaP-c) platforms.

This topic solicits Direct-to-Phase-II (DP2) proposals only; Phase I proposals will not be accepted. Offerors must document that Phase I feasibility has already been established through prior work. Acceptable feasibility evidence includes the fabrication and measured characterization of graphene phototransistor and/or graphene-on-CMOS coupon test structures exhibiting broadband (UV-through-LWIR) photoresponse; demonstration of die- or wafer-scale graphene integration with quantified device yield and uniformity. Documentation may comprise technical reports, peer-reviewed publications, measured data, and design artifacts sufficient to substantiate the scientific, technical, and commercial merit required to enter Phase II. Requirements definition for the naval use case, detailed focal-plane-array performance modeling, and pixel-architecture and back-end-of-line (BEOL) integration-flow design need not be complete at proposal; these activities are carried into the Phase II Base effort below.

Design, fabricate, and deliver a prototype monolithic graphene–CMOS broadband/SWIR FPA, maturing the technology from documented feasibility through a demonstrated camera. The effort is organized into a Base task that completes design and risk reduction and a prototype task that builds and characterizes the imager.Base (design and risk reduction). Define imager requirements against a representative naval ISR use case; develop and validate FPA performance models (spectral response, responsivity, noise-equivalent irradiance, dynamic range, operability); and complete the pixel-architecture and BEOL integration-flow design for a foundry CMOS ROIC. Fabricate and characterize coupon-level and small-array test structures to confirm material quality, integration yield, and broadband photoresponse, and finalize the wafer-scale process definition.Prototype (fabrication and demonstration). Mature the wafer-scale process — graphene growth/transfer, encapsulation, patterning, contacting, and absorber sensitization — to demonstrate high device yield and pixel-to-pixel uniformity across full wafers. Build and demonstrate a functioning broadband camera (sensor plus read-out and minimal supporting electronics and optics) and characterize spectral response, responsivity, noise-equivalent irradiance, dynamic range, frame rate, operability, fixed-pattern noise, and stability against Navy-relevant targets, including passive low-light (atmospheric nightglow) imaging and imaging through obscurants such as fog and haze. Conduct an initial environmental and reliability assessment.Deliverables. Validated performance models and final FPA design; prototype FPA(s)/camera(s); the documented wafer-scale process flow with measured yield and uniformity; a full test-and-evaluation data package; and a Phase III transition and manufacturing plan, including a path to a pilot qualification lot on the order of tens of wafers with defined yield and performance metrics.

Transition the technology to naval and joint platforms that require affordable, compact, broadband/SWIR imaging — unmanned aerial, surface, and undersea vehicles; handheld, weapon-, and helmet-mounted night-vision and threat-warning systems; shipboard situational-awareness and navigation suites; and distributed or expendable sensor nodes — and to hyperspectral and multispectral payloads for camouflage/decoy discrimination and littoral mine countermeasures. Establish and qualify a domestic, CMOS-foundry-based manufacturing capability for monolithic 2D-material FPAs. The same platform carries broad commercial dual-use value in automotive and autonomous-vehicle vision (through fog, smoke, and darkness), machine vision and semiconductor/solar-wafer inspection, agricultural and food-quality sorting, medical and biometric imaging, and environmental and industrial-process monitoring, supporting an economically sustainable supply base.

The objective of this Phase II effort is to design, validate, and demonstrate a secure, high-density private 5G network platform for stadiums and large venues—integrating open-source OCUDU, SD-Core, SD-RAN, and OSC components—to deliver resilient, multi-service communication alongside a 6G-ready Integrated Sensing and Communication (ISAC) architecture. This platform will be validated at a representative venue site to prove stable performance under extreme device congestion, enable native device localization for crowd analytics, and establish a cost-effective, vendor-neutral dual-use framework for both commercial entertainment venues and dense military installation environments.

The realistic near-to-mid-term serviceable addressable market for private 5G/6G-ready platforms among U.S. venues and stadiums is a subset of venues with acute connectivity, safety, and operational pain: major-league and collegiate stadiums, multi-purpose arenas, outdoor amphitheaters, and convention/exhibition centers that host recurring high-density events, require public-safety-grade coverage throughout bowls, concourses, tunnels, and back-of-house areas, and are increasingly asked to support fan-facing digital experiences, cashier less concessions, camera and sensor networks, and first-responder communications simultaneously on event day. Venues already invest heavily in connectivity infrastructure, yet several published industry reports indicate persistent cost and coverage pain. Distributed Antenna System (DAS) deployments in large public venues have grown from a few million dollars in early builds to routinely tens of millions of dollars. Independent of venue scale, active multi-carrier DAS hardware and installation is commonly quoted at $5–$10 per square foot, meaning even a mid-sized 300,000 sq. ft. concourse/bowl footprint implies a multi-million-dollar build before integration, spectrum, and ongoing carrier-management costs.The United States features an extensive footprint of sports and entertainment infrastructure, spanning an estimated 2,000 to 5,000 major stadiums and arenas when accounting for all professional, collegiate, and municipal facilities, which further scales to over 15,000 total venues if relatively large localized high school stadium is included. Beyond stadiums and arenas, industry directories catalog well over 400 U.S. convention and exhibition centers, ranging from single-hall regional facilities to multi-million-square-foot complexes. Together, these figures put the large-venue addressable base at several hundred U.S. facilities, before counting mid-sized arenas, amphitheaters, and secondary convention space. Besides, localized specific large gatherings (such as fairs) add up to several thousand.Despite this infrastructure spend, published reviews consistently cite coverage dead zones in lower bowls and concourses, congestion during peak moments (kickoff, halftime, entry/egress), and multi-year vendor lock-in as recurring pain points, and industry reporting suggests that MNO appetite to fund new DAS builds outside "Tier 1" venues (70,000+ capacity or 200+ events/year) is shrinking, leaving small and mid-sized venues with a widening connectivity gap.This segment buys on measurable fan and operational outcomes (dropped-call rate at kickoff, POS uptime, camera uptime, incident-response time), not on global platform standardization, and its stated barriers to adopting anything other than the incumbent DAS/neutral-host model are consistent: high capex and multi-year contract terms, uncertainty about interoperability across multiple wireless carriers that must all be hosted on one system, integration complexity with legacy venue IT/OT and public-safety radio systems, and a lack of in-house RF/cellular engineering staff.An all-open-source stack removes the structural cost and lock-in that makes proprietary DAS platforms a poor fit for this segment's economics. Because OCUDU communicates with the rest of the network over open, standardized interfaces (especially the O-RAN 7.2x split to the O-RU), the network can be assembled from whichever RU vendor and antenna form factor best fits a given venue's bowl geometry, concourse layout, and budget. Together, OCUDU, SD-Core, SD-RAN, and OSC form one integrated, fully open-source 5G stack that a systems integrator can deploy, support, and price as a right-sized, as-a-service offer for a single venue, rather than a broad, vendor-locked, multi-carrier neutral-host platform.The trade-off of an all-open-source stack is the same one seen in other verticals: the burden of proving interoperability, stability, and security shifts from a single vendor's warranty to the integrator and the open-source community. Venue operators, who by their own account do not carry in-house cellular or RF engineering expertise, have essentially zero tolerance for connectivity failures discovered live, on a broadcast event, in front of tens of thousands of people. This is exactly the gap the on-going OCUDU Testing & Validation Plan, and its RTEC-centered extensions, are designed to close: independently witnessed, multi-vendor testing of device diversity, RU diversity, high-density/high-mobility RF performance, Core/RIC/SMO integration, and security. The proposal should leverage the current, on-going testing and evaluation activities in RTECs and associated results on this front.Although this topic is anchored in a specific vertical to ensure a concrete deployment environment, real users, and a defensible commercialization path, proposers should recognize and are required to present the technical work in terms of the generic network performance classes it advances. Improvements made to the OCUDU O-CU/O-DU under this effort (scheduler behavior, mobility management, uplink capacity, stability under sustained load, security features) are expected to generalize across verticals and to benefit the broader community of RAN developers building on OCUDU. The Technical Volume shall include a mapping of each selected use case, and its associated Section 3.0 KPMs, to the performance class or classes it exercises, and shall identify which anticipated OCUDU code or feature enhancements correspond to each class.

This topic is accepting Direct to Phase II proposals ONLY. Therefore, a formal Phase I award will not be issued. To qualify for a Phase II award, proposers must submit Feasibility Documentation (as part of their proposal package) demonstrating that they have already completed "Phase I-type" research and development. The purpose of this documentation is to prove that the underlying technology is mature, scientifically sound, and ready to transition immediately into the Phase II prototyping and testing environment. The Government will accept a wide variety of documentation styles. Proposers do not need to have a perfect, finished product, but they must show that their core ideas have been successfully tested. One or more of the following items should be included to prove technology readiness:Test Data & Metrics: Real-world measurements, performance charts, or network test data from previous lab environments or early field trials.Technical Reports & White Papers: Written summaries explaining your previous research, system designs, or software integration efforts.Prototype Designs & Simulation Models: Diagrams, architectural blueprints, or computer simulation results showing how your proposed software and hardware components interact.Previous Project Outcomes: Success criteria, milestone reports, or commercialization results from prior private, academic, or non-SBIR federally funded work.

For this topic, the dominant performance classes are extreme user density, ultra-secure operation, and integrated sensing: tens of thousands of concurrent devices per venue with sharp event-day load peaks, public-safety-grade availability and access control across bowls, concourses, and back-of-house areas, and an architecture evolvable to 6G Integrated Sensing and Communication (ISAC). Research and development for this effort should address, at minimum, the following questions:All-Open-Source Economics: What is the fully loaded cost (integration, support, spectrum, hardware, RF design) of an OCUDU + SD-Core + SD-RAN + OSC deployment at venue scale relative to a proprietary DAS/neutral-host platform, and how should that be packaged as a CBRS-based, as-a-service offer within the price point venue operators require?Use-Case-First Deployment: Which of the use cases defined below deliver the fastest, most measurable ROI on the open-source stack, and what RTEC-executed interoperability tests (Device, RU, Core, RIC/SMO, and Infrastructure dimensions) are needed to validate each one end-to-end under stadium-scale, high-density loading conditions?6G/ISAC Evolution Path: What architectural changes (waveform, RU capability, RIC application, and SMO orchestration) are required to evolve the platform from a 5G communications-only deployment to a 6G-ready platform capable of Integrated Sensing and Communication, and which ISAC-enabled use cases can be prototyped now using 5G-Advanced sensing features as a bridge to native 6G ISAC?Trust in Open Source: How does RTEC-executed testing of the full open-source stack reduce the integration risk and skills-shortage barrier venue operators most often cite, and what evidence package best converts community-maintained, no-license-fee software into a procurement-ready proof point for a buyer with no in-house cellular expertise? Solutions leveraging artificial intelligence (AI) and machine learning (ML) for crowd analytics, predictive maintenance, network optimization, or automated fault resolution are encouraged but not required. DoW will consider any novel concept that increases the reliability, economics, and trustworthiness of an all-open-source private 5G/FutureG platform for the venues and stadiums vertical.Dual-use opportunities are expected across commercial venue operators, DoW-affiliated event and installation venues, and public-safety agencies. Proposers must address at least two of the following four use cases in their Phase II Statement of Work and must identify which use case(s) their reference architecture and pilot deployment are designed to validate. Each use case below is defined in terms of the operational scenario it supports, the connectivity and/or sensing requirement it places on the platform. Device-Class Diversity and 5G RedCap. Each use-case set spans device classes from full-capability UEs (equipment modems, cameras, broadcast and production units) to reduced-capability IoT endpoints (sensors, wearables, tags, and trackers). Proposers shall address how the platform serves reduced-capability device classes, including 3GPP Release 17 Reduced Capability (RedCap) and Release 18 eRedCap UEs, and shall identify any OCUDU scheduler or feature enhancements required to support RedCap operation; such enhancements are strongly encouraged as upstream contributions under the common OCUDU benchmarking and enhancement work package. Where RedCap-certified devices are not commercially available for a given endpoint type at demonstration time, proposers may demonstrate with available device classes (or emulated RedCap UE profiles) and shall document the RedCap migration path. Use Case 1: High-Density Fan Connectivity & Broadcast/Production BackhaulTens of thousands of fans, concession point-of-sale terminals, ticketing scanners, and broadcast/production camera and audio feeds must all operate simultaneously within a single bowl and concourse footprint, with demand spiking sharply at kickoff, halftime, and egress. Legacy DAS and Wi-Fi are commonly saturated at these peak moments, producing dropped sessions and stalled transactions. This use case requires the platform to sustain high concurrent-device density with consistent per-user throughput, plus dedicated low-latency, low-jitter uplink capacity for broadcast and production camera backhaul, across the full bowl and concourse footprint. Use Case 2: ISAC-Enabled Crowd Analytics & Situational Awareness (6G-Ready)Venue operators and public-safety personnel need continuous, accurate awareness of crowd density, flow, and anomalies (bottlenecks at egress, unattended objects, unauthorized drone incursion into restricted airspace above the bowl) to prevent crushing incidents/stampedes and respond quickly to emerging threats. Deploying a separate dedicated sensor network (radar, lidar, additional camera arrays) to provide this awareness is costly and adds another system to integrate. This use case requires the platform to support Integrated Sensing and Communication (ISAC). ISAC uses the same radio infrastructure and spectrum that carries communication traffic to also sense the physical environment (bistatic or monostatic sensing from gNB/O-RU hardware, correlated with RIC-hosted analytics applications), without requiring a separate sensing-only network build. [3GPP Release 19 Technical Report (TR) 22.837 identifies more than 30 ISAC use cases spanning applications such as object and intruder detection, environmental monitoring, motion sensing, and public-safety scenarios directly applicable to stadiums, arenas, and convention centers. Complementing these use cases, 3GPP TS 22.137 establishes a standardized set of ISAC performance metrics, including positioning accuracy, velocity accuracy, sensing resolution, sensing range, refresh rate, latency, and missed-detection and false-alarm probabilities, to enable consistent evaluation and deployment of sensing-enabled wireless networks.] Proposers should treat 5G-Advanced sensing features as the near-term bridge path toward native 6G ISAC. Hybrid localization architecture. Proposers shall employ a hybrid architecture in which standardized network-native UE positioning (3GPP Release 16/17 NR positioning: UL-TDoA, multi-RTT, AoA/AoD) over the connected device population provides the primary, near-term source of crowd density, flow, and bottleneck analytics, with appropriate aggregation and anonymization for fan-facing devices and RF sensing (ISAC) is applied to non-cooperative targets that carry no connected device. Crowd-analytics KPMs may be satisfied via UE positioning in the Phase II demonstration. Tiered scope. Sensing functions under this use case are tiered by 12-month feasibility. Tier 1 (Phase II demonstration): (a) crowd density and flow analytics derived from network-native UE positioning of connected devices (see the hybrid-localization requirement above), aggregated and anonymized; and (b) at least one non-cooperative RF-sensing bridge function achievable at 5G-Advanced maturity and deployed sensing bandwidths (for example, detection of unauthorized drone incursion exploiting Doppler and motion signatures) demonstrated in a laboratory or limited field configuration. Tier 2 (roadmap): unattended-object detection and fine-grained tracking of individuals within dense, multi-directional crowds, which are limited by achievable sensing resolution (approximately c/2B) at deployable bandwidths; these shall be addressed in the documented 6G/ISAC evolution path with quantified bandwidth, waveform, aperture, and sensor-fusion requirements rather than demonstrated in Phase II. Custom or modified waveforms are not required for Phase II. The Positioning/Velocity accuracy, Anomaly Alert, and Missed-Detection/False-Alarm KPMs in the table below apply to the Tier 1 demonstrated function(s). Use Case 3: Public Safety & First Responder Priority CommunicationsFirst responders, venue security, and event staff require reliable, prioritized push-to-talk and data communications throughout the bowl, concourses, tunnels, loading docks, and below-grade back-of-house areas that legacy DAS and Wi-Fi frequently fail to reach or fail to prioritize during network congestion. This use case requires the platform to sustain low-latency, high-reliability, priority/preemption-capable connectivity for public-safety traffic across the full indoor venue footprint, including areas outside typical fan-facing coverage design. Use Case 4: Venue Operations, Logistics & Outdoor Perimeter CoverageLoading docks, outdoor plazas, parking structures, and perimeter areas surrounding a venue increasingly require connectivity for autonomous cleaning and security robots, connected cameras, RFID/asset tracking for concessions and merchandise logistics, and credentialed-access control, yet typically fall outside indoor DAS/Wi-Fi coverage entirely. This use case requires the platform to extend secure, private coverage into outdoor plaza, parking, and perimeter areas immediately adjacent to the venue, using the same OCUDU-based infrastructure rather than a separate outdoor Wi-Fi or cellular repeater buildout. KPMs for Phase IIFor Phase II, proposers should address specific, relevant, measurable, and quantifiable key performance metrics (KPMs), including, for example, concurrent-device density, sensing detection accuracy, latency, jitter, and service availability. An example KPM in context could be as follows: "The platform must sustain a session success rate greater than 99.5% for fan-facing connections at a concurrent-device density of 3,000 devices per acre in the lower bowl." Other suggested KPMs for the various use cases and system requirements are given below for reference. The KPM values in the tables below are suggested reference values, not pass/fail contract requirements. Proposers shall propose specific, justified KPM targets in the Technical Volume, calibrated to their selected use cases, demonstration environment, spectrum plan, and channel bandwidth; deviations from the suggested values must be technically justified. Threshold values represent the intended standard of Phase II demonstration success; Objective values are stretch goals, some of which are expected to mature during Phase III or along the FutureG evolution path. Final KPM targets will be agreed with the Government at kickoff and confirmed at the Critical Design Review. Consistent with Section 4.1, partial achievement within a defined and documented scope may be considered successful. Latency measurement definition. Latency KPMs in this document denote round-trip application-layer latency measured between the UE application interface and the local edge application endpoint served behind the on-site/edge UPF (i.e., device-to-edge through the RAN and core user plane, excluding external WAN transport). Handover time denotes user-plane interruption time at the RAN, per 3GPP definitions. For each latency KPM adopted, proposers shall specify the measurement reference points, the traffic type and packet size, and the measurement methodology (e.g., KPI definitions per 3GPP TS 28.554), and shall include in the Critical Design Document a latency budget decomposition across air interface, DU/CU processing, fronthaul and F1 transport, core user plane, and application processing. Suggested KPMs for Use Case 1: High-Density Fan Connectivity & Broadcast/Production BackhaulThese metrics focus on the platform's ability to sustain high device density and dedicated broadcast/production bandwidth during peak event moments. Thresholds are anchored to published stadium Wi-Fi/DAS deployment data; a particular venue's own concurrent-connection and peak-throughput figures may be used instead to calibrate a proposer's specific KPM targets.KPM CategoryKey Performance Metric (KPM)Suggested Threshold (Minimum Success)Suggested Objective (Desired Success)ScalabilityConcurrent Connection Take Rate: Percentage of ticketed attendance connected to the platform simultaneously during peak load. 20,000 devices60,000 devicesThroughput[small/medium venue config.]Aggregate Peak Throughput: Combined uplink/downlink throughput sustained across the platform during peak load. > 10 Gbps aggregate> 15 Gbps aggregateReliabilitySession Success Rate: Percentage of data sessions completed without error or drop during peak event moments (kickoff, halftime, egress).> 99%   > 99.9%TimelinessBroadcast Backhaul Latency & Jitter: Round-trip latency and jitter for production camera/audio uplink traffic.< 30 ms latency, < 10 ms jitter< 15 ms latency, < 5 ms jitterPer-User ThroughputPer-Active-User Experienced Data Rate: data rate experienced by active users at the 95th percentile during peak event moments.≥ 5 Mbps DL / ≥ 2 Mbps UL≥ 25 Mbps DL / ≥ 10 Mbps UL (consistent with 3GPP TS 22.261 dense-crowd targets) Note: The connection-count and throughput rows above size the network as a whole; they are not meant to be divided into a per-device rate. At any moment most connected devices are idle, so the average per connected device is naturally low (a few hundred kbps). The performance an individual user must actually experience is set by the Per-Active-User Experienced Data Rate KPM above. Suggested KPMs for Use Case 2: ISAC-Enabled Crowd Analytics & Situational Awareness (6G-Ready)These metrics measure the platform's ability to deliver accurate, low-latency sensing insight using shared radio infrastructure, alongside its ability to maintain communication-traffic performance while sensing is active. KPM CategoryKey Performance Metric (KPM)Suggested Threshold (Minimum Success)Suggested Objective (Desired Success)Sensing Accuracy (Position)Positioning Accuracy: Deviation between ISAC-derived object/person position estimate and ground truth.1 - 10 m   1 - 10 cm (long-term research target)Sensing Accuracy (Velocity)Velocity Accuracy: Deviation between ISAC-derived velocity estimate of a moving object/person and ground truth.1 - 10 m/s   < 1 m/sTimelinessAnomaly Alert Latency: Time from a sensing-detected anomaly (e.g., unauthorized drone incursion, unattended object, crowd-crush precursor) to alert receipt at the monitoring system.< 3 seconds< 1 secondReliabilityMissed-Detection / False-Alarm Probability: Percentage of anomaly events missed or falsely flagged by the ISAC sensing function (per the missed-detection and false-alarm KPIs defined in 3GPP TS 22.137).< 5% missed detection, < 10% false alarm< 1% missed detection, < 3% false alarmCoexistenceCommunication-Throughput Impact: Percentage reduction in available communication throughput attributable to concurrent sensing operation.< 15% reduction< 5% reductionCoverageSensing Range: Effective sensing radius from a single gNB/O-RU for crowd and object detection.> 50 meters> 100 metersSensing Resolution (Tier 2 / lab and roadmap)Range Resolution: minimum separable distance between two objects, per 3GPP TS 22.137, at the demonstrated effective sensing bandwidth.≤ 2 m (laboratory, ≥ 100 MHz effective sensing bandwidth)≤ 0.5 m (roadmap; documented path via wider bandwidth/6G waveforms)Positioning (Tier 1)UE Positioning Accuracy: horizontal positioning error for connected devices using NR positioning methods (Rel-16/17), at 90% confidence, across bowl and concourse areas.< 10 m< 3 m Suggested KPMs for Use Case 3: Public Safety & First Responder Priority CommunicationsThese metrics measure the platform's ability to deliver reliable, prioritized, low-latency coverage for safety-critical communications across the full venue footprint, including areas not typically covered by fan-facing design. Thresholds are anchored to 3GPP mission-critical push-to-talk standards and the IFC/NFPA in-building public-safety radio coverage codes already applied to venue construction.KPM CategoryKey Performance Metric (KPM)Suggested Threshold (Minimum Success)Suggested Objective (Desired Success)TimelinessPush-to-Talk Access Time: Time from a first-responder PTT keypress to receipt of permission to speak. < 300 ms   < 150 msAvailabilityService Availability: Percentage of time the network is operational for safety-priority traffic in public-safety-designated zones.> 99.9%> 99.999%CoverageCoverage Completeness: Percentage of designated public-safety zones (tunnels, back-of-house, below-grade areas, loading docks) with verified signal coverage.> 95% general areas / 99% critical areas (IFC 510 / NFPA 1225 minimum)100%PriorityPreemption Success Rate: Percentage of instances where public-safety traffic is successfully prioritized over congested fan-facing traffic during peak load.> 99%   > 99.9% Suggested KPMs for Use Case 4: Venue Operations, Logistics & Outdoor Perimeter CoverageThese metrics measure the platform's ability to extend secure, private coverage into outdoor plaza, parking, and perimeter areas adjacent to the venue and to support mobile operational assets such as autonomous robots and connected cameras. Coverage-radius thresholds are informed by published CBRS small-cell propagation figures.KPM CategoryKey Performance Metric (KPM)Suggested Threshold (Minimum Success)Suggested Objective (Desired Success)CoverageOutdoor Coverage Radius: Distance from the nearest small cell at which the platform maintains a usable connection for plaza, parking, and perimeter assets > 200 meters (~650 ft, consistent with CBRS Category A)> 500 meters (~1,640 ft, within CBRS Category B outdoor range)MobilityHandover Success Rate: Percentage of handovers completed without session drop as autonomous robots or connected vehicles move between indoor and outdoor coverage.> 98%   > 99.5%ReliabilitySession Success Rate (Outdoor): Percentage of data sessions completed without error or drop in outdoor perimeter conditions.> 98%> 99.5%SecurityUnauthorized Access Attempts Blocked: Percentage of unauthorized association/connection attempts detected and blocked at the outdoor perimeter.> 99%100% Suggested KPMs for General System & Architectural RequirementsThese metrics focus on the non-functional requirements of the all-open-source stack itself, ensuring it is efficient, scalable, interoperable, 6G-evolvable, and compliant with the O-RAN architecture.KPM CategoryKey Performance Metric (KPM)Suggested Threshold (Minimum Success)Suggested Objective (Desired Success)InteroperabilityRTEC-Validated Reference Configurations: Number of distinct RU/hardware-accelerator/RIC-SMO combinations validated through RTEC testing and available as reusable reference configurations. ≥ 2 combinations≥ 5 combinationsComplianceO-RAN Interface Compliance: Adherence to specified O-RAN Alliance interface standards (E1, F1-C/F1-U, O-RAN 7.2x, O1, E2).100% pass of a defined conformance test suite100% pass of a defined conformance test suiteEconomics Fully Loaded Deployment Cost: Total cost (hardware, integration, support).≤ 30% of an equivalent DAS system≤ 20% of equivalent DAS systemScalabilityManaged Device Capacity: Number of concurrent fan, operations, and sensing-relevant devices a single deployment can support.   20,000 devices60,000 devicesEvolvability6G/ISAC Readiness: Demonstrated bridge-path capability (via 5G-Advanced sensing features) toward native 6G Integrated Sensing and Communication.Documented roadmap with lab-validated bridge feature(s)Field-demonstrated bridge feature(s) at pilot siteLicensingProprietary Component Count: Number of proprietary core, RIC, or SMO components in the deployed stack.00Device-Class SupportRedCap UE Support: demonstrated attach, session establishment, and mobility for Rel-17 RedCap UEs (or emulated RedCap profiles where commercial devices are unavailable).Lab-validatedField-demonstrated at the pilot/demonstration site Phase II consists of an eighteen-month PoP focused on prototype production, test, and evaluation. Key milestones include:Month 1: Kickoff and TIMMonthly Status Reports (MSRs)Month 12: Critical Design Review (CDR)Month 16: Prototype demonstrationMonth 14: Final design review, demonstration, and assessmentMonth 18: Final Phase II Report MSRs are to be presented to the OCUDU T&E Working Group as well, bringing the community up to speed on progress. Prototype demonstrations will be performed at the proposer's site, ideally an operating or representative venue/stadium environment (or a full-scale representative test bed where live-venue access is not feasible during Phase II). Partial solutions may be considered successful if effective within a defined scope. A final technical report detailing the capabilities demonstrated will be required. Extended user evaluations or additional prototypes may be pursued based on utility. OCUDU and Open-Source IntegrationThe Open Centralized Unit Distributed Unit (OCUDU) software codebase is released and continuously enhanced with a 3GPP-compliant open-source Centralized Unit (CU) and Distributed Unit (DU) implementation supporting open interfaces. Proposers should integrate OCUDU together with SD-Core (5G Core), SD-RAN (Near-RT RIC), and the OSC stack (Non-RT RIC and SMO) into a single, fully open-source reference architecture, with no proprietary core, RIC, or SMO component anywhere in the stack. Proposers should additionally document, and where feasible demonstrate, the specific RAN and RIC-application changes required to bridge toward native 6G ISAC capability. The MVP demonstration, including physical RUs and UEs (and, for Use Case 2, ISAC-capable RU/sensing hardware or software-defined sensing functions), will need to occur at the venue-representative site described above. Performers should address scalability, including testing across multiple RU vendors and hardware-accelerator options, and should leverage RTEC-executed interoperability testing to address integration risks ahead of the demonstration wherever a validated reference configuration already exists. OCUDU Baseline Benchmarking and Upstream Enhancement:All performers under this topic shall execute the following common work package, which is a required element of the Phase II Statement of Work regardless of the use cases selected. Task A: Baseline Benchmark. Establish a quantified performance baseline of the integrated open-source stack (OCUDU + SD-Core + SD-RAN + OSC) against the KPMs relevant to the selected use cases, including the General System and Architectural Requirements. An emulated end-to-end configuration (emulated RUs and UEs, RF channel emulation, and/or synthetic load generation) is acceptable and encouraged for the baseline, provided the benchmark methodology, tooling, configurations, and results are fully documented and reproducible. Where an RTEC-validated reference configuration already exists for the proposed RU/Core/RIC/SMO combination, the baseline shall incorporate available RTEC results rather than duplicate them. Baseline methodology and results shall be presented to the OCUDU T&E Working Group. Task B: Code and Feature Enhancement. Identify the gaps between baseline performance and the threshold and objective values, and develop the OCUDU code improvements and features required to close them (e.g., scheduler and QoS enhancements, mobility/handover optimization, uplink capacity improvements, stability hardening, security features). All modifications to OCUDU shall be contributed upstream through the project's standard contribution and review process; enhancements that cannot be upstreamed shall be documented with rationale. Progress against each targeted KPM, and the status of each upstream contribution, shall be reported in the Monthly Status Reports presented to the OCUDU T&E Working Group. Task C: Benchmark and Regression Harness. Deliver the emulation-based end-to-end benchmark suite developed under Task A as a repeatable, documented, open-source harness suitable for adoption by the OCUDU community and RTECs for regression testing of future OCUDU releases. This work package complements, and does not replace, the interoperability testing and the physical MVP demonstration required elsewhere in this topic. Emulated results establish the baseline and guide enhancement work; over-the-air performance with physical RUs and UEs at the RTEC and/or representative demonstration site remains the standard of evidence for final KPM achievement. Security RequirementsSecurity shall be a first-class design requirement of the platform, not a demonstration afterthought. Performers shall implement and document a security architecture covering: 3GPP security per TS 33.501 (mutual authentication, air-interface encryption and integrity protection); protection of the O-RAN open interfaces (open fronthaul, E2, A1, O1) per O-RAN WG11 specifications; zero-trust principles per NIST SP 800-207, including least-privilege access and separation of management and user traffic; monitoring of Common Vulnerabilities and Exposures (CVEs) affecting OCUDU and its dependencies, and timely upstream patching. Security features and hardening developed for OCUDU shall be contributed upstream under the common benchmarking and enhancement work package. The security architecture shall be documented at CDR and validated in RTEC testing, and the MVP demonstration shall include at least one security capability shown live (e.g., rejection of an unauthorized device, encrypted fronthaul, or detection of a simulated intrusion). Phase II DeliverablesKickoff and TIM slidesMonthly Status Reports (MSRs)Critical Design Document (full reference architecture: OCUDU + SD-Core + SD-RAN + OSC, including the 6G/ISAC evolution path)Key Performance MetricsMVP Demonstration Slides and Documentation, including a description of the demonstration site's fidelity to venue/stadium conditions and the KPI results achieved against Section 3.0 thresholdsReference Configuration Package: executables, integration documentation, and RTEC test results for the validated RU/Core/RIC/SMO combination(s) usedIntegration of the platform into an RTEC-affiliated test/evaluation network and/or a venue-representative demonstration site, demonstrating at least one of the two selected use cases.Integration of the platform into an RTEC-affiliated test/evaluation network and/or a factory-representative demonstration site, demonstrating at least one of the two selected use cases.OCUDU Baseline Benchmark Report: methodology, emulation environment description, configurations, and measured baseline results against Section 3.0 KPMs (expected by Month 3)Upstream Contribution Log: itemized record of OCUDU code contributions (patches/pull requests), their review status, and the KPM gap each addresses (updated in each MSR; final version in the Final Technical Report)Open-source benchmark and regression harness, with documentation sufficient for independent execution by RTECs and the OCUDU communityFinal Design DocumentFinal Technical Report

The advanced private 5G and FutureG networking platform outlined in this solicitation presents significant dual-use opportunities by leveraging a single, open-source technology stack to serve both commercial venues and critical DoW operational needs. For commercial interests, this technology offers a cost-effective and vendor-neutral alternative to proprietary systems in stadiums, arenas, and convention centers. It aims to enhance fan experiences with high-density connectivity, support broadcast backhauling, and improve venue operations through integrated sensing for crowd analytics and situational awareness.For the DoW, the same platform provides resilient, secure, and high-density wireless coverage essential for DoW-affiliated event venues, training facilities, and large-scale installation assembly spaces. The platform's capability for Integrated Sensing and Communication (ISAC) can be adapted for enhanced situational awareness, asset tracking, and security monitoring in dynamic military environments, ensuring that advancements in commercial wireless technology directly bolster defense capabilities.

The objective of this Phase II effort is to design, validate, and demonstrate a fully open-source, private 5G network platform for smart manufacturing that integrates OCUDU, SD-Core, SD-RAN, and OSC components into a secure, vendor-neutral architecture. This platform will deliver highly reliable, low-latency connectivity to support autonomous robotics, machine vision, and connected-worker safety, providing a cost-effective, FutureG-ready solution for both commercial manufacturers and dual-use defense logistics facilities.

The realistic near-to-mid-term serviceable addressable market for private 5G among U.S. small and medium-sized manufacturers is not "all manufacturers." It is the subset with real mobility, reliability, coverage, or security pain: plants using automated guided vehicles (AGVs), autonomous mobile robots (AMRs), machine vision, connected workers, outdoor yards, large indoor spaces, or metal-heavy RF environments. Manufacturing is already among the leading sectors for private mobile network deployments worldwide, and published case studies show double-digit productivity gains and lower infrastructure capex versus Wi-Fi deployments. Based on data compiled by the National Association of Manufacturers, roughly 50,000 U.S. manufacturing firms fall in the 20-99-employee band alone, with several thousand more in the 100-250 range. This segment buys on simplicity, speed, fit, and economics, not on global platform standardization, and its stated barriers to adoption are consistent and compounding: ROI ambiguity, legacy equipment and retrofit costs, spectrum and regulatory fragmentation, uneven device ecosystems, IT/OT integration complexity, in-house skills shortages, and tight capital budgets. A proprietary platform from a tier-one vendor addresses almost none of these barriers directly; it is priced and supported for large campuses and multi-site accounts, not a single plant with one connectivity problem to solve. An all-open-source stack removes the structural cost and lock-in that makes proprietary platforms a poor fit for this segment. Because OCUDU's O-CU/O-DU communicate with the rest of the network over open, standardized interfaces (especially the O-RAN 7.2x split to the O-RU), the network can be assembled from whichever RU vendor best fits a given plant's bands, form factor, and budget, rather than a single bundled radio line. Together, OCUDU, SD-Core, SD-RAN, and OSC form one integrated, fully open-source 5G stack that a smaller solution provider or systems integrator can deploy, support, and price as a right-sized, as-a-service offer for a single plant, instead of selling a broad, vendor-locked platform. That directly answers this market's stated preference for outcome-first, economically flexible offers, and it supports a Wi-Fi-coexistence posture (private 5G for the hard problem zones, Wi-Fi where it already works) rather than a rip-and-replace sale. The trade-off of an all-open-source stack is that the burden of proving interoperability, stability, and security shifts from a single vendor's warranty to the integrator and the open-source community itself. SMM buyers, who by their own account lack in-house cellular and associated cybersecurity expertise, have little tolerance for integration failures discovered after deployment. This is exactly the gap the on-going OCUDU Testing & Validation Plan, and its RTEC-centered extensions, are designed to close: independently witnessed, multi-vendor testing of device diversity, RU diversity, outdoor RF performance, Core/RIC/SMO integration, and security. The proposal should leverage the current, on-going testing and evaluation activities in RTECs and associated results on this front. Although this topic is anchored in a specific vertical to ensure a concrete deployment environment, real users, and a defensible commercialization path, proposers should recognize and are required to present the technical work in terms of the generic network performance classes it advances. Improvements made to the OCUDU O-CU/O-DU under this effort (scheduler behavior, mobility management, uplink capacity, stability under sustained load, security features) are expected to generalize across verticals and to benefit the broader community of RAN developers building on OCUDU. The Technical Volume shall include a mapping of each selected use case, and its associated KPMs, to the performance class or classes it exercises, and shall identify which anticipated OCUDU code or feature enhancements correspond to each class. For this topic, the dominant performance classes are ultra-reliable low-latency communication (URLLC) and high-mobility reliability: sustained sub-30 ms (threshold) to sub-15 ms (objective) latency for machine-vision backhaul, ≥99.5% handover success at operational AGV/AMR speeds, and ≥ five-nines availability for safety-critical services, all in dense, metal-heavy RF environments. Research and development for this effort should address, at minimum, the following questions:All-Open-Source Economics: What is the fully loaded cost (integration, support, spectrum, hardware) of an OCUDU + SD-Core + SD-RAN + OSC deployment relative to a proprietary platform at SMM scale, and how should that be packaged as a CBRS-based, as-a-service offer within the price point SMM buyers require ($100,000-$250,000)?Use-Case-First Automation: Which of the use cases defined below deliver the fastest, most measurable ROI on the open-source stack, and what RTEC-executed interoperability tests (Device, RU, Core, RIC/SMO, and Infrastructure dimensions) are needed to validate each one end-to-end?Trust in Open Source: How does RTEC-executed testing of the full open-source stack (not just OCUDU) reduce the integration risk and skills-shortage barrier that SMM buyers most often cite, and what evidence package best converts community-maintained, no-license-fee software into a procurement-ready proof point for a buyer with no in-house cellular expertise? Solutions leveraging artificial intelligence (AI) and machine learning (ML) for predictive maintenance, network optimization, or automated fault resolution are encouraged but not required. DoW will consider any novel concept that increases the reliability, economics, and trustworthiness of an all-open-source private 5G/FutureG platform for the manufacturing vertical. Dual-use opportunities are expected across both commercial SMM and DoW facility networks.

This topic is accepting Direct to Phase II proposals ONLY. Therefore, a formal Phase I award will not be issued. To qualify for a Phase II award, proposers must submit Feasibility Documentation (as part of their proposal package) demonstrating that they have already completed "Phase I-type" research and development. The purpose of this documentation is to prove that the underlying technology is mature, scientifically sound, and ready to transition immediately into the Phase II prototyping and testing environment. The Government will accept a wide variety of documentation styles. Proposers do not need to have a perfect, finished product, but they must show that their core ideas have been successfully tested. One or more of the following items should be included to prove technology readiness:Test Data & Metrics: Real-world measurements, performance charts, or network test data from previous lab environments or early field trials.Technical Reports & White Papers: Written summaries explaining your previous research, system designs, or software integration efforts.Prototype Designs & Simulation Models: Diagrams, architectural blueprints, or computer simulation results showing how your proposed software and hardware components interact.Previous Project Outcomes: Success criteria, milestone reports, or commercialization results from prior private, academic, or non-SBIR federally funded work.

This Phase II effort will design, validate, and demonstrate a fully open-source private 5G network platform purpose-built for manufacturing facilities, integrating OCUDU (O-CU/O-DU), SD-Core, SD-RAN, and the OSC stack with no proprietary core, RIC, or SMO components. The platform addresses four manufacturing-specific needs: high-mobility connectivity for automated guided vehicles (AGVs) and mobile plant equipment; low-latency video/camera backhaul for quality inspection and process monitoring; worker and plant safety communications; and outdoor yard and logistics coverage extending beyond the factory floor. Phase II work will produce a validated reference architecture, RTEC-executed interoperability testing across RU, Core, RIC/SMO, and infrastructure dimensions, and a working MVP demonstrated at a representative manufacturing site, along with a documented technical bridge path toward FutureG capability. Anticipated benefits include a lower-cost, vendor-neutral alternative to proprietary industrial wireless systems, improved reliability for mobile robotics and safety-critical communications in dense industrial RF environments, and a reusable open-source deployment model. Commercial applications span discrete and process manufacturing facilities of varying scale, with dual-use potential for DoW-affiliated depots, maintenance facilities, and logistics operations requiring resilient, high-mobility industrial wireless connectivity. Proposers must address at least two of the following four use cases in their Phase II Statement of Work, and must identify which use case(s) their reference architecture and pilot deployment are designed to validate. Each use case below is defined in terms of the operational scenario it supports, the connectivity requirement it places on the platform, and the corresponding KPM table. Device-Class Diversity and 5G RedCap. Each use-case set spans device classes from full-capability UEs (equipment modems, cameras, broadcast and production units) to reduced-capability IoT endpoints (sensors, wearables, tags, and trackers). Proposers shall address how the platform serves reduced-capability device classes, including 3GPP Release 17 Reduced Capability (RedCap) and Release 18 eRedCap UEs, and shall identify any OCUDU scheduler or feature enhancements required to support RedCap operation; such enhancements are strongly encouraged as upstream contributions under the common OCUDU benchmarking and enhancement work package. Where RedCap-certified devices are not commercially available for a given endpoint type at demonstration time, proposers may demonstrate with available device classes (or emulated RedCap UE profiles) and shall document the RedCap migration path.For the manufacturing vertical specifically, proposers shall additionally address Industrial IoT (IIoT) service characteristics as framed by 3GPP TS 22.104 (service requirements for cyber-physical control applications), including: the mapping of selected use cases to TS 22.104 communication service classes; support for private-network (NPN) operation; awareness of Time-Sensitive Communication (TSC) and IEEE TSN integration concepts in the platform architecture (see also the latency-class scope note in Section 3.0); and secure IT/OT segmentation for IIoT traffic (e.g., via network slicing or 5G-LAN group management). Use Case 1: AGV/AMR Connectivity & MobilityAutomated guided vehicles (AGVs) and autonomous mobile robots (AMRs) move continuously across the plant floor, between production cells, and into staging or storage areas, requiring an uninterrupted control-plane and telemetry connection as they roam. Roaming interruptions have historically been a common source of dropped sessions and stalled vehicles in Wi-Fi-served plants. Modern Wi-Fi roaming standards (IEEE 802.11k neighbor reports, 802.11r fast BSS transition, and 802.11v BSS transition management) substantially mitigate fixed-AP handoff behavior when properly deployed on capable client devices; the more fundamental challenges in this environment are contention-based access on unlicensed, shared spectrum and the severe attenuation, multipath, and reflection conditions of metal-heavy plants, which degrade any RF system absent careful network planning. The advantage sought under this topic is therefore not that Wi-Fi cannot roam, but that a 3GPP system provides deterministic, network-scheduled access on interference-managed spectrum, standardized mobility management under network control, and quality-of-service guarantees that remain enforceable under load. This use case requires the platform to sustain low-latency, high-reliability connectivity and seamless handover as AGVs/AMRs move between small cells, indoors and, where applicable, into adjoining outdoor areas. This use case additionally requires on-floor localization of AGVs/AMRs and tagged mobile assets for fleet management, geofencing, and safety zoning. Network-native positioning using 3GPP NR positioning methods (Release 16/17) is preferred; hybrid approaches that fuse NR positioning with existing plant localization systems may be proposed with justification. Use Case 2: Machine Vision BackhaulQuality-inspection and process-monitoring cameras generate continuous, high-bandwidth video or image streams that must reach an on-prem or edge analytics system with minimal delay and jitter to support real-time defect detection and line-stoppage decisions. This use case requires the platform to sustain high uplink throughput with low jitter for multiple simultaneous camera streams, including in metal-heavy or RF-reflective areas of the plant where Wi-Fi performance typically degrades. Use Case 3: Connected-Worker SafetyPlant personnel increasingly carry or wear connected devices (such as gas/hazard sensors, push-to-talk radios, panic buttons, or health/location monitors) that must reliably reach a monitoring system without gaps in coverage, including in areas (mezzanines, tank farms, loading docks) that legacy Wi-Fi does not reliably reach. This use case requires the platform to sustain consistent, low-latency coverage for safety-critical alerting across the full indoor plant footprint. Use Case 4: Secure Outdoor Yard & Logistics CoverageLoading docks, staging yards, rail sidings, and outdoor storage areas typically fall outside indoor Wi-Fi coverage entirely, yet increasingly require connectivity for yard trucks, RFID/asset tracking, outdoor cameras, and inventory handling equipment. This use case requires the platform to extend secure, private coverage into outdoor areas immediately adjacent to the plant, using the same OCUDU-based infrastructure rather than a separate outdoor Wi-Fi buildout. KPMs For Phase IIFor Phase II, proposers should address specific, relevant, measurable, and quantifiable KPMs, including, for example, session success rate, handover success rate, latency, jitter, and service availability. An example KPM in context could be as follows: "The platform must sustain a session success rate greater than 99.5% for AGV/AMR connections while handing over between at least 3 small cells at speeds up to 10 mph." Other suggested KPMs for the various use cases and system requirements are given below for reference. The KPM values in the tables below are suggested reference values, not pass/fail contract requirements. Proposers shall propose specific, justified KPM targets in the Technical Volume, calibrated to their selected use cases, demonstration environment, spectrum plan, and channel bandwidth; deviations from the suggested values must be technically justified. Threshold values represent the intended standard of Phase II demonstration success; Objective values are stretch goals, some of which are expected to mature during Phase III or along the FutureG evolution path. Final KPM targets will be agreed with the Government at kickoff and confirmed at the Critical Design Review. Consistent with key milestones outlined below, partial achievement within a defined and documented scope may be considered successful. Latency measurement definition. Latency KPMs in this document denote round-trip application-layer latency measured between the UE application interface and the local edge application endpoint served behind the on-site/edge UPF (i.e., device-to-edge through the RAN and core user plane, excluding external WAN transport). Handover time denotes user-plane interruption time at the RAN, per 3GPP definitions. For each latency KPM adopted, proposers shall specify the measurement reference points, the traffic type and packet size, and the measurement methodology (e.g., KPI definitions per 3GPP TS 28.554), and shall include in the Critical Design Document a latency budget decomposition across air interface, DU/CU processing, fronthaul and F1 transport, core user plane, and application processing.Scope note on latency classes. Hard-real-time machine motion control (isochronous traffic with cycle times of approximately 0.5–2 ms per 3GPP TS 22.104) is outside the Phase II demonstration scope. The latency KPMs in this topic target AGV/AMR supervision and control-plane traffic, machine-vision backhaul, and safety alerting. Proposers shall, however, address in their FutureG evolution path the OCUDU enhancements required to approach the 1 ms latency class over time (including deterministic/priority scheduling, Time-Sensitive Communication support, mini-slot and preemption features etc.). Suggested KPMs for Use Case 1: AGV/AMR Connectivity & MobilityThese metrics focus on the platform's ability to maintain reliable, low-latency connectivity for mobile robotics moving throughout a plant.KPM CategoryKey Performance Metric (KPM)Suggested Threshold (Minimum Success)Suggested Objective (Desired Success)TimelinessHandover Time: Time to complete a handover between small cells during AGV/AMR movement.< 50 ms< 20 msReliabilityHandover Success Rate: Percentage of handovers completed without session drop.> 99%> 99.9%LatencyEnd-to-End Latency: Round-trip latency for AGV/AMR control-plane traffic.< 20 ms< 10 msReliabilitySession Success Rate: Percentage of data sessions completed without error or drop.> 99%> 99.9%CoverageMobility Range: Sustained connectivity across the full indoor/outdoor yard footprint at operational AGV/AMR speeds.Full indoor footprintFull indoor + outdoor yard footprintPositioningDevice Localization Accuracy: horizontal positioning error for AGV/AMR and asset-tag devices using NR positioning methods, at 90% confidence, indoors< 3 m< 1 m Suggested KPMs for Use Case 2: Machine Vision BackhaulThese metrics measure the platform's ability to support high-bandwidth, low-jitter traffic for quality-inspection and process-monitoring cameras.KPM CategoryKey Performance Metric (KPM)Suggested Threshold (Minimum Success)Suggested Objective (Desired Success)ThroughputSustained Uplink Throughput: Per-camera uplink throughput supported for machine-vision backhaul.> 50 Mbps> 150 MbpsTimelinessLatency & Jitter: Round-trip latency and jitter for real-time inspection traffic.< 30 ms latency, < 10 ms jitter< 15 ms latency, < 5 ms jitterReliabilityPacket Loss/Error Rate: Percentage of packets lost or corrupted in transit.< 0.5%< 0.1%ScalabilityConcurrent Camera Streams: Number of simultaneous camera streams supported per cell without degradation.10 streams30 streams Suggested KPMs for Use Case 3: Connected-Worker SafetyThese metrics measure the platform's ability to deliver reliable, low-latency coverage for safety-critical wearables and alerting devices across the full plant footprint.KPM CategoryKey Performance Metric (KPM)Suggested Threshold (Minimum Success)Suggested Objective (Desired Success)TimelinessAlert Latency: Time from a safety-event trigger (e.g., gas sensor, panic button) to alert receipt at the monitoring system.< 2 seconds< 500 msAvailabilityService Availability: Percentage of time the network is operational and able to provide service in safety-monitored zones.> 99.9%> 99.999%CoverageCoverage Completeness: Percentage of designated safety zones (mezzanines, tank farms, loading docks) with verified signal coverage.> 95%100%ReliabilityFalse Negative Rate: Percentage of safety-alert transmissions that fail to reach the monitoring system.< 0.1%< 0.01% Suggested KPMs for Use Case 4: Secure Outdoor Yard & Logistics CoverageThese metrics measure the platform's ability to extend secure, private coverage into outdoor yard and logistics areas adjacent to the plant.KPM CategoryKey Performance Metric (KPM)Suggested Threshold (Minimum Success)Suggested Objective (Desired Success)CoverageOutdoor Coverage Radius: Distance from the nearest small cell at which the platform maintains a usable connection for yard trucks and asset tracking.> 200 meters> 500 metersReliabilitySession Success Rate (Outdoor): Percentage of data sessions completed without error or drop in outdoor yard conditions.> 98%> 99.5%SecurityUnauthorized Access Attempts Blocked: Percentage of unauthorized association/connection attempts detected and blocked at the outdoor perimeter.> 99%100%MobilityYard-Truck Handover Success Rate: Percentage of handovers completed without session drop as yard trucks move between outdoor and indoor coverage.> 98%> 99.5% Suggested KPMs for General System & Architectural RequirementsThese metrics focus on the non-functional requirements of the all-open-source stack itself, ensuring it is efficient, scalable, interoperable, and compliant with the O-RAN architecture.KPM CategoryKey Performance Metric (KPM)Suggested Threshold (Minimum Success)Suggested Objective (Desired Success)InteroperabilityRTEC-Validated Reference Configurations: Number of distinct RU/hardware-accelerator/RIC-SMO combinations validated through RTEC testing and available as reusable reference configurations.≥ 2 combinations≥ 5 combinationsComplianceO-RAN Interface Compliance: Adherence to specified O-RAN Alliance interface standards (E1, F1-C/F1-U, O-RAN 7.2x, O1, E2).100% pass of a defined conformance test suite100% pass of a defined conformance test suiteEconomicsFully Loaded Deployment Cost: Total cost (hardware, integration, support) for a single-plant deployment.≤ $250,000≤ $100,000ScalabilityManaged Device Capacity: Number of concurrent AGV/AMR, camera, and connected-worker devices a single deployment can support.100 devices500 devicesLicensingProprietary Component Count: Number of proprietary core, RIC, or SMO components in the deployed stack.00Device-Class SupportRedCap UE Support: demonstrated attach, session establishment, and mobility for Rel-17 RedCap UEs (or emulated RedCap profiles where commercial devices are unavailable).Lab-validated   Field-demonstrated at the pilot/demonstration site Phase II – Eighteen MonthsPhase II consists of an eighteen-month PoP focused on prototype production, test, and evaluation. Key milestones include:Month 1: Kickoff and TIMMonthly Status Reports (MSRs)Month 12: Critical Design Review (CDR)Month 16: Prototype demonstrationMonth 14: Final design review, demonstration, and assessmentMonth 18: Final Phase II ReportNote that Monthly Status Reports must be presented to the OCUDU T&E Working Group also, bringing the community up to speed on the progress. Prototype demonstrations will be performed at the proposer's site, ideally an operating or representative manufacturing facility (such as a partner SMM plant, a manufacturing institute or applied-research factory floor, or a comparable industrial or laboratory environment) where live plant access is not feasible during Phase II. The demonstration environment must be representative of the target deployment class in RF character (metal-heavy, multipath-rich industrial construction) and in scale (a footprint and cell count at minimum three cells, sufficient to exercise inter-cell handover at operational AGV/AMR speeds), and its fidelity to plant conditions must be documented in the MVP demonstration package. Partial solutions may be considered successful if effective within a defined scope. A final technical report detailing the capabilities demonstrated will be required. Extended user evaluations or additional prototypes may be pursued based on utility. OCUDU and Open-Source IntegrationThe Open Centralized Unit Distributed Unit (OCUDU) software codebase is released and continuously enhanced with a 3GPP-compliant open-source Centralized Unit (CU) and Distributed Unit (DU) implementation supporting open interfaces. Proposers should integrate OCUDU together with SD-Core (5G Core), SD-RAN (Near-RT RIC), and OSC stack (Non-RT RIC and SMO) into a single, fully open-source reference architecture, with no proprietary core, RIC, or SMO component anywhere in the stack. The MVP demonstration, including physical RUs and Ues, will need to occur at the factory-representative site described above (as close to a real environment). Performers should address scalability, including testing across multiple RU vendors and hardware-accelerator options, and should leverage RTEC-executed interoperability testing to address integration risks ahead of the demonstration wherever a validated reference configuration already exists. OCUDU Baseline Benchmarking and Upstream Enhancement:All performers under this topic shall execute the following common work package, which is a required element of the Phase II Statement of Work regardless of the use cases selected. Task A: Baseline Benchmark. Establish a quantified performance baseline of the integrated open-source stack (OCUDU + SD-Core + SD-RAN + OSC) against the Phase II KPMs relevant to the selected use cases, including the General System and Architectural Requirements. An emulated end-to-end configuration (emulated RUs and UEs, RF channel emulation, and/or synthetic load generation) is acceptable and encouraged for the baseline, provided the benchmark methodology, tooling, configurations, and results are fully documented and reproducible. Where an RTEC-validated reference configuration already exists for the proposed RU/Core/RIC/SMO combination, the baseline shall incorporate available RTEC results rather than duplicate them. Baseline methodology and results shall be presented to the OCUDU T&E Working Group. Task B: Code and Feature Enhancement. Identify the gaps between baseline performance and threshold and objective values, and develop the OCUDU code improvements and features required to close them (e.g., scheduler and QoS enhancements, mobility/handover optimization, uplink capacity improvements, stability hardening, security features). All modifications to OCUDU shall be contributed upstream through the project's standard contribution and review process; enhancements that cannot be upstreamed shall be documented with rationale. Progress against each targeted KPM, and the status of each upstream contribution, shall be reported in the Monthly Status Reports presented to the OCUDU T&E Working Group. Task C: Benchmark and Regression Harness. Deliver the emulation-based end-to-end benchmark suite developed under Task A as a repeatable, documented, open-source harness suitable for adoption by the OCUDU community and RTECs for regression testing of future OCUDU releases.This work package complements, and does not replace, the interoperability testing and the physical MVP demonstration required elsewhere in this topic. Emulated results establish the baseline and guide enhancement work; over-the-air performance with physical RUs and UEs at the RTEC and/or representative demonstration site remains the standard of evidence for final KPM achievement.RF Network Planning and Site Engineering Industrial facilities are among the most difficult RF environments for any wireless system: dense metal structures, racking, and machinery produce severe attenuation, multipath, and reflection conditions that directly affect handover performance, throughput, jitter, and coverage completeness. Performers shall execute a representative facility-specific RF engineering task comprising: (1) predictive propagation modeling incorporating facility-specific features (metal racking, machinery, mezzanines, tank farms, loading areas); (2) an RF design that mitigates identified dead spots and multipath-driven impairments through cell placement, antenna selection and orientation, and mobility-parameter tuning; and (3) address installation engineering practices that protect radio hardware, including antenna placement clearances from nearby reflective metal and verification of antenna-system return loss/VSWR at commissioning, with monitoring thereafter, to prevent reflected-power damage to RU front-ends. Security RequirementsSecurity shall be a first-class design requirement of the platform, not a demonstration afterthought. Performers shall implement and document a security architecture covering: 3GPP security per TS 33.501 (mutual authentication, air-interface encryption and integrity protection); protection of the O-RAN open interfaces (open fronthaul, E2, A1, O1) per O-RAN WG11 specifications; zero-trust principles per NIST SP 800-207, including least-privilege access and separation of management and user traffic; monitoring of Common Vulnerabilities and Exposures (CVEs) affecting OCUDU and its dependencies, and timely upstream patching. Security features and hardening developed for OCUDU shall be contributed upstream under the common benchmarking and enhancement work package. The security architecture shall be documented at CDR and validated in RTEC testing, and the MVP demonstration shall include at least one security capability shown live (e.g., rejection of an unauthorized device, encrypted fronthaul, or detection of a simulated intrusion). Phase II DeliverablesKickoff and TIM slidesMonthly Status Reports (MSRs)Critical Design Document (full reference architecture: OCUDU + SD-Core + SD-RAN + OSC)Key Performance Metrics (see Section 3)MVP Demonstration Slides and Documentation, including a description of the demonstration site's fidelity to factory conditions and the KPI results achieved against Section 3.0 thresholdsReference Configuration Package: executables, integration documentation, and RTEC test results for the validated RU/Core/RIC/SMO combination(s) usedIntegration of the platform into an RTEC-affiliated test/evaluation network and/or a factory-representative demonstration site, demonstrating at least one of the two selected use cases.OCUDU Baseline Benchmark Report: methodology, emulation environment description, configurations, and measured baseline results against Section 3.0 KPMs (expected by Month 3)Upstream Contribution Log: itemized record of OCUDU code contributions (patches/pull requests), their review status, and the KPM gap each addresses (updated in each MSR; final version in the Final Technical Report)Open-source benchmark and regression harness, with documentation sufficient for independent execution by RTECs and the OCUDU communityRF Design Report (including representative coverage maps and return-loss/VSWR commissioning approaches).Final Design DocumentFinal Technical Report

The development of an open-source private 5G network platform for smart manufacturing offers significant dual-use potential, benefiting both commercial industry and DoW operations. For the commercial sector, this technology provides small and medium-sized manufacturers (SMMs) with a low-cost, secure, and vendor-neutral wireless solution. It directly addresses key manufacturing needs such as enhancing automated guided vehicle (AGV) mobility, enabling real-time machine vision for quality control, improving connected-worker safety, and extending secure connectivity to outdoor logistics yards.For the DoW, this same technology can be applied to its own industrial and logistical environments. It offers a pathway to modernize DoW-affiliated depots, maintenance facilities, and logistics operations with resilient, high-mobility wireless connectivity. This is particularly relevant for contested logistics, where reliable, secure, and private communication networks are critical for maintaining operational tempo and supply chain integrity. The platform's open-source nature reduces dependency on proprietary systems and enhances security, aligning with key DoW modernization goals.

Develop an agentic AI (artificial intelligence) based cognitive radar system for automatic selection of radar parameters, waveforms, and exploitation for resilient GEOINT applications.

Agentic AI enables autonomous control of expert systems for desired information gathering or completing a task. Compared to the general AI systems, an agentic AI system can make its decision by sensing the environment autonomously without relying on human input. Hence, agentic AI is desired for many expert systems such as self-driving car (Tesla) and many other systems. In this research, we are seeking development of an agentic AI based cognitive radar system for next generation, resilient radar system. Once initiated, agentic AI enabled radar will sense the environment for operating conditions such as interference, clutter, and signal to noise ratio. Based on this information, the system will learn (i.e., cognition process) to transmit optimum waveforms with desired frequency, bandwidth, pulse repletion frequency (PRF) and other critical parameters. This will enable future GEOINT capabilities to be resilient in the presence of asymmetric operating environments that adversaries may impose to significantly reducing our GEOINT mission.

This topic is accepting Direct to Phase II proposals ONLY. To qualify for a Phase II award, proposers must submit Feasibility documentation showing a developed concept for agentic AI based cognitive radar systems. Provide details on the components of the systems and subsystems.The performer must demonstrate capability of the agentic AI based radar system with the detection of interference signals and mitigating these by transmigtting a different signal. This should improve the Signal-to-interference and noise-ration(SINR) <70% to 95% . Also after mitigation image quallaity/resolution should improve from <70% detection and classificvation to 95% detection and classification.

Prototype the agentic AI based cognitive radar system in a modeling and simulation environment. Develop software systems to select various parameters of the radar systems and operating environment. Analyze performance of the system in a testing environment.

Develop and build the hardware for the agentic AI based cognitive radar system for technology transition.

Develop VLM based SAR imagery search and classification from sensor independent complex data (SICD)

Vision language models (VLMs) combine multimodal (Video, SAR and Infrared Imagery) data/imagery and generative AI models to understand and process video, image, and text. VLM integrates large language models (LLM) with a vision encoder that allows LLM to explain contents of an imagery. The goal of this research is to analyze (detect and classify) synthetic aperture radar (SAR) imagery from sensor independent complex data (SICD) data.

This topic is accepting Direct to Phase II proposals ONLY. To qualify for a Phase II award, proposers must submit Feasibility Documentation demonstrating: successful classification (>95% accuracy) of single SAR image chips in SICD format; that the performer is very well qualified (e.g., PhD, research level) and has demonstrated experience classifying complex SAR imagery. Qualification requires a scientist’s extensive knowledge of SAR signal and image processing, SAR operations from space, and deep learning (machine learning) understanding and implementation. The purpose of this documentation is to prove that the underlying technology is mature and ready to transition immediately into Phase II requirements.

Develop a VLM based SAR SICD Imagery classification system, where input contains SAR imagery with multiple targets and output should be location and classification of the targets. Use SAR SICD data provided by government or your own/commercial data.

Transition the VLM based SAR SICD classification tool for government utilities.

The objective of this topic is to spur research into industrially scalable production methods for an IR-transparent composite ceramic exhibiting sub-100 nm microstructural features in all phases on samples larger than 2" x 4" x 0.5", porosity below 0.1%, microstructural and optical stability to 1200 degrees C, and a thermal expansion to thermal conductivity ratio (alpha/k) at or below 1.0 micrometers/W at 1000 degrees C.

The Navy has demonstrated within its laboratories that a composite ceramic exhibiting IR transparency can be produced with distinct phases, microstructural feature sizes below 100 nm in all phases, and porosity content below 0.1% on component parts as large as 0.4 inch in lateral dimension. Phase identity, crystal structure, phase chemistry, microstructure feature size, and porosity content were established via X-ray diffraction (XRD) and scanning electron microscopy (SEM) cross-sections with energy dispersive spectroscopy (EDS) analysis. Retention of sub-100 nm feature sizes across all phases is critical to achieving the desired mechanical and thermal properties of the composite; porosity above 0.1% similarly degrades mechanical performance. All three specifications -- sub-100 nm microstructural features in all phases, porosity below 0.1%, and Short-Wave to Mid-Wave Infrared (SWIR/MWIR) transparency of at least 80% -- must be achieved at scale for the material to be suitable for transition.Producing IR-transparent composite ceramics meeting these specifications at sample sizes relevant to aperture applications is a significant technical challenge. Conventional ceramic processing routes that rely on mechanical mixing or co-precipitation of constituent phases typically result in microstructural coarsening during densification that precludes achieving sub-100 nm feature sizes in all phases. Innovative powder synthesis and consolidation approaches capable of satisfying all microstructural, porosity, and optical transparency requirements at sample sizes exceeding 2" x 4" x 0.5" are sought. Furthermore, the proposed processes should be industrially scalable in both capacity and final component size, with a path towards producing components in the 3" x 9" range or larger. In addition to these requirements, the composite ceramic must retain its microstructure and IR transparency after exposure to temperatures up to 1200 degrees C for 10 minutes. Phase transformation or grain growth during high-temperature service would degrade both mechanical and optical performance. The composite must also exhibit a low ratio of thermal expansion coefficient (alpha) to thermal conductivity (k). The threshold requirement for alpha/k is 1.0 micrometers/W and the target is 0.5 micrometers/W at 1000C.

Phase I efforts should focus on research to establish the feasibility of a proposed material system and processing approach. Proposals should outline a plan to investigate and demonstrate the potential to produce the target IR-transparent composite ceramic with sub-100 nm microstructural features in all phases and porosity below 0.1%. The research should address initial process tuning, explore pathways to scalability (demonstrating the approach can plausibly be extended to industrially relevant sample sizes), and provide a scientific basis for meeting the optical and thermal property goals. The applicant should also investigate the anticipated thermal stability of the proposed composition to 1200 degrees C and provide an estimate or measurement of the alpha/k ratio. For Direct to Phase II (D2P2) proposals, the applicant is required to provide details and documentation demonstrating accomplishments of a "Phase I-type" effort.

The Phase II effort should mature the proposed technology through focused research and development aimed at scaling the process and optimizing the material. Key research objectives for this phase include, but are not limited to:Developing and refining a novel composition and process route with the goal of achieving sub-100 nm microstructural features in all phases, porosity below 0.1%, and SWIR/MWIR transparency of at least 80% on samples exceeding 2" x 4" x 0.5".Investigating and verifying the retention of nanoscale microstructural features (critical to the target mechanical and thermal properties) via SEM/EDS cross-section analysis.Researching and demonstrating the industrial scalability of the process, including establishing a clear path towards producing components in the 3" x 9" range or larger.Validating microstructural and optical stability (including maintained SWIR/MWIR transparency and retained sub-100 nm features without deleterious phase transformation) after exposure to 1200 degrees C.Measuring key thermomechanical properties, specifically targeting an alpha/k ratio at or below the 1.0 micrometers/W threshold (with a target of 0.5 micrometers/W) at 1000 degrees C.Performing and reporting initial mechanical property characterization, including hardness, flexural strength, and fracture toughness testing at ambient temperature.Providing representative samples to the Navy for independent characterization, alongside a final cost estimate for continued scale-up and per-unit material cost.

The contractor will pursue commercialization of the materials and processes developed during Phase II with ITAR/CUI-eligible organizations. IR-transparent composite ceramics with refined nanostructure have broad potential for dual-use applications including electro-optical/infrared (EO/IR) sensor windows and domes for airborne and maritime platforms, hypersonic vehicle apertures, and commercial thermal imaging systems. The technologies may be transitioned by expanding mission capabilities across a broad range of government users including directed energy, EO/IR sensing, and hypersonic systems programs. Direct procurement of IR-transparent composite ceramic components in coordination with the government program manager may be part of a Phase III program.

Is 4.0 microns adequate range in the MWIR to be of interest for this topic?

Develop an innovative, non-destructive diamond semiconductor defect metrology technique and laboratory-scale apparatus to identify, quantify, determine location in the device, and energetically characterize charge traps that cause current collapse in surface-channel diamond transistors.

Hydrogen-terminated (surface-channel) diamond transistors hold great promise for next-generation, high-frequency, high-power RF electronics and advanced communications due to diamond's high breakdown field and superior thermal conductivity. However, wide-scale operational deployment is constrained by "current collapse" and "knee walkout" - phenomena where transient charges trapped at defect sites in the semiconductor prevent the transistor from operating at its full, high-frequency RF power. Commercial device-characterization tools, built primarily for silicon or traditional compound semiconductor materials, lack the specialized physics and sensitivity required to isolate and characterize traps in ultra-wide bandgap (UWBG) diamond devices. These performance-limiting charge traps can reside in multiple distinct, critical locations within the device stack, including the gate dielectric, the dielectric-to-diamond interface, the diamond epitaxial layer, the epitaxial-to-substrate interface, and the diamond bulk substrate. Understanding and mitigating these mechanisms requires a specialized metrology capability. This topic seeks the development of a comprehensive measurement system and associated methodology capable of extracting trap density, energy levels, physical location (specifically identifying the layers or interfaces where the traps reside), and time constants characterizing these defects so that design teams can efficiently work to address them.Standard capacitance-voltage (CV) or simple transient electrical analyses do not provide sufficient physical insight into trap dynamics. Specifically, a successful technique and system must be capable of resolving multiple trap populations and correlating these distinct signatures with observed current collapse behavior in diamond. Because hydrogen-terminated diamond relies on unique surface-channel p-type conduction, validation of these new techniques can not necessary rely on prior validation from conventional n-type semiconductor materials (e.g., GaN, Ga2O3, AlN), as the fundamentally different physical mechanisms and device architectures may not be acceptable surrogates for the diamond device behavior.To meet operational requirements, all primary experimental validations and core metrology capability demonstrations under this effort must be performed specifically on Government-provided hydrogen-terminated diamond material and RF transistor devices. The Government will provide these verified working devices and/or test articles as Government Furnished Property (GFP) during the execution phase to anchor the research. The public literature contains examples of hydrogen-terminated diamond RF transistors that exhibit comparable baseline characteristics [1, 2]. While the GFP will vary in specific design, architecture, and properties from the literature, they can provide a baseline for concept development. It is expected that preliminary or intermediate metrology demonstrations on other wide or ultra-wide bandgap semiconductor devices may be used for initial development, the main and final capability demonstrations must be validated directly on the specific diamond device architectures provided. This effort will address a critical metrology gap, establishing a validated metrology standard that accelerates the development of high-reliability diamond RF electronics.

Conduct a 6-month study to establish the scientific and technical feasibility of the proposed defect metrology technique. The performer shall describe the measurement process, provide sound scientific arguments justifying the approach’s ability to meet the project objectives of trap identification and measurement, and describe the hardware equipment requirement needed to perform the measurement. Expected means to demonstrate feasibility include preliminary experimental demonstrations, a review of relevant existing techniques used on other types of semiconductors, and supporting modeling or simulations. In alignment with the overall topic objective, while initial benchtop calibration may utilize other wide bandgap materials, the core Phase I feasibility demonstration must be applied specifically to hydrogen-terminated diamond architectures. To facilitate this early validation, the Government will provide representative diamond test structures as Government Furnished Property (GFP). Phase I Deliverables:i. A comprehensive feasibility study report detailing the proposed metrology process, scientific justification, and measurement equipment used for the approach.ii. Initial feasibility data (derived from preliminary experimental demonstrations, literature review of relevant semiconductor techniques, or modeling) supporting the viability of the technique for surface-channel p-type architectures.iii. A detailed Phase II transition plan outlining the schedule, testing procedures, and integration strategy for validating the prototype instrument on the provided diamond devices.

Develop, construct, and validate a fully functional prototype, laboratory-scale, trap metrology instrument based on the Phase I design. The performer is expected to demonstrate the system’s ability to successfully isolate and distinguish between different trap locations (e.g., gate-dielectric interface vs. bulk epitaxial layer) and correlate these signatures with measured RF current collapse on hydrogen-terminated diamond transistors, which will continue to be provided as GFP by the Government. The performer is expected to continue refining the technique developed in Phase 1 incorporating those refinements into the prototype. The principal milestone of the Phase II effort is the validation of the developed hardware and measurement methodology at the performer's facility. For this effort, "validation" is explicitly defined as the successful identification, characterization, and physical location attribution of the specific charge traps responsible for current collapse and similar detrimental effects in the provided diamond transistors. Following this successful demonstration, the complete, operational prototype measurement system, including all associated hardware, specialized instrumentation, and software, will be provided as a deliverable to the Government. Phase II Deliverables:i. Prototype System Validation & Hardware Transfer: Successful demonstration of the developed technique and hardware’s ability to identify, locate, and quantitatively characterize (specifically provide numerical values for trap density, energy levels, time constants, etc.) the specific traps responsible for current collapse and other detrimental effects in the GFP diamond devices, as well as delivery of the fully operational prototype defect metrology test instrumentation to the Government.ii. Documentation & Training: A comprehensive Standard Operating Procedure (SOP) manual containing step-by-step measurement instructions tailored specifically to the provided diamond RF devices, accompanied by hands-on training for Government personnel.iii. Final Report: A technical report detailing the identified trap signatures on the GFP devices, the methodology used to correlate these measurements to observed RF performance loss, detailed procedures by which the prototype tool can be used to reproduce the validation results on GFP devices, details of any identified limitations of the technique or system related to the desired function, including any identified material or processing mitigation options related to those limitations.

Military Application: The delivered measurement technique will be used to analyze, optimize, and validate the reliability of high-power diamond transistors. US Army DEVCOM is presently developing diamond transistor devices for the next generation of advanced military sensing, high-frequency communications, and broad-spectrum electromagnetic platforms. Successful outcomes of this research and development program will result in laboratory techniques and supporting equipment necessary to continue development of this technology. It is expected that the technology will become a standard metrology technique within DEVCOM electronic device laboratories and among the Defense Industrial Base partners with semiconductor foundries presently being engaged in this development.Commercial Application: The performing small business can commercialize the diagnostic system design, measurement software, and procedural methodology to support the emerging domestic commercial diamond semiconductor industry. This highly specialized metrology capability will be valuable to domestic and allied commercial foundries manufacturing advanced diamond electronics to improve device reliability and manufacturing yield for commercial 5G/6G telecommunications, commercial satellite communications (SatCom), commercial radar systems, and high-frequency communication systems requiring advanced thermal management. Because this metrology system is designed to evaluate high-power, semiconductor technologies, some of which fall under ITAR or CCL export-controls, all commercialization, licensing, and replication services will need to comply with U.S. export control laws (ITAR/EAR). While this may limit certain commercial markets, it also has the potential to establish higher exclusivity within controlled markets.

For the Government-furnished hydrogen-terminated diamond test structures, can you identify the surface acceptor and gate/passivation dielectric stack that will be used (for example, ALD Al2O3 alone, or a transition metal oxide such as V2O5 or MoO3 with an Al2O3 or other encapsulation layer), including approximate layer thicknesses? If more than one stack will be provided, please indicate which variants to plan for.

The baseline Government Furnished Property (GFP) test structures and devices will utilize an Atomic Layer Deposition (ALD) aluminum oxide (Al2O3) layer acting as both the gate dielectric and the surface acceptor layer, deposited directly on the hydrogen-terminated diamond. For proposal and modeling purposes, proposers should consider a baseline thickness of 30 nanometers. However, because the Government actively optimizes these device architectures, the proposed metrology technique should not be strictly limited to this single baseline. The methodology should be adaptable to analyze thicker and thinner single-layer dielectrics (12 – 100nm), as well as multi-layer dielectric stacks (e.g., an additional ALD-deposited dielectric layer atop the baseline Al2O3). Specific details regarding alternate thicknesses and multi-layer stacks will be provided to the selected performer during the execution phase, following initial validation on the baseline structures.

The objective of this effort is to develop an advanced digital signature management and deception system that obfuscates cellular metadata ("digital exhaust") to protect personnel, small units, and critical facilities from adversarial surveillance, tracking, and pattern-of-life analysis on 3rd-party commercial networks.

As military and government personnel increasingly rely on commercial mobile networks, the management of digital signatures has become a critical operational concern. Accessing foreign mobile phone networks exposes individuals and organizations to surveillance and espionage threats due to their "digital exhaust", the metadata required to operate on a cellular network (e.g., credentials, location data, device IDs). Adversaries can leverage this data to track daily routines, identify deviations indicating special events (e.g., VIP visits or mission preparation), and map sensitive facilities based on cell phone concentration or periods of inactivity.

During Phase I, proposers are required to present a comprehensive concept design and feasibility study for a digital exhaust deception system. Solutions should outline the proprietary software required to conduct AI-enabled mission planning and operations. Proposers must define specific, relevant, measurable, and quantifiable key performance metrics (KPMs) for their proposed solutions. Suggested KPMs for the system include, but are not limited to: KPM CategoryKey Performance Metric (KPM)Suggested Threshold (Minimum Success)Suggested Objective (Desired Success)Persona CapacityAI-powered personas broadcasted simultaneously per decoy device.2 personas4+ personasOperational EnduranceBattery life for highly mobile/pluggable decoy form factors.12 hours24 - 36 hoursSystem WeightWeight of the personal decoy device.< 2 pounds~1 poundObfuscation RealismAbility of AI-generated traffic to mimic realistic patterns of life to defeat automated network analysis.Defeats basic heuristic analysisDefeats advanced ML-based behavioral tracking Phase I will consist of a six-month Period of Performance (PoP) to develop the initial application concepts, algorithms, and a comprehensive design document that outlines the software architecture for future development and deployment. Key activities include: Phase kickoff:Technical Interchange Meeting (TIM)Preliminary Design Review (PDR) Before the end of Phase I, the performer must develop and present a detailed plan for addressing Phase II prototype development, testing, and evaluation, aiming to advance the technology from its current state to TRL 7. Phase I Deliverables:Kickoff and TIM slidesMonthly Status Reports (MSRs)Preliminary Design Document detailing AI-persona generation and ID-swapping mechanicsPhase II PlanFinal Phase I Report

A Phase II follow-on effort will focus on prototype production, testing, and evaluation to reach a TRL 7 capability. The effort should result in the delivery of fully integrated mission management software and hardened decoy box form factors (e.g., Wi-Fi router-sized team devices and puck-sized personal devices). Key milestones will include:Month 1: Monthly Status Reports (MSRs) Month 1: Kickoff and TIMMonth 6: Critical Design Review (CDR)Month 9: Prototype demonstration of single and multi-node networked operationsMonth 11: Final design review, field demonstration (e.g., 5G test network execution), and assessmentMonth 12-18: Final Phase II Report Prototype demonstrations will be performed at the proposer’s site or an approved DoW test range. Performers should address scalability, including the ability to run multiple linked decoy boxes from a single operations laptop.

The proposed digital signature management technology presents significant dual-use potential. While fundamentally designed to protect military assets from advanced signals intelligence (SIGINT), the core capability of obfuscating cellular metadata directly translates to protecting high-value corporate assets, personnel, and intellectual property from commercial espionage and tracking.

The primary goal of this initiative is to design, build, and test a device that uses geometric phase (also known as Berry phase) to amplify laser light in the telecom band (wavelength ~ 1,550 nm). The device will use radio-frequency modulation of linear, lossy elements to produce optical amplification that outperforms existing technologies in parameter regimes of interest to DOW

Present-day devices for amplifying telecom laser light mostly produce gain by incoherently pumping a medium (optically or electrically), or by coherently pumping a nonlinear medium with a laser. Both approaches are technologically mature, and offer a range of performance tradeoffs.In contrast, geometric amplification is a gain mechanism that has only been recently proposed, and to date it has only been demonstrated in the acoustic domain [1]. However, the principle of geometric amplification can be applied to any domain. It can be realized using coupled resonators consisting only of linear, lossy components, so long as they can be modulated at a frequency comparable to the resonators’ decay rate [1].In the telecom domain, this can be accomplished using a pair of fiber loops that include electrically tunable phase shifters that can be modulated at ~ 1 MHz. The adiabatic evolution associated with this relatively slow modulation (together with the components’ intrinsic loss) results in the accumulation of a geometric (Berry) phase [2,3] whose complex part can be engineered to provide gain [1,4,5].Geometric gain differs existing forms of amplification in several respects, including that it achieves photon-number gain through rf modulation. This may offer practical advantages in terms of reduced device complexity, size, and power consumption.

Produce a complete design for a prototype telecom-band geometric amplifier based entirely on commercial off-the-shelf components. The design should be based on quantitative simulations that incorporate the components’ specifications into the mathematical model of geometric amplification.

Construct the device and optimize it with respect to the following performance metrics: gain, bandwidth, power consumption, added noise, and harmonic distortion. The device should exhibit > 10 dB gain with bandwidth > 100 kHz.

Collaborate with industrial and/or DOD lab partners to incorporate the lessons learned from Phase II into a commercial on-chip geometric amplifier that is superior to existing optical amplifier technologies in parameter regimes of importance to DOD.

Develop ultrafast, high-endurance, nonvolatile memory technology based on sliding ferroelectricity in polar moiré van der Waals homostructures.

Twisted stacks of van der Waals (vdW) crystals can form moiré superlattices with polar domains whose dipoles are antiferroelectrically aligned and controllable by applied electric fields [1]. Sliding ferroelectricity arises from nm-scale interlayer sliding in vdW materials, coupling in-plane atomic displacement to out-of-plane polarization switching [2]. This mechanism has been demonstrated in bilayer hexagonal boron nitride and semiconducting transition metal dichalcogenides, where polarization reversal can occur with minimal energy dissipation [3]. Recent Department of War investments through the Multidisciplinary University Research Initiative (MURI) have demonstrated advances in twisted two-dimensional heterostructures into atomically thin twistronic memory cell prototypes with potential advantages in speed, endurance, energy efficiency, and scalability [2, 3]. The advancement and prototype development requires a combined multidisciplinary expertise in the design, fabrication, measurement, and modeling of lattice dynamics in twisted moiré van der Waals structures, as well as charge transport and optoelectronics in van der Waals materials. The technical approach should exploit the atomically thin nature, low defect density, and strong in-plane bonding of vdW materials to develop sliding ferroelectric nonvolatile memory devices designed to outperform current memory technologies in speed, endurance, and scalability. Engineered nanoscale polar domains in moiré superlattices will serve as nonvolatile memory cells based on local ferroelectricity. To demonstrate the electrical and optical readouts in the designed nonvolatile memory devices, the proposal should leverage the scalability and controllability features of well-established systems, such as Graphene field-effect transistors and transition-metal-dichalcogenide-based field-effect transistors.

Demonstrate the feasibility of optimal moiré superlattice design for fast and durable sliding ferroelectric domain reversal, including domain wall pinning strategies and nanostructured polar moiré superlattice fabrication. Evaluate and analyze electrical and optical readout schemes using graphene field-effect transistors or transition-metal-dichalcogenide-based devices integrated with moiré polar domain structures. Perform quantitative analysis of the switching behavior, retention, readout fidelity, speed, energy efficiency, and endurance indicators under optimal device operating conditions. The success of the project will be evaluated using measurable performance indicators, including switching speed, switching energy, endurance, retention, readout fidelity, device-to-device reproducibility, and scalability beyond single-device demonstrations. During Phase I, these values will be quantified to establish appropriate performance targets for Phases II and III and to enable benchmarking against existing nonvolatile memory technologies.

Develop integrated sliding-ferroelectric memory-device prototypes and array-level architectures for more practical use by focusing on systematic evaluation of memory operation benchmarks including endurance, switching speed, and energy efficiency under realistic operating conditions. Particular attention must be paid to address the atomic-scale configuration of the engineered sliding ferroelectric state and the role of domain-wall pinning for controllability. Address scaling and manufacturability beyond single-device demonstrations, aiming initial demonstration of the wafer-scale patterning of local gates, partitioning of vdW structures into individual memory cells, and device packaging of memory arrays. Finally, establish quantitative comparison against competing nonvolatile memory technologies by evaluating switching energy, achievable integration density, and intrinsic fatigue resistance for long-term device operation.

Develop a high-speed memory device with low-power device operation, emphasizing energy-efficient memory for edge computing, high-density embedded memory, and robust architectures for defense-relevant electronics. Identify use cases where atomically thin, rapid, durable and low power switching will provide a demonstrable advantage over existing technology, and will describe approaches to industrial adoption and system level integration. Relatively low-power and moderate-speed operation offered by the developed technology can provide added value to the general purpose edge-computing applications. As performance metrics are established during Phases I and II, broader applications will be evaluated, including high-density embedded memory, neuromorphic and in-memory computing, reconfigurable logic, radiation-tolerant electronics, cryogenic control electronics, and memory components integrated with two-dimensional semiconductor platforms.

Bhawin LLC is evaluating OSW26TZ06-NV005, “Development of Ultrafast Nonvolatile Memory Based on Sliding Ferroelectricity in Moiré Polar Homostructures,” and we would appreciate clarification on several technical points as we develop our Phase I approach.Does Phase I require fabrication and testing of a fully functional sliding-ferroelectric memory device, or would a combination of moiré design/modeling, partial device fabrication, and experimentally validated subcomponents be sufficient to establish feasibility?Is there a preferred material platform for Phase I, such as twisted bilayer hBN or a particular transition-metal dichalcogenide, or may offerors select the polar homostructure based on switching performance, manufacturability, and integration potential?For the Phase I performance metrics—switching speed, switching energy, endurance, retention, readout fidelity, reproducibility, and scalability—does the Government have preferred quantitative targets, or should offerors establish these through benchmarking against existing nonvolatile-memory technologies?The topic references graphene FETs and TMD-based devices for readout. Would demonstration of one electrical readout architecture be sufficient in Phase I, or is both electrical and optical readout capability desired?What level of domain-wall pinning control is expected in Phase I? Are approaches such as patterned gates, electrostatic confinement, strain engineering, or engineered defects all considered acceptable?Does “scalability beyond single-device demonstrations” in Phase I imply fabrication of a small multi-cell array, or would an experimentally supported process-flow and scaling analysis be acceptable?Since Phase II calls for initial wafer-scale patterning of local gates, memory-cell partitioning, and packaging, should Phase I already demonstrate a specific scalable transfer/alignment/lithography process, or is a detailed manufacturability and scale-up plan sufficient?Would the Government consider participation by a university or industry partner with specialized expertise in 2D-material synthesis/transfer, nanofabrication, transport measurement, or device modeling to be particularly important for this topic?Thank you very much for your time and guidance. Your clarification will help us develop a Phase I approach that is well aligned with the Government’s technical expectations.

Does Phase I require fabrication and testing of a fully functional sliding-ferroelectric memory device, or would a combination of moiré design/modeling, partial device fabrication, and experimentally validated subcomponents be sufficient to establish feasibility?Yes, Phase I requires a functional prototype device.  Is there a preferred material platform for Phase I, such as twisted bilayer hBN or a particular transition-metal dichalcogenide, or may offerors select the polar homostructure based on switching performance, manufacturability, and integration potential?Materials choice is not limited to hBN or TMDC. For the Phase I performance metrics—switching speed, switching energy, endurance, retention, readout fidelity, reproducibility, and scalability—does the Government have preferred quantitative targets, or should offerors establish these through benchmarking against existing nonvolatile-memory technologies?Offerors should present benchmarked data against the existing SOA NVM technologies. The topic references graphene FETs and TMD-based devices for readout. Would demonstration of one electrical readout architecture be sufficient in Phase I, or is both electrical and optical readout capability desired?Either one of the readout techniques should be sufficient for the Phase I study. What level of domain-wall pinning control is expected in Phase I? Are approaches such as patterned gates, electrostatic confinement, strain engineering, or engineered defects all considered acceptable?There is no constraint on the type of technique used for the demonstration of domain-wall pinning control. Does “scalability beyond single-device demonstrations” in Phase I imply fabrication of a small multi-cell array, or would an experimentally supported process-flow and scaling analysis be acceptable?Since device demonstration along with the roadmap to scalability beyond it is expected from the Phase I effort. Since Phase II calls for initial wafer-scale patterning of local gates, memory-cell partitioning, and packaging, should Phase I already demonstrate a specific scalable transfer/alignment/lithography process, or is a detailed manufacturability and scale-up plan sufficient?Phase I should demonstrate a roadmap to Phase II requirements. Would the Government consider participation by a university or industry partner with specialized expertise in 2D-material synthesis/transfer, nanofabrication, transport measurement, or device modeling to be particularly important for this topic?If the team composition criteria for an STTR call is met, the offeror is free to select the team members or partners.  The small business must perform 40% of the work and a singular qualified RI must perform 30% of the work. The remaining 30% of the work is discretionary.

Design a chip-scale oxychalcogenide film (non-toxic, supply-chain-secure material platform)-based room temperature THz and infrared sensors.

Infrared sensing sits at an inflection point. The industry-standard HgCdTe (MCT) requires bulky cryogenic cooling and is built on toxic, supply-chain-fragile elements, while uncooled microbolometers, are limited to millisecond response times. This leaves unaddressed the regime of fast, uncooled, low-SWaP-C (Size, Weight, Power, and Cost) detection from the long-wave infrared (LWIR) through the THz, which hypersonic threat warning, proliferated drone platforms, and contested-spectrum operations now demand. Recently, new mechanisms have emerged that can fill this important technical gap. Oxychalcogenide films containing heavy elements have characteristic responses in the THz range [1-3] and can enable ms-scale detection responses in the THz and far-infrared spectral regions, e.g., hot-electron rectification/photothermoelectrics, thermally decoupled from the lattice of heavy elements [4-6]. Notably, these phenomena do not require cryogenic cooling like the MCT system because the signal is not based on an inter-band transition, and its response is orders of magnitude faster than that of room-temperature bolometers because it is driven by hot electrons decoupled from the lattice. Moreover, these materials, such as Bi2O2Se and InBiSe3, are composed of non-toxic, earth-abundant elements, and are supply-chain-secure material platforms. Department of War’s investments through the Multidisciplinary University Research Initiative (MURI) have already enabled the development of high-mobility chalcogenide films and their characterization via optical and THz spectroscopy [1–3]. Building on this, oxychalcogenide films can serve as room-temperature detectors offering uncooled, chip-scale access to the jam-free THz and far-infrared bands — a regime current sensor technologies cannot reach without cryogenic cooling — and will directly advance Quantum and Battlefield Information Dominance. Moreover, the hot-electron mechanism is fast, which allows detection of ms transients such as laser pulses and hypersonic signatures that slow uncooled microbolometers wash out.

Synthesis of oxychalcogenide thin film materials with strong spin-orbit coupling that can detect THz and LWIR signals at room temperature, and demonstration of direct absorption in the Long-wavelength infrared (LWIR) and antenna-coupled rectification at THz frequencies, benchmarked by responsivity (~0.5 A/W), noise-equivalent power (~0.1 pW/ √Hz), and response speed (ms) at room temperature, is expected. These results should anchor an electromagnetic and thermal design of an integrated dual-band THz/LWIR pixel.

Fabricate and validate the dual-band pixels, while adding quarter-wave cavity enhancement to the LWIR channel and demonstrating simultaneous, low-crosstalk two-band readout. Refine multilayer architectures and investigate the feasibility of even higher-mobility layers and quantum wells. Scale to a small-format array (~8x8) for as high as kilohertz-rate dual-band imaging of test scenes. Deliver a SWaP-C and manufacturability assessment benchmarked against cooled MCT and microbolometer incumbents.

Terahertz (THz) and Infrared (IR) sensing devices operating at room temperature (uncooled) represent a critical dual-use technology. By eliminating the need for bulky, power-intensive cryogenic cooling systems, these sensors enable highly portable, lightweight, and low-cost systems.  Features that underline a dual usage role for the developed sensing devices include:A fast uncooled oxychalcogenide focal plane enables short-range THz/infrared inspection of packages, vehicles, and surfaces — penetrating clothing, packaging, and dielectric coatings to reveal concealed weapons or contraband while keeping the operator at a safe standoff distance.The same long-wavelength response allows the sensor to see through smoke, dust, and brownout obscurants and makes a drone-borne payload effective in degraded visual environments where electro-optical and shortwave-IR imagers fail.

Are the performance benchmarks meant for just the THz frequencies? Do they also apply for the LWIR results?

The performance benchmarks were meant for both the THZ and LWIR applications.

Is the benchmark response time meant to be milliseconds (comparable to microbolometers) or something faster?

It is meant to be milliseconds.

Develop a reliable, cost-effective method to produce large area films of mechanically robust 2-dimensional polymers where the individual sheets are highly orientated perpendicular to film plane for membrane applications.

2-dimensional polymers (2DPs) such as covalent organic frameworks (COFs) are an emerging class of materials which have displayed significant potential in applications ranging from catalysis, energy storage, dielectrics, nanofiltration, gas storage, and mechanically robust engineering materials. They are synthesized from geometrically pre-defined building blocks and can accommodate a wide variety of pore shapes, sizes, and functionality. Most methods used to produce 2DPs result in an insoluble microporous powder that cannot be processed into a functional form factor which limits their relevance in commercial or military applications. Despite these challenges, a variety of creative approaches have been explored to process 2DPs into films, composites, or gels. Top-down methods such as exfoliation or solution casting or bottom-up methods that form films directly from cast monomer solutions have been used to varying levels of success to access films and membranes. Interfacial polymerization has also been used to form films at the interface of two immiscible solvents. Despite this progress, many of the available techniques suffer from limitations that preclude further elaboration into industrially relevant processing techniques or lead to formation of films of poor quality. Exfoliation based approaches are low-yielding and solution casting techniques often involve appending solubilizing groups to the pore wall which can block access to the pore itself. Methods that cast directly from monomer solution can be scaled up in a roll-to-roll process but often result in films that are mechanically weak as it is difficult to control the size and orientation of the individual 2DP sheets and they often lack sufficient intermolecular interactions. More work is needed to understand the underlying kinetics and thermodynamics of the film forming processes as it relates to monomer selection, layer alignment, domain size, and formation of defects. New engineering approaches are also needed to further control film formation, thickness, functionality, and orientation during deposition and post-processing. Special focus should be given to controlling and minimizing defects that could mitigate material performance: point and stacking defects within 2D polymer crystals, stacking defects in between crystallites, pinholes, and residual solvent / reactant contaminations within the films, crystallite size distributions to name a few.The objective of this topic is to develop a scalable, cost-effective method to produce large area 2DP ensemble films with superb control over structural evolution. Designed processes must consider monomer composition, long range structural order in lateral and parallel planes, interlayer interactions and flaw tolerance. The process should be amenable to roll-to-roll processing or a related method to produce continuous films.

Develop a continuous process to produce 2DP ensemble films from predefined monomer building blocks. The process should achieve a rate of 100 feet per minute of a film that is at least 1 foot wide and 1-50 microns thick. Using computational modeling and/or experimental studies, identify role of defects and flaws and quantify needed levels of domain size, layer alignments, and intermolecular interactions to achieve mechanically robust films. Using insights gained from understanding the underlying film forming mechanism, develop a framework to be implemented in Phase II to achieve required structural ordering.

Further develop processing approach from Phase I to increase deposition rate by 2-5X while expanding range of film width and of thickness while achieving domain sizes and orientations needed to form robust films. The method should be amenable to post-processing including annealing, tensioning, or post-polymerization modification to further increase ordering and alignment. Proxy measurement techniques may be developed to rapidly assess ordering and alignment.

Phase III efforts will further optimize the processing method and scale production to manufacturing-relevant levels and rates to achieve films with large, highly aligned domains with minimal defects. A variety of dual-use applications would benefit from an efficient production pipeline for 2DP films including nanofiltration membranes, battery separators, gas impermeable films, and critical mineral recovery.

What is the nominal pore size? What's the primary targeted application(s) of the resulted COF? 

What is the nominal pore size?  There is not a prescribed pore size for the 2D polymers. What's the primary targeted application(s) of the resulted COF? There are no prescribed or preferred applications for the Phase I effort. 

Utilize the fundamental understanding of hydrodynamic benefits from underwater vehicles swimming in proximity to each other to develop and demonstrate a design for an underwater vehicle team optimized for range, endurance, speed and quietness. The design should be based on rigorous analysis and leverage results from recent computational and experimental fluid dynamics investigations that have shown signifcant gains in efficiency resulting from group swimming. The design should also leverage new vehicle design spaces that result from the platform being unmanned and are available that might include novel propulsors (for example, fins, tails or other bio-inspired mechanisms) that utilize unsteady propulsion, body shape and body deformation. This STTR will provide increased capabilities for UUV teams based on the technology push from the fundamental understanding we now have of how hydrodynamic benefits of underwater swimming in groups.

Bio-inspired underwater vehicles have nearly matched the speeds and efficiencies of real fish. Now, these platforms are on the cusp of operating as multiagent teams, which would further improve efficiency and unlock novel mission utility. Recent work has shown how the hydrodynamic benefits of schooling can be translated into groups of underwater vehicles. In this STTR, the use of physical models and 3D simulations of sufficient fidelity are expected to enable exploration and understanding of the effects of controlled variation of key parameters such as geometric positioning with respect to other wakes and body deformation in developing protype underwater teams. Recent progress in this area, combined with the wide availability of 3D physical and computational methods, presents a significant, new opportunity for the application of fundamental knowledge to exploit the hydrodynamic benefits that result from schooling fish. This STTR Topic will pursue the design and demonstration of innovative, bio-inspired UUV teams with capabilities well beyond the state of the art for range, endurance, speed and quietness. The overall design objective and targeted capabilities apply to a group of untethered UUVs, each between 1-5 meters in length, and capable of operating in salt water to depths of 50 ft, to support Phase II and Phase III testing. Conventional designs and propulsors (such as propellers and jets) are not in scope for this topic. The design will be evaluated according to measurable performance criteria:– Speed: minimum 4 meters/sec, with an objective of 6 meters/sec or higher; Cost of Transport (COT): proposed project should optimize the COT and demonstrate clear improvement over the state-of-the-art, for the chosen vehicle length and speed; Quietness: underwater acoustic energy generated by the vehicles, should be minimized by design; Power: the design shall not rely on energy harvesting from the environment but can incorporate methods of energy recovery from mechanical motion itself. It shall utilize state-of-the-art energy storage (R&D into energy storage is outside the scope of this topic); Power Transmission: the design shall use state-of-the-art means of transferring power to the propulsor. Successful proposals will explain how the proposed means of power transmission will contribute to meeting the performance objectives; Sensing and control: approaches to sensing and dynamic control that optimize hydrodynamic interactions and flow physics are in-scope for this Topic. The successful proposal will explain how these will contribute to meeting the performance objectives; Path Planning: use off-the-shelf components to provide sufficient capability for the platforms to perform the demonstrations during Phase II and Phase III, including straight line tracks and simple maneuvers sufficient to demonstrate speed, range, endurance and acoustics. R&D into path planning is outside the scope of this topic; Vehicle cost: estimated cost of scaled manufacturing is a factor in the proposal evaluations and can be used to guide material and design selection. The successful proposal will identify supply chain risks and a mitigation plan.

The small business shall demonstrate the feasibility of the concept in meeting Navy needs for a team of UUVs capable of meeting the desired performance objectives, via model-scale experiments, computation, previous results and data, or fabrication of components (if feasible) for any difficult-to manufacture component. This body of evidence shall support the high-risk aspects of the design. The Phase I should convincingly show that the design is sufficiently robust to undergo the testing described in Phases II and III.

The small business shall fabricate a prototype team of UUVs, according to the requirements stated in this Topic, and evaluate the design via in-water tests conducted at a facility arranged by the small business. These tests shall target the STTR performance objectives listed above, via untethered operations. At a minimum, the prototype testing shall consist of (1) basic operability testing, (2) speed trials, (3) range/endurance trials, and (4) acoustic testing. The small business may propose other tests as needed to demonstrate the benefits of their design. It shall also perform analyses to establish reliability, identify areas for further improvement, and analyze manufacturing scalability to transition the design to the Navy.

The small business shall apply the knowledge gained in Phase II to build an advanced prototype UUV team. The small business shall test the advanced prototype according to the Phase II test goals. The small business shall support Government testing of the advanced prototype.

Generate a minimally viable component system with solar, water, and carbon dioxide inputs which generates >66% methanol/water fuel at a rate of 0.5L/hr with a total system weight <90 lb.

Modern warfare tactics have demonstrated the need to shift toward small, specialized, dismounted tactical units which can operate free from the supply line. Systems enabling Soldier power sustainment are essential to facilitate zero-resupply operations amid increasing energy requirements on the battlefield. To accomplish this demand, we need investments to capitalize on energy sources that can be replenished in austere environments, whether to directly power devices or charge batteries. Further, this energy source needs to impart minimal cognitive load on the warfighters, acting passively until put into use. Finally, it should be invisible to modern UAS-mounted sensors (e.g., IR detection). A technology that enables continuous methanol fuel cell usage from just sunlight, water, and atmospheric gases can accomplish these goals for uninterrupted power in contested logistics environments. The motivation for this topic has arisen from recent research that showed efficient utilization of locally available carbon resources and the selective synthesis of liquid fuels under austere conditions [5,6]. In one study, a solar-driven artificial photosynthesis platform was demonstrated that directly converts carbon dioxide and water into methanol, enabling onsite fuel generation without the high temperatures, pressures, and complex infrastructure required by conventional syngas-based processes. In a complementary effort, a pathway was developed for converting stranded natural gas and methane emissions into transportable liquid fuel using only sunlight and water, overcoming long-standing challenges associated with methane activation and overoxidation. Together, these advances establish scalable photocatalytic technologies for producing methanol from diverse carbon feedstocks, providing a foundation for expeditionary fuel manufacturing with reduced logistics burdens and enhanced energy resilience for distributed military operations.Based on these advances, the proposed system will leverage solar (concentrated or ambient) energetic inputs along with water (potable or otherwise) and carbon dioxide (ambient or concentrated) as the only chemical inputs to generate methanol fuel capable of meeting the daily power requirements of up to 4 Soldiers. This approach will produce ≥66% methanol-in-water that is immediately available for use with direct/reformed fuel cell systems including the Honey-Badger 20/50W PEM Power Generator. The system will be operable in remote, austere locations without a direct Soldier interface, while placed on the ground, or while secured to a light tactical off-road vehicle (e.g., Flyer 60). Operation with direct access to fresh water, ambient CO2, and clear weather conditions should generate at least 0.5 L of methanol per hour, with increased efficiency if concentrated CO2 sources are available. The total system weight should not exceed 90 lb (equivalent to a typical T6 battery), nor the dimensions exceed 0.5 m3. Heat emissions from the system should be minimal such that the system remains near ambient to IR cameras.The system will be designed with a 0.5 L (16.9 oz) input cartridge containing potable water (equivalent to a standard plastic water bottle volume) which will be converted into a 66% methanol/33% water fuel stream. Ideally, the system can also be directly powered by alternative sources (e.g., military standard generators, wind, etc.). Achieving the desired production rate while remaining lightweight and utilizing onboard vehicle power will require an innovative approach.

Create feasibility concepts for a methanol generation system with solar, water, and carbon dioxide inputs which generates >66% methanol/water fuel at a rate of 0.5L/hr and a total system weight <90 lb. Feasibility will be established by light harvesting toward methanol synthesis (catalytic or otherwise) and kinetics/turnover/selectivity evaluation, and analytical modeling to include engineering diagrams, heat/mass balance calculations, and computer-aided design models of possible prototype architectures. The final product is a Phase II development plan with performance goals and key technical milestones that address technical risk reduction.

Produce a prototype minimally viable product system for evaluation and assessment in accordance with the criteria established in this Topic. Demonstration and delivery to a DoW transition partner (e.g., DEVCOM C5ISR, DEVCOM Soldier Center, DEVCOM GVSC, etc.) is required to establish compatibility with DoW systems and direct future product iterations.The results of the evaluation will be leveraged to generate refinement plans for the prototype to better meet DoW requirements and determine product effectiveness in an operationally relevant environment. The final products of Phase II include the prototype described above, evaluation with a DoW partner and a Phase III development plan. The technology should reach TRL 6 at the conclusion of this phase.

The end-state of this research effort will be the introduction of an innovative strategy and prototype for producing methanol fuel in-field for use with DoW methanol fuel cell platforms. Because use of available materials represents an essential logistics benefit, the system will be designed to produce fuel from a standard 16.8 oz plastic water bottle, carbon dioxide, and direct or indirect solar energy. Such a system will permit Soldier power sustainment for mounted or dismounted teams, facilitating zero-resupply operations.A single unit should be able to meet the daily power requirements of 4 dismounted soldiers. Multiple units should be able to link up and provide auxiliary power to a FOB. As we expand toward fuel cells for UAS and UGV, the fuel produced by the projected device will directly be able to transition to provide power for those technologies. In some military and commercial cases where methanol fuel cells are prevalent, the projected devices will be able to easily and cheaply replace solar panels and batteries.Further, a simple, scalable method for methanol production can be directly plugged- into commercial use cases, such as industrial feedstock for other reactions (e.g., formaldehyde, hydrocarbons, olefins) for a wide array of applications (e.g., polymers). In such cases, the methanol produced by technologies driven during this STTR will enable on-site synthesis near factories and at lower temperatures (>200 °C) and energy costs than the current state-of-the-art.

Does the 90 lb and 0.5m3 requirement include the energy source, i.e. solar panels?

The 90 lbs includes everything including solar cells. (I gave an erroneous answer last week, so this answer supersedes it. However, note that these are just goals and not requirements from the start)

Are applicants to develop a system inclusive or exclusive of the solar power source and its associated hardware? A weight limit of 90lbs is stated, which we assume is excluding the solar power system itself. Thanks.

The 90 lbs includes everything including solar cells. - Answer updated from 9/24

Minimum requirements state >66% v/v Methanol in Water produced by the refinery at a rate of 0.5L/hr. If applicants propose the refine methanol to higher concentrations, such as 100%, does the volumetric minimum requirement remain at 0.5L, or shift lower to the effective methanol volume when mixed with water? eg: 0.33L of pure methanol is equivalent to 0.5L of methanol in water at 66% v/v.

If pure methanol can be produced, that is perfectly acceptable as long as the 66% 0.5L/h metric can be achieved via dilution.

Develop and demonstrate architected energy dissipation structures with rigid responsiveness at large tensile, compressive, and shear strains, but capable of conformability to surfaces of complex topographies and other fluid-like behaviors in response to small strains.

The DoW requires lightweight protection materials for a variety of applications, including personal protection, vehicle safety, and shielding sensitive electronics. Most protection structures are either a) rigid materials – e.g. metals, ceramics, composites - designed to carry significant mechanical loads and/or blunt kinetic threats, or b) flexible materials – e.g. elastomers, foam structures, structures based on polymeric fibers – intended to compress and/or stretch, are conformable, and effective at reducing peak accelerations [1]. However, most protection solutions cannot provide both rigid material response and conformability which limits applications for the Warfighter. Recently, a new family of energy dissipating structures known as “polycatenated architected materials” have been introduced that may display both solid- and fluid-like behaviors [2]. These structures, essentially “3D chainmail” and realized through additive manufacturing, derive their mechanical behaviors not through intrinsic material properties, but rather through geometric arrangement of internal solid elements, e.g. rings or cage-like particles interconnected into 3D networks (note that these materials consist entirely of solid linkages, collectively displaying “fluid-like” behaviors in response to small deformations). In response to severe loading, rigid elements may align and develop complex force chains that exhibit high strength and offer significant protection mechanisms not possible through conventional flexible options [2,3]. However, elements may also reorganize, slide, and/or rotate, which offers novel design mechanisms for dissipating energy, and new ways to enable comfort for applications related to personal protection.The goal of this topic is to create architected structures with tunable mechanical energy dissipating behaviors that can vary spatially throughout the material. Teams will investigate element and linkage materials, geometries, and nearest neighbor spacings to design architected structures that perform optimally for various static and dynamic loading conditions, e.g. via tensile, compression, impact, and rheology characterization. Teams will then design, process, characterize, and simulate energy dissipating behaviors of materials in multiple geometrical configurations, e.g. through comparisons to legacy impact attenuating materials like foams that are used for impact protection (knee pads, elbow pads, helmet pads). Teams will be expected to work alongside Army scientists and engineers to guide the design, manufacturing, and testing of materials. If successful, this effort would enable new materials design tools for the DoW to create customized protection structures for the expeditionary Soldier.

Design architected structures with individual linked grains in the following approximate rectangular configuration, 82 mm x 87 mm x 19.5 mm (thickness). The given geometry approximates a commonly tested helmet pad configuration and will allow teams to make comparisons to known technologies. Architected sheets shall display conformability to various geometries to include features with radii of curvature ranging from approximately 0.5-3.0 cm. The through-thickness compression response of the material should seek to maximize energy absorption efficiency as described in Equation 1 of reference [4]. Simultaneously, the material should minimize shear stiffness in the thickness direction. Teams will use advanced processing techniques, e.g. additive manufacturing approaches, to fabricate a minimum of 10 test specimens. Teams will perform computer simulations and initial experimental mechanical characterization to estimate in-plane and out-of-plane loads required to initiate solid-to-fluid transitions in the architected materials. Teams will perform impact tests across the range of 1-50 J and use legacy foam pads as a comparison.

Design and demonstrate architected structures with variable energy dissipating properties with respect to spatial position. Teams may consider multi-material and/or variable grain/linkage architectures to achieve the tunable behaviors. Process a minimum of 20 specimens in the geometrical configurations provided for Phase I and develop test techniques to assess the response of the structures whose energy dissipation behaviors vary spatially. Simulate the mechanical behaviors of the architected structures in response to compressive, tensile, shear, and impact loads. Determine loads required to initiate flexible-rigid transitions at various spatial positions within the structure. Work with Army Research Laboratory (ARL) scientists to design, manufacture, and deliver test specimens for advanced dynamic mechanical testing at ARL. Develop commercial and outreach plans to market the technology for civilian and defense markets; in addition, teams shall develop plans to scale manufacturing.

The discovery of polycatenated mechanical metamaterials has introduced a new family of structures that may display both solid- and fluid-like behaviors. The additional degrees of freedom associated with granular elements linked to nearest neighbors may enable a variety of new civilian and defense technologies, e.g. Soldier/Vehicle protection, sports equipment, law enforcement, and lightweight concepts for dissipating vibrational energy. Phase III efforts shall include outreach efforts based on market research to leverage opportunities in both civilian and defense markets. Implement plans to rapidly modify designs for specific customer needs. In addition, teams shall implement plans to scale manufacturing.

8. What properties and ranges would give success for this program? In particular, target energy absorption efficiency, peak transmitted force or acceleration at given energies within the 1-50 J range, areal density, an upper bound on shear stiffness, and the thickness and footprint envelope the final pads should fall within.9. Durability over a multi-year service life cannot be demonstrated inside a Phase II period of performance. What accelerated aging or repeat-impact protocols would ARL accept as supporting evidence, for example compression set after thermal cycling, humidity soak, or multi-hit testing at a fixed site?10. What functions must the pad serve beyond impact attenuation? We assume standoff, fit, ventilation, moisture management, and compatibility with the retention system are required functions. Anything else we should design against?11. Is the polycatenated architecture of reference [2] the objective in itself, meaning discrete linked grains such as rings or cages, or is any architected structure acceptable provided it delivers fluid-like response at small strain and rigid response at large strain? We ask because our process produces interlinked printed thread networks rather than assembled discrete elements, and the answer materially changes our Phase I design space. We can implement a series of gaps in our foams to achieve this performance for what it's worth.12. What attachment method is expected: hook-and-loop, adhesive, or mechanical? May the architected sheet incorporate integral attachment features, and is modification of the shell or the existing pad interface permitted, or is that structure not preferred?13. What flammability, smoke and toxicity, chemical decontamination, near-infrared signature, and restricted substance requirements apply to soldier-worn materials of this type? What is the qualification and approval path, and which organizations hold responsibility? 

1. Beyond what is stated in the solicitation, what are the key shortfalls of the legacy pad systems in the fleet today? Is it compression set after repeated wear, stiffening at low temperature, degradation from sweat and oils, comfort complaints/hot spots, or impact performance at specific energies? Any field data, removal records, or user feedback you can share would help us target the right mechanism with our technology.2. What assumptions should we make about the service environment? Such as temperature range, humidity, UV exposure, contact with sweat or chemicals, vibration, storage conditions, and the expected duty cycle (the number of impacts before replacement)?3. Is the 82 mm x 87 mm x 19.5 mm coupon the article of interest by itself, or should we plan for a full pad set spanning crown, front, rear, and side positions? How many pads per helmet, and what curvature does each position see? Is the 0.5-3.0 cm radius requirement tied to helmet interior features, or is it a broader conformability target covering knee, elbow, and vehicle applications?4. Will ARL release the legacy pad baseline product information to awardees? Including material, density, thickness, supplier, and the compression and impact data used for comparison beyond what is published in ARL-TR-8808? Separately, are sample legacy pads available for side-by-side testing in our lab? If a formal request is required, what is the channel?5. Is energy absorption efficiency per Equation 1 of Clough et al. the acceptance criterion for the coupon itself, or is it a helmet-level test the pad must help the assembly pass? If the latter, which standard and which threshold (for example, peak headform acceleration at 17 ft/s^2)?6. Beyond through-thickness compression, which loading modes dominate in service? Blunt oblique impact, rotational acceleration, repeated low-energy hits? At what strain rates would you like the solid-to-fluid transition characterized, and are there simulation approaches or codes ARL prefers for comparison against your own models?7. My reading of the topic is that the priorities rank as: 1.) energy absorption efficiency in through-thickness compression, then 2.) conformability across the 0.5-3.0 cm radius range, then 3.) minimum shear stiffness in the thickness direction, then 4.) spatial tunability, then 5.) areal density. Is that ordering correct, or would you weight them differently? 

When discussing minimum number of test specimens, is it 10 test specimens of a single design, or is it 10 unique designs that must be tested?

Thanks for the question.  For the Phase I metrics, we would be looking for a minimum 10 specimens for a single design.  The goal here is for firms to demonstrate control over the processing-structure-property-performance of the architected materials.

What is the target geometry to be used for impact testing? Can we use an actual dummy head?

Thanks for the question.  We don’t prescribe the material design or the impact tests to be performed.  It is expected that the materials could be applied to a range of technologies for impact mitigation.  We offer the example of the legacy foam pads and the reference to prior published Army research in this space as a starting point for an easily accessible comparison.

To understand the standard for the impact tests (currently given in J), what is the target impact speed and contact point?

Thanks for the question.  We don’t prescribe the particular impact tests to be performed, but offer the comparison to legacy foam pads and a reference to prior published Army research in this space as a starting point.

Is there a target material? In other words, is metal required, or can another rigid material be proposed?

Thanks for the question.  We don’t prescribe the particular material nor the design for the topic, just that the structure should be able to display both conformable and rigid behaviors depending on the applied loads.

1. Beyond what is stated in the solicitation, what are the key shortfalls of the legacy pad systems in the fleet today? Is it compression set after repeated wear, stiffening at low temperature, degradation from sweat and oils, comfort complaints/hot spots, or impact performance at specific energies? Any field data, removal records, or user feedback you can share would help us target the right mechanism with our technology.2. What assumptions should we make about the service environment? Such as temperature range, humidity, UV exposure, contact with sweat or chemicals, vibration, storage conditions, and the expected duty cycle (the number of impacts before replacement)?3. Is the 82 mm x 87 mm x 19.5 mm coupon the article of interest by itself, or should we plan for a full pad set spanning crown, front, rear, and side positions? How many pads per helmet, and what curvature does each position see? Is the 0.5-3.0 cm radius requirement tied to helmet interior features, or is it a broader conformability target covering knee, elbow, and vehicle applications?4. Will ARL release the legacy pad baseline product information to awardees? Including material, density, thickness, supplier, and the compression and impact data used for comparison beyond what is published in ARL-TR-8808? Separately, are sample legacy pads available for side-by-side testing in our lab? If a formal request is required, what is the channel?5. Is energy absorption efficiency per Equation 1 of Clough et al. the acceptance criterion for the coupon itself, or is it a helmet-level test the pad must help the assembly pass? If the latter, which standard and which threshold (for example, peak headform acceleration at 17 ft/s^2)?6. Beyond through-thickness compression, which loading modes dominate in service? Blunt oblique impact, rotational acceleration, repeated low-energy hits? At what strain rates would you like the solid-to-fluid transition characterized, and are there simulation approaches or codes ARL prefers for comparison against your own models?7. My reading of the topic is that the priorities rank as: 1.) energy absorption efficiency in through-thickness compression, then 2.) conformability across the 0.5-3.0 cm radius range, then 3.) minimum shear stiffness in the thickness direction, then 4.) spatial tunability, then 5.) areal density. Is that ordering correct, or would you weight them differently?  

Thank you for the questions: All of the criteria you mentioned are important.  It is difficult to rank these criteria in terms of importance, particularly since the topic authors do not have one particular application in mind, but rather seek to establish a new class of energy absorbing materials that could inform a variety of new protection schemes.  That said, specific energy absorption for a given thickness is critical for most protection technologies.We don’t prescribe these testing criteria at the moment given the low TRL nature of the topic.We offer this example as a starting point to help bound the problem and provide teams a readily accessible legacy material to make comparisons.  We are not expecting system level comparisons at this point.Again, we offer the example of a protection material of interest that will be commercially available.  However, this is a just a starting point and teams should consider how readily the designs might translate to other protection applications.See #2.  No, there are not particular codes that the topic authors would recommend.  All of the loading conditions mentioned are of importance.  See #1.See #1. 

We understand that the Polycatenated Materials inspired the topic, where the chainmail-like loop is used for the flexibility. Are you only accepting the chain-like connectivity between the units in this topic? Or, will you accept some form of continuum connectivity (e.g., snapping, bistable link) between the units?  We have a design that can potentially meet the metrices of the proposal (e.g., radii of curvature covering 0.5-3.0 cm) without a chainmail-like link. Can you please clarify the requirement of connectivity between the units? Is a polycatenated link essential?  Thank you!

Thank you for the question.  No, there is no requirement to use polycatenated architectures; we offer this as a recent discovery that may enable the topic objective.  The concept, as described, could be responsive to the topic, particularly if the structure is able to display conformable and rigid material behaviors over a range of impact energies.  Overall, the solicitation is seeking robust architected materials that can conform to complex curvatures, such as the human body, and demonstrate high efficiency energy attenuating properties. 

The topic appears to require architected structures that are conformable under small strains but develop a rigid, energy-dissipating response under more severe loading, with Phase I evaluated in a helmet-pad-sized geometry against legacy foams. Would a concept ultimately aimed at ballistic body armor be considered responsive if it meets that rigid-flexible behavior—for example, an additively manufactured metallic or multi-material architected structure that remains conformable in normal use but locks or stiffens under high-rate impact? Or is the intent primarily to develop replacements for foam-like impact attenuators used in helmet, knee, and elbow pads?More specifically, is high-velocity ballistic protection an intended application space for this topic, or should offerors assume the ultimate loading regime is primarily the 1–50 J impact attenuation described in Phase I?

Thank you for the questions.  The concept, as described, could be responsive to the topic, particularly if the structure is able to display conformable and rigid material behaviors.  The legacy foam pads are an example that is readily available for comparison - the 1-50 J range should be considered a starting point for teams to test new materials - but teams should not feel limited to this range only.  Personal protection for the dismounted Soldier is certainly a point of emphasis, wherein injurious impact events can range from 1 to hundreds of Joules.  Protection against ballistic impact is of course highly relevant to the Army.  Overall, the solicitation is seeking novel architected materials that can conform to complex curvatures, such as the human body, and demonstrate high efficiency energy attenuating properties.  It is anticipated that designs could be adapted to other applications with potentially higher energy attenuating requirements in future.  

Mature commercial and dual-use technologies that detect, track, identify, or defeat small low-flying drones (Group 1 and Group 2 unmanned aerial systems) in hostile or contested areas.

Inexpensive, highly maneuverable, commercially available unmanned aerial systems (UAS) threaten tactical forces, critical infrastructure, and installations. Current defenses are limited by cost, by the operator attention they require, and by their vulnerability to countermeasures. A capability gap against Group 1 and Group 2 UAS remains.This topic seeks mature or maturing technology at any point in the counter-UAS kill chain. The three areas below are where capability is most needed. They are examples. A proposal may address one area, more than one, or a gap not listed here.Detection and Tracking. Detect and hold track on highly agile targets in cluttered low-altitude airspace. The proposer selects the sensing modality. Approaches that hold track when the target is not emitting are preferred. Solutions that require permanent site infrastructure or mains power, including fixed perimeter sensor installations, are out of scope for this area. The system must move with the force.Identification and Decision Support. Classify and identify unauthorized platforms and support an engagement decision. Processing must run on tactical computing hardware carried or emplaced with the force. Proposals should describe a pathway to interoperate with existing command and control. Conformance to a named standard is not required at this stage and will not be scored.Mitigation and Defeat. Kinetic, non-kinetic, or cyber approaches that defeat hostile UAS in remote tactical theaters and in densely populated areas. Proposals must address collateral effects.Operating preferences. The operating environment is denied, contested, and unattended. The four conditions below are preferences, not eligibility requirements. Every proposal must state where it stands against each one.(a) The system does not require the target to emit radio frequency (RF) energy. Passive RF may be part of a solution; the preference is that track holds when the target is silent.(b) The system does not radiate. The Government favors kinetic and cyber defeat over approaches that require the friendly system to emit. Jamming, active illumination, and transmission into a target's control or navigation link are in scope. A proposal that uses any of them must say so and describe the operational effect.(c) The system does not require cloud services or reachback. Training and analytics may occur off-platform. The processing that produces the operational output should run on the platform, and the system should continue to function with all external network interfaces disabled.(d) The system does not require a dedicated operator, meaning no person whose only task is attending it. Human judgment over the use of force is expected and is not addressed by this preference.Out of scope: work requiring classified access or a facility clearance at the time of award, and approaches that depend on cooperative identification, including Remote ID broadcast.

This topic solicits Direct-to-Phase-II (DP2) proposals only. Direct to Phase II proposers shall submit documentation showing that Phase I-equivalent feasibility has already been achieved outside the SBIR/STTR program. Adequate documentation is a written record of at least one test of the proposed approach stating the conditions under which the test was conducted, the dates, the target, threat, or surrogate used, the measured result, and how it was measured.Test data, technical reports, and third-party evaluation metrics are acceptable. A system design alone is not sufficient. A self-declared technology readiness level unsupported by a documented test is not sufficient.As required by the DoW solicitation, the feasibility documented may not rest solely upon, or logically extend from, prior or ongoing federally funded SBIR or STTR work; the proposing firm and/or the principal investigator must have substantially performed the work relied upon; and the firm must demonstrate ownership or licensure of the associated intellectual property prior to proposal submission.

Phase II is a major research and development effort. Performers refine the Phase I concept into an operational prototype that demonstrates real-world functionality. The primary deliverable is a functional system, software package, or physical prototype ready for test and evaluation in a militarily relevant or simulated field environment. The technology shall reach TRL 6 by the end of Phase II.The period of performance is twelve months rather than the twenty-four the announcement allows. The intent is to move a demonstrated capability to a transition decision within one year. Proposals should be scoped to that schedule.The Government may host a showcase about six months after award. Attendance is by invitation and is based on end user interest in the capability. It is not required of every performer. Performers shall provide operational evidence supporting a follow-on funding decision whether or not they are invited.

Commercial applications are those in which the equipment deploys with a team rather than being installed at a site: temporary airspace security for outdoor events, venues, and construction or energy sites; convoy, executive, and site-survey protection; wildfire, disaster, and critical infrastructure response; and mobile detection kits for law enforcement and allied partners. Detection, tracking, and identification technologies have a direct commercial market in these roles. Authority to mitigate or defeat unmanned aircraft in the United States is limited by statute to covered federal entities. A defeat-focused proposal is not expected to show a near-term domestic commercial market for that function.Military applications include integration into point-defense systems for tactical units, forward operating bases, and naval vessel protection platforms, which may be funded via non-SBIR/STTR acquisition budgets.

Mature commercial and dual-use technologies that detect, track, identify, or defeat small low-flying drones (Group 1 and Group 2 unmanned aerial systems) in hostile or contested areas.

Inexpensive, highly maneuverable, commercially available unmanned aerial systems (UAS) threaten tactical forces, critical infrastructure, and installations. Current defenses are limited by cost, by the operator attention they require, and by their vulnerability to countermeasures. A capability gap against Group 1 and Group 2 UAS remains.This topic seeks mature or maturing technology at any point in the counter-UAS kill chain. The three areas below are where capability is most needed. They are examples. A proposal may address one area, more than one, or a gap not listed here.Detection and Tracking. Detect and hold track on highly agile targets in cluttered low-altitude airspace. The proposer selects the sensing modality. Approaches that hold track when the target is not emitting are preferred. Solutions that require permanent site infrastructure or mains power, including fixed perimeter sensor installations, are out of scope for this area. The system must move with the force.Identification and Decision Support. Classify and identify unauthorized platforms and support an engagement decision. Processing must run on tactical computing hardware carried or emplaced with the force. Proposals should describe a pathway to interoperate with existing command and control. Conformance to a named standard is not required at this stage and will not be scored.Mitigation and Defeat. Kinetic, non-kinetic, or cyber approaches that defeat hostile UAS in remote tactical theaters and in densely populated areas. Proposals must address collateral effects.Operating preferences. The operating environment is denied, contested, and unattended. The four conditions below are preferences, not eligibility requirements. Every proposal must state where it stands against each one.(a) The system does not require the target to emit radio frequency (RF) energy. Passive RF may be part of a solution; the preference is that track holds when the target is silent.(b) The system does not radiate. The Government favors kinetic and cyber defeat over approaches that require the friendly system to emit. Jamming, active illumination, and transmission into a target's control or navigation link are in scope. A proposal that uses any of them must say so and describe the operational effect.(c) The system does not require cloud services or reachback. Training and analytics may occur off-platform. The processing that produces the operational output should run on the platform, and the system should continue to function with all external network interfaces disabled.(d) The system does not require a dedicated operator, meaning no person whose only task is attending it. Human judgment over the use of force is expected and is not addressed by this preference.Out of scope: work requiring classified access or a facility clearance at the time of award, and approaches that depend on cooperative identification, including Remote ID broadcast.

Phase I shall determine the technical, scientific, and commercial feasibility of the proposed approach. Work may include developing a concept architecture, modeling critical software components, or bench testing key hardware elements. Phase I deliverables are a feasibility study, a technical report, and an initial system design package showing the path to a prototype.The technical report shall state the conditions, dates, and target or threat surrogate used in any testing performed, and the measured result. It shall also state where the approach stands against each of the four operating preferences.As required by the DoW solicitation, the feasibility documented may not rest solely upon, or logically extend from, prior or ongoing federally funded SBIR or STTR work; the proposing firm and/or the principal investigator must have substantially performed the work relied upon; and the firm must demonstrate ownership or licensure of the associated intellectual property prior to proposal submission.

Phase II follow-on depends on the availability of future-year funds and will be considered among the Phase I awardees under this topic.Phase II is a major research and development effort. Performers refine the Phase I concept into an operational prototype that demonstrates real-world functionality. The primary deliverable is a functional system, software package, or physical prototype ready for test and evaluation in a militarily relevant or simulated field environment. The technology shall reach TRL 6 by the end of Phase II.The period of performance is twelve months rather than the twenty-four the announcement allows. The intent is to move a demonstrated capability to a transition decision within one year. Proposals should be scoped to that schedule.The Government may host a showcase about six months after award. Attendance is by invitation and is based on end user interest in the capability. It is not required of every performer. Performers shall provide operational evidence supporting a follow-on funding decision whether or not they are invited.

Commercial applications are those in which the equipment deploys with a team rather than being installed at a site: temporary airspace security for outdoor events, venues, and construction or energy sites; convoy, executive, and site-survey protection; wildfire, disaster, and critical infrastructure response; and mobile detection kits for law enforcement and allied partners. Detection, tracking, and identification technologies have a direct commercial market in these roles. Authority to mitigate or defeat unmanned aircraft in the United States is limited by statute to covered federal entities. A defeat-focused proposal is not expected to show a near-term domestic commercial market for that function.Military applications include integration into point-defense systems for tactical units, forward operating bases, and naval vessel protection platforms, which may be funded via non-SBIR/STTR acquisition budgets.

The objective of this topic is to develop applied research toward an innovative capability that provides resilient, jam-resistant communications and cooperative navigation for distributed Group three (3) unmanned aerial system (UAS) formations operating in Global Positioning System (GPS)-denied environments across a theater-scale formation spanning two hundred (200) to three hundred (300) nautical miles over feature-sparse terrain. The proposed free-space photonic crosslinks will simultaneously provide low probability of intercept and low probability of detection (LPI/LPD) data transport, precision time transfer, optical direction finding, and ranging.

Future autonomous operations will occur in contested electromagnetic environments where traditional positioning, navigation, and timing (PNT) references cannot be assumed. Radio frequency (RF) emissions are inherently detectable, direction-findable, and susceptible to interference and spoofing. These properties are extensively characterized in the open engineering and civil aviation safety literature. Distributed autonomous systems still need to execute coordinated maneuver, distributed sensing, collaborative targeting, long-range autonomy, and mesh-networked operations under these conditions. Inertial navigation accumulates drift over long-duration sorties. RF cooperative navigation can be detected and jammed. Existing free-space optical terminals often exceed Group three (3) UAS size, weight, and power (SWaP) constraints. The needed capability is an ad hoc PNT network, or distributed navigation transport layer, in which the optical mesh serves simultaneously as a data transport layer and as a distributed navigation sensor. Each photonic inter-UAS crosslink provides high-capacity coherent optical communications, two-way precision time transfer, precision optical direction finding, and ranging. Adjacent nodes exchange state vectors, time-transfer references, optical angle measurements, range measurements, and navigation corrections, and a distributed estimator fuses these optical measurements with local inertial data to constrain relative geometry and suppress drift. Anchor nodes operating within visual navigation range of land provide absolute position, bearing, and time references, and these references propagate hop by hop through an optical relay chain to nodes operating over featureless open water. The required capability is defined at the scale of the full swarm, with the formation-level requirement taking precedence over any single link. The swarm shall maintain a navigation accuracy of eight (8) to eleven (11) meters circular error probable (CEP), or better, at the most distant node of a distributed formation spanning two hundred (200) to three hundred (300) nautical miles over feature-sparse terrain, with the formation anchored to land-based references at one end and extending beyond visual navigation range at the other. A representative relay geometry uses approximately eight (8) to twelve (12) optical hops with per-hop ranges of twenty (20) to thirty (30) nautical miles. Proposers may trade hop count against per-hop range, provided the architecture closes the full formation span and meets the formation-level CEP requirement. The architecture shall maintain a shared, formation-wide navigation solution across all nodes in the chain, shall bound error growth across successive hops such that accumulated drift at the seaward edge of the formation remains within the formation-level accuracy requirement stated above, and shall preserve formation coherence under the loss of individual nodes or links within the chain. Candidate payload architectures should provide broad angular coverage within Group three (3) UAS SWaP constraints, including multi-sector optical apertures combining wide-field acquisition sensing (tens of microradians of precision after approximately 1 second of integration) with high-bandwidth photonic beam steering and coherent detection for navigation-grade closed-loop tracking (sub-microradian angular resolution in less than 1 millisecond). As a part of this feasibility study, the proposers shall address all viable overall system design options with respective specifications on the key system attributes, including link budget and range, acquisition and tracking precision, time-transfer accuracy, ranging accuracy, distributed estimation architecture, payload SWaP, and robustness to atmospheric attenuation, atmospheric ducting, turbulence, link interruption, and node loss.

As a requirement of this Direct to Phase II (DPII), proposers must include a feasibility study that assesses what is in the art of the possible that satisfies the requirements specified in the above paragraphs entitled “Objective” and “Description.”The objective is to document the results of a thorough feasibility study (“Technology Readiness Level 3”) to investigate what is in the art of the possible within the given trade space that will satisfy a needed technology. The feasibility study should investigate all options that meet or exceed the minimum performance parameters specified in this writeup. It should also address the risks and potential payoffs of the innovative technology options that are investigated and recommend the option that best achieves the objective of this technology pursuit. For this topic, the feasibility study should define the system architecture, select the platform configuration, model navigation performance across the full two hundred (200) to three hundred (300) nautical-mile multi-hop relay geometry, including error propagation, time-transfer degradation, and observability across all hops from the land-anchored node to the most distant open-water node, study payload integration on a representative Group three (3) UAS, analyze attitude sensor bias instability, trade front-end optics magnification against coarse pointer precision, and culminate in fabrication of a prototype payload and demonstration of a single optical flight link validating acquisition, precision tracking, and single-link state exchange.

Develop, install, and demonstrate a prototype system determined to be the most feasible solution during the Phase I feasibility study on a representative Group three (3) UAS formation. The Phase II effort extends the work from one link to multiple cooperating assets by demonstrating a feature-rich-to-feature-sparse relay chain representative of a two hundred (200) to three hundred (300) nautical-mile formation, extending optical link range toward twenty (20) to thirty (30) nautical miles, investigating atmospheric ducting effects on pointing-error bias and navigation state estimation, validating cooperative navigation under degraded external-reference conditions, and characterizing multi-hop distributed operation across multiple assets. The measured results will be scaled against the formation-level objective of eight (8) to eleven (11) meters CEP, or better.

This system could be used in a broad range of military applications where distributed platforms require jam-resistant, LPI/LPD communications and GPS-independent navigation, including distributed sensing, autonomous intelligence, surveillance, and reconnaissance (ISR) swarms, attritable aircraft, maritime autonomous systems, long-range autonomous maneuver, contested logistics, and distributed operations at theater scale. Commercial applications include free-space optical backhaul for telecommunications, coordination of commercial drone fleets in GPS-degraded urban environments, precision timing distribution for critical infrastructure, offshore wind and maritime survey operations, and airborne relay networks for disaster response where terrestrial infrastructure is unavailable.

The RIPTIDE topic identifies Group 3 UAS SWaP as an important consideration for the proposed optical payload but does not specify numerical payload constraints. Can the Government provide representative or bounding limits for payload mass, electrical power, volume/dimensions, and thermal dissipation? If specific limits are not intended, should proposers select a representative Group 3 UAS platform and define an appropriate payload SWaP envelope for the Phase II feasibility analysis? 

Yes, the Phase II Statement of Objectives (SOO) provides specific target limits for the payload's size, weight, and power (SWaP). These can be found in Solicitation Documents & Instructions > Supporting Documents & Templates.The Phase I feasibility study requirements state that a study should "study payload integration on a representative Group three (3) UAS." Proposers are expected to select a suitable platform and analyze the integration of a payload that meets the specified SWaP constraints. 

The topic description refers to “photonic beam steering”.  Does the government require a specific beam-steering technology, like a fiber-based or solid-state optical phased array, or is the government open to other beam-steering technologies?  It seems like a fairly low-TRL category of technologies to require for transceivers that need to be flight tested soon.

We are open to any and all beam-steering technologies. As long as it fits in Group 2-3 form factors.

The topic description refers to “coherent optical communication” and “coherent detection”.  Is a coherent modulation technique required, or is the government open to direct detection (e.g. amplitude shift keying)?

Thank you for the question. We did not intend to overly constrain the methods and simply wanted to give an example that the government was familiar with. We are open to direct detection techniques as well.

The Phase I feasibility requirement states that the study should “culminate in fabrication of a prototype payload and demonstration of a single optical flight link validating acquisition, precision tracking, and single-link state exchange,” while describing the required feasibility as TRL 3. For D2P2 eligibility, must the offeror have already fabricated such an integrated airborne payload and demonstrated the optical link in flight prior to proposal submission? Or may feasibility be established by prior offeror work demonstrating the relevant constituent technologies, supported by analysis showing their feasibility and integration into the proposed payload, even though the complete integrated payload has not previously been flight-demonstrated? Please clarify whether prior integrated flight demonstration is an eligibility requirement for this topic.

A completed integrated payload does not have to have already been flight demonstrated. While a flight demonstration would be beneficial, the Government is willing to review submissions where the offeror has demonstrated a non-trivial communication link between endpoints and can establish the feasibility of the proposed approach.