ASIMOV_FAQs_Version1.3.pdf

Autonomy Standards and Ideals with Military Opera�onal Values (ASIMOV) BAA FAQS Purpose amendment

Administra�ve Ques�ons

1. What is the expected budget for a performer? What is the overall program budget for all performers?

a. Program budget informa�on will not be provided. Proposals should provide a cost that accurately reflects the level of effort the proposer expects to expend in order to meet program goals.

2. How many performers is DARPA expec�ng to award in Phase 1?

a. Performers will be funded based on the available program funding and the quality of proposals received.

3. According to the published program schedule, it appears that program Phase 1 will not begin un�l mid/first quarter 2025, 13-14 months from now?

a. The Schedule in the BAA is an es�mate. ASIMOV expects to kickoff in Q4 of CY 2024

(Q1FY25), 9-10 months from now.

4. Is U.S. ci�zenship required to be performers of ASIMOV?

a. ASIMOV is a CUI program. Foreign performers may par�cipate if they can comply with CUI requirements. Please see Submission Informa�on and Special Considera�ons in the Broad Agency Announcement (BAA).

5. Is DARPA looking for well-formed teams to submit a proposal?

a. Proposals will be evaluated against the criteria as published in the BAA. Please see

Sec�on II: Evalua�on Criteria in the BAA.

Responsible Ar�ficial Intelligence (AI) Principle Ques�ons

6. How much coordina�on do you expect across the performer team and technical community?

Are all ethical AI framework teams independent of each other? There was a men�on of workshops.

a. Under the ASIMOV program, performers will pursue their own solu�ons and approaches. However, program-wide reviews will enable the performers to present their progress to other ASIMOV performers and stakeholders. The Technical Community Panel (TCP) enables sharing of informa�on in an open-source format. Please see sec�ons on the TCP in the BAA.

7. RAI principles may not be directly decomposable into Interna�onal Humanitarian Laws/Rules of Engagement (IHL/ROEs). Is the emphasis more on RAI principles or IHL/ROEs?

a. RAI principles and IHL/ROEs should both be considered in the AWS benchmarks. Please see Sec�on I: Funding Opportunity Descrip�on and 1.1. Program Overview.

8. Is it desired to have AI principles other than the 5 DoD ethical principles?

a. Please see sec�on 1.1.1 Phase I Base: Autonomous Weapon System (AWS) Benchmark

Reference Feasibility and Decomposi�on, bulleted list (2) in the ASIMOV BAA: “Describe, if applicable, alternate/addi�onal ethical principles in addi�on to the five DoD RAI ethical principles….”

9. Opera�onalizing DoD RAI principles has a large design space. Are there specific ethical systems or reasoning packages that will be used by all performers?

a. ASIMOV is seeking a diversity of thought on how the RAI principles can be decomposed quan�ta�vely and how benchmarks can be developed. Please see sec�on 1.1.1 Phase I Base: AWS Benchmark Reference Feasibility and Decomposi�on, bulleted list (1) in the ASIMOV BAA: “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….”

Ethical, Legal, and Societal Implica�ons (ELSI) Ques�ons

10. Can the official ASIMOV ELSI group members be part of performers teams?

a. No.

11. Can you clarify the ELSI solicita�on process? When will this be released? Is the ELSI solicita�on open for compe��on?

a. ASIMOV ELSI solicita�on is not part of the ASIMOV BAA.

Genera�ve Environment Ques�ons

12. What kind of fidelity is the ASIMOV program aiming for in modeling and simula�on for the genera�ve environment?

a. Under the ASIMOV program, the genera�ve environment should be sufficiently detailed to explore the ethical scenarios under study. Please see sec�on 1.1.1 Phase I Base: AWS Benchmark Reference Feasibility and Decomposi�on, bulleted list (3) -(5) in the ASIMOV BAA: “Document each RAI ethical principle's (i.e., for Responsible, Equitable, Traceable, Reliable, Governable)…”

13. Could you please define generated scenes for Instances? Are they instantaneous snapshots, sequences of snapshots or videos? Are scenes 3D?

