CDAO_26-01 AI Coding Capabilites Q_A.pdf

CDAO_26-01 Q&A

# Question Answer

For this section 6.1.1(c) task: “Provide a proposed project schedule and total estimated out-the-door price for enterprise deployment, and describe how the proposed schedule is achievable” - Are you referring to the Army Enterprise? Also, could you provide some sizing guidance? For example, the number of users you expect to have this AI for the SDLC capability?

The term "enterprise deployment" in the context of this Call for Solutions refers to the entire Department of War.

For planning and proposal purposes, offerors should base their estimates on a potential user base ranging from tens of thousands to upwards of 100,000 users. This information is provided as an estimate for scoping and does not represent a guaranteed number of users.

Section 3.1 states the solution "must hold or be capable of achieving FedRAMP High authorization and DISA IL5 PA." For solutions deployed entirely self-hosted within the customer's existing IL5-authorized infrastructure (no SaaS component, no external connectivity), does the FedRAMP High requirement apply to the product itself, or is it satisfied by the customer's infrastructure authorization?

As stated in Section 3.1, the proposed solution must meet the authorization requirements specified. Offerors must clearly describe in their proposal the current authorization status of their solution. If an existing authorization is held, the proposal must identify the authorization holder and the authorizing body. If the offeror's proposed implementation strategy involves leveraging the Government's existing authorized infrastructure, the offeror is responsible for detailing the approach by which their complete solution will meet all stated security and authorization requirements.

3 Section 7.1(a) lists Technical Merit evaluation criteria including "model architecture and flexibility." Are the Desired Attributes in Section 3.2 scored separately from Required Attributes, or are they evaluated holistically within Technical Merit?

The Government will conduct its evaluation in accordance with the criteria set forth in the Call for Solutions. All proposals will be evaluated against the evaluation factors for award as described in Section 7.1. The Government will not provide further details on its evaluation methodology beyond what is published in the Call for Solutions.

Section 1.0 states "The Department's existing infrastructure includes authorized cloud platforms and model serving endpoints that may be leveraged by prospective solutions." Can the Government provide additional detail on the authorized model serving endpoints currently available (e.g., API format, model types, hosting environment)?

The statement in Section 1.0 is intended to inform offerors that Government infrastructure may be available for use. The Government will not be providing a prescriptive list of available model serving endpoints. Offerors are encouraged to articulate their solution’s preferred or required model endpoints within their proposal. The proposal should also describe the technical approach, level of effort, and any complexities associated with integrating the proposed solution with new or different model endpoints.

At this point in the acquisition process, offerors do not yet have sufficient visibility into final teaming structures that would enable accurate completion of Attachment 1 for all potential participants. We request that the Government consider one of the following:

• Allowing offerors to defer submission of this documentation until a later phase of the acquisition, or

• Permitting offerors to provide preliminary information at this time, with finalized documentation submitted upon request or during negotiations.

This form is meant to incorporate both FAR and non-FAR language in the event that an OTA is chosen as the appropriate award instrument based on your solution submission. It is understandable that vendors may not have finalized teaming structures in time for Phase 1 submissions. For the template, please submit the preliminary arrangement, including any major subcontractors/NDCs, by the Solution Brief due date. Adjustments may be made prior to Phase 3 when formal Solution Proposals are required, should your solution be selected.

6 Is landscape orientation allowed for tables, graphics, and charts? Yes.

7 Please confirm whether fonts smaller than 12-point may be used within tables, graphics, and charts (e.g., to preserve readability and formatting), provided the narrative text remains compliant with the 12-point Times New Roman requirement

For graphics, figures, tables, and diagrams, a smaller font size may be used provided the content remains clearly legible. The Government retains sole discretion in determining whether submitted content meets the readability standard. Offerors should ensure all submitted content is easily readable.

8 The instructions state that internet links will not be considered as part of the Solution Brief evaluation. Please confirm whether hyperlinks to short prototype/demo videos are allowed for reference?

External links to websites, videos, or additional information will not be viewed or considered part of the evaluation. The Solution Brief must stand on its own.

Section 6.1.1(f) requires submission of Attachment 1 (Affirmation of Business Status Certification). Please confirm whether Attachment 1 must be included within the single combined Phase 1 PDF submission (Sections a–h), or whether it should be submitted as a separate standalone PDF?

The Government prefers that Attachment 0001 be incorporated into the single PDF submission for ease of file management and evaluation, but a separate standalone PDF of Attachment 0001 will be accepted if vendors have issues with combining all the files.

In Attachment 1, the “explanation” field/box appears non-fillable in the provided template. Could the Government please provide an editable version of the template (or confirm an acceptable method to complete that field, such as attaching a separate page or providing the text elsewhere in the combined PDF submission)?

Offerors can add a text box over top of (or below) the "explanation" box using a pdf editor. If that is not possible or additional space is needed, offerors can include an additional page providing the information immediately following that second page of Attachment 0001.

