HR001123S0033.pdf

Broad Agency Announcement

Business Process Logic (BPL)

DARPA I2O

HR001123S0033

April 27, 2023

TABLE OF CONTENTS

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

A. Program Overview B. Program Structure and Plan C. Program Metrics D. Government-furnished Property/Equipment/Information E. Intellectual Property F. Additional Program Information

II. Award Information A. General Award Information B. Fundamental Research

III. Eligibility Information A. Eligible Applicants B. Organizational Conflicts of Interest C. Cost Sharing/Matching D. Other Eligibility Criteria

IV. Application and Submission Information A. Address to Request Application Package B. Content and Form of Application Submission

V. Application Review Information A. Evaluation Criteria B. Review of Proposals

VI. Award Administration Information A. Selection Notices and Notifications B. Administrative and National Policy Requirements C. Reporting D. Electronic Systems E. DARPA Embedded Entrepreneurship Initiative (EEI)

VII. Agency Contacts VIII. Other Information

IX. APPENDIX 1 – CLASSIFIED ADDENDUM REQUEST FORM

X. APPENDIX 2 – PROPOSAL SUMMARY SLIDE

PART I: OVERVIEW INFORMATION

Federal Agency Name – Defense Advanced Research Projects Agency (DARPA), Information Innovation Office (I2O)

Funding Opportunity Title – Business Process Logic (BPL) Announcement Type – Initial Announcement Funding Opportunity Number – HR001123S0033 Catalog of Federal Domestic Assistance Numbers (CFDA) – Not applicable Dates o Posting Date: April 27, 2023 o Request for classified addendum due: May 4, 2023, 5:00 PM Eastern Time (ET) o Proposers Day: May 9, 2023 o Abstract Due Date and Time: May 23, 2023, 12:00 PM ET o Questions Due: June 9, 2023 o Proposal Due Date and Time: June 30, 2023, 12:00 PM ET

Program Overview – The Business Process Logic (BPL) program aims to characterize and resolve vulnerabilities in business logic systems to protect defense-critical workflows for government and business. BPL will extract representations from Business Logic (BL) and use those representations to characterize and mitigate faults and vulnerabilities identified in workflow environments. This program is not intended to find cyber vulnerabilities in the underlying BL infrastructure.

Anticipated awards – Multiple awards are anticipated. A total of up to $15.6M may be awarded across Technical Area (TA) one (1). Additional funding may be available depending upon the quality and potential of the proposals. Anticipated amounts for TA2 and TA3 can be found in the classified addendum.

Types of instruments that may be awarded – Procurement Contracts and Other Transactions.

Agency contact o Points of Contact

The BAA Coordinator for this effort can be reached at BPL@darpa.mil.

DARPA/I2O

ATTN: HR001123S0033

675 North Randolph Street Arlington, VA 22203-2114

PART II: FULL TEXT OF ANNOUNCEMENT

I. 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 enable revolutionary advances that address the security and operation of the large-scale mega-systems for manufacturing, infrastructure, and logistics in modern societies. Specifically excluded is research that primarily results in evolutionary improvements to the existing state of practice.

All proposers should read all sections of this solicitation. The technical information contained in the discussion of each individual Technical Area (TA) is relevant to the execution of all TAs.

A. Program Overview

The Business Process Logic (BPL) program will develop tools to identify logic faults and vulnerabilities in business systems that control and manage defense-critical workflows (such as manufacturing, infrastructure, and logistics) for governments and businesses around the world in order to protect those systems.

Automated workflows, written in workflow environments known as Business Logic (BL) such as SAP, Oracle, Workday, IBM Dynamics 365, or Salesforce, control most of the world’s enterprises, from administration and operation of seaports worldwide to the assembly of weapons systems. An example is the Department of Defense (DoD) Procurement Integrated Enterprise Environment (PIEE), which processes approximately 8.0% of the U.S. budget. The BPL program aims to develop tools to characterize logic faults in the high-level scripts and templates of BL systems.

