19-13 Amend 2 first repub.doc

AMENDMENT 2 to BAA FA8750-19-S-7013

The purpose of this modification is to republish the original announcement, incorporating any previous amendments, pursuant to FAR 35.016(c).

This republishing also includes the following changes:

1. Part I, Overview Information:

a. Updates FBO reference to Beta SAM website;

b. Updates the BAA Manager name and information;

2. Part II, Full Text Announcement:

a. Section III.2.b.2, updates the DCSA website;

b. Section IV.3.a, updates the DCSA website;

c. Section IV.4.b and IV.4.c. updates clause dates;

Section IV.4.e, updated the link to reference the Beta SAM website;

d. Section VI.1, updates the RI Specific Proposal Preparation Instructions Beta SAM link;

e. Section VII, updates the TPOC name and information and the AFFARS Ombudsman clause date

No other changes have been made.

NAICS CODE: 541715

FEDERAL AGENCY NAME: Department of the Air Force, Air Force Materiel Command, AFRL - Rome Research Site, AFRL/Information Directorate, 26 Electronic Parkway, Rome, NY, 13441-4514

BAA ANNOUNCEMENT TYPE: Modification

BROAD AGENCY ANNOUNCEMENT (BAA) TITLE: Multi-Domain Command & Control Execution Management & Workflows -- Flyleaf

BAA NUMBER: FA8750-19-S-7013

PART I – OVERVIEW INFORMATION

This announcement is for an Open, 2-Step BAA which is open and effective until 30 Sep 2022. Only white papers will be accepted as initial submissions; formal proposals will be accepted by invitation only. While white papers will be considered if received prior to 4 PM Eastern Standard Time (EST) on 30 Sep 2022, the following submission dates are suggested to best align with projected funding:

FY20 by 19 Sep 2019

FY21 by 31 Mar 2020

FY22 by 31 Mar 2021

Offerors should monitor the Contract Opportuities on the Beta SAM website at https://beta.SAM.gov in the event this announcement is amended.

The Flyleaf Program Team anticipates hosting an Industry Day to provide interested offerors an opportunity to learn more about Flyleaf and AFRL/RI’s MDC2 activities. Details regarding time, place, and visitor access will be published in FedBizOps shortly following the announcement publication proper.

CONCISE SUMMARY OF TECHNOLOGY REQUIREMENT: Seeking innovative research to create a capability within AFRL/RI to assess, in a Multi-Domain Command and Control (MDC2) context, the maturity and operational applicability of various MDC2 applications – all with a mind toward their transition to the infrastructure and architecture of future Air Force operations centers, such as envisioned by the Air Force’s ShadowOC concept. Workflow representation and application methodologies are needed for managing MDC2 workflows, including technologies and tools to model operations-floor actors, actions, and activities as a set of processes, to enable their tracking, monitoring, and execution management. A rigorous, well-defined and validated test case scenario that exercises all critical framework configurations – a “Golden Path” scenario – is needed to ensure quality, performance and safety of the developed software. An on-line or linked capability to emulate real-world data sources and consumers - a “White Cell” – is needed to ensure that applications, and operators using those applications in the course of knowledge elicitation and application assessment, have a real-world equivalent of expected data flows and executed actions to address deficiencies in data or data consumers. A micro-service development and integration capability is needed to rapidly implement missing or inadequate operations floor capabilities. Dynamic composition of the MDC2 workflows via aggregation of these micro-services is paramount. The workflow management infrastructure must facilitate instrumentation in support of machine-learning data collection and process assessment. The resulting data is critical to establishing the viability and usefulness of the assessed candidate technologies, and the applications embodying those technologies, in preparation for transition of those applications to future Air Force operations centers, and eventual inclusion within the operations floor enterprise. The projected rapid pace of applications development requires that applications developed through disparate and segregated sources be easily integrated into existing host infrastructures, and that existing workflows not be intrinsically impacted by that insertion.

BAA ESTIMATED FUNDING: Total funding for this BAA is approximately $24.9M. Individual awards will not normally exceed 24 months with dollar amounts normally ranging from $300,000 to $1,000,000. There is also the potential to make awards up to any dollar value as long as the value does not exceed the available BAA ceiling amount.

ANTICIPATED INDIVIDUAL AWARDS: Multiple Awards are anticipated.

TYPE OF INSTRUMENTS THAT MAY BE AWARDED: Procurement contracts, grants, cooperative agreements or other transactions (OT) depending upon the nature of the work proposed. In the event that an Other Transaction for Prototype agreement is awarded as a result of this competitive BAA, and the prototype project is successfully completed, there is the potential for a prototype project to transition to award of a follow-on production contract or transaction. The Other Transaction for Prototype agreement itself will also contain a similar notice of a potential follow-on production contract or agreement.