11 Should the ROM be submitted as a single total “out-the-door” price, or do you also want labor categories/rates and hours by role?

As stated in section 6.1.1(e), Offerors must break out pricing and tie to milestones where appropriate. A Rough Order of Magnitude (ROM) does not require the level of detail of a Cost Proposal, but the breakout and detail provided should be commensurate with the Solution maturity and proposed schedule to support the solution feasibility and achievability. Existing commercial pricing structure can be mirrored, if available. Please annotate any assumptions used in development of the ROM.

12 Are there funding constraints (ceiling, target budget range, or not-to-exceed) for enterprise deployment? There are no funding constraints identified in the Solicition, and the Government is not providing such information at this time.

13 Should ROM include license costs (commercial models/tools), or do you prefer open-source-only assumptions?

Offerors are expected to propose a complete solution that meets the requirements of the Call for Solutions. If the proposed solution includes commercial models, tools, or licensing costs, the offeror must clearly articulate the basis for those inclusions and identify the sources from which pricing and product information were derived. The Government has not directed offerors to limit their proposals to open-source-only solutions.

14 Will the solution need to operate in an existing IL5 enclave, or can a new enclave be provisioned?

The Government requests the offeror provide additional clarity regarding the nature of this question, including the specific Call for Solutions section or formatting instruction that prompted the inquiry, so that a more precise response may be provided.

15 Are there existing DLP tools we must integrate with?

The Call for Solutions is intended to inform offerors that Government infrastructure and existing tools may be available for use. The Government will not be providing a prescriptive list of existing Data Loss Prevention (DLP) tools or other security tooling within the environment. Offerors are encouraged to articulate their solution's preferred or required DLP integrations within their proposal. The proposal should also describe the technical approach, level of effort, and any complexities associated with integrating the proposed solution with new or different DLP tools and security capabilities.

16 Are there restrictions on open-weight models?

The Call for Solutions does not prescribe or restrict specific model types unless otherwise stated. Offerors are encouraged to clearly articulate within their proposal which models they intend to use, including whether such models are open-weight, proprietary, or a combination thereof, along with the rationale for their selection.

17 Are there restrictions on IDE extensions?

The Call for Solutions does not prescribe or restrict specific IDE extensions unless otherwise stated. Offerors are encouraged to clearly articulate within their proposal which Integrated Development Environments (IDEs) they intend to integrate with, including any required extensions, plugins, or dependencies, along with the rationale for their selection and any associated security considerations.

What does DoW mean by a “phased approach” to the contract? Are vendors expected to propose a flexible phasing plan - e.g., “we can move as quickly as you’d like”—while still anchoring on a defined overall approach? We can be clear about which vectors of scaling are actual rate limiters.

The Government anticipates the desire for a rapid iterative roll out of capabilities. Provide details on how you would propose to roll out your solution rapidly and iteratively.

19 How many different environment targets are you anticipating, and what are their differentiators and expected dates?

The number and type of target environments will depend on the nature of the proposed solution and the deployment strategies offered. As stated in Section 3.1, the solution must be deployable in environments authorized at IL5. The Government is also interested in solutions that can support IL6 and higher environments.

This capability is expected to serve the Department of War broadly, and the diverse networking and security environments across the Department may require tailored deployment strategies to address this operating environment.

The Government may pursue a phased delivery approach. Examples of potential phases may include, but are not limited to: (1) a web-based solution; (2) extension-based integration with one or more native IDEs; and (3) an AI-powered IDE or integrated development workflow. Offerors should describe their proposed phasing approach and identify any environment-specific dependencies or timelines within their Solution Brief.

20 The description of Phase 3: Solution Proposal (p. 5), mentions a "detailed proposal for final evaluation and potential award." Does the DoW intend to release a traditional, written multi-volume RFP, or will it focus more on demonstrable technical capability?

Vendor Solutions that proceed to Phase 3 will receive an invitation letter that includes a Request for Solution Proposal, which will resemble a typical RFP. However, both FAR and non-FAR awards are possible, so the volumes and content required to be submitted may be different. Specific instructions will be included in the invitation letter. Phases 1 and 2 are meant to evaluate solution fit first and foremost before requiring detailed submission volumes, to cut down on the effort required by both industry and Government for proposal submission and evaluation.

The RFP describes a "prototype phase". Does the government want to see only a limited proposal/ROM accounting for a prototype phase? The RFP text suggests a phased rollout for tens of thousands of users. Is it acceptable to address the proposal with a year 1 approach (prototype) and to include follow on years?

Sections 8, 9, and 10 of the Call for Solution relate to OT Prototype awards resulting from the Call. Solutions that are conceptual or require protoyping and development may be best suited by an OT Prototype award, while more mature commercial solutions may be better suited by a FAR 12 commercial contract award. Both award instruments are available. Vendors should develop their ROM and schedule approriate for the maturity path of their proposed solution to maximize success, noting any assumptions used to develop each. See also the response to Question 19.