Nearly all businesses with over $5M in sales use some form of BL to manage operations. It has become a necessary operating tool in the way that the telephone shifted from a technological innovation to a necessary tool in the 1920s. BL is widely used, to the point where lack of a BL system is considered a significant deficit in small business operations. The vulnerabilities and exposure to loss due to operational risk from coding errors can range from annoyances to business-threatening outcomes. Identification of potentially problematic issues such as “one-way” actions or “lost resources” would provide for increased resilience in the manufacturing and communications sectors, and reduce inefficiencies in supply chain management.

Here is a notional example of a bad outcome that can result from a logic fault: a major defense system’s final assembly requires a critical component. Recently, a batch of these components was lost in the inventory system because of a data entry error. Production of the defense system was brought to a dead stop when the inventory system reported these specialty components as unavailable. The production line shut down for two weeks, holding up completion of orders to multiple countries, with over one hundred people searching for the components before they were found – all because the inventory system that was tracking parts was faulty.

BL systems enable automation and efficiency in the operations that control an enterprise. These systems provide a simple coding environment, which enables extremely complex processes to be implemented with straightforward, uncomplicated tools that are, in essence, giant write-rarely spreadsheets. Business processes are represented in BL by a combination of visual point-and-click coding, embedded spreadsheets, and scripting languages that resemble a constrained form of Java.

BL systems are designed to support speed and flexibility for responding quickly to market needs.

In this environment, system security, robust limit- and type-checking, and exhaustive testing take a back seat to the agility required to support market needs. The scripts created are built on database technology; however, data often are duplicated without associated integrity checks.

Many of these systems are based on process documentation, such as what is contained in International Organization for Standardization (ISO) 9000 quality management systems. There is an assumption implicit in the development of workflow processes that humans will input reasonable data. As the notional example above makes glaringly clear, this assumption is faulty.

BL systems often are constructed as human-machine mega-systems, which are limited in regard to underlying science, as well as in regard to current engineering practice. Common cyber security practices are insufficient for identifying faulty business logic and current science has insufficient understanding of the behavior of human-machine mega-systems to deal with their size and scope. Scientific limitations include:

• Sub-system behavioral analysis is unavailable for large-scale systems;

• Ambiguous representations prevent a clear grasp of the intended logic;

• Bad outcomes of logic faults are described but not measured; and,

• Logic faults are not traceable to human-entered source code.

Current engineering practice also has not addressed the shaping or analysis of large-scale logic flows across system boundaries. Engineering limitations include:

• Ingestion of enterprise process flows are not automated;

• Results of high-level BL faults cannot currently be automatically characterized or cataloged;

• Data provenance is not maintained across sub-systems; and,

• Fault analysis is not currently traced across composed systems.

BPL is not intended to find cyber vulnerabilities in the underlying BL infrastructure. Efforts focused on finding underlying cyber vulnerabilities are out of scope for BPL.

B. Program Structure and Plan

Proposers may submit single proposals to TA1 and/or TA2; a combined TA1 and TA2 proposal will not be accepted. Proposals submitted to any TA must encompass all 3 Phases. Proposers are limited to submission of one proposal per TA. Proposers selected for TA3 may not perform on TA1 or TA2.

1. Program Technical Areas

BPL has three Technical Areas:

TA1: Represent and characterize logic faults;

TA2: Resolve vulnerabilities; and, TA3: Test and evaluate defense-critical workflows.

TA1: Represent and characterize logic faults

TA1 will use scalable techniques to ingest BL systems and associated documentation, such as BL system code, database schema, data dictionaries, ISO 9000 documentation, and user training documentation, to identify logic flaws or vulnerabilities in a system. The purpose of developing these representations is to be able to reason across the logic embedded in the BL system and to identify flaws or vulnerabilities. Given this objective, representations that do not support this kind of reasoning would not suffice. A challenge will be meeting the scale of the systems involved; while some BL systems support tens of users, BPL will address systems that have hundreds to tens of thousands of users. In order to support the massive scale of realistic processes that BPL will address, automatic ingestion of system data and documentation will be required to develop the BL system representations.

