21-03 Amend 1 first repub.docx

AMENDMENT 1 to BAA FA8750-21-S-7003

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:

0. Updated references of Beta SAM to SAM throughout;

0. Updates the guidance regarding future white paper date from FY22-25 to FY23-25;

1. Part II, Full Text Announcement:

1. Section III, adds paragraph 4;

1. Section IV.1, Updates the guidance regarding future white paper date from FY22-25 to FY23-25;

1. Section IV.3.a, updates the classification guidance;

1. Section V.2.a, updates Review and Selection Process language;

1. Section VI.1, updates the Proposal Formatting language;

1. Section VI.4.d, adds new language;

1. Section VI.7, updates the applicable provisions;

1. Section VII, updates the OMBUDSMAN No other changes are 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: Composable Collaborative Planning

BAA NUMBER: FA8750-21-S-7003

PART I – OVERVIEW INFORMATION

This announcement is for an Open, 2 Step BAA which is open and effective until 28 Feb 2026. 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 28 Feb 2026, the following submission dates are suggested to best align with projected funding:

FY21 by 22 MAR 2021 (8 AM EST)

All potential Offerors are requested to wait to submit white papers for future fiscal years (FYs) until the BAA announcement is updated with specific dates. The BAA will be amended to include new and updated in-scope technology requirements in FYs 23-25.

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

A virtual Industry Day on this topic was held on 18 Feb 2021. Details regarding format and attendee access can be found in Beta SAM under a special announcement with the same BAA title.

CONCISE SUMMARY OF TECHNOLOGY REQUIREMENT: Seeking innovative research to develop a Composable Collaborative Planning to overcome the serial and time-intensive nature of existing planning techniques and to enable parallel planning to be performed at the operational level. This research will focus on addressing the Force Flow planning problem for Operation Plan (OPLAN) development to address critical planning needs. This research will rethink how dependencies and conflicts are discovered, tracked, and managed in order to reduce the overall planning time.. Specifically, this research seeks to: 1) Overcome global complexity problem through the investigation of dependency & assumption tracking techniques and 2) Develop a composable and collaborative planning framework to enable parallel planning across the diverse set of highly specialized teams. A key idea is to share the resources and context of the other planning stages to all other stages to allow the respective planning teams to have context of the dependencies and plan requirements both upstream and downstream.

BAA ESTIMATED FUNDING: Total funding for this BAA is approximately $24.5M. Individual awards will not normally exceed 24 months with dollar amounts normally ranging from $500,000 to $2,000,000 per Technical Area. 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. While the initial funding for this BAA will come from the Shared Context Planning (SCP) program, it is anticipated that there will be follow on programs that will complement the work started by SCP that align with the original scope of this BAA.

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):

BAA MANAGER:

Aaron McVay

AFRL/RISB

525 Brook Rd Rome, NY 13441-4505 Telephone: (315) 330-4780 Email: aaron.mcvay.3@us.af.mil

Questions of a contractual/business nature shall be directed to the cognizant Contracting Officer, as specified below (email requests are preferred):

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: Composable Collaborative Planning

BAA NUMBER: BAA FA8750-21-S-7003

CATALOG OF FEDERAL DOMESTIC ASSISTANCE (CFDA) Number: 12.800

I. TECHNOLOGY REQUIREMENTS:

Planning is an integral part of military operations. It is an involved process that requires hundreds of experts working in concert to develop the plan needed to conduct military operations and fulfill Commander’s Intent. The Operations Plan (OPLAN) is the ultimate in military planning endeavors, capturing the first 30 days of an engagement with an entire country or theater for the joint force. Due to this joint nature, the components’ planning experts are often geographically dispersed and only capable of large-scale collaboration planning during prescheduled planning conferences. These conferences are where operational planners and logistics planners come together to match the means (the military capabilities and resources) with the ways (the deliberate process of determining the how) to achieve the ends (Commander’s Intent).

The Air Force Research Laboratory is soliciting white papers under this Broad Agency Announcement (BAA) for research, development, integration, test and evaluation of remote, collaborative approaches in order to facilitate the coordination of operational and logistics planning prior to the planning conferences in order to reduce the time it takes to map means to ways by making logistical considerations an integral part of early operational planning as opposed to a task performed after a large portion of the plan is already complete.