a. Under the ASIMOV program, the genera�ve environment should be sufficiently detailed to explore the ethical scenarios.

14. Are proposers expected to validate the genera�ve simula�on environment?

a. The performer is not required to validate the physical phenomenology of the genera�ve simula�on environment. However, the performer’s genera�ve simula�on environment must be able to meet the required performance set under Sec�on 1.1.1 Phase I Base:

AWS Benchmark Reference Feasibility and Decomposi�on, bulleted list (3) -(5) in the ASIMOV BAA. The ethical valida�on of the performer’s technical approach including the performer’s genera�ve simula�on environment will occur via a combina�on of ELSI group and Government IV&V team.

15. Is the goal to have a common genera�ve environment at the end of the program? How do we deal with differences in developed environments across performers?

a. No. Performers will be developing their own genera�ve environments.

16. Are performers responsible for genera�ng use cases as well as the genera�ve environment?

a. Performers are responsible for genera�ng use cases for internal tes�ng. In addi�on, please see answers to Ques�ons 14, 15, and 16.

17. Is the Government providing the synthe�c environment scenarios?

a. The Government team will guide the scenario development. The performers will develop the synthe�c data/scenes required for the scenarios as well as the genera�ve environment itself. Please see Program Structure sec�on in the BAA, numbered list 2) and 3): “ASIMOV Government Independent Verifica�on & Valida�on (IV&V) Team, who will provide input to Instances…”

18. Will the proposed genera�ve environment be required to accommodate new use cases poten�ally from the government or other performers?

a. Yes. Please see in Program Structure sec�on in the BAA for more detailed descrip�on: “A key output of ASIMOV is the development and ini�al valida�on tes�ng of a genera�ve modeling environment in which itera�ve tes�ng…”

19. Do data rights mater on the genera�ve environment?

a. Please see Sec�on II: Evalua�on Criteria on data rights and intellectual property in the

BAA: “In addi�on, the evalua�on will take into considera�on the extent to which the proposed intellectual property (IP) rights structure will poten�ally impact the Government's ability to transi�on the technology.”

20. What kind of scenario environments will ASIMOV explore? Urban? Jungle? Desert? What does diversity of scenarios mean?

a. Please see Technical Approach sec�on of the BAA.: “The scenario environment must allow the performer to 1) explore self-proposed or Government provided "what if?"

ethical scenarios, 2) rapidly collect the required sta�s�cal data volume to generate performer- and program-metric scores, and 3) interface with algorithms to measure the ethical performance of specific Approaches.”

21. What will be involved in the data collec�on by the IV&V team?

a. The Government may conduct Phase II data collec�ons to correlate the genera�ve environment tool's synthe�c Instance data with real world sensor data. The Government IV&V Team will conduct data collec�ons based on program Instances and Approach algorithm needs in support of program metrics evalua�on. In addi�on, try to correlate the genera�ve environment tool's Instance data with real world sensor data which may include the electro-op�c / infrared (EO/IR), laser detec�on and ranging (LADAR), and radar domains. Please see Program Structure and Technical Approach sec�on.

22. Is the synthe�c data for the different sensor modali�es – sensor or aircra� dependent? Or is it more generic sensing data?

a. It is more generic sensing data. Please see Technical Approach sec�on on synthe�c data in the BAA: “Performers will develop a genera�ve modeling environment to rapidly explore the ethical difficulty of Instances…”

23. Do you have a feel for the volume of data that will need to be generated and for how quickly new environments will need to be generated?

a. No. ASIMOV does not have a defined value for the volume of data to be generated or how quickly the environments will need to be generated. The genera�ve environment should be able to assess Instances sufficiently rapidly to produce a coverage metric. In addi�on, please see the answer to Ques�on 22. Since each performer is required to develop a genera�ve environment to explore self-proposed “what-if?” ethical scenarios and collect the required sta�s�cal data volume to generate program-metric scores, each performer must propose its own “what-if?” scenarios and es�mate size of data based on the proposed approach.

24. What physical scale (building, small town, base, large city) will be focused on in ethical tes�ng?

