STE VSW CFS Q_A Vendor 09.02.26.pdf

LOT

3 LOT 1

4 All

2 Pending Response

STE VSW Call for Solution Q&A 09.02.26 Vendor

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.

Questions Responses

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?

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

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.

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.

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.

5 All

6 Lot 4

7 Lot 3

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

Is it the Government's intent that Product Demonstration Videos and the live API/SKI Documentation are anonymous? 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.

9 All

10 Lot 1

11 Lot 3

12 Lot 1/2/3/4

13 Lot 1/2/3/4

14 All

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

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

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.

15 All

16 All

17 Section 6

18 Section 6

19 Section 6

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.

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 proposing on or performing Lot 5 if the offeror or any of its affiliates propose on or perform Lots 1, 2, or 4. The government will ensure clarity in the final CFS.

20 Section 5

21 Volume 4

22 Lot 2

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.

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.