STE VSW Call for Solutions Amend 002.pdf

Call for Solution

Synthetic Training Environment (STE) Virtual Software (VSW)

18 September 2026 Amendment 002

Project Number STE-VSW-26-0006 Army Open Solicitation (AOS) Number W9128Z-25-S-A002 Call for Solution Title Synthetic Training Environment (STE)

Virtual Software (VSW) Issued By Army Contracting Command - Aberdeen Proving

Grounds (ACC-APG) Orlando Division

Submission Instructions To respond to this Call for Solution, please refer to Sections 6 of this Call for Solution

*Solutions Due Date/Time (Suspense)

Monday, 29 Sep 2026 at 1300 Eastern Daylight Time (EDT)

Point of Contracts (POCs) for Solution Brief Submission

Contracting/Agreements Officer: MARK A. MUÑIZ;

mark.a.muniz6.civ@army.mil Contracting/Agreements Officer: DAVE HAGLER;

david.a.hagler.civ@army.mil Contracting/Agreements Officer: SEAN J. JOHNSON;

sean.j.johnson2.civ@army.mil Contracting/Agreements Specialist: RUTH TORRES;

ruth.e.torres10.civ@army.mil Contracting/Agreements Specialist:

KIMBERLY SKINNER Skinner;

kimberly.c.skinner.civ@army.mil

NOTE: Please advise the cognizant Contracting/Agreements Officer and Specialist as soon as possible via the emails above if your organization intends to submit a Solution in response to this Call for Solution. Please complete the Forms at the following link referenced in Description section of the sam.gov posting or at:

https://forms.osi.apps.mil/r/n5qzG3ZZEY

*Any submissions that are received by the Contracting/Agreements Officer after the suspense date/time listed above will be deemed late and not evaluated. It is the sole responsibility of the company to ensure that its submission is received in the email inboxes listed above before the deadline specified.

mailto:mark.a.muniz6.civ@army.mil mailto:david.a.hagler.civ@army.mil mailto:sean.j.johnson2.civ@army.mil mailto:ruth.e.torres10.civ@army.mil mailto:kimberly.c.skinner.civ@army.mil https://forms.osi.apps.mil/r/n5qzG3ZZEY

This Call for Solution is issued under the authority of Defense Federal Acquisition Regulation Supplement (DFARS) 212.70 – Defense Commercial Solutions Opening and may result in the Government awarding Federal Acquisition Regulation (FAR) contracts or non-FAR agreements. Other Transactions (OT) that may be awarded from this Call for Solution are not subject to the FAR or its supplements, as applicable.

The purpose of this Amendment 0001 is to formally amend the STE VSW Call for Solutions (CFS) dated 15 September 2026 to clarify the operational allocation, facility responsibilities, physical boundaries, and infrastructure scope for the Software Integration Laboratory (SIL).

Specifically, this amendment clarifies that the Lot 5 (Enterprise Integration Support) awardee is solely responsible for acquiring, provisioning, accrediting, securing, and maintaining the brick-and-mortar physical laboratory facility and dedicated enterprise network infrastructure in Orlando, Florida. While the Government furnishes the Reconfigurable Virtual Collective Trainer (RVCT) crew station cockpits and associated computing equipment as Government Furnished Equipment (GFE), the Government will not provide the physical real estate, building envelope, environmental controls, or external network telecommunications infrastructure.

All offerors must formally acknowledge receipt of this Amendment 0001 in their Volume I Transmittal Letter / Master Compliance Matrix.

1. BACKGROUND.

The Synthetic Training Environment (STE) is modernizing how the Army conducts immersive virtual training to match the pace of a rapidly evolving operational environment. While the current Reconfigurable Virtual Collective Trainer (RVCT) software baseline, Training and Simulation Software (TSS), continues to provide critical training value to the force, it currently has capability gaps that must be filled on an accelerated timeline. To meet the demands of the modern operational environment, the STE Virtual Software (VSW) solution must deliver five core operational priority capability deliverables outcomes. These Core Operational Priority Deliverables are the primary near-term focus of this effort:

1. A Doctrinal Gate to Live Fire: A Certifiable Table II virtual collective training capability, as defined in the TC 3-20.0 Integrated Weapons Training Strategy (IWTS), that serves as a formal gate to live-fire training for mounted maneuver units at the section through company level. Capability must be capable of accurately simulating the necessary platform behaviors and weapons effects to include fire control systems, ballistics, and pH/pK, that enable realistic training.

