STE VSW CFS Q_A Vendor 10.08.26.pdf

LOT/Section

3 LOT 1

Lot 5

With regard to submission instructions Volume III: Product Demonstration Aritifacts; Will a live API/SDK Documentation access be required if the vendor selects the GOTS-provided TSS approach for all Lots of this proposoal?

No, live public API/SDK documentation is not mandatory for offerors proposing Path A (GOTS-based TSS approach). The Government recognizes that the current state of the GOTS baseline as it pertains to external API/SDK documentation; an offeror will not be disqualified or penalized solely for lacking existing public-facing API/SDK links for the GFI. However, one of the fundamental objectives of this modernization effort is to open, modernize, and decouple the core architecture. Offerors proposing a GOTS-based approach must provide in Volume II a clear, detailed technical roadmap and interface design approach demonstrating how they will establish open, published SDKs and modern APIs (e.g., REST, gRPC, HLA/DIS) to expose

TSS simulation services, data models, and external interfaces for third-party integration.

The distributed data requirements associated with the Training Management/AAR Data Layer and the broader STE virtual architecture.

As we reviewed the architecture, we identified a potential failure mode that may be worth validating before the architecture and integration requirements are finalized.

In a distributed training environment, restoring network connectivity after a degraded or disconnected period does not necessarily restore a consistent data state. If individual nodes continue generating or modifying training, mission-command, AAR, scenario, or system data while communications are unavailable or bandwidth constrained, the architecture must ultimately determine:

• What data was successfully delivered before the interruption

• What remains outstanding

• How interrupted transfers resume without retransmitting completed data

• How queued changes are delivered after reconnection

• How distributed nodes return to a synchronized and authoritative state

• How this occurs over constrained links without creating a large recovery-bandwidth requirement

Importantly, we are not suggesting a change to the STE applications themselves.

If this data-continuity condition is already explicitly addressed within the STE-VSW architecture, I would appreciate being pointed toward the responsible technical team or integration partner. If it is not, we believe it may be worthwhile to validate the requirement now, while the architecture remains at a stage where it can be addressed without significant downstream integration impact.

2 Appreciate the comment. The Government welcomes offerors to propose solutions that address these challenges and prevent these potential failure nodes.

1 Thank you for the comment. The Government recognizes the importance of SBOMs for software supply chain risk management and is aligning its approach with current ASA(ALT)

SBOM policy, which requires SBOM delivery, collection, storage, and ongoing monitoring for covered software. In addition, given Lot 5’s role in managing the Government-owned

DevSecOps environment and providing objective integration and conformance validation across multiple vendors, SBOM management and analysis may be an implied support function within that governance framework; the Government will consider whether additional vendor-neutral clarification is appropriate in the final solicitation or draft Q&A response.

The Lot 5 integrator will manage a Government-owned DevSecOps CI/CD pipeline and Conformance Test Suite validating software delivered by independent Lot 1 through 4 vendors, on a "secure by design" foundation aligned to

Program Protection Plan best practices and an accelerated RMF ATO timeline. In a multi-vendor ecosystem, the binaries that actually reach the Software Integration Lab often contain components that vendor-declared inventories do not list.

A documented use case is validating vendor-provided SBOMs against the actual binaries.

The practical effect is objective, automated evidence about third-party code entering the baseline, without adding manual review burden to the integrator or the Program Office. We recognize SBOM tooling is not named in the draft; we raise it only because the governance role you describe depends on knowing what is in each delivered build.

STE VSW Call for Solution Q&A.10.08.26 Vendor

ResponsesQuestions

4 All

5 All

6 Lot 4

7 Lot 3

8 All

9 All

Is the "System Message Bus" equivalent to the LOT 1 data fabric? No, they represent distinct architectural layers with strict boundary demarcation: Lot 1 Data

Fabric: The high-speed, internal data distribution mechanism native to the Lot 1 Core

Simulation Engine, responsible for real-time entity state management, spatial indexing, physics, and local simulation tick synchronization. System Message Bus / Enterprise API Gateway (Lot

5): The overarching "digital motherboard" operated and governed by Lot 5 on behalf of the

Government. It provides the standardized, external publish-subscribe transport layer (e.g., gRPC, Kafka, DDS, HLA/DIS) that moves validated data payloads between Lot 1, Lot 2 applications, Lot 3 hardware inputs, and Lot 4 AAR analytics.

Please clarify whether the Lot 3 contractor's responsibility ends with translating physical GFE inputs/outputs into the

Government-approved HAPI/HAL format and delivering compliant packets to the Lot 5 API Gateway, or whether Lot 3 is also expected to develop or modify platform-specific software residing within Lot 2 applications

Lot 3 responsibility strictly ends at the HAPI/API Gateway boundary. Per CFS Section 2

(Demarcation of Responsibilities, Page 5), Lot 3 is exclusively responsible for the physical-to-digital translation: mapping physical GFE RVCT crew stations, controls, and instruments into compliant Hardware API (HAPI) packets and delivering them to the Lot 5 gateway. Lot 3 contractors shall not develop, alter, or modify Lot 2 application software (such as vehicle dynamics, fire control logic, or weapon terminal effects) or Lot 1 simulation physics.

Will the Government consider hosting the demonstrations in the contractor facilities?

