AISAP_Draft_PWS_v1-0_ 20241127.pdf

PERFORMANCE WORK STATEMENT (PWS)

Artificial Intelligence and Software At Pace (AIS@P) Multiple Award Task Order Contract (MATOC) in support of Program Executive Office Intelligence, Electronic Warfare, &

Sensors (PEO IEW&S)

27 November 2024

Version 1.0

General Information

1.0 General: This is a non-personal service(s) contract under which the personnel rendering the service(s) are not subject, either by the contract’s terms or by the manner of its administration, to the supervision and control usually prevailing in relationships between the Government and its employees.

1.1 Description of Services/Introduction: This Multiple Award Task Order Contract

(MATOC) is to provide support for programs and requirements within PEO IEW&S, other US Army customers, as well as other Department of Defense (DoD) entities as required. This contract will support multiple lines of effort, with initial requirements being in the areas of Artificial Intelligence/Machine Learning (AI/ML) and Software (SW) Development. AIS@P will support Requirement Pools (RP) as defined within this document, with the initial RPs being in the areas of Artificial Intelligence/Machine Learning (AI/ML) and Software (SW) Development. A RP may be further broken down into sub-Requirement Pool (sRP) based on Government requirements. Additional RP/sRP may be established at any point during the base ordering period of this contract to support future missions or requirements. In the event of an additional RP/sRP being established, the Government will define the instructions, evaluation criteria, as well as solicit responses from industry.

1.2 Background: The primary mission of PEO IEW&S is to provide affordable, world class Intelligence, Sensor, and Electronic Warfare capabilities enabling rapid situational understanding and decisive action. PEO IEW&S has identified a definitive need for a contract vehicle that supports rapid awards to meet customer requirements in response to a constantly evolving threat environment, rapid on/off ramping of vendors, and the ability to quickly transition between vendors in the event of contractor performance concerns. This contract will provide the Warfighter the best capabilities at the best value – in the quickest and most efficient manner possible.

The primary mission of PEO IEW&S is to provide affordable, world class Intelligence, Sensor, and Electronic Warfare capabilities enabling rapid situational understanding and decisive action. PEO IEW&S is composed of nine (9) Project Director (PD)/Project Management (PM) Offices, to include:

• PM Aircraft Survivability Equipment (ASE)

• PM Cyber & Space (C&S)

• PM Defensive Cyber Operations (DCO)

• PM Electronic Warfare & Cyber (EW&C)

• PM Intelligence Systems & Analytics (IS&A)

• PM Positioning, Navigation & Timing (PNT)

• PD Sensors-Aerial Intelligence (SAI)

• PM Tactical Exploitation of National Capabilities (TENCAP)

• PM Terrestrial Sensors (TS)

1.3 Scope: The Contractor shall provide all personnel, equipment, supplies, facilities, transportation, tools, materials, supervision, and other items necessary to perform services as described in this PWS as well as associated Task Order/Delivery Order (TO/DO) PWSs and associated contract documents, except for those items specified herein. The Contractor shall perform to the standards and acceptable quality levels identified in both this PWS and the respective TO/DO PWS and associated contract documents. All TO/DOs shall be performed within the scope of the Requirement Pools (RPs) as defined in section 3 of this PWS.

Initial RPs being supported by this contract will be for Artificial Intelligence/Machine Learning (AI/ML) and Software (SW) Development. The Government shall add RPs to expand the future scope of work covered by this contract as needed based on future requirements as defined within section 3.0 of this PWS.

PEO IEW&S leads the charge for the Army’s AI/ML efforts, with Project Linchpin (LP) being the Army’s Program of Record (PoR) for Artificial Intelligence Operations and Services (AIOps+). AIOps+ includes the industry recognized practices of AI/Machine Learning Operations (AI/MLOPs) and PL AI ecosystem, PL standardized approaches (e.g. AI Risk Framework), PL design principles, and the secure trusted environments and services which enable the delivery of AI solutions to AI-enabled programs.

SW Development is the cornerstone of the programs that allow the Army to develop the capabilities which enable Spectrum and Cyberspace superiority. SW is key to each piece of the Army’s networked Intelligence, Electronic and Cyber Warfare capabilities.

PEO IEW&S leverages modern SW development practices as it supports future Army efforts such as Electronic Warfare (EW) re-programming as it paces the threat.

1.4 Objectives: The objective of the AIS@P MATOC contract is to provide PEO IEW&S, other Department of Defense (DoD) agencies/departments, and other federal agencies with access to large pools of contracts with skillsets specific to requirements outlined for each pool. This MATOC will support the acquisition of both services and supply for efforts defined within sect. 3 of this PWS. AIS@P shall support rapid TO awards in an effort to meet customer requirements in response to a constantly evolving threat environment. TOs shall be awarded for services and supplies at all stages of a programs lifecycle.

1.5 General Information:

1.5.1 Contract Type: This base contract is a multiple award Indefinite Delivery Indefinite Quantity (IDIQ) type contract. Individual TO/DOs can be awarded on a Firm Fixed Price (FFP), Fixed Price Incentive (FPI), Time and Material (T&M), Cost Plus Fixed Fee (CPFF), Cost Plus Award Fee (CPAF), and/or Cost-Plus Incentive Fee (CPIF) basis.