The past fifteen years have seen significant growth in web-based collaborative, interactive, and knowledge graph [1] [2] technologies, as well as massive improvements in compute and network performance. This BAA seeks to couple this technological ecosystem with a holistic approach to planning that goes beyond focusing on plan data, by also incorporating planner roles as descriptive input/output (I/O) descriptions to represent planners as computational units within the system. It is also composable, allowing organizations to capture their own planning process, so that the framework fits their existing workflow. Rather than forcing it into the “once-size-fits-all” paradigm, often seen in typical software systems with support for tailored interaction and visualization paradigms to facilitate the remote and collaborative planning process. Through the development of knowledge graphs and model combined with tailorable collaboration & interactive paradigms, it will be possible to net a 10x increase in planning efficiency.

Background

This work proposes to rethink how dependencies and conflicts are discovered, tracked, and managed in order to reduce the overall planning time by enabling a more parallel and collaborative approach to Force Flow Planning (FFP). FFP is the area of OPLAN development that identifies the military assets and their dependencies that will be needed to execute the various aspects of the plan, as well as asset location, time to deliver, and means of transport. This type of planning is conducted between logistics and operational planners together at the aforementioned planning conferences. Because this form of planning occurs only after a large portion of the operation planning has been completed, it is often found that the resources that were anticipated are not available or cannot be provided per the required operational timeline. The former requires potentially extensive re-writes that consume valuable planner time, the latter introduces schedule slips in plan execution. It should be noted that, currently, planners lack any means for assessing the time delay impacts to the effectiveness of the OPLAN.

Force Flow Planning needs to be integrated into the earlier stages of OPLAN development, as opposed to being an activity that it performed after a significant portion of the OPLAN has been defined. This will reduce those time intensive re-writes and scheduling delays because the ways and means of the OPLAN will be determined simultaneously. This avoids the build-and-fix approach (also recognized as an inefficient approach in the software development industry) that is used to conduct planning today.

Figure 1 illustrates the differences between the serial planning process of today and proposed collaborative, parallel planning approach to be explored with this work. The key idea is to share the resources and context of the other planning stages to all other stages in order to allow the multiple, large member planning teams from the various services and combatant commands (COCOMs) to have context of the dependencies and plan requirements both upstream and downstream. This is driven by several deficiencies identified in the 2005 Adaptive Planning roadmap: 1) Stovepiped data not accessible for planning, 2) No mechanisms exist for early and frequent consultation between civilian and military leaders during plan development, and 3) Limited periodic collaboration in the physical space [3]. Making the plan data universally accessible to all those involved in the planning process as well as giving accessibility to each other will address those deficiencies.

Figure 1 - Serial versus Parallel Planning

Today, there exists an abundance of unprecedented, remote, collaborative capabilities, such as Microsoft Teams, Skype for Business, and Zoom. These tools, in conjunction with nearly ubiquitous high-speed internet, have allowed many to continue to work despite the challenges presented by the COVID-19 pandemic. Their barrier of entry is fairly low and they all offer basic collaborative capabilities such as messaging, file sharing, meetings, and some even have the ability to collaborate on the simultaneous modification of information products, though those are typically limited to the parent company’s other software offerings. This leads to an application-centric means of collaboration as opposed to a data-centric one, resulting in the same issues associated with a stand-alone application-based approach: information is caged within a given application, encoded in forms that do not lend themselves to interoperability such as a bitmap image of an Area of Regard (AoR), and lacking details of the pedigree of that information. Later in this BAA, these issues will be addressed through the concept of a unified planning model as part of SCMA.

There are other tools from the software development community such as the Atlassian tool chain and team management solutions like Monday.com even allow users to informally capture their business workflow via user input and interaction with the system. This is however, based on the awareness of the user base and is not captured to ensure continuity of operations with respect to time and employee turn-over. TPP’s ability to allow the user to define the workflows of an organization and SCMA’s ability to capture them will provide a more formalized and rigorous approach to human collaboration, alleviating much of the collaborative friction experienced today when the onus is on the individual to track those processes and allowing its users to concentrate on the work at hand.

Additionally, none of the technical offerings of today have the ability to support interfacing with existing planning tools and Systems of Record (SoR) and would instead require additional human effort to move into and out of these systems. Even if middleware was developed to perform this kind of data migration, it still usually places a burden on human operators to use these tools correctly and to track consistency of the data on both sides of the transaction. This is avoided with SCMA, as it will be designed to be flexible and extensible to work alongside these legacy systems, brokering the data from them to the user smartly, making queries of these systems to get the user the data the need and no more. When data exists elsewhere, SMCA must not try to subsume it, but rather persist knowledge on how to access it and perform that access per user-driven demands.

