ASIMOV_FAQ_SecondRound_final.pdf

1. Are performers expected or required to have Ethical, Legal, and Societal Implica�ons (ELSI) subject mater experts on their team?

a. No. DARPA envisions having ELSI experts assist the ASIMOV Program Manager. See the sec�on on the ELSI group in the Broad Agency Announcement (BAA). Performers are free to have ELSI subject mater experts on their teams.

2. Will IDA ELSI group be available for individual team interac�ons or consulta�on?

a. The ELSI group has not been established at this �me and is being pursued separately from the ASIMOV BAA (HR001124S0011). Please see the sec�on on the ELSI group in the BAA. It is envisioned that the ELSI group POC will be available on a weekly basis during the program execu�on phase.

3. Is improving and refining physics-based engines within the scope of the program?

a. The focus of ASIMOV is to develop benchmarks. The genera�ve environment is also a key component of the program. Please see the sec�on on Program Objec�ves, Technical Approach, and Deliverables, Phase I and II, in the BAA. All proposed approaches and technologies will be reviewed in accordance with the Evalua�on Criteria stated in the BAA.

4. Will the program emphasize systema�c genera�on of all scenarios that cover a space of ethical situa�ons? Or will a smaller set of subject mater expert-designed scenarios be used?

a. Both are within scope of the program depending on the proposers' approaches.

5. With human operator knowledge and employment of an autonomous system, how do we apply and implement those considera�ons into the simula�on? Is that within scope of ASIMOV?

a. It is up to the proposer to decide whether to include and implement operator knowledge and employment of an autonomous system into their proposed genera�ve environment. The objec�ve of the benchmarks is to represent the ethicality of the scenario and therefore test a system. ASIMOV makes no assump�ons concerning human operator involvement.

6. What do you mean by the reference's ability to "accurately" measure instances? Who determines? How will ASIMOV get ground truth? For example, 1000's of instances?

a. Coverage is defined as the observability of all condi�ons in the benchmark at a given ARL level. The Government team will evaluate if demonstrated coverage of proposed benchmarks is acceptable. The Coverage metric sec�on of the BAA provides answers to a ques�on of "does the benchmark cover the breadth of cases it is designed to represent/test(?)". "(A)s an illustra�ve example, if 1,000 Instances are assessed in a Monte Carlo fashion and the Reference is able to accurately measure (i.e., correctly, or without outpu�ng an error) 800 of those Instances, then the Coverage is calculated as 800/1000 or 80%." Here, in the example, Instances can be comprised of 100's observable condi�ons. In the Reference level, it can be comprised of 1000's observable condi�ons at a given Autonomy Readiness Level. While the final arbiter of ground truth will be the Government IV&V and ELSI groups for these observable condi�ons, the performer is responsible for developing a benchmarking system that can correctly account for 80% or higher of these observable condi�ons. Please see sec�ons on the Metrics in the BAA.

7. Are benchmarks fully automated?

a. That is up to the proposer's approach.

8. Will there be human tes�ng?

a. No.

9. Will ASIMOV look into ICDs?

a. We assume ICD stands for Interface Control Documents. ICD development is outside the scope of ASIMOV.

10. What does success look like for ASIMOV? Tool set or a design of a tool, what is the end deliverable?

a. Please see the Program Objec�ve and Deliverables sec�on, Phase I and II, in the BAA.

11. How many algorithms will the Government make available?

a. Please see sec�on 1.1.1 Phase I Base: AWS Benchmark Reference Feasibility and Decomposi�on, bulleted list (1) in the ASIMOV BAA: "(1) Develop and demonstrate a RAI ethical principles decomposi�on appropriate for an AWS Reference that is self-tested using performer provided Instances and exis�ng open source or otherwise white box Approach algorithms. The performer shall include requirements for test criteria, test input datasets, observables, and associated trade studies in their system architecture descrip�on of their Reference."

12. What level of ethical reasoning is required or expected in white/gray box algorithms from what is available to avoid low benchmark scoring and coverage?