1.5.2 Ordering Period: The AIS@P ordering period is a five (5) year base period and one (1) five (5) year option period from the date of award. Individual

TO/DOs can be awarded at any time during this period. Performance of an individual TO/DO awarded during the IDIQ period will not extend more than one year beyond the ordering period. Options under the TO/DOs will not be exercised outside of the base IDIQ contract ordering period.

1.5.3 Place of Performance: The place of performance shall be identified in individual TO/DOs. Locations will be Government or Contractor sites within the Continental United States (CONUS) and/or Outside the Continental United States (OCONUS). OCONUS requirements regarding Theater Business Clearances (TBC), Status of Forces Agreements (SOFA) and or Technical Expert Statys Accreditation (TESA) will be included at the TO/DO level when applicable.

1.5.4 Recognized Holidays: The following provides information on recognized holidays for the purpose of the base MATOC PWS. If submittal of any documentation (e.g. deliverables, submittals, etc.) deadlines fall on a holiday, the closest workday prior to the holiday will apply as the deadline for submittal.

1.5.4.1 U.S. Holidays: Each respective TO/DO will establish whether work shall or shall not be permitted on a U.S. Holiday. When a U.S. holiday occurs on a Saturday or a Sunday, the holiday is observed on the preceding Friday or following Monday, respectively.

• New Year’s Day January 1st

• M. L. King Memorial Day 3rd Monday in Jan

• Presidents Day 3rd Monday in February

• Memorial Day last Monday in May

• Juneteenth June 19th

• Independence Day July 4th

• Labor Day 1st Monday in September

• Columbus Day 2nd Monday in October

• Veteran’s Day November 11th

• Thanksgiving Day 4th Thursday in November

• Christmas Day December 25th

1.5.4.2 Host Nation Holidays: Each respective TO/DO will establish whether work shall or shall not be permitted on Host Nation Holidays.

1.5.4.3 Operating Hours: Operating hours for individuals performing work either at Government or Contractor facilities, shall be specified at the TO/DO level.

1.5.5 Enterprise-wide Contractor Manpower Reporting Application (eCMRA):

The Contractor shall report all Contractor labor hours (including subcontractor labor hours) required for performance of services provided under this MATOC via the System for Award Management (SAM) secure data collection site. The Contractor is required to completely fill in all required data fields within SAM using the following web address: https://www.sam.gov.

Reporting inputs will be for the labor executed during the period of performance during each Government fiscal year (FY), which runs October 1 through September 30. While inputs may be reported any time during the FY, all data shall be reported no later than October 31 of each calendar year, beginning with 2024. Contractors may direct questions to the help desk at:

https://www.sam.gov. Should contractors have issues using SAM, they should contact the Federal Service Desk at https://www.fsd.gov. This web site may contain additional information on how to complete the required information.

1.6 Post Award Conference/Periodic Progress Meetings: Post award conferences and periodic meetings will be specified at the TO/DO level if required. The Contractor shall attend any post award conference convened by the contracting activity or contract administration office in accordance with FAR Subpart 42.5. The Contracting Officer, COR, and other Government personnel, as appropriate, may meet periodically with the Contractor to review the Contractor's performance. At these meetings the Contracting Officer will apprise the Contractor of how the Government views the Contractor's performance and the Contractor shall apprise the Government of problems, if any, being experienced. Appropriate action shall be taken to resolve outstanding issues. These meetings shall be at no additional cost to the Government.

1.6.1 The Contractor shall attend, participate in, and furnish input to scheduled and unscheduled meetings, conferences, and briefings that relate to the functions and services herein as required by the Government to provide effective communication and impart necessary information. The Contract Manager or designated representative shall attend meetings as requested by the Government. Meeting attendees shall at times include Contractor managerial, supervisory, and other personnel knowledgeable of the subject matter.

Meetings may start or end outside of regular duty hours.

1.7 Contracting Officer’s Representative (COR): As determined by the Contracting

Officer, a COR will be appointed and identified by letter of designation, a copy of which will be provided to the Contractor by the Contracting Officer. The designation letter states the responsibilities and limitations of the COR, especially with regard to changes in cost or price, estimates, or changes in delivery dates. The COR is not authorized to change any of the terms and conditions of the resulting order. The COR monitors all technical aspects of the contract and assists in contract administration. The COR is not authorized to obligate the Government. If the work is not written in the contract, the COR is not authorized to request new work. The COR is authorized to perform the following functions: assure that the Contractor performs the technical requirements of the contract, perform inspections necessary in connection with contract performance, maintain written and oral communications with the Contractor concerning technical aspects of the contract, issue written interpretations of technical requirements, https://www.sam.gov/ including Government drawings, designs, specifications, monitor Contractor's performance and notifies both the Contracting Officer and Contractor of any deficiencies, coordinate availability of Government property, and coordinate site entry of Contractor personnel.

1.8 Identification of Contractor Employees: All Contractor personnel attending meetings, answering Government telephones, and working in other situations where their Contractor status is not obvious to third parties must identify themselves, to include proper marking of signature blocks in correspondence, to avoid creating an impression in the minds of members of the public that they are Government officials. The Contractor shall ensure that all documents or reports, produced by Contractors are suitably marked as Contractor products or that Contractor participation is appropriately disclosed.

