Multi – DASH CLOSED CALL (SOO) BattleCOA Production (PAE, MEF, GBC Decision Functions)

1.0 OBJECTIVE

The Joint All Domain Persistent Adaptive Collaborative Technologies (JADPACT) Project seeks to develop Human-Machine Teaming (HMT) concepts that leverage AI/Automation capabilities to support Battle Managers. C2 Decision Advantage events provide support for the ABMS Transformational Model decision functions and an opportunity to learn about and explore many different AI/automation approaches for Battle Management. Furthermore, the events and R&D aim to ensure warfighter involvement in the development of AI/autonomy and further identify areas where AI augmentation would support Battle Managers. The goal is to include industry to ensure work being done to develop and adapt the latest, cutting-edge AI/automation approaches can be leveraged and adapted to the needs of Battle Managers. This will be accomplished by seeking unique and innovative solutions to accomplish the defined technical requirements.

2.0 SCOPE

The Combined Joint All-Domain Command and Control (CJADC2) Campaign Plan 2030 defines decision advantage as the ability to consistently make better, timelier decisions than the adversary. Current DAF command and control (C2) systems and processes are optimized for low intensity conflict and do not address decision advantage over the pacing challenge. Deriving effective C2 capability development toward decision advantage requires a clear understanding of what C2 decisions are. The DAF Advanced Battle Management System (ABMS) Cross Functional Team (CFT) provides a quantitative model for the Joint Warfighting Function of C2 as the Command, Plan, and Battle Management decision domains, supported by and integrated with Battle Analysis (military intelligence and surveillance). Each of these decision domains are decomposed in the Transformational Model for Decision Advantage (TM-DA) using model-based systems engineering to bridge the gap between operational concepts and software design.

2.1 TRANSFORMATION MODEL

The TM describes military decisions being made within a human-machine team (HMT), including specific choices within these domains and the battlespace information needed to inform said choices. Therefore, the TM provides foundational requirements for C2 decision-making that are universal (agnostic to time epoch, process, geography, organization, doctrine, weapon systems, among others). Additional information on the TMs can be found at: SAM.gov The TM-DA domain of Battle Management (TM-DA.BM) is comprised of 13 distinct and orthogonal subfunctions (Figure 1) deduced from the following operational environment (OE) assumptions/axioms:

Figure 1: Transformational Model – Battle Management Subfunctions.

In OEs where these assumptions apply (which will be the case for the pacing challenge), the TM-DA.BM subfunctions explain the comprehensive set of battlespace information elements and decisions an HMT must make to battle manage the OE. Consequently, the TM-DA.BM reveals measures of performance and gives structure to a design of experiments (DOE) that best characterize a battle management HMT. The resulting analysis delivers C2 decision advantage requirements to military capability developers and acquisition professionals through rigorous defensible analysis.

2.2 The BATTLECOA Production Ensemble

The TM-DA does not describe or prescribe a linear process for decision-making. Instead it reflects the reality of military decision making in combat: dynamic and unpredictable simultaneous cycles and epicycles of highly coupled reasoning chains contingent on specific contexts. Within complex/chaotic OEs, there are patterns of decision-making that repeat more frequently than others. Those patterns are called Decision Function Ensembles. The BattleCOA Production Ensemble is a common partially-ordered iteration through three Battle Management Decision Functions (Perceive Actionable Entity - PAE, Match Effectors - MEF, and Generate BattleCOA - GBC) which is associated with publication of complete BattleCOAs to be considered for sequencing, implementation, and execution. Each instance of a BattleCOA Production Ensemble starts with an EntityOfInterest (EoI, e.g., a new dynamic target, a new friendly support request, etc.) as the trigger input (into PAE), and produces BattleCOAs (out of GBC, e.g., various force packages with gameplans to achieve commander intent) for that EoI. In accordance with the systems engineering best practice of favoring re-use over duplication, the BattleCOA Production ensemble arises from the dependency of GBC to iterate through PAE and MEF to create new graph nodes (“BattleEvents”) that constitute a fully developed BattleCOA.