Section 3.1 requires solutions to "hold or be capable of achieving FedRAMP High authorization and DISA IL5 Provisional Authorization." For AI coding tools deployed within an already-authorized IL5 platform that operates under an existing authorization boundary, does the tool itself require a separate standalone FedRAMP High PA, or may it operate within the host platform's existing authorization?

The applicability of specific authorization requirements will depend on the nature of the proposed solution and the authorization boundary within which it operates. Offerors should clearly describe their proposed deployment architecture, the current authorization status of all solution components, and how their approach satisfies the security and compliance requirements stated in Section 3.1. The Government will assess authorization adequacy based on the specifics of each proposed solution.

The Background section references "authorized cloud platforms and model serving endpoints that may be leveraged by prospective solutions." Can the Government identify which model serving endpoints are currently authorized and available for integration, or provide guidance on the authorization status of major commercial LLM APIs within DoW infrastructure?

The Government will not provide a prescriptive list of authorized model serving endpoints at this time. Offerors are encouraged to describe within their proposal the AI models and model endpoints their solution requires or prefers, along with the technical approach for integrating with Government-provided or alternative model endpoints.

Does the Government require or prefer that AI-generated code undergo automated security analysis (e.g., SAST, SCA, SBOM generation) as part of the proposed solution, or is this expected to be handled by the Department's existing security tooling downstream of the AI coding capability?

The Call for Solutions does not prescribe specific automated security analysis tooling as a required component of the proposed solution. Offerors are encouraged to describe any additional tooling or pipeline capabilities their solution provides or integrates with. If the proposed solution includes capabilities beyond the scope of this Call for Solutions, those capabilities should be clearly identified and architected in a modular manner so that the Government may elect whether to include them.

Given the Government reserves the right to award Other Transactions for prototype projects (Section 4.0) and describes iterative prototyping (Section 8.0), would the Government consider prototype awards that evaluate AI coding tools deployed within existing authorized IL5 DevSecOps platforms, with follow-on production scaling upon successful prototype completion?

As described in Sections 4.0, 8.0, 9.0, and 10.0, the Government may award OT prototype agreements, and successful completion of a prototype may lead to follow-on production awards pursuant to 10 U.S.C. § 4022 without further competitive procedures. The specific award instrument for any resulting or follow-on effort will be determined based on the nature of the solution and applicable acquisition authorities. Offerors should describe their proposed approach, including any phased deployment or prototyping strategy, within their Solution Brief.

What does the Government consider the minimum acceptable scope for a single award under this CFS — is an offeror required to propose against the full scope (both IDE and CLI modalities, all deployment models, all classification levels, 25,000+ user capacity), or would the Government consider awarding to an offeror proposing a narrower but deeper capability? For example, would the Government evaluate favorably a proposal that delivers both modalities at IL5 for an initial 5,000-user cohort with a priced option to scale to 25,000, versus requiring every offeror to propose full enterprise scale from the outset?

Offerors are directed to the requirements set forth in the Call for Solutions, including the Required Attributes in Section 3.1 and the Desired Attributes in Section 3.2, which describe the scope and capabilities the Government is seeking. The Government will evaluate all proposals in accordance with the evaluation criteria in Section 7.1.

27 Does "tens of thousands of users" refer to concurrent users, total licensed users, or total users across DoD?

The Government is not providing specific concurrency requirements at this time. Offerors should clearly state any assumptions regarding user concurrency, licensing models, and capacity within their proposal. Offerors are also encouraged to describe the elasticity of their solution, to meet fluctuating demand.

28 What "virtual desktop" and "web-based development environments" are currently in use across DoD?

The Government requests that the offeror provide additional clarity regarding the relevance of this question to the offeror's proposed solution and the specific Call for Solutions requirement it pertains to, so that a more precise response may be provided.

29 Does the Government anticipate a single award or multiple awards?

As stated in Section 5.2, the Government reserves the right to make multiple awards, a single award, or no award as a result of this Call for Solutions. The number and type of awards will be determined at the Government's discretion based on the merit of the submissions received and the availability of funds.

30 What is the anticipated period of performance and option structure for resulting contracts?

The period of performance and option structure for any resulting contract or agreement will be determined and negotiated at the time of award, based on the nature of the proposed solution and the selected award instrument.

31 For "administrative policy controls" (Section 3.1), can the Government provide examples of the types of policies anticipated?

Section 3.1 requires the solution to support "administrative policy controls appropriate for managing deployments across a large organization." Examples of such controls may include, but are not limited to, the ability to manage user access permissions, configure usage policies, and establish rate limits or other administrative parameters.

Offerors should describe the full range of enterprise administration capabilities their solution provides.

