Automated Lethality

# Q&A Changes Summary **Key Addition:** New answer to Q1 clarifying Phase III architecture: Government expects approach (b) — a common unifying architecture with target-class-specific engines integrated as separate components, with the complete end-to-end stack requirement applying to the unifying architecture as a whole (not per target class). **Q2 Answer Expanded:** Clarified that all success metrics (accuracy, runtime, memory, embedded hardware constraints) matter equally, and emphasized the solution must be readily transitionable to Phase II/III. **No other substantive changes** — Q3, Q4, and Q5 answers remain identical to previous version.

**Key Changes to Q&A:** Added Q1 clarifying Phase III scope: Government expects a **common architecture/interface** with target-class-specific engines (maritime, mobile, structural) as separate components, not a single generalizing model. "Complete end-to-end stack" requirement applies to the unifying architecture, not per target class. All other Q&As (Q2-Q5, now renumbered Q3-Q5) remain substantively unchanged from previous version.

**Q&A Changes Summary:** Added Q1 addressing three new concerns: minimum target variability expected in Phase I (predefined vs. broader generalization), quantitative success criteria priorities (accuracy, runtime, memory, hardware constraints), and availability of government models/datasets/interfaces. All other Q&As (Q2-Q4) and answers remain substantively unchanged from previous version.

# Q&A Changes Summary **Q1:** Clarified that proposals must provide a **complete end-to-end software stack** during Phase I; modular components integrated with partners are not acceptable. **Q2:** Answered all four sub-questions: - Target effects definition left to proposer (destruction, structural collapse, etc.) - Uncertainty reporting approach is proposer's choice - AI/software origin restrictions are context-dependent (open-source okay; compiled executables problematic); proposers should specify what they plan to use - Phase II seeker access: use freely available drone software for demos **Q3:** Answered all eight sub-questions: - Government lethality simulation tools available upon request - Model granularity/accuracy is proposer's choice (feasibility vs. high-fidelity) - Ancillary target data (dimensions, construction) may be used but shouldn't be assumed in operations - No preferred building type; no Government-provided imagery/data; proposers design their own datasets (exclude civilian residential) - Use drone package for Phase I; avoid specific munitions (classification); engagement choice generation vs. selection is proposer's decision - Solution must be weapon-agnostic, embedded on weapon platform; operational details cannot be discussed (tech push exploratory) - Drone package assumed; electro-optical primary; multi-modal sensor fusion (SAR, LiDAR) viewed favorably - All success measures (target accuracy, lethality prediction, engagement selection, processing time, uncertainty) equally important

Status changed from Pre-Release to Open

**Q&A Changes Summary:** Added Q1 clarifying that proposals may use modular approaches integrated with qualified partners' components rather than requiring independent end-to-end stacks in Phase I. Renumbered previous Q1-Q2 to Q2-Q3. All eight technical questions from Q2 (lethality definition, uncertainty reporting, AI/software restrictions, seeker access, government models/data, model accuracy expectations, target information assumptions, building/weapon/platform specifications, test environments, and success measures) remain substantively unchanged but now appear in Q3.

This Q&A clarifies critical technical ambiguities for applicants: performers must now understand that the government hasn't yet defined key requirements (lethality metrics, model fidelity, test data, weapons specifications, success criteria), meaning applicants have flexibility to propose approaches but must explicitly justify their technical choices and assumptions in Phase I.

New opportunity: Automated Lethality