1.8.1 Contractor workspace (staging site, on-site office, desk or work area, etc.) shall contain a sign signifying the space is occupied by Contractor employee(s) to ensure that Government employees and the public know that they are not Government employees. The proposed sign shall be submitted to the Contracting Officer via the COR for review and acceptance after TO/DO contract award as applicable. Workspace sign location shall be coordinated with the COR. Contractor employees shall identify themselves by name and company affiliation when answering the telephone, presenting briefings, conducting or attending meetings, and seminars. All Contractor correspondence (written, facsimile, and email display) shall include their company name.

1.8.2 Contractor Identification Badges: Contractor personnel shall be easily identifiable through the display of badges IAW Contractor Identification (AE Reg.

27-715).

1.9 Contractor Travel: The Contractor may be required to travel to various CONUS and

OCONUS locations throughout the period of performance of this contract. All travel will be specified at the TO/DO level. The Contractor may be authorized travel expenses at rates no higher than the substantive provisions of the Joint Travel Regulation (JTR), IAW FAR Part 31.205-46, and the limitation of funds specified in the contract. All travel requires Government approval and authorization prior to scheduled travel.

1.10 Other Direct Costs (ODCs): If applicable, ODCs will be specified at the TO/DO level.

ODC costs can include, not to be limited to, special freight/shipping costs, special test equipment or tooling, software licenses/maintenance, expenses associated with OCONUS performance such as DBA insurance, VISAs, housing, leased vehicles, communication costs (phone/internet) sponsorships, Cost of Living Expense (COLA) as well as hardship/danger/hazard differential allowances, etc. All ODCs require Government approval and authorization prior to purchase.

1.11 Data Rights: Specific IP strategies will be developed at the Task Order (TO) level. At each TO, the Government will execute an IP strategy that addresses return on government investment and mitigates the risk of vendor lock by enhanced competitive development, integration, test, deployment, modernization, and implementation of MOSA and open API standards. The Government will establish open standards for model interface requirements and open API specifications that are codified through AI governance policies. The Government will incorporate current AIOps+ development tools as Government Furnished Information (GFI) in a trusted cloud development environment and will employ agile AIOps+ development techniques to accelerate delivery timelines and lower overall programmatic and technical risks. For example, PL’s IP strategy relies on a robust foundation of data generated by government sensors and systems. This data is exclusively owned and produced by the respective government organizations and systems. This data is not supplied by industry partners, nor does it involve the transfer of software. Instead, industry collaborators transform the data using their innovative tools and services to process and prepare it for the development of Artificial Intelligence. Once the data undergoes this transformation, it is referred to as "AI-Ready data." In parallel, industry partners contribute tools and services for managing the government data, maintaining the highest standards of security and integrity. PL is committed to ensuring that contractual agreements result in the acquisition of the necessary data rights for all forms of data, fostering a successful and mutually beneficial partnership between the government and industry.

Program Specific and Product Sustainment Consideration: The IP Strategy will be agile to support a change in the product support strategy, if needed. The commercial market intelligence and market research findings reinforces an approach that leverages multiple modular, short term, and flexible contracts from small business and non-traditional defense capabilities.

Data and Software Deliverable Considerations: Government funded data developed for model training and data labeling, remains the intellectual property of the government as the data was produced from government owned sensors. This includes data with modifications, transformations, and formatting for the program requirements. The government will share this data within the government and with third-party contractors.

• High-level overview of Data and Data Rights

• AIOps+ Pipeline Computer Software

• The Government is intending to maximize the use of COTS and vendor products.

The software components may include tools and techniques developed for organizing and evaluating data and model training algorithms.

• The Government will require Government Purpose Rights (GPR) at a minimum for the software components of the pipeline. The outputs of the components will be Government owned.

AIOps+ Data

• Data produced by government systems or programs to include sensor data, written reports, logs, etc., are fully government owned.

• Synthetic data that is derived from Government data or parameters is Government

Owned.

• Synthetic data that is NOT derived from Government data or parameters Unlimited

Rights.

• Augmentations to the government produced data including transformations/permutations are government owned.

IP Solicitation Plan - Contractor participation in solicitations is contingent upon sufficient clarity in contractors’ identification and assertion of restrictions on IP rights to be able to assess how those assertions may affect IP objectives over the life cycle. Intellectual property may be a source selection factor in any task order as applicable.

1.12 Non-Disclosure Requirements: Performance under this contract may require the

Contractor to access data and information proprietary to a Government agency, another Government Contractor, or of such nature that its dissemination or use other than as specified in this work statement would be adverse to the interests of the Government or others. The Contractor and Contractor personnel, shall not divulge or release data or information developed, or obtained under performance of this PWS, except to authorized Government personnel or upon written approval of the Contracting Officer.

The Contractor shall not use, disclose, or reproduce proprietary data, which bears a restrictive legend, other than as specified in this PWS. All documentation showing individual names or other personal information shall be controlled and protected under the provisions of the Privacy Act of 1974, Public Law 93-579, 5 United States Code (U.S.C.) Section 552a.