32 Does the Government have a specific definition of "acceptance rate" for agentic/CLI-based AI coding tools that do not use line-by-line autocomplete?

The Government does not have a prescribed definition of "acceptance rate" for CLI-based or agentic coding tools at this time. Section 3.1 requires the solution to provide the ability to measure and report on AI coding tool usage, including "AI-generated code contribution metrics, and acceptance rates." Offerors should describe how their solution measures and reports on usage and effectiveness across all supported modalities, including any proposed metrics for agentic interactions.

Does terminal access within a VDI environment satisfy the "virtual desktop" requirement? Does "web-based" mean browser-based IDEs or any network-accessible environment? What browser-based IDEs does the government expect to use?

The Call for Solutions identifies desktop-based, virtual desktop, and web-based as the computing environments in use across the Department's developer workforce (Section 1.0). The Call for Solutions does not prescribe specific definitions for these terms beyond their common usage, nor does it identify specific browser-based IDEs or VDI configurations. Offerors should describe which computing environments their solution supports and how the solution delivers its capabilities in each environment. The Government will evaluate the breadth and flexibility of environment support as part of its Technical Merit assessment under Section 7.1(a).

Does the Government permit retaining user behavior metadata (session counts, request volumes, feature usage) for usage analytics purposes, given the data handling requirement that data "must not be retained beyond what is necessary for immediate processing"?

The data handling requirements in Section 3.1 pertain to customer source code and data. The scope of permissible data retention for analytics and operational purposes, including user behavior metadata, will be addressed as part of the data rights and intellectual property negotiations associated with any resulting award.

Offerors should clearly describe their data handling, retention, and privacy practices within their proposal as required by Section 3.1.

Readability Standards for Complex Data: The Call for Solutions specifies 12-point Times New Roman for body text. To ensure the clarity of complex information, will the Government confirm that a smaller, legible font (e.g., 10-point) is permissible for architectural diagrams, tables, and flowcharts?

See the Answer to Question 7.

Legacy Modernization vs. Greenfield: The Problem Statement focuses on productivity tools for development. Will the Government confirm if AI-driven legacy code modernization (e.g., automated refactoring of existing systems) is within the intended scope, or if the focus is strictly on new development assistance?

The Call for Solutions describes the required capabilities in Sections 2.0 and 3.1, which encompass AI-enabled coding assistance for software development broadly, including code generation, code completion, debugging, refactoring, and related development activities. The Call for Solutions does not limit the scope of AI coding assistance to new development only, nor does it specifically require legacy modernization as a distinct capability.

Offerors should describe the full range of coding assistance capabilities their solution provides.

Modality Evaluation: The Call for Solutions states a preference for dual-modality (IDE and CLI). Will the Government clarify the scoring impact of a solution that provides superior depth in a single modality versus a solution that provides broader but less integrated coverage of both?

The Government will conduct its evaluation in accordance with the criteria set forth in Section 7.1. As stated in Section 3.1, "Solutions that address both modalities are preferred." The Government will not provide additional detail regarding its evaluation methodology or relative weighting beyond what is published in the Call for Solutions.

Workload Metrics for ROM: To ensure a comparable and accurate ROM, can the Government provide a standard "token budget" or "transaction volume" estimate for a workforce of "tens of thousands," or should offerors define and annotate their own consumption models?

The Government will not prescribe standardized consumption assumptions for ROM development due to varability in solution approaches. Each solution will be evaluated singly and independently against the stated criteria. Offerors should develop their ROM in accordance with the instructions in Section 6.1.1(e) and should clearly annotate all assumptions used, including any consumption or usage models underlying their pricing.

39 Infrastructure Assumptions: Should the Phase 1 ROM assume a Government-provided IL5 cloud environment (e.g., cARMY) for initial deployment, or should the offeror include costs for a full-stack, vendor-managed IL5 hosting environment?

The Call for Solutions does not prescribe a specific infrastructure model for the proposed solution. Offerors should describe their proposed deployment architecture and clearly state whether their ROM assumes the use of Government-provided infrastructure, vendor-managed infrastructure, or a combination thereof. All infrastructure assumptions should be clearly annotated in the ROM per Section 6.1.1(e).

Model Integration Preference: Regarding "Model Flexibility," does the Government prioritize solutions that utilize enterprise-provided AI model endpoints (e.g., AWS Bedrock via cARMY) to ensure unified data governance, or is the preference for self-contained model orchestration?

As stated in Section 3.2, "Model Flexibility" — the ability to integrate with customer-designated AI model endpoints, support multiple model providers, or allow customers to configure which AI models are used — is identified as a Desired Attribute. The Call for Solutions does not mandate a specific model integration approach.

Offerors should describe their solution's model architecture and flexibility within their proposal.

41 Authorization Timeline: Will the Government clarify if a full DISA IL5 Provisional Authorization (PA) is required at the time of award, or if a credible plan and timeline to achieve authorization during the prototype phase is sufficient to remain competitive?

