DRAFT STE VSW Call for Solutions 08.27.26.pdf

DRAFT

Call for Solution Synthetic Training Environment (STE)

Virtual Software (VSW) 27 August 2026

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 7 of this Call for Solution

*Solutions Due Date/Time

(Suspense)

Monday, 21 Sep 2026 at 1000 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: SEAN J. JOHNSON;

sean.j.johnson2.civ@army.mil

Contracting/Agreements Specialist: RUTH TORRES;

ruth.e.torres10.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.

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

mailto:mark.a.muniz6.civ@army.mil mailto:sean.j.johnson2.civ@army.mil mailto:ruth.e.torres10.civ@army.mil

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 four core operational priority capability deliverables outcomes:

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

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

4. 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 four 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 OCI restrictions). Each Lot will be evaluated independently to ensure the Army acquires the best 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 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 Common Core

Software (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 has a strong desire for the Lot 1 CCS to provide a high-level scripting environment accessible to non-developer "Power Users.”

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). Solutions that provide this capability as part of their baseline offering will be evaluated more favorably. 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 true “best-of-breeds” capabilities of industry. 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 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.

• Key Responsibilities:

• Infrastructure Management: Deploy and manage the Government-owned

DevSecOps CI/CD pipeline, the enterprise API gateways/message bus, and the physical Software Integration Lab (SIL) under the direct supervision of the

Government Program Office.

• 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: To ensure objective integration and impartial governance, a strict OCI firewall is established for the Lot 5 Integration Support vendor. Any vendor awarded Lot

5 is strictly prohibited from proposing on or providing software for Lot 1 (Common Core), Lot 2 (Simulation Apps), or Lot 4 (Training Management).

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 owns the

"digital motherboard" (API Gateway, Message Bus, and HAPI standard) on behalf of, and under the direct authority of, the Government. Lot 5's technical responsibility is limited to the transport, validation, and, if necessary, translation of data payloads between Lots. Lot 5 is responsible for providing objective compliance reports to the

Government but 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 owns 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 own 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 owns the

"physical-to-digital translation." Lot 3's responsibility starts at the physical GFE control outputs and stops once those signals are successfully converted into compliant HAPI data packets and delivered to the Lot 5 API Gateway. Lot 3 shall not modify the Lot 1 core simulation physics or the Lot 2 application software.