AGENCY CONTACT INFORMATION: All white paper submissions and any questions of a technical nature shall be directed to the cognizant Technical Point of Contact (TPOC) as specified below (unless otherwise specified in the technical area) (email requests are preferred):

Multi-Domain C2 Execution Management & Workflows (Flyleaf) TPOC:

Mr. John Myers

AFRL/RISC

525 Brooks Rd

Rome, NY 13441-4505

Telephone: (315)330-4812

Email: john.myers.28@us.af.mil Copies of white paper submissions should also be sent to:

Multi-Domain C2 Execution Management & Workflows (Flyleaf) BAA MANAGER:

Mr. Joshua Surman

AFRL/RISC

525 Brooks Rd

Rome, NY 13441-4505

Telephone: (315)330-3810

Email: joshua.surman@us.af.mil Questions of a contractual/business nature shall be directed to the cognizant contracting officer, as specified below (email requests are preferred):

Ms. Amber Buckley

Telephone (315) 330-3605

Email: amber.buckley@us.af.mil Emails must reference the solicitation (BAA) number and title of the acquisition.

Pre-Proposal Communication between Prospective Offerors and Government Representatives: Dialogue between prospective offerors and Government representatives is encouraged. Technical and contracting questions can be resolved in writing or through open discussions. Discussions with any of the points of contact shall not constitute a commitment by the Government to subsequently fund or award any proposed effort. Only Contracting Officers are legally authorized to commit the Government.

Offerors are cautioned that evaluation ratings may be lowered and/or proposal rejected if proposal preparation (proposal format, content, etc.) and/or submittal instructions are not followed.

PART II – FULL TEXT ANNOUNCEMENT

BROAD AGENCY ANNOUNCEMENT (BAA) TITLE: Multi-Domain Command & Control Execution Management & Workflows -- Flyleaf

BAA NUMBER: BAA FA8750-19-S-7013

CATALOG OF FEDERAL DOMESTIC ASSISTANCE (CFDA) Number: 12.800

I. TECHNOLOGY REQUIREMENTS:

The Air Force Research Laboratory Information Directorate (AFRL/RI) is soliciting white papers under this Broad Agency Announcement (BAA) for research, development, integration, test and evaluation of technologies/techniques to create a capability within AFRL/RI to assess, in a Multi-Domain Command and Control (MDC2) context, the maturity and operational applicability of various MDC2 applications – all with a mind toward their transition to the infrastructure and architecture of future Air Force operations centers, such as envisioned by the ShadowOC concept.

The ability to bring new information technology systems on-line successfully, specifically command and control (C2) systems and applications, into the Air Force operations environment has become a major concern for the Air Force. Current and future Air Force military operations require the coordinated execution of authority and direction to gain, fuse and exploit information from any source in order to integrate planning and synchronize execution of operations in the multiple domains of air, space and cyber across time, space and purpose to meet the commander’s objectives. However, current operations center information technology infrastructure & systems do not provide the operational agility & decision speed needed for 21st-century information age command & control of military forces. The rapid pace of technology change presents a challenge to the traditional acquisition process in the transitioning of new technologies and applications to the field before they become outdated. Part of this is due to the massive, monolithic aspect of many military C2 systems that stymie the introduction of incremental enhancements and integration of new software components.

Air Force C2 operations are different from contemporary large-scale commercial operations. This presents the Air Force a number of unique challenges. Air Force operations are inherently multi-domain, involving assets and weapons across air, space, and cyber domains and supporting operations across global, regional, and unit levels, while commercial operations are often singularly focused and less vertically structured. The Air Force has to keep national security and network access concerns always in mind, while these are rarely a factor for commercial concerns. Much of the software and technology advances taken advantage of by commercial entities have as a focus the sharing of data, the military and national security communities often seem obsessed, and rightly so, on the restriction of access to data. Lastly, much of Air Force operations are largely composed of legacy and out-of-date technology, and stove-piped infrastructures not amenable to revolutionary and new technology; where the commercial world operates with an expectation of turning over their information technology infrastructure in five years or less. In addition, commercial domains often have the luxury of static, well-understood business processes “baked-in” to the information infrastructure and applications.

To meet current C2 requirements, the Air Force has outlined a new vision for MDC2 – a vision that separates out the development, acquisition, and sustainment of information systems into their constituent components: user interfaces and visualization, C2 mission applications, infrastructure, and data – that moves the Air Force from a world of requirements translated into whole systems, to a world characterized by “perpetual enhancement in operations.” This vision posits the rapid design and prototyping of user-centered solutions with integration, security, test, deployment, and sustainment in mind from the start – an approach referred to as Design to Test. A companion goal is to develop and field software in months, and in a manner that supports easy sustainment or replacement. This approach is referred to as Minimum Viable Product and supports a “crawl, walk, run” progression of capabilities. The Flyleaf program ascribes to these precepts and seeks to ensure they are supported by technologies and environments produced by the program.