Beyond the ability to collaborate in general, there is the potential for the development of new techniques to support planning specific to military planning in a collaborative and interactive fashion. The exploration of new techniques addressing the specific challenges of military planning are of interest.

Finally, there are also security considerations as none of the current collaborative offerings are certified to process and store data at the levels required for planning at this level. With most commercial solutions moving to a software as a service (SaaS) business model, it’s becoming increasingly difficult and/or cost prohibitive to establish a stand-alone infrastructure with commercial-off-the-shelf (COTS) to address those security concerns.

This BAA seeks to develop a novel composable planning paradigm to overcome the serial and time-intensive nature of existing planning techniques in order to reduce plan development time by a factor of ten without degrading plan quality. The program will be broken down into two technical areas: Shared-Context Management & Analysis and Tailored Plan Presentation.

Program Challenges & Technical Areas

This program targets one of the most time and resource intensive phase of the plan development – the resourcing and flow of materiel against strategic objectives, commonly referred to as Force Flow Planning. This planning stage takes as input the strategic plan (how we will win the war) and identifies, schedules, and places materiel against the strategy to make it executable. Accelerating this process is non-trivial. The breadth and depth of the problem suggests a more functionally independent approach, which lends itself to parallelization; yet the planning stages are inherently dependent across resources and time. This complicates parallelization while also introducing inconsistencies and conflicts resulting in plans that are neither optimal as compared with the strategic objectives nor timely to match the changing world-state.

This work will reconcile the seemingly opposing demands for a force flow planning solution to reduce the planning time by an order of magnitude compared to the status quo. The globally dependent nature suggests a global approach to the solution, yet the complexity means a solution will far exceed any human planner capacity. The breadth and depth indicates a functional decomposition, bottoms up approach, however this introduces significant conflicts that must be reconciled through costly iterations. Specifically, this work seeks to: 1) Overcome global complexity problem through the investigation of dependency & assumption tracking techniques and 2) Develop a composable and collaborative planning framework to enable parallel planning across the diverse set of highly specialized teams. With both of these components, and an operational-focused evaluation, a significant reduction in planning time can be achieved.

It is envisioned that remote, collaborative planning will consist of two distinct, yet intertwined, technical areas:

1) Shared Context Management & Analysis (SCMA): What would it take to achieve a shared context – how to disseminate and provide awareness of planning attributes and make the information available to all teams engaged in the planning process in a parallel and collaborative nature?

2) Tailored Plan Presentation (TPP): How can planners be allowed to maintain their individual planning context with support for their distinct specialization(s) - how to provide tailored planning tools and information to support specialized planning teams’ requirements?

Program Structure

The Shared Context Planning program will be organized into two high-level technical areas that will persist throughout the life of the program (all phases). An overview of the technical areas is provided below.

Technical Area 1: Shared Context Management and Analysis (SCMA): This is the heart of the system and provides the underlying framework required to identify, track, and manage resources, timing dependencies, and constraints. It goes further than other planning support systems which only persist and perhaps share plan artifacts. SCMA involves concepts needed to define the distinct roles of planners as well as allowing for the capturing and execution of an organization’s planning process. This unified model of planning that consolidates plan data, the planning process, and planner roles will provide the required flexibility and reconfigurability to meet the needs of the various planning institutions and support them as those needs change over time. It will provide the mechanisms to define the methods for identifying, tracking, and managing resource and scheduling changes and dependencies across all planning phases. This unified planning model will be the foundation for several capabilities Shared Context Planning will need to provide:

· Planning collaboratively and in parallel. The serial nature of planning is the reason that it has become “insufficiently responsive to the demands of today’s security environment” [4]. Therefore, the system must allow for potentially hundreds of planners to add/modify/delete their portions of the plan at the same time. Many planning tasks also require some form of coordination between planners so the system must provide mechanisms by which collaboration can occur. Any of the collaborative techniques should have various criticality states, definable by the organization, with criticality concepts running from ‘informational and dismissible’ to ‘mission essential and immediately priority’. What is not sought in this area is the automatic generation of plan Courses of Action (CoA) or the development of Artificial Intelligence (AI) or Machine Learning (ML) algorithms capable of “learning” how to collaborate.