Unlike conventional processing environments, BL environments contain results whose interpretation depends on the way those results are formatted on the screen, with the final association of information occurring as users interpret it while interacting with the system. To understand how a high-level BL script actually operates, it is necessary to consider the visual context, the natural language being used, and the enterprise jargon.

A common characteristic of cyber security tools is their dependence on language and protocol constructs to identify data, code, and communications protocols. State-of-the-art (SOTA) cyber security tools fail with BL systems because the visual nature of BL systems does not provide the information needed to build the graphs and metadata used to explore code for faults and vulnerabilities.

BL systems are optimized for responding quickly and flexibly to market needs rather than for security and resilience. BL technology roadmaps focus on two approaches to close this gap. The first is training, which is expensive, marginally effective, and does not scale well. The second is providing a more formal automated coding environment that manages access control, data permissions, and movement of information between subsystems. Even so, neither training nor a more formal coding environment can address cognitive errors made by human scripters, such as faulty logical assumptions and inaccurate interpretation of the visual cues in the scripting environment.

BPL will develop technology to extract information from BL spreadsheets and scripts, and disambiguate that extracted information by correlating it with parsed ISO 9000 documents and user documentation. The resulting information will be fed into SOTA program analysis tools to identify logic faults or vulnerabilities and their possible mitigations. Ingestion of user documentation will allow for identification of semantic-level errors, such as one-way processes, i.e., those that cannot be rolled back. BL workflows do not represent these one-way processes as known good or bad outcomes. That assessment can be derived only from the human-readable documentation and the organizational objective functions contained in the documentation. An example of a one-way process would be deprovisioning all telephone circuits belonging to a customer that failed to pay for service. If it turns out that the customer’s bills were in fact paid, and the report of failure-to-pay was an error, there is no way to undo the deprovisioning, because all supporting information is lost when a telecom circuit is deprovisioned. Another type of error is loss of data consistency, which may result from multiple representations of the same data becoming disconnected. Loss of data consistency may occur when processes designed to catch instances of, say, faulty duplication of database subsets, fail to do so. Copies of information that are cached by warehouse management systems can lose synchronization with inventory management systems. The result of the mismatch leads to lost components or “surprise” shortages of parts. These kinds of data consistency errors can be identified by reasoning over the multiple, differing, versions of dataset-modifying processes that may be present in system documentation. More importantly, errors in data consistency also can be detected by reasoning over multiple versions of these processes that may have been implemented and are running within the operating BL system.

The ingestion and system mapping tasks of TA1 can be performed as fundamental research. TA1 is anticipated to be operating on a commercial system, and, as a result, analysis outputs that identify system flaws would be Controlled Unclassified Information (CUI).

Strong TA1 proposals will:

Address operational considerations of a large BL system and offer a team with deep expertise in the daily operational use of BL systems.

Demonstrate an understanding of BL both from a theoretical computer science perspective and from an operational perspective.

Demonstrate an understanding of how to automatically build reasoning representations for common scripting languages and software that is based on visual programming methods.

Identify mechanisms for integrating representations for user and ISO documentation with representations for software systems and their operation.

Demonstrate an ability to explore very large operational spaces to produce actionable results in a short period of time. An actionable result at a minimum would include existence, location, and severity of characterized BL faults.

Provide detailed plans for how the developed technology will transition into industrial use.

Provide innovative teaming of researchers that may include universities, commercial industry, the Defense Industrial Base (DIB), and other organizations with expertise in

BL.

Substantiate all claims about capabilities or achievements.

TA1 will deliver the following artifacts to TA3, along with documentation and the associated data in machine-readable form, prior to each of the tests in Figure 1:

A representation of the BL workflows found in the system under test and extracted from human-readable documentation and human-entered code. The extracted representation should include system topology and workflows between systems of systems.

Characterizations of BL faults including details about the type of fault, the location of the fault in the system (i.e., module affected), and a measure of severity of the fault. TA3 will evaluate these faults for accuracy against a TA3-provided list of known faults. TA3 also will evaluate the quality and validity of previously unknown faults through a mechanism such as Lot Acceptance Testing (see Section I.C for more details around metric measurement).

A demonstratable user interface to convey existence, location, and severity of BL faults to a user.

TA2: Resolve vulnerabilities

TA2 will be responsible for resolving identified vulnerabilities in the BL systems under test.

Performers will develop approaches to trace logic faults to human-entered code, characterize/catalog high-level BL faults, maintain data provenance across sub-systems, trace fault analysis across component interdependencies, and provide mitigations that do not introduce new BL faults. TA2 performers must be able to receive and process controlled and classified information on system vulnerabilities.

Additional information about TA2 can be found in the classified addendum. Instructions on requesting the addendum can be found in Section IV.B of this BAA (“Application and Submission Information – Content and Form of Application Submission”).

TA3: Test and evaluate defense-critical workflows

TA3 will provide representative Defense Industrial Base (DIB) platforms for test and evaluation using existing platforms with operational software. The performer will provide access to unmodified documentation: ISO 9000, user guides, training material, and well-documented lists of known logic and operational flaws/bugs. The test systems will be implemented in at least one major BL platform environment. TA3 will be responsible for validating TA1 and TA2 solutions and capabilities. TA3 will manage a collaboration site where TA1 will submit all identified logic faults and vulnerabilities. TA3 will also act to inform the DIB of flaws and issues detected.

Additional information about TA3 can be found in the classified addendum. Instructions on requesting the addendum can be found in Section IV.B of this BAA (“Application and Submission Information – Content and Form of Application Submission”).

2. Program Schedule

BPL is a 48-month, 3-phase program. Phases 1 and 2 are each 18-months and Phase 3 is 12-months. A go/no-go decision will occur after Phase 2, for the execution of Phase 3 of the program, based on the acceptance by a transition partner of the technology developed in the first two phases.

During Phase 1, performers will have access to an initial test platform, anticipated to be a representative DIB manufacturing BL system. The goal of Phase 1 is to demonstrate the feasibility of performer technical approaches. Phase 2 will introduce a second test platform, also anticipated to be a representative DIB logistics BL system. The goal of Phase 2 is to demonstrate that the effectiveness of performers’ technical approaches can be reproduced on a different test platform with a different type of critical workflow. TA3 will provide information for each of these platforms, including unmodified documentation, such as ISO 9000 documents, user guides, and training materials. TA3 also will provide TA1 and TA2 performers with the software and licenses needed to operate the test system or a TA3-supported operating environment. TA1 and TA2 proposers are encouraged to describe any additional information they plan to use in detecting and characterizing flaws. Finally, Phase 3 is contingent on transition partner acceptance of the technology developed in the first two phases and will focus on a transition-relevant BL system.

Figure 1: BPL Program Schedule C. Program Metrics

The following program metrics for TA1 will serve as one basis for determining whether satisfactory progress is being made to warrant continued funding of the program (Table 1).

Although the following program metrics are specified, proposers should note that the Government has identified these goals with the intention of bounding the scope of effort, while affording the maximum flexibility, creativity, and innovation in the proposing solutions to the stated problem.

Proposals should cite the quantitative and qualitative success criteria, per Phase, that the proposed effort will achieve. Those measurements will be conducted at test events illustrated above in Figure 1.