2. TC 3-04.3 Table VII & Table X Collective Gunnery Gate for Air: Simulating crew coordination, pilot/co-pilot gunner (CPG) handoffs, sensor-to-shooter acquisition, target handovers, and weapon engagement physics (Hellfire, 2.75" Hydra 70 / APKWS, 30mm AWS, M230/M240 door gunnery) for AH-64E, UH-60M/V, and CH-47F.

3. A True Combined Arms Environment: The seamless integration of the full spectrum of direct and indirect fires and effects, to include Bradley Fire Support Team (BFIST), and terrain shaping to allow for realistic, combined arms training.

4. Full Mission Command Concurrency: The integration of the most current Mounted Mission Command (MMC) and other Mission Command Information System (MCIS) being used by operational units.

5. Open system architecture with published Software Development Kit (SDKs) and Application Programming Interfaces (APIs) to enable user manipulation and rapid integration of future capabilities.

2. PROBLEM STATEMENT

The Army is seeking solutions that deliver on the five operational outcomes. Offerors may submit any solution – whether a new Commercial Off the Shelf (COTS), a significant modification of the provided Government Off the Shelf (GOTS) baseline, or a hybrid approach – that they believe best meets the Government’s objectives. The Government requires solutions that deliver the user community’s desired attributes and can open the software to third-party integration.

To execute the Government-as-Integrator model, the STE Virtual Software solution is divided into five (5) distinct capability Lots. The architecture relies on a “Platform and Application” model, where Lot 1 provides the foundational software platform and Lot 2 provides the specialized applications that run on it. Lots 3 and 4 provide the critical human interface and data analysis layers, while Lot 5 provides the overarching integration and governance. Offerors may submit solutions for one or multiple Lots (subject to Lot 5 Organizational Conflict of Interest (OCI) restrictions). Each Lot will be evaluated independently to ensure the Army acquires the most advantageous commercial technology for each specific function. The following provide scope and requirements for each Lot.

Lot 1: Common Core Software (CCS)

• Scope: The Lot 1 awardee will be granted access to the TSS Government Furnished Information (GFI) source code and is responsible for enhancing, simplifying, and opening the core software architecture for third-party integration. This architecture includes the simulation and rendering engines.

• Scalability Requirement: The Lot 1 Common Core Software must execute at a minimum of 60Hz tickrate (simulation) and 90Hz frame rate (rendering) with under 20ms of end-to-end latency, while supporting a minimum threshold of 50,000 active entities.

• Extensibility: The Lot 1 CCS must provide fully documented, open SDKs and APIs that allow third-party modules (from Lot 2) to seamlessly “dock” into the environment and utilize the data fabric.

• Mandate for Open Ecosystem and Fair Competition: The Lot 1 CCS provider is the steward of the STE Virtual Software application ecosystem. While the Lot 1 provider is encouraged to develop its own native Lot 2 applications, they are contractually obligated to maintain a "level playing field." The Lot 1 provider shall not implement any architectural, API-based, or performance-related features in their native Lot 2 applications that are not also made available to third-party Lot 2 developers via the common, Government-approved SDK. The Lot 5 Conformance Test Suite will be used to verify that the platform provides fair and equal access to all application developers.

• User Scripting Environment: The Government requires the capability for the Lot 1 CCS to provide a high-level scripting environment accessible to non-developers. This environment must allow users to create custom entity behaviors, trigger complex scenario events, and modify simulation parameters without requiring access to the core source code or a professional software development integrated development environment (IDE). If a submitted solution does not have a user scripting environment at the time of award, the offeror must provide a detailed technical roadmap for delivering this capability in a future, near-term software release.

Lot 2: Simulation Application Software (SAS)

• Scope: Provide specialized software modules, or “plug-in” applications that execute within the modernized Lot 1 environment via the new Government-approved SDK. This is where the Government seeks to leverage the diverse capabilities of industry. This is a software-only lot, and there is no limit to how many specialized software modules an offeror can offer for this Lot.

• Future Expansion and “App Store” Model: The Government views Lot 2 as a continuous, expanding capability bucket that forms a competitive “app marketplace.” The eventual Lot 1 architecture will support the rapid, competitive integration of third-party Lot 2 applications to prevent end-to-end vendor development lock on future capability development. The Government may execute subsequent, competitive awards for new Lot 2 applications (e.g., future vehicle platforms, s-UAS modules, Table II Precision Gunnery trainers) at any time. The solicitation for this lot will remain open for the life of the project.

• Requirement: All Lot 2 applications, regardless of the vendor, must be developed using the common, Government-approved SDK provided by the Lot 1 platform and governed by the Lot 5 integration partner. They must pass the Lot 5 Conformance Test Suite prior to acceptance.

Lot 3: Hardware-in-the-Loop (HIL) Integration and Test

• Scope: The Lot 3 awardee shall serve as the specialized engineering partner for hardware-to-software integration. The primary responsibility of this Lot is to ensure the high-fidelity, real-time integration of the Lot 1 Core Simulation Engine with the GFE RVCT physical hardware utilizing the Government-provided Hardware API (HAPI) or equivalent Hardware Abstraction Layer (HAL) for mapping physical GFE RVCT inputs to the HAPI standard.

Lot 4: Training Management & AAR Data Layer

• Scope: Provide the suite for instructors to Plan, Prepare, Execute, and Assess (PPEA) training. Must ingest real-time event data from the system message bus to generate objective, automated After-Action Reviews (AAR) and human performance analytics.

Lot 5: Enterprise Integration Support (Independent Team)

• Scope: Serve as the Government's technical execution agent. The Lot 5 awardee is responsible for providing, operating, and maintaining a contractor-provided, secure physical Software Integration Laboratory (SIL) facility located within five

(5) miles of the Central Florida Research Park / Team Orlando modeling and simulation precinct. The Lot 5 vendor is responsible for delivering the complete physical facility envelope, including physical access controls conforming to DoDM 5200.01 CUI standards, industrial three-phase clean power, redundant HVAC capacity to support high-density simulation computing and multiple hardware-in-the-loop (HIL) vehicle cabs, the internal simulation and development networks within the facility capable of supporting a DoD Impact Level 4/5 (IL4/IL5) DevSecOps posture. The Lot 5 vendor will strive to leverage the Government’s investment in the UnITE IDE/DevSecOps environment to facilitate operations and management of the STE Virtual Software to support the Government’s role as the Lead Systems Integrator and is responsible for managing the TSS source code repository, administering the modernized SDK, and operating the Conformance Test Suite to validate all modifications and integrations. The Government retains sole, non-delegable authority over all system configurations, architectural decisions, interface approvals, and final vendor compliance certifications. While the Government will deliver the physical RVCT platforms and computing rigs as Government Furnished Equipment (GFE), the Government will not provide physical facility space or internal laboratory network infrastructure.

• Key Responsibilities:

• Infrastructure Management: Acquire, accredit, and manage the contractor-provided Orlando SIL facility, and deploy and manage the Government-owned DevSecOps CI/CD pipeline, the enterprise API gateways/message bus, RVCT GFE, and physical lab computing racks under the direct supervision of the Government Program Office. The facility must also include a conference room and a minimum of 5 office spaces available for the Government or Lot 1-4 contractors. Office spaces are for temporary use in support of lab activities.

• API and SDK Administration: Serve as the technical custodian and configuration manager for the system’s common APIs and SDKs. Lot 5 will maintain the technical documentation and distribute the Government-approved SDKs to Lot 2 and Lot 4 developers, subject to final Government approval of all baseline changes.

• Independent Conformance Testing: Operate the automated Conformance Test Suite (CTS) to evaluate software compliance. Lot 5 will generate objective, data-driven test reports for the Government, which the Government will use as the sole basis for final acceptance and certification of all Lot 1–4 components.

• OCI Firewall: Strict Structural OCI Exclusion for Lot 5: To ensure complete objectivity in operating the Software Integration Lab (SIL) and executing the Conformance Test Suite (CTS), an organization (including its parent company, subsidiaries, corporate business units, and corporate affiliates) will not be awarded or permitted to perform on Lot 5 (Enterprise Integration Support) if that organization or any of its affiliates is awarded or performing work on Lot 1 (Common Core), Lot 2 (Simulation Apps), or Lot 4 (Training Management & AAR Data Layer). Firewall-only OCI mitigation plans between corporate affiliates will not be accepted for Lot 5.

• Competing Across Lots: Companies and corporate affiliates are permitted to submit proposals and compete for both Lot 5 and software development lots (Lots 1, 2, or 4) during Phase 1 and Phase 2.

• Award Selection & Election Protocol: In the event an offeror (or its corporate family) is evaluated as the highest-rated / selected vendor for both Lot 5 and one or more software lots (Lots 1, 2, or 4), the Government will issue a formal notification requiring the offeror to elect which Lot award it will accept. The remaining unselected Lot will be awarded to the next highest-rated, unconflicted offeror.

Demarcation of Responsibilities To prevent overlap and ensure absolute accountability within the Government-as-Integrator model, the technical boundaries between all STE Virtual Lots are strictly defined as follows. The Government retains sole, non-delegable authority over all architectural decisions, interface approvals, and final compliance of certifications.

• Lot 5 Boundary (The Government’s Technical Agent): The Lot 5 contractor is responsible for the physical laboratory facility shell, environmental utilities, physical access security, server rack infrastructure, and the internal simulation and development networks within the facility. Lot 5 acts as physical custodian for the SIL: receiving, uncrating, rigging, physically placing, powering, and safeguarding all delivered GFE RVCT hardware units and computing rigs. Lot 5 owns the 'digital motherboard' (API Gateway, Message Bus, and HAPI standard) on behalf of, and under the direct authority of, the Government, and provides secure, non-discriminatory physical and logical access to all authorized ecosystem performers. Lot 5's technical responsibility is limited to physical lab management, transport, validation, and translation of data payloads between Lots, and objective compliance testing via the Conformance Test Suite (CTS). Lot 5 does not possess autonomous decision-making authority regarding system acceptance, baseline changes, or vendor compliance.

• Lot 1 Boundary (The Platform Owner): The Lot 1 contractor is responsible for the "virtual world operating system." Lot 1's responsibility is to provide the core simulation engine, data fabric, and rendering pipeline. Crucially, the Lot 1 vendor must also provide and document the open SDK and APIs that allow third-party Lot 2 "applications" to run on the platform. Lot 1 shall have no direct software dependency on, or communication with, the physical RVCT hardware.

• Lot 2 Boundary (The Application Developers): The Lot 2 contractors are responsible for the "specialized applications." A Lot 2 vendor's responsibility begins at the ingestion of data from the Lot 1 data fabric/SDK and stops at the generation of high-fidelity, platform-specific outputs (e.g., accurate flight physics for a s-UAS, doctrinally correct behaviors for a CGF entity). Lot 2 applications must operate entirely within the framework provided by Lot 1 and the governance of Lot 5.

• Lot 3 Boundary (The HIL Integration Specialist): The Lot 3 contractor serves strictly as the technical Hardware-in-the-Loop (HIL) integration specialist within the Lot 5-provided Orlando SIL. Lot 3's responsibility is focused purely on connecting to, configuring, calibrating, and instrumenting the pre-staged GFE RVCT crew stations and converting physical control inputs/outputs into compliant HAPI data packets delivered to the Lot 5 API Gateway. Lot 3 shall not modify Lot 1 core simulation physics or Lot 2 application software.

• Lot 4 Boundary (The AAR and Data Analytics Provider): The Lot 4 contractor Is responsible for the "data analysis." Lot 4's responsibility starts at the ingestion of validated event data from the system message bus and stops at the rendering of objective AARs and performance dashboards. Lot 4 shall not modify the core simulation or control any runtime components.

3. REQUIRED SOLUTION ATTRIBUTES.

The Government is funding an integration effort of mature technologies. To achieve rapid fielding and eliminate vendor lock-in, all submitted solutions must adhere to the following required attributes.

• COTS/GOTS/Hybrid Approaches: The Government will make available the technical baseline for the current TSS software as GFI. This GFI is available to all offerors to serve as a common performance baseline and to enable them to submit the most innovative and efficient solution possible. Offerors are not required to use the GFI in their submitted solution, but they must be prepared to justify their approach (whether GOTS-based, COTS-based, or Hybrid).

• Technological Maturity (Technical Readiness Level (TRL) 8/9): The Government will only accept mature, fielded products that meet the baseline requirements of their respective Lot at the time of solution submission. Submitted solutions requiring software development, major re-architecting, or any effort beyond minor configuration and integration to meet the baseline capabilities of a lot will be considered non-compliant.

Offerors for Lots 1, must possess a fully developed, documented SDK and/or APIs at the time of solution submission.

• Modular Open Systems Approach (MOSA) and Interoperability Interface Standards: To achieve a true plug-and-play ecosystem, all components (Lots 1, 3, and

4) must expose their capabilities and data externally utilizing standard, well-documented, and widely accepted industry protocols. At a minimum, core simulation state data must be shared externally via standardized HLA (IEEE 1516), DIS (IEEE 1278.1), modern web services (REST/gRPC), or similar. While vendors may utilize proprietary, legacy, or Government-owned data fabrics internally within their own component(s), they must provide fully documented, open API wrappers to translate that internal data into standard interfaces at the Lot boundary. Proprietary, closed-loop point-to-point integrations with components that cross Lot boundaries and prevent third-party modular replacement are strictly prohibited.

• Rapid Integration of Emerging Capabilities: The overarching goal of this acquisition is agility. The proposed software architecture must eliminate the need for long-lead vendor support for routine capability updates. The ecosystem must allow the Government (via the Lot 5 integration partner) to rapidly plug in new 3rd-party technologies, AI models, and capabilities in a matter of days and weeks, not months or years. This will position the government to leverage common software to support future/emerging requirements such as embedded training and new vehicle platforms.

• One World Terrain (OWT) Integration: The proposed solution must natively ingest and render OWT data formats. This is a critical, non-negotiable requirement for all components incorporating a terrain or 3D rendering engine. The Government provides sample OWT datasets as part of the TSS GFI baseline for verification.

• RVCT Hardware Compatibility: The software ecosystem must be capable of integrating with existing RVCT physical peripherals through an open hardware abstraction layer.

• Cybersecurity and Rapid Accreditation: The STE Virtual ecosystem will be built on a "secure by design" foundation. The Government will prioritize solutions that can accelerate the RMF Open Network Authority to Operate (ATO) timeline by leveraging existing FedRAMP authorizations (for cloud components) and demonstrating a clear path to security control inheritance within the Government-managed DevSecOps pipeline provided by Lot 5.

• Program Protection, Releasability, and Data Sanitization: The STE Virtual ecosystem must structurally support multinational and coalition training environments.

Submitted solutions must align with Program Protection Plan (PPP) best practices and support Foreign Disclosure Office (FDO) releasability requirements. Specifically, the software architecture must decouple core executable code from sensitive platform data.

The solution must provide a streamlined, verifiable mechanism for administrators to rapidly segregate, manipulate, mask, or entirely remove sensitive data, Controlled Unclassified Information (CUI), or classified performance parameters to allow the system to operate safely in unclassified or coalition (e.g., FVEY) environments.

• Modern AI-Assisted Software Development: The Government expects offerors to utilize modern, efficient software development practices. The use of AI-assisted tools for code generation, automated testing, and DevSecOps pipeline acceleration is expected.

Offerors should be prepared to describe their approach to these modern practices.

• Virtual Training Operational Requirements:

o Doctrinal Foundation: The STE Virtual Software solution shall enable realistic, rigorous, and scalable training focused on the collective tasks and battle drills required to defeat near-peer threats, as defined in TC 3-20.0 (Integrated Weapons Training Strategy) and detailed in Attachment A v1_STE Virtual Software Training Requirements Overview (Air). The system must facilitate mastery of crew coordination, synchronized maneuver, and collective fire control, moving beyond isolated individual skills to unit-level execution. It must empower commanders to assess, build, and sustain combat readiness at the crew, section, platoon, and company levels through repeatable, standards-based collective scenarios.

o Gate to Live Fire (Ground): The system must function as the primary "gating" event (Table II equivalent) for mounted maneuver sections through companies before they proceed to live-fire qualification.

o Adaptable Operating System: The STE Virtual Software solution shall be delivered as an adaptable and composable software operating system that executes collective training and combat drills seamlessly across both physical simulator devices (e.g. RVCT) and active combat platforms (i.e., as an Embedded Trainer) o Aviation Collective Gunnery and Flight Operations: To ensure the system fully supports the air domain, it must provide the following capabilities:

High-Fidelity Flight and Weapons Modeling: The system must deliver high-fidelity flight modeling for AH-64, UH-60, CH-47, and Gray Eagle platforms, accurately simulating aircraft dynamics, systems (weapons, engines, fuel, etc.) and ballistics. Weapons shall simulate all current types and munitions (Hellfire, Rockets, 30mm, M240).

Aviation Gunnery Gate (Air): The solution must serve as a certifiable gate to live fire for aviation crews by supporting advanced gunnery tables, including Table VII and Table X as defined in TC 3-04.3, stressing crew coordination, sensor-to-shooter drills, and target handovers.

Foundational Mission Command: The software must simulate aircraft specific current Operational Flight Program (OFP), digital communications (BFT, Link 16, Longbow Net) and mission command systems. It must also integrate with AMPS for mission planning to be accomplished on standalone AMPS machines.

• External Ecosystem and Interoperability Requirements:

o Live, Virtual, and Constructive (LVC) (LVC Interoperability): The virtual software component of the STE must be interoperable with the broader Army LVC ecosystem. It shall be capable of operating effectively in distributed exercises, sharing data and entity states with both Army Live training systems (e.g., CTC-IS) and Constructive simulations (e.g., Next Generation Constructive

– NGC).

o Digital Training Record: The STE Virtual Software solution must capture and share training data with Army enterprise systems in a digital and persistent fashion. All training records, performance assessments, and gate to live fire qualifications generated within the system must be exportable in a standard format for ingestion by the Army’s system of record.

4. AWARDING INSTRUMENT

The Call will be awarded in accordance with the Army Open Solicitation procedures detailed within Solicitation W9128Z-25-S-A002, found here:

https://sam.gov/opp/860e295fdae04aab9d83810aa4a01531/view

This Call provides instructions to vendors and how the Government will evaluate submissions.

The Government anticipates awarding multiple CSO FAR based contracts and/or OTA agreements under this Call for Solutions.

5. CALL INSTRUCTIONS AND NOTES

The Government requires rapid and accountable integration of all products.

• Automated Conformance Testing: The Lot 5 vendor will manage an automated Conformance Test Suite (CTS). All Lot 1-4 software must pass the CTS prior to deployment. Lot 5 telemetry will serve as the objective technical record to identify latency or interface failures.

• Associate Contractor Agreement (ACA): All awardees (Lots 1-5) must execute a Government-approved ACA upon submission, legally binding them to share technical data, SDKs, APIs, and actively collaborate on troubleshooting without additional cost to the Government. Failure to execute the ACA upon submission will result in the selection of an alternate vendor for its respective lot.

https://sam.gov/opp/923946ff85b94746be9249b5ed5f2fc7/view

To meet urgent operational needs on an accelerated schedule, the Government intends to execute a modernization effort in a milestone-driven, capability-focused approach. The strategy is centered on rapidly integrating the five Priority Capability Deliverables outlined in Section 1 into the STE Virtual Software solution, while concurrently opening the system’s architecture for future growth.

The Government intends to award all three Lots concurrently as either multiple FAR contracts and/or OTA agreements, to establish the full modernization team from the outset. The total combined value of all awarded Lots is approximately $250M. The Government will also establish a basket of vendors that have been identified to have developed solutions of technical merit but were not invited to Phase II. These vendors may be selected to be retained in a basket for up to twenty-four (24) months from notice for potential future selection during the performance of any of the identified Lots. Please note, Lot 2 will remain open for on boarding opportunities throughout the performance of Lot 2. Additional opportunities will be identified at various times throughout the year.

The Government will make available the complete technical baseline for the current TSS, including all available source code, documentation, and Integrated Development Environments (IDEs), as GFI to all qualified offerors upon request. GFI Distribution Agreement is proved as Attachment 6 and the available GFI is referenced in Attachment 6a. All necessary RVCT hardware units, HAPI, technical manuals, and existing software will be provided as Government Furnished Property (GFP)/GFE to the Lot 5 awardee upon contract or agreement award. To assist offerors in facility planning, the Government has incorporated the Hardware Description Characterization Specification (HDCS) into the Technical Data Package (TDP), accessible to qualified U.S. offerors via the GFI distribution process. The HDCS outlines exact dimensions, weights, floor loading requirements, power consumption, heat dissipation (BTU), and clearance profiles for the RVCT suite.

For proposal, facility sizing, and ROM planning purposes, offerors shall assume the SIL facility must support the following representative RVCT system planning baseline:

• Five (5) Concurrent Ground Stations: Each reconfigurable for any combination of available RVCT Ground platforms (e.g., Abrams, Bradley, Stryker, Other Wheeled variants).

• Five (5) Concurrent Air Stations: Each reconfigurable for any combination of available RVCT Air platforms (e.g., AH-64, UH-60, CH-47).

• Three (3) Non-Rated Crew Member (NRCM) Gunner Stations: Configurable for any RVCT gunner variant.

• One (1) Sling Station.

• One (1) Hoist Station.

• Two (2) Unmanned Aerial Systems (UAS) Stations: (e.g., Gray Eagle).

• Two (2) Instructor/Operator Stations (IOS).

• Core Network & Compute Suite: One (1) Central Node, one (1) Field Server, five (5) laptops, and one (1) Distribution Switch Kit.

• Dedicated Hardware Storage: Secure, climate-controlled on-site storage capacity for additional modular RVCT kits, peripheral controls, and cabling while not in active use on the lab floor.

GFE hardware will be delivered directly to the Lot 5 contractor-provided physical facility in Orlando, FL. The Government will not furnish real estate, physical building space, facility utilities, or internal laboratory networking infrastructure for the SIL.

Important, anticipated acquisition events, and dates are as follows:

Acquisition Event Anticipate Date(s) DRAFT STE VSW CFS posting 27 Augst 2026 DRAFT STE VSW CFS Q&A 27 August 2026 - 13 September 2026 FINAL STE VSW CFS posting 15 September 2026 STE VSW Industry Day and One on One sessions, Orlando, Fl. 22 - 24 September 2026 STE VSW CFS solutions due 29 September 2026 STE VSW Lots 1,3, & 5 Down select notifications 02 October 2026 STE VSW Lot 1, 3, & 5 Demonstration Pitch 20 - 22 October 2026 Selection Notices STE VSW Lot 1, 3, & 5 vendors 30 October 2026 SOW/PWS collaboration, request for final price, and solutions 02 – 06 November 2026 Anticipated Lots 1, 3, & 5 awards 13 November 2026

The Government team will host a voluntary in-person Industry Day on Tuesday, 22 September 2026, between 0800 – 1200 at the Central Florida Tech Grove, Partnership IV, 12809 Science Drive, Orlando, Florida 32826. The Government will also schedule One-on-One’s to be held between 22-24 September 2026 at a location to be determined during Industry Day or sooner.

Link to Industry Day and One-on-One’s Form: https://forms.osi.apps.mil/r/qBdF1QH0XE

5.1 Overview of Submission Phases

This Call for Solutions utilizes a multi-phase rapid down-select process designed to identify mature, integration-ready solutions. The Phase I submission is intended to be a lightweight, high-impact technical snapshot, not an exhaustive written solution/proposal.

Updated Phased Solicitations and Awards: To eliminate cross-lot dependencies and ensure application developers build against a validated core foundation, the Government will execute a phased award schedule:

1. Initial Awards: Concurrent award of Lot 1 (two competing vendors for the 90-day sandbox), Lot 3 (HIL Integration), and Lot 5 (Enterprise Integration Support).

2. Deferred Solicitations (Lots 2 and 4): Formal proposal submission deadlines and awards for Lot 2 (Simulation Applications) and Lot 4 (AAR https://forms.osi.apps.mil/r/qBdF1QH0XE

Data Layer) are deferred until completion of the 90-day sandbox and selection of the final Lot 1 Common Core provider (approx. Month 4). Upon final Lot 1 selection, the Government-approved SDK and API specifications will be released to Lot 2 and Lot 4 offerors.

The response process for this Call will generally consist of the following phases:

Phase 1: Solution Brief

Offerors will submit a high-level summary of their solution, addressing the government’s objectives and requirements. Offerors shall submit a solution structured into the Volumes as noted in Section 6. Solutions that fail to adhere to the page limitations or submission requirements will be considered non-compliant and may not be reviewed.

Detailed solution brief submission requirements for Phase 1 are provided in Section 6.

Evaluation criteria for Phase 1 are outlined in Section 7.

Phase 2: Demonstration Pitch

Selected offerors may be invited to present and discuss their solution in a live or virtual setting.

Phase 3: Revised Solution

The Government shall use the same criteria to evaluate prototype solutions as described for Solution Briefs.

5.2 General Notes

• Offerors are reminded that all awards are subject to the availability of funds and the Government reserves the right to make multiple awards, a single award, or no award as a result of this Call.

• Only a Contracting or Agreements Officer has the authority to enter into, modify, or execute a binding instrument on behalf of the United States Government. All payment obligations are subject to Congressional appropriations.

• In order to be eligible for award, offerors must:

o Possess a Unique Entity ID (UEI) and be registered in the System for Award Management (SAM) prior to award and maintain active registration throughout the period of performance.

o Register in the prescribed government invoicing system (e.g., Wide Area Work Flow).

o Accurately represent their small business size and status as required.

o Be determined responsible by the Contracting/Agreements Officer and not be suspended, debarred, or otherwise prohibited from receiving an award.

o Disclose any actual or potential OCIs to the Contracting/Agreements Officer prior to award.

• Offerors are responsible for monitoring SAM.gov for any amendments or updates to this Call.

Notice to Offeror(s): The Government reserves the right to cancel this open Call, either before or after the closing date. If the Government cancels this open Call, the Government has no obligation to reimburse an offeror for any costs.

6. SOLUTION BRIEF SUBMISSION REQUIREMENTS

6.1 Phase 1 – Solution Brief

All solution briefs must conform to the guidance outlined in Section 6 and be sent electronically to all Point of Contracts (POCs) for Solution Brief Submission, identified on Page 1 of the Call for Solution, no later than Tuesday, 29 September 2026 at 1300 EDT for Lot 1, Lot 3, and Lot 5. Submissions will be evaluated with consideration given to the vendor’s ability to substantiate a solution that presents the best value to the Government and lowest overall project risk.

All solution/proposal submissions shall be submitted using no less than 11 size arial font, one-inch margins on a 11x 8 standard size page. File size shall be broken up to no larger than 5MB size per email submission. There are no restrictions on file naming. The email solution/proposal submission shall identify specific Lot number.

Acknowledgment Required: Offerors submitting proposals for all Lots must acknowledge receipt of Amendment 001 in their Volume I Transmittal Letter. Failure to acknowledge this amendment may result in rejection of the submission.

6.1.1 Volume I: Mandatory Technical Readiness and Compliance

(No Page Limit, Standard Forms, MS Word or PDF)

1. Attachment 01 STE VSW Company Information 01 and/or Interested Vendor and Information Form: https://forms.osi.apps.mil/r/n5qzG3ZZEY

2. Attachment 4, ACA Letter of Intent (LOI): A signed statement acknowledging and agreeing to the ACA data-sharing requirements, approved DD Form 2345 (JCP) and valid SAM registration at time of solution/proposal submission.

3. One World Terrain (OWT) / OGC Ingestion & Rendering (Applicable to any Lot with a Terrain/Rendering Engine). The proposed solution must demonstrate the native ability to ingest and render One World Terrain (OWT) data formats. Offerors must provide either:

a. Direct links to technical documentation, user manuals, or software release notes demonstrating native support for OWT data formats and standard OGC 3D streaming protocols (e.g., OGC 3D Tiles, WMS, WFS); or

b. A screen capture / short video clip (embedded in the 5-minute product demo) showing the software successfully ingesting, streaming, and rendering OWT sample datasets (provided in the TSS GFI baseline) or standard OGC 3D Tiles.

4. OCI Dual-Submission Acknowledgement Statement (If bidding Lot 5): Offerors bidding on Lot 5 must provide a signed corporate statement acknowledging the Lot 5 Structural Award Exclusion. If the offeror or any of its corporate affiliates are simultaneously proposing on Lots 1, 2, or 4, the statement must explicitly acknowledge that:

a. The corporate family, and its subcontractors, cannot be awarded or perform on both Lot 5 and Lots 1,2, or 4; and https://forms.osi.apps.mil/r/n5qzG3ZZEY

b. If selected for award on multiple conflicting Lots, the offeror agrees to execute the Government’s single-award election process prior to Phase 3 agreement/contract execution.

5. Master Compliance Matrix (Optional): Offerors may include a comprehensive Master Compliance Matrix mapping all CFS requirements to proposal sections in Volume I. This does not count against any page limits.

6.1.2 Volume II: Anonymous Technical Concept Submission

(Limit: Pages limitation as described below applicable per Lot Submission, MS Word or PDF)

Page Limits:

• Lot 1 (Common Core Software): Maximum of 8 pages total, structured as:

o Core Technical Concept (Pages 1-5): Core simulation architecture, modernization path (A, B, or C), Ground Table II collective live-fire gating capability, open SDK/API framework.

o Annex A – RVCT-Air Architectural Strategy (Pages 6-8): A dedicated 3-page trade space narrative addressing the offeror’s architectural approach to delivering RVCT-Air requirements (e.g., Unified Simulation Core vs. Modular Lot 2 Flight Plugins vs. Federated Aviation Engines; 6-Degree of Freedom aerodynamic modeling; TC 3-04.3 Tables VII/X collective gunnery; and AMPS/mission-rehearsal tool interoperability).

• Lot 2 (Simulation Applications): Maximum of 5 pages per distinct standalone software application/module offered).