· Planning organizations need to define and codify their planning process in the system so the system integrates seamlessly with their workflow. Every planning organization has their own way of performing planning; the system needs to allow for the capturing of that process so that the system mirrors how they already perform their duties. This will require a user-friendly means for defining this process which is usable by those in the operational community, likely a graphical user interface that allows for a visual compositing of the process that is easy to understand. This will be backed by a vocabulary that will drive the system according to the captured process. This vocabulary must be open-world so that future additions can be made to it without hampering existing functionality but also supporting new requirements. What is not sought in this area is the development of Artificial Intelligence (AI) or Machine Learning (ML) for natural language processing.

· Adaptive Planning Process. Every institution changes their doctrine and policies over time. This the why they need the ability to change their planning process definition as their processes change and evolve over time. A system that is reconfigurable by the user-base will remain consistent with policy, do so on a much shorter timeframe, and will stay operationally relevant for longer.

· Planner Modeling. SCMA has to provide a mechanism for the planning organization to model planners as computational units with a rich Input/Output (I/O) description, allowing plan data, planning process, and planner roles to be part of a single, cohesive model for planning. By modeling each planner role as a set of inputs and outputs, it allows for the seamless insertion of the planner as part of the planning process. It will also identify what plan data each role requires, so that the data is directed to where it is needed when it is needed. Having a formal description of planner roles will also support integration of AI/ML technologies in the future, since it will be as simple to define the required inputs and outputs of the autonomous system as it is for a human planner.

· Asynchronous & Parallel Plan Updates. Integral to a networked, multi-user system, SCMA will need to appropriately decompose plan artifacts so that portions of the plan can by updated simultaneously. It will also have to guarantee transactions to maintain data consistency when more than one planner is working on the same portion of the plan.

· Collaboration Focused. SCMA must take every opportunity to reduce collaboration “friction” and allow planners to concentrate on planning. Some options for this are effortless communication between planners, including the ability to identify all other planners in a given planner’s data pipeline, a customizable dashboard that tracks all of a planner’s tasking, their priorities, and other pertinent information to improve planner efficiency, and an automated system that can remind planners when items are coming due. It must also be easy for planners to get information into and out of the system and work on approved DoD networks and with hardware seen in typical DoD environments.

· Planning Interoperability. To the maximum extent possible, SCMA will support interoperability with existing planning tools and Systems of Record (SoRs). SCP will sit alongside of existing SoRs as opposed to attempting to replace them, which would be a herculean endeavor. By working with the existing planning ecosystem, it will be possible to leverage and augment current planning capabilities and will also encourage adoption by the user community. This will require an examination of the systems in place today so that system interoperability, within legacy system limitations, will be possible in both directions. Through AFRL’s relationships with both the Joint and AF Component planners, it will be possible to obtain representative dataset samples as well as pertinent information about the interfacing capability of current planning SoRs such as the Joint Operation Planning and Execution System (JOPES), the Deliberate and Crisis Action Planning and Execution System (DCAPES), and the Joint Flow and Analysis System for Transportation (JFAST). What is not sought in this area are any systems that would be a complete or partial replacement for existing SoRs.

· Planning Instrumentation. SCMA should allow monitoring of overall plan progression. Through the knowledge graph such instrumentation and tracking can be made possible. Full instrumentation will enable tracking of progress, issues, and coordination bottlenecks to drive further refinement and customization of the planner workflows.

Technical Area 2: Tailored Plan Presentation (TPP): TTP is the means for presenting role-specific plan information to the planner and the creation of human-machine interfaces for interacting with local and linked plans. It will enable a personalized plan representation that will provide each member of the planning team, and the roles they fulfill, with views into pertinent aspects of the plan that are rich, meaningful, yet easily understood.

A key focus is on technologies capable of developing a framework that does not require a software engineer to modify, to support local planning teams while being globally connected by the sharing of context. Approaches will be supported by industry best practices when it is warranted and new planning interaction paradigms explored to address existing gaps. What is not sought in this area is the use of Virtual Reality/Augmented Reality (VR/AR) technologies to aid in the planning process. Some considerations of this task should be:

· Planner Role Aware. The solution should leverage the planner role Input/Output (I/O) definitions to provide access to the appropriate plan data to the planner based on their role and the tasks they are completing. While planner I/O will be defined within SCMA, it will be the responsibility of TPP to present that data to the planner. As such, TPP needs to understand the directives an organization has encoded in SCMA so that it may composite the desired default views needed based on planner role, the planning task being executed, and the recommendations for the default ways to represent the appropriate data of that task and role. It must also be able to store back into SCMA any user preference overrides implemented by the planner so that it is accessible to the planner on subsequent work sessions. Finally, TPP must be able to capture the outputs “O” of the planner’s labors and publish them back into SCMA for persistence and to propagate them further down the planning process pipeline.

· Plan Visualization, Creation, & Introspection Tools. TTP is the mechanism that provides data in visual representations based on information visualization principles and practices, organizational requirements, and individual user preferences. There has been considerable work done in the domain of information visualization to define a more rigorous science for mapping data to appropriate visual representations. A good compendium of this can be seen in Munzner’s ‘Visual Analysis and Design’ [5]. This BAA seeks solutions that take advantage of best practices and existing solutions, while also addressing the specific challenges and collaborative planning outlined in this solicitation.

· Plan Progression. Overall plan progress is another depiction that can be provided by TPP. This would involve aggregate representations of the plan data that convey summary information about the plan, such as overall progression, bottlenecks and estimated time to completion. These types of views will be driven be the needs of the planning community to the greatest extent possible. It should also be noted that this capability should support extensibility like the rest of the system, with the end user being given the means for compositing new summary views as required, as well as overall views and status.

· Self-Optimizing. A central goal will be to identify visual representations that are most effective. By monitoring, over time, the preferred visual metaphors planners utilize of any given planning dataset, a catalog of best practices can be created. This necessitates that the user preference (mentioned above) be collected over time to allow for trending analysis to be performed and stored within SCMA. This results in an automatic capture of the organization’s cultural best practices with respect to plan data representation with zero impact on planner productivity.

· User-Interface. A user-interface will be provided to allow the organization to define the planning process and planner roles. The need for this was touched on in the section of SCMA that discussed the ability to define and codify their planning process. This interface will be graphical in nature and allow users to composite the process without requiring any level of software development skills. It may be found that multiple visual representations of the process are required to address a particular aspect of capturing that process. It also needs to be inspectable, so that a planning organization can determine whether or not the system is performing correctly. A web-based approach using best practices is encouraged.

· Logistics Data “Elevation”. Logistics data needs to be made available to operational planners in forms that are easily understandable, so that logistical considerations are incorporated in the initial plan iterations, and not deferred until the first planning conference. Currently, this “elevation” of data occurs manually by the logistics planners and is a labor-intensive process. Allowing logistics planners to capture these rules to incorporate them into SCMA will be required of TPP. Once these rules are in place, TPP will use these to allow operational planners direct access to logistics data without the repeated need to solicit logistics planners’ assistance to accomplish this, reducing the time required to make such inquiries.

The figure below outlines how the two technical areas contribute to the overall vision of the shared context planning vision. This depiction is meant to illustrate the key planning concepts identified in this BAA and how they may come together to achieve the overall vision. It is only for illustrative purposes and does not limit any type of solution.

Figure 2 – SCMA & TPP Conceptual Overview

Shared Context Management. The left of Figure 2 represents Shared Context Management components that will identify, track, and manage resources, timing dependencies, and constraints across planning artifacts, users, and user roles. This will also include the ability to interface with legacy systems and data. These components are responsible for managing data requirements, planning tasks across different planners and roles.

Tailored Plan Representation. The right of Figure 2, a series of user presentations spanning different planning and user groups. These tailored plan representation and interaction tools will enable specific planner roles to tailor their views based on their primary task while also accessing and displaying required information about the larger plan to include dependencies and information at the appropriate level of fidelity. All changes, interactions, and assumptions will be tracked through the Shared Context Bus to update and interact with the Shared Context Management components. The Shared Context Bus will also be responsible for instrumentation and tracking of operations to facilitate status modeling and instrumentation of the process.

The system should be composable allowing new groups and planning functions to be added/remove and refined. It should also support full remote collaboration using best practices while also being tailored to operate on military network and systems. This also includes the potential to operate across security boundaries as needed to support remote military collaboration and planning.

Schedule