TA3 will provide, for use in test and evaluation, a well-documented list of known logic and operational flaws for the TA3-provided test system and will maintain a list of BL faults known to be present in the system under test; these faults will be detectable by analysis of TA3-provided documentation and scripts. TA3 will evaluate TA1 on coverage of BL workflows by comparing TA3’s list of known faults with the list of faults found by TA1. The documentation and scripts provided by TA3 will constitute ground truth for fault detection. In addition to being evaluated on fault detection, TA1 also will be evaluated by TA3 on accuracy of characterization of those faults.

It is anticipated that TA1 will identify additional, previously-unknown BL faults in the system under test. To measure the quality and validity of these newly-discovered faults, TA3 will provide a mechanism for automated test and evaluation; an example of one such mechanism is Lot Acceptance Testing (LAT). See Figure 2 for an example of LAT as applied to validating TA1-characterized BL faults.

Immediately following each test event, TA3 will provide evaluation of the accuracy, reproducibility, location, and severity of TA1’s characterization of both previously-known and newly-discovered faults.

Table 1: BPL TA1 Metrics

Figure 2: Lot Acceptance Testing process used to evaluate claimed BL faults.

Details on TA2 metrics are contained in the classified addendum. Instructions on requesting the addendum can be found in Section IV.B of this BAA (“Application and Submission Information

– Content and Form of Application Submission”).

D. Government-furnished Property/Equipment/Information

The Government, through TA3, anticipates providing information on Government test platforms that may be under test in Phases 2 and 3. In describing their technical approaches, proposers may assume the Government will provide BL spreadsheets and scripts, ISO 9000 documents, and user documentation, as well as any necessary software and licenses. TA3 will be responsible for providing this information in Phase 1.

Proposers are encouraged to propose any additional, external information or data that would be useful in developing their proposed technologies.

E. Intellectual Property

A key goal of the program will be to share information about identified flaws in commercial BL systems with industry participants. The Government also encourages commercialization strategies for the TA1, TA2, and TA3 developed technologies. Intellectual property rights asserted by proposers are strongly encouraged to be aligned with the program goals.

It is desired that all noncommercial software (including source code), software documentation, and technical data generated by the program be provided as deliverables to the Government, with a minimum of Government Purpose Rights (GPR), as lesser rights may adversely impact the program’s ability to resolve vulnerabilities in commercial and government BL systems.

The testing environments and transition environments may contain proprietary intellectual property that would be shared with BPL performers. Performers will be required to sign Associate Contractor Agreements (ACA) to protect proprietary information and to use the information only for BPL research. TA3 will be responsible for leading ACA negotiations with all selected performers.

F. Additional Program Information

To facilitate the exchanging of ideas, sharing of research, and management of the program, performers must be able to provide a video teleconference capability, such as Zoom, that can support Controlled Unclassified Information (CUI) in accordance with National Institute of Standard and Technology (NIST) SP 800-171. Performers should expect to host at least one demonstration at their facility; the facility must have the capability to hold up to 20 people.

II. Award Information

A. 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 IV.B.3.d, “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, whether or not the research is classified as Fundamental Research, 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. § 4022(f), the Government may award a follow-on production contract or Other Transaction (OT) for any OT awarded under this solicitation 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 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

B. 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:

http://www.darpa.mil/work-with-us/contract-management#OtherTransactions

‘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 solicitation, the Government expects that program goals as described herein may be met by proposed efforts for fundamental research and non-fundamental research. Some proposed research may present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Based on the anticipated type of proposer (e.g., university or industry) and the nature of the solicited work, the Government expects that some awards will include 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.

III. Eligibility Information

A. Eligible Applicants

All responsible sources capable of satisfying the Government's needs may submit a proposal that shall be considered by DARPA. Historically Black Colleges and Universities, Small Businesses, Small Disadvantaged Businesses and Minority Institutions are encouraged to submit proposals and join others in submitting proposals; however, no portion of this announcement will be set aside for these organizations’ participation due to the impracticality of reserving discrete or severable areas of this research for exclusive competition among these entities.

1. Federally Funded Research and Development Centers (FFRDCs) and Government Entities http://www.darpa.mil/work-with-us/additional-baa