a. ASIMOV benchmarks should be able to cover scales as appropriate to X-to-ground scenarios. In addi�on, please see answers to Ques�ons 22 and 23.

General ASIMOV Ques�ons

25. Does a successful proposal require experience or access to specific weapons systems? Are proposers at a disadvantage w/o this? Are general vignetes acceptable? Should proposers consider teaming with a weapons pla�orm provide?

a. Proposals will be evaluated against the criteria as published in the BAA. Please see the Evalua�on Criteria sec�on in the BAA. General vignetes are acceptable.

26. This seems to be geared towards AI/autonomy simula�on industries. Is there room for a mission engineering firm with CONOPS decomposi�on exper�se (a firm that does not build AI/autonomy)?

a. ASIMOV is seeking a diversity of thought in measuring the ethical readiness of AI/Autonomy systems with military opera�onal values. There is no specific industry category. Please see Program Overview and Background sec�on.

27. Will all performers be evaluated on the same set of Instances and Approaches? If not, how will they be compared? Is there a subjec�ve por�on to evalua�on?

a. Performers are free to test their benchmarks internally on self-defined Instances/Approaches. ASIMOV sponsored metric tes�ng will be evaluated on the same set of Instances. Performers will not be evaluated against each other. Please see sec�on

1.1.1 Phase I Base: AWS Benchmark Reference Feasibility and Decomposi�on, bulleted list (1) in the ASIMOV BAA: “Develop and demonstrate a RAI ethical principles decomposi�on appropriate for an AWS…”

28. In the BAA, the ASIMOV focus area is shown as the air to ground domain. Is it no�onal or the actual focus domain? Is the scope restricted to X-to-ground?

a. Please see Table 2, Figure 1, and Program Descrip�on sec�on in the BAA for ASIMOV focus and scope of the program.

29. Related to mul�-valued ground truth, is it referring to disagreement between the human annotators or mul�ple AI principles per scenario?

a. Depending on the specific Instance, the ground truth will depend on the rules of engagement (ROE).

30. Can you comment on whether the program is more biased towards informing ARLs for AWS to enable DOT&E, or toward more general tools for ARLs for any autonomy system?

a. ASIMOV’s focus is a Reference Benchmark for AWS, with specific Instances of X-to-ground scenarios. Please see Program Overview and Background sec�on.

31. Are evalua�ons of long-term learning in AWS systems in scope, vs. single use adapta�on?

a. Please see sec�on 1.1.1 Phase I Base: AWS Benchmark Reference Feasibility and

Decomposi�on, bulleted list (1) to (7) in the ASIMOV BAA for specific scope of the ASIMOV Phase I. Please see sec�on 1.1.2 Phase II Op�on: RAI Benchmarking Technology

– Opera�onal Refinement, bulleted list (1) to (6) in the ASIMOV BAA for specific scope of the ASIMOV Phase II.

32. Is there a minimum number of test ports or algorithms to provide?

a. The number of test ports should be sufficient to access the ethical performance of the

AI/autonomy system or algorithm. Please see sec�on 1.1.1 Phase I Base: AWS Benchmark Reference Feasibility and Decomposi�on in the BAA for more informa�on.

33. Should proposers contextualize their solu�ons with specific use cases or Instance implementa�ons?

a. Yes, to the extent possible exemplar uses cases/Instances that will be used for internal tes�ng/development should be detailed in the proposal.

34. There seems to be a big emphasis on rich, accurate sensor ATR performance, but that’s not everything that goes into the ethical behavior of a LAWS. Is that meant as a representa�ve (e.g., deep dive as illustra�ve of the kind required in other areas) or am I over-complica�ng the problem rela�ve to your concep�on and intent?

a. ATR performance was provided as an illustra�ve example, not an all-inclusive example into the ethical considera�ons ASIMOV benchmarks must consider.

35. Is there any interest/emphasis here on “extra” U.S. ethical standards and behaviors (e.g., NATO/UN)

a. The focus of ASIMOV is on U.S. military opera�onal values.