PAE takes in potential new targets/support requests (EntityOfInterest – EoI) and guidance/objectives/plans (i.e., “BattleGoals”), along with other contextual information, and produces effect options (“BattleEffects”), i.e, potential assignable tasks like “track cruise missile”, “sink ship”, “jam radar”, “hack server”, “protect convoy”, etc. PAE can output multiple BattleEffects per EOI, e.g., “damage/destroy radar” and “jam radar” could both be output BattleEffects for the same EOI. MEF takes in candidate BattleEffects (from PAE), along with other contextual information, and identifies potential units/formations (EffectEffectorMatches) that can be tasked to prosecute the input BattleEffect, e.g., for the “sink ship” effect, a particular bomber airborne in the OE is a potential match, but so is a destroyer with surface-to-surface missiles, and they may be ranked by the likely success of their munitions, time to prosecute the target, etc. GBC takes in an EffectEffectorMatch (from MEF) along with other contextual information, and builds a force package with gameplan (i.e., a “BattleCOA”) to transform a potential tasking into a well-integrated feasible set of actions that help achieve the commander’s intent. In the course of “growing” a BattleCOA around the seed of a Principal EffectEffectorMatch, GBC “calls” PAE-to-MEF, i.e., triggers a cycle through those decision functions to fill in details about additional participants and actions in a BattleCOA, e.g., if there are enemy fighters in the vicinity of a strike route, GBC will call PAE to provide options which in turn will trigger MEF to consider candidates to resolve that problem, such as with a set of escort fighters that can be added to the Principal Effector’s force package. More detailed descriptions of PAE, MEF, and GBC can be found at the following URLs on SAM.gov (PAE Link ,MEF Link, GBC Link).

Because BattleCOA production involves three Decision Functions (PAE, MEF, and GBC), particular knowledge elements created or updated as part of the cognitive (or computational) process of publishing complete and good-quality BattleCOAs:

· An understanding of operational limits (OpsLimits), i.e., restraints and constraints on actions against targets (applied in PAE) and use of scarce resources (applied in MEF).

· An understanding of the fleeting nature of certain targets/tasks (“TimeWindows” inferred in PAE).

· An understanding of the variability in how well any particular action satisfies (or counteracts) a BattleGoal (goal coupling inferred in PAE).

· A comparison between different solutions for BattleEffects (Effector Rankings chosen in MEF)

· Optionality available within individual BattleCOAs (COAPaths created in GBC).

· Deviations from pre-planned missions (PlannedCOAs) necessitated by changes in a complex/chaotic OE (inferred in GBC).

· Pros and cons associated with implementation of a BattleCOA (inferred in GBC).

While not all ensembles are ordered, BattleCOA Production follows the cycle of PAE – to – MEF – to – GBC repeating with the following nuances. BattleCOA Production begins with an Entity Of Interest (EoI) (published by the Battle Management Decision Function of Improve Situational Understanding – ISU) that triggers an instance of PAE. Note that this one initial trigger EoI can and often will spawn multiple strings of BattleCOA Production. This is because that first instance of PAE can output multiple candidate effects (“BattleEffects”) for one EoI. Each of those BattleEffects trigger their own instances of MEF, which can each produce multiple candidate units/platforms to consider for tasking (i.e., “EffectEffectorMatches”). Each of those EffectEffectorMatches then triggers its own instance of GBC to perform the necessary force packaging to support the “Principal Effector” from the first input EffectEffectorMatch. (The first EffectEffectorMatch that triggers a new GBC instance is called the “Principal EffectEffectorMatch” which indexes the unique BattleCOA for that input.) The combinatorial explosion possible even in a modestly sized operation with multiple effects branching into multiple candidate taskings is one of the urgent drivers of the need for human-machine teaming. Now with potentially many independent BattleCOA Production strings running (in series for a single human operator, in parallel with machine augmentation), each GBC instance will call the PAE-MEF-GBC loop multiple times, but this loop terminates back in the requesting GBC instance, as opposed to spawning new BattleCOA Production cycles (this might be implemented as an application of the common software design element of a “promise”).