a) FFRDCs FFRDCs are subject to applicable direct competition limitations and cannot propose to this solicitation 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.

b) 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.

c) 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.§ 4892 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.

2. Other Applicants Non-U.S. organizations and/or individuals may participate to the extent that such participants comply with any necessary nondisclosure agreements, security regulations, export control laws, and other governing statutes applicable under the circumstances.

B. 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 solicitation. 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 solicitation 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.

C. 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.

D. Other Eligibility Criteria

TA1 proposals must demonstrate the ability to deliver work product classified up to the SECRET level on identified BL vulnerabilities. TA1 proposals must demonstrate the ability to execute work at the SECRET level and access only TOP SECRET information in time to commence program execution in accordance with their proposed statement of work (SOW), no later than sixty (60) calendar days after contract award. This includes:

1. A sufficient number of key management personnel with personnel security clearances at the TOP SECRET level with eligibility for SCI access;

2. A sufficient number of key management personnel and staff with personnel security clearances at the SECRET level;

3. The ability for at least one team member facility to obtain a TOP SECRET facility clearance with SECRET safeguarding or access within (60) days of contract award;

4. The ability to establish an Automated Information System (AIS) approved to operate at the SECRET level by the Defense Counterintelligence and Security Agency (DSCA);

and,

5. The ability to safeguard CUI information and separate fundamental research tasks/ team members from CUI tasks (See BPL CUI Guide).

TA2 and TA3 proposals must demonstrate the ability to deliver work product at the TOP SECRET level in time to commence program execution in accordance with their statement of work (SOW), no later than sixty (60) calendar days after contract award. This includes:

1. A sufficient number of key management personnel and staff with personnel security clearances at the TOP SECRET level with eligibility for SCI access;

2. The ability for at least one team member facility to obtain a TOP SECRET facility clearance with TOP SECRET safeguarding or access to a “carved out” accredited Security Compartmented Information Facility (SCIF);

3. The ability to establish an Automated Information System (AIS) approved to operate at the TOP SECRET level by the Defense Counterintelligence and Security Agency (DCSA) or be able to leverage an existing accredited TOP SECRET/SCI system; and,

4. The ability to safeguard CUI information and separate fundamental research tasks/ team members from CUI tasks (See BPL CUI Guide).

IV. Application and Submission Information

A. 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 BPL team at BPL@darpa.mil.

B. Content and Form of Application Submission

All submissions, including abstracts and proposals, must be written in English using Times New Roman typeface with font size not smaller than 12-point, with margins no smaller than 1 inch.

Font sizes of 8 or 10 may be used for figures, tables, and charts in the Technical Volume, but not http://www.darpa.mil/ mailto:BPL@darpa.mil for text or tables in the summary slide. Document files must be in .pdf, .doc, .docx, .xls, or .xlsx formats, with the exception of the Summary Slide, which must be in .ppt or .pptx format. All pages must be numbered. Line spacing should be no less than 12-pt (single-spacing).

All documents submitted must be clearly labeled with the DARPA BAA number, proposer organization, and proposal title/proposal short title. All monetary references in the proposal shall be in U.S. Dollars.

The TA2 and TA3 efforts solicited by this BAA are expected to produce proposals classified at the SECRET level and will involve access to or generation of classified information. A formal request for the classified addendum and classification guidance may be submitted by filling out the HR001123S0033 REQUEST FORM (APPENDIX 1) and emailing the REQUEST FORM to BPL@darpa.mil with the subject line titled “Request DARPA-BAA-HR001123S0033”.

TA2 and TA3 proposers that are incorporating sub-contractor team members into their proposal to perform classified proposal preparation must submit subcontractor DD-254s to BPL@darpa.mil no later than June 1, 2023 or prior to sharing classified information with other companies.

Classified proposal teams will be limited to 5 work locations (Prime contractor + 4 alternate or subcontractor work locations). One copy of the classified addendum will be transmitted by DARPA to a single location only per proposal team.