Is it the Government's intent that Product Demonstration Videos and the live API/SKI Documentation are anonymous?

No. To ensure standard, fair, and equal evaluation conditions for all competing vendors, Phase

2 Demonstration Pitches will be conducted either: Virtually via a secure Government-hosted collaboration platform (e.g., MS Teams / Zoom for Gov); or In-Person at a designated

Government facility in Orlando, FL (e.g., Central Florida Tech Grove / Partnership IV). Offerors will connect remotely or present using portable equipment. The Government will not travel to individual contractor facilities for Phase 2 demonstrations.

No, Volume III artifacts (Demonstration Video and API/SDK Documentation) are not required to be anonymous. The Government intends to refine the final CFS to utilize the Volume III artifacts as an objective Pass/Fail (Go/No-Go) technical readiness gate to verify "Proof of

Commercial Maturity" (TRL 8/9) and "Integration Readiness." Because Volume III serves to validate that working, fielded software actually exists rather than being subjectively scored, vendor branding and system names in Volume III are permissible. Note: Volume II (Technical

Concept Submission) remains a blind, narrative evaluation focused on technical approach and architecture, and must remain free of corporate names, logos, or identifying personnel marks.

Please clarify the anticipated sequencing of Lot awards relative to the Lot 1 competitive sandbox and down-select.

Specifically, does the Government anticipate making Lot 2, Lot 3, and Lot 4 selections prior to selection of the final Lot 1 common-core provider? If so, how should Offerors address dependencies on the final Lot 1 SDK/API, data fabric, and interface implementation in their proposed approaches?

The Government is planning to refine the phased award structure to eliminate cross-lot technical dependencies. Initial Awards: The Government will initially award Lot 1 (two competing vendors for the 90-day sandbox), Lot 3 (HIL Integration), and Lot 5 (Enterprise

Integration Support) to establish the Software Integration Lab (SIL), hardware translation layers, and testing infrastructure. Deferred Solicitations/Awards (Lots 2 and 4): Formal awards and integration sprints for Lot 2 (Simulation Applications) and Lot 4 (Training Management & AAR

Data Layer) will likely be deferred until the final Lot 1 Common Core provider is selected at the end of the Phase 4 competitive sandbox (Month 4). Once the winning Lot 1 provider is down-selected, the Lot 5 integrator will publish the authoritative SDK/APIs to all Lot 2 and Lot 4 offerors, ensuring all application and analytics developers build against a known, stable software foundation.

For vendors awarded under Lots 1–4, please clarify whether each Lot vendor will be required to develop and provide applicable environment, cybersecurity, RMF, STIG, vulnerability, and other accreditation/integration artifacts to the Lot 5 integrator.

Yes. While the Lot 5 Integrator administers the enterprise DevSecOps CI/CD pipeline and automated scanning infrastructure, each individual Lot 1–4 vendor is responsible for delivering security-compliant software and supporting accreditation artifacts for their respective components. Deliverables include: containerized builds hardening against applicable DISA

STIGs, automated vulnerability mitigation reports, software architecture descriptions for RMF control implementation, Software Bill of Materials (SBOM), and documentation supporting the system's Authority to Operate (ATO).

10 Lot 1

11 Lot 3

12 Lot 1/2/3/4

13 Lot 1/2/3/4

14 All

15 All

Please clarify whether the requested pricing is intended to cover only the prototype effort described in the CFS or whether Offerors should also provide pricing assumptions for anticipated follow-on production, fielding, sustainment, and/or licensing. If follow-on or enterprise licensing pricing is requested, please provide the applicable period of performance and the scope and planning assumptions Offerors should use for the enterprise license.

Prototype Effort: The primary ROM pricing in Volume IV must cover the prototype modernization and integration effort (Months 1–9). Commercial Software Licensing: For commercial software (Lots 1, 2, and 4), Offerors must provide their long-term licensing structure, specifically defining: Initial prototype license pricing (covering the initial 9-month period of performance); and Annual recurring enterprise subscription or perpetual maintenance/support fees for follow-on production and fielding across the STE program life cycle.

For the Government's preferred enterprise licensing approach; does the enterprise scope cover the STE VSW only, US

Army only, or Department of War wide?

The primary requirement and preference for this CFS is an Enterprise-wide license for the

Synthetic Training Environment (STE) / STE Virtual Software (VSW) program ecosystem. This covers all planned STE nodes, RVCT suites, S/SVT platforms, installations, home stations, and deployed Points of Need (PoN) without per-seat, per-core, or per-installation scaling surcharges. Offerors are welcome to include optional pricing for broader Department of the

Army Enterprise licensing within Volume IV, but the baseline evaluation will focus on the STE

VSW program-wide enterprise scope.

Of the 19 ground and air platforms currently simulated, which are required for STE VSW? All currently fielded platforms are ultimately required over the life of the program; however, integration will be prioritized and executed incrementally. Specific platform implementation schedules will be refined collaboratively as user requirements and capability drops are finalized.

For the initial CFS submission and baseline evaluation, offerors should focus their primary technical approach and architectures on fulfilling the Four Core Operational Priority Capabilities