• Standard Baseline: Maximum of 5 pages per Lot submission (Lots 3, 4, and 5).

Architectural Diagrams: Up to two (2) additional pages of high-level architectural diagrams may be included as an attachment that does not count against the page limit. Narrative text on diagram pages must be strictly limited to structural labels and functional callouts; embedded descriptive narratives will be disregarded by evaluators.

Anonymity Guidelines: Offerors must omit company names, corporate logos, CAGE codes, personnel names, and prime contract numbers from Volume II. Standard commercial product names, third-party COTS, and GOTS baselines (e.g., Unreal Engine, Unity, Kafka, gRPC, OneSAF, Cesium, TSS) may be named for technical and architectural clarity, provided the offeror does not state they are the developer/owner of the product or make claims that disclose corporate identity.

Solutions that violate this anonymity requirement in Volume II may be considered non-compliant and may not be reviewed. All other volumes should be clearly marked with the vendor’s information.

Each solution brief must include:

1. Modernization Path Declaration (Applicable to Lot 1 Offerors Only): The offeror must explicitly declare which of the following modernization paths their solution is based on:

a. Path A: GOTS-based Approach. The vendor’s solution is primarily based on modifying and enhancing the available TSS baseline.

b. Path B: COTS-based Approach. The vendor’s solution is based on a new COTS solution that will replace the TSS baseline.