1.13 Protection of Government and Contract Information: Per Public Use Notice of

Limitations stated by Defense imagery Management operations Center and contained at www.dimoc.mil/resources/limitations/ , the Contractor shall not cite any information (e.g., contract information, pictures, locations, etc.) obtained through this contract on any hard copy or digital marketing tools to include its company website.

1.14 Non-Disclosure Statements: If applicable at the TO/DO level, the Contractor shall provide signed non-disclosure agreements to the Government prior to commencement of work under the contract. Disclosure of information by Contractor personnel may result in removal of Contractor personnel from performance under this contract.

1.15 Organizational Conflict of Interest (OCI): Contractor and subcontractor personnel performing work under this contract may receive, have access to or participate in the development of proprietary or source selection information (e.g., cost or pricing information, budget information or analyses, specifications or work statements, etc.) or perform evaluation services which may create a current or subsequent OCI as defined in FAR Subpart 9.5. The Contractor shall notify the Contracting Officer immediately whenever it becomes aware that such access or participation may result in any actual or potential OCI and shall promptly submit a plan to the Contracting Officer to avoid or mitigate any such OCI . The Contractor’s OCI Mitigation Plan will be determined to be http://www.dimoc.mil/resources/limitations/ acceptable solely at the discretion of the Contracting Officer. In the event the Contracting Officer unilaterally determines that any such OCI cannot be satisfactorily avoided or mitigated, the Contracting Officer may affect other remedies as he or she deems necessary, including prohibiting the Contractor from participation in subsequent contracted requirements which may be affected by the OCI.

2.0 Applicable Documents: The following documents form a part of this PWS to the extent specified herein. The most recent revision of the referenced document at the time of contract award shall be used unless otherwise specified. In the event of conflict between the applicable documents and this PWS, the PWS shall take precedence. The KO will have final say in any descrepancies that need further clarification. Nothing in this PWS supersedes applicable laws and regulations unless a specific exemption has been obtained. Military and Federal standards, performance specifications, and handbooks may be obtained from the Document Automation and Production Service, Building 4/D, 700 Robbins Avenue, Philadelphia, PA 19111-5094 or visit https://assist.dla.mil/online/start/.

2.1 Inspection/Acceptance: The Contractor shall deliver all products to the locations specified in the TO/DO. Inspection and acceptance of deliverables shall be specified in the TO/DO. When specified, acceptance shall be as indicated on a DD Form 250 or Wide-Area-Work-Flow (WAWF). All products delivered shall be accepted by authorized Government representative. The Contracting Officer and/or Contracting Officer’s Representative shall be notified of any discrepancies found during acceptance inspection upon identification.

2.2 Contract Deliverables: Requests for data under the AIS@P MATOC will be specified on a DD Form 1423, Contract Data Requirements List (CDRL) and will be specified at the TO/DO level. All data shall be prepared and submitted in accordance with the applicable CDRL at the TO/DO level. A list of common CDRLs has been provided below, however this list is not all inclusive and additional CDRLs may be required.

Additionally, associated DIDs may vary at the TO/DO level for required CDRLs. This below list is provided as an example only.

Government Property (GP) Inventory Report DI-MGMT-80441D Contract Work Breadown Structure DI-MGMT-81334D Contract Funds Status Report DI-MGMT-81468A Integrated Master Schedule DI-MGMT-81650 Contractor's Progress, Status and Management Report DI-MGMT-81904 Small Business Utilization Report DI-MGMT-82041B Presentation Material DI-ADMN-81373 Report, Record of Meeting/Minutes DI-ADMN-81505 Training Materials DI-ILSS-80872 Software Version Description DI-IPSC-81442A Scientific and Technical Reports DI-MISC-80048 Test Plan/Procedures DI-NDTI-80808 https://assist.dla.mil/online/start/

3.0 Contract Structure: All TO/DO performed under this MATOC shall be completed within the scope of a RP. RP are defined as a requirement(s) with an associated list of contractors capable of satisfying the pool’s requirements. Contractors will not be limited to participation in a single RP/sRP – contractors with diverse capabilities will be able to compete for work within multiple RP/sRP. Contractors will be unable to participate in every RP/sRP as participation in some RP/sRP may restrict the participation in other RP/sRP as defined below within sections 3.1 and 3.2. Each RP will define additional requirements such as size standards, small business set asides, etc. (Restrictions and set-asides are TBD for this draft of the RFP/PWS).

RPs may be added or removed as required by the Government based on current or future requirements. The Government will post new solicitations on SAM.gov, to be followed by a source selection for each new RP post award of the base contract. As Army and other Government requirements evolve, new RPs will be instantiated in response. The Government will complete ongoing evaluations of RP requirements to ensure that there is a defined need for each RP. The Government may terminate a RP/sRP based on lack of expected future requirements.

RP may be further broken down into sub-Requirement Pools (sRP) as required. sRPs will be smaller pools of vendors broken down by requirement or classification. sRPs will roll up into the RP. The RP and sRP relationship shall best be described as a “parent-child” structure in which the sRPs (child) may only exist under an existing RP (parent).

