STE VSW Call for Solutions Amend 004.pdf

Call for Solution

Synthetic Training Environment (STE) Virtual Software (VSW)

08 October 2026 Amendment 004

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/Proposals Due

Date/Time (Suspense)

Tuesday, 13 October 2026 at 1000 Eastern

Daylight Time (EDT); Lots 1, 3, and 5 ONLY.

Lots 2 & 4 submissions are deferred and NOT due on 13 October 2026.

Point of Contracts (POCs) for Solution Brief Submission

Contracting/Agreements Of f icer: MARK A. MUÑIZ;

mark.a.muniz6.civ@army.mil

Contracting/Agreements Of ficer: 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;

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.

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.

The purpose of Amendment 002 is to revise the submission date from Monday to Tuesday in Section 6.

The purpose of Amendment 003 is to apply revisions captured in red bold italics font.

All offerors must formally acknowledge receipt of all amendments in their Volume I Transmittal Letter / Master Compliance Matrix.

The purpose of Amendment 004 is to apply revisions captured in red bold italics font.

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/proposals 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/proposals 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.

*See Section 3 Operational Scalability and Echelon Bounding

• 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 Government may issue subsequent calls for specifically identified capabilities, either based on an emerging operational need, or due to a system capability gap. 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.

• Doctrinal Baseline: The Government desires automated, objective data logging and parsing to generate standardized After-Action Review (AAR) products, 2D/3D spatial event timelines, and automated gunnery scorecards in direct compliance with TC 3-20.0 (IWTS Table II) for mounted maneuver and TC 3-04.3

(Tables VII/X) for aviation.

• Readiness Analytics and Industry Innovation: The Government actively welcomes innovative industry capabilities, commercial analytics methods, and modern data-visualization approaches that enable commanders and master gunners to better, more rapidly, and more intuitively understand the true combat readiness of their formations. Offerors are encouraged to propose advanced capabilities beyond legacy playback—such as predictive trend analysis, automated coaching insights, human performance metrics, squad/crew cognitive load indicators.

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.

• Contractor-Furnished Software Integration Lab (SIL) Requirements: The physical facility for the Software Integration Lab must achieve an initial operational capability (IOC) to power and network five (5) RVCT-G kits and five (5) RVCT-A kits within forty-five (45) days post-award to facilitate the start the Lot 1 competitive sandbox.

• Long-Term Facility Vision and Strategic Utility: While the initial Software

Integration Lab (SIL) sprint is bounded within the 9-month prototype period of performance, the Government’s programmatic intent is for the Contractor-

Furnished SIL in Orlando, FL to serve as the enduring, central integration, conformance testing, and cybersecurity accreditation hub for the life of the STE

Virtual Software program. Following Lot 5 vendor success during the Lot 1 competitive sandbox and 9-month prototype period, it is the Government's intent that the physical SIL will transition into a permanent operational facility responsible for:

• Hosting continuous integration and onboarding cycles for third-party Lot 2

“App Store” plug-ins (cadence to be determined);

• Verifying hardware-in-the-loop (HIL) compatibility and low-latency performance for future modifications;

• Serving as the primary staging and validation environment for both live test events and the automated Conformance Test Suite (CTS) to certify all software drops prior to deployment across the Army’s fielded installations;

• Managing continuous DevSecOps pipeline operations, container security hardening, and SBOM policy enforcement in support of fleet-wide Post

Deployment Software Support (PDSS).

• 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.

o The Government confirms that a Lot 5 awardee is permitted, but not required, to introduce innovative technical methods for enabling message traffic generated by

Lots 1–4 to be understood, validated, translated, transported, and made usable within the STE Virtual Software ecosystem. This includes any innovative integration approaches, provided they remain within Lot 5’s defined boundary of responsibilities and comply with established interoperability standards.

o As stated in this solicitation, Lot 5 is responsible for the system API Gateway, message bus, and HAPI standard, serving as the Government’s technical agent responsible for transporting, validating, and translating data payloads between

Lots, and ensuring interoperability across the STE Virtual environment. However, the Government emphasizes that this does not create a requirement for Lot 5 to develop its own integration method/solution. A Lot 5 vendor may fully utilize the open APIs and data fabric provided by the Lot 1 Common Core Software vendor without restriction.

▪ Innovation is allowed: Lot 5 may propose improved or modernized approaches to how integrations are executed, validated, or managed—so long as they remain compatible with the overall STE open-architecture model.

▪ Innovation is not mandatory: Lot 5 is not required to replace or supersede

Lot 1’s SDK or APIs. It is fully acceptable for Lot 5 to rely on the integration mechanisms provided by Lot 1.

▪ Open ecosystem remains the priority: Any Lot 5 innovations must preserve interoperability, avoid proprietary lock-in, and comply with