c. Path C: Hybrid Approach. The vendor’s solution is a hybrid that combines significant portions of the GOTS baseline with new COTS components.

2. A high-level software architecture diagram relevant to that Lot’s function and declared Modernization Path.

a. Lots 1, 2, and 4 (Software Providers): Detail the software architecture, scalability, and physics/data handling capabilities. For Lot 1, this section must also address the solution’s current capability or future roadmap for providing a user-facing scripting environment.

b. Lot 3 (HIL Integrator): Detail the engineering methodology for mapping physical GFE RVCT inputs to the HAPI standard, minimizing latency, and executing hardware integration in the Orlando Software Integration Lab (SIL).

c. Lot 5 (Enterprise Integrator): Detail the DevSecOps administration, the physical facility and network infrastructure plan for the contractor-provided Orlando, FL Software Integration Lab (SIL), and the methodology for executing the Conformance Test Suite (CTS). The facility narrative must address square footage and floor plan accommodating the three (5) baseline RVCT trainer cabs (per the HDCS); physical security and CUI safeguarding controls; power, cooling, and structural floor-loading capacity; internal simulation and development local area network architecture; and the facility’s ability to sustain operations beyond the 9-month prototype into follow-on production. (Narrative must be contained within the 5-page limit for Volume II).

i. (Optional) Lot 5 vendors may also submit an alternative, hybrid or cloud-based operational hosting model as an appendix to this volume. This optional solution should detail the value proposition, including potential cost savings, performance benefits, and a realistic assessment of the network and security challenges associated with streaming the simulation from the cloud to fielded sites.

