SS DRAFT - Attachment 1 - Draft STATEMENT OF OBJECTIVES - Software Development and Technical Support.pdf

DRAFT

DRAFT DOCUMENT

Department of Commerce National Oceanic & Atmospheric Administration

Office of Oceanic & Atmospheric Research Geophysical Fluid Dynamics Laboratory and

Office of the Chief Information Officer

INDEFINITE DELIVERY INDEFINITE QUANTITY

STATEMENT OF OBJECTIVES

High Performance Computing

Software Development and Technical Services

AUGUST 2026

GFDL SDTS IDIQ SOLICITATION | STATEMENT OF OBJECTIVES (SOO)

1 INTRODUCTION AND BACKGROUND

The Geophysical Fluid Dynamics Laboratory (GFDL) is a Federal research laboratory within the Office of Oceanic and Atmospheric Research (OAR), a line office of the National Oceanic and Atmospheric Administration (NOAA). GFDL conducts advanced scientific research to improve the understanding of physical, chemical, and biological processes governing the Earth system.

To achieve this, GFDL relies on state-of-the-art computational models, high-performance computing (HPC), and highly specialized systems engineering support services.

To maximize technical efficiency, reduce administrative overhead, and establish a highly stable and responsive technical operations framework, the Government consolidated its requirements into a unified, four-objective procurement structure. This strategy optimizes operational agility by grouping related IT, supercomputing, facilities, and business support disciplines into cohesive management zones under a single-award Indefinite Delivery, Indefinite Quantity (IDIQ) contract.

1.1 Purpose and Scope

The objective of this acquisition is to procure scientific software engineering, Information Technology (IT) system administration and operations, cybersecurity, and administrative and facilities management services to sustain and advance the strategic missions of the GFDL and the NOAA. The designated Contractor shall execute these requirements within an integrated, highly collaborative workforce structure, maintaining close coordination with Federal research scientists, university researchers and students, technical personnel, contractor staff, and industry stakeholders. Furthermore, the Contractor shall furnish all management, technical supervision, qualified personnel, materials, and operational resources required to fulfill the specific performance objectives mandated in each Task Order.

The scope of this Indefinite Delivery, Indefinite Quantity (IDIQ) contract encompasses High-Performance Computing (HPC) software engineering, scientific modeling integration, data science, and specialized technical, business, and facilities administration for GFDL. Additionally, it provides critical infrastructure and operational support to NOAA's Office of the Chief Information Officer (OCIO) in the administration and security governance of the agency's Research and Development High Performance Computing Systems (R&DHPCS) enterprise.

Key functional domains within scope of this IDIQ include:

1. Component and coupled Earth system model engineering;

2. Scientific software infrastructure maintenance and modernization;

3. Data science and high-volume data management;

4. Embedded scientific support and analysis;

5. Multi-OS endpoint system administration;

6. Continuous 24/7/365 computer operations;

7. Tiered technical help desk support;

8. Business operations management

9. Advanced HPC and network security hardening; and 10.Comprehensive facilities management, maintenance, and more.

Although this contract excludes the direct procurement of high-performance computing hardware, Contractor personnel shall formulate technical requirements and specifications for systems, hardware, software, and external services to be acquired directly by the Government.

1.2 Program Objectives

The consolidated four-objective structure is defined as follows:

Objective 1: Enabling Earth System Model Development. Focuses on capacity-based, agile software engineering to develop and optimize NOAA's Earth System Models and modeling infrastructure. Focus areas include developing the Flexible Modeling System (FMS); supporting the development of Earth system model components; developing and deploying the GFDL FMS Runtime Environment (FRE) and associated utilities and tools; supporting fully integrated models through testing, development, running, and evaluating scientific output; testing and validating software and hardware on HPC and cloud systems; deploying a unified, user-facing software stack; evaluating and implementing the latest emerging technologies; managing, integrating, and publishing data; leveraging the latest data science advances; and providing direct support and liaison to scientific divisions at GFDL.

Objective 2: Endpoint Administration, Computer Operations, & Business Administration.

Consolidates all standard operational IT and management support. This includes user endpoint support (Linux/Windows), 24/7/365 remote and on-premise supercomputing systems operations (remote and local high-performance computing, Hierarchical Storage Management System, and networks), IT projects and project management, and administrative/mission-oriented support (federal travel, security clearances, foreign national visitors, human resources, and property management).

Objective 3: High Performance Computing (HPC) Support & Network Security.

Establishes a highly proactive, continuous threat monitoring and vulnerability defense posture for all NOAA OCIO and GFDL HPC, network, and development environments. Focuses on security compliance, automated DevSecOps pipelines, FEDRAMP cloud authorizations, and rapid 1-hour critical incident reporting and response.

Objective 4: Facilities. Provides 24/7/365 facilities consulting, management, engineering, project management, data center physical power and cooling operations, preventative maintenance, and on-demand trade and construction services for minor building alterations.

1.3 GFDL Vision, Mission, Goals

GFDL, located on Princeton University's Forrestal Campus in Plainsboro, New Jersey, is a world-class federal research laboratory operating under NOAA's Office of Oceanic and