3.1 RP1 - Artificial Intelligence/Machine Learning (AI/ML): RP1 shall support AI/ML requirements for programs such as PEO IEW&S Project Linchpin (PL). RP1 will be responsible for assisting in delivering trusted AI solutions to Army programs that require infrastructure, standards, process, governance, and AI products solutions and services.

Requirements include but are not limited to:

• AI consulting to assist government with technical architectures, frameworks, and standards;

• Foundational cloud / hybrid cloud, infrastructure services / capabilities

• Internal business management services for onboarding projects, trouble shooting, internal workflow management

• Data Engineering / Data Management

• Data Curating / Data Labeling

• Model Training

• Test & Evaluation (T&E) / Validation & Verification (V&V)

Test Inspection Report DI-NDTI-80809B Technical Work Breakdown Structure and Technology Maturation Plan DI-SESS-82100

Commercial Off-The-Shelf (COTS) Manuals and Assocatiated Supplemental Data DI-TMSS-80527D Maintenance Manual Changes DI-TMSS-81666B Technical Data Packages MIL-STD-31000B

• Deployment and Post Deployment Model Monitoring and Feedback

• Other AI/ML efforts as required

RP1 is designated full and open competition at the base award level. RP1 shall be composed of smaller sRPs, of which some maybe designated limited competition or set-asides. Additional restrictions to competition or small business requirements may also be defined within the individual TO/DO.

3.1.1 sRP1.1 - AI Onboarding Support: This sRP is composed of a team that aligns

AI capabilities with customer objectives by providing use case intake, design planning, and cost estimating services. This service involves a team of subject matter exports who work closely with the PL customers to tailor their AI initiatives to their specific needs and goals. The contractor shall be responsible for providing services within the following scope:

3.1.1.1: Provide use case intake services to gather and analyze the

Governments’ requirements for AI solutions.

3.1.1.2: Provide design planning services to develop a detailed plan for implementing AI solutions that meet the Government’s requirements.

3.1.1.3: Assist the Government with cost estimating services to provide a detailed cost analysis for the implementation of the proposed AI solutions.

3.1.1.4: Ensure that the AI initiatives are aligned with the Governments strategic objectives and delivered in a cost-effective manner.

3.1.1.5: Maintain market awareness of latest AI standards, technologies, and solutions.

3.1.1.6: Other AI Onboarding services as required by the Government.

3.1.2 sRP1.2 - Data Management & Labeling: This sRP is composed of a dedicated data management team consisting of skilled data engineers, data scientists, and data analysts. Their primary responsibility is to oversee the entire data lifecycle, ensuring data is effectively managed from creation to disposal. Data labeling involves assigning tags or annotations to data from standard ontologies to provide a clear understanding of the data’s meaning and context. PL will provide high-quality labeled datasets for training and testing by utilizing trained, knowledgeable labelers and/or automated methods. The contractor shall be responsible for providing services within the following scope:

3.1.2.1: Onboard Army data into secure hosting environments.

3.1.2.2: Design and implement a secured data architecture and infrastructure, including data warehouses, data lakes, data pipelines, and versioning.

3.1.2.3: Develop and maintain data integration and transformation processes to ensure data is secure, accurate, complete, and consistent.

3.1.2.4: Maintain Government provided and Government hosted data Application Programming Interfaces (API) to enable data access controls and integration with other systems.

3.1.2.5: Implement data security and privacy measures to protect sensitive data and ensure compliance with regulations and policies.

3.1.2.6: Monitor and optimize data pipelines to ensure they are performing efficiently and meeting Service Level Agreements (SLA).

3.1.2.7: Provide data engineering support and guidance to other teams and users.

3.1.2.8: Implement and maintain a data catalog that enables easy discovery, understanding, and management of data products within the pipeline.

3.1.2.9: Ensure that the data is handled in accordance with applicable statutes and regulations and that it is secure from unauthorized access.

3.1.2.10: Integrate data from multiple sources and support the data sharing process to provide a comprehensive view of the data, which may involve using data integration tools or creating custom scripts.

3.1.2.11: Provide a team of qualified data labelers who have experience in labeling the specific type of data required for the project.

3.1.2.12: Ensure that all data labelers are trained and supervised to ensure the quality of the labeling work.

3.1.2.13: Ensure that all data is labeled accurately and consistently, and any errors or inconsistencies are corrected promptly.

3.1.2.14: Ensure the data labeling standard and ontologies provided by the Army.

3.1.2.15: Use appropriate tools and technologies to label the data efficiently and accurately.

3.1.2.16: Leverage the Army’s environment for handling and storing the data, and ensure that all data is kept confidential, secure, and does not leave the Army’s environments.

3.1.2.17: Provide regular progress reports and updates to the Government, including the number of data points labeled and any issues or challenges encountered.

3.1.2.18: Other AI Data Management and Labeling services as required by the Government.

3.1.3 sRP1.3 Model Development and Training: This sRP is composed of a Model Training team of data scientists and ML engineers. Their responsibility is to train AI models, enabling them to learn and make accurate predictions, decisions, or take appropriate actions based on the data. During the training process, the algorithm is exposed to a large number of examples, allowing it to identify patterns and relationships in the data. The contractor shall be responsible for providing solutions within the following scope:

3.1.3.1 Have expertise in developing and training AI models for each of the required modalities (imagery, text, signals) and shall provide evidence of their experience and qualifications.