a. Please see Technical Approach sec�on in the BAA: "For clarity, observables can include the

"decisions" or outputs the approach under test makes plus addi�onal internal informa�on or intermediary steps/reasoning required by the benchmark. This may require future autonomy solu�ons to be gray box at a minimum. To that end, proposals should describe the methods to develop these observables for the en�re lifecycle of the autonomy system (i.e., ini�al development, training, refinement, deployment, use, sustainment, etc.). For Instances, they may pertain to target sensing (e.g., target search, iden�fica�on, recogni�on, etc.), context of the scene (e.g., adjacency, cluter, keep out zones, etc.), engagement reasoning (e.g., collateral damage, proposal force, etc.) and other relevant considera�ons." The proposer must provide appropriate steps of reasoning required to support the proposer's benchmarking methodology.

13. For the genera�ve environment, must all categories of sensor data, electro-op�cal/infrared

(EO/IR); light detec�on and ranging (LADAR); and radio detec�on and ranging/synthe�c aperture radar (RADAR/SAR) be generated? Or only what is required for the given autonomy and "test port" to run an assessment?

a. All sensor modali�es men�oned in the ques�on above are within scope of the program. The genera�ve environment is expected to support all the sensor types listed in the BAA. It is reasonable for the genera�ve environment to only generate modali�es that support a concept under test. For example, a Long-Wave Infrared (LWIR) concept would only require the genera�ve environment to produce LWIR. Please see the sec�on on sensor data in the Technical Approach in the BAA.

14. Is DARPA more interested in benchmarking autonomous systems during mission execu�on or in mission planning?

a. Both are within the scope of the program and contain condi�ons and variables that ASIMOV plans to explore. Please see the Coverage metric in the Metrics sec�on in the BAA and the sec�on on benchmarks in the Technical Approach.

15. Is it desirable to have the ASIMOV solu�ons model the outcome of a strike and include the a�er-ac�on report in scoring the outcome of an autonomous system, e.g. collateral damage? Is it required or desired to render the whole strike event from a third-person point-of-view, specifically post-strike events?

a. ASIMOV aims to explore the ethical scenarios that come with AWSs including a breadth of condi�ons, varia�ons, and complexity as part of the scenario. Rendering Perspec�ve is irrelevant so long as the ethical decomposi�on and benchmarking are not condi�onal to rendering perspec�ves. The benchmark is not intended to evaluate mission effec�veness in terms of post-strike. Please see the genera�ve environment Program Objec�ve, Program Descrip�on and Technical Approach sec�ons in the BAA.

16. Regarding the real-�me considera�ons - the end-strike �meline is very brief, with litle �me to observe the scene, and decide whether to strike or divert and how to divert. Is this effort concerned with the computa�onal cost and �melines of such processing and decision-making onboard the AWS? If so, what are the desired constraints? Similarly, is the real-�me rendering from the simulator required?

a. The ASIMOV program is not concerned with the computa�onal cost of such processing and decision-making. However, we are concerned with the �melines, latency, and uncertain�es of such decision-making steps. ASIMOV aims to develop benchmarks to objec�vely and quan�ta�vely measure the ethical difficulty of future autonomy use-cases and readiness of autonomous systems to perform in those use-cases within the context of military opera�onal values. ASIMOV performers will need to develop prototype genera�ve modeling environments to rapidly explore scenario itera�ons and variability across a spectrum of increasing ethical difficul�es. Please see the sec�ons on benchmarks and genera�ve environment in the Technical Approach in the BAA.

17. Technical Volume, Statement of Work sec�on instruc�ons state: "Provide a detailed task breakdown by Contractor Fiscal Year". Is it acceptable to provide the task breakdown by either Program Year / Phase?

a. Yes. It is not necessary to provide a detailed task breakdown by "Contractor's Fiscal Year" if the task breakdown is provided by DoD Fiscal Year, Program Year, and by Phases.