Consider the following simple example (note: for this example, Decision Function instances will be indexed with capital letters and numbers while information inputs/outputs will be indexed with lower-case letters and numbers, those indices are illustrative only and will be replaced by names and UUIDs in the schema for the M–DASH, the example ignores potential computational efficiencies to illustrate the flow of information conceptually, and is not meant to imply kinetic-only operations; these Decision Functions apply to mutli-/all-domain ops):

Some new dynamic target “EoI x” triggers an instance of PAE (for bookkeeping purposes this instance of PAE is indexed as PAE.X).

PAE.X subsequently streams a set of three candidate BattleEffects: e1.x, e2.x, and e3.x. (The number of outputs here is arbitrary—neither PAE nor MEF are limited in principle to any number of outputs—but provides an illustration on the potential for combinatorial explosion).

Each of those output BattleEffects become input triggers for three new instances of MEF: MEF.E1.X, MEF.E2.X, and MEF.E3.X.

Each of those instances of MEF publishes three candidate strikers (i.e., potentially taskable units) resulting in nine total candidate strikers: f11.e1.x, f12.e1.x, f13.e1.x, f21.e2.x, f22.e2.x, f23.e2.x, f31.e3.x, f32.e3.x, f33.e3.x. Candidate “strikers” could be any platform/unit with any capability that achieves the associated (indexed) BattleEffect, e.g., sensors, explosive munitions, jammers, cyber weapons, decision-makers (i.e., C2 of C2), etc.

Each of the nine potentially taskable units paired to a specific effect become “Principal EffectEffectorMatches” that each trigger their own instance of GBC, i.e., there are now nine BattleCOA Production Ensemble instances available to reason through (in series or parallel depending on the HMT configuration). The example will now follow just one of those ensemble strings to illustrate the need for modular and scalable solutions for Decision Functions.

Consider the GBC instance indexed by its Principal EffectEffectorMatch, GBC.F11.E1.X:

Suppose this instance of GBC assesses that some form of threat mitigation is needed against a particular enemy system that presents an obstacle (e.g., a surface-to-air missile system protecting the principal target, a.k.a., the “Actionable”). GBC.F11.E1.X triggers a new instance of PAE with an EntityOfInterest (the SAM system) and a BattleGoal (uncontested strike route). This new instance of PAE, “PAE1001.GBC.F11.E1.X” is different from the first instance of PAE (“PAE.X”), because it is reasoning over a different EoI and different set of goals. PAE.1001.GBC.F11.E1.X outputs candidate BattleEffects indexed as e101.pae1001.gbc.f11.e1.x, and so on. Each of those BattleEffects trigger MEF with unique indices (e.g., MEF.E101.PAE1001.GBC.F11.E1.X with EffectEffectorMatches indexed as f101011.e101.pae1001.gbc.f11.e1.x, etc.) those EffectEffectorMatches route back into the GBC instance GBC.F11.E1.X (as opposed to spawning new production strings) as promises for this specific BattleCOA Production string providing potential taskable units that may be able to mitigate the SAM threat (perhaps through a kinetic attack, jamming, etc.). GBC.F11.E1.X will continue to send requests and the need to keep track of the promise loops is evident as a new request could be generated while the instance of GBC is still waiting for an answer from a previous request to PAE, and while other instances of GBC are asking for their own inputs from the PAE-to-MEF-back-to-GBC cycle. Take note of the fact that the exact same kind of reasoning (i.e., Decision Functions) is necessary to come up with a Principal EffectEffectorMatch and to come up with any supporting elements in the strike package: there’s a problem to be solved (EoI) and goals to achieve (BattleGoals) that result in potential tasks (BattleEffects) which may be accomplished by particular units/systems (EffectEffectorMatches). The nuance is that, associated with an instance of GBC, the ensemble delivers those potential EffectEffectorMatch solutions back to that instance of GBC instead of spawning new ensemble strings.