3.1.3.2 Train AI models for imagery, text, and/or signals.

3.1.3.3 Ensure that all AI models are developed, trained, and hosted within a secure hosting environment that meets government security standards and regulation.

3.1.3.4 Provide documentation for each AI model (model cards) that includes what it was trained on, what architecture was used, and what pretrained weights are used.

3.1.3.5 Other Model Development and Training services as required by the Government.

3.1.4 sRP1.4 Test & Evaluation (T&E): This sRP is composed of a Testing and Evaluation team who are responsible for testing and evaluating AI models.

Their responsibility is to conduct a range of tests and evaluations at different levels. The goal is to ensure that the AI/ML model is performant, reliable, and meets the requirements of the intended application or use case. The contractor shall be responsible for providing services within the following scope:

3.1.4.1 Provide a team of qualified AI/ML engineers who have experience in testing and evaluating AI/ML models.

3.1.4.2 Have the capability to test and evaluate AI/ML models in multiple modalities, including imagery, text, and sensors.

3.1.4.3 Follow the testing and evaluation guidelines and protocols provided by the Government.

3.1.4.4 Ensure that all testing and evaluation is conducted in inside the

Army’s Secure Environments.

3.1.4.5 Build T&E pipelines inside the Governments Secure Environment to ensure the tests are repeatable.

3.1.4.6 Use appropriate tools and technologies to test and evaluate the AI/ML models.

3.1.4.7 Provide regular progress reports and updates to the Government, including the results of testing and evaluation and any issues or challenges encountered.

3.1.4.8 Other T&E services as required by the Government.

3.2 RP2 – Software (SW) Development: RP2 shall support SW Development which shall include design, development, fabrication, and testing of developmental systems covering the complete range of the Electronic Warfare and Cyber, PEO IEW&S or other customer portfolios as required. Support shall include but not be limited to system engineering and integration, test and evaluation services, logistics support, as well as operation and maintenance support. RP2 will be responsible for developing SW solutions in the following areas:

• Development of custom SW, to include both cloud and localized solutions

• Plug-in or other SW development in support of electronic warfare, signals intelligence, or cyber effects

• Commercial Off The Shelf (COTS) SW solutions, to include modified COTS to meet

Government requirements

• Customization, integration, or modification of a SW solution

• SW as a service enablement

• SW security and hosting modernization

• Integration of SW into a Hardware (HW) solution, to include HW procurement

• Other SW development efforts as required

• Implementing Modular Open Systems Approach (MOSA) for software engineering, modifications, development, and support to include development of Open Systems Management Plans that describe the developer’s MOSA to implement an Open Systems Architecture (OSA).

Clearance requirements for RP2 – SW Development will be defined at the TO/DO level and potentially require up to TOP SECRET.

3.2.1 sRP2.1 Software and Systems Engineering Support: The Contractor shall provide engineering support utilizing an open software architecture focused on the following areas:

3.2.1.1 Software Architecture and Design: The Contractor shall develop and maintain an open software architecture that enables centralized Command and Control (C2) utilizing persistent and non-persistent data links; shall implement software solutions to support autonomous, semi-autonomous, ore pre-programmed actions for Denied, Disrupted, Intermittent, and Limited (bandwidth) operations; and shall integrate with existing systems, common architectures, frameworks, and standards (APIs, ICDs, etc.) and adhere to open systems architecture approaches (MOSA, OSA).

3.2.1.2 Situational Awareness and Data Processing: The Contractor shall develop and integrate software components to enhance situational awareness, enabling timely and informed decision-making; shall implement data analysis and reporting capabilities, including data collection, analysis, visualization, and interpretation; and shall ensure secure data processing practices following Development Security Operations (DevSecOps) principles and cybersecurity requirements.

3.2.1.3 Cybersecurity Engineering: The Contractor shall integrate cybersecurity measures, such as firewalls, antivirus and malware software, encryption, multi-factor authentication, and intrusion detection; and shall ensure software and systems comply with cybersecurity standards and shall implement secure software development practices (DevSecOps, cybersecurity requirements, etc.).

3.2.1.4 Systems Integration and Configuration: The Contractor shall plan and deploy software and systems, including objective setting, resource planning, and risk identification; shall perform configuration and calibration to ensure compatibility, measurement accuracy, and optimal performance of PEO systems; and shall integrate with existing systems, common architectures, frameworks, and standards (APIs, ICDs, etc.) and adhere to open systems architecture approaches

(MOSA, OSA).

3.2.1.5 Resource Management: The Contractor shall develop and implement software solutions for efficient management of shared resources, such as transceiver channels, CPU/GPU/FPGA processing, and Direction Finding (DF); shall optimize resource allocation and usage across manned and unmanned remote devices and other legacy and future Army EW sensors and effectors; and shall ensure resource management practices align with secure software development principles.

3.2.1.6 Monitoring, Control, and Performance Optimization: The Contractor shall implement software solutions for monitoring and control of manned and unmanned remote devices and EW sensors and effectors; shall ensure that all integrated systems function as intended and meet performance requirements; and shall continuously monitor and optimize performance, ensuring compliance with cybersecurity standards.