Within the Air Force, this new approach is embodied in a proof-of-concept demonstration known as the ShadowOC – an alternative approach to C2 system development, fielding, and sustainment using 21st century best practices for software development. The primary manifestation of the ShadowOC is as a parallel, multi-node enterprise co-located with operations center(s) operators to allow for data sharing and apps deployment simultaneously in the development and operations environments, side by side permitting relatively risk-free experimentation with live data. Following the Design-To-Test philosophy further allows rapid test and promotion of new applications and networks to operations centers – operators have already seen and used the new technology, are less intimidated by it and quicker to embrace its use. The Minimum-Viable-Product manner of introducing new technology allows software to be developed and fielded in months – software that can be easily maintained and upgraded, or even replaced. Technology developed with close cooperation of the user community provides an opportunity for that community to influence the development, providing immediate feedback on how best to leverage the technology. However, the ShadowOC approach does not address management of the resulting multitude of operations floor processes. The Flyleaf Program seeks to develop tools, technology, and a framework for execution management of these operational center process workflows and applications. By this means, assessment of new and existing C2 applications is performed in a controlled environment prior to their introduction onto the operations floor, reducing the risk of disruption and increasing the quality of the next generation of operational software. The Flyleaf Program also seeks to a capacity to function as a node on the ShadowNet, the collection of operations centers ascribing to the ShadowOC concept, further smoothing the transition of technology from the laboratory to the field.

The objective of the MDC2 Execution Management and Workflows Program (also known as “Flyleaf”) at AFRL/RI is to improve the performance of C2 processes at the operational-echelon level through the automation and instrumentation of workflows, allowing for the application of machine learning and artificial intelligence. The vision of this program is to facilitate the acceptance and transition of new technology, in the form of applications, developed in-house or under contract from the Air Force Research Laboratory (AFRL), to the ShadowOC facility. AFRL/RI needs to be able to screen new tools from industry and from our own science and technology programs. Our testing and accreditation processes must be acceptable and in step with those of the ShadowOC. This requires the development and assembly of an organic capability to host & execute operations center workflows & applications. Definition of C2 workflow structures and format, application on-boarding processes will enable the effectiveness and efficiency measurement of new applications and operations-floor processes as AFRL and other agencies develop new technology and applications. AFRL seeks to establish an “on-ramp” evaluation capability to ensure proper evaluation of candidate MDC2 micro-services and applications before their delivery to operational users, particularly through the ShadowOC acquisition pipeline, for acceptance and transition. Through this means AFRL seeks to deliver technology to the decision makes that is consistent with the speed of technology advancement and the scale of Air Force operations and data. It is important to understand that the focus of this BAA is on the environment and framework necessary to support rapid technology transition, and not on the new applications themselves, per se, which other programs, agencies and portfolios are developing.

There are two challenges in implementing this capability. The first – Product – is to create an infrastructure to enable a military operations-centric development and test-case creation environment. Having a development environment with sophisticated scenario execution capabilities for extensive validation of created artifacts provides a proper verification and validation framework for measuring the meeting of performance objectives. The instrumentation capability and resulting data will also serve the functions of increasing the knowledge repository of objective, real-time data for feeding back into the development process, but also a source of data for input to machine learning algorithms under development to reduce operator workload by anticipating future planning actions and relieving operators of mundane and repetitive task.

The Flyleaf Program seeks to facilitate this rapid transition of lower maturity applications through a tight development/operations (DevOps) approach. To do this developers and programmers need to become keenly proficient in the duty position for which they are developing applications and operational personnel need to be exposed to the technology as early as possible –with both parties functioning in close proximity, enabling operations-driven development with a predictable engagement, data availability, & operator interaction. Technology maturation performed in an environment that allows observing the daily exercise and workflows ensures that, when ready, applications can quickly transition from the hosted environment to use by operators on the floor. We envision a daily vignette executed identically & repeatedly over 2-4 week period that will allow development to focus on product over process.

The second challenge – Process – is to ensure that applications under developed and assessment are accurate and appropriate to the targeted real-world C2 environment. Creation of a sophisticated White Cell and scenario generation capability serves this purpose, including development of micro-services to fill gaps in the Flyleaf environment to bring the environment to parity with actual operations center practices, tools and capabilities. Proper exercise of applications under assessment requires the use of interactive and iterative warfighter scenarios.

Process and workflow management is core to the Flyleaf program. A set of software services are a viable proxy for some of the specific processes invoked by C2 operations centers to effect military action, from event identification through to threat resolution. Management of these services is currently technology-constrained: multi-domain process management tools (apps) are insufficient in number and maturity, modeling of duty-station roles and actions is incomplete and not responsive to varied user capabilities and expertise, the dimensionality of the decision spaces is high, mission data is incomplete or not readily accessible and not consistent across domains, and the multitude of simultaneous temporal modes (seconds to weeks) hampers the application of machine learning and automation.