As stated in Section 3.1, vendors "must describe all current security certifications, authorizations, and compliance postures held by the product or its underlying infrastructure, and if IL5 authorization is not currently held, must provide a credible plan and timeline to achieve it." The Call for Solutions does not require that IL5 authorization be held at the time of the Phase 1 submission or at the time of award.

Intellectual Property Protections: If the proposed solution is a Commercial-Off-The-Shelf (COTS) product, will the Government confirm its intent to seek "Commercial Computer Software" rights (per DFARS 227.7202) rather than "Unlimited Rights" to the underlying proprietary AI orchestration logic?

Yes, the Government would consider "Commercial Computer Software" rights in accordance with DFARS 227.7202-1(a).

43 Cost Structure and Sustainment: Licensing Model: Does the Government prefer an enterprise-wide licensing model, a consumption-based model (e.g., token/compute usage), or a hybrid "tiered" structure?

The Call for Solutions does not prescribe a specific licensing or pricing model. Offerors should propose the licensing structure that best supports their solution and clearly describe the pricing model, including whether it is enterprise-wide, consumption-based, hybrid, or another structure, along with the rationale and any assumptions.

The ROM should be developed in accordance with Section 6.1.1(e).

44 Cost Structure and Sustainment: Sustainment: Should offerors include a separate line item for long-term sustainment (O&M, model fine-tuning, and technical support), or should these costs be fully burdened within the enterprise license?

Offerors should present their ROM in accordance with Section 6.1.1(e), which requires a breakout of pricing tied to milestones where appropriate and annotation of all assumptions. Offerors should structure their ROM in a manner that clearly conveys the total estimated cost of the proposed solution implementation. Any sustainment, operations, maintenance, or support costs can be included as separate items and should clearly state all assumptions regarding sustainment scope and duration.

45 Cost Structure and Sustainment: PoP: What is the anticipated period of performance for the initial sustainment phase (e.g., 12-month base with option years)?

The period of performance for any resulting contract or agreement will be determined and negotiated at the time of award. Offerors should propose a period of performance appropriate to their solution maturity and implementation glidepath, and clearly annotate any assumptions regarding duration in their schedule per Section 6.1.1(e).

46 ROM and Basis of Estimate (BOE): Detail Level: For the Phase 1 Solution Brief, is a high-level Rough Order of Magnitude (ROM) sufficient, or does the Government require a preliminary Basis of Estimate (BOE) detailing labor categories and non-labor resources? See the response to Question 11.

47 ROM and Basis of Estimate (BOE): User Normalization: To ensure "apples-to-apples" pricing comparisons, should offerors assume a standardized initial user population (e.g., 10,000 users)?

The Government will not prescribe a standardized user population for ROM normalization. Offerors should develop their ROM in accordance with Section 6.1.1(e) and should clearly annotate assumptions used to develop the pricing. Each solution will be evaluated independently against the evaluation criteria due to the variation in solution approaches.

48 ROM and Basis of Estimate (BOE): Deployment Scale: Should the ROM reflect a pilot-scale implementation (MVP) or a full enterprise-wide deployment at scale?

Section 6.1.1(c) requests a "total estimated out-the-door price for enterprise deployment." Offerors should develop their ROM consistent with this instruction and the ROM requirements in Section 6.1.1(e). If the offeror proposes a phased approach that includes an initial pilot or prototype followed by broader deployment, the ROM should clearly delineate the costs associated with each phase.

49 ROM and Basis of Estimate (BOE): Are there standard usage assumptions (e.g., average prompts per developer per day, concurrency levels) the Government would like offerors to use to normalize pricing comparisons?

The Government will not prescribe standardized usage assumptions. Offerors should develop their ROM based on reasonable assumptions informed by their commercial deployment experience and should clearly annotate all usage assumptions per Section 6.1.1(e) to enable the Government to evaluate proposals.See also the response to Question 38.

50 Infrastructure, Security, and Compliance: Impact Level (IL): What is the required security impact level for the initial deployment (e.g., IL4, IL5, or IL6)?

As stated in Section 3.1, the solution must be deployable in environments authorized at DoW Impact Level 5 (IL5). The Call for Solutions does not specify a different impact level for initial deployment versus full deployment.

See also the response to Question 19.

51 Infrastructure, Security, and Compliance: ATO Responsibility: Will the Government provide a "Fast Track" ATO or reciprocity through an existing platform, or should the offeror factor in the full cost of the Risk Management Framework (RMF) process?

The Government will support expedited authorization processes as required, including leveraging authorization inheritance and reciprocity to enable rapid deployment. Offerors should describe their current authorization posture and any existing authorizations that may be leveraged, and should not assume the full Risk Management Framework (RMF) timeline in their schedule without first accounting for available acceleration mechanisms.