2.2.1 The Core Information Transformations of the BattleCOA Production Ensemble A successful product for the BattleCOA Production Ensemble must demonstrate the ability to continuously the following information categories and keep track of separate production strings to produce coherent BattleCOA outputs.

Input Data (What the software receives) The Transformation (What the software must do) Output Data (What the software produces)

Entities of Interest (i.e., new dynamic targets and requests for support):

The trigger to establish and run multiple BattleCOA Production strings.

Establish and iterate BattleCOA Production:

The system must identify Principal EffectEffectorMatches and run the BattleCOA Production Ensemble on each to quickly produce high-quality and complete BattleCOAs.

Complete, viable, and measured BattleCOAs that, as a set, represent the fully explored solutions space for the original input EoI: viable BattleCOAs contain optionality (COAPaths) and provide coherent and implementable force package gameplans.

Current Activities:

Probabilistic models of what is happening + the current states of assets and their associated activities (i.e., in the on-going sequence of BattleCOAs) via structured and unstructured data sources.

Analysis, Refinement, & Estimation:

The system must use contextual information from the current situation (i.e., the BattleCOAs currently being implemented) and enemy/neutral-third-party activities Cost/Benefit Assessments: Quantified options with predictions of the gains and losses (pros and cons) if an option were to be implemented

Guidance and Plans:

Pre-mission guidance (including operational limits and decision weights) and plans (including force dispositions and Joint Tasking Orders) as well as real-time updates to both via unstructured data (i.e., chat) Multi-Objective Sorting:

The system must apply multiple measures to BattleCOAs including material, non-material, and opportunity gains and losses, up-side and down-side risk, and success and failure modes Best BattleCOAs for Sequencing:

A subset of physically plausible, tactically valid BattleCOAs which, if implemented, would achieve the most utility

2.2.2 Required Functional Capabilities

To achieve the necessary information transformations for the three Decision Functions of the BattleCOA Production Ensemble, the system must perform the following computational tasks. Contractors must demonstrate how their software service models and manipulates the following variables:

1. Parsing structured and unstructured data for Entities of Interest, Resources, Goals, and Context:

· The software integrates and updates entity states from multiple sources.

· Example Application: Recognizing that a data link track (with location and activity information) is the same entity as one mentioned in a chat message (with resource, e.g., fuel state, data) and combining both sets of data into a coherent entity state.

2. Rapidly producing complete BattleCOAs with built-in optionality (i.e., more than one COAPath in a BattleCOA):

· The software service understands how to index individual BattleCOAs and their constituent COAPaths, and can build a multi-COAPath BattleCOA to provide down-stream decision makers with options during implementation.

· Example Application: A BattleCOA to conduct Electronic Attack on a drone swarm contains a COAPath with heavy escort assets and a “leaner” option COAPath where the jamming platform performs self-protection.

3. Tracking multiple BattleCOA Production strings and correctly tagging the inputs/outputs as members of a particular string:

· The software service tracks the combinatorial growth from an initial EntityOfInterest to potentially multiple BattleEffects, each with potentially multiple EffectEffectorMatches, and BattleCOA generation which may have any number of iterations through the PAE-MEF-GBC cycle.

· Example Application: EntityOfInterest X results in 3 BattleEffects, 7 EffectEffectorMatches for 7 BattleCOAs which in turn have multiple iterations through PAE and MEF back to the requesting GBC instance to build out complete BattleCOAs for each of the seven principal EffectEffectorMatches.

4. Publishing intermediate products from PAE (BattleEffects) and MEF (ranked EffectEffectorMatches):

· The software service publishes the BattleEffects considered for asset matching and the EffectEffectorMatches considered for either BattleCOA generation or tasking within a BattleCOA, all appropriately tagged so they can be grouped into their respective production strings.

· Example Application: As part of a promise interaction with a particular instance of GBC, MEF provides that GBC instance a list of 5 potential EffectEffectorMatches and simultaneously publishes those matches to the government decision orchestration service for logging, even if, that instance of GBC ultimately only incorporates 2 of the 5 into the BattleCOA it is building.

2.2.3 Boundaries

The following functional boundaries must be considered:

· BattleCOA Production is a Solution-Space Explorer, NOT a solution chooser: The BattleCOA Production Ensemble’s job is to provide as many good-quality BattleCOAs as quickly as possible for downstream Decision Functions (primarily Sequence BattleCOAs) to choose from integrate, implement, and execute. BattleCOA Production services should not discard potential solutions simply because a resource may already be tasked. Assets can be re-tasked as objectives evolve with the battle. BattleCOA Production services should make decision-makers aware of realm-of-the-possible solutions available for selection without presupposing any particular bias toward on-going activities.

· BattleCOAs (and their constituent COAPaths) are indexed by their Principal EffectEffectorMatch : A core utility the software service provides is the ability to mathematically or logically justify the "costs and consequences" as well as benefits of pivoting between gameplans of gameplans (i.e., Integrated BattleCOA Sequences).

2.3 Scenario Context for BattleCOA Production The Contested Maritime Chokepoint Imagine a highly chaotic, experimental battlespace in a contested maritime chokepoint where adversary tactics are shifting unpredictably, and sensor data and communications are heavily degraded by intermittent electronic warfare. A BattleCOA Production software service becomes aware of new potential targets and friendly requests for support that have emerged from the dynamic fight. There is a strike package marshalling in the North, tasked in accordance with the daily Joint Tasking Order to strike a drone production facility in enemy territory. There is also a set of fighters with tanker support responding to a friendly ship-in-distress situation. One of the on-orbit sensing constellations is about to shift configurations to conduct surveillance in the south of the area of operations. There are other forces arrayed throughout the area of operation and the adversary is moving to counter the on-going missions. A ship previously thought to be a commercial vessel is identified as an enemy destroyer. At the same time, a liaison unit with an allied ground assault force requests immediate air support, just as a report of an imminent bomber launch from one of the enemy airbases comes across chat. The software service should consider what actions should be taken with respect to each of these new situations (EntitiesOfInterest), understand the states of all usable resources, determine which, if any, of those resources could be tasked against those situations, and build force packages and gameplans around those taskable assets, providing as much optionality as possible.

3.0 TECHNICAL REQUIREMENTS

Current C2 solutions focus on decision support (i.e., system interoperability, information exchange, and information presentations, i.e., battlespace awareness/display) and do not directly address decision advantage (i.e., software that machine-assists/automates battle management decision-making). To win against a peer adversary, the joint force must achieve decision advantage by equipping C2 HMTs with automation to sort through complex and high-volume battle management decisions with faster tempo and improved decision quality.

3.1 Multi-Decision Advantage Sprint for Human-Machine Teaming (Multi –DASH) for Battle COA Production The ABMS CFT (AF/A57RB) and Air Force Research Laboratory, 711 Human Performance Wing (711 HPW) will host a series of events. These events will conduct Research and Development surrounding the Transformational Model – Battle Management (Figure 1), with the function(s) varying for each event. The event is seeking the following: 1) understanding of the Transformational Model 2) alignment with the Transformational Model 3) new and novel approaches for software services that completes all three decision functions (PAE, MEF, GBC)

During these events the contractor shall accomplish the following: Participating software development teams will travel to attend the event 25 Jan-4 Feb 2027 in Las Vegas, NV. The teams will witness a battle management crew making battle management decisions in a simulated combat environment for the specified decision function. The participating software developers will then apply the Transformational Model (the functional description of the decision function) and their creativity in applying a software service that helps the humans make faster and higher quality battle management decisions. Battle management warfighters will be teamed with coders to provide operational perspective and feedback. As part of the event, each team will have the opportunity to demonstrate how their software affects overall human-machine team decision making during culminating battle management scenarios. During these scenarios, each team will have opportunities to run their software addressing the specified decision functions. Software solutions will be measured based on the number, speed and quality of decisions made by the Human Machine Team (HMT), alignment to transformational model, and depth/completeness. A government owned User Interface and API will be provided at the event. The contractor will be required to provide their own hardware as well as connect their hardware/software to the event’s local area network (which has commercial internet connection) to consume and produce data. The software solutions shall utilize varied, structured and unstructured data streams, including but not limited to text chat, voice communications converted to text, entity state streams and scenario data to inform their software solution. The contractor will be required to provide outputs specific to the decision functions to the AFRL Digital Orchestrator via a government defined output schema. The AFRL Digital Orchestrator output schema will be provided to notified selected contractors prior to the event. The contractor shall be required to connect to the AFRL service providing digitized inputs for the specific decision function. Evaluation results and the list of participants will be shared with government stakeholders. Invited participants will retain their intellectual property (IP), including any changes made over the course of the week. Government stakeholders reserve the right to analyze all collected sprint data (including software performance and technical integration insights) to derive, refine and mature functional and technical C2 software requirements.

