HR001120S0022.pdf

Broad Agency Announcement

Joint All-Domain Warfighting Software (JAWS)

DARPA Adaptive Capabilities Office (ACO)

HR001120S0022

3 April 2020

TABLE OF CONTENTS

PART I: OVERVIEW INFORMATION

1 Funding Opportunity Description

1.1 Program Overview

1.2 Program Structure

2 Award Information

2.1 General Award Information

2.2 Fundamental Research

3 Eligibility Information

3.1 Eligible Applicants

3.2 Federally Funded Research and Development Centers (FFRDCs) and Government Entities

3.3 Organizational Conflicts of Interest

3.4 Cost Sharing/Matching

4 Application and Submission Information

4.1 Address to Request Application Package

4.2 Content and Form of Application Submission

4.3 Abstract Format

4.4 Full Proposal Format

4.5 Additional Proposal Information

4.6 System for Award Management (SAM) and Universal Identifier Requirements

4.7 Submission Information

5 Application Review Information

5.1 Evaluation Criteria

5.2 Review of Proposals

6 Award Administration Information

6.1 Selection Notices and Notifications

7 Agency Contacts 8 Other Information

9 APPENDIX 1: PROPOSAL SLIDE SUMMARY

10 APPENDIX 2: CLASSIFIED ADDENDUM REQUEST FORM

PART I: OVERVIEW INFORMATION

Federal Agency Name – Defense Advanced Research Projects Agency (DARPA), Adaptive Capabilities Office (ACO) Funding Opportunity Title – Joint All-Domain Warfighting Software (JAWS) Announcement Type – Initial Funding Opportunity Number – HR001120S0022 Catalog of Federal Domestic Assistance Numbers (CFDA) – Not applicable Dates o Posting Date: 3 April 2020 o Abstract Due Date and Time: 24 April 2020 at 3:00 PM EST o Proposers Day: Cancelled o FAQ Submission Deadline: 10 April 2020 o Proposal Due Date and Time: 23 June 2020 at 3:00 PM EST o BAA Closing Date: 23 June 2020 o Estimated period of performance start: 4 November 2020

The DARPA JAWS program will develop a software suite to maximize the effectiveness of military force through theater scale battle management command and control by orchestrating resources in all domains with automation and predictive analytics.

The amount of resources made available under this BAA will depend on the quality of the proposals received and the availability of funds.

Multiple awards are anticipated.

Anticipated funding type: 6.3 Types of instruments that may be awarded -- Procurement contract or other transaction.

Agency Point of Contact

The BAA Coordinator for this effort can be reached at:

HR001120S0022@darpa.mil.

DARPA/ACO

ATTN: HR001120S0022

675 North Randolph Street Arlington, VA 22203-2114

PART II: FULL TEXT OF ANNOUNCEMENT

1 Funding Opportunity Description

This publication constitutes a Broad Agency Announcement (BAA) as contemplated in Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016 and 2 CFR § 200.203. Any resultant award negotiations will follow all pertinent law and regulation, and any negotiations and/or awards for procurement contracts will use procedures under FAR 15.4, Contract Pricing, as specified in the BAA.

The Defense Advanced Research Projects Agency (DARPA) is soliciting innovative proposals to develop a theater-wide, Joint All-domain Warfighting Software (JAWS) suite that orchestrates resources to maximize the efficiency and resiliency of kill webs. Effective, efficient allocation of finite resources, such as sensor coverage, communications capability, target assignments and platforms as a whole, are critical to success in highly contested engagements against peer competitors. This needs to take a holistic, theater-wide view of resource management, lends itself to a highly centralized approach. However, the anticipated emphasis of potential adversaries on disrupting our communications, command, and control infrastructure makes simple highly centralized control architectures vulnerable, consequently requiring innovative solutions that operate across the theater while retaining resiliency.

Therefore, the JAWS program seeks to develop novel approaches that provide comprehensive battlespace awareness and assurance of mission success in a contested environment along with tools encompassing target search through battle damage assessment at a faster decision rate than ever before. Specifically, the focus of JAWS is battle management with dynamic command and control at theater scale with tactical coordination to accomplish goals of target custody and weapon/target pairing for engagements.

Proposed research should investigate innovative approaches that enable revolutionary advances.

Specifically excluded is research that primarily results in evolutionary improvements to the existing state of practice.

1.1 Program Overview

1.1.1 Program Background: See classified addendum

1.1.2 Program Objective

The DARPA JAWS program seeks to develop a software suite to maximize the effectiveness of military force through theater scale battle management command and control with automation and predictive analytics. Sensors, weapons, and decision makers are not assumed to be co-located, and this program considers dynamic coordination of kill webs across the battlespace.

This approach to battle management command and control enables flexibility during execution by empowering decision makers to optimize tasking assignments. The goal of this program is to develop the enabling software for the warfighter to adaptably setup and execute synchronized kill webs encompassing the undersea, sea surface, land, air, space, and electromagnetic domains.

The foundational issues for command and control are sensing, communications, and weapons.

For the purpose of JAWS, sensing is the ability to detect, geolocate, and identify/classify potential targets sufficiently to engage a weapon, which will vary parametrically by domain and target type. Communications in this context is the ability to ensure the appropriate quantity of data can be passed at the right time and latency in order to coordinate the functions necessary to deploy, maintain, and maneuver assets within the environment. The tasking of weapons is the assignment of weapons and target for engagement with a focus on coordination between weapon systems (e.g. surface, land, and electromagnetic). Each of these components have geospatial and temporal variations, and their optimization is the critical challenge to be addressed by JAWS.

Battle damage assessment restarts the cycle and should be considered within sensing. DARPA anticipates performers using these concepts at a minimum when executing the program.

However, other taxonomy approaches could be addressed in proposals provided they encompass dynamic execution of all domain kill chains in a kill web context.

The theater-wide coordination of kill webs represents a scaling problem where technology can augment humans to improve capacity. Traditionally, the military community separates the planning and execution cycles with a focus on centralized planning and distributed execution, which allows a high degree of centralization with high-level planning and proliferated tactical communications for low-level execution. Static separation of responsibilities allows large amounts of autonomy and flexibility within lower echelon units but results in strict hierarchies that are difficult to adapt in evolving situations as the number of targets grow. The result is a military process focused on human intensive task planning and widespread tactical radios with targeting information. One goal of the JAWS program is to develop the software tools that disrupt this trade-off and vary the level of centralization or tactical scope as needed by the decision maker or mission. In order to orchestrate these resources, JAWS desires a distributed command and control structure using dynamic teaming and machine-to-machine interfaces in order to enable a spectrum of centralized and distributed planning and execution combinations.

For example, when few targets and resources are involved, much of the overall battlespace can be pushed to the tactical edge without need for significant coordination. However when large numbers of targets are present over large areas, theater level coordination is needed to enable efficient resource allocation. While human operators are responsible for traditional planning and execution cycles, DARPA seeks to reframe these processes from cyclical to continuous interactions with human operators.

All-domain kill webs result in a wide variety of timescales and latencies to be coordinated during a mission. The surface domain can change on the order of hours, while the air domain can change drastically in minutes. This program specifically considers the need to control all domains within a single architecture. For example, if high-bandwidth, low-latency communications are universally available then globally optimal tactical (e.g. weapon fires) decisions could be made in a centralized location. If systems have high-latency, then some decisions and tactical scope may be pushed down into the system for time sensitive decisions closer to the fight. Similar decentralization may be needed to ensure resilience. JAWS is not intended to prescribe command structures but enable them based on mission need. The JAWS system is inherently a man-machine team and DARPA desires novel approaches that enable real-time orchestration with planning horizons sufficiently large enough to impact overall metrics.

Ultimately, the tools developed in JAWS should support the various speeds needed by decision makers to synchronize kill webs at scale.

The intended users of JAWS are the joint force commanders working across military services and warfare domains (e.g. combatant or joint task force commander) and battlespace owners with control over tasking and objectives (theater or task force components). It is anticipated that select command and control forces at the tactical edge will interface with JAWS for tight coordination. The robotics and artificial intelligence communities have had significant success in planning and control mechanisms that rely on probabilistic or data dependent adaption so DARPA anticipates the key is varying the level of automation with the scale of the problem.

Ultimately, the tools developed in this program should shape warfighting and redefine doctrine.

1.2 Program Structure

The JAWS program is structured to incrementally develop capacities that optimize kill web orchestration. While agile development approaches are encouraged, quarterly releases will be used to synchronize program execution. The program is divided into two phases, each of which will culminate in a demonstration.

The JAWS program has technical areas (TAs) aligned with types of automation and control that span across an entire kill web. Note that software components do not need to be segmented in this manner but proposers should describe how the challenges will be addressed. The use of microservices to allow for continuous integration into the government LVC environment is anticipated. For guidance on DevSecOps and microservices see the DoD Enterprise DevSecOps Reference Design (https://dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Refere nce%20Design%20v1.0_Public%20Release.pdf?ver=2019-09-26-115824-583). DARPA specifically discourages approaches that use a monolithic software architecture.

1.2.1 JAWS Security Overview

The JAWS program anticipates that the development of the software suite will occur at the UNCLASSIFIED and SECRET//NOFORN classification level. Therefore proposers shall ensure all industrial, personnel, and information system processing security requirements are in place and at the appropriate level (e.g., Facility Clearance (FCL), Personnel Security Clearance (PCL), assessment and authorization (A&A)). Additionally, proposers will participate in integration and demonstration events throughout the program with classification at a minimum at the TS/SCI level, therefore proposers should identify personnel cleared to participate in those events.

1.2.2 Program Technical Focus Areas

The program is broken into three technical areas representing 1) orchestration services, 2) predictive analytic services, and 3) operator interfaces. These are shown in Figure 1 and proposals must include all technical areas.