• Lot 4 Boundary (The AAR and Data Analytics Provider): The Lot 4 contractor owns 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 Training Simulation Software (TSS) as Government Furnished Information (GFI). This GFI is provided 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 (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, 2, and

4 must possess a fully developed, documented Software Development Kit (SDK) and/or

Application Programming Interfaces (APIs) at the time of solution submission.

• MOSA and Interoperability Interface Standards: To achieve a true plug-and-play ecosystem, all components (Lots 1, 3, 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 initial system acceptance.

• 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 (STE Virtual Software

Training Requirements Overview). 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: 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)

• External Ecosystem and Interoperability Requirements:

o Live, Virtual, and Constructive (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: [INSERT MOST RECENT SAM.GOV AOS PUBLIC VIEW LINK] This Call provides instructions to companies and how the Government will evaluate submissions.

The Government anticipates awarding multiple CSO FAR based contracts 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 within 30 days of award, 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 within 30 days of award 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 four 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 five Lots concurrently as either multiple FAR contracts 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 highly qualified solutions for potential future selection during the performance of any of the identified Lots.

The Government will make available the complete technical baseline for the current Training Simulation Software (TSS), including all available source code, documentation, and Integrated Development Environments (IDEs), as GFI to all qualified offerors upon request. Instructions for distribution to be published as an attachment to the CFS. All necessary RVCT hardware units, HAPI, technical manuals, and existing software as GFP/GFI to the Lot 5 awardee upon contract or agreement award. This GFP will be utilized to establish the physical STE Virtual Software Integration Lab (SIL) for multi-vendor testing and conformance validation.

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

Acquisition Event Anticipate Date(s)

DRAFT CFS Posting 27 Augst 2026

DRAFT CFS Q&A 27 August 2026 - 09 September 2026

FINAL CFS Posting 10 September 2026

Industry Day and One on One sessions, Orlando FL. 15 - 17 September 2026

CFS Solutions Brief Due 21 September 2026

Down Select notifications 25 September 2026

Demonstrations Lots 1-5 13 - 15 October 2026

Lot 1-5 Selection Notices 23 October 2026

Request for Revised Solution 26 - 30 October 2026

Anticipated Lots 1 - 5 awards 06 November 2026

The Government team will host a voluntary in-person Industry Day and One on Ones on 15 – 17 September 2026, 0800 – 1600 at the Central Florida Tech Grove, Partnership IV, 12809 Science Drive, Orlando, Florida 32826. Link to RSVP to follow.

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

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

After Demonstration Pitches, the Government shall further down-select potential awardees and issue a Request for Revised Solution (“RRS”) to the remaining vendors. The RRS will have specific guidelines. Chiefly, offerors must submit a statement of work/performance work statement and a detailed price breakdown as it relates to payment milestones. The Government shall use the same criteria to evaluate prototype solutions as described for Solution Briefs.

Phase 4: LOT I Competitive Table II STX-V Sandbox

Lot 1 awardees, two, will compete to deliver a certified Platoon-level Table II STX-V capability in a 90-day sprint.

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 Organizational Conflicts of Interest (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

Volume I: Administrative and Compliance

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

1. Cover Letter: Identifying the specific Lot(s) being bid.

2. ACA Letter of Intent (LOI): A signed statement acknowledging and agreeing to the Associate Contractor Agreement (ACA) data-sharing requirements.

3. TRL 8/9 Verification: A link to a live commercial webpage, press release, or existing contract number demonstrating the proposed core software is currently fielded and operational.

4. OCI Mitigation Plan (If bidding Lot 5): A legally binding statement confirming the offeror is not bidding on Lots 1, 2, or 4, or a formal Organizational Conflict of Interest (OCI) mitigation plan if corporate affiliates are involved.

Volume II: Anonymous Technical Concept Submission

(Limit: 5 Pages per Lot Submission, MS Word or PDF)

To ensure an impartial and objective assessment, the Government will conduct a blind assessment of the Technical Concept (Volume II). Offerors must ensure that their company name, logos, identifying marks, or names of key personnel do not appear anywhere in the Volume II submission. 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 GFI.

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 the deployment plan for fielded sites.

c. Lot 5 (Enterprise Integrator): Detail the DevSecOps administration, the plan for managing the physical Software Integration Lab (SIL), and the methodology for executing the Conformance Test Suite (CTS).

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

Technical Schedule Narrative: 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 GFI to meet all core four priority capability deliverables.

ii. If Path B (COTS): A detailed plan to configure, integrate, and if necessary, modify the COTS product to meet all four 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.

Volume III: Product Demonstration Artifacts

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

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

1. Product Demonstration Video (5-Minute Maximum): A link to a non-password-protected, 5-minute (max) video demonstrating the core functionality of the proposed software. The video must show the actual software running, not a PowerPoint presentation.

2. Live API/SDK Documentation: A direct URL to a live, public-facing portal, GitHub repository, or similar site containing the offeror’s existing API documentation and/or SDK for the software.

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) for planning and historical purposes. The submitted ROM is not a binding price proposal and will not be evaluated.

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.

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.

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 costs must be broken out to show HIL integration/testing in the SIL versus the travel and labor costs for physical fielding, installation, and calibration at fielded training sites.

c. For Lot 5, ROM pricing must clearly separate the setup of the DevSecOps pipeline and API Gateway from the ongoing, continuous management of the physical SIL.

4. ROM for Data Rights and Intellectual Property: If there are any separate price or fees required for the Government to obtain the necessary rights to use, modify, or share the vendor’s 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.

Volume V: Recent and Relevant Experience Narrative

(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, and relevant contracts. The narrative for each contract must be no more than one page and must include:

1. Contract Identification: Contract number, period of performance, total contract value, and current Government Point of Contact (POC) with phone number and email.

2. Brief Description of Work: A short summary of the work performed.

3. Relevance Narrative: A specific, detailed narrative explaining how the referenced contract demonstrates the offeror’s experience with the key capabilities outlined in Relevant Experience (e.g., how they acted as a modular component, how they teamed with other vendors, or how they managed a secure IL environment).

Based on the Evaluation of the written submissions, the Government will down-select the most highly rated vendors for each Lot to proceed to Phase II.

6.2 Phase 2 – Demonstration Pitch

•Live Demonstrations: Down-selected offerors will be invited to conduct a one-hour, live technical demonstration of their submitted software solution to the Government evaluation team.

6.3 Phase 3 – Revised Solution Submission

Phase 3 revised submission requirements and evaluation criteria will be outlined in the invitation to this phase.

6.4 Phase 4 Competitive Table II STX-V Sandbox

(Only Applicable to Lot I Awardees)

GOAL: Two Lot 1 vendors will compete to deliver a certified Platoon-level Table II STX-V capability in a 90-day sprint. The winner will be selected based on superior performance and integration speed.

• Milestone 1.1: Concurrent Award and SRR (First 30 Days) o Action: Two Lot 1 competitors to provide a functional Table II Capability.

o Action: A joint System Requirements Review is held. The rules of the 90-day

“Table II Sandbox” competition are finalized.

• Milestone 1.2: SIL Establishment and API Scaffolding (First 30 Days Concurrently) o Action: Lots 3 and 5 establishes the SIL that will host the 90-day competitive sandbox.

o Action: Within the first 15 days of the sandbox period, both Lot 1 awardees shall deliver their complete, existing software development kit (SDK) and all associated API documentation to the Lot 5 integration partner. The maturity, completeness, and ease of use of this SDK will be an evaluation factor in the final down-select.

• Milestone 1.3: 90-Day Competitive Sandbox (Days 31 - 120) o Action: The two Lot 1 vendors are given access to the SIL. They have exactly 90 days to develop and/or integrate the Table II application into their respective

Common Core engines utilizing RVCT hardware.

o Event: A mid-point preliminary design review is held to check progress and ensure both vendors are working towards requirements/objectives and remain on schedule.

• Milestone 1.4: CDR and Final Down-Select (End of first 120 Days) o Event: A final, head-to-head demonstration where both Lot 1 vendors execute a live, scored Platoon Table II run on the RVCT hardware.

o Metric: The winner is selected based on which platform demonstrates higher performance, greater stability, and lower latency.

o Outcome: By the end of 120 Days, the Government will have a working, fieldable

Table II Capability.

Upon selection and award of the Lot I sandbox competition, the Government will select one vendor to proceed and perform the following:

Full Ecosystem Expansion (Months 5-9)

GOAL: With the core platform and the highest-priority capability now proven, rapidly integrate the remaining priority items and priority capabilities. Upon selection of the final Lot 1 awardee, the Lot 5 Integration Partner will work with the winner to establish the formal common SDK. This Government-controlled SDK will be provided to all future Lot 2 awardees as GFI and will serve as the single, authoritative interface for all third-party application development.

• Milestone 2.1: Combined Arms and MCIS Integration o Action: The new Lot 2 vendors for specified, priority Combined Arms and Mission

Command Capabilities plug their applications into the now-stable architecture.

• Milestone 2.2: AAR Integration o Action: The new Lot 4 vendor for After Action Review capabilities plug their application(s) into the now-stable architecture.

• Milestone 2.3: IOC and Continuous Onboarding (Month 9 and beyond) o Action: The Lot 2 “Open Window” policy is activated for the competitive onboarding of future capabilities.

7. EVALUATION CRITERIA

7.1 Phase 1 - Solution Brief Basis of Evaluation

Volume I: Requirements will be evaluated for completeness

Requirement Proof Required in Solution

1. TRL 8/9

Maturity

The core software proposed must be currently fielded or commercially available

Offerors must provide links to existing user manuals or live deployments. Crucially, offerors must also provide documentation for the mature, open APIs (e.g., REST, HLA, DIS) they will use to expose their internal proprietary data to the STE Virtual software ecosystem.

2. ACA

Commitment

The vendor must agree to sign the Associate Contractor Agreement (ACA) to share data and troubleshoot across Lots.

A signed Letter of Intent (LOI) acknowledging the ACA requirement in Section 6.

3. OGC Standards Compliance (Lot 1)

The proposed solution's terrain engine must demonstrate the native ability to ingest and render OWT data formats.

Offerors must provide one of the following as proof: A) A direct link to existing public-facing technical documentation, user manuals, or software release notes that explicitly state compliance with OGC standards (e.g., WMS, WFS, or 3D Tiles). OR B) A screenshot or short video clip (included in the 5-minute product demo) showing the offeror's software successfully connecting to and displaying data from a known public OGC data source.

Volume II and V:

Weighted Evaluation Factors for Volumes II and IV

Evaluation Order of Importance:

Factor 1 (Technical Schedule) > Factor 2 (Technical Approach) > Factor 3 (Relevant and Recent Experience)

Factor 1: Technical Schedule Narrative

• Speed to IOC: The Government will evaluate proposals that deliver the mandatory capabilities on the most compressed timeline.

Velocity of Capability Delivery: The Government prioritizes rapid fielding to the warfighter. Solutions that demonstrate the earliest viable deployment of the mandatory core capabilities, specifically achieving an operational Initial Operating Capability (IOC) and a certifiable Table II training capability on the most aggressive, credible schedule are preferred.

• Factor 2: Technical Approach

• Lot 1 (Common Core Software): The Government will evaluate the offeror’s chosen path for delivering the core capabilities described in Section 1.

• If proposing GOTS-based solution, the Government will evaluate the credibility, efficiency, and technical feasibility of the plan to enhance, simplify, and open the existing code to meet all Priority Capability Deliverables and open architecture requirements.

• If proposing a new COTS-based solution, the Government will evaluate the credibility, efficiency, and technical feasibility of the plan to configure, integrate, and, if necessary, modify the COTS product to meet all Priority Capability

Deliverables and open architecture requirements.

• Regardless of path, all Lot 1 solutions will be evaluated against the following universal technical criteria:

• Architectural Soundness & Modularity: The Government will evaluate and favor solutions that demonstrate a clear separation of concerns, utilize a service-oriented or microservices-based design, and minimize inter-component dependencies. This ensures the solution is inherently adaptable and easy to sustain over the long term.

• Data Management & Releasability Strategy: The Government will evaluate the offeror's approach to data handling. This includes the strategy for separating sensitive data from the core executable code to support Program Protection and Foreign Disclosure requirements.

Proposals that provide a clear, streamlined mechanism for data sanitization, parameter masking, and creating releasable "export versions" will be rated more favorably.

• Integration Readiness & “Developer Experience”: The Government will evaluate the maturity and quality of the proposed APIs and SDKs that will enable the "App Store" model. The evaluation will focus on the completeness of the documentation, the use of modern, standards-based protocols (e.g., REST, OpenAPI), and the overall ease of use for third-party developers who will need to integrate with the system.

• Lot 2 (Simulation Application Software): The Government will evaluate the offeror’s plan to rapidly integrate their proposed “application” (e.g. Table II module, new vehicle platforms, Mounted Mission Command) into the modernized Lot 1 TSS baseline. This includes:

• The vendor’s proven ability to decouple their application from proprietary engines.

• A detailed integration plan demonstrating how their application will utilize the new

Government-approved SDK to plug into the TSS core. Note to Offerors for Lot 2:

The Government recognizes that the final Lot 1 SDK will not be selected until after proposal submission. Offerors for Lot 2 should base their integration plan on their own proven corporate experience integrating with third-party, standards-based SDKs (e.g., Unreal, Unity, or other open simulation platforms). The evaluation will focus on the credibility of the offeror’s integration process and methodology, not on a detailed plan for a specific, yet-to-be-determined SDK.

• Lot 3 (HIL Integration and Test): The Government will evaluate the offeror's technical methodology for ensuring the software (Lot 1) and its integrated applications (Lot 2) perform with high fidelity on the physical GFE RVCT hardware. This includes the plan for testing and validating the HAPI interface, minimizing latency, and performing on-site calibration.

• Lot 4 (AAR & Training Mgmt): The Government will evaluate the offeror's plan to integrate their AAR and training management tools with the modernized software baseline. This includes their technical approach to subscribing to the new open APIs and ingesting real-time event and telemetry data to generate objective, data-driven AARs.

Lot 4 (AAR & Training Management Data Layer): The Government will evaluate the technical maturity, efficiency, and analytical depth of the offeror’s integration plan.

Evaluation will be based on:

• API Compliance & Zero-Lock Ingestion: The extent to which the offeror’s tool natively subscribes to standard publish-subscribe messaging interfaces (e.g., gRPC, Kafka streams, WebSockets) utilizing open data schemas, without requiring proprietary adapters, code-level engine modifications, or third-party middleware.

• High-Throughput Stream Processing: The credibility of the offeror's approach to ingesting, buffering, and logging high-density simulation event streams (supporting 50,000+ active entities at high tick rates) while maintaining low compute/memory overhead and preventing data loss.

• Automated, Doctrinal Performance Analytics: The capability of the tool to automatically parse raw event telemetry (e.g., trigger pull, time-of-flight, target presentation, hit/kill outcomes) to generate objective, standardized After-Action Review (AAR) products, 3D spatial replays, and automated doctrinal scorecards (specifically supporting IWTS Table II crew and section gunnery metrics IAW TC 3-20.0).

• Lot 5 (Enterprise Integration Support): The Government will evaluate the offeror's technical expertise and proposed plan to manage the Government’s DevSecOps environment. This includes their methodology for:

• Securely hosting the GFI source code repository.

• Administering the modernized, Government-approved SDK and APIs.

• Operating the Conformance Test Suite (CTS) to objectively validate all code modifications and third-party integrations against the modernized baseline.

• Managing data from the core software. Solutions that provide automated or highly streamlined tools for data sanitization, parameter masking, and exportability/releasability configuration will be evaluated favorably.

Lot 5 (Enterprise Integration Support): The Government will evaluate the technical feasibility, architectural soundness, and operational effectiveness of the offeror’s integration methodology across four core areas:

• Multi-Vendor Architecture & Interface Governance: The maturity of the offeror's plan to serve as technical custodian for the system's common APIs and SDKs.

The Government will evaluate the offeror's tools and processes for managing the master interface registry (e.g., gRPC/Protobuf contracts), enforcing backward-compatibility standards across independent vendor releases, and distributing unified, language-specific developer stubs to prevent software interface drift across Lots.

• Automated Conformance Test Suite (CTS) & Acceptance Verification: The completeness and objectivity of the offeror's automated testing methodology. The evaluation will favor solutions that provide automated, data-driven validation frameworks capable of stress-testing combined multi-vendor builds—specifically measuring end-to-end latency, compute and memory consumption, simulation tick rates, and data throughput under high-entity loads (50,000+ entities) to generate definitive compliance reports for Government milestone acceptance.

• Software Integration Lab (SIL) & Collaborative Prototyping Operations: The credibility and thoroughness of the offeror's plan to establish, configure, and operate the physical and virtual SIL environments. Evaluation will focus on the offeror’s approach to managing physical RVCT hardware-in-the-loop (HIL) connections, supporting the 90-day competitive sandbox for Lot 1 offerors, and facilitating cooperative troubleshooting among component developers under the

Associate Contractor Agreement (ACA).

• Integrated DevSecOps Platform & Data Management: The efficiency of the offeror’s pipeline infrastructure to automate software intake, automated quality checks, and configuration management across all

Factor 3: Recent and Relevant Experience

The Government will evaluate the offeror’s recent, within three (3) years from CFS submission date, track record of successful performance in analogous environments based on the Relevant Experience Narrative submitted in Volume V. The Government will rate the recency and level of relevance to the narratives that provide specific, verifiable examples demonstrating the following:

• Multi-Vendor Teaming: Experience successfully integrating the offeror’s software into a third-party or Government-owned architecture, acting as a modular component rather than a monolithic prime.

• Proactive “Self-Teaming” and Co-Development: A history of proactively forming partnerships with other commercial vendors to deliver a combined, “best-of-breed” solution to a government customer, minimizing the integration burden on the government program office.

IL-Level Deployment and Environment Management (For Lot 5 specifically): Experience managing and operating secure, complex DoD software development and integration environments.

The relevant ratings will be no relevancy/relevant

The Government will confirm recency as a submission within three (3) years from date of CFS submission date.

Volume III:

This volume serves as the primary technical validation for Lots 1, 2, and 4.

Based on the evaluation, the Solution submission will be categorized as Selected for Further Consideration or Not Selected for Further Consideration.