Atmospheric Research (OAR). GFDL’s vision are climate-and weather-ready communities and economies and healthy ecosystems enabled by trusted and actionable earth system science. Its mission is to advance the scientific understanding, predictions and projections of the climate and earth system, and inform decision-making through comprehensive computational modeling covering weather to climate timescales. GFDL scientists apply these comprehensive models to seamlessly understand, predict, and project Earth system behavior across multiple spatial and temporal scales, from global-to-regional and from hours to decades, accounting for natural environmental variations and forced changes.

Models developed and refined at GFDL are frequently transitioned into operational environments across NOAA and other federal and international agencies. These models represent vital, societally relevant decision-support tools used to assess environmental shifts, forecast extreme weather, protect life and property, manage coastal and marine resources, inform local, state, and national policymakers, and enhance the nation's economy.

The following is a summary of the top five overarching scientific efforts anticipated to be undertaken at GFDL over the next five to ten years:

1. Unified Modeling & Prediction: Focus on unified Earth system modeling to provide seamless predictions across timescales.

2. Advance Scientific Understanding of the earth system: Deepen fundamental research into Earth system processes to improve understanding, model fidelity and accuracy.

3. Artificial Intelligence (AI), Machine Learning (ML), & Computational Modernization:

Leverage AI/ML to accelerate model discovery and transition to modern and scalable computing and HPC and cloud environments.

4. Societal Connectivity & Impacts: Bridge the research-to-applications (R2X) gap to deliver actionable scientific products.

5. GFDL-Wide Collaborative Enterprise & Infrastructure: Foster research through laboratory-wide coordination, open data platforms, and talent development.

GDFL undertook a gap analysis and found the following with respect to current versus future states:

Gap Area 1 Earth System Modeling Coordination—Address fragmented modeling ecosystems by moving towards unified modeling within the lab

Gap Area 2 Strategic Computing Modernization & Data Infrastructure—Transition from traditional HPC to modern and scalable computing environments for kilometer-scale modeling.

Gap Area 3 Stakeholder Engagement & Co-development—Focus on targeted, continuous co-development to address societal impacts throughout the research and development lifecycle.

Gap Area 4 Governance and Cross-Lab Leadership Authority—Establish administrative frameworks that grant cross-lab leads clear authority.

Gap Area 5 Private Sector Partnerships & Workforce—Engage with the broader private ecosystem; build a robust talent pipeline.

Through this acquisition, GFDL seeks a contract partner to help it bridge these gaps in order to achieve its five to ten year scientific objectives, to advance NOAA’s mission, and achieve its vision.

1.4 The Software Development and Technical Services (SDTS)

Requirement

To pursue its ambitious scientific mission, GFDL partners closely with NOAA's OCIO to secure, manage, and seamlessly integrate the high-performance computing (HPC) resources that are critical to Earth system modeling. Under the SDTS requirement, the Contractor shall provide a highly specialized technical, scientific, and administrative workforce capable of supporting GFDL and NOAA OCIO. The Contractor's staff will work in a fully integrated environment alongside federal scientists and academic partners, including the Atmospheric and Oceanic Sciences (AOS) Program and the Cooperative Institute for Modeling the Earth System (CIMES) - a collaborative program with Princeton University funded by NOAA cooperative agreements, and well as collaborators from the University Corporation for Atmospheric Research (UCAR).

1.5 Modeling in Support of Science (The Technical Baseline)

GFDL's state-of-the-art component and coupled global Earth system models provide a suite of societally relevant decision-support products. The Contractor shall support a complex, evolving scientific technology stack and partnership network, which includes:

1. Core Modeling Frameworks: The Flexible Modeling System (FMS) is the foundation of all earth system models at GFDL and is developed by MSD. At the top level is the FMS Coupler which runs the GFDL models and allows the atmosphere, land, ocean, and ice components to work together to model the entire earth system. MSD is the primary development team of these infrastructure layers and supports development of the earth system components.

2. Unified Forecast System (UFS) & EPIC: In partnership with the National Centers for Environmental Prediction (NCEP) and the Environmental Modeling Center (EMC), GFDL laid the foundation for the UFS - NOAA's framework for unifying research and operational forecasting. GFDL develops key UFS components (FV3, MOM6, LM4, and FMS) and collaborates with NOAA's Earth Prediction Innovation Center (EPIC) to accelerate development, containerization, and expand open-source academic collaboration.