3.2.1.7 Software Maintenance and Upgrades: The Contractor shall provide ongoing software maintenance, updates and upgrades to enhance functionality, improve performance, and address security vulnerabilities; shall ensure software and systems remain compatible and interoperable with evolving technologies and standards; and shall follow configuration management and operation and maintenance activities.

3.2.1.8 Documentation and Requirements Management: The Contractor shall develop and maintain comprehensive documentation, for example, Software System Specifications (SSS), Software Requirements Specifications (SRS) and Interface Design Documentation (IDD); shall adhere to development processes and standards (for example

IEEE/EIA 12207, Agile methodologies); and shall ensure all documentation aligns with secure software development and integration practices.

3.2.1.9 Other SW efforts as required for design, development, fabrication, procurement, and testing in support of PEO IEW&S, US Army, or other DoD programs.

3.2.1.10 Characteristics of open software architecture shall include, but are not limited to:

• Modular Design

• Standardized Interfaces

• Interoperability

• Scalability

• Open Standards

• Transparency

• Extensibility

3.2.2 sRP2.2 Electromagnetic Spectrum (EMS) Techniques Support: The Contractor shall have the following abilities to provide EMS techniques support.

3.2.2.1 Signal Detection and Analysis: Ability to detect, exploit, copy and identify known and unknown Signals of Interest (SOIs).

3.2.2.2 EMS Effects: Ability to disrupt or deceive an adversary’s command and control system, communication or sensor network via RF effects.

3.2.2.3 Signal Exploitation: Ability to perform signal exploitation for sensing, detecting and identification for known and unknown signal types.

Ability to perform signal exploitation for D4M missions.

3.2.2.4 Technique Implementation: Ability to develop techniques (detectors and effectors) for known and unknown signal types. Ability to implement EMS techniques into executable EMS capabilities. Ability to provide integration of EMS capabilities into existing EMS frameworks and platforms.

3.2.2.5 Advanced, Coordinated EMS Effects: Ability to develop and perform advanced simultaneous, multi-target, multi-platform coordinated RF effects. Ability to optimize scheduling of multiple missions within a single system. Ability to optimize scheduling of multiple missions between multiple systems. Ability to implement multi-ship geolocation from systems on separate timing. Ability to perform Multi-ship coherent jamming.

3.2.3 sRP 2.3 Infrastructure as a Service: The Contractor shall provide the following capabilities as part of Infrastructure as a Service support:

3.2.3.1 Cloud Services: The Contractor shall acquire Government Cloud

Services to host a DevSecOps Continuous Integration / Continuous Deployment (CI/CD) environment which will include tools that include, but are not limited to: source code management, collaboration tools, build servers, test servers, development servers, identity access and management, and artifact repositories. The Government will not direct which cloud-based service is used.

3.2.3.2 Secure Hosting and Security Compliance: The Contractor shall provide secure hosting compliance and shall acquire and provide an IaaS solution that is rated to host up to Impact Level 5 information (DoD CUI and National Security Systems (NSS)) as per Defense Information Systems Agency Cloud Computing Guide and shall ensure that the IaaS environment complies with all relevant security standards and regulations, including but not limited to DoD CUI and NSS requirements.

3.2.3.3 Software Licensing: The Contractor shall acquire and provide commercial licensing for any software needed to fulfil the following criteria:

• Requirements and Design

• Git based source code configuration management services or equivalent

• Build CI/CD tool

• Code quality coverage and analysis tool

• Binary artifact repository service

3.2.3.4 System Administration and License Ownership and Delivery: The

Contractor shall provide system administration, registration, and access management for the IaaS environment for Government, Contractor, and Government directed users and shall ensure the Government is named as the owner/purchaser of these software commercial licenses and shall deliver these licenses in accordance with applicable CDRLs specified at the DO/TO level.

3.2.3.5 CM Library Administration: The Contractor shall administer a CM Library or Source of Record for key documents and artifacts to include a Technical Data Package (TDP) up to and including Level III.

3.2.3.6 Continuous Integration/Continuous Deployment (CI/CD) Setup: The Contractor shall set up and configure the CI/CD pipeline to automate the building, testing, and deployment of applications.

3.2.3.7 User Support and Training: The Contractor shall provide ongoing user support and training for Government and Contractor users to ensure effective use of the IaaS environment and associated tools.

3.2.3.8 Monitoring and Maintenance: The Contractor shall monitor the IaaS environment for performance, security, and compliance, and perform regular maintenance to ensure optimal operation.

3.2.4 Development Security Operations (DevSecOps): The Contractor shall possess extensive knowledge in the DevSecOps process and leveraging of DoD enterprise DevSecOps approaches and tools for development of a software factory and Continuous Integration/Continuous Deployment (CI/CD) pipeline. Including a change management system, unit test scripts, and implementation of cybersecurity requirements. Experience with a secure Impact Level 5 (IL5) DevSecOps environment to perform software development, integration, testing, security, and software hardening in support of production/delivery pipeline.

3.2.4.1 The Contractor shall Implement Modular Open Systems Approach

(MOSA) for software engineering, modifications, development, and support.

