PM C2 Apps RFI QA.xlsx
XLSX spreadsheet 38 KB Posted
- Solicitation number
- C2APPSRFI-1
About this file
This file is a Questions and Answers (Q&A) matrix documenting industry feedback and Government responses to a Request for Information (RFI) concerning the PM C2 Apps acquisition strategy.
The Government is pursuing a consolidated acquisition model under a singular lead entity to manage the PM C2 Apps portfolio, including a unified DevSecOps pipeline and application storefront that integrates Government-Off-The-Shelf (GOTS), Commercial-Off-The-Shelf (COTS), and tactical applications. The storefront will operate as a centralized control plane enabling warfighters to discover and deploy applications across multiple classification levels (UNCLAS through TS/SCI/JWICS), with initial operating capability (IOC) proposed at IL5 and growth path to IL6. Key technical requirements include support for heterogeneous endpoints (Windows, Linux, Android, iOS, macOS), continuous integration/continuous deployment (CI/CD) pipeline capabilities, automated security scanning (SAST/DAST), containerization and orchestration, disconnected/degraded operations (DDIL), and integration with NGC2 ecosystem components including data fabric/mesh architectures. The Government has not mandated specific tools, frameworks, cloud providers, compute orchestration platforms, hardware baselines, or pricing models; respondents must propose solutions aligned with DoD Enterprise DevSecOps Reference Design standards and state explicit assumptions regarding user scale, application counts, infrastructure costs, and lifecycle timelines. Responses are limited to 25 pages (Microsoft Word .docx format, 11-point font) and must include a Rough Order of Magnitude (ROM) with detailed cost breakdowns, notional schedules, and DevSecOps pipeline descriptions. The Government anticipates pursuing this effort through the Army Open Solicitation (AOS) in Q3 FY2026 and welcomes industry recommendations on architectural approaches, governance models, licensing strategies, accreditation inheritance mechanisms, and organizational structures for managing lead-vendor responsibilities, third-party application onboarding, and potential conflicts of interest.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Industry Day Recording Link.docx | DOCX document | |
| PM C2 Apps Industry Day QA.pdf | ||
| Attachment 1_Response Form 1-.docx | DOCX document | |
| THE FULL RFI TEXT AND ADDITIONAL SECTIONS.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Comment Matrix_Actual
| Row | RFI Question/Comment/Feedback | Government Response |
| N/A | We are an application in the NGC2 application layer already, should we respond to the RFI still? If so, what information are you looking for as an application beyond modularity? | Yes. All industry parterns are welcome to respond, including current NGC2 partners, and should be IAW Section 3 Response Form. Feel free to include any information to support your solution within the mandatory page limits. |
| N/A | What is the Army's definition for the term "data layer?" |
| It is used a number of times but believe the term can be quite ambiguous, even when set within an NGC2 context. | The data layer is part of the NGC2 full stack ecosystem and will integrate sensor and platform inputs, aggregating multiple sources of data to inform a unified operational picture. | |
| N/A | How is the government envisioning a single storefront operator having direct control over an interoperable suite of applications? |
| The open paragraph states, "the Government is particularly interested in solutions offered by entities with direct control over the capability development and innovation." If the goal is interoperability, by definition these applications come from different vendors/OEMs/ISVs which means one entity would not have direct control over all of their capability development and innovation cycle. Hoping you can clarify how and why you're particularly interested in this and why. | The Storefront is envisioned as the single source of truth and a centralized control plane, enabling end-users to seamlessly discover and deploy applications tailored to specific warfighter functions. While full application-to-application interoperability is not the primary focus, the Government prioritizes functional performance, plug and play ability, along with robust data layer integration to ensure applications can securely push and pull information as required by the mission. | ||
| N/A | Since inclusion of the Response Form questions would consume approximately 6-pages of the 25 page response limit, is it acceptable for offerors to omit the full question text and provide responses organized by question row number only? | Please leave the full question text in the document. | |
| N/A | Since inclusion of the Response Form questions would consume approximately 6-pages of the 25 page response limit, is it acceptable for offerors to omit the full question text and provide responses organized by question row number only? | Please leave the full question text in the document. | |
| 37 | Will the government accept a solution with an existing ATO from another agency/branch of service, or is an Army-specific ATO/IATT required? | Industry partners may leverage a previous Authority to Operate (ATO) as evidence of technical readiness and maturity. However, Army ATO/IATT standards remain the governing requirement for network operations. The Government will evaluate existing ATOs for reciprocity, but all solutions must ultimately meet specific Army cybersecurity and technical controls to operate on the Army network. | |
| 21, 21a | Does the government have a preferred or mandated list of SAST/DAST tools that must be used within the DevSecOps pipeline, or is industry free to propose their own toolchain? | The Government does not mandate a specific toolchain at this time; industry is free to propose their own standard DevSecOps tools. | |
| 1b, 1c | When the RFI references a "government-provided data layer" scenario versus an "industry partner-provided data layer" scenario, is the government indicating these are two separate contract scenarios or two configurations that must simultaneously be supported? | Industry partners should describe their capability to support either scenario, as the final architecture may involve Government data, Industry partners data, or a federated mix. | |
| 8 | Is there a government-defined threshold or policy for how frequently applications within the storefront must be updated (e.g., monthly patches, quarterly releases), or is this left to the contractor's proposed cadence? | Update cadence is not currently mandated. Industry partners should propose their recommended cadence. | |
| 4a | Does the government require the storefront to function on classified networks (SIPR/JWICS) as well as unclassified (NIPR), and must it be a single unified storefront or separate instances per network classification? | Storefront functionality shall be available on Army tactical systems across both IL5 and IL6 environments. Industry parterners should propose their approach to handling multiple classifications, whether through a unified cross-domain storefront or federated instances. | |
| 14 | Will Industry be expected to manage all licensing for applications including GOTS/COTS under ELAs? | Industry partners should propose their recommended license management strategy for handling a mix of GOTS and COTS | |
| 15 | What level of license compliance reporting does the Government require? Is there an existing Army enterprise license management tool that the storefront must integrate with? | Specific reporting tools are not yet mandated. Industry partners should propose dashboards that provide real-time utilization and compliance tracking. | |
| 1, 2 & 3 | How does the Government intend to procure warfighter applications as part of NGC2, given the RFI’s references to a “singular lead” and “lead vendor” construct? | The specific procurement strategy is still under development. Industry partners should propose how a lead vendor could manage these transactions. | |
| 1 | How does the Government envision aligning the implementation of tailorable warfighting applications with existing NGC2 full-stack prototypes? | Industry partners should propose how their storefront solutions can integrate with or run alongside existing NGC2 full-stack prototypes. | |
| 1b, 4, 23, 28 & 31 | For responses involving application capabilities, should respondents assume the Government provided data layer will serve as the authoritative enterprise integration layer, or should applications also account for interoperability with external or vendor provided data environments? | Applications should ideally account for interoperability with both, but industry partners should explicitly state their integration assumptions. | |
| 1, 8, 18, 25 & 33 | What are the specifications and/or parameters that would require a tailorable warfighting application to go through the storefront for deployment to the tactical edge? | Parameters are currently being informed by market research. Industry partners should propose standard deployment specifications that work best for their solution. | |
| 2, 3, 8a, 9, & 10 | For tailorable warfighting applications onboarded into the ecosystem, what role does the Government envision for application providers in sustainment, lifecycle management, and release management activities? | Industry partners shall submit comprehensive Continuous Integration and Continuous Deployment (CI/CD) solutions that address the full lifecycle management of the application. | |
| 1, 2 & 3 | Does the Government envision onboarding multiple independently developed warfighting applications into the ecosystem concurrently, or sequencing onboarding under centralized integration oversight? | The Government is interested in industry's recommendation on whether concurrent or sequenced onboarding provides better stability and velocity. | |
| 1b | For Question 1b, should respondents interpret “a separate industry partner” as an external third-party data layer provider independent from the respondent team, or may this include a partnered capability provider within a proposed respondent team? | The reference to a 'separate industry partner' is intended to evaluate the modularity and portability of the proposed solution within the broader NGC2 ecosystem. Industry partners must demonstrate how their solution maintains functional integrity when integrated with external data application layers or when operating alongside partnered capability providers from different industry sources. | |
| 1, 2 & 5 | Does the Government envision a standardized onboarding and accreditation process for warfighting applications entering the storefront ecosystem, or will onboarding requirements vary by hosting environment and operational unit? | Industry partners should address how they would manage environment-specific variances. | |
| Section 3.4.2 ROM | Is there a specific number of users that will be supported? Also, is there a breakdown of storefront and DevSecOps users? | While specific user counts are not defined for this RFI, industry partners shall clearly document their assumed user scale within their Rough Order of Magnitude (ROM). | |
| Section 2, Background | The RFI references an initial “thin thread” consisting of a basic CI/CD pipeline and rudimentary storefront. Can the Government clarify the minimum capabilities expected in this initial thin thread versus capabilities expected in later maturity phases? | The term 'Thin Thread' denotes a Minimum Viable Product (MVP) that demonstrates an end-to-end DevSecOps Continuous Integration/Continuous Delivery (CI/CD) pipeline, successfully transitioning an application from development to production-level readiness. | |
| 1, 2 | For the proposed teaming model, does the Government envision the lead vendor being responsible for onboarding, validating, maintaining, patching, and sustaining all approved GOTS, COTS, and tactical applications after Government approval? | The Lead Concept is based on managing the integrated technical ecosystem while sustaining the App Store, pipeline and lifecycle to independently procure and deploy best-of-breed warfighter applications for each unit. | |
| 1b, 1c | Can the Government provide additional context on the expected data layer interfaces, APIs, services, or standards that storefront and pipeline solutions should assume for both Government-provided and third-party-provided data layer scenarios? | The Government has not mandated specific APIs yet. Industry partners should recommend industry-standard interfaces that works best for their solution. | |
| 17, 17a | Can the Government clarify whether vendors are expected to propose the process for moving updates from commercial/development environments into IL5/IL6 environments, or whether an existing Government-controlled process will be used? | Industry partners shall propose a detailed process for the secure transfer and synchronization of software updates from commercial development environments to IL5 and IL6 production enclaves. Responses should specifically address Cross-Domain Solution (CDS) integration, artifact signing, and automated vulnerability scanning during the transition. | |
| 18, 25 | For hybrid-cloud, on-premise, and DDIL environments, does the Government expect the storefront and pipeline to remain fully operational while disconnected, or support synchronization and update operations once connectivity is restored? | Industry partners shall describe the maximum disconnected capability of their proposed solution, including caching and post-connection synchronization. | |
| 21, 21a | Does the Government have preferred cybersecurity scanning tools, SBOM standards, vulnerability thresholds, or SAST/DAST requirements that vendors should align to? | There are no mandated tools yet. Industry partners shall align their proposed solutions with the DoD Enterprise DevSecOps Reference Design and established DoD Software Modernization standards. | |
| 22, Section 3.4.2 ROM | Can the Government provide notional assumptions for user counts, number of applications, deployment locations, and tactical nodes to support a more meaningful ROM and notional schedule response? | The Government is not providing a baseline scale at this time. | |
| 1b, 1c & Section 3.4.2 ROM | The Synopsis describes consolidating "the entire PM C2 Apps portfolio" under a singular team lead. To inform sizing, integration timelines (Rows 1b, 1c), and ROM (Section 3.4.2), please describe the current and anticipated scope of the portfolio: approximate number of applications, application categories or warfighting functions covered, and whether existing programs of record are expected to migrate into the storefront. | The exact scope of the portfolio is currently under assessment. Industry partners shall base their proposed integration timelines on a scalable, modular framework and clearly define their throughput capacity (e.g., the number of applications onboarded per month). | |
| To inform compatibility and orchestration responses, please clarify whether respondents should assume specific reference hardware profiles (e.g., CHS-class compute, current Nett Warrior / IVAS / EUD baselines, ITN family) or describe broadly across heterogeneous endpoints. | The Government is not mandating specific hardware profile at this time. Industry partners shall describe their approach to endpoint agnosticity across Army environments. Industry partners should describe compatibility broadly across heterogeneous endpoints (e.g., Android, Windows, Linux) | ||
| 28, 1b & 1c | Row 28 asks how the solution shares data through "a single source of truth data layer," while Rows 1b and 1c frame two distinct scenarios -- a Government-provided data layer and an industry-partner-provided data layer. Please clarify how respondents should reconcile these: is the "single source of truth" intended to be a single Government data layer in the end state, with multi-data-layer scenarios only relevant to integration/transition, or is the Government open to a federated multi-data-layer end state with logical single-source-of-truth semantics? | The Government is utilizing this RFI to help determine the optimal acquisition strategy. The Government is open to whichever option is a better for your solution. | |
| 31a, 32a | Rows 31a and 32a request that respondents describe "your application solutions application boundary." Please clarify whether the Government is asking respondents to describe (a) the deployment unit (e.g., container, service, monolith), (b) the security or accreditation boundary, (c) the data-ownership boundary between the application and the data layer, or (d) all of the above. | Industry partners shall incorporate any applicable element to their solution including; deployment unit, security boundary, and data-ownership boundary | |
| 4 | Row 4 asks whether the proposed solution allows "cross-platform consistency for existing, new or partnering data layers." Please clarify the dimensions of consistency the Government is interested in: API/contract consistency, data-model consistency, user-experience consistency across endpoints, or operational/observability consistency. | Industry partners should detail their technical approach for maintaining consistency across API contracts, data schemas, and operational observability. Responses should outline the governance mechanisms used to prevent fragmentation in multi-vendor data environments. | |
| N/A | Can the Government clarify if compute orchestration will be provided? | The Government has not yet determined if compute orchestration will be GFE/GFI or vendor-provided. |
Industry feedback will inform this decision. Industry partners should explicitly state their orchestration assumptions (e.g., Kubernetes, K3s) and recommend the most effective model for managing a modular ecosystem across IL5/IL6 and tactical edge environments.
1, 2, 3 The RFI repeatedly references a “singular team lead” (Synopsis; Table 1, Rows 1, 2, 3) and asks whether respondents would “onboard applications to the Government as a container and maintain them.” Please clarify:
(a) What technical and commercial authority will the lead hold over third-party application providers — specifically, can the lead reject submissions, require remediation, or set onboarding standards independent of Government direction?
(b) How is liability allocated when an onboarded third-party application fails, has a vulnerability, or causes a security incident — is the lead expected to indemnify code it did not author?
(c) How will the Government manage conflicts of interest where the lead also offers, or has commercial relationships with applications competing for storefront placement?
(d) Is the lead expected to hold sub-contracts with app providers, or will the Government hold
| separate prime relationships and task the lead solely with integration and curation? | These governance, liability, and OCI details are part of the market research. Industry partners should propose structures that mitigate risk and ensure capability delivery. | |
| 1b, 1c | The Synopsis states this effort “mirrors” the NGC2 methodology, and Rows 1b/1c distinguish between |
scenarios where the data layer is “provided by the Government” versus “a separate industry partner.”
Please clarify:
(a) Is PM C2 Apps subordinate to, peer to, or independent of the NGC2 prime contract, and is the resulting storefront/pipeline expected to operate inside, alongside, or downstream of NGC2 infrastructure?
(b) Will the lead be required to integrate with a specific NGC2-provided data fabric, or will the lead have authority to influence data-layer selection?
(c) Who owns the interface contract between the storefront/pipeline and the data layer, and what is the change-control mechanism when either side evolves?
(d) Are there existing NGC2 reference architectures, certifications, API specifications, or data schemas that respondents should assume as constraints to this response? Contractual relationships are being finalized. For this RFI, please assume:
(a) Relationship: Peer-level with NGC2; storefront operates alongside NGC2 infrastructure.
(b) Data Integration: Integration with Government-designated NGC2 layers is required; industry feedback will inform the final strategy.
(c) Ownership: The Government owns Interface Control Documents (ICDs); a Configuration Control Board (CCB) manages change control.
(d) Constraints: Base responses on MOSA, OpenAPI, and DoD DevSecOps standards.
1 The RFI references the “entire PM C2 Apps portfolio” without enumeration. Please provide, or describe how respondents may obtain:
(a) The current in-scope application list (GOTS and COTS), including current sustainers, contract vehicles, end-of-life or option dates, and deployed user/device footprints.
(b) Whether existing IATTs and ATOs are transferable to a new pipeline and authorization boundary, or whether re-accreditation is required and on what timeline. The Government is not releasing specific PM C2 Apps portfolio data during this RFI phase. Please assume the following:
(a) Scope: Assume a diverse mix of GOTS/COTS applications.
(b) Accreditation: Existing ATOs may support reciprocity, but assume transitioning applications require validation and potential re-accreditation within the new cATO boundary.
Section 3.3.ii, 8b & 22a Section 3.3.ii references existing IDIQ vehicles (DLA, CHS); Section 1.1 references the Army Open Solicitation; and Section 3.3.iv asks for Traditional vs. Non-Traditional Defense Contractor status.
Please clarify:
(a) The expected pricing construct — FFP per integration, T&M sustainment, subscription/SaaS storefront fee, per-transaction or per-app fees, or other.
(b) Rows 8b and 22a direct respondents to place pricing in “Section 3.4.10,” but only Sections
3.4.1 and 3.4.2 are defined; please confirm whether all pricing belongs in 3.4.2. The Government is utilizing this RFI to help determine the optimal acquisition strategy. Please note the following clarifications:
(a) Pricing Construct: Industry partners should propose their recommended pricing models (e.g., FFP per integration, SaaS subscription, hybrid models) that best align with their solution.
(b) Section Clarification: All pricing information should be consolidated in Section 3.4.2 14, 15, 16 & 17 Rows 14–17 describe a mixed GOTS/COTS storefront operating up to IL6, with continuous updates from commercial environments into secured environments. Please clarify the governance and security model:
(a) Who holds decision authority for admitting an application to the storefront — Government, lead, or a joint board — and what is the target SLA from submission to availability?
(b) Is the lead expected to perform independent cybersecurity scanning and remediation on third-party application code, or only validate that the third party has performed it?
(c) For IL5 and IL6 environments, will an existing accreditation boundary be inherited by onboarded apps, and what is the expected process and duration for crossing the commercial-to-IL6 boundary on each update cycle?
(d) Will the lead serve as the AO’s single interface for ATO actions across all storefront applications, or will each app provider retain that responsibility? The final governance and security models are being informed by this RFI. Please assume the following baseline:
(a) Authority: Final risk acceptance remains with the Government; Industry partners should propose an optimal target SLA.
(b) Scanning: The Lead performs independent automated scans; third-party providers remain responsible for code remediation.
(c) IL6 & Transfer: Apps inherit platform controls but require validation. Propose your technical process and duration for the commercial-to-IL6 transfer.
(d) AO Interface: The Lead serves as the primary interface for the storefront cATO and aggregates compliance artifacts across the ecosystem.
Section 3.1 Section 3.1 specifies “Microsoft Word for Office 2000 compatible format,” 11-point font, a 25-page limit and prohibits “inserted textboxes/pop-ups or internet links.” Please clarify:
(a) Is .docx acceptable, or must the file be saved in legacy .doc (Word 97–2003) format?
(b) Are embedded images, diagrams, tables, or charts permitted within the 25-page body, or are those also prohibited as “inserted” elements?
(c) Does the 25-page limit fully include the ROM (Section 3.4.2) and notional schedule, or are these treated as separate attachments? The following administrative clarifications apply to the RFI submission:
(a) File Format .docx is acceptable; however, ensure the file is saved for maximum backward compatibility.
(b) Embedded images, diagrams, tables, or charts are permitted and part of the 25 page count.
| (c) Page Limit | The 25-page limit is comprehensive and includes the ROM (Section 3.4.2) and the notional schedule. | |
| Section 1.1 | Section 1.1 states that PM C2 Apps “may pursue [solutions] through the Army Open Solicitation |
(AOS) during 3rd quarter (Q3) Fiscal Year (FY) 2026.” Q3 FY26 spans 1 April 2026 through 30 June 2026, which is largely past as of this submission. Please confirm:
(a) Is the reference to Q3 FY26 a typo for Q3 FY27 (April–June 2027)?
(b) If Q3 FY26 is correct, when in the remaining weeks of the quarter is the AOS expected to release, and is a draft solicitation planned in advance?
| (c) What is the expected response window between AOS release and proposal due date? | Data acquired via this RFI will assist the Government in assessing industry capabilities to include determining objectives for future solicitations that may arise in Q3 FY26 under the AOS. | |
| Section 2. Background | The RFI describes a “thin thread” CI/CD pipeline and storefront but does not specify what existing |
Army or DoD infrastructure the solution will inherit or be required to integrate with. Please clarify:
(a) Will Cloud One, cArmy, Platform One, Iron Bank, Repo One, Big Bang, or similar enterprise services be GFE/GFP, mandated, available optionally, or out of scope?
(b) Are DoD PKI and CAC/PIV the expected identity model, or is ICAM/SSO planned? Will the lead be required to integrate with an existing ICAM provider?
(c) What is the assumed cloud-service-provider landscape (AWS, Azure, GCP, Oracle), and are GovCloud/IL5/IL6 instances Government-furnished or contractor-provided?
(d) Are there existing PM C2 Apps DevSecOps tools, repositories, or CI/CD pipelines the lead is
| expected to take ownership of, replicate, or replace? | (a-d) The Government has not mandated specific enterprise services yet. Industry partners should propose integration with whichever option works best with your solution | |
| Section 3.4.2 ROM | Section 3.4.2 requests a ROM “including a breakout of anticipated licensing models, non-recurring |
and recurring integration hours, cybersecurity hours, training tool development, and sustainment,” but provides no baseline. Please clarify:
(a) Should the ROM cover the initial period of performance only, a 5-year lifecycle, or full program lifecycle?
(b) What user population and application count should respondents assume for the ROM?
(c) Should the ROM assume contractor-provided cloud and infrastructure?
(d) Should the ROM include a separate breakout for ATO/accreditation hours, or are those folded into “cybersecurity hours”? The Government is using this RFI to inform the program's final lifecycle and scale. Please use the following assumptions for your ROM:
(a) Timeline: Provide your solution's full program life cycle.
(b) Scale: Industry partners must explicitly state their own assumptions for user and application counts.
(c) Infrastructure: The ROM should include any cost to get to your solution.
(d) Categorization: cATO and accreditation hours should be included within cybersecurity hours.
| 4a, 26 | Row 4a includes Windows, MacOS, Linux, and Android vs. row 26 mentions Windows, iOS, Linux, and Android. Could the government please clarify expected target platforms? | There are no expected target platforms at this time. Target platforms identified in 4a and 26 of the RFI were stated as examples, please include what works best for your solution. |
| General, full RFI | Does this requirement include/require a public-private partnership with CECOM ASIC? | Formal industry partnerships are not mandated for this RFI. Industry partners may propose them if it adds value to your solution. |
| General, full RFI | Is there an expected user scale for the initial storefront (thousands, tens of thousands, etc.)? | The Government is not providing a baseline scale at this time. Industry partners shall state their own assumptions within their Rough Order of Magnitude (ROM). |
| 1, 1a, 2 & 35 | Does NGC2 expect respondents to provide the actual storefront/catalog capability, integrate with a Government-designated storefront, or propose either approach? | The Government is seeking industry recommendations for the most effective storefront/catalog implementation. |
At this phase of market research, the Government is open to all approaches.
| 1b, 1c, 4, 28, 31, & 32 | Should the data layer be provided by the respondent, provided by the Government, provided by another industry partner, or simply integrated with through governed access patterns? | The RFI seeks flexible solutions capable of any of these data layer scenarios; whichever is the best fit for your solution. |
| 4a, 26, 26a, & 33 | What application types should respondents assume: web, mobile, desktop, containerized services, tactical-edge applications, or all of the above? | Industry parterners should use whichever application type is best fit for your solution |
| 2, 8, 8a, 9, 21 & 33 | What does “onboard applications to the Government as a container and maintain them” mean in practice? | This involves managing the DevSecOps pipeline to: |
Ingest & Containerize: Package third-party code or artifacts into portable containers.
Vet: Perform automated security scans (SAST/DAST) to meet cATO requirements.
Publish: Deliver hardened containers to the Government registry/storefront.
Maintain: Manage vulnerability remediation and continuous updates throughout the lifecycle.
| 16, 18, 19, 25, 27 | What DDIL capabilities are expected: local application execution, local catalog availability, local authorization, caching, delayed synchronization, or all of the above? | Industry partners should detail which of these DDIL capabilities their proposed solution supports. |
| Section: 3.4.2 | Should ROM pricing cover the initial thin-thread capability, the mature objective-state platform, or both in phased scenarios? | ROMs should include all costs associated with your solution |
| Section: 3.4.2 ROM, Related Rows: 1, 2, 16, 22, 22a, 22b, 25, 27 & 38 | For ROM planning purposes, can NGC2 Apps provide an expected scale boundary for the initial thin-thread and/or mature objective-state solution, including anticipated numbers of users, applications, environments, tactical-edge nodes, data-layer integrations, support hours, and deployment sites? In the absence of a Government-provided estimate, should respondents make and state their own assumptions for scale and price accordingly? | The Government is not providing a baseline scale at this time. |
Industry partners must explicitly define their own assumptions for users, applications, and nodes to support their ROM.
| 17, 17a, 18 & 19 | Is IL6 expected as an initial requirement, or should respondents describe an IL5 baseline with an IL6 growth path? | Describe an IL5 baseline with a clear, defined growth path and mechanism to reach IL6. | ||
| 4 | Could the government please specify what platforms are intended to be included in the definition of cross-platform consistency? | Cross-platform consistency includes things like Windows, Linux, Android, iOS, and macOS environments. | ||
| N/A | What are the upcoming exercises or events for the industry to observe sensor-to-shooter operations with baseline/capability today? | Data acquired via this RFI will assist the Government in assessing industry capabilities and determining performance objectives for future solicitations. | ||
| 17, 37 | Will the storefront be required to operate concurrently across UNCLAS, CUI/IL4, Secret/IL5, TS/SCI, and JWICS at initial operating capability (IOC), or is a phased classification rollout acceptable? If phased, what is the minimum classification scope at IOC? | A phased classification rollout is acceptable; IOC minimum scope should be proposed by the industry partner (e.g., UNCLAS/IL5). | ||
| 1, 4, 18 | Does the government envision a single integrated platform with a unified accreditation boundary, or federated storefronts per classification level with cross-domain synchronization between tiers? | Industry partners should propose the architecture they assess as most secure and feasible for their solution. | ||
| 1, 1a, 1c | What is the expected scope of 'tailorable warfighting applications'? Are these government-owned reference applications the lead entity must maintain, or third-party applications that must meet a government tailoring standard before publish? | It encompasses both government-owned reference apps and third-party apps adapted to standard deployment profiles to prove the initial proof of concept for the "Build Once, Deploy Anywhere" strategy. | ||
| 37 | Is the development pipeline and storefront expected to inherit ATOs from existing accredited Army platforms (e.g., Iron Bank, cArmy, AWS Secret Region), or stand up an entirely new, independent accreditation boundary? | The Government is highly interested in solutions that can inherit controls from existing accredited platforms to speed up deployment. | ||
| 2, 3 | What is the anticipated transaction model between the lead entity, application vendors, and the government — direct contract, subcontract, OTA consortium, or a marketplace transaction model in which vendors transact through the storefront? | Transaction models are being researched. Industry partners should propose their recommended approach. | ||
| 37 | Is the government's preference for a continuous ATO (cATO) posture for applications hosted inside the storefront, or a per-application ATO at time of publish? Will the platform ATO's controls be inheritable by hosted applications? | This RFI is being used to help shape PM C2 Apps strategy which has not been determined at this time. | ||
| 1b, 1c, 9 | Will the lead entity be expected to maintain the existing PM C2 Apps application portfolio during transition, or will a separate sustainment contract handle legacy applications until full storefront cutover? | Sustainment strategies are still being determined. Industry partners should outline their capability to assume legacy sustainment if required. | ||
| 22, 3a | What are the expected user volumes and growth assumptions over 1, 3, and 5 years (e.g., number of active users, number of applications at IOC vs. FOC, classification tiers in scope)? This directly informs infrastructure sizing and ROM cost drivers. | Industry partners should provide their own modeled assumptions. | ||
| 5, 29, 35 | Is the developer environment (sandbox, SDK access, compute) expected to be Government-furnished, vendor-furnished, or a hybrid model? Will developers receive compute provisioned within the government boundary or access a vendor-managed developer cloud? | Industry partners should propose their recommended developer environment model (hybrid, GFE, or vendor-furnished). | ||
| 14, 17, 37 | What is the desired posture on commercial-tool inheritance — can the storefront enable commercial software (databases, analytics tools, AI/ML frameworks) to operate in IL5/IL6 environments without per-tool STIG/ATO certification, consistent with existing Army programs? | This RFI is being used to help shape PM C2 Apps strategy which has not been determined at this time. | ||
| 8, 9, 11 | Has the government considered establishing pipeline velocity — specifically time-to-publish (i.e., elapsed time from vendor application submission to warfighter-available certified artifact) — as a formal Technical Performance Measure? If so, what is the target SLA? | Industry partners should propose a realistic target SLA based on their pipeline maturity. | ||
| 17, 37 | Will the government weight prior production deployments at TS/SCI and JWICS when evaluating the lead entity, given the mission risk of deploying an unproven platform at those classification levels? Will past accreditation history be a source selection discriminator? | Data acquired via this RFI will assist the Government in assessing industry capabilities and determining performance objectives for future solicitations. | ||
| 14, 37 | Does the government value compliance inheritance as a differentiating capability — i.e., the ability for vendor applications hosted within the storefront to inherit the platform's accredited boundary (security controls, FIPS 140-3, cATO) without requiring per-application certification? Will this reduce time-to-publish for hosted apps? | This RFI is being used to help shape PM C2 Apps strategy which has not been determined at this time. | ||
| 18, 19, 25, 33 | Is the government open to a hybrid Platform-as-a-Service (PaaS) architecture that orchestrates workloads across commercial cloud, on-premise HPC, and DDIL tactical edge nodes under a single accredited security boundary? Or is a cloud-first architecture preferred? | The Government is open to any solution provided by industry partners that align with the content of this RFI | ||
| 1a, 1b, 2 | Will the government consider a lead entity's existing two-sided marketplace ecosystem — active vendor relationships, an already-integrated tool catalog, and onboarded ISVs — as an accelerator to MVP delivery and reduced time-to-IOC in evaluation? | The Government is open to any solution provided by industry partners that align with the content of this RFI | ||
| 11, 34 | How will the government measure storefront success at 6, 12, and 24 months post-IOC? What Technical Performance Measures (TPMs) and telemetry metrics will define whether the program is on track, and will those KPIs be shared with industry respondents prior to final RFP? | This RFI is being used to help shape PM C2 Apps strategy which has not been determined at this time. | ||
| 1, 3, 4 | What is the intended relationship between the NGC2 storefront and existing Army software acquisition vehicles — specifically Tradewinds Solutions Marketplace, Big Bang, GSA MAS, and the Army Applications Laboratory (AAL)? Is interoperability or joint intake with these vehicles required at IOC? | This RFI is being used to help shape PM C2 Apps strategy which has not been determined at this time. | ||
| 4, 23, 27 | Will the lead entity be expected to host or interoperate with applications originating from sister-service software factories — including USAF Kessel Run, USSF Atlas, and Navy enterprise programs — in joint or coalition operating contexts? | The solution should be capable of interoperating with joint/coalition data application layers. | ||
| 2, 3b, 20 | What organizational conflict-of-interest (OCI) screening standards will the government apply to the lead entity, particularly regarding the relationship between the storefront operator and application vendors that sell or distribute through the same storefront? | This RFI is being used to help shape PM C2 Apps strategy which has not been determined at this time. | ||
| 18, 19 | Is the government's preference for a lead entity that includes a hyperscaler partner (AWS, Microsoft, Google) as a named subcontractor, or is the architecture intended to remain cloud-agnostic and infrastructure-neutral, with the lead providing an abstraction layer across providers? | The Government is open to any solution provided by industry partners that align with the content of this RFI | ||
| 1 | The RFI describes a "teaming" arrangement under a singular lead. Will the Government define and publish a mandatory workshare or work-split model between the storefront lead and subordinate application vendors, or will that structure be left entirely to the prime/lead to negotiate? Understanding the Government's intended level of prescriptiveness here is critical to accurately modeling a bid structure. | The Government typically does not dictate workshare splits in teaming arrangements; industry partners should structure this as they see fit. | ||
| 2, 3 | Does the Government intend for the storefront platform provider and the CI/CD pipeline provider to be the same entity, or is there an expectation they could be separate vendors teamed together? Is the Government open to a sub-contractor operating the pipeline while a prime operates the storefront? | They can be the same entity or separate teamed entities. The Government is open to any solution provided by industry partners that align with the content of this RFI | ||
| 3b | When the Government asks for "expertise in being a lead," does this refer specifically to DoD program lead experience, or will demonstrated commercial enterprise lead vendor experience (e.g., managing a portfolio of SaaS applications for large enterprises) be considered equivalent? | This RFI is being used to help shape PM C2 Apps strategy which has not been determined at this time. | ||
| N/A | Will the resulting contract vehicle be a single-award or multiple-award IDIQ? The RFI references the AOS (Army Open Solicitation), will this effort be structured as a separate standalone contract or a task order under an existing vehicle such as ITES-SW, CHESS, or GSA IT Schedule 70? | This RFI is being used to help shape PM C2 Apps strategy which has not been determined at this time. | ||
| 1b, 1c, 31, 31a | The RFI references scenarios where "a data layer is provided by the Government" and "a data layer is provided by a separate industry partner." Can the Government clarify the intended technical definition of "data layer" in this context? Specifically: | |||
| • | Is the data layer a messaging/pub-sub bus (e.g., MQTT, Kafka)? | |||
| • | Is it a set of shared databases or data fabric? | |||
| • | Does it include the Army Vantage (Palantir Foundry) system? | |||
| • | Is it an NGC2-specific data layer already under development (e.g., tied to the NGC2 clean-slate effort) or one that is well established? | "Data layer" broadly refers to a data fabric/mesh. Industry partners should specify which responsibilities they are proposing to undertake. | ||
| 28, 31 | Is the Government's "single source of truth data layer" already defined, contracted, or in development under NGC2? If so, will the awardee of this effort be required to interface with that specific layer, and will the Government provide an ICD (Interface Control Document) or API specification? | If a specific NGC2 data layer is mandated, ICDs/APIs will be provided when applicable. | ||
| 32, 32a | Regarding AI/ML model consumption and publication from a data layer, does the Government have a preferred AI/ML framework, model registry standard (e.g., MLflow, ONNX), or classification level at which AI/ML inferencing is expected to operate (IL5 vs. IL6)? | The Government does not mandate a framework yet. Industry partners should propose their supported registries (e.g., MLflow) and IL5/IL6 capabilities. | ||
| 17 | The RFI asks for IL5 up to IL6 solutions. Will both an IL5 and IL6 solutions be provided with data separation and defined data transfer across the levels, or will there be a single solution that will be deployed in IL5 or IL6 depending on a later decision? | Industry partners should outline their capability to provide distinct IL5 and IL6 instances with secure cross-domain data transfer. | ||
| 17a | For transferring updates from commercial environments to classified/secured environments (IL5/IL6), is the Government expecting the vendor to own and operate the transfer mechanism (e.g., a data diode/transfer appliance), or will a Government-provided or -managed cross-domain solution be in place? | Industry partners should propose how they would utilize a Government-managed CDS or if they recommend a vendor-managed appliance. | ||
| 18 | The RFI references "DDIL environments." Can the Government specify the minimum DDIL scenario the solution must support? For example: | |||
| • | What is the minimum acceptable disconnected operation duration (hours, days)? | |||
| • | Are there defined bandwidth floor thresholds (e.g., < 10 Kbps)? | |||
| • | Is satellite-only connectivity a required operating condition? | Industry partners should state the minimum connectivity thresholds (bandwidth/latency) their solution requires to function. | ||
| 18, 25 | In a DDIL scenario, will the Government permit cached/stale application versions to remain operational, or is there a hard policy requirement that applications be validated against a current-version authority before execution? | Industry partners should outline how their solution manages policy enforcement for stale apps in DDIL environments. | ||
| 1a | Can the Government provide an approximate order of magnitude for the expected number of applications in the storefront at initial operating capability (IOC) and at full operating capability (FOC)? (e.g., 10–20 apps at IOC, scaling to 100+ at FOC?) This directly impacts architecture sizing decisions. | Industry partners must state their own assumptions for IOC and FOC application counts for ROM modeling. | ||
| 8a | The question asks what is "an acceptable amount of times an upgrade or update is allowable for an application storefront platform." Does the Government have a preferred or expected update cadence already in mind (e.g., monthly sprint releases, quarterly major updates), or is the question asking vendors to propose their recommended cadence? | The Government is asking Industry partners to propose their recommended, sustainable update cadence. | ||
| 8a | Is the question “Please describe your process for reverting to a known-good version if an application has a vulnerability” applicable to the applications hosted in the storefront or to the storefront platform itself? | The question applies to both the storefront platform itself and the orchestration of the applications hosted within it. | ||
| 14 | Regarding GOTS/COTS license management, will the Government provide GOTS application licenses as Government-Furnished Information (GFI), or is the lead vendor expected to negotiate, procure, and manage GOTS licenses on the Government's behalf? This has significant contracting and IP implications. | Industry partners should state their assumptions on GFI licensing versus vendor-managed procurement in their ROM. | ||
| 20 | On Intellectual Property (IP)/Data Rights, will the Government require delivery of full technical data packages (TDPs) and source code for all applications onboarded to the storefront, including COTS components? Or will COTS applications be permitted to remain closed-source provided they meet functional and security standards? | Standard DFARS data rights clauses will apply. Industry partners should propose how they manage closed-source COTS security validations. | ||
| 5, 6 & 29 | Does the Government have a preferred or mandated CI/CD toolchain (e.g., GitLab, GitHub Enterprise, Jenkins, Tekton)? Or is the vendor free to propose their own toolchain provided it meets DoD Enterprise DevSecOps Reference Design (DEDSORD) standards? | Industry partners should propose their own toolchain provided it meets DEDSORD standards. | ||
| 21a | The Government asks what SAST/DAST tools vendors are using today. Is the Government open to vendors proposing and operating their own scanning toolsets, or is there an anticipated requirement to use Army/DoD-standard tools (e.g., SonarQube, Fortify, or tools approved under a DoD STIG/SRG)? | Industry partners should propose the operational toolsets that work best for their solution (e.g., SonarQube, Fortify) and map them to DoD STIG requirements. | ||
| 37 | For ATO/IATT: Will the Government accept an existing commercial ATO (e.g., FedRAMP High authorization) as a starting baseline, or will a DoD RMF ATO be required from scratch? Which authorizing official (AO) organization will govern, Army, ARCYBER, or DISA? | Industry partners may leverage a previous Authority to Operate (ATO) as evidence of technical readiness and maturity. However, Army ATO/IATT standards remain the governing requirement for network operations. The Government will evaluate existing ATOs for reciprocity, but all solutions must ultimately meet specific Army cybersecurity and technical controls to operate on the Army network. | ||
| 26 | The RFI requires support for Android, iOS, Linux, and Windows end devices. Can the Government clarify whether mobile device management (MDM) will be Government-furnished (e.g., via NIPR/SIPR mobile device infrastructure), or whether the vendor is expected to include an MDM capability in the proposed solution? | Industry partners should state whether their solution relies on Government-furnished MDM or includes integrated MDM. | ||
| 4a | Are there specific Army-standard hardware baselines (e.g., Common Hardware Systems [CHS-5], JBC-P, TMT) that the storefront must be validated against, particularly for the Android and Linux tactical edge form factors? | Baselines are not mandated yet; Industry partners should describe compatibility with general ruggedized/tactical hardware. | ||
| 33 | Regarding Tactical Edge Compute (TEC) and container orchestration, is the Government's target TEC environment already defined (e.g., Kubernetes on a specific ruggedized platform)? Will the awardee be required to integrate with existing TEC infrastructure, or propose a TEC solution as part of this effort? | The TEC environment is evolving. Industry partners should describe their Kubernetes/container orchestration capabilities agnostic of specific hardware. | ||
| 3.4.2 ROM | The ROM request asks for "lifecycle cost." Can the Government clarify the anticipated period of performance for this effort (e.g., base + option years) to enable accurate lifecycle cost modeling? | Your ROM should include all costs associated with your solution | ||
| N/A | The RFI references the Army Open Solicitation (AOS) in Q3 FY2026. Will the AOS be a full and open competition, or set aside for small businesses (given NAICS 541511 / 1250-employee standard)? This directly affects SOFtact Solutions' teaming strategy. | This RFI is being used to help shape PM C2 Apps strategy which has not been determined at this time. | ||
| N/A | Will the Government release a draft RFP or draft Performance Work Statement (PWS) for industry review prior to final solicitation release? If so, what is the anticipated timeline? | This RFI seeks industry solutions to various PM C2 Apps for market research purposes and is not solicitation. | ||
| Section 4: Meetings | The Industry Day referenced in the RFI was scheduled for 05 May 2026, has that occurred, and will a recording or transcript be made available to all respondents to ensure equal access to information shared? | Industry Day materials, recordings, or transcripts will be officially posted to SAM.gov for equal access. | ||
| N/A | Does Storefront Lead only manage application onboarding and integration activities, or will Storefront Lead also be responsible for operating, maintaining, and sustaining each onboarded application on NGC2 provided by individual vendors? | The Government is open to any solution provided by industry partners that align with the content of this RFI. Industry partners should specify which responsibilities they are proposing to undertake. | ||
| N/A | Are vendors expected to support existing legacy Army systems and hardware in addition to modern cloud-native and containerized applications within the NGC2 ecosystem? Additionally, does the Government anticipate integration with Army Vantage, existing Army software factories, or other operational data ecosystems? | The Government is open to any solution provided by industry partners that align with the content of this RFI | ||
| N/A | Does the Government expect the Storefront Lead to support automated rollback and recovery capabilities if an application update introduces vulnerabilities, failures, or operational issues within the NGC2 ecosystem? | Yes, automated rollback and recovery capabilities are a critical DevSecOps requirement. | ||
| N/A | Does the Government expect the storefront provider to manage security scanning, container validation, and vulnerability remediation for third-party applications? | Industry partners should clarify if they are proposing to perform the scanning or just validate that they performed it. | ||
| N/A | Will the Government provide guidance regarding expected scalability targets for the NGC2 ecosystem, such as: | |||
| 1. | estimated number of applications, | |||
| 2. | expected number of concurrent users, | |||
| 3. | anticipated data throughput, | |||
| 4. | and storage or data retention requirements? | Scalability targets will be refined based on RFI feedback. Industry partners must state their baseline assumptions in their response. | ||
| N/A | Does the Government expect the Storefront Lead to enforce data governance, API governance, and interoperability standards across onboarded applications? | Yes, a lead entity would be expected to help enforce data and API governance standards across the storefront. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .