DARPA SBIR DPA26BZ06-DV027: Casualty Operations and Resource Prediction Software (CORPS)
Quick Answer
DPA26BZ06-DV027 is a DARPA SBIR Direct to Phase II topic under the DoW 2026 SBIR Broad Agency Announcement, Release 6. DARPA wants software that predicts casualty and patient streams following large scale medical emergencies in austere environments, and then projects the lifesaving potential of different response options, with limited or no access to real-time data or communications. The award per the topic index is $750,000 over 12 months with no options. The topic opens September 23, 2026 and closes October 21, 2026 through the Defense SBIR/STTR Innovation Portal.
The problem DARPA describes is a decision-making problem under bad information, not a modeling problem in the abstract. Strategic and operational medical planning happens with time and full situational awareness. Crisis action decisions do not: they must be made in much shorter time frames, using sparse, low-quality situational data that cannot be verified because communications are denied, disrupted, intermittent, and limited in bandwidth. And medical response competes with tactical and logistical demands, so the medical benefit of a response option has to be weighed against what that option costs the mission. Without quantitative metrics for the medical benefit of each option, those lifesaving decisions get made subjectively.
Important scheduling note before you plan anything. The topic index states $750,000 over a 12 month period of performance with no Option 1 or Option 2. The Phase II narrative and milestone tables in the same document describe an 18 month base period plus a 6 month option period, with milestones running through Month 24. Those two statements cannot both be right, and this is the first question to send to DARPA.
Topic At a Glance
Topic number: DPA26BZ06-DV027
Title: Casualty Operations and Resource Prediction Software (CORPS)
Agency: Defense Advanced Research Projects Agency (DARPA)
Solicitation: DoW 2026 Small Business Innovation Research Broad Agency Announcement, Release 6, DARPA Proposal Submission Instructions
Program type: Direct to Phase II (DP2). This topic is soliciting DP2 proposals only
Technical volume format: White Paper and Slide Deck. The white paper shall not exceed 20 pages and the slide deck shall not exceed 15 slides
Award per the topic index: $750,000
Period of performance per the topic index: 12 months, with no Option 1 and no Option 2
Award structure per the topic narrative: an 18 month base period plus a 6 month option period, with milestones through Month 24. This conflicts with the index and needs clarification
Component Technology Priority Areas: Advanced Computing and Software; Integrated Network Systems-of-Systems; Trusted AI and Autonomy
Projected CMMC level requirement: Level 2 (Self)
Export control status: no topic-level ITAR or EAR restriction paragraph appears on this topic
Minimum technology maturity: offerors should only propose products at or above Technology Readiness Level 2
Prototype delivery requirement: no less than 4 prototypes supporting different military user evaluations
Technical and Business Assistance: up to $25,000 per Phase II project, in addition to the cost ceiling
Topic Q&A: DSIP Topic Q&A is not available for DARPA topics. Technical questions go to SBIR_BAA@darpa.mil by October 14, 2026
Topic open date: September 23, 2026
Proposal deadline: October 21, 2026. DARPA will not accept late proposals
Submission portal: DSIP at dodsbirsttr.mil
Keywords: medical response, austere environments, casualty stream predictions, contested logistics, decision aid, automation
The Schedule Discrepancy You Must Resolve
This is the single most important administrative item on this topic, and it affects your cost volume, your milestone plan, and your staffing.
The Current Release Award Structure by Topic table for the White Paper and Slide Deck format lists DPA26BZ06-DV027 with an Award Amount of $750,000, a Period of Performance of 12 months, an Option Amount of N/A, and an Option Period of Performance of N/A.
The Phase II narrative for the same topic states that the 18-month base period should focus on developing, integrating, and demonstrating the core capabilities of the prototype through measurable milestones and evaluations, and that the 6-month option period should focus on refining the prototype based on user feedback, validating performance in operationally relevant scenarios, and enabling transition. The Phase II Milestones table then runs M1 through M6 across Months 1 to 18, and a Phase II Option Milestones table runs O1 through O3 across Months 19 to 24. A closing paragraph restates the 18 month base and 6 month option split, describing the base as "Develop, Integrate, and Demonstrate" and the option as "Refine, Validate, and Enable Transition."
Twelve months with no options and eighteen months plus a six month option are not reconcilable. Possible readings include that the index is correct and the milestone tables were carried over from a longer version of the topic, or that the index row is in error and the narrative governs. We cannot tell from the document.
What to do. Submit this question to SBIR_BAA@darpa.mil with the topic number in the subject line, well before the October 14 deadline, and watch the consolidated FAQ. In the meantime, note that DARPA's instructions state that proposals which do not comply with the requirements detailed in the BAA and the research objectives of the corresponding topic are considered non-conforming and are therefore not evaluated. That makes proposing the wrong period of performance a real risk rather than a cosmetic one. If you cannot get an answer, the safer construction is to propose to the index figures, since the index is the controlling award structure table, while showing in the technical volume how your milestone plan maps onto the six-milestone base structure DARPA described, compressed to the funded period.
What DARPA Is Actually Looking For
The objective
A software tool to predict casualty and 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.
Why crisis medical planning is different
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 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, or 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.
That final sentence is the gap. Today the medical benefit of a response option is a judgment call made from bad data. DARPA wants it to be a number.
What the product must do
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 and 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.
Three functions, and the third one is the differentiator. Predicting casualties is one thing. Predicting the medical needs those casualties generate, with variable latencies, is harder. Quantifying the benefit of each response option as a function of time is the part that turns a model into a decision aid.
Solutions must have the potential for use in the civilian sector, meaning 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.
That last requirement is the DDIL constraint restated as a design principle. Your tool has to degrade gracefully. Full connectivity, intermittent connectivity, and no connectivity should all produce usable output at different confidence levels, and saying how is central to a responsive proposal.
The Feasibility Requirement
This topic is soliciting Direct to Phase II 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.
DARPA then lists seven things a demonstration of feasibility may include. The permissive "may include" language gives you latitude in how you evidence it, but the list tells you what DARPA expects to see.
Conceptual characterization of the complete product.
Relevant use cases, required data categories, and anticipated final capabilities.
Leveraged 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 above.
Design specifications for any computational or software components of a prototype.
Then a separate requirement that is not optional: proposals should contain preliminary data, published or unpublished, supporting the rationale for the development of the candidate products. Describe how the product will be usable in the operational continuum or the environmental settings for which it is designed.
Note that this feasibility bar is notably softer than several other topics in this DARPA release. It asks for conceptual characterization, methodology, design specifications, and preliminary data, rather than a validated working prototype. That opens the topic to modeling and analytics teams with strong underlying science and a credible design, rather than restricting it to companies with fielded software. If you have published casualty modeling work, medical logistics optimization research, or operations research applied to mass casualty response, read this requirement carefully before assuming you are ineligible.
For the White Paper and Slide Deck format, the white paper shall not exceed 20 pages and the slide deck shall not exceed 15 slides. Refer to Appendix B, DARPA Direct to Phase II Instructions, for the content of each element of the Technical Volume and the commercialization strategy.
The Phase II Program
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, for example 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 2.
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.
What the proposed work may include
Information required for a Phase I proposal, including selected methods and approaches.
Medical, scientific, and technical justification and selection criteria for specific approaches.
Anticipated data sources, for example theater, casualty, medical, natural, virtual, and types, organic versus synthetic.
Interactions and relationships between the data and modeling components of the proposed work.
Detailed description of planned prototype design and development, covering communication requirements, data, architecture, software, interface, and models.
Methodology and outcome metrics for determination of functionality and utility.
Threshold and objective exit criteria.
The four prototype requirement
The 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.
That is an unusual and demanding structure. Four successive prototypes, each evaluated by different military users, each more capable than the last. It maps directly onto the milestone table below, where Prototypes 1 through 4 are named milestones at Months 8, 11, 15, and 18. Your plan must be organized around iterative delivery and user evaluation, not a single build.
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.
Dynamic uncertainty quantification appears in both the Phase III strategy requirement and in the Prototype 2 milestone. Given that the entire premise is decision-making on sparse, unverifiable data, quantified uncertainty is not a refinement, it is the feature that makes the output trustworthy. Treat it as core.
The milestone structure DARPA specifies
Note that these milestones assume the 18 month base and 6 month option structure described in the narrative, which conflicts with the 12 month no-option structure in the index. Resolve that before building your plan, but understand the intended shape.
M1, Operational Requirements and Technical Baseline, Months 1 to 2. Technical objective: establish the operational concept, technical architecture, and data strategy for casualty prediction and medical decision support in DDIL environments. Exit criteria and deliverables: System Requirements Specification, System Architecture Description, Data Management Plan, with an End of Month 2 System Requirement Review.
M2, Casualty Prediction and Data Fusion, Months 3 to 5. Technical objective: develop and validate the baseline casualty prediction engine using representative military and civilian datasets with varying data completeness. Exit criteria: baseline casualty prediction engine demonstrated, data fusion capability validated using representative operational scenarios, initial model performance assessment completed, with an End of Month 5 Technical Baseline Review.
Note the phrase "varying data completeness." Your validation has to show the engine works when the data is partial, which is the operational reality the topic describes.
M3, Prototype Number 1, Technical Baseline and Decision Optimization Prototype, Months 6 to 8. Technical objective: establish 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. Exit criteria: an Operational Model Baseline covering physiology model requirements, performance objectives, and fidelity needed to support operational decision making; operational parameter space, key decision variables, and scenario boundaries; data requirements, model assumptions, constraints, and uncertainty characterization; threshold and objective performance metrics, verification methodology, and validation approach. Plus automated Course of Action generation and ranking demonstrated. There is a Month 6 Government Technical Baseline Review completed, establishing technical foundation and evaluation criteria for prototype maturation, and an End of Month 8 Prototype 1 Presentation and Demonstration.
M4, Prototype Number 2, Decision Support and Interaction, Months 9 to 11. Technical objective: develop an interactive decision-support interface incorporating user-defined constraints and dynamic uncertainty quantification. Exit criteria: interactive visualization demonstrated, dynamic uncertainty and confidence metric demonstrated, user assessment completed and incorporated into prototype refinement, with an End of Month 11 Prototype 2 Presentation and Demonstration.
M5, Prototype Number 3, Integrated Operational Prototype, Months 12 to 15. Technical objective: integrate prediction, optimization, visualization, and user interaction into a single operational prototype and demonstrate functionality in representative military scenarios. Exit criteria: successful tabletop exercise completed, prototype evaluated against metrics, with an End of Month 15 Prototype 3 Presentation and Demonstration.
M6, Prototype Number 4, Operational Prototype Demonstration and Transition Planning, Months 16 to 18. Technical objective: demonstrate a mature prototype and establish the technical foundation for Phase III transition. Exit criteria: operational prototype demonstration completed, final technical report completed, Phase III transition strategy completed, with an End of Month 18 Prototype 4 Presentation and Demonstration.
Option milestones:
O1, Operational Refinement and Model Optimization, Months 19 to 20. Refine casualty prediction, decision optimization, and user interface capabilities based on Government feedback from Phase II evaluations. Exit criteria: prototype refinement demonstration, model improvement documentation, with an End of Month 20 updated prototype demonstrating improved performance.
O2, Expanded Operational Validation, Months 21 to 22. Validate prototype performance across representative military and civilian emergency response scenarios. Exit criteria: prototype demonstration with expanded scenarios with metric and threshold validations, user evaluation report documentation, with an End of Month 22 updated prototype demonstration.
O3, Transition Readiness, Months 23 to 24. Prepare the prototype for Phase III maturation by documenting technical maturity, transition planning, and integration considerations. Exit criteria: updated transition and commercialization plan identifying DoD and commercialization opportunities, preliminary integration and cyber security strategy documented, final prototype package delivered, with an End of Month 24 final program review.
Phase III
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" or 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 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 is 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, for example following natural disasters or war.
Two practical notes. The ATO requirement is real work with its own timeline, and the O3 option milestone asks for a preliminary integration and cyber security strategy, which is where you begin addressing it. And the transition target is Service-specific mobile applications, which tells you the eventual delivery form factor and argues for designing the interface with mobile constraints in mind from the start.
Funding, Cost Structure, and DARPA Mechanics
The award
Per the topic index, $750,000 over 12 months with no options. Per the topic narrative, an 18 month base plus a 6 month option. See the discrepancy section above and resolve it with DARPA before you build your cost volume.
The resources made available for each topic will depend on the quality of the proposals received and the availability of funds. The Government reserves the right to select for negotiation all, some, one, or none of the proposals received and to make awards with or without communications with proposers, and to award all, some, one, or none of the options based on available funding and the performer's technical performance.
Contract type, which you must elect
DARPA may award FAR-based contracts, firm-fixed-price or cost-plus reimbursement, or Other Transactions for Prototype under the authority of 10 U.S.C. 4021, subject to approval of the Contracting Officer or Agreements Officer respectively. Proposers must state their requested contract type in their proposal.
Cost-plus reimbursement requires including your Defense Contract Management Agency Final Determination Letter showing approval of your accounting system. An Other Transaction for Prototype requires including a completed OT using the Model OT for Prototype from the DARPA Small Business site, plus completed OT Certifications, both loaded in Volume 5, with at minimum the color-coded areas completed and redlines with explanations for any article you wish to negotiate. Firm-fixed-price requires no additional action.
Templates are mandatory
Templates for Volume 2 Technical Volume and Volume 3 Cost Volume are provided as attachments on the DARPA Small Business website. Use of the DARPA Cost Proposal template is mandatory.
Technical and Business Assistance
Phase II awardees may request up to $25,000 per Phase II project. TABA funding is in addition to the cost ceilings and is not subject to profit or fee. Requests will be reviewed by the respective contracting office or specialist at time of award.
For this topic, cybersecurity assistance is directly relevant given the ATO requirement flagged in Phase III, and market validation with civilian emergency management buyers supports the dual-use requirement.
Questions and the FAQ
DSIP Topic Q&A will not be available for these DARPA topics. Technical questions must be submitted by October 14, 2026, by email to SBIR_BAA@darpa.mil with the topic number in the subject line, including the name, email address, and telephone number of a point of contact. Questions submitted within seven calendar days of the proposal due date may not be answered. DARPA posts a consolidated Frequently Asked Questions document under the topic number summary on its Small Business site, updated on an ongoing basis until one week prior to the proposal due date.
DARPA will not accept late proposals.
Classification, marking, and registrations
All proposals are required to be UNCLASSIFIED or CUI. Do not include any classified information in your proposal submission. Do not include any proprietary information on the Proposal Coversheet in Volume 1.
Proposal titles, abstracts, anticipated benefits, and keywords of proposals selected for contract award will undergo a DARPA Policy and Security Review and are subject to revision or redaction by DARPA. Final approved versions may appear on the DoW SBIR/STTR awards website and the SBA's award website at sbir.gov/awards.
Proposers should ensure they have an accurate and active entity registration on SAM.gov. Those engaging in ITAR or CUI work for DARPA must have CMMC Level 2 certification, and the projected requirement for this topic is Level 2 with self-assessment. DARPA points to sprs.csd.disa.mil/nistsp.htm and notes Project Spectrum at projectspectrum.io as an assistance resource.
Venture capital, hedge fund, and private equity ownership
Proposers that are more than 50 percent owned by multiple venture capital operating companies, hedge funds, private equity firms, or any combination of these as set forth in 13 CFR 121.702 are eligible to submit proposals in response to DARPA topics advertised within this BAA. Three conditions apply: register with the SBA Company Registry Database before submitting; submit the Majority-Owned VCOC, HF, and PEF Certification, with the SBIR VC Certification available on the DARPA Small Business site, in Supporting Documents Volume 5; and immediately notify the Contracting Officer, register in the appropriate SBA database, and submit the required certification if you enter that ownership class after submitting but before receiving a funding agreement.
Evaluation and selection
All proposals will be evaluated in accordance with the evaluation criteria listed in the DoW SBIR Program BAA. DARPA will conduct an evaluation of each conforming proposal. Proposals that do not comply with the requirements detailed in this BAA and the research objectives of the corresponding topic are considered non-conforming and are therefore not evaluated nor considered for award.
Using the evaluation criteria, the Government will evaluate each proposal in its entirety, documenting the strengths and weaknesses relative to each evaluation criteria, and based on those will determine the proposal's overall selectability for funding. Proposals will not be evaluated against each other but on their own individual merit.
A selectable proposal is one where the strengths of the overall proposal outweigh its weaknesses, with no accumulated weaknesses that would require extensive negotiations or a resubmitted proposal. A non-selectable proposal is one where the strengths do not outweigh its weaknesses.
Proposing firms will be notified of selection or non-selection status within 90 calendar days of the closing date of the BAA. The Corporate Official indicated on the Proposal Cover Sheet will be notified by email. In accordance with the SBA SBIR/STTR Policy Directive, Appendix I, paragraph 4, subparagraph (d), DARPA will provide a technical evaluation narrative to the proposer for each proposal submitted in response to a topic. An informal feedback session may additionally be requested via email at sbir@darpa.mil, provided at the sole discretion of DARPA.
Company Commercialization Report information will not be considered by DARPA during proposal evaluations.
Protests regarding the selection decision should be submitted, as prescribed in FAR 33.106(b) and FAR 52.233-3, to DARPA Contracts Management Office, 675 N. Randolph Street, Arlington, VA 22203, by email to CMO_SBIRProtests@darpa.mil and sbir@darpa.mil.
Post-award support
DARPA provides Transition and Commercialization Support Program services to Phase II and DP2 awardees upon contract execution at no cost to awardees. Awardees may also be eligible for the Embedded Entrepreneurship Initiative, an invitation-only program at DARPA's sole discretion, typically no more than $310,000 per awardee over the duration of the award, supporting a Senior Commercialization Advisor relationship, investor working group connections, and hiring an embedded entrepreneur to execute a Go-to-Market strategy.
The References
Two, both from the military medical literature rather than the modeling literature.
Quinn M.T., et al. (2024). Automating the Survival Chain and Revolutionizing Combat Casualty Care, Human-Technology Teaming on the Future Battlefield. Military Review.
Butler FK, Bennett B, Wedmore CI. Tactical Combat Casualty Care and Wilderness Medicine: Advancing Trauma Care in Austere Environments. Emergency Medicine Clinics of North America. 2017 May;35(2):391-407.
That both references are clinical and doctrinal rather than computational is a signal. DARPA is not steering you toward a modeling method. It is telling you to understand combat casualty care and the survival chain, and leaving the operations research to you. Butler is a foundational Tactical Combat Casualty Care author, and the Quinn paper on human-technology teaming in the survival chain is the conceptual frame for a decision aid that assists rather than replaces the medical planner.
Timeline and What to Do When
The dates
Topic opens: September 23, 2026
Technical question deadline: October 14, 2026, to SBIR_BAA@darpa.mil with the topic number in the subject line
Proposal deadline: October 21, 2026. DARPA will not accept late proposals
Selection notification: within 90 calendar days of BAA close
Period of performance: unresolved. 12 months per the index, 18 months plus a 6 month option per the narrative
A working backward plan
Before September 23. Submit the period of performance question to DARPA immediately, since it affects everything downstream. Download the mandatory DARPA Volume 2 and Volume 3 templates. Read the FAQ and keep rechecking it. Read both cited references. Assemble your feasibility package against the seven-item list plus the preliminary data requirement. Identify your data sources and be specific about theater, casualty, medical, natural, and virtual data, and about organic versus synthetic. Line up military users for the four prototype evaluations, because four different user groups is a real coordination burden. Decide your contract type and prepare the corresponding documents. Confirm SAM registration and your CMMC Level 2 self-assessment in SPRS. If venture-backed, register with the SBA Company Registry and obtain the SBIR VC Certification.
September 23 through October 5. Draft the 20 page white paper and 15 slide deck. Structure the white paper around the DDIL constraint, the casualty and needs prediction engine, the response option benefit metric as a function of time, dynamic uncertainty quantification, and the four-prototype iterative plan. Address civilian integration and DoD planning tool integration, both of which are stated requirements.
October 6 through October 14. Build the cost volume in the mandatory template to whichever period of performance DARPA confirms. Price four prototype builds and four user evaluation events, data acquisition or synthesis, and the tabletop exercise support.
October 15 through October 18. Assemble Volume 5 with contract-type documents and certifications, complete Volume 7 and the Volume 4 CCR, and run compliance: 20 page white paper, 15 slide deck, unclassified or CUI only, no proprietary information on the coversheet, mandatory cost template.
October 19 through October 20. Submit and certify in DSIP.
Frequently Asked Questions
What is DARPA SBIR topic DPA26BZ06-DV027?
DPA26BZ06-DV027 is a DARPA SBIR Direct to Phase II topic titled "Casualty Operations and Resource Prediction Software (CORPS)," released under the DoW 2026 SBIR Broad Agency Announcement, Release 6. It seeks a software tool to predict casualty and patient streams and needs following large scale medical emergencies in austere environments, and to project the lifesaving potential of various response options with limited or no access to real-time data or communications.
How much funding is available, and for how long?
The topic index states $750,000 over 12 months with no options. However, the topic narrative and milestone tables describe an 18 month base period plus a 6 month option period with milestones running through Month 24. These conflict, and the discrepancy needs to be resolved with DARPA before you finalize a cost volume or milestone plan.
How should I handle the schedule conflict?
Submit the question to SBIR_BAA@darpa.mil with the topic number in the subject line, well before the October 14 deadline, and watch the consolidated FAQ. Because DARPA treats non-compliant proposals as non-conforming and does not evaluate them, this is not a cosmetic issue. Absent an answer, the safer construction is to propose to the index figures, since the index is the controlling award structure table, while showing how your plan maps onto DARPA's six-milestone base structure compressed to the funded period.
When is the proposal deadline?
October 21, 2026. DARPA will not accept late proposals. Note the separate technical question deadline of October 14, 2026.
Can I submit a Phase I proposal?
No. This topic is soliciting Direct to Phase II proposals only, and the offeror shall provide detail and documentation demonstrating the accomplishment of a "Phase I-like" effort demonstrating feasibility and proof-of-concept.
What feasibility documentation is required?
DARPA lists seven things a demonstration of feasibility may include: conceptual characterization of the complete product; relevant use cases, required data categories, and anticipated final capabilities; leveraged 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 supporting the above; and design specifications for any computational or software components of a prototype. Separately and not optionally, proposals should contain preliminary data, published or unpublished, supporting the rationale for the development of the candidate products.
Is the feasibility bar lower than on other DARPA topics in this release?
Notably so. This topic asks for conceptual characterization, methodology, design specifications, and preliminary data rather than a validated working prototype or fielded system. That opens it to modeling, analytics, and operations research teams with strong underlying science and a credible design. If you have published casualty modeling, medical logistics optimization, or mass casualty operations research, read the requirement before assuming you are out of scope.
What is the DDIL constraint?
Crisis action decisions must be made in much shorter time frames than strategic planning, using sparse, low-quality situational data that cannot be verified due to lack of secure communications and denied, disrupted, intermittent, and limited-bandwidth states. The topic requires that proposed approaches be adaptable to variable levels of communication capability and medical care, which means your tool must degrade gracefully and produce usable output at different confidence levels depending on connectivity.
What are the three core functions?
Automated prediction of casualty and 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. The third is the differentiator, because it converts a subjective judgment about medical benefit into a quantitative one.
Does the tool have to work in the civilian sector?
Yes. Solutions must have the potential for use in the civilian sector, meaning integration with civilian networks and infrastructure, as well as integration into existing DoD planning tools. Both integrations are stated requirements, not commercialization aspirations.
What technology readiness level must I start at?
Offerors should only propose products at or above Technology Readiness Level 2.
How many prototypes must I 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 milestone table names Prototype 1 through Prototype 4 at Months 8, 11, 15, and 18 respectively, each with a presentation and demonstration.
What are the four prototypes for?
Per the milestone table, Prototype 1 is the technical baseline and decision optimization prototype integrating casualty prediction with medical resource allocation and response optimization to evaluate alternative Courses of Action. Prototype 2 is decision support and interaction, adding an interactive interface with user-defined constraints and dynamic uncertainty quantification. Prototype 3 is the integrated operational prototype demonstrated in a tabletop exercise. Prototype 4 is the operational prototype demonstration with the Phase III transition strategy.
What is dynamic uncertainty quantification and why does it matter?
It appears both in the Prototype 2 milestone, which requires a dynamic uncertainty and confidence metric demonstrated, and in the Phase III strategy requirement. Because the whole premise is decision-making on sparse, unverifiable data, quantified uncertainty is what makes the output trustworthy rather than a false-precision number. Treat it as a core feature rather than a refinement.
What data sources should I plan for?
The topic names anticipated data sources including theater, casualty, medical, natural, and virtual, and types including organic versus synthetic. It also requires you to outline required data, data sources and environments, data quality management, and model development design and integration. The M2 milestone requires validating the baseline casualty prediction engine using representative military and civilian datasets with varying data completeness.
What testing is expected?
The proposal shall describe planned prototype design, product development, testing, and validation of the prototype product in table-top like exercises, relevant to the requirements of medical command and control functions in austere and contested environments. The M5 milestone requires a successful tabletop exercise completed.
How long can my technical volume be?
This topic uses the White Paper and Slide Deck format. The white paper shall not exceed 20 pages and the slide deck shall not exceed 15 slides. Refer to Appendix B, DARPA Direct to Phase II Instructions, for the content of each element and the commercialization strategy.
What happens in Phase III?
Phase II work will result in a final phase funded by sources other than a Federal government SBIR Program, and Phase III awards may be made by any Government entity without further competition, creating a sole-source-like pathway. Phase III matures the prototype into an operational decision-support capability, potentially transitioning to an Acquisition Program managed by Service Product Developers for inclusion into Service-specific mobile applications. Deployment will require appropriate cybersecurity certifications and the ability to join an existing Authority to Operate or obtain a separate ATO.
Do I need to think about an ATO?
Yes, though not in Phase II. Phase III deployment requires appropriate cybersecurity certifications and the ability to join an existing ATO or obtain a separate one, and the O3 option milestone asks for a preliminary integration and cyber security strategy documented. Building toward that from the start is better than retrofitting.
Can I ask questions through DSIP Topic Q&A?
No. DARPA states DSIP Topic Q&A will not be available for these topics. Technical questions go to SBIR_BAA@darpa.mil with the topic number in the subject line by October 14, 2026. Questions submitted within seven calendar days of the due date may not be answered. DARPA posts a consolidated FAQ, updated until one week before the due date.
Do I have to choose a contract type?
Yes. Proposers must state their requested contract type. DARPA may award FAR-based firm-fixed-price or cost-plus reimbursement contracts, or Other Transactions for Prototype under 10 U.S.C. 4021. Cost-plus requires your DCMA Final Determination Letter showing accounting system approval. An OT requires a completed Model OT plus OT Certifications in Volume 5. Firm-fixed-price requires no additional action.
Is the cost template mandatory?
Yes. Templates for Volume 2 and Volume 3 are on the DARPA Small Business website, and use of the DARPA Cost Proposal template is mandatory.
Are venture capital backed companies eligible?
Yes. Proposers more than 50 percent owned by multiple venture capital operating companies, hedge funds, private equity firms, or any combination as set forth in 13 CFR 121.702 are eligible, subject to registering with the SBA Company Registry Database before submitting, submitting the Majority-Owned VCOC, HF, and PEF Certification in Volume 5, and notifying the Contracting Officer if you enter that class after submitting but before award.
How will my proposal be evaluated?
Against the evaluation criteria in the DoW SBIR Program BAA. DARPA evaluates each conforming proposal in its entirety, documenting strengths and weaknesses relative to each criterion, then determines overall selectability. Proposals are not evaluated against each other. A selectable proposal is one where strengths outweigh weaknesses with no accumulated weaknesses requiring extensive negotiations or resubmission.
Will I get feedback if not selected?
Yes. DARPA will provide a technical evaluation narrative to the proposer for each proposal submitted in response to a topic, per the SBA SBIR/STTR Policy Directive. An informal feedback session may additionally be requested via sbir@darpa.mil, at DARPA's sole discretion.
What is the commercial application?
The product will provide a similar capability for the planning of response to non-military emergency events, for example following natural disasters or war. Combined with the stated requirement to integrate with civilian networks and infrastructure, the buyers are emergency management agencies, hospital systems and trauma networks doing surge planning, and disaster response organizations.
Who do I contact with questions?
The DARPA Small Business Programs Office at SBIR_BAA@darpa.mil for both program administration and topic technical questions, with the topic number in the subject line. DSIP technical support at DoDSBIRSupport@reisystems.com with a copy to SBIR_BAA@darpa.mil, Monday through Friday 9:00 a.m. to 5:00 p.m. ET. DARPA also offers free resources through DARPAConnect at DARPAConnect.us.
Positioning Advice for Companies Considering This Topic
Resolve the period of performance first. Twelve months with no options versus eighteen months plus a six month option is a factor-of-two difference in scope, staffing, and price. Ask DARPA before you write, because a proposal built to the wrong structure risks being found non-conforming.
Recognize that this is a softer feasibility bar than its neighbors. Several topics in this DARPA release demand validated fielded prototypes. This one asks for conceptual characterization, methodology, design specifications, and preliminary data. Operations research groups, casualty modeling teams, and medical logistics analytics companies who would be ineligible elsewhere should look here.
Make the benefit metric the intellectual core. Predicting casualties is the entry price. Quantifying the lifesaving benefit of each response option as a dynamic function of time is what the topic actually lacks and what decision makers need. Define your metric, ground it in survivability science, and explain how it lets a planner compare a fast partial response against a slower complete one.
Design for degradation, explicitly. The DDIL constraint means your tool must work at full connectivity, at intermittent connectivity, and at none. Show three operating modes with the confidence bounds each produces. A proposal that assumes data availability has misread the topic's central premise.
Make uncertainty quantification visible in the interface. Prototype 2 requires a dynamic uncertainty and confidence metric demonstrated, and Phase III requires dynamic uncertainty quantification to support operational decision-making. A planner who cannot see how much to trust a projection will not use it. This is an interface problem as much as a statistical one.
Line up four different military user groups now. The four-prototype requirement specifies different military user evaluations, and each prototype has a presentation and demonstration milestone. Access to military medical planners for four separate evaluation events is a coordination burden that will not appear from nowhere at Month 8. Naming your evaluation partners strengthens the proposal considerably.
Answer both integration requirements. Civilian networks and infrastructure, and existing DoD planning tools. These are stated as requirements. Naming specific DoD planning systems you would interoperate with, and specific civilian emergency management systems, converts a generic claim into a credible one.
Ground the work in TCCC and the survival chain. Both references are clinical and doctrinal, not computational. Butler is foundational Tactical Combat Casualty Care, and the Quinn paper frames human-technology teaming in the survival chain. Using that vocabulary correctly signals that you understand the medical decision the tool supports, rather than treating it as an abstract allocation problem.
Design for a mobile end state. Phase III transition is to Service-specific mobile applications. A desktop-first interface will need rework. Thinking about screen real estate, offline operation, and low-bandwidth sync from Prototype 2 onward is cheap now and expensive later.
Start the cybersecurity story early. CMMC Level 2 self-assessment is the projected requirement, the option period asks for a preliminary cyber security strategy, and Phase III requires ATO. For a tool that will handle casualty data and join a Service network, security architecture is not a late-stage concern.