36. Should performer systems be capable of discovering alterna�ve courses of ac�on that tested autonomy agents did not choose?

a. No, this is outside the scope of ASIMOV. ASIMOV is not developing an autonomous system.

37. Genera�ve environment and ethical AI decomposi�on, what takes priority?

a. Both need to be addressed, please review the Technical Approach and Deliverables sec�on in the BAA.

38. Commercial-off-the-shelf (COTS), Government Furnished Equipment (GFE), on the shelf equipment, etc., what is allowed?

a. Based on the proposer’s approach, all equipment is allowed to be proposed. Proposers will need to document all equipment required for their approach in their proposals and all appropriate informa�on regarding the equipment such as but not limited to cost and ownership organiza�on of the GFE.

39. Does this program address adversary countermeasures against ethical performances?

a. ASIMOV benchmarks will need to represent real-world condi�ons and address military opera�onal values. Please see the sec�on on military opera�onal values in the BAA, and the ASIMOV CUI guide.

40. Is this program bounded by military opera�onal values?

a. Please see Sec�on I: Funding Opportunity Descrip�on for the defini�on and descrip�on of military opera�onal values in the BAA.

41. Does the ASIMOV benchmark look like a series of tests or more of a rubric?

a. Please see the sec�on on Technical Approach and Deliverables in the BAA for informa�on on benchmarks.

42. Open System Architecture (OSA) vs. Weapons Open System Architecture (WOSA)?

a. ASIMOV will be taking the OSA approach, not WOSA. Please see the Program

Background and Technical Approach sec�on on OSA in the BAA.

43. Will ASIMOV be looking at fully autonomous systems or semi-autonomous systems (human-in-the-loop/human-on-the-loop)?

a. ASIMOV benchmarks should be applicable to mul�ple levels and concepts of autonomy.

44. Will ASIMOV look into large language models?

a. ASIMOV is not developing an autonomous system. ASIMOV does not restrict approaches toward the development of benchmarks. Please see the Program Background, Technical Approach and Deliverables sec�on on benchmarking in the BAA.

Algorithm Ques�ons

45. Are performers expected to adapt algorithms to run against generated use cases/scenes?

a. ASIMOV will not fund Approach algorithm development.

46. Is the use of genera�ve algorithms required?

a. ASIMOV benchmarks should be capable of assessing any AI/autonomous system, whether it is genera�ve or not.

47. Will the Government provide guidance on autonomous systems and algorithms to use as the “model under test”?

a. ASIMOV benchmarks must be applicable to any AWS that can be considered for an X-to-ground Instance.

48. Do proposers need to provide algorithms for input? Should proposers iden�fy algorithms in the proposal? Such as model algorithms?

a. Please see the Technical Approach sec�on on the concept of model algorithm and test port in the BAA and sec�on 1.1.1 Phase I Base: AWS Benchmark Reference Feasibility and Decomposi�on, bulleted list (1) in the ASIMOV BAA: “Develop and demonstrate a RAI ethical principles decomposi�on appropriate for an AWS…”

Metrics Ques�ons

49. Will uncertainty be an important theme of the project?

a. Yes. Please see repeatability metric in the Program Metrics sec�on and Table 7 in the BAA. As noted, the Government expects some condi�ons may contribute significantly more to the accuracy of the benchmarking performance while causing different levels of uncertainty. Being able to have a good handle on these will be able to strengthen the performance of repeatability score.

50. For government-developed metrics/coverage elements, are they expected to change throughout program execu�on or are they fixed early before start?

a. Please see sec�on 1.2 Program Metrics in the BAA.

51. Does “coverage” represent the % of scenarios explicitly defined in one’s proposal, or the ability of the system to return value for some % of individual Instances?

a. The ability of the system to return a value for some % of individual Instances. Please see

Coverage metric in Table 7 in the BAA.

52. Can I propose addi�onal metrics?

a. Yes. Proposers are free to propose addi�onal metrics to assess their internal development.

53. Can you elaborate on compactness versus coverage?

a. Please see sec�on on Program Metrics in the BAA on compactness and coverage.