https://dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v1.0_Public%20Release.pdf?ver=2019-09-26-115824-583 https://dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v1.0_Public%20Release.pdf?ver=2019-09-26-115824-583

Figure 1: Technical Area Functions

1.2.2.1 Technical Area 1 (TA-1): Orchestration Services

The generation of own force course of action recommendations and task dissemination is the focus of the Orchestration Services, Technical Area 1 (TA-1). Static, centralized decision hierarchies have limited flexibility in reassigning resources. Fully distributed systems are often too complex or computationally intractable. In this program, globally optimal command and control solutions should be traded for practical considerations, such as running a planning or orchestration service at different timescales on different platforms to allow decomposition of objectives from strategic to tactical processes. DARPA is seeking technical approaches to dynamic planning and control of taskable resources capable of considering current joint force plans, such as target sets, space de-confliction orders, and rules of engagement in order to form dynamic teams. Since time sensitive actions must be executed at fast control loops, such as within tactical command and control nodes, the architecture should account for these timeline requirements and resiliency.

The automated recommendation engine considers ensuring custody of targets throughout a kill web, maximizing effectiveness with target assignments, and ensuring safety from fratricide.

Multiple options should be available to the human operator available for selection when feasible, such as using a scoring approach for different resource assignments. Orchestration services functionality includes dissemination of tasking and continuously updating based on responses of subordinate resources, new threat information, or changes in command intent, as shown in Figure

2. The assignment of a unit to a control node forms a team. The operation of a command node and control node may be located on the same physical platform or dispersed.

Figure 2: Notional Command and Control Architecture

The recommendation of actions is highly dependent on the capabilities of resources available to the decision authority. Throughout the program, software solutions developed will be evaluated with the management and control of systems for which parameters and capabilities are not provided except during execution. Proposers should consider how capabilities should be described in the application programming interface (API). Performers will actively participate with the Government team to refine the interface. External system interfaces are required to be via an Universal Command and Control Interface (UCI). Attributes that are determined by a human user are considered internal to the system and should be addressed by proposers. The ability to query and inspect current and future status of the plan should be made available in a machine-to-machine interface.

DARPA is interested in capabilities to include, but are not limited to Extendable architectures that abstract essential resource and tasking data dependencies for rapid integration of new sensors, communication concepts, and weapon systems Concepts and techniques that provide confidence in successful mission execution both before and during engagements Methods to abstract or resolve desired sequences of events (e.g. coordinated fires) and vary planning horizons Abilities to prescribe command and control hierarchies as teams and generate new ones Resilience of warfighting capability from intermittent or permanent loss of information flow between any nodes

Successful proposals should describe

Rationale for distributed, centralized, or hybrid architectures including execution resiliency and complexity. Note that orchestration architecture and software services do not have to resemble human users within the hierarchy.

Objective or reward function used for comparing courses of action and how external system inputs, from human or machines, would be included

Approach to optimization for decisions that consider resource constraints, time variation, and adaptability

Path to scaling up increasingly complex scenarios

1.2.2.2 Technical Area 2 (TA-2): Predictive Analytical Services

The ability to plan own force allocations relies on the ability to predict how threat, allied, neutral, and own force entities will act. Projecting the actions of agents into the future is the objective of Predictive Analytic Services, TA-2. The primary objective of TA-2 is to provide the predictive capability needed for TA-1. This includes but is not limited to behaviors of human elements, the kinematics of physical platforms, overall force employment strategies, and system of systems interactions. DARPA seeks technical solutions to this problem that allows for confidence and explainability into the prediction for human understanding. There are numerous mathematical approaches to this problem (e.g. Markov decision processes, reinforcement learning, etc.), and data required should be clearly described in proposals. Performers are encouraged to use data or models at any security classification level.

Successful proposals should describe Mathematical or computational foundation of predictive capability Approaches that incorporate uncertainty of inputs (e.g. geolocation precision) as well as process noise or behavior uncertainty Rational for level of fidelity for prediction in context of the JAWS mission Requirements or use case of the API to be used by TA-3 for human operators Approach to quantify the validity of the prediction capability

A common data layer will be provided as government furnished information where the API will be developed collaboratively with a common data layer developer in order to abstract interoperability with various data feeds. Open standard interfaces are expected based on current best practices (e.g. Apache Spark). Proposers should describe how the proposed approach would be tested and what services are required in a microservice architecture.

1.2.2.3 Technical Area 3 (TA-3): Operator Interface

The Operator Interface will be the primary means for operators to analyze mission status, review recommended courses of action, and allow operators the ability to input or modify tasking based on commander’s intent. Within TA-3, DARPA seeks solutions that allow users to modify mission objectives and priorities while specifying the granularity of oversight for tasking to be disseminated. The user interface should include both strategic and tactical decision aids. The system should provide up-to-date information to the warfighter on the future plan and current operating status. JAWS is not seeking to replace campaign or mission planning but create adaptive capabilities that cross physical domains and military services. For visualization, modern solutions that make use of Open Geospatial Consortium (OGC) standards (https://www.opengeospatial.org/) for compatibility, plug-in architectures, user defined layouts that support customization, and robust visualization capabilities are strongly desired.

Successful proposals should include Use cases for graphical user interface Approaches to user defined displays Methods and approach to modifying current and future tasking Oversight of lower echelon and resource management Geospatial and time dynamic environment visualization Use of existing and industry supported geospatial standards and tools for visualization Ability to provide insight and trust for human operators without extensive experience

1.2.3 Program Phase Structure

The JAWS program is structured in two distinct phases—Phase 1 (Base - 15 months and Option

- 3 months), and Phase 2 (15 months) starting 15 months after Phase 1. If the option in Phase 1 is exercised, it will overlap with Phase 2. One year into Phase 1, performers will deploy a JAWS system to be evaluated in the performer's facility as Demonstration 1. An option may be exercised to deploy and perform another demonstration utilizing an additional scenario to be executed at a government facility. Performers will provide an end of phase report that concisely summarizes the effort conducted, technical achievements, and remaining technical challenges, as well as all software artifacts (source code, libraries, executables, etc.) 30 calendar days after Demonstration 1. At the end of Phase 2, performers will execute another demonstration, details of which are defined in the classified addendum. Full costing is required for Phases 1 and 2.

Figure 3: Release Cycle

Proposals should describe the minimum viable product and when this is expected to be released.

DARPA anticipates a Phase 1 minimum viable product would be in a release within nine months after the award date. The minimum viable product should address the following:

• Optimum allotment of resources assuming targets are identified and tracked https://www.opengeospatial.org/

• Kill chain selection in the context of static communication limitations (latency, bandwidth, etc.)

• Time-varying nature of resource assignment (weapon miss, attrition, movement)

• At least one classified vignette

Leading up to the Phase 1 demonstration, proposers are expected to make incremental updates to the minimum viable product to address the following:

• Assigning tasking and data to Control Nodes from Command Node or proposed command and control distribution (see Figure 2)

• Managing dynamic communication limitations (bandwidth reduction, loss of node, etc.)

• New vignettes as developed in program

Proposers are encouraged to use unclassified constructive simulation environments for general software development with two week sprints within each quarterly release. Threat data and scenarios will be classified; therefore, performers should describe their team’s access to cleared personnel, physical spaces, and computer systems. It is anticipated that performers will need to work at the SECRET level shortly after kickoff and require TOP SECRET clearances with SCI eligibility to attend Phase 2 integration events. Proposers should also describe how they will share classified information with team members. During Phase 1, DARPA anticipates providing a classified computing environment to the prime contractor(s) to facilitate classified data transfer with DARPA as well as a government development environment, but this environment should not be the primary development environment for performers.

1.2.4 Development and Integration Environment

DARPA is seeking to demonstrate solutions in a live, virtual, constructive (LVC) environment during the option of Phase 1 and Phase 2. The purpose of the simulation environment is to consider various scenarios and evaluate battle management command and control features within JAWS. DARPA is developing the Quint development environment to enable a continuous integration capability in which, as shown in Figure 4 below, the JAWS components are connected to a common data layer that will be provided with Quint, and physically deployed in Phase 1 for testing. Each Quint deployment is anticipated to be comprised of the following:

4 rack-mounted compute servers each with o ~500 GB of memory o ~100 cores on CPU o 1s TB of SSD SAS mixed use storage

1 network attached storage o 500 TB of storage

5 desktop work stations each with o 10 core CPU o ~256 GB of memory o 1 TB disk storage

Figure 4: Quint Development Environment

1.2.4.1 Integration Phasing and Overview

For the JAWS program, the goal of Phase 1 is to provide sufficient maturity for integration into the Quint development environment. In Phase 1, performers will be expected to provide monthly development versions of the JAWS suite with quarterly stable releases. The DARPA government team anticipates providing quarterly development versions of the common data layer and constructive, virtual, and live environment (see Figure 4), which the performers can utilize for testing. In Phase 2, performers will provide bi-weekly development versions into Quint.

Quarterly releases and on-site integration testing is anticipated in Phase 2.

With each major and minor release, updates to Quint (new simulated entities, data services, etc.)

are anticipated. In order to coordinate these updates with other Quint features, for each JAWS minor upgrade deployment, a JIRA Task will be created by performers with a Declaration of Intent. Within this Task, the performer will identify the core objectives of the JAWS upgrade, the technical challenges addressed, how the upgrade will be tested prior to integration and any updates required to be implemented by the government. During Phase 1 only loose coordination with the Quint development environment will be considered until a mature JAWS stable release occurs as a minimum viable product.

1.2.4.2 Phase 2 Production Environment and Integration Process

The production environment for final integration is at a government facility and will be a compute environment with ~8,000 cores at ~3 GHz with 2 PB of DDR4 RAM and several NVIDIA Tesla V100S and T4 GPUs in multiple enclaves. The environment will be built on OpenStack, but performers are anticipated to operate exclusively within hardened containers.

Integration into this environment will be collaborative with the government beginning with the Option of Phase 1.

The Quint development environment provides a small scale representation for integration testing prior to deployment into the Phase 2 production environment. The production environment deployment leverages a system engineering approach developed to support the rapid and agile evolution of complex System of Systems (SoS) architectures. This approach incorporates continuous development and integration for assessing capabilities and limitations of the selected systems, matures technologies based on key performance parameters, and reduces risk by understanding performance and cost tradeoffs as the system evolves. Central to this process is the Continuous Integration Environment (CIE), which is a digital, cloud-based collaboration and automation environment. Integration will be executed over a series of developmental phases (excursions) to mature the architecture, and numerous technical insertions to develop the components necessary to meet program objectives. A notional year-long integration process is shown in Figure 5. Performer requested updates to the environment will be included in this process and reviewed at each Quarterly Project Review (QPR). A System Integration Exercise (SIE) will be conducted by the government prior to integration into the production environment.

Performers are required to adhere to the Information Assurance (IA) process and policies of the DoD for any systems entering the environment. For collateral environments, performers are required to comply with Defense Counterintelligence and Security Agency (DCSA), Defense Security Service (DSS) Assessment and Authorization Process Manual (DAAPM), https://www.dcsa.mil/mc/ctp/tools/.

Figure 5: Notional Yearly Integration Schedule

1.2.5 Deliverables

All proposers awarded procurement contracts or Other Transactions (OTs) will be required to provide, at a minimum, the following deliverables:

a. Monthly development versions of the software, to include source code, unit tests, testing scenario, and offline headless installer provided through DI2E (https://www.di2e.net/) or similar environment. Source code should be checked in daily to a source code management system accessible to DARPA personnel.

b. Quarterly releases of the software, to include source code, unit tests, and testing scenario, and offline headless installer provided through DI2E (https://www.di2e.net/) or similar environment. These will be due one month after each quarter starting after the second quarter.

https://www.dcsa.mil/mc/ctp/tools/ https://www.di2e.net/ https://www.di2e.net/

c. Program management plan must be delivered at the program kick-off meeting, and updated/delivered on a quarterly basis.

d. Slide presentations must be submitted within one week after the program kickoff meeting and after each program event (program reviews, PI meetings, and technical interchange meetings).

e. Monthly financial and technical status reports detailing progress made, tasks accomplished, major risks, planned activities, changes to key personnel, and any potential issues or problem areas that require the attention of the Government team must be provided within 15 calendar days of the end of each month.

f. A final phase report Word and PowerPoint document for each program phase that concisely summarizes the effort conducted, technical achievements, and remaining technical challenges will be due 30 calendar days after the end of each phase; a Final Report at the end of the overall period of performance that summarizes the entire project.

It is desired that all technical data and software deliverables (a, b, f) be provided with no less than Government Purpose Rights. See Section 4.5.3 for more information.

1.2.6 Metrics

The metrics for the program are given below as custody, resiliency and attrition. Performers will provide software releases as source code and unit tests along with the scenarios used to verify metrics. The building, testing, and deployment should be executed through automation in an offline headless fashion (execution of a script for example) requiring no dependencies that government personnel will execute for independent verification. Automated tests should cover custody and resiliency, described below, and results may be provided to performers for each release after independent verification. Note that more frequent testing and release cycles are encouraged, but metric criteria will also be reviewed using scenarios available only to the government assessment team.

Custody o Measured by fraction of targets tracked with a given (parametric) volume of uncertainty.

Resiliency o Measured by the success of meeting mission objectives (custody or attrition) with varying levels of own force availability. This will be tested iteratively by removing own force assets from the environment.

Attrition o Measured by the percentage of threats eliminated with regard to time. As one of the goals of this BAA is to establish and execute fast and efficient kill webs, this will be a critical metric for success.

During Phase 1, proposers will be measured on the overall success of the system during a constructive and virtual demonstration within the proposer’s environment and independent testing within Quint. Phase 2 demonstrations will be measured on the overall success of the system during a constructive and virtual demonstration within the production environment for independent evaluation by the government assessment team.

See classified addendum for further description.

2 Award Information

2.1 General Award Information

Multiple awards are anticipated. The amount of resources made available under this BAA 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 in response to this solicitation and to make awards without discussions with proposers. The Government also reserves the right to conduct discussions if it is later determined to be necessary. If warranted, portions of resulting awards may be segregated into pre-priced options. Additionally, DARPA reserves the right to accept proposals in their entirety or to select only portions of proposals for award. In the event that DARPA desires to award only portions of a proposal, negotiations may be opened with that proposer. The Government reserves the right to fund proposals in phases with options for continued work, as applicable.

The Government reserves the right to request any additional, necessary documentation once it makes the award instrument determination. Such additional information may include but is not limited to Representations and Certifications (see Section Representations and Certifications 6.1.3.4., “Representations and Certifications”). The Government reserves the right to remove proposers from award consideration should the parties fail to reach agreement on award terms, conditions, and/or cost/price within a reasonable time, and the proposer fails to timely provide requested additional information. Proposals identified for negotiation may result in a procurement contract or other transaction, depending upon the nature of the work proposed, the required degree of interaction between parties, and other factors.

Proposers looking for innovative, commercial-like contractual arrangements are encouraged to consider requesting Other Transactions. To understand the flexibility and options associated with Other Transactions, consult http://www.darpa.mil/work-with-us/contract-management#OtherTransactions.

In accordance with 10 U.S.C. § 2371b(f), the Government may award a follow-on production contract or Other Transaction (OT) for any OT awarded under this BAA if: (1) that participant in the OT, or a recognized successor in interest to the OT, successfully completed the entire prototype project provided for in the OT, as modified; and (2) the OT provides for the award of a follow-on production contract or OT to the participant, or a recognized successor in interest to the OT.

In all cases, the Government contracting officer shall have sole discretion to select award instrument type, regardless of instrument type proposed, and to negotiate all instrument terms http://www.darpa.mil/work-with-us/contract-management#OtherTransactions and conditions with selectees. DARPA will apply publication or other restrictions, as necessary, if it determines that the research resulting from the proposed effort will present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Any award resulting from such a determination will include a requirement for DARPA permission before publishing any information or results on the program. For more information on publication restrictions, see the section below on Fundamental Research.

2.2 Fundamental Research

It is DoD policy that the publication of products of fundamental research will remain unrestricted to the maximum extent possible. National Security Decision Directive (NSDD) 189 defines fundamental research as follows:

‘Fundamental research’ means basic and applied research in science and engineering, the results of which ordinarily are published and shared broadly within the scientific community, as distinguished from proprietary research and from industrial development, design, production, and product utilization, the results of which ordinarily are restricted for proprietary or national security reasons.

As of the date of publication of this BAA, the Government expects that program goals as described herein either cannot be met by proposers intending to perform fundamental research or the proposed research is anticipated to present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Therefore, the Government anticipates restrictions on the resultant research that will require the awardee to seek DARPA permission before publishing any information or results relative to the program.

Proposers should indicate in their proposal whether they believe the scope of the research included in their proposal is fundamental or not. While proposers should clearly explain the intended results of their research, the Government shall have sole discretion to determine whether the proposed research shall be considered fundamental and to select the award instrument type. Appropriate language will be included in resultant awards for non-fundamental research to prescribe publication requirements and other restrictions, as appropriate. This language can be found at http://www.darpa.mil/work-with-us/additional-baa.

For certain research projects, it may be possible that although the research to be performed by a potential awardee is non-fundamental research, its proposed subawardee’s effort may be fundamental research. It is also possible that the research performed by a potential awardee is fundamental research while its proposed subawardee’s effort may be non-fundamental research.

In all cases, it is the potential awardee’s responsibility to explain in its proposal which proposed efforts are fundamental research and why the proposed efforts should be considered fundamental research.

3 Eligibility Information http://www.darpa.mil/work-with-us/additional-baa

3.1 Eligible Applicants

All responsible sources capable of satisfying the Government's needs may submit a proposal that shall be considered by DARPA.

3.1.1 Non-U.S. Organizations

Non-U.S. organizations and/or individuals may not participate in this effort as a prime contractor to DARPA since most work will be performed at the SECRET/NOFORN level. Non U.S.

organizations and/or individuals may act as subcontractors to the extent that the prime contractor can ensure such participants comply with any necessary nondisclosure agreements, security regulations, export control laws, and other governing statutes applicable under the circumstances.

Non-U.S. organizations or individuals acting as subcontractors will perform solely at the unclassified level. See Section 4.2 “Security and Proprietary Issues” regarding the proposers capabilities to perform research and development at the classification level they propose.

3.1.2 Applicants Considering Classified Submissions

DARPA expects classified submissions to this BAA. Applicants considering classified submissions (or requiring access to classified information during the life-cycle of the program) shall ensure all industrial, personnel, and information system processing security requirements are in place and at the appropriate level (e.g., Facility Clearance (FCL), Personnel Security Clearance (PCL), certification and accreditation (C&A)) and any Foreign Ownership Control and Influence (FOCI) issues are mitigated prior to such submission or access. Additional information on these subjects can be found at: http://www.dcsa.mil.

3.1.3 Associate Contractor Agreement Clause

a) It is recognized that success of the JAWS research effort depends in part upon the open exchange of information between the various Associate Contractors involved in the effort.

This clause is intended to ensure that there will be appropriate coordination and integration of work by the Associate Contractors to achieve complete compatibility. By executing this contract, the Contractor assumes the responsibilities of an Associate Contractor. For the purpose of this clause, the term Contractor includes subsidiaries, affiliates, and organizations under the control of the contractor (e.g., subcontractors).

b) Work under this contract may involve access to proprietary or confidential data from an Associate Contractor. To the extent that such data is received by the Contractor from any Associate Contractor for the performance of this contract, the Contractor hereby agrees that any proprietary information received shall remain the property of the Associate Contractor and shall be used solely for the purpose of the JAWS research effort. Only that information which is received from another contractor in writing and which is clearly identified as proprietary or confidential shall be protected in accordance with this provision. The obligation to retain such information in confidence will be satisfied if the Contractor http://www.dcsa.mil/ receiving such information utilizes the same controls as it employs to avoid disclosure, publication, or dissemination of its own proprietary information. The receiving Contractor agrees to hold such information in confidence as provided herein so long as such information is of a proprietary/confidential or limited rights nature.

c) The Contractor hereby agrees to closely cooperate as an Associate Contractor with the other Associate Contractors on this research effort. This involves as a minimum:

a. Maintenance of a close liaison and working relationship;

b. Maintenance of a free and open information network with all Government identified

Associate Contractors;

c. Delineation of detailed interface responsibilities;

d. Entering into a written agreement with the other Associate Contractors setting forth the substance and procedures relating to the foregoing, and promptly providing the Agreements Officer/Procuring Contracting Officer with a copy of same; and,

e. Receipt of proprietary information from the Associate Contractor and transmittal of Contractor proprietary information to the Associate Contractors subject to any applicable proprietary information exchange agreements between associate contractors when, in either case, those actions are necessary for the performance of either.

d) In the event that the Contractor and the Associate Contractor are unable to agree upon any such interface matter of substance, the technical data identified is not provided as scheduled, the Contractor shall promptly notify the DARPA JAWS Program Manager. The Government will determine the appropriate corrective action and will issue guidance to the affected Contractor.

e) The Contractor agrees to insert in all subcontracts hereunder which require access to proprietary information belonging to the Associate Contractor, a provision which shall conform substantially to the language of this clause, including this paragraph (e).

f) Associate Contractors for this JAWS research effort include:

Performer ACA With Each JAWS performer Each common data layer development contractor (See Section 1.2.4 of the BAA).

Note: It is intended that ACAs be established prior to contract award. The Government will provide the selected JAWS proposers with point of contact information for each data core developer contractor no later than 30 days after receipt of selection letters.

3.2 Federally Funded Research and Development Centers (FFRDCs) and Government Entities

3.2.1 FFRDCs

FFRDCs are subject to applicable direct competition limitations and cannot propose to this BAA in any capacity unless they meet the following conditions. (1) FFRDCs must clearly demonstrate that the proposed work is not otherwise available from the private sector. (2) FFRDCs must provide a letter, on official letterhead from their sponsoring organization, that (a) cites the specific authority establishing their eligibility to propose to Government solicitations and compete with industry, and (b) certifies the FFRDC’s compliance with the associated FFRDC sponsor agreement’s terms and conditions. These conditions are a requirement for FFRDCs proposing to be awardees or subawardees.

3.2.2 Government Entities

Government Entities (e.g., Government/National laboratories, military educational institutions, etc.) are subject to applicable direct competition limitations. Government Entities must clearly demonstrate that the work is not otherwise available from the private sector and provide written documentation citing the specific statutory authority and contractual authority, if relevant, establishing their ability to propose to Government solicitations and compete with industry. This information is required for Government Entities proposing to be awardees or subawardees.

3.2.3 Authority and Eligibility

At the present time, DARPA does not consider 15 U.S.C. § 3710a to be sufficient legal authority to show eligibility. While 10 U.S.C.§ 2539b may be the appropriate statutory starting point for some entities, specific supporting regulatory guidance, together with evidence of agency approval, will still be required to fully establish eligibility. DARPA will consider FFRDC and Government Entity eligibility submissions on a case-by-case basis; however, the burden to prove eligibility for all team members rests solely with the proposer.

3.3 Organizational Conflicts of Interest

FAR 9.5 Requirements In accordance with FAR 9.5, proposers are required to identify and disclose all facts relevant to potential OCIs involving the proposer’s organization and any proposed team member (subawardee, consultant). Under this Section, the proposer is responsible for providing this disclosure with each proposal submitted to the BAA. The disclosure must include the proposer’s, and as applicable, proposed team member’s OCI mitigation plan. The OCI mitigation plan must include a description of the actions the proposer has taken, or intends to take, to prevent the existence of conflicting roles that might bias the proposer’s judgment and to prevent the proposer from having unfair competitive advantage. The OCI mitigation plan will specifically discuss the disclosed OCI in the context of each of the OCI limitations outlined in FAR 9.505-1 through

FAR 9.505-4.

Agency Supplemental OCI Policy In addition, DARPA has a supplemental OCI policy that prohibits contractors/performers from concurrently providing Scientific Engineering Technical Assistance (SETA), Advisory and Assistance Services (A&AS) or similar support services and being a technical performer.

Therefore, as part of the FAR 9.5 disclosure requirement above, a proposer must affirm whether the proposer or any proposed team member (subawardee, consultant) is providing SETA, A&AS, or similar support to any DARPA office(s) under: (a) a current award or subaward; or (b) a past award or subaward that ended within one calendar year prior to the proposal’s submission date.