3.2.4.2 The Contractor shall support the development of Open Systems Management Plans that describe the developer’s Modular Open Systems Approach (MOSA) to implement an Open Systems Architecture (OSA).

3.2.4.3 The Contractor shall develop documentation outlining technical requirements in a System Subsystem Specification (SSS), Software Requirement Specification (SRS) Interface Design Description (IDD), System Subsystem Design Document (SSDD), Software Version Description Document (SVDD), Software Design Document (SDD) Software Architecture design document (SADD), and Network Management Plan (NMP).and any other document applicable to documenting the design.

3.2.4.4 The contractor shall utilize tools for capturing system and software requirements such as Model Based Systems Engineering (MBSE) CAMEO, IBM DOORs, etc.

3.2.4.5 The contractor shall develop a Requirements Verification Traceability Matrix (RVTM) to show the following in order to show requirement compliance:

• Requirement ID

• Requirement Description

• Verification Method

• Verification Results

• Traceability

3.2.4.6 The Contractor shall perform software development utilizing Institute of Electrical and Electronics Engineers (IEEE) and the Electronic Industries Association (EIA), IEEE/EIA 12207 or equivalent standard for software life cycle processes.

3.2.4.7 The Contractor shall provide Software Development Kits (SDK) that enables external entities to develop additional capabilities to augment SW functionality, integrate as part of a future baseline, and leverage the existing system data, sufficient for third party developers with knowledge of software languages and tools to be independently trained via a training course.

Software development process that supports DevSecOps in the form of sprints and epics to rapidly deliver incremental capabilities, test incremental updates, and address defects and evolving requirements on an ongoing basis.

3.2.4.8 In addition to advanced capabilities, Contractors shall provide solutions to potential requirements centered around Signals of Interest capabilities such as identifying, scheduling on single and multiple systems, jamming and attacking as required at the DO/TO level. The Contractor shall perform engineering disciplines for the design, development and production of new and modified EWC systems and Information Technology (IT) capabilities. Contractor support shall include scientific analytical and engineering efforts necessary to transform operational needs into unique system performance parameters for evolution into improved system capabilities.

3.2.4.9 The Contractor shall provide modeling, hardware design, simulation and prototyping when required and concepts shall include provisions for continuous technological improvement to maximize opportunities for product improvement available from emerging technological advances in the marketplace. Proven technologies, products and processes shall be utilized wherever possible. Contractors shall be available to support technical interchange meetings and Integrated Product Teams as required.

3.2.5 Integration: The contractor shall have thorough knowledge of the existing EWC systems operations, components and subsystems; and the interoperability of proposed systems to existing networks. Solutions shall have the capability to leverage software Interface Control Documents (ICDs), Software Development Kits (SDKs), and Application Programming Interfaces (APIs) to facilitate efficient and timely software development and integration efforts. Examples include but not limited to the Tactical Assault Kit (TAK-X), Fabric User Situational Environment (FUSE), Joint Interface Control Document (JICD) 4.2.X, JICD Common Services, Network-Centric Collaborative Targeting (NCCT), Theater Net-Centric Geolocation (TNG), and the Modular Payload Standard. Proposed architectures shall ensure compatibility, security, message generation, data dissemination and interoperability with legacy and future military EW systems and subsystems while facilitating the integration of advanced data analytics and machine learning components that aid in:

• Data collection for rapid data processing and information gathering.

• Feature engineering involving data transformation, extraction and selection.

• Model selection for identification of the most appropriate machine learning algorithm for problem identification and resolution.

• Validation ensuring selected model can generalize well to new and unseen data.

• Deployment for integrating the model into a host environment where it can be used to make predictions on new data or to automate the decision-making process.

3.2.6 Configuration Management: The Contractor shall perform the following CM functions when developing a system or software architecture:

• Configuration identification

• Configuration Control

• Configuration Auditing

• Release Management

• Change Management

• Version Control

3.2.7 Metrics: The Contractor shall provide the following, but not limited to, metrics:

• Performance

• Reliability

• Maintainability

• Scalability

• Availability

• Security

• Cost

3.2.8 Integrated Logistics Support: The Contractor shall provide Integrated

Logistics Support (ILS) services and data in all areas of Life Cycle Management within the EWC portfolio as defined at the DO/TO level. The contractor shall implement ILS as a multi-functional technical management discipline associated with the design, development, test, production, fielding, sustainment, and improvement modifications of cost effective EWC systems that achieve the warfighters' peacetime and wartime readiness requirements.

The principal objectives of ILS are to ensure that support considerations are an integral part of the system's design requirements, that the system can be cost effectively supported through its life cycle (from program initiation to system retirement), and that the infrastructure elements necessary to the initial fielding, operation and maintenance support of the system are identified, developed and acquired. The Contractor shall ensure systems are designed with support considerations from the outset. The Contractor shall identify and acquire necessary infrastructure elements for initial fielding, operation and maintenance when applicable.

3.2.8.1 The Contractor shall provide any or all of the following publications:

systems level operations and maintenance technical manual, quick reference guide, and electronic formatted manuals to include but not limited to, Electronic Technical Manual (ETM), Interactive Electronic Technical Manual (IETM), Modification Work Orders, Field or Technical Bulletins, Repair Parts and Special Tools technical manuals, Provisioning…