52 Infrastructure, Security, and Compliance: Can the government provide details on how the ROM should be structured around infrastructure costs, model usage costs, and other costs associated with the solution?

Due to the variation in potential solution approaches and pricing structures, the Government cannot readily specify how ROMs and their elements should be structured. Solutions will be evaluated independently against the criteria specified in the Call for Solutions, and offerors must clearly annotate the assumptions used to develop their ROM. See also the response to Questions 39, 47, and 49.

53 Infrastructure and Compute Assumptions: If Government-provided model endpoints or IL5 cloud infrastructure are to be leveraged, are there defined assumptions regarding throughput, availability, or model scale?

The Government will not provide detailed specifications regarding Government infrastructure throughput, availability, or model scale at this time. Offerors should clearly state within their proposal any infrastructure assumptions, including minimum requirements for compute, network, and model serving capabilities that their solution requires. All assumptions should be annotated in the ROM per Section 6.1.1(e).

54 Infrastructure and Compute Assumptions: Does the Government prefer an all-inclusive enterprise price (including infrastructure and compute), or a disaggregated pricing structure separating licensing from infrastructure costs?

The Call for Solutions does not prescribe a specific pricing structure. Offerors may present their pricing in the manner that most clearly conveys the total cost and value of their proposed solution. The ROM must comply with Section 6.1.1(e), which requires a breakout of pricing tied to milestones with annotated assumptions.

55 User Segmentation and Use Cases: User Profiles: Does the Government have a projected distribution of roles (e.g., Full-Stack Developers vs. Data Scientists) to help refine agentic vs. IDE-based tool requirements?

The Government will not provide a projected distribution of user roles at this time. As stated in Section 3.1, the solution should support one or both IDE-based and CLI-based modalities. Offerors should describe how their solution serves different user profiles and workflows within their proposal and how the solution scales to accommodate shifts in user composition over time. Any assumptions regarding user segmentation should be clearly annotated.

56 User Segmentation and Use Cases: Legacy Systems: Is there a requirement for the AI capability to support specific legacy languages or proprietary DoD frameworks as a priority use case?

The Call for Solutions does not identify specific programming languages or proprietary frameworks as requirements. As stated in Section 3.1, the solution must be compatible with the operating systems and environments commonly used by the Department's developer workforce. Offerors should describe the programming languages and frameworks their solution supports within their proposal.

57 User Segmentation and Use Cases: Are there priority mission use cases or environments that should drive initial deployment scheduling assumptions?

The Call for Solutions does not identify specific priority mission use cases or environments for initial deployment scheduling. Offerors should propose a deployment schedule consistent with the requirements of the Call for Solutions and clearly annotate any assumptions regarding deployment sequencing in their schedule per Section 6.1.1(e).

58 Deployment and Adoption: Timeline: What is the target window for Initial Operational Capability (IOC)?

The Government expects Initial Operational Capability (IOC) within 90 days of award. Offerors should develop their proposed schedule accordingly and clearly identify any dependencies or risks that could affect this timeline.

The schedule should be presented in accordance with Section 6.1.1(e).

59 Deployment and Adoption: Training: Does the Government anticipate a requirement for "Train-the-Trainer" sessions or embedded adoption leads as part of the implementation cost?

As stated in Section 3.2, "Training and Adoption Support" — including availability of training resources, documentation, and change management support — is identified as a Desired Attribute. The Call for Solutions does not prescribe a specific training delivery model. Offerors are encouraged to describe the training and adoption support capabilities available with their solution within their proposal.

Target User Base. Section 3.1 references enterprise deployment at scale to "tens of thousands of users." For the purposes of the initial prototype effort described in Section 8.0, what is the approximate size of the target developer population? Understanding whether the initial deployment targets hundreds or thousands of users will inform infrastructure sizing, provisioning approach, and cost estimates in the Rough Order of Magnitude (ROM).

See the response to Question 21 for clarification regarding prototypes, and the response to Question 19 regarding possible phased delivery approach. The Call for Solutions does not specify a distinct user population for the prototype phase separate from the enterprise deployment scale described in Section 3.1. Offerors proposing a phased approach that includes an initial prototype deployment should clearly define and justify their proposed initial deployment scope and describe the path to full enterprise scale. Offerors are encouraged to describe how the solution supports scaling from an initial deployment to full enterprise availability. Any user population assumptions should be clearly annotated per Section 6.1.1(e).

Impact Level. Section 3.1 states the solution must be deployable at Department of War (DoW) Impact Level 5 (IL5). Should offerors assume IL5 as the target deployment environment, or should the solution also account for IL6 data handling requirements? The available model catalog, network architecture, and cross-domain considerations differ between IL5 and IL6.

As stated in Section 3.1, the solution must be deployable in environments authorized at DoW Impact Level 5 (IL5). As communicated in the response to Question 19, the Government is also interested in solutions that can support IL6 and Top Secret environments. Offerors whose solutions can support higher classification levels should describe those capabilities and any additional infrastructure or architectural requirements within their proposal.