3. Data Segregation and Releasability Approach: A description of the architectural approach to data segregation, showing how sensitive/CUI data is isolated from the core application to enable rapid data sanitization and coalition releasability.

4. The licensing model and architectural data rights for the software solution for that Lot.

Offerors must clearly define their commercial model (e.g., Perpetual License for one-time purchase, Enterprise Subscription, or usage-based).

6.1.2.1 Schedule Narrative:

(This is also part of Volume II and page count)

The vendor will provide a brief narrative describing how the solution meets the requirements of that specific Lot.

a. For Lot 1 Offerors: Based on your declared path, you must provide:

i. If Path A (GOTS): A detailed plan for opening, simplifying, and enhancing the TSS baseline to meet all core priority capability deliverables.

ii. If Path B (COTS): A detailed plan to configure, integrate, and if necessary, modify the COTS product to meet all core priority capability deliverables.

iii. If Path C (Hybrid): A clear description of which GFI components will be retained, which COTS components will be introduced, and the integration plan between them.

b. For All Other Lots: A detailed integration plan demonstrating how your application/service will utilize the Government-approved SDK to plug into the core architecture.

5. Special Topic: Aviation Simulation Architectural Approach (RVCT-Air):

Army Aviation requires high-fidelity flight dynamics (6-DOF), rigorous aircraft OFP concurrency, specialized mission rehearsal tools, and TC 3-04.3 Table VII/X collective gunnery. Vendors proposing Lot 1 or Lot 2 (Aviation Applications) must specifically articulate their architectural strategy for delivering RVCT-Air capabilities by addressing:

1. Architectural Paradigm: Does the offeror propose (a) a Unified Engine handling both ground vehicle dynamics and high-fidelity rotary-wing flight physics; (b) a Modular App-Store Model where specialized Lot 2 aviation physics modules plug into a core platform via the SDK; (c) a Federated Architecture interfacing the core ground simulation with dedicated aviation simulation/rehearsal engines via standard protocols (DIS, HLA, gRPC); or (d) another alternative that best meets the Army’s objectives

2. External Tool & AMPS Integration: How does the proposed solution ingest AMPS mission-planning data and interoperate with incumbent aviation mission-rehearsal tools (e.g., MACE, FalconView) and cockpit hardware (e.g., RVCT-A, CAP-T)?

3. Teaming & Subject Matter Expertise: What teaming or co-development strategies will the offeror leverage with accredited aviation simulation providers to ensure rapid delivery of certified AH-64E, UH-60M/V, and CH-47F collective capabilities?

6.1.3 Volume III: Product Demonstration Artifacts

(No page limit for artifacts, MS Word or PDF)

Volume III serves as an objective technical readiness gate to verify and validate TRL 8/9 maturity and integration readiness. Volume III artifacts are not required to be anonymous.

Vendors must provide the following “show, don’t tell” artifacts:

1. Product Demonstration Video (5-Minute Maximum): Video demonstrating the core functionality of the working software, HIL test rig (Lot 3), or operational DevSecOps/CTS tooling (Lot 5). Videos may be provided via public URL, password-protected portal, or secure electronic transfer (details in submission instructions).