If SETA, A&AS, or similar support is being or was provided to any DARPA office(s), the proposal must include:

The name of the DARPA office receiving the support;

The prime contract number;

Identification of proposed team member (subawardee, consultant) providing the support; and An OCI mitigation plan in accordance with FAR 9.5.

Government Procedures In accordance with FAR 9.503, 9.504 and 9.506, the Government will evaluate OCI mitigation plans to avoid, neutralize or mitigate potential OCI issues before award and to determine whether it is in the Government’s interest to grant a waiver. The Government will only evaluate OCI mitigation plans for proposals that are determined selectable under the BAA evaluation criteria and funding availability.

The Government may require proposers to provide additional information to assist the Government in evaluating the proposer’s OCI mitigation plan.

If the Government determines that a proposer failed to fully disclose an OCI; or failed to provide the affirmation of DARPA support as described above; or failed to reasonably provide additional information requested by the Government to assist in evaluating the proposer’s OCI mitigation plan, the Government may reject the proposal and withdraw it from consideration for award.

3.4 Cost Sharing/Matching

Cost sharing is not required; however, it will be carefully considered where there is an applicable statutory condition relating to the selected funding instrument. Cost sharing is encouraged where there is a reasonable probability of a potential commercial application related to the proposed research and development effort.

For more information on potential cost sharing requirements for Other Transactions for Prototype, see http://www.darpa.mil/work-with-us/contract-management#OtherTransactions.

4 Application and Submission Information

4.1 Address to Request Application Package

This announcement, any attachments, and any references to external websites herein constitute the total solicitation. If proposers cannot access the referenced material posted in the announcement found at www.darpa.mil, contact the administrative contact listed herein.

4.1.1 Security

A formal request for the DARPA- HR001120S0022 BAA Classified Addendum and Security Classification Guide may be submitted by filling out the Classified Documents Request Form http://www.darpa.mil/

(found in APPENDIX 2 to this BAA) and emailing the Request Form to HR001120S0022@darpa.mil with subject line titled “Request DARPA- HR001120S0022 Classified Documents.” Security classification guidance via a Security Classification Guide (SCG) and a DD Form 254, “DoD Contract Security Classification Specification,”, and the BAA Classified Addendum will be provided.

Proposers should allow at least five (5) business days for processing requests for the classified BAA addendum plus time for delivery.

4.2 Content and Form of Application Submission

All submissions, including abstracts and proposals must be written in English with type not smaller than 12 point font. Smaller font may be used for figures, tables, and charts. Copies of all documents submitted must be clearly labeled with the DARPA BAA number, proposer organization, and proposal title/proposal short title.

4.3 Abstract Format

Proposers are strongly encouraged to submit an abstract in advance of a full proposal. Abstracts should follow the format described below in this section. The cover sheet should be clearly marked “ABSTRACT” and the total length of Section II should not exceed 7 pages.

Section I. Administrative

A. Cover sheet to include:

(1) BAA number (HR001120S0022);

(2) Technical area(s) (all technical areas are required);

(3) Lead Organization submitting abstract;

(4) Type of organization, selected among the following categories:

Large Organization, Small Disadvantaged Organization, Other Small Organization, HBCU, MI, Other Educational, Other Nonprofit;

(5) Proposer’s internal reference number (if any);

(6) Other team members (if applicable) and type of organization for each;

(7) Proposal title;

(8) Technical point of contact to include:

Salutation, last name, first name, street address, city, state, zip code (+4), telephone, fax (if available), electronic mail;

(9) Administrative point of…