This program will consist of a 24-month period of performance. It will initiate with a kickoff meeting where participants will provide a detailed outline of their technical approach. This 24-month effort will concentrate on development of an initial capability. All invited participants to the follow-on will be required to present at a kickoff meeting to provide a detailed outline of their technical approach.

For the 24-month effort, Quarterly Program Reviews (QPRs) will be held every three months. QPRs will be held individually between the Government and the performer. SCP program Principal Investigator (PI) meetings will be held every six months in the place of a QPR either remotely or in an agreed upon location. All SCP performers will be present during the PI meetings along with other Government/Military guests invited by the SCP program. SCP performers will also be attending the annual AC2 CTC PI meeting, normally held in the Washington DC area. This AC2 CTC PI meeting will take the place of a scheduled SCP PI meeting. It is anticipated that all performers will individually participate in short biweekly updates on progress, issues, etc. via remote means.

Evaluation

For the Shared Context Planning (SCP) program, the Government will lead the evaluation of SCP artifacts. The Government will conduct independent evaluations that will be defined and conducted by Government led team. The Government team will include AFRL researchers as well as Joint and MAJCOM planner SMEs. The Government evaluation team will be responsible for providing input data such as the TPFDD (or acceptable surrogate) and example OPLANs. The Government evaluation team will work with its operational partners to develop a baseline scenario and appropriate data to be used for artifact evaluation. To the maximum extent possible, the evaluation team will also be responsible for providing representative users in the form of operational and logistics planners through existing and emerging relationships with the planning community. Finally, the evaluation will be responsible for collecting and analyzing results.

The offerors will be required to provide periodic (see Schedule) software deliverables in source form with all the required installation tools and documentation for the evaluation team to perform the installation. The source version will be evaluated as to whether or not it compiles and executes. It will also be tested to determine if it is moving towards meeting the capabilities herein. The installation will be on a standalone Air Force network with no ability to depend on external services or resources. Delivery of the software will be every six months starting at six months from contract award.

The software artifacts described above will be the performers’ inputs to a series of evaluation events throughout the program. These evaluation events will serve to assess progress of the technical and operational capability within the artifacts. These evaluation events will increase in complexity and relevance as the program executes culminating in a program capstone event at the end of phase 2. The evaluation events will assess the potential planning time decreases, gained efficiencies and the resulting plan quality consistent with SCP program goals. The plan quality will be assessed in a static evaluation fashion by SME members of the Governments evaluation team.

The Government is interested in integration of Technical Area 1 and Technical Area 2 components and proposals need to provide evaluators with the information required to assess the extent to which the developed interfaces will be open and accessible. Understanding that it is not always possible for collaboration between performers to occur under a program, at a minimum, open interface standards will be used so that integration is achievable in the future. If a performer will only be proposing against one of the two technical areas, theywill be required to provide open interfaces based on GraphQL so that it will eventually be possible to couple to the other technical area. Proposals offering to address multiple technical areas are still required to develop open interfaces based on GraphQL [6] that enable software components to be decoupled and, potentially, integrated with other technical solutions delivering similar functionality.

Metrics

Offerors are expected to provide a baseline for the technical area(s) pursued, and justify how they will determine that baseline. Then, they must show how their approach will improve on that baseline. Progress towards achieving the stated improvement will be evaluated as part of the QPRs. As the program matures metrics may be re-evaluated for appropriateness and augmented when needed based on user feedback.

The following are the areas that will be evaluated to measure performer success. Each area has its sub-components listed under it; each sub-component was described earlier in this BAA. The metrics for that sub-component are then listed with specific questions that will be asked in order to evaluate performer progression. Performers only have to address the metrics appropriate for the area(s) of the program for which they are developing.

Shared Context Management & Analysis

· Collaboration and Parallelism – The level by which multiple users are able to work on the development of aspects of the plan simultaneously and together. The ability for the system to inform the user that others are working on the same or dependent parts of the plan.

· What mechanisms are provided a user to allow for communication with others performing updates?

· How well does the approach handle cases where more than one user is working on the same plan?

· How well does it handle consistency of data between itself and any SoRs it is required to interact with?

· What level does the approach lock plan data to strike a balance between concurrent write access to any plan artifact and exclusive access to the entire plan?

· Will inconsistencies in the data be possible with this approach?

· How are these inconsistencies resolved under these conditions?

· Expressiveness – The ability to capture planning process workflow. The need to see the plan under various lenses. The ability to capture all aspects of planner roles.