(specifically achieving a certifiable Table II virtual collective gate to live fire for mounted maneuver, a true combined arms environment with integrated fires and terrain shaping, mounted mission command concurrency, and open modular SDK/API architectures.

If an Offeror is selected to demonstrate capabilities across multiple Lots, may those demonstrations be consolidated into a single extended Demonstration Pitch, or will separate sessions be required for each Lot?

Yes, the Government will permit consolidated demonstrations. If an offeror is down-selected to participate in Phase 2 across multiple Lots, the Government will allow the offeror to present their capabilities within a single, coordinated, and extended Demonstration Pitch session. The offeror will be responsible for clearly structuring their presentation agenda to address the distinct technical criteria and functional demonstrations required for each respective Lot.

Please clarify whether Offerors should include costs associated with participation in the 90-day Lot 1 competitive sandbox in their proposed pricing. If so, should those costs be separately identified, and what Government-furnished facilities, equipment, infrastructure, licenses, or other resources will be provided during the sandbox?

Costing: Yes. Lot 1 Offerors must include the labor and engineering costs for participating in the 90-day Phase 4 Sandbox within their Volume IV ROM, explicitly broken out under

Milestones 1.1 through 1.4. Government-Furnished Resources (GFE/GFI): The Government

(via Lots 3 and 5) will provide: - Access to the physical and virtual Software Integration Lab

(SIL); - RVCT physical crew station hardware modules (GFE); - The TSS GFI source code baseline and HAPI specifications; - SIL server infrastructure, enterprise message bus, and automated CTS testing harness. Offerors are responsible for providing their own core software licenses, developer workstations, and engineering personnel.

For Lot 3 ROM pricing associated with physical fielding, installation, calibration, and integration at fielded training sites, will the Government provide an assumed number and type of RVCT devices, locations, and fielding events to establish a common pricing basis?

The government does not anticipate these activities to be within the scope for Lot 3. Please disregard this bullet as it pertains to Lot 3 ROM pricing as it will be removed in the final CFS posting.

16 All

17 Section 6

18 Section 6

19 Section 6

20 Section 5

Regarding anonymity, do Offeror's product names and fielded capabilities need to be excluded? Proprietary & Restrictive Markings: Standard proprietary notices and restrictive legends are permitted on headers/footers, provided they are genericized and do not contain the company name, entity CAGE code, or corporate logos. Commercial Product Names: If a commercial product brand name is uniquely owned by and identifiable to the submitting offeror (such that mentioning it directly reveals the offeror’s corporate identity), it must be genericized in Volume

II (e.g., referred to as "Offeror’s Core Simulation Engine" or "Offeror’s AAR Analytics Tool").

Industry-standard open commercial software, third-party COTS, or third-party engines referenced for integration purposes (e.g., Unreal Engine, Unity, Kafka, gRPC, Cesium) may be named, provided their use does not disclose the offeror's identity.

Section 6 (Solution Brief Submission Requirements) states that Volume II must be submitted anonymously and that

'company name, logos, identifying marks, or names of key personnel' should not appear anywhere in the submission.

Will the Government please clarify if the prohibition of identifying marks extends to proprietary markings on documents or specific commercial product names being called out?

Proprietary & Restrictive Markings: Standard proprietary notices and restrictive legends are permitted on headers/footers, provided they are genericized and do not contain the company name, entity CAGE code, or corporate logos.Commercial Product Names: If a commercial product brand name is uniquely owned by and identifiable to the submitting offeror (such that mentioning it directly reveals the offeror’s corporate identity), it must be genericized in Volume

II (e.g., referred to as "Offeror’s Core Simulation Engine" or "Offeror’s AAR Analytics Tool").

Industry-standard open commercial software, third-party COTS, or third-party engines referenced for integration purposes (e.g., Unreal Engine, Unity, Kafka, gRPC, Cesium) may be named, provided their use does not disclose the offeror's identity.

Section 6 (Solution Brief Submission Requirements) for Volume III requires a direct URL to a 'live, public-facing portal...

containing the offeror’s existing API documentation and/or SDK.' Will the Government please confirm if a portal accessible to the public, but requiring standard user registration and password protection, meets the definition of 'public-facing' for this requirement?

Yes, conditionally. A public portal that requires standard, immediate, self-service user registration and password authentication is acceptable, provided that: 1.Registration is free, immediate, and does not require manual administrator vetting or approval delays that would hinder Government evaluators. 2.Alternatively, the offeror may provide direct guest/evaluation login credentials in Volume I (Administrative & Compliance) so evaluators have unimpeded, immediate access to Volume III artifacts without delay.

Does the Government consider a parent company and a wholly-owned subsidiary to be the same, or separate entities? For the purposes of the Lot 5 OCI Firewall, the Government considers a parent company, its wholly-owned subsidiaries, business units, and corporate affiliates to be part of the same organizational entity under FAR Subpart 9.5. Due to the inherent Impaired Objectivity conflict arising from Lot 5's role in operating the Conformance Test Suite (CTS) and certifying software compliance, an offeror and its corporate affiliates are strictly prohibited from performing Lot 5 if the offeror or any of its affiliates perform on Lots 1, 2, or 4. The government will ensure clarity in the final CFS.

Regarding the "Associate Contractor Agreement (ACA)" anticipated under Section 5, can the Government please provide additional context on this requirement. Specifically, is the expectation that each of the awardees will execute an

ACA with each other? Additionally, given the Government intends to "approve" the ACA, can the Government please provide Offerors with anticipated approval criteria, a draft or model ACA, or other information to inform this requirement so that Offerors can both understand the expectations while ensuring protection of proprietary and sensitive information.

Execution Expectation: Yes. All awardees across Lots 1 through 5 are required to execute bilateral or multilateral ACAs within 30 days of award to govern inter-vendor cooperation, data sharing, SDK/API exchange, and Software Integration Lab (SIL) troubleshooting without government cost escalation. Government Approval Criteria: The Government’s review and approval of the ACAs will focus on ensuring: 1.No artificial barriers or proprietary restrictions are placed on required system APIs, SDK distribution, or SIL telemetry. 2.Clear protection mechanisms for background intellectual property and trade secrets among competing contractors. 3. Defined escalation and dispute-resolution timelines to prevent schedule impacts to the 90-day Sandbox and system integration milestones. The Government intends to provide a standard model ACA template (incorporating standard DFARS/AFARS ACA provisions) to all awardees upon selection to streamline execution.

21 Volume 4

22 Lot 2

23 All

24 All

Specifically, may a small business/nontraditional subcontractor provide engineering support, such as cloud engineering, data engineering, and/or data analytics, to one prime supporting Lots 1, 2, and/or 4, while also providing engineering support to a different prime on Lot 5? In this scenario, the subcontractor would not be providing or owning the software being evaluated by Lot 5. If this type of participation is permitted, are there any Organizational Conflict of Interest (OCI) restrictions, limitations, or mitigation requirements the Government intends to apply to subcontractors supporting multiple Lots?

Teaming Across Lots 1 through 4: Cross-lot teaming, partnerships, and multi-lot subcontractor participation across Lots 1, 2, 3, and 4 are greatly encouraged. The Government actively promotes collaboration among commercial vendors, small businesses, and nontraditional defense contractors to assemble "best-of-breed" software and training capability solutions.

Subcontractors may support multiple primes across Lots 1–4 without restriction, provided standard proprietary data-protection and NDA practices are maintained. Lot 5 Clean Separation

Rule: To keep governance simple, transparent, and completely objective, a strict structural separation applies to Lot 5. Because Lot 5 operates the Software Integration Lab (SIL), executes the automated Conformance Test Suite (CTS), and provides the objective data used for Government milestone acceptance, any company or subcontractor performing on Lot 5 cannot participate in any capacity (as a prime, subcontractor, or technical advisor) on Lots 1, 2, or 4. Bottom Line: Industry partners are encouraged to freely team across the developments lots (Lots1-4). However, any entity providing support to Lot 5 must remain entirely independent of the Lots 1,2, and 4.

Please clarify when and how the Government intends to provide Offerors with access to the current TSS baseline source code, associated technical documentation, SDKs/APIs, and other applicable Government Furnished Information

(GFI). Will access to the TSS baseline/GFI be provided to qualified Offerors prior to solution submission and/or demonstrations, and will authorized subcontractors/team members supporting an Offeror also be permitted access?

Yes. To enable offerors to formulate credible, technically grounded proposals (particularly for

Path A GOTS and Path C Hybrid approaches), the Government will make the current TSS technical baseline, documentation, and interface specifications available prior to the Phase 1

Solution Brief submission deadline. Authorized U.S. subcontractors and teaming partners supporting an Offeror are permitted access, provided the prime Offeror formally notifies the

Program Office of the name, address, and designated POC of each subcontractor, and ensures that all subcontractor personnel are briefed on and adhere to all terms of the

Distribution Agreement (to be posted). Detailed instructions will be officially posted as an attachment to the CFS on SAM.gov. Offerors must email their completed, signed Distribution

Agreement to the Contracting/Agreements Officers. Physical Storage Media Requirement: Due to the large size of the complete TSS software repository, terrain data, and IDE assets, electronic transfer is not supported. Offerors must provide their own external storage media

(external SSD/HDD, minimum 8 TB capacity). Media Delivery & Pickup: Local Vendors

(Orlando, FL area): May coordinate drop-off and pickup of their storage device at the designated Government facility in Orlando. Non-Local Vendors: May ship their storage device along with a pre-paid, tracked return shipping label to the address provided upon verification of credentials.

Volume IV (Rough Order of Magnitude (ROM) and Licensing Model) states that the Government prefers a flat, Enterprise-wide licensing model. Will the Government confirm if this is assumed to be VSW-wide or Army-wide?

The primary requirement and preference for this CFS is an Enterprise-wide license for the

Synthetic Training Environment (STE) / STE Virtual Software (VSW) program ecosystem. This covers all planned STE nodes, RVCT suites, S/SVT platforms, installations, home stations, and deployed Points of Need (PoN) without per-seat, per-core, or per-installation scaling surcharges. Offerors are welcome to include optional pricing for broader Department of the

Army Enterprise licensing within Volume IV, but the baseline evaluation will focus on the STE

VSW program-wide enterprise scope.

Regarding Lot 2, Volume 2: Can we assume that a separate 5-page narrative is to be submitted for each component included in the submission?

Yes. Because Lot 2 (Simulation Application Software) functions as an open "app marketplace" where vendors may propose one or multiple discrete, specialized software modules (e.g., Table

II Precision Gunnery module, s-UAS flight physics plugin, Mounted Mission Command module), offerors may submit a separate, standalone 5-page Volume II Technical Concept narrative for each distinct specialized software application/module offered.Each module will be evaluated independently on its own technical merits.

25 All

26 Lot 2/ 4

27 All

28 All

29 All

30 Lot 2/ 4

31 Lot 2

32 All

33 Demo

34 ID

35 Lot 4

For the Phase 2 demonstration, is there a max number of offeror personnel that can participate in the demonstrations, either at the Government location or virtually?

There is no strict cap on in-person or virtual attendees for demonstrations, however, to ensure smooth flow of demonstrations, offerors should limit attendees to those personnel that are essential to the facilitation of the demonstration

For the Industry Day one-on-ones, is there a limit to the number of offeror personnel that can attend in person? Yes. To maintain effective, focused discussions and adhere to conference breakout room capacities, each company/consortium team is limited to three (3) in-person representatives during scheduled One-on-One sessions.

For Lot 4, please provide or identify the anticipated message-bus event schemas, peak event rates, latency targets, concurrent exercise volumes, data-retention requirements, and sample AAR outputs that vendors should use to size and demonstrate their solutions.

Additional information will be provided upon conclusion of the Lot 1 competitive sandbox and subsequent final Lot 1 award. THis will inform the SKD/API standards that the Lots 2 and 4 providers will adhere to. Lots 2 and 4 awards will be extended/delayed for this dependency. In the meantime, reference Attachment A to the CFS for the operational requirements of the system

Will the Government please clarify whether cover pages, tables of contents (if included), and acronym lists count towards the specified page limit for each volume?

These items do not count towards page limits

Will the Government consider allowing offerors to submit the required video for Vol III Product Demonstration

Artifacts via a secure method instead of a non-password protected link? We have video that clearly illustrates

TRL 8/9 with working, fielded software, but the videos are not approved for public release.

Yes this method will be accepted

Will the Government confirm if the GFI to be provided as part of the CFS will include geospatial data products for areas of interest (e.g., OWT source data, runtime outputs)?

Yes. The TSS GFI baseline distribution (provided on the 8TB external drive upon approval of the Distribution Agreement) includes sample One World Terrain (OWT) 3D Tiles, elevation datasets, vector features, and representative operational training geographic areas of interest

(AOIs)

Given the Government’s recent guidance regarding the submission of separate Technical Volumes for discrete software modules, combined with the refined phased award structure and the anticipated timeline dependencies (specifically the sequential award of Lot 1 prior to Lot 2 and the subsequent availability of the

SDK and the referenced "Deferred Solicitations/Awards (Lots 2 and 4)"), can we assume that the government is providing an extension for the Lot 2 submission deadline? We request this clarification to ensure that offerors have sufficient time to develop fully compliant, high-quality technical narratives for each distinct application module.

Yes, there will be an extensionfor the Lots 2 and 4 deadline. More details to follow in the final

CFS posting.

The Government's response to question 7 in the Q & A released on 1 September stated, "The Government intends to provide a standard model ACA template (incorporating standard DFARS/AFARS ACA provisions) to all awardees upon selection to streamline execution." Please consider providing a copy of the model ACA to offerors before proposal submission. The nature of the agreement, as well as any IP costs and associated risks, will inevitably have an impact on proposal approach and pricing. Furthermore, due to the short-turn negotiation anticipated (30 days), this will help ensure offerors are best able to align with the Government's timeline."

The ACA will be posted as an attachment

The updated timeline released on Friday, 4 September via sam.gov still indicates that Lots 2 & 4 submission will be at the same time as Lot 1, 3, & 5. Should we expect that submission of those Lots will shift later, or will they remain simultaneous to Lot 1, 3, & 5 submission?

The formal submission deadline for Lot 2 and Lot 4 will shift later.

For Lot 2, is the Government only interested in software solutions or would the Government accept Lot 2 submissions for a software and hardware solution (HIL)

The Government will only consider software solutions for this effort at this time.

For the 5-page Volume II Anonymous Technical Concept, will the Government allow architectural diagrams to be included as an attachment that does not count against the 5-page limit? This would allow offerors to provide the detail requested in the response.

Architectural diagrams may be included as an attachment that does not count against the 5 page limit. If the Government, in its sole discretion, determines that an offeror has utilized this diagram exemption to circumvent the established page limits by embedding excessive narrative text, the narrative text will be disregarded. Narrative text on diagram pages must be limited to labels and callouts.

36 Lot 4

37 Lot 4

38 Lot 4

39 Lot 4

41 All

42 All

43 Lot 1/2//4

44 SAM

If names of products “are” allowed, is it allowed to mention if the offeror is the developer of the products? It seems difficult to avoid mentioning this without leaving out a potentially significant technical discriminator that the Government might want to consider (i.e., that the offeror could steer the product roadmap and after the product codebase to specially meet program requirements).

Given that companies can always find ways of conveying what products they are using without actually naming them (e.g. “the engine that was used in the Games for Training Program”), would the Government consider dropping the anonymity require – al least for Lots 1, 2, and 4 when product / technology discriminators are important to the Government evaluation?

I am looking for the posted Characteristic of Need (CoN) for Virtual Software (former VCTS) but I do not see it linked here any longer: SAM.gov

Please note, the STE VSW effort was previously titled, "STE VCTS" but has since been revised to "STE VSW" The previous name was already a title assigned to another effort, which required rebranding of the project name.

Please define the minimum Government rights and ACA sharing requirements applicable to Lot 4 source code, proprietary platform components, connectors, SDKs, API documentation, and interface-control documents, including whether a vendor may retain ownership of its commercial core platform while granting ecosystem participants access only to documented interfaces.

Commercial Core IP Retention: Yes. Commercial vendors retain full ownership and proprietary data rights to their underlying, commercial core analytics software engines.

Mandatory Government Rights: The Government requires Government Purpose Rights (GPR) or Unlimited Rights for all custom-developed integration code, API schemas, connectors, and

Interface Control Documents (ICDs) developed under this effort.

ACA Interface Sharing: Under the Associate Contractor Agreement (ACA), vendors are required to share only documented APIs, SDK stubs, data schemas, and interface definitions with ecosystem participants—not proprietary internal source code.

Section 6.1 indicates that Volume II cannot mention the offeror’s company name or include any of the offeror’s logos; it can be difficult to effectively describe a technical solution without being able to name the components and modules. Does that mean the offers also must avoid mentioning names of any COTS products they might be using (e.g., VBS, Unreal, VR-Forces, Cesium, MASSV, etc.) as that might give away the offeror’s identity?

If so, could this place COTS providers at a disadvantage?

If COTS products names cannot be mentioned, does that restriction apply to GOTS products as well (e.g., OneSAF, AFSIM, etc.)? If not, the rule would seem to disadvantage companies using COTS solutions.

Please confirm the anticipated classification, CUI handling requirements, DoD impact level, RMF control baseline, and deployment environments for Lot 4, including whether operation is required at disconnected or intermittently connected field sites and whether any FedRAMP or DoD provisional authorization must exist at submission.

CUI at this present time. Existing FedRAMP High or DoD IL4/IL5 Provisional Authorizations

(PA) for cloud components are highly favorable but not mandatory at initial submission, provided the offeror demonstrates containerized STIG compliance and security control inheritance within the Lot 5 DevSecOps pipeline. More information will be provided upon the award of Lot 1 and Lot 5

For Lot 4, may the TRL 8/9 and recent/relevant-experience requirements be satisfied by a fielded commercial training analytics or AAR platform deployed outside the Army LVC environment, provided that the vendor demonstrates mature

APIs and a credible integration path to the Government-approved SDK?

Yes. TRL 8/9 and past experience requirements may be satisfied by mature, operational commercial platforms deployed in non-defense sectors (e.g., civil aviation, commercial esports/gaming analytics, enterprise telemetry analytics), provided the offeror provides verifiable proof of live deployment, mature pub-sub APIs, and a credible path to ingesting military simulation telemetry.

Please provide the anticipated period of performance and planning quantities for Lot 4, including installations, physical nodes, environments, instructors, concurrent users, and support hours, and confirm whether enterprise subscription and perpetual-license approaches will be compared on total evaluated cost over the same period.

There are 22 planned fielded sites for RVCT, that at the most, must be capable of running simultaneous operations up to Battalion-level scale. The Government will consider/compare the perpetual vs enterprise license approach.

Mentioning COTS/GOTS Names: Permitted for integration context. Offerors may reference standard industry technologies, commercial tools, and GOTS baselines (e.g., “utilizes Unreal

Engine,” “connects to OneSAF,” “implements Kafka streaming”) to explain technical architecture and interoperability.

Developer Status & Discriminators: In Volume II, offerors must NOT state "we are the creator/owner of Product X" or include corporate marketing claims that explicitly identify the bidding company. Offerors can fully articulate their technical agility, source-code access, and roadmap velocity functionally (e.g., "The proposed engineering team maintains full architectural control and direct codebase modification authority over the core engine").

Retaining Anonymous Volume II: The Government will NOT drop the anonymity requirement for

Volume II. Blind reviews are a core principle of the Army Open Solicitation (AOS) framework to ensure an objective, merit-based technical evaluation.

45 All

46 Lot 2

48 Lot 2/4

49 Lot 2

52 Section 6;

Section 7

Where are the ACA LOI, GFI request, and software list forms? The STE VSW sam.gov posting will include Att 04 ACA LOI, 06 STE-IS SDA and 06a TSS-

TMT GFI available for review and submission POCs.

Section 3 requires mature, fielded products at the time of solution submission. For Lots 2 and 4, will software that is fielded and operational with commercial or non-defense customers satisfy the TRL 8/9 requirement, or must the offeror demonstrate fielding in a Government or defense training context?

Yes, commercial/non-defense fielding fully satisfies the TRL 8/9 requirement. In alignment with

Commercial Solutions Opening (CSO) authorities (DFARS 212.70), mature commercial gaming, physics simulation, autonomous vehicle simulation, or data analytics platforms fielded in the private commercial sector meet the entry threshold, provided they can be integrated via the Government-approved SDK.

The Lot 1 platform and its Government-approved SDK will not have been selected at the time Lot 2 solution briefs are due. For a Lot 2 application that is engine-native today, will the effort of re-targeting it to the selected

Lot 1 SDK be treated as minor configuration and integration, or as software development that renders the solution non-compliant under Section 3?

Re-targeting an existing, mature application to the new Lot 1 SDK/API is considered standard integration and configuration, NOT new software development. Section 3's technological maturity restriction is intended to prohibit offerors from submitting conceptual, unbuilt software that requires ground-up development. If the underlying core algorithms, flight/vehicle physics, or fire-control logic are already built and proven (TRL 8/9), the engineering effort required to adapt those capabilities to the standardized Lot 1 SDK/APIs is expected and fully compliant.

Volume II must contain no company names, logos, identifying marks, or names of key personnel. Where an offeror’s solution incorporates a component or capability provided by a named teammate, how should that relationship be described in Volume II without breaching the anonymity requirement, and should the teammate’s fielded product and past performance be carried in the offeror’s Volume I and Volume V?

Reference previous questions regarding Volume II Anonymity. That has been answered at length.

Section 5 states the Government will establish a basket of vendors identified as having developed highly qualified solutions for potential future selection. What are the criteria for inclusion in that basket, how will vendors be notified, and can a company be considered for it without submitting a Solution Brief against a specific Lot under this Call?

The basket of vendors option will be clarified in the FINAL CFS posting. The following is the intended language to be identiied in the FINAL STE VSW CFS, Section 5, "The Government will also establish a basket of vendors that have been identified to have developed solutions of techincal merit but were not invited to Phase II. These vendors may be selected to be retained in a basket for up to twenty-four (24) months from notice for potential future selection during the performance of any of the identified Lots. Please note, Lot 2 will remain open for on boarding opportunities throughout the performance of Lot 2. Additional opportunities will be identified at various times of the year." and Section 7.2, " Based on the evaluated sections, the Solution submission will be categorized as Selected for Further Consideration or Not Selected for

Further Consideration. Those selected to have technical merit but not selected for further consideration may be selected for basket consideration for up to twenty-four (24) months."

Lot 2 is described as remaining open for the life of the project, with subsequent competitive awards for new applications. What is the mechanism and expected cadence for submitting a Lot 2 application after the 21

September 2026 suspense, and will those submissions be made under this Call or under a separate future announcement?

Following the baseline Lot 1 award and release of the standardized Lot 1 SDK (approx. Month

4–5), the Government will publish a Lot 2 Application Catalog & Call Notice. From that point forward, Lot 2 will operate on a continuous, rolling submission cadence (frequency TBD) under the AOS umbrella, enabling industry to propose specialized tactical modules, vehicle dynamics plugins, and weapon systems on an ongoing basis.

Lot 2 references future vehicle platforms and s-UAS modules, and Section 3 makes native ingest and render of One World Terrain data a non-negotiable requirement for initial system acceptance. Is the production of 3D content, including vehicle and platform models at simulation fidelity and terrain and environment authoring against the OWT pipeline, in scope for any of the five Lots, or does the Government intend to acquire that content separately?

The intent is for the Government to acquire this content from OWT, outside the scope for any of the five lots.

The CFS states that Volume IV (ROM) “will not be evaluated,” yet Section 7 identifies “Volumes II and IV” as part of the weighted evaluation factors.

Question:

Can the Government clarify whether Volume IV will be evaluated during Phase 1, and if so, which elements of

Volume IV factor into the weighted scoring?

Volume IV will not be evaluated during the Phase I down-select. Refined submission requirements and evaluation criteria will be in the final CFS posting

53 Section 6, Section 7

54 Section 3, Section 7

55 Section 6, Section 7

56 Section 12, Section 7, Section 5

58 Section 3, Section 6

Volume II is limited to a maximum of 5 pages per Lot, yet it must address architecture, modernization path, SDK/API maturity, data segregation, licensing model, and a detailed technical schedule narrative. These requirements exceed what can be reasonably captured within 5 pages.

Question:

Will the Government consider expanding the Volume II page limit or clarifying which elements are required within the 5 pages versus which may be included as appendices?

Page Limit Maintained: The 5-page limit per Lot for Volume II remains in effect (with Lot 2 permitted up to 5 pages per distinct software application/module offered).

Content Focus: Volume II is intended as a high-impact, executive technical summary. Offerors should focus the 5 pages on their Modernization Path, core architectural diagram, and technical approach to meeting the core Operational Priorities.

Relief / Appendices: Licensing terms, data rights assertions, and administrative compliance details belong in other Volumes, freeing up Volume II space exclusively for the technical narrative and embedded architectural diagrams.

Section 3 lists OWT ingestion/rendering as the requirement. However, Phase 1 evaluation (Volume I

Requirement #3) requires OGC standard compliance (WMS, WFS, 3D Tiles) as proof of OWT capability.

Question:

Is OGC standards compliance a mandatory submission requirement, or will OWT ingestion alone satisfy the

Phase 1 evaluation criteria? If OGC compliance is mandatory, will the Government update Section 3 to reflect this?

OWT ingestion alone will satisfy the Phase 1 Criteria. The Government will clarify in the final

CFS posting

Volume III is described as the “primary technical validation” for Lots 1, 2, and 4, but Section 7 does not specify if or how Volume III factors into weighted evaluation.

Question:

Can the Government clarify whether Volume III will be scored in Phase 1, and if so, what specific evaluation criteria apply to the demo and API/SDK documentation?

The Government intends to refine the final CFS to utilize the Volume III artifacts as an objective

Pass/Fail (Go/No-Go) technical readiness gate to verify "Proof of Commercial Maturity" (TRL

8/9) and "Integration Readiness." Because Volume III serves to validate that working, fielded software actually exists rather than being subjectively scored.

Section 12 requires an OCI analysis for all offerors, but the evaluation criteria do not specify how OCI compliance affects scoring. Given the strict Lot 5 firewall restrictions, this may affect eligibility.

Question:

Will OCI findings or mitigation plans be evaluated as part of Phase 1 scoring, or are they treated solely as pass/fail compliance checks?

The Government will refine the OCI requirements as pass/fail and will not be a part of scoring.

The intent of the OCI is to cover the Lot 5 firewall.

If a company is awarded Lot 5, are they precluded from providing support on Lots 1, 2 and 4? Yes.

Requirement (Section 3) Technological Maturity (TRL 8/9):

All submitted solutions must be mature, fielded products (TRL 8/9). No major development or re‑architecting allowed.

Discrepancy:

Section 6 requires Lot 1 to declare a modernization path (GOTS, COTS, Hybrid), each of which involves modifying or enhancing the TSS baseline—work that is contradictory to the TRL 8/9 restriction.

Questions:

Will the government please define no major development.

Does the solution have to include the existing TSS/TMT software?

What is the current TRL for TSS?

The government understands that a path may require integration and minor configuration. The underlying foundational simulation software engine, rendering pipeline, physics models, or analytics architectures must already exist, be fielded, and be operational (TRL 8/9). The

Government is funding integration, API adaptation, HAPI mapping, and configuration—not the ground-up development of a new, unproven simulation engine.

Offerors may propose Path A (GOTS enhancement), Path B (complete COTS replacement), or

Path C (Hybrid). Solutions are not required to incorporate the existing TSS/TMT baseline.

TSS is an actual system proven through successful mission operations, so a TRL 9 is appropriate.

59 Section 1;

Section 6, Section 3

60 Section 7, Section 3

61 Section 6

62 Lot I

Requirement (Section 1) 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.”

Discrepancy:

Section 6 allows vendors to provide a future roadmap instead of a working scripting environment, while

Section 3 requires all major components to be mature at submission.

Questions:

Can the government please clarify the discrepancies between the three Sections.

Is the user scripting environment part of the TRL 8/9 maturity requirement?

The Government will refine the language regarding "Power Users"

There is no discrepancy. A mature solution can still plan and provide for future enhancement to meet future requirements.

The scripting environment is a "Government desire", not a pass fail requirement. Per the CFS:

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

Requirement (Section 7):

Speed to IOC is the highest‑weighted evaluation factor.

Discrepancy:

Section 3 prohibits major development, but achieving aggressive IOC timelines may require development work beyond “minor configuration.”

Questions:

If accelerated IOC requires development beyond minor configuration, does this violate TRL requirements?

Are vendors expected to propose additional development work to meet aggressive schedules, or strictly limit efforts to integration?

There is no discrepancy.

Per the CFS: "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."

Requirement (Section 6):

Volume II must be completely anonymous and contain no content revealing vendor identity.

Discrepancy:

Modernization path declarations (GOTS, COTS, Hybrid) and architecture diagrams may inherently reveal identity (e.g., vendors known for specific COTS engines).

Questions:

Should vendors avoid naming specific engines/products in Volume II even if required for architecture clarity?

How will the Government enforce unbiased evaluation if modernization path inherently reveals the vendor?

Reference previous questions regarding Volume II Anonymity. That has been answered at length.

We are currently reviewing the STE VSW Call for Solutions (STE-VSW-26-0006) and the newly released

Attachments 06 and 06a.

We would appreciate clarification regarding access to the TSS/TMT Government Furnished Information for

Lot 1.

RAMROD XR is an international organization with both a U.S. entity and a German development organization.

For a Lot 1 offeror requiring access to the TSS/TMT GFI identified in Attachment 06a, are foreign-owned or affiliated offerors eligible to participate in the Lot 1 competitive sandbox?

If so, could you please clarify what foreign disclosure, FOCI mitigation, TAA, or other approvals would be required for non-U.S. development personnel to support the effort and access the required GFI?

This clarification would help us determine the appropriate organizational structure for a potential Lot 1 submission.

Foreign-owned or affiliated offerors are not eligible to participate in the Lot 1 competitive sandbox. RVCT is a CUI/NOFORN system and not approved for foreign disclosure at this time.

63 GFI

64 One-on-One's

65 Lot 4 —

Scope and

Requirements

66 Lot 4 —

Scope and

Requirements

67 Section 3

68 Eligibility and

Teaming

69 Lot 4

70 Eligibility and

Teaming

71 Administrative

72 Lot 1

73 All

Any analytics are limited to real-time event data from the system message bus.

Q&A response 6 confirms Lot 4 subscribes to the Lot 5 System Message Bus rather than the Lot 1 data fabric.

Does the 50,000-entity throughput figure in the Lot 4 criteria describe the bus's aggregate capacity, or a throughput each Lot 4 tool must independently sustain?

The 50,000+ active entity count describes the throughput for After Action Review of each independent training exercise. It is not the aggregate of all entities for a site.

Regarding Lot 1, If the Government determines that only one complete and compliant capability exists in an offeror's response as demonstrated in Phases 1, 2, and 3, will you consider removing the Phase 4: Lot I

Competitive Table II STX-V…