Proposers are required to submit the classified addendum request no later than May 4, 2023 at 5:00 PM ET to allow adequate time for delivery of the material to be shipped by May 10, 2023.

Requests submitted after this date will be disregarded. The HR001123S0033 REQUEST FORM is the only method of request that will be accepted. Only fully completed forms will be processed. All requestors will receive a confirmation email with either a delivery tracking number or email confirmation depending on delivery method. Proof of facility clearance level must be validated by the DARPA Program Security point of contact before any classified documentation on the BAA is sent to the proposer.

The full HR001123S0033 Classified Addendum consists of: a SECRET CD which includes BAA DD254 (DoD Contract Security Classification Specification), a security classification guide (SCG), and a paper copy of the Classified Addendum.

Please state on the classified addendum request form (see APPENDIX 1) if you need the entire packet in paper form only. All other packets will be sent as a SECRET CD containing the classified addendum and SCG. If you have trouble reading the CD or its contents, please email BPL@darpa.mil as soon as possible to request the packet in paper form. Proposers requesting the classified addendum must currently possess at a minimum a SECRET facility clearance with SECRET safeguarding. All appropriate security safeguards must exist prior to receiving the classified addendum. No extension of the proposal due date will be granted based on inability to acquire Facility Clearances in a reasonable timeframe.

mailto:BPL@darpa.mil

Classified submissions shall be appropriately and conspicuously marked with the proposed classification level and declassification date. Submissions requiring DARPA to make a final classification shall be marked as follows:

CLASSIFICATION DETERMINATION PENDING. Protect as though classified (insert the recommended classification level: (e.g., Top Secret, Secret or Confidential)

1. Abstracts Format

Proposers are strongly encouraged to submit an abstract in advance of a full proposal. Abstracts should follow the same general format as described for proposals (see Section IV.B.2., “Proposals Format”) but include ONLY Sections I and II of Volume I, Technical and Management Proposal. The cover sheet should be clearly marked “ABSTRACT,” and the total length must not exceed 4 pages. The maximum pages count excludes the cover page and official transmittal letter but does include any figures, tables, and charts. An official transmittal letter is not required. Bracketed numbers below denote recommended page limits for each section of the abstract.

Abstracts must include the following components:

Cover Sheet: Provide the administrative and technical points of contact (title, name, address, phone, email, organization). Include the BAA number, title of the proposed project (not the BAA title), Technical Area, subcontractors, estimated cost, duration of the project, and the label “Abstract.”

Goals and Impact: {1.0} Describe what is being proposed and how, if successful, it will lead to a broad solution (qualitatively and quantitatively) for identifying vulnerabilities in business systems that control and manage defense-critical workflows. This section should succinctly describe the uniqueness and benefits of the proposed approach relative to current state-of-art approaches. Describe a clear and detailed path to transition with a specific transition partner, including a description of the current working relationship with that potential transition partner.

Technical Plan: {2.5} Outline and address all technical challenges inherent in the approach and possible solutions for overcoming potential problems. Describe milestones and how they will be achieved.

Capabilities/Management Plan: {0.25} Provide a brief summary of expertise of the team, including subcontractors and key personnel. Include a brief description of relevant expertise in large-scale business logic, manufacturing or infrastructure systems, natural language processing, automated system mapping, and automated system analysis. Identify the principal investigator and include a one-sentence summary of the team’s organization, including roles and responsibilities.

Cost and Schedule: {0.25} Provide a cost estimate by phase, broken out by labor, materials, travel, and a ROM for each subcontractor. Include a list of deliverables and a delivery schedule.

2. Proposals Format

All proposals must be in the format given below. The typical proposal should express a consolidated effort in support of one or more related technical concepts or ideas. Disjointed efforts should not be included into a single proposal. Proposals shall consist of two volumes: 1) Volume I, Technical and Management Proposal (composed of 3 parts), and 2) Volume II, Cost Proposal. Volume I is limited to 28 pages. The maximum pages count for Volume I excludes the cover page, required summary slide, and official transmittal letter, but does include figures, tables, and charts. Bracketed numbers before each section denote recommended page limits.