If processes are not tracked they are hard to manage effectively. If processes are not instrumented and measured they cannot be tracked. The measuring of a process must be undertaken in an objective and rigorous manner or management of the processes will be meaningless and futile. Processes that cannot be managed cannot be directed or changed, and any improvement is purely serendipitous. The Flyleaf program seeks to bring the power of execution (business process) management to operations workflows. A better understanding of how operations floor processes interact, where the gaps in communications exist, and which processes are inefficient or superfluous will allow the proper application of resources to improve operations floor performance. As the Air Force moves from singular domain operations centers, e.g, Air Operations Center (AOC) to multiple-domain operations center the need to measure, track and assess workflow will become even more important. The resulting assembly of MDC2 processes, data, and operator interaction, along with a robust observation and assessment capability, is critical to establishing the viability and usefulness of the assessed candidate MDC2 applications both in the Air Force Research Laboratory during development and in preparation for their transition to future Air Force operations centers, and later after their eventual inclusion within the operations floor enterprise.

The focus of the Flyleaf program is on managing the process workflows present in an MDC2 operations center – or any operations center for that matter, not solely on the development of new applications in isolation. The development of this capability supports the development and enhancement of MDC2 products at speed and scale – fast enough to keep pace with technology change, while coexisting with the massive amounts of data that are collected, produced, stored and reasoned over across an operations center enterprise. A realistic, operationally-relevant testbed will support rigorous assessment of applications in a true multi-domain environment, where tighter control is required to ensure activities in the individual domains do not conflict or interfere with each other, or unduly burden the underlying information infrastructure, and consistently support the intent of the commander. The close association of in-house developers with operational experts will provide a faster, tighter feedback loop – increasing the speed of debugging and refinement, and shortening the time to field for new applications.

Workflow representation and application methodologies are needed for managing MDC2 workflows, including technologies and tools to model operations-floor actors, actions, and activities as a set of processes, to enable their tracking, monitoring, and execution management. Desired capabilities include a rigorous, well-defined and validated test case scenario that exercises all critical framework configurations – a “Golden Path” scenario –to ensure quality, performance and safety of the developed software. An on-line or linked capability to emulate real-world data sources and consumers - a “White Cell” –ensures that applications and operators have a real-world equivalent of expected data flows and executed actions to address deficiencies in data or data consumers, in the course of exercising the developed applications. AFRL seeks a micro-service development and integration capability for implementing missing or inadequate operations floor capabilities. Dynamic composition of the MDC2 workflows via aggregation of these micro-services is paramount. Machine-learning data collection and process assessment goals require instrumentation of the workflows and processes to facilitate their effective management. The resulting data is critical to establishing the viability and usefulness of the assessed candidate technologies, and the applications embodying those technologies, in preparation for transition of those applications to future Air Force operations centers, and eventual inclusion within the operations floor enterprise. The projected rapid pace of applications development requires that applications developed through disparate and segregated sources are easily integrated into existing host infrastructures, and that existing workflows not be intrinsically impacted by that insertion.

A “toggle” application-insertion capability permits the assessment of new features and services, including micro-services easily combined and aggregated to compose even more powerful service capabilities. The toggle approach permits researchers to effectively “flip a switch(es)” to experiment across a collection of application configurations and explore both singular and synergistic effects without the need for exhaustive rewriting of software.

The MDC2 EMW program will develop, implement, and serve as an “on-ramp” for delivery of AFRL/RI MDC2 applications to the ShadowOC and its surrogates for acceptance and transition, through the creation of a local and distributed MDC2 mission applications assessment environment. This program will document warfighter operations in the form of machine-readable workflows and processes that will enable the application of artificial intelligence and machine learning techniques to improve operations center capability.

The scope of this BAA is to develop not only the technology needed to form a core infrastructure for development, test and evaluation of MDC2 applications, but also the underlying scenarios and database content to exercise those applications. The resulting framework and infrastructure for the collection and assessment of performance data will also be invaluable to supporting efforts in other endeavors to utilize machine learning and objective performance assessment to improve MDC2 processes.

AFRL seeks technologies for improvement of MDC2 operations in the following technical areas:

Focus Area 1 – Domain-Agnostic Development Infrastructure:

The focus of Area 1 is on the development and implementation of a local, unclassified core operational testbed infrastructure, including one or more “golden-path” test case scenarios to ensure integrity and coverage of the testbed and its applications, and a “white cell” to address lack of data or data consumers. A capability to facilitate the rapid development of micro-services to address application capability gaps, supporting dynamic MDC2 workflow composition, is key to a tightly coupled development/operations (a.k.a., Dev/Ops) environment, including the shepherding of micro-service software through the accreditation process. The ability to dynamically engage/disengage individual applications as part of the evaluation process is also a critical capability. Key capabilities to be developed include:

· Capture of Warfighter Operations: Workflows representing standard operations floor processes, across multiple domains, e.g., Air, Space, Cyber, embodied in a digital format serve as the basic representation-model paradigm for Flyleaf.

· Dev/Ops Test Bed: Ascribing to a Minimal Viable Product model, the goal is to have a simple, but comprehensive, dev/ops capability in place at the earliest, then extend it as lessons are learned, and a greater understanding gained of the idiosyncrasies of candidate applications.

· Golden Path Test Case: This test scenario will serve as a benchmark by which to evaluate other scenarios and data sets, the comprehensiveness of the Flyleaf framework through end-to-end exercising of functionality, and the validity and robustness of candidate MDC2 applications. This test case will also be used to measure progress of the Flyleaf program toward objectives.

· White Cell: No amount of automation or autonomy can anticipate every eventuality, nor can a virtual laboratory environment explicitly represent every operations floor resource or response to outside real-world events. This functionality will ensure that no process unnecessarily dead-ends due to a lack of data input or data consumer. Functionality shall encompass single-stepping during initial stages of application evaluation through full-resource, multi-domain, near-real-time exercising of applications. Ultimately, the White Cell should be able to inject unanticipated events, system failures and data and communications “noise” to test the response of the applications under assessment to these factors.

· Micro-Services (w/Accreditation): AFRL seeks within the Flyleaf framework a capability to rapidly identify, bound, and develop new services, specifically micro-services, to fill functionality gaps within the MDC2 processes that will inevitably identified in the course of MDC2 operations center development and standup. This capability must support the development and enhancement of MDC2 products at speed and scale – fast enough to keep pace with technology change, while coexisting with the massive amounts of data that are collected, produced, stored and reasoned over across an operations center enterprise. The Flyleaf testbed must support rigorous assessment of applications in a true multi-domain environment. A tight association between developers and operational experts will provide a faster, tighter feedback loop – increasing the speed of debugging and refinement, and shortening the time to field for new applications. The testbed must be cognizant of the accreditation requirements for operationally fielded software. As the ultimate goal of being able to redefine workflows on-the-fly within an operational center comes closer to reality, ensuring the quality and safety of software to the warfighter becomes paramount.

· Feature Toggle: A “toggle” application-insertion capability is sought to permit the assessment of new features and services, including micro-services that can be easily combined and aggregated to compose even more powerful service capabilities. The toggle approach permits researchers to effectively “flip a switch(es)” to experiment across a collection of application configurations and explore both singular and synergistic effects without the need for exhaustive rewriting of software.

Focus Area 2 – MDC2 Scenarios and Workflows:

The focus of Area 2 is on the development of a full, MDC2 application assessment environment, including appropriate extensions to unclassified databases, e.g., “Pacifica”, to support multi-domain application assessments. Capture of MDC2 design patterns and workflows, along with performance data, is necessary to inform machine learning algorithms and to determine the readiness and viability of new MDC2 applications, as exercised via the Flyleaf infrastructure. Key capabilities to be developed include:

· Pacifica Extension: The fictional “Pacifica” virtual world requires extension of its data set to encompass a multi-domain set of entities and relationships, as well as to ensure that air, space and cyber components are not defined in isolation, e.g., availability of a satellite ground station would be reflected in modelling of space network applications, as well as in cyber network connectivity models, and be amenable for kinetic air targeting applications. Maximum interaction across domains of the respective applications during an evaluation event is a goal.

MDC2 Design Patterns (Workflows): As applications are assessed and warfighter operations captured we expect a set of core MDC2 design patterns – the processes through which operations floor activity evolves over the course of an event response – to become evident. Unobtrusive observation of these processes, and the human operators, is necessary to properly judge the performance and effect of a given application under a known set of conditions. These MDC2 design patterns will form the basis of a set of workflows with known performance attributes and criteria, and their intelligent application to future scenarios and real-world events.

Machine Learning: An additional goal of the Flyleaf Program is to facilitate the application of machine learning technology to improve operations floor performance through the collection and assessment of process data associated with particular MDC2 design patterns and simulated environments and scenarios, e.g., Pacifica. This requires the ability to specify parameters, instrument workflows accordingly and to perform first-level collection, aggregation and assessment of the resulting data.

This BAA seeks white papers addressing both of the above focus areas, offerors may respond to one or both areas, or any portion thereof, at any time. Multiple white papers from a single proposer are allowed. There is NO requirement for a single, all-encompassing, comprehensive white paper.

The technical point of contact (TPOC) for both of these focus areas is:

Multi-Domain C2 Execution Management & Workflows (Flyleaf) TPOC:

Mr. John Myers

AFRL/RISC

525 Brooks Rd

Rome, NY 13441-4505 Telephone: (315)330-4812 Email: john.myers.28@us.af.mil