Virtual Desktop Environment. Section 1.0 and Section 3.1 identify virtual desktop as one of the three computing environments in use (desktop-based, virtual desktop, and web-based). Can the Government provide additional detail on the Virtual Desktop Infrastructure (VDI) platform in use (e.g., Citrix, VMware Horizon, Amazon WorkSpaces) and whether developers in VDI sessions have the ability to install Integrated Development Environment (IDE) extensions and Command-Line Interface (CLI) tools? This information affects whether the solution can deliver the full IDE-based modality to VDI users or whether those users would be limited to browser-based and terminal-based access.

The Government will not provide detailed specifications of its VDI infrastructure at this time. As stated in Section 3.1, the solution must support deployment across diverse computing environments, including virtual desktop environments. Offerors should describe their solution's compatibility with common VDI platforms and any requirements or constraints regarding extension installation or terminal access within virtual desktop sessions.

Air-Gapped Deployment Priority. Section 3.2 lists flexible deployment architecture as a desired attribute, including air-gapped/disconnected network environments. Should offerors include air-gapped deployment as an objective within the initial prototype period of performance, or is it acceptable to architect for air-gapped capability with full configuration deferred to a follow-on effort? If air-gapped deployment is a near-term objective, can the Government clarify whether managed model services (e.g., Amazon Bedrock) are accessible within the target disconnected environment, or whether the solution should assume self-hosted model inference? A fully disconnected deployment with no access to managed services requires GPU infrastructure sized for frontier-class open-weight models, which represents a materially different scope from a connected Government Cloud (GovCloud) deployment.

As stated in Section 3.2, flexible deployment architecture, including air-gapped/disconnected network environments, is identified as a Desired Attribute, not a Required Attribute. Offerors should describe their solution's current air-gapped deployment capabilities and their approach to supporting disconnected environments. The Call for Solutions does not mandate that air-gapped deployment be included in an initial prototype scope.

Existing AI Coding Tools. Are any organizations within the Department currently using commercially available AI-enabled coding tools (e.g., GitHub Copilot, Windsurf, products available through General Services Administration (GSA) OneGov)? If existing tools are deployed, the proposed evaluation framework could benchmark them alongside the delivered solution during the prototype phase, providing the Department with comparative performance data across its AI coding tool portfolio.

The Government will not be providing specific details regarding current use of GSA coding tools. The comment following the question is noted.

Authorization to Operate. Section 3.1 requires vendors to describe their security posture and, if IL5 authorization is not currently held, provide a credible plan and timeline to achieve it. Should offerors include a complete Authorization to Operate (ATO) package as a deliverable within the prototype period of performance, or is ATO support documentation (security controls mapping, architecture diagrams, data flow documentation) sufficient for the prototype phase with full ATO pursued during follow-on production?

Section 3.1 requires offerors to describe their current security posture and, if IL5 authorization is not currently held, provide a credible plan and timeline to achieve it. The specific deliverables and authorization milestones for any prototype or production effort will be negotiated and defined in the resulting award instrument. Offerors should describe their proposed approach to achieving the necessary authorizations within their Solution Brief.

66 Will the Government conduct an Industry Day or pre-proposal conference for this solution ? If so, then please provide the anticipated dates and participation details.

At this time, the Government does not anticipate any pre-proposal conference or Industry Day. Any events, if planned, would be announced through SAM.gov. Offerors are responsible for monitoring SAM.gov for any amendments or updates to this Call for Solutions, as stated in Section 5.2.

67 Can the government provide anticipated labour categories, skill requirements, or staffing expectations for their requirement? Offerors should propose the staffing approach and skill mix necessary to deliver their proposed solution in accordance with the requirements of the Call for Solutions.

68 Are there any incumbent contractors currently providing related AI_enabled conding or software development support serrvices?

This is a new requirement for unique capabilities of which each Offeror's proposed solution will vary. There are not "incumbent contractors" providing the breadth of desired solution attributes across the Department to the level anticipated in this effort.

69 Can the government provide incumbent details?

This is a new requirement for unique capabilities of which each Offeror's proposed solution will vary. There are not "incumbent contractors" providing the breadth of desired solution attributes across the Department to the level anticipated in this effort.

70 Can the government provide an estimated contract value or budget range for this effort ?

The Government will not provide estimated contract values or budget ranges as the Call for Solutions is looking for unique capabilities that may vary in price. Offerors should develop their ROM in accordance with Section 6.1.1(e) and clearly annotate all assumptions. The ROM is just an estimate and will not be evaluated and Offeror(s) will not be held to ROMs submitted in Phase I. Phase III will provide additional details so more accurate pricing can be proposed.

71 What is the anticiptated total Government spending or funding ceiling for enterprise deployment under this Call for Solutions, including potential follow-on production? See question 70.