2. Live API/SDK Documentation: A URL/link to existing public or access-controlled developer documentation, OpenAPI specs, or test harnesses. (Note: Path A GOTS-based offerors are exempt from public internet URL requirements for GFI code and may provide technical interface architecture specifications).

6.1.4 Volume IV: Rough Order of Magnitude (ROM) and Licensing Model

(No Page Limit. Offerors shall provide a fully unlocked Excel workbook)

This volume provides the Government with a Rough Order of Magnitude (ROM) and is collected for Government planning and market research only; this volume will NOT be evaluated or scored.

1 The ROM for Government-Owned (GOTS) Solutions: If an offeror is submitting the use of existing GOTS, they shall not provide software license cost data. Instead, the ROM must detail:

a. Any non-recurring engineering (NRE) costs required to modify, wrap, or configure the GOTS component to meet the open API mandates of this RFS.

b. The annual, recurring labor and material price required to sustain and support the GOTS component for the period of performance (9-months).

2. Software Licensing Models (Applicable to Lots 1, 2, and 4): Offerors submitting commercial software must define their price. The Government heavily prefers flat, Enterprise-wide licensing models that do not penalize the Army for scaling user counts or adding installations. Enterprise-wide refers to the Synthetic Training Environment (STE) / STE Virtual Software (VSW) program ecosystem across all planned simulator suites and deployed Passive Optical Network (PoN) nodes.