IMPORTANT NOTES REGARDING:

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 cannot identify whether work proposed under this BAA may be considered fundamental research and may award both fundamental and non-fundamental research. 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 select award instrument type and to negotiate all instrument terms and conditions with selectees. Appropriate clauses will be included in resultant awards for non-fundamental research to prescribe publication requirements and other restrictions, as appropriate.

For certain research projects, it may be possible that although the research being performed by the awardee is restricted research, a sub-awardee may be conducting fundamental research. In those cases, it is the awardee’s responsibility to explain in their proposal why its sub-awardee’s effort is fundamental research.

CLOUD COMPUTING. In accordance with DFARS Clause 252.239-7010, if the development proposed requires storage of Government, or Government-related data on the cloud, offerors need to ensure that the cloud service provider proposed has been granted Provisional Authorization by the Defense Information Systems Agency (DISA) at the level appropriate to the requirement.

II. AWARD INFORMATION:

1. FUNDING: Total funding for this BAA is approximately $24,900,000. The anticipated funding to be obligated under this BAA is broken out by fiscal year as follows:

FY20 - $4,500,000

FY21 - $9,500,000

FY22 - $10,900,000

a. Individual awards will not normally exceed 24 months with dollar values normally ranging from $300,000 to $1,000,000. There is also the potential to make awards up to any dollar value as long as the value does not exceed the available BAA ceiling amount of $24,900,000.

b. The Government reserves the right to select all, part, or none of the proposals received, subject to the availability of funds. All potential Offerors should be aware that due to unanticipated budget fluctuations, funding in any or all areas may change with little or no notice.

2. FORM. Awards of efforts as a result of this announcement will be in the form of contracts, grants, cooperative agreements or other transactions depending upon the nature of the work proposed.

3. BAA TYPE: This is a 2-step open broad agency announcement. This announcement constitutes the only solicitation.

As STEP ONE – The Government is only soliciting white papers at this time. DO NOT SUBMIT A FORMAL PROPOSAL. Those white papers found to be consistent with the intent of this BAA may be invited to submit a technical and cost proposal. See Section VI of this announcement for further details regarding the proposal.

III. ELIGIBILITY INFORMATION:

1. ELIGIBILITY: All qualified offerors who meet the requirements of this BAA may apply.

2. FOREIGN PARTICIPATION/ACCESS:

a. This BAA is closed to foreign participation. This includes both foreign ownership and foreign nationals as employees or subcontractors.

b. Exceptions.

1. Fundamental Research. If the work to be performed is unclassified, fundamental research, this must be clearly identified in the white paper and/or proposal. See Part II, Section I for more details regarding Fundamental Research. Offerors should still identify any performance by foreign nationals at any level (prime contractor or subcontractor) in their proposals. Please specify the nationals’ country of origin, the type of visa or work permit under which they are performing and an explanation of their anticipated level of involvement. You may be asked to provide additional information during negotiations in order to verify the foreign citizen’s eligibility to participate on any contract or assistance agreement issued as a result of this announcement

2. Foreign Ownership, Control or Influence (FOCI) companies who have mitigation plans/paperwork in place. Proof of approved mitigation documentation must be provided to the contracting office focal point, Amber Buckley, Contracting Officer, telephone (315) 330-3605, or e-mail Amber.Buckley@us.af.mil prior to submitting a white paper and/or a proposal. For information on FOCI mitigation, contact the contact the Defense Counterintelligence and Security Agency (DCSA). Additional details can be found at: https://www.dcsa.mil/mc/ctp/foci/

3. Foreign Nationals as Employees or Subcontractors. Applicable to any effort not considered Fundamental Research. Offerors are responsible for ensuring that all employees and/or subcontractors who will work on a resulting contract are eligible to do so. Any employee who is not a U.S. citizen or a permanent resident will be restricted from working on any resultant contract unless prior approval of the Department of State or the Department of Commerce is obtained via a technical assistance agreement or an export license. Violations of these regulations can result in criminal or civil penalties.

c. Information Regarding Non-US Citizens Assigned to this Project

1. Contractor employees requiring access to USAF bases, AFRL facilities, and/or access to U.S. Government Information Technology (IT) networks in connection with the work on contracts, assistance instruments or other transactions awarded under this BAA must be U.S. citizens. For the purpose of base and network access, possession of a permanent resident card ("Green Card") does not equate to U.S. citizenship. This requirement does not apply to foreign nationals approved by the U.S. Department of Defense or U.S. State Department under international personnel exchange agreements with foreign governments. It also does not apply to dual citizens who possess US citizenship, to include Naturalized citizens. Any waivers to this requirement must be granted in writing by the Contracting Officer prior to providing access. Specific format for waiver request will be provided upon request to the Contracting Officer. The above requirements are in addition to any other contract requirements related to obtaining a Common Access Card (CAC).

2. For the purposes of Paragraph 1, it an IT network/system does not require AFRL to endorse a contractor's application to said network/system in order to gain access, the organization operating the IT network/system is responsible for controlling access to its system. If an IT network/system requires a U.S. Government sponsor to endorse the application in order for access to the IT network/system, AFRL will only endorse the following types of applications, consistent with the requirements above:

a) Contractor employees who are U.S. citizens performing work under contracts, assistance instruments or other transactions awarded under this BAA.

b) Contractor employees who are non-U.S. citizens and who have been granted a waiver.

Any additional access restrictions established by the IT network/system owner apply.

3. FEDERALLY FUNDED RESEARCH AND DEVELOPMENT CENTERS AND GOVERNMENT ENTITIES: Federally Funded Research and Development Centers (FFRDCs) and Government entities (e.g., Government/National laboratories, military educational institutions, etc.) are subject to applicable direct competition limitations and cannot propose to this BAA in any capacity unless they meet the following conditions:

a. FFRDCs: FFRDCs must clearly demonstrate that the proposed work is not otherwise available from the private sector; and FFRDCs must provide a letter on official letterhead from their sponsoring organization citing the specific authority establishing their eligibility to propose to Government solicitations and compete with industry, and their compliance with the associated FFRDC sponsor agreement’s terms and conditions. This information is required for FFRDCs proposing to be prime contractors or sub-awardees.

b. Government Entities: 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. 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.

FFRDC and Government entity eligibility will be determined on a case-by-case basis; however, the burden to prove eligibility for all team members rests solely with the proposer.

Government agencies interested in performing work related to this announcement should contact the Technical Point of Contact (TPOC). If resulting discussions reveal a mutual interest, cooperation may be pursued via other vehicles.

IV. APPLICATION AND SUBMISSION INFORMATION:

All responses to this announcement must be addressed to the Technical Point of Contact (TPOC) listed in SECTION VII. DO NOT send white papers to the Contracting Officer.

1. SUBMISSION DATES AND TIMES:

It is recommended that white papers be received by 4 PM Eastern Standard Time (EST) on the following dates to maximize the possibility of award:

FY20 by 19 Sep 2019 FY21 by 31 Mar 2020

FY22 by 31 Mar 2021

White papers will be accepted until 4 PM EST on 30 Sep 2022, but it is less likely that funding will be available in each respective fiscal year after the dates cited. This BAA will close on 30 Sep 2022.

All offerors submitting white papers will receive notification of their evaluation results within 45 days of submission. Offerors should email the TPOC and the Contracting Officer listed in Section VII, for status of their white paper(s) after 45 days, if no such correspondence has been received.

2. CONTENT AND FORMAT: Offerors are required to submit a 3 to 5 page white paper, in the form of a PDF file, summarizing their proposed approach/solution. The purpose of the white paper is to preclude unwarranted effort on the part of an offeror whose proposed work is not of interest to the Government.

The white paper will be formatted as follows:

a. Section A: Title, Period of Performance, Estimated Cost, Name/Address of Company, Technical and Contracting Points of Contact (phone and email)(this section is NOT included in the page count);

b. Section B: Task Objective; and

c. Section C: Technical Summary and Proposed Deliverables.

All white papers shall be double spaced with a font no smaller than 12 point. In addition, respondents are requested to provide their Commercial and Government Entity (CAGE) Code, their unique entity identifier and electronic funds transfer (EFT) indicator (if applicable), an e-mail address and reference BAA FA8750-19-S-7013 with their submission.

Multiple white papers within the purview of this announcement may be submitted by each offeror. If the offeror wishes to restrict its white papers, they must be marked with the restrictive language stated in FAR 15.609(a) and (b).

3. HANDLING AND MAILING INSTRUCTIONS:

a. CLASSIFICATION GUIDANCE. All Proposers should review the NATIONAL INDUSTRIAL SECURITY PROGRAM OPERATING MANUAL (NISPOM), dated February 28, 2006, and Change 2, dated May 18, 2016, as it provides baseline standards for the protection of classified information and prescribes the requirements concerning Contractor Developed Information under paragraph 4-105. Defense Counterintelligence and Security Agency (DCSA) Site for the NISPOM is: http://www.dcsa.mil/.

In the event of a possible or actual compromise of classified information in the submission of your white paper or proposal, immediately but no later than 24 hours, bring this to the attention of your cognizant security authority and AFRL Rome Research Site Information Protection Office (IPO):

Information Protection Office (contact only if a security compromise has occurred) Monday-Friday (0730-1630):

Call 315-330-4048 or Email: vincent.guza@us.af.mil Evenings and Weekends:

Call 315-330-2961

b. CLASSIFIED SUBMISSIONS. AFRL/RISC will accept classified responses to this BAA when the classification is mandated by classification guidance provided by an Original Classification Authority of the U.S. Government, or when the offeror believes the work, if successful, would merit classification.

Security classification guidance in the form of a DD Form 254 (DoD Contract Security Classification Specification) will not be provided at this time since AFRL is soliciting ideas only.

Offerors that intend to include classified information or data in their white paper submission or who are unsure about the appropriate classification of their white papers should contact the technical point of contact listed in Section VII for guidance and direction in advance of preparation.

c. MAILING INSTRUCTIONS.

Unclassified electronic submission to the TPOC identified in Section VII will only be accepted. Encrypt or password-protect all proprietary information prior to sending. Offerors are responsible to confirm receipt with the TPOC. AFRL is not responsible for undelivered documents. If electronic submission is used, only one copy of the documentation is required.

Questions can be directed to the TPOC listed in Section VII.

4. OTHER SUBMISSION REQUIREMENTS/CONSIDERATIONS:

a. COST SHARING OR MATCHING: Cost sharing is not a requirement. Cost sharing may be proposed and will be considered on a case-by-case basis. Cost share will not be a factor in selection for award.

b. SYSTEM FOR AWARD MANAGEMENT (SAM). Offerors must be registered in the SAM database to receive a contract award, and remain registered during performance and through final payment of any contract or agreement. Processing time for registration in SAM, which normally takes forty-eight hours, should be taken into consideration when registering. Offerors who are not already registered should consider applying for registration before submitting a proposal. The provision at FAR 52.204-7, System for Award Management (Oct 2018) applies.

c. EXECUTIVE COMPENSATION AND FIRST-TIER SUBCONTRACT/ SUBRECIPIENT AWARDS: Any contract award resulting from this announcement may contain the clause at FAR 52.204-10 - Reporting Executive Compensation and First-Tier Subcontract Awards (Jun 2020). Any grant or agreement award resulting from this announcement may contain the award term set forth in 2 CFR, Appendix A to Part 25 which can be viewed at: https://www.govinfo.gov/app/details/CFR-2012-title2-vol1/CFR-2012-title2-vol1-part25-appA.

d. ALLOWABLE CHARGES: The cost of preparing white papers/proposals in response to this announcement is not considered an allowable direct charge to any resulting contract or any other contract, but may be an allowable expense to the normal bid and proposal indirect cost specified in FAR 31.205-18. Incurring pre-award costs for ASSISTANCE INSTRUMENTS ONLY are regulated by 2 CFR part 200.458, Pre-Award Costs.

e. GOVERNMENT APPROVED ACCOUNTING SYSTEM: An offeror must have a government approved accounting system prior to award of a cost-reimbursement contract per limitations set forth in FAR 16.301-3(a) to ensure the system is adequate for determining costs applicable to the contract. The acceptability of an accounting system is determined based upon an audit performed by the Defense Contract Audit Agency (DCAA). IMPORTANT: If you do not have a DCAA approved accounting system access the following link for instructions: https://beta.sam.gov/opp/e628c811fafe041accdddf55fb8539bf/view?keywords=AFRL-BAA-Guide&sort=-relevance&index=&is_active=true&page=1

f. HUMAN USE: All research involving human subjects, to include the use of human biological specimens and human data, selected for funding must comply with Federal regulations for human subject protection. Further, research involving human subjects that is conducted or supported by the DoD must comply with 32 CFR 219, “Protection of Human Subjects” found at: http://www.access.gpo.gov/nara/cfr/waisidx_07/32cfr219_07.html, and DoD Instruction 3216.02, “Protection of Human Subjects and Adherence to Ethical Standards in DoD-Supported Research” found at: http://www.dtic.mil/whs/directives/corres/pdf/321602p.pdf.

1. Institutions awarded funding for research involving human subjects must provide documentation of a current Assurance of Compliance with Federal regulations for human subject protection, for example a Department of Health and Human Services, Office of Human Research Protection Federal Wide Assurance found at: http://www.hhs.gov/ohrp.

2. All institutions engaged in human subject research, to include subcontractors, must have a valid assurance. In addition, personnel involved in human subject research must document the completion of appropriate training for the protection of human subjects.

3. For all research that will involve human subjects in the first year or phase of the project, the institution must submit evidence of a plan for review by an institutional review board (IRB) as part of the proposal. The IRB conducting the review must be the IRB identified on the institution’s Assurance of Compliance. The protocol, separate from the proposal, must include a detailed description of the research plan, study population, risks and benefits of study participation, recruitment and consent process, data collection, and data analysis. The designated IRB should be consulted for guidance on writing the protocol. The informed consent document must comply with 32 CFR 219.116. A valid Assurance of Compliance and evidence of appropriate training by all investigators should accompany the protocol for review by the IRB.

4. In addition to a local IRB approval, an AFRL-level human subject regulatory review and approval is required for all research conducted or supported by the DoD. The Air Force office responsible for managing the award can provide guidance and information about the AFRL-level review process. Confirmation of a current Assurance of Compliance and appropriate human subjects protection training is required before AFRL-level approval can be issued.

5. The time required to complete the IRB review/approval process will vary depending on the complexity of the research and/or the level of risk to study…