3. Advanced Tracking & Grid Tools: GFDL maintains and modernizes the GFDL Vortex Tracker - a critical tropical cyclone forecasting tool transitioned into a GitHub (https://github.com/) hosted resource. GFDL also develops grid generation and manipulation tools for the atmosphere and ocean systems and for facilitating the complex interactions between them. GFDL also maintains a suite of post processing tools.

4. Rigorous Cross-Platform Testing: A central part of GFDL's methodology includes rigorous testing across on-premise HPC Systems and cloud environments. This testing ensures scientific reproducibility and data integrity on existing and newly delivered systems.

5. Interagency & Community Partnerships: GFDL's research is executed in close collaboration with the National Weather Service (NWS), the Weather Program Office (WPO), the National Aeronautics and Space Administration, the Department of Energy, the Department of War, the Environmental Protection Agency, Princeton University, other universities, private sector and nonprofit partners, and others both inside and outside of government and academia.

1.6 Operating Environment Complexity and Workforce Stability

The Government has managed model development, system administration, operations, security, facilities management, and business administration at GFDL for over seventy years. Throughout this history, the Government has established that the stability and continuity of its highly specialized, blended workforce is essential to the successful pursuit of its complex mission. This extends beyond the complexities of numerical weather prediction and extends even to GFDL's physical operating environment.

Situated on a 6.25-acre parcel, inclusive of its adjacent parking lot, the GFDL complex consists of three distinct but highly integrated buildings:

1. The Main Building: A 50,000-square-foot, three-story steel and glass structure constructed in 1968. This building houses GFDL's scientific, administrative, and support staff, and requires standard comfort HVAC.

2. The Computer Building: A 18,000-square-foot, slab-on-grade facility constructed in 1981. This building houses the supercomputing infrastructure and requires precision process cooling and humidity control around the clock every day of the year.

3. The Generator Enclosure Building: A 2,000-square-foot, weathertight brick-and-block building constructed in 2018 that houses the facility's two 1-megawatt diesel electric standby generators.

The Main Building and Computer Building are physically interconnected structures that share a common electrical feed, a common chilled water plant, and overlapping mechanical infrastructure. Given the age, interdependency, and divergent HVAC requirements of these systems, there is a substantial learning curve required to master the equipment's behavior and https://github.com/ its integration with the Laboratory's scientific community, HPC networks, and archival data storage systems. Because Contractor personnel will develop highly specialized institutional knowledge, not just regarding the facility, but for the other elements of this requirement as well, the Contractor is expected to implement robust work-life balance, professional development, competitive compensation, and advanced benefits programs across the full scope of this requirement to minimize staff turnover to the greatest extent possible.

1.7 The Modeling Systems Division (MSD) and Software Ecosystem

Modeling Systems Division's (MSD) mission is to develop and maintain the user-facing software infrastructure that enables development of Earth system and climate models and high-performance computing (HPC) at GFDL. MSD focuses on four main areas: the Flexible Modeling System (FMS); the FMS Runtime Environment; exploring advanced and emerging technologies such as heterogeneous HPC, cloud, DSLs, and AI/ML; and data services for internal use and external partnerships. Additional areas of focus include building an integrated set of tools that scientists use in various analysis and visualization activities, and working with the GFDL computer users to implement lifecycle management for those tools. The Data Sciences team also develops and maintains the Model Diagnostics Taskforce Framework. The work of MSD is highly complex and must be responsive to various scientific opportunities or issues as they arise, often unexpectedly. Consequently, among its requirements, MSD must have the ability to pivot effort and provide surge capacity in order to support scientific inquiry and development that is not well defined nor predictable in advance.

The relationship between the scientific models and the infrastructure can be broken down into specific roles:

1. Model Components (The Science): GFDL's specific models - such as the Modular Ocean Model (MOM6) or atmospheric dynamical cores like FV3 - contain the scientific code to model fluid dynamics and physical parameterizations.

2. The Flexible Modeling System (FMS): Developed in 1998 and continuously modernized, FMS is a software framework for supporting the efficient development, construction, execution, and scientific interpretation of atmospheric, oceanic, and climate system models. FMS provides the infrastructure to handle parallelization, I/O, data exchange between distinct model grids, and orchestration of time stepping, largely insulating users from machine-specific details. FMS standardizes interfaces between component models and employs a rigorous software quality review process for contributed models.

3. FMS Runtime Environment (FRE): FRE is a suite of workflow management tools that encapsulates complete model configurations. It reduces model spin-up time, minimizes manual configuration errors, and enables reproducibility. FRE manages everything from the submission of model runs and output archiving to post-processing and automated analysis figure creation.

4. High Performance Computing (HPC): GFDL’s models run on HPC systems. MSD works with science groups to ensure that code runs efficiently on the NOAA HPC and cloud systems by running manual regression tests and automated continuous integration (CI) tests with various supported compilers. Additionally, MSD tests new HPC, emerging technology (e.g., AI/ML), and cloud systems while modifying workflow and other software to ensure that models can continue to run on the new platforms.

5. Software Management: In order to maintain consistency across HPC and local computing environments, MSD maintains and releases a unified software stack that is the same across HPC and local computers. The software stack is used by the GFDL community to enable the science via post processing and analysis of the model output, and can be used to support GFDL products such as the GFDL Vortex Tracker.

Containerized software stacks are developed and maintained for model building/running and supporting the FRE workflow.

6. Data and Metadata: The FRE infrastructure and data stewardship tools provide the software infrastructure and data catalog capabilities needed to manage, organize, and share data from model configuration through archival. Together, they unify access to climate modeling components and enable scientists to efficiently publish and make datasets discoverable to the broader community, leveraging and contributing to evolving community standards for interoperable data discovery and access.

7. Data Portal and Public Releases: Public datasets from GFDL model simulations are distributed through institutional and NOAA-aligned repositories, including the GFDL Data Portal (http://data1.gfdl.noaa.gov/) and NOAA Open Data Dissemination (https://www.noaa.gov/information-technology/open-data-dissemination) with Digital Object Identifiers, where applicable. Furthermore, GFDL's Flexible Modeling Infrastructure and several model codes are maintained as public releases. MSD manages the Data Portal and the NOAA-GFDL GitHub (https://github.com/NOAA-GFDL/) where the model release code is available.

8. Data Stewardship and Stakeholder Engagement: In partnership with the GFDL Data Science group, the Contractor shall co-create systems, workflows, processes, and open data platforms that make Earth system data products usable, accessible, and transparent. By leveraging AI/ML, cloud-native object storage, and modern big data ecosystems (e.g., Pangeo, data catalogs, NetCDF/Zarr), the Contractor shall facilitate the translation of science to societal applications. This includes developing smart data exploration hubs with semantic translation utilities and organized data-use training modules to bridge complex Earth system models and data with public and private stakeholder needs. The effort will also develop Earth system analysis frameworks, leveraging and extending the Model Diagnostics Task Force (MDTF https://www.gfdl.noaa.gov/mdtf-diagnostics/)) software framework for process-oriented diagnostics across climate and weather data, including data generated by AI emulators.

http://data1.gfdl.noaa.gov/ https://www.noaa.gov/information-technology/open-data-dissemination https://github.com/NOAA-GFDL/ https://www.gfdl.noaa.gov/mdtf-diagnostics/

1.8 Hierarchical System Development (HSD)

GFDL's engineered workflow ecosystem utilizes the Hierarchical System Development (HSD -https://ral.ucar.edu/testing-and-evaluation/hierarchical-system-development) methodology to accelerate scientific discovery and enhance performance tracking. By allowing developers to enter the testing pipeline at multiple levels of complexity, HSD avoids the risks of testing massive, fully coupled systems all at once.

HSD generally follows a "simple-to-more-complex" methodology:

1. Component and Mechanism Level: Testing individual physics schemes or isolated modules.

2. Simplified Environments: Running small-domain, regional, or Single Column Models (SCMs).

3. Fully Integrated Systems: Deploying complex, global, or fully coupled prediction models (e.g., integrating atmospheric, ocean, sea-ice, and land models together).

4. End-to-End Evaluation: Continuous verification spanning data assimilation, modeling, and post-processing steps.

1.9 The Computing Environment

The computing environment operates 24 hours a day, 365 days a year. Reliability, availability, and Contractor support are considered fundamental aspects of the HPCS and are key requirements for any proposed HPCS changes or related procurements.

High-Performance Computing (HPC): NOAA's Research and Development High-Performance Computing (RDHPCS) program is critical to the GFDL mission. It is managed by NOAA's Office of the Chief Information Officer (OCIO). The RDHPCS program consists of large computational and storage environments at various sites across the nation to support numerical modeling. The RDHPCS sites include:

1. Geophysical Fluid Dynamics Laboratory (GFDL) in Princeton, New Jersey

2. NOAA Environmental Security Computing Center (NESCC) in Fairmont, West Virginia

3. DOE's Oak Ridge National Laboratory (ORNL) in Oak Ridge, Tennessee

4. University of Mississippi in Starkville, Mississippi

5. Cloud Computing supplied by Microsoft Azure, Google Cloud Platform, and Amazon

Web Services

In addition to the RDHPCS compute resources, the RDHPCS contains two Hierarchical Storage Management Systems (HSMS) providing exabyte (EB) scale archiving capacity to meet the rates of data generated on the production computing systems. The systems are located in Fairmont, WV and Princeton, NJ.

https://ral.ucar.edu/testing-and-evaluation/hierarchical-system-development

The NOAA N-Wave Enterprise Network (https://www.noaa.gov/organization/information-technology/n-wave) connects the remote production nodes to the local post-processing and analysis nodes, the HSMS, and the user workstations. Of particular note is a highly specialized set of tools needed to satisfy the extremely demanding requirement for reliable transfer of data from the remote production sites to the storage and analysis systems at GFDL.

Local Computing and User Base: Distributed throughout GFDL are approximately 250 Linux-based desktop workstations and laptops, primarily located in scientists' offices, and also within several shared spaces within the Lab. These workstations are used for data analysis and visualization of the results from HPC experiments. In addition, the Laboratory also provides approximately 50 Windows desktops and laptops to its scientific, information technology, administrative, and leadership staff. There are about 250 users at GFDL and approximately 150 other collaborators worldwide currently who share all of these computing resources.

2 PROGRAM OBJECTIVES

The overarching goals of the SDTS contract are organized around four core program objectives.

These objectives form the pillars of the technical, scientific, and administrative support services to be delivered by the Contractor. Each objective represents a vital component of the GFDL and NOAA OCIO operational mission:

Objective 1: Adaptive Earth System Model Development To provide agile, high-performance software engineering and scientific programming capacity to support the development, optimization, containerization, and deployment of GFDL's component and coupled Earth system models (e.g., MOM6, AMx, SHiELD, SPEAR, CMx, ESMx, etc) and modeling infrastructure (FMS and FRE). The objective is to rapidly deliver prioritized, functional code increments that adapt to shifting scientific requirements without administrative friction.

Work is drawn dynamically from the Government's prioritized Master Portfolio Backlog to accelerate scientific discovery and research-to-application/operations (R2X) transitions.

Note on Embedded Support: While the iterative Agile process is anticipated for the majority of Objective 1, some scientific divisions at GFDL require dedicated, embedded Contractor model development and code maintenance staff. In these cases, the contractor shall provide firm-fixed-price for embedded support, scaling the number of embedded personnel as scientific needs evolve (currently estimated at four embedded contractor staff members).

Data Science, Diagnostics, and AI/ML Infrastructure Integration: Within the scope of Objective 1, the Contractor shall provide specialized software and data engineering support to champion shared data stewardship and modernization. The Contractor shall:

https://www.noaa.gov/organization/information-technology/n-wave

1. Develop Open Data Platforms & AI Workflows: Build and maintain scalable data platforms that leverage Agentic AI workflows, AI/ML user agents, and Retrieval-Augmented Generation (RAG) to accelerate model data discovery, optimize resource efficiency, and reduce turnaround time for data publishing.

2. Advance Diagnostic Frameworks: Foster research and multi-institutional alignment by developing data analysis frameworks for process-oriented and performance diagnostics, specifically leveraging and upgrading the Model Diagnostics Task Force (MDTF) framework.

3. Modernize Data Pipelines: Integrate cloud-native object storage with weather model data from the Unified Forecast System (UFS) and other modeling systems.

4. Ensure Code Health & CI/CD: Establish robust, automated CI/CD workflows and portable, self-documented code repositories that invite user contribution, maintain passing status across pipelines, and serve as core building blocks for agentic AI workflows.

Objective 2: Standardized & Secure, Endpoints, Highly Available Computer Operations, and Efficient Business Administration This consolidates all standard operational IT and management support. This includes user endpoint support (Linux/Windows), 24/7/365 remote and on-premise supercomputing and archival data storage systems operations (remote and local high-performance computing, Hierarchical Storage Management System, and wired and wireless networks and network switches, and other networking components) and help desk support, and administrative/mission-oriented support.

Included within this requirement is for the contractor to:

1. Deliver highly responsive, secure, and standardized system administration and technical support services, including still and animated scientific illustrations and graphical support services, for workstation (Linux), PC (Windows), and laptop (Windows and Linux) environments. Ensure all systems are rigorously patched, scanned, and compliant with federal security mandates on a continuous monthly cycle. Build and deploy new devices on an annual replacement cycle (accounting for approximately 20% of the 300-device inventory annually).

2. Ensure continuous, around the clock supercomputing operations, high-availability system administration, robust storage management, and responsive help desk support.

The objective is to minimize system downtime, proactively monitor infrastructure, and resolve end-user technical issues rapidly. This includes overseeing local post-processing Dell clusters, managing over half an EB of archiving capacity (and growing) on the Hierarchical Storage Management System (HSMS), coordinating with ORNL to support the Gaea supercomputer, and executing the secure, reliable transfer of up to 80 TB/day of scientific data.

3. Provide seamless, expert business administration, human resources, travel, and property services. This includes coordinating complex personnel security processing, facilitating Foreign National Visitor and Guest access, administering GSA/FTR-compliant travel, managing NOAA property with minimal variance.

Objective 3: HPC Support & Network Security To maintain a resilient, proactive cybersecurity defense posture across all R&DHPC networks for NOAA’s OCIO and GFDL, local computational clusters, and high-speed data conduits. This includes continuous security monitoring, aggressive vulnerability remediation within federally mandated timeframes, and strict compliance with Department of Commerce and NOAA IT security policies.

The contractor shall serve as the Information Technology Security Officer for NOAA’s Research and Development High Performance Computing System (R&DHPCS). As such, it shall establish and maintain a highly proactive, continuous threat monitoring and vulnerability defense posture for all NOAA and GFDL R&DHPC, network, and development environments. This includes a strong focus on security compliance, automated DevSecOps pipelines, FEDRAMP cloud authorizations, and rapid 1-hour critical incident reporting.

Objective 4: Facilities Management To execute a rigorous preventative operations and maintenance (O&M) program to seek to achieve zero unplanned downtime for the GFDL campus and HPC data center. Provide facilities consultation support for GFDL and other NOAA OCIO enterprise-wide R&DHPCS facilities, facilities project management, and ancillary repairs and alteration services.

3 OPERATING CONSTRAINTS AND METHODOLOGY

3.1 Task Order Execution Models

The Government is subject to dynamic project work and frequent urgent response requirements across all four objectives. The Contractor shall ensure sufficient operational capacity to respond to emerging demands, whether they be ad hoc or planned projects or responses to higher headquarters requirements. Historically, the combination of these consumes approximately 15% of total annual hours. Task orders under this IDIQ will be executed using two distinct models based on operational needs:

1. Objective 1 (Agile Development): The Contractor's proposed solution must accommodate a dynamic, capacity-based Agile development framework to manage shifting software prioritization (Sprint Capacity Model). For embedded Contractor staff within the science divisions, the Government will notify the Contractor annually of the required Labor Categories and full-time/part-time requirements.

2. Objectives 1 through 4 (Managed Services): For these operational objectives, the Government will issue task orders under a Managed Service model, requiring the Contractor to submit technical and price quotes guaranteeing service-level availability and continuous operations under a Managed Service model.

3.1.1 Decentralized Technical Decision-Making and "Guard Rails"

3.1.1.1 Team-Level Autonomy

To facilitate rapid software delivery and maintain momentum under Objective 1, the Contractor's cross-functional teams are granted the autonomy to make decentralized technical, architectural, and design-level decisions regarding how to implement prioritized user stories, provided those decisions fall within defined project guard rails.

3.1.1.2 Guard Rail Boundaries

The Contractor's autonomous decision-making boundaries for Objective 1 are restricted to efforts that:

1. Do not expand or alter the contract's baseline scope, overall Product Vision, or approved budget.

2. Do not compromise the strict modular design principles, Separation of Concerns (SoC), or HSD testing methodology of FMS, FRE and component and coupled models.

3. Strictly comply with all federally mandated cybersecurity controls and DOC/NOAA IT security policies.

Any technical decision or priority change falling outside of these boundaries requires the explicit, written direction of the Government Product Owner, COR, or Contracting Officer.

3.2 Key Contractor Requirements for Objective 1 (Model

Development) In supporting Objective 1, the Contractor shall operate under an Agile-Teams-as-a-Service model to support the complex and dynamic software requirements of the Modeling Systems Division (MSD). The Government retains authoritative Product Owner (PO) status, managing a single Master Portfolio Backlog. The contractor delivers cross-functional development capacity through a series of Firm-Fixed-Price (FFP) sprint blocks, preventing slow contract modification cycles. The contractor shall adhere to modern software engineering constraints and collaborative methodologies:

1. Agile Methodology: The Contractor shall actively incorporate Agile DevSecOps methodologies and ceremonies into the workflow, including sprint planning, daily scrums, sprint reviews, sprint retrospectives, backlog estimation, and prioritization activities.

2. Iterative Release Cycle: The Contractor shall develop, test, stage, and release scientific software and business applications using iterative processes and a frequent, reliable release cycle.

3. User-Centered Design: The Contractor shall actively involve scientific users in the design of software solutions, incorporating user research and usability testing (personas, wireframes, prototypes).

4. DevSecOps & Automated Testing: The Contractor shall utilize Development, Security, and Operations (DevSecOps) techniques, including Continuous Integration and Continuous Deployment (CI/CD), across all environments (development, staging, production). The Contractor shall deploy automated frameworks to create unit, integration, and functional tests for 100% of delivered functionality, striving for Test-Driven Development (TDD) compliance.

5. Security Integration: The Contractor shall ensure all configurations, credentials, and sensitive API keys are strictly excluded from source code and stored exclusively in encrypted federal credential management systems.

3.2.1 Joint Alignment on "Ready" and "Done" Standards

3.2.1.1 Definition of Ready (DoR)

Prior to commencing work on any user story during a sprint, the Contractor and the Government Product Owner shall establish a mutual "Definition of Ready." No user story shall enter a development sprint unless it contains detailed acceptance criteria, maps directly to a parent Epic, and has been relatively sized by the engineering team. At a minimum, a user story is only "Ready" for development once it contains clear acceptance criteria, has been relatively sized by the development team, and is prioritized at the top of the backlog.

3.2.1.2 Definition of Done (DoD)

The Contractor must propose a comprehensive, highly rigorous "Definition of Done" that will serve as the validation gateway for all delivered user stories and sprint increments. No user story shall be accepted or invoiced until it satisfies 100% of the DoD, which must contractually mandate:

1. Complete integration into the main branch with zero regression errors in the CI/CD pipeline.

2. Successful automated unit and regression testing achieving agreed-upon coverage thresholds.

3. Generation of automated, clean developer and user documentation (including API/ReadTheDocs updates).

4. Peer-reviewed, refactored code that strictly adheres to the Separations of Concerns (SoC) design principle and NOAA security directives.

3.2.1.3 Sprint Reviews & Technical Demonstrations

The Contractor shall prioritize the delivery of functional code over static presentation materials.

At the beginning of the performance period, the Contractor shall provide a plan of how sprints will be ended and the review methodology. The Contractor and COR shall agree upon a final methodology to complete the review of the sprint and satisfy the DoD requirement.At the conclusion of each iteration, the Contractor shall demonstrate working software to the Government Product Owner, MSD leads, and key scientific stakeholders. These sessions serve as the primary mechanism for eliciting immediate feedback, validating that user stories satisfy acceptance criteria, and confirming the increment fulfills 100% of the "Definition of Done."

3.3 Technical Debt Control

To prevent software degradation, the contractor must continuously monitor, estimate, and report on the accumulation of ‘Technical Debt’ utilizing automated tools integrated into the CI/CD pipelines. The contractor must allocate a minimum of fifteen percent (15%) of one FTE within the sprint team exclusively to refactoring, code cleanup, dependency remediation, and codebase optimization to ensure long-term model portability and performance.

3.4 Portfolio Backlog & Capacity-Based Scope (Objective 1)

Instead of rigidly defined deliverables for each application, the Government will manage a centralized Master Portfolio Backlog encompassing all development requirements across various models and infrastructure (e.g., FMS, FRE, ESM, MOM6, CMxm SHiELD, SPEAR, etc, and CMIP support).

1. Agile Teams as a Service: The Government is procuring the capacity of cross-functional Agile teams to perform continuous application development, software optimization, and scientific programming.

2. Dynamic Shifting of Effort: The Government Product Owner retains sole authority to prioritize the backlog. The Contractor shall draw work exclusively from the top of the prioritized backlog during Sprint Planning. This enables the Government to pivot development focus between different modeling codes sprint-to-sprint without requiring formal contract modifications.

3.4.1 Shared Agile Application Lifecycle Management Environment and Traceability Guard Rails

To ensure 100% data transparency, both the Contractor and Government team members shall utilize the same shared, Government-furnished Application Lifecycle Management (ALM) tool (e.g., GitHub Projects, Jira, ServiceDesk). The Contractor shall ensure bi-directional traceability is maintained at all times within the tool, mapping every discrete developer task and user story directly back to its parent Epic, Release, and high-level GFDL Strategic Program Theme. Verbal confirmations of feature completion are strictly prohibited for reporting purposes; all progress must be verified via the shared ALM tool's objective data logs.

3.5 Performance Measurement, Metrics, and Quality Control

(Objective 1)

3.5.1 Decoupling of Velocity from Contractor Performance

The Contractor and Government acknowledge that Velocity (the rate at which a team delivers story points) is a highly team-specific, variable metric to be utilized solely for internal capacity planning and sprint-to-sprint sizing. Velocity is not comparable between different teams, and the Contractor's performance shall not be graded on velocity trends, thereby avoiding the risk of story-point inflation. Bids will be evaluated solely on the realistic capacity, labor mix, and cost-efficiency of the cross-functional team delivered per sprint CLIN.

3.5.2 Contract Accountability Metrics

Contractor performance under Objective 1 will be measured utilizing the following objective, tool-derived metrics:

1. Lead Time / Cycle Time: Measuring the duration from backlog entry/sprint activation to successful production deployment, assessing how rapidly user needs are met.

2. Defect Escape Rate: Tracking the volume of bugs or configuration errors that bypass automated testing and are discovered post-release.

3. Say/Do Ratio: Evaluating the percentage of story points committed to during Sprint Planning that successfully meet the "Definition of Done" by the end of the sprint iteration.

4. Technical Debt Accumulation: The Contractor shall continuously monitor and report on the accumulation of "Technical Debt" (unresolved architectural shortcutting, legacy code dependencies, and deferred refactoring). The Contractor shall proactively allocate a portion of each sprint's capacity to technical debt remediation to ensure the modeling codebases remain highly performant, portable, and clean.

3.6 CLIN Structure for the IDIQ Suite

The solicitation pricing and invoicing are aligned across seven contract line items (CLINs) as detailed in the master rate table:

Bidders are to apply a fixed 3.0% maximum annual escalation to option-year rates.

Evaluate the FAR 52.217-8 six-month option by halving the final year's total.

PWS CLIN Number and Name

Objective Alignment Pricing & Execution Model

OBJECTIVE 1 CLIN 0001:

Baseline Dev Sprint

Objective 1: Model Development - Provides 1 cross-functional team for 1 sprint drawing exclusively from the prioritized Portfolio Backlog. Govt. to define standard cross-functional team composition (Government-fixed team size/labor mix so offers are comparable)

Firm-Fixed-Price per 4-Week Sprint Block

OBJECTIVE 1 CLIN 0002:

Surge Dev Sprint

Objective 1: Model Development - Optional capacity to scale up additional Agile teams for targeted, urgent scientific modeling efforts. Executed in 2-week increments as needed.

Firm-Fixed-Price per 2-Week Sprint (On-Demand)

OBJECTIVE 1 CLIN 0003:

Embedded Support

Objective 1: Scientific Modeling Support - Provides dedicated Contractor technical staff embedded within GFDL scientific divisions during regular business hours (currently estimated at 4 FTEs).

Firm-Fixed-Price for 1,880 Hours per FTE (On-Demand)

OBJECTIVE 1 CLIN 0004:

Managed Services Projects

Objective 1: Scientific Software Stack Lifecycle Management

Firm-Fixed-Price Managed Services

SLA

OBJECTIVE 2 CLIN 0001:

Standard IT Operations, Sys Admin, and Business Admin

Objective 1&2: Endpoint, HPC Ops, & Business Admin

Firm-Fixed-Price Monthly Managed Services SLA

PWS CLIN Number and Name

Objective Alignment Pricing & Execution Model

OBJECTIVE 3 CLIN 0001:

HPC Support & Network Security

Objective 3: HPC Support & Network Security, NOAA R&DHPCS IT Security Officer

Firm-Fixed-Price Monthly Managed Services SLA

OBJECTIVE 4 CLIN 0001:

Facilities Routine O&M

Objective 4: Data Center & Facilities O&M

Firm-Fixed-Price Monthly Managed Services SLA

OBJECTIVE 4 CLIN 0002:

Facilities Routine O&M Sub-contracted work

Generator Fuel Polishing, Diesel Fuel, Pest Control, and Boiler Maintenance

Firm-Fixed-Price

OBJECTIVE 4 CLIN 0003:

Facilities Routine O&M Direct Purchases

Maintenance Supplies and Services Allowance

Firm-Fixed-Price

OBJECTIVE 4 CLIN 0004:

Ancillary Repair and Alteration Projects

Objective 4: On-Demand Facilities Construction

Time & Materials (T&M) or FFP per Project Work Order

4 GENERAL REQUIREMENTS

4.1 Contract Administration and Management

The Contractor retains complete responsibility for organizing, equipping, supervising, and directing a workforce that is capable of executing each PWS and all of its requirements. The Contractor shall establish clear organizational lines of authority and rigorous management controls to ensure effective oversight, accountability, and optimal resource utilization.

4.1.1 On-Site Supervision

An on-site supervisor must be present at the government facility on Federal government work-days, i.e., non-holiday or closure Monday through Friday, during standard operating hours to oversee contractor staff. This requirement may be satisfied by the designated Program Manager.

4.1.2 Workforce Qualifications & Optimization

The Contractor shall deploy qualified personnel who possess the requisite education, training, certification(s), and experience specified for each Labor Category. The Contractor shall optimize skill-matching to ensure efficient task execution—avoiding under- or over-utilization of resources—while maintaining the operational agility needed to accommodate urgent or unanticipated requirements. Applied labor categories, rates, and hours shall represent the minimum necessary to achieve complete task execution.

4.1.3 Talent Acquisition, Retention, and Continuity:

1. Recruitment Strategy: The Contractor shall execute a robust, multi-channel in-person and on-line recruitment strategy leveraging academic and professional networks, career fairs, and other means, to consistently attract top-tier scientific and engineering talent.

2. Retention & Continuity: The Contractor shall implement effective retention practices (competitive compensation, inclusive of both pay and benefits, as well as mentoring and professional development) to minimize turnover and maintain uninterrupted service performance.

4.2 Hours of Operation and Work Schedules

4.2.1 Standard Operating Hours

Standard Government operational hours are 0730 to 1800, Monday through Friday, excluding official federal holidays. Unless assigned to approved shift work or special projects, Contractor personnel shall maintain normal business hours consisting of eight (8) hours per day, Monday through Friday, encompassing core operating hours from 1000 to 1600.

4.2.2 Continuous Operations (24x7) & Special Projects

Certain functional areas—such as Computer Operations and Facilities support—require around-the-clock continuous coverage every day of the year. Specific coverage requirements will be defined in individual Task Order PWSs.

1. Shift Hand-Off: For continuous operations functions, shift personnel must remain on duty until formally relieved by the incoming shift.

4.2.3 Schedule Deviations & Interruptions

Any deviation from established work hours—including substituting holiday or weekend hours for normal business days—requires prior written approval from the Contracting Officer's

Representative (COR). Interruption of critical services must be minimized; non-emergency operational interruptions require advance COR approval.

1. Advance Notice Requirement: The Contractor shall submit schedule deviation requests to the COR at least five (5) business days prior to the proposed shift, detailing the specific operational need.

2. COR Decision & Authority: The COR will review all deviation requests and render a written decision in a timely manner without unreasonable delay. The COR maintains final authority to direct or mandate specific working hours on a case-by-case basis to support Government mission requirements.

4.3 Place of Performance, Telework, and Remote Work

4.3.1 Place of Performance

The primary place of performance is the Geophysical Fluid Dynamics Laboratory (GFDL) in Princeton, New Jersey, or other designated NOAA facilities.

4.3.2 Site-Specific Labor Rates

Labor rates apply based on the authorized work site:

1. Government Site or Home-Based / Remote Work: On-site labor rates apply.

2. Contractor Site: Off-site labor rates apply.

4.3.3 Telework Policy

Telework is an administrative privilege, not an entitlement. In certain requirements or circumstances, telework may be considered and or approved. However, operational necessity, performance, and conduct take precedence and may result in denial of telework requests and or the suspension or revocation of telework on an individual or group basis.

All contractor personnel shall perform duties on-site at the GFDL facility in Princeton, New Jersey. Except for fully-remote staff across all of the objectives, telework for positions in Objective 1 require on-site presence for three (3) work-days per week, allowing for telework for the remaining work-days of each week. In Objectives 2-4 telework may be approved up to one

(1) day per week. Reasonable exceptions may be considered upon request of the Contractor Program Manager. In all cases, telework requires prior PM approval recommendation and COR approval.

1. Telework Plan Requirement: Before telework commences, the Contractor shall submit a detailed Telework Plan to the COR and appropriate Lab/Office Point of Contact for written approval, outlining specific tasks and performance expectations.

4.3.4 Work Site Transitions

Any proposal to transition on-site tasks to off-site locations requires a formal impact mitigation plan submitted to and approved in writing by the COR prior to transition. The plan must detail deliverable impacts, collaboration tools, progress monitoring, and meeting attendance protocols.

4.3.5 Security Boundaries

All remote access and telework must be conducted strictly from within the geographic boundaries of the United States and in compliance with Department of Commerce and NOAA IT Security Policy and Commerce Interim Technical Requirements (CITR) 0008.

4.4 Facility Closures and Emergency Operations

4.4.1 Recognized Holidays

The Government observes official Federal holidays as well as any other day designated by Federal Statute, Executive Order, or Presidential Proclamation. Except for designated 24x7 continuous operations staff, Contractor personnel shall not perform work on federal holidays or during Government dismissals unless specifically requested by the Contractor Program Manager and approved by the COR.

4.4.2 Unforeseen Facility Closures & Dismissals

During emergency dismissals, inclement weather, loss of power, or early holiday dismissals, Contractor personnel with pre-approved telework agreements and proper equipment may continue working remotely.

4.4.3 Extended Closures & Compensation

1. Observance of official holidays or closure of Government facilities shall not entitle the Contractor to additional periods of performance or extra compensation except as explicitly set forth in the contract.

2. If a catastrophic event closes Government facilities for more than two (2) consecutive workdays, costs and payment for idle time shall be separately negotiated with the Contracting Officer (CO). If an unplanned closure impacts price or schedule, the Contractor must formally notify the CO and submit a claim for equitable adjustment.

3. Nothing in this subsection abrogates the rights and responsibilities of either party regarding "Stop Work" provisions cited elsewhere in this contract.

4.5 Government Furnished Resources

4.5.1 Facilities and Utilities

For Contractor personnel performing work on-site at a Government facility, the Government…