a. Perpetual Licenses (One-Time Purchase): If submitting an outright sale, the offeror must clearly separate the one-time perpetual license price from the recurring annual Maintenance and Support price.

b. Subscription/SaaS Licenses: If submitting a subscription, the offeror must define the term (e.g., annual) and exactly what is included (e.g., software access, hosting, all patches/updates, and tech support).

c. Tiered/Metric-Based Pricing: If the license is not Enterprise-wide, the offeror must explicitly state the limiting metric (e.g., price per concurrent user, price per physical node, or price per CPU core) and provide the cost-scaling tiers.

3. ROM for Labor and Integration Services (As applicable to all Lots): Offerors must provide a ROM for the labor required to execute the scope of their Lot

a. A breakdown of labor categories and estimated annual hours.

b. For Lot 3, ROM pricing must focus exclusively on HIL engineering, HAPI translation development, and SIL integration testing.

c. For Lot 5, ROM pricing must clearly separate: (1) physical SIL facility establishment, commercial lease/occupancy costs, power/HVAC infrastructure, and internal simulation/development local area networking;

(2) the technical setup of the DevSecOps pipeline, CI/CD toolchain, and API Gateway; and (3) the ongoing, continuous operations, physical security, and maintenance of the physical SIL facility and CTS testing harness.

Offerors shall price the initial 9-month prototype effort while identifying anticipated annual recurring facility run-rates for follow-on operational planning.

4. ROM for Data Rights and Intellectual Property: If there are any separate price or fees required for the Government to obtain Government Purpose Rights (GPR) for the proposed API documentation, SDKs, or Interface Control Documents (ICDs) within the STE Virtual Software ecosystem, a ROM for those prices must be explicitly identified as a separate line item.

6.1.5 Volume V: Recent and Relevant Experience

(Limit: 3 pages per lot submission, MS Word or PDF)

Offerors shall provide narrative detailing up to three (3) recent, within three (3) years from CFS submission date, relevant contracts/agreements.