Offerors must describe the current maturity level of their proposed tool. Is it a conceptual model, a lab prototype, or a market-ready product? Evidence of new applications is highly encouraged. This event is looking to focus on establishing new relationships and expanding the industrial base.

Crucially, offerors must describe in the proposal their plan and technical approach for achieving a live, functional demonstration of their PAE, MEF, and GBC software services during the Multi-DASH event. Proposals must explicitly detail how their solution is designed to:

1. Fit the requirements of the 3 decision function (as defined in section 2.2).

2. Process dynamic inputs: Ingest real-time, streaming structured and unstructured data from the government's simulation environment.

The primary goal is to demonstrate the offeror's completion of the 3 decision functions in a live, government-hosted ecosystem, not to deliver a final, static codebase for government acceptance at the conclusion of the event.

Prior to the event, the Government may Host an “Ask Me Anything” and subsequent on-line academic “office hours” for the selected notified contractors to attend at their discretion. Pre-event meetings will be held virtually and will provide additional details on event logistics, AFRL UI, and Digital Orchestrator output schema. During the Multi-DASH event additional contractor software development support may be provided virtually from remote locations, however access to live data from the event will not be available for remote support. In-person participation is encouraged. Contractors can rotate or substitute on-site staff during the event if needed, however, be aware that individuals arriving later in the event will not have the full benefit of the technical and operational academics and experiences that will occur throughout the two weeks.

3.1.1 EXPECTED OUTCOMES

The government is not procuring a final software deliverable through this M-DASH event. Instead, participation will be evaluated based on the offeror's ability to successfully demonstrate the following key outcomes within the two-week event window:

1. Demonstrated Functional Relevance: The tool demonstrably processes dynamic scenario data and provides outputs that are relevant to the targeted Decision Functions (integrated modular PAE, MEF, GBC).

2. Contribution to Human-Machine Team Performance: The demonstrated outputs of the tool contribute to the overarching goal of enabling the human operator to make better, faster decisions. The tool should help the user process and make sense of a complex environment rather than simply presenting more raw data.

During the event the contractor will be required to adhere to the government owned messaging standard and provide outputs to the Government Software System API. All messaging outputs will be recorded and available for future Government use.

At the conclusion of the M-DASH, government assessors will record the outputs of each contractor’s solution and measure performance during a simulated run in which warfighters will complete a complex battle management scenario while using the solution. As part of that evaluation, each contractor will provide a record (log) of their intermediate (PAE, MEF, and GBC calls to PAE) outputs as well as their final outputs (BattleCOAs from GBC) (Reported in CDRL A001). This record of demonstrated capability and a final out briefing provided by the contractor will serve as the primary output of the event. No transfer of intellectual property or final code delivery is required under this agreement.

3.2 REPORTING

During simulation runs at the event, the Contractor shall provide outputs for each Decision Function, and the outputs shall be in the Government provided data schema.

At the conclusion of each event, the Contractor shall compile findings within and deliver a presentation that includes a summary of the work that was conducted, any relevant metrics, and lessons learned, via a Technical Review Presentation Package (CDRL A001)

3.2.1 DELIVERABLES

3.2.2 Within the Technical Review Presentation Package (CDRL A001) the Contractor shall deliver the following:

· End-of-Event Accomplishment Presentation (PowerPoint format)