72 SOW Section 2: Is there a preferred list of development environments or IDEs that the Department prioritizes for integration

The Call for Solutions does not identify a preferred list of specific IDEs. As stated in Section 3.1, the solution must provide AI-enabled coding assistance within at least one of the specified modalities and must support the operating systems and environments commonly used by the Department's developer workforce. Offerors should describe which IDEs and development environments their solution supports.

73 SOW Section 1: Will the Government provide standardized developer environments or must solutions support all existing heterogeneous environments independently?

As stated in Section 1.0, the Department's developer workforce operates across a diverse set of environments, including desktop-based, virtual desktop, and web-based. The Call for Solution requires that the solution be capable of operating within this heterogeneous environment (Section 3.1). The Government does not anticipate standardizing developer environments for this effort. Offerors should describe the range of environments their solution supports.

74 SOW Section 3.1: Is there a defined target number of users or deployment scale expectations beyond “tens of thousands”?

Offerors are directed to the enterprise deployment scale requirements described in Section 3.1 of the Call for Solution. Offerors should clearly annotate any user population assumptions used in developing their proposal and ROM per Section 6.1.1(e). Offerors are encouraged to describe how their solution supports elastic scaling to accommodate dynamic changes in the size of the user population over time.

75 SOW Section 3.1: Will Government-furnished infrastructure or authorized cloud environments be made available for deployment testing?

As stated in Section 3.1, "The solution itself, or the infrastructure upon which it operates, must hold or be capable of achieving FedRAMP High authorization and DISA IL5 Provisional Authorization (PA)." The requirement applies to the solution or its operating infrastructure. Offerors should clearly describe where they are targeting to deploy their proposed solution.

76 SOW Section 3.1: Can the Government clarify whether FedRAMP certification is required for the proposed solution/product itself, the hosting environment/infrastructure, or the vendor organization?

As stated in Section 3.1, "The solution itself, or the infrastructure upon which it operates, must hold or be capable of achieving FedRAMP High authorization and DISA IL5 Provisional Authorization (PA)." The requirement applies to the solution or its operating infrastructure. Offerors should clearly describe how their proposed solution and deployment architecture satisfy this requirement.

77 SOW Section 3.1: Are there specific DISA IL5 reference architectures or security baselines that vendors must follow?

The Call for Solutions does not reference specific DISA IL5 reference architectures or security baselines beyond the requirements stated in Section 3.1. Offerors should describe their security approach and any applicable frameworks or baselines their solution adheres to.

78 SOW Section 3.2: Can the Government clarify expectations for integration with existing CI/CD pipelines and version control platforms?

As stated in Section 3.2, "Integration with Existing Infrastructure" — including integration with version control systems and CI/CD pipelines — is identified as a Desired Attribute. The Call for Solutions does not prescribe specific CI/CD or version control platforms. Offerors should describe their solution's integration capabilities within their proposal.

79 SOW Section 2: Does the Government expect agentic CLI tools to operate fully autonomously or under defined human-in-the-loop controls?

As stated in Section 2.0, the Call for Solutions describes CLI-based agentic coding tools as "capable of performing autonomous, multi-step coding tasks including code generation, testing, debugging, refactoring, and deployment workflows with human oversight." Offerors should describe the level of autonomy and human oversight their solution provides.

80 SOW Section 1: Are there requirements or preferences regarding specific programming languages that must be supported? The Call for Solutions does not specify required programming languages. Offerors should describe within their proposal the programming languages supported by their solution.

81 SOW Section 4: Can the Government clarify how FAR contracts versus Other Transaction (OT) agreements will be selected for award?

As stated in Section 4.0, the Government intends to award FAR Part 12, Firm-Fixed-Price (FFP) type contract(s);

however, the Government also reserves the right to award Other Transaction(s) (OT) for Prototype Project(s) pursuant to 10 U.S.C. § 4022. The specific award instrument will be determined based on the nature of the proposed solution, the applicable acquisition authorities, and the award path that is most beneficial to the Government and its goals.

82 SOW Section 5.1: Will feedback be provided to vendors whose Solution Briefs are not selected for further consideration?

The Army makes every attempt to provide companies technical feedback and transparency. However, please note the CSO functions under “other competitive procedures” and does not entitle industry to debriefings.

Depending on the volume of Solution Briefs received, the number of requests for feedback, and available resources, the Government may provide general feedback to requesting vendors.

83 SOW Section 7.1: Can the Government clarify how external market research will be used when evaluating company viability?

As stated in Section 7.1, the Government reserves the right to use external market research in the evaluation of a Company's viability. This provision allows the Government to supplement its evaluation with publicly available market information. The Government will not provide additional detail regarding the specific sources or methodology for external market research beyond what is stated in the Call for Solutions.

84 SOW Section 3.1: Are there defined performance benchmarks or latency requirements for AI-assisted…