MOSA requirements, ensuring seamless consumption of message traffic by all STE components.

• 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.

o Operational Scalability and Echelon Bounding (Battalion and Below): The proposed software architecture must be optimized for distributed virtual collective training at the Battalion echelon and below, with primary system design and evaluation focused on the Company and below operational baseline:

▪ Primary Operational Baseline (Company through Crew – 90% use case):

• The system must deliver high-fidelity simulation performance supporting networked RVCT suites representing a full maneuver

Company/Team (accounting for additional variables such as various manned station types, dismounts, and sim operators). In this baseline configuration, the software must seamlessly process active tactical interactions—including platform dynamics, fire-control switchology, weapons effects, and immediate threat/friendly semi-automated forces (SAF).

▪ Distributed Scalability Envelope (Battalion Task Force – Objective / ~10%

Use Case):

• The software architecture and underlying data fabric must scale to support distributed, multi-company collective training up to a

Battalion Task Force. It must keep the design stable, keep entity states synchronized, and ensure weapon effects are delivered on time, even across a distributed tactical network that includes manned stations, adjacent units, and threat SAF.

• 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.

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 Lots 1, 3, and 5 concurrently as either multiple FAR contracts and/or OTA agreements, to establish the modernization team from the outset. The Government will also establish a basket of vendors that have been identified to have developed solutions to have Schedule Narrative, Technical Merit, Solution Viability, Recency, Relevancy, with Low or Moderate overall project risk 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.

Program Lifecycle, Multi-Year Options, and Performance Off-Ramps: While initial awards execute a nine (9) month prototype period of performance to validate core software stability, hardware integration, and Table II live-fire gating, the STE Virtual Software (VSW) program is planned and funded across the FYDP as a multi-year effort with an estimated overall programmatic ceiling of $250M.

• The Government intends to structure resulting awards with a 9-month base prototype period, followed by pre-priced option periods covering a five (5) year lifecycle.

• Performance-Gated Transition: The initial 9-month prototype milestone serves as a formal Government evaluation gate and unilateral performance off -ramp. Performing vendors that successfully demonstrate progress towards the achievement of the Government’s objectives will transition directly into long-term enterprise production and continuous Post-Deployment Software Support (PDSS) under the authority of 10 U.S.C.

§ 4022(f).

• Off-Ramp Authority: In the event an awardee fails to meet technical, schedule, or integration performance milestones during the initial prototype period, the Government reserves the right to off-ramp the vendor and transition the requirement to an alternate qualified vendor from the STE Electronic Basket of Vendors.

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 August 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 Lots 1, 3, & 5 ONLY 13 October 2026

STE VSW Lots 1,3, & 5 ONLY Down Select Notifications 19 October 2026

STE VSW Lot 1, 3, & 5 ONLY Demonstration Pitch 03 - 05 November 2026

Selection Notices STE VSW Lot 1, 3, & 5 ONLY Vendors 13 November 2026 SOW/PWS Collaboration, Request for Final Price, and Solutions Lots 1, 3, & 5 ONLY 13 - 20 November 2026

Anticipated Lots 1, 3, & 5 ONLY Awards 20 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.

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:

• 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).

• Deferred Solicitations (Lots 2 and 4): Formal proposal submission deadlines and awards for Lot 2 (Simulation Applications) and Lot 4 (AAR 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 Workflow).

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, 13 October 2026 at 1000 EDT for Lots 1, 3, and 5 ONLY.

Lots 2 and 4 submission dates will be identified at a later time and are NOT due on Tuesday, October 13 at 1000 EDT.

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 submissions shall be submitted using no less than 11 size Arial font, one-inch margins on an 8.5 x 11 standard size page. File size shall be broken up to no larger than 30MB size per email submission. There are no restrictions on file naming. The email solution submission shall identify specific Lot number.

Acknowledgment Required: Offerors submitting solutions for any of the Lots must acknowledge receipt of all amendments 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. Completed Attachments: (2) Warranties and Representation, (3) Telecom Reps, (4) ACA Letter of Intent (LOI); A signed statement acknowledging and agreeing to the ACA data-sharing requirements, and valid System for Award Management (SAM) registration at time of solution 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

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: Technical Concept Submission

(Limit: Pages limitation as described below applicable per Lot Submission, one side of the page equals one page, MS Word or PDF)

Page Limits:

• Lot 1 (Common Core Software): Maximum of 8 pages total (one side of the page equals a page), 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 (one side of the page equals a page) per distinct standalone software application/module offered).

• Standard Baseline: Maximum of 5 pages (one side of the page equals a page) per Lot submission (Lots 3, 4, and 5).

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

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 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…