NOTE: Non-conforming submissions that do not follow the instructions herein may be rejected without further review.

a) Volume I, Technical and Management Proposal

(1) Section I: Administrative

(a) Cover Sheet to Include

(1) BAA number (DARPA-BAA- HR001123S0033);

(2) Technical area;

(3) Lead Organization submitting proposal;

(4) Type of organization, selected among the following categories: “LARGE BUSINESS”, “SMALL DISADVANTAGED BUSINESS”, “OTHER SMALL BUSINESS”, “HBCU”, “MI”, “OTHER EDUCATIONAL”, OR “OTHER NONPROFIT”;

(5) Proposer’s 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, telephone, fax (if available), electronic mail (if available);

(9) Administrative point of contact to include: salutation, last name, first name, street address, city, state, zip code, telephone, fax (if available), electronic mail (if available);

(10) Total funds requested from DARPA, and the amount of cost share (if any); AND

(11) Date proposal was submitted.

(b) Official transmittal letter

(2) Section II: Summary of Proposal

A. {4} Technical rationale, technical approach, and constructive plan for accomplishment of technical goals in support of innovative claims and deliverable creation. (In the full proposal, this section should be supplemented by a more detailed plan in Section III of the Technical and Management Proposal.)

B. {4} Innovative claims for the proposed research. This section is the centerpiece of the proposal and should succinctly describe the uniqueness and benefits of the proposed approach relative to the current state-of-art alternate approaches.

C. {2} Deliverables associated with the proposed research and the plans and capability to accomplish technology transition and commercialization. Include in this section all proprietary claims to the results, prototypes, intellectual property, or systems supporting and/or necessary for the use of the research, results, and/or prototype. If there are no proprietary claims, this should be stated. For forms to be completed regarding intellectual property, see SectionIV.B.3.i of this BAA. There will be no page limit for the listed forms.

D. {1} General discussion of other research in this area.

E. {1} A clearly defined organization chart for the program team which includes, as applicable:

(1) the programmatic relationship of team member; (2) the unique capabilities of team members; (3) the task of responsibilities of team members; (4) the teaming strategy among the team members; (5) the principal investigator (PI), co-PI, and program manager (if applicable) for each team member to include subcontractor’s PI, co-PI, and program manager; and (6) the key personnel along with the amount of effort to be expended by each person during each year.

F. A summary slide of the proposed effort, in PowerPoint format, should be submitted with the proposal. Submit this file in PowerPoint format in addition to Volumes 1 and 2 of the full proposal. The format for the summary slide is included in APPENDIX 2 to this BAA and does not count against the page limit.

(3) Section III: Detailed Proposal Information

A. {3} Statement of Work (SOW) - Clearly define the technical tasks/subtasks to be performed, their durations, and dependencies among them. The page length for the SOW will be dependent on the amount of the effort. For each task/subtask, provide:

A general description of the objective (for each defined task/activity);

A detailed description of the approach to be taken to accomplish each defined task/activity;

Identification of the primary organization responsible for task execution (prime, sub, team member, by name, etc.);

The completion criteria for each task/activity - a product, event or milestone that defines its completion;

Define all deliverables (reporting, data, reports, software, etc.) to be provided to the Government in support of the proposed research tasks/activities; and Clearly identify any tasks/subtasks (to be performed by either an awardee or subawardee) that will be accomplished on-campus at a university, if applicable.

Note: It is recommended that the SOW should be developed so that each Phase of the program is separately defined.

Do not include any proprietary information in the SOW.

B. {1.5} Description of the results, products, transferable technology, and expected technology transfer path to supplement information included in the summary of the proposal.