· Does the language for the planning process adequately define key planning concepts?

· Is it capable of defining a variety of workflows of a complex nature?

· How easy is it to interrogate to determine aspects of overall plan progression?

· How does the approach associate the data needs of a planner role to that role?

· How does the approach define the output product(s) of the planner role?

· How to planning tasks fit into the model for a planner role?

· Extensibility – The dynamic nature of the approach. Ability to enrichen planner role definition.

· Does it take an open world approach and allow for additional planning workflow concepts to be defined?

· Does the approach make it easy to capture the input/output aspects of a planner role?

· How difficult is it for an end user to define these new concepts?

· Completeness – The level that the approach interoperates with SoRs. Coverage of plan details.

· How much of the TPFDD and OPLAN data can the approach address?

· How much of the overall plan is visible to provide this capability?

· Will it be necessary to coordinate with SoRs to provide this overvlew or will all the necessary data be self-contained?

· How will it handle updates that have occurred within the SoRs?

Tailored Plan Presentation

· Timeliness – Reducing time via reduced barrier of entry.

· What are the time reductions for both the operational and logistics planners by providing a means of automatically accessing logistics data for the operational planner in pre-defined ways (established by the logistics planner)?

· How often does an operational planner make use of this capability over time and what is the overall reduction in time compared to how this is achieved today?

· Usability – The human-machine interface caters to the user with ease of use and ease of customization.

· How well does the approach capture the results of the planner’s outputs so that they may be published back into the planning workflow?

· Is the interface easy to use within the context of planning?

· Does the verbiage match that of what is used within planning organization?

· Are functions and options easy to find?

· Does the approach allow the planner to complete tasks with a minimum of user interface interactions?

· How well are user preferences preserved and can those preferences be migrated to new planner roles that user may take on in the future?

· How well does the approach support the logistics planner with mechanisms for defining access to logistics SoRs so that “queries” can be formulated for operational planners to utilize independently?

· Completeness – Breath of visual capabilities to support all aspects of planning.

· Does the approach provide ample user interfaces that allow for the performance of planning tasks?

· How much of the plan data can be incorporated in order to generate plan overviews?

· To what extent is the approach capable of monitoring all aspects of the planning process as it is performed to capture usage and performance information?

· Does the approach provide all the required user interface elements to support all the planning concepts necessary to capture the planning process and planner roles?

· How well does the approach maintain consistency between itself and the SoRs where the logistics data is kept?

· Expressiveness – Extracting plan overview details. How to make use of planning awareness. Adaptable to the organization.

· Does the approach provide for repeatability of this access (such as a saved query or a template that can be re-applied)?

· How well does the approach allow the planning organization to identify and persist how data should be presented to a planner role by default?

· What user interface mechanisms are available to composite an organization’s overall planning process?

· To what extent can the approach provide unfettered definition of the data elements with SoRs so that only the required data is accessed in order to provide logistics views to the operational planners?

Technical Points of Contact (TPOCs) for the Aforementioned Technical Requirements:

In addition to the cognizant TPOC listed in section VII. AGENCY CONTACTS, all white paper and proposal submissions and any questions of a technical nature shall be directed to the following TPOCs (email requests are preferred):

Shared Context Planning (SCP), Shared Context Management & Analysis (SCMA), Tailored Plan Presentation (TPP) TPOC :

Chad Salisbury

AFRL/RISB

525 Brook Rd Rome, NY 13441-4505 Telephone: (315) 330-7804 Email: chad.salisbury@us.af.mil

Shared Context Planning (SCP), Shared Context Management & Analysis (SCMA), Tailored Plan Presentation (TPP) TPOC :

Aaron McVay

AFRL/RISB

525 Brook Rd Rome, NY 13441-4505 Telephone: (315) 330-4780 Email: aaron.mcvay.3@us.af.mil

Bibliography

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,500,000. The anticipated funding to be obligated under this BAA is broken out by fiscal year as follows:

FY21 - $1,300,000

FY22 - $3,600,000

FY23 - $3,900,000

FY24 - $9,200,000

FY25 - $6,500,000

a. Individual awards will not normally exceed 24 months with dollar values normally ranging from $500,000 to $2,000,000 for each of the two Technical Areas and a limit of $4,000,000 if proposing against both Technical Areas. 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,500,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 depending upon the nature of the work proposed.

3. BAA TYPE: This is a two-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.