· End-of-Event Technology Survey

· Simulated Run Digital Audit Logs Detailed description for each of these sections can be found in the Technical Review Presentation Package (CDRL A001)

4.0 OTHER REQUIREMENTS

4.1 SECURITY

4.1.1 OPSEC

General Operations Security (OPSEC) procedures, policies and awareness are required in an effort to reduce program vulnerability from successful adversary collection and exploitation of critical information. OPSEC will be applied throughout the life cycle of the contract. The Critical Information and Indicator List (CIIL) and the 711th HPW OPSEC Plan will be provided upon request by AFRL/711HPW Information Protection Office. While working on the government installation, OPSEC guidance and OPSEC training will be provided by AFRL/711HPW Information Protection Office. This training will ensure contractors are familiar with 711th HPW’s CIIL and OPSEC Plan as it pertains to their contract. The contractor shall apply OPSEC in their management of their current program IAW AFI 10-701 Operations Security. All contractor personnel require a minimum of a Tier 1 background check (T1)/SF85 for any position that requires access to the internet, use of automated information systems to cover standalone computers or unescorted entry into restricted or controlled areas prior to reporting for duty in support of any requirement. The investigation is not for a security clearance; it is for a position of trust. This is a mandatory requirement set forth in DoDM 5200.02_AFMAN 16-1405, Air Force Personnel Security Program. All documentation required for security certification shall be the responsibility of the contractor. (T1 required for CUI access, not for Public Releasable information).

4.1.2 Highest Security Classification [Unclassified]

4.1.3 SECURITY RISK REVIEW

Initial and Development (R&D) Senior/Key Person Profile: In accordance with required proposal submission documents the Contractor shall provide R&R Senior/Key Person Profile Worksheet(s). Contractor shall obtain coordination from the Government on all ad hoc R&D Senior/Key Person Profile Worksheet(s) prior to the covered employee(s) receiving access to S&T information. If, at any time, during performance of this award, the contractor/subcontractor learns that its Senior/Key Research Personnel are or are believed to be participants in a Foreign Government Talent Program or have Foreign Components with a strategic competitor or country with a history of targeting U.S. technology for unauthorized transfer, the contractor shall notify the Contracting Officer no later than 5 business days from the date at this information became known. In the event a security risk is identified, and the Government determines the security risk exceeds the acceptable threshold, the Contracting Officer will promptly notify the Contractor of the Government’s recommended course of action, which may include full or partial termination of award. The Government will provide as much information/rationale as OPSEC measures allow for. In the event the Contractor wishes to challenge the Government’s decision, fundamental research awards will follow the OSD R&E Memorandum dated 6 Jun 2023. All other awards follow the Ombudsman procedures in DAFFARS 5352.201-9101.

Contractor shall flow down this requirement to all subcontractors involved in the performance of research under this effort.

4.1.4 All documents, including papers, abstracts and posters shall be cleared by AF prior to public release.

4.2 SAFETY REQUIREMENTS

4.2.1 The Contractor shall comply with all applicable federal, state, and local safety, occupational health and environmental regulations.

5.0 AFRL POLICY ON EMPLOYMENT OF NON-US CITIZEN CONTRACTORS

5.1 Contractor employees requiring access to USAF bases, AFRL facilities, and/or access to U.S. Government Information Technology networks in connection with the work on this contract must be U.S. citizens. 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. Any waivers to this requirement must be granted in writing by the Contracting Officer prior to providing access. The above requirements are in addition to any other contract requirements related to obtaining a Common Access Card (CAC).

6.0 FEDERAL HOLIDAYS

6.1 The prices / costs in Section B of the contract include holiday observance; accordingly, the Government shall not be billed for such holidays, except when services are required by the Government and are actually performed on a holiday. The following days are contract holidays: New Year’s Day, Birthday of Martin Luther King, Jr., Washington’s Birthday, Memorial Day, Juneteenth, Independence Day, Labor Day, Columbus Day, Veterans Day, Thanksgiving Day, and Christmas Day.

image1.png