ASA(ALT)_26-01 Acquisition Data Nexus Q_A.pdf

# Question Answer

1 Does the Government prefer Phase 1 Solution Briefs to focus on a single layer, either the Data Brokerage Layer or the Application and Automation Layer, or are combined solutions equally encouraged?

The Government encourages solutions that are severable between the Data Brokerage Layer and the Application and Automation Layer. Offerors may propose solutions addressing one or both layers; however, proposed architectures should clearly delineate capabilities between layers to support modular acquisition and integration flexibility.

2 Would a solution that primarily addresses the Application and Automation Layer, while integrating with an existing or future Data Brokerage Layer, be considered responsive to this Call?

Yes. A solution that primarily addresses the Application and Automation Layer while demonstrating the ability to integrate with an existing or future Data Brokerage Layer would be considered responsive to this Call.

3 Is the Government interested in solutions that automate acquisition workflows initiated through enterprise email and task coordination, provided authoritative systems remain the system of record?

Solutions focused on automating acquisition workflows initiated through enterprise email and task coordination are outside the scope of this Call.

For Phase 1 submissions, is it sufficient to describe a solution as deployable in a Department of Defense Impact Level 5 environment, subject to Government hosting and authorization decisions, rather than asserting an existing Authority to Operate?

Yes, for Phase 1 submissions, it is sufficient to describe a solution as deployable in a Department of Defense Impact Level 5 (IL5) environment, subject to Government hosting and authorization decisions, rather than asserting an existing Authority to Operate (ATO). However, offerors should be aware that the Government's evaluation of proposed solutions will consider the overall timeline to achieve operational capability in a production environment. Solutions with an existing ATO or those further along in the authorization process may present a shorter path to operational deployment compared to solutions that require a full authorization effort.

Offerors are encouraged to clearly articulate the current authorization status of their solution and provide a realistic timeline for achieving production readiness within a Government environment.

5 Is the Government interested in solutions that automate acquisition workflows initiated through enterprise email and task coordination, provided authoritative systems remain the system of record? See the answer to Question 3.

6 Does the proposed solution need to be implemented using only CIO Approved Data Platforms and CIO Approved Development Platforms, or the vendor can propose their own tooling?

Vendors are not required to implement solutions exclusively using CIO-approved data platforms or CIO-approved development platforms. However, any proposed solution will require an Authority to Operate (ATO) prior to production deployment. The Government notes that solutions leveraging CIO-approved platforms and utilities may benefit from a more streamlined authorization process, potentially reducing the timeline to achieve an ATO. Solutions with an existing ATO or those further along in the authorization process may also present a shorter path to operational deployment compared to solutions that require a full authorization effort. Offerors are encouraged to clearly articulate the current authorization status of their solution, identify any CIO-approved platforms or utilities being leveraged, and provide a realistic timeline for achieving production readiness within a Government environment.

When integrating "innovative Artificial Intelligence (AI) capabilities", will the underlying model be made available as part of the cARMY environment, furnished via the Army through API keys, run locally, selected and paid for by the vendor, or something else?

Offerors are encouraged to clearly articulate the intended integration method for AI capabilities, including which models are suitable for their proposed solution and the rationale for model selection. The cARMY environment does provide access to foundational models (e.g., AWS Bedrock is available); however, enabling access to specific models within the environment may require separate authorization processes. Offerors should account for these considerations in their proposed approach and timeline.

8 When proposing AI capabilities, what type of token budget and throughput is acceptable and in-scope -- i.e.

how many individual end-users, approximately?

Offerors are encouraged to propose a token budget and throughput model as part of their solution. Offerors are encouraged to articulate estimated token consumption on a per-transaction or per-AI-embedded-workflow basis. When characterizing token consumption, it is important to differentiate by model, as token costs vary significantly across models. Offerors should clearly identify the model(s) proposed, the associated token consumption estimates, and how the solution scales relative to the anticipated user base.

The Problem Statement emphasizes reducing manual data entry within the Application and Automation Layer.

Does the Government consider the automated ingestion and structuring of unstructured acquisition artifacts (e.g., proposals, pricing tables, labor categories, technical narratives) to be within the intended scope for this layer, or is the intent limited primarily to workflow automation and structured system integrations? (Ref: Section 3, Required Solution Attributes)

The ability to ingest and structure acquisition artifacts may be a component of the end solution. However, the primary intent of the Application and Automation Layer is to provide a flexible platform that enables Program and Acquisition Executive (PAE) organizations to define and implement their own business processes without being hampered by the need to manually feed required acquisition data into disparate systems. Offerors should focus their proposed solutions on enabling that flexibility and reducing the manual burden on acquisition professionals.

The Problem Statement highlights the need for both speed and accountability. Does the Government value Application Layer solutions that incorporate automated, pre-award risk identification (e.g., highlighting ambiguities, missing clauses, or potential FAR non-compliance) to proactively mitigate bid protest risk prior to the “virtual handoff” to contracting? (ref: Section 2, Problem Statement)

The Government values solutions that provide the flexibility for organizations to define and implement business processes relevant to their specific needs. Offerors are encouraged to articulate how their proposed solution enables configurable, organization-defined workflows and decision-support capabilities rather than focusing on a single use case.

The solicitation seeks solutions that allow PAEs to rapidly implement their own business processes. In evaluation, does the Government expect to evaluate differently domain-specific COTS solutions that provide pre-configured acquisition workflows, templates, and data models, versus general-purpose low-code platforms that require development from a blank slate? (ref: Section 3, Application Layer)

The Government will evaluate all Phase 1 Solution Briefs in accordance with the evaluation criteria set forth in the solicitation. Offerors are encouraged to clearly articulate how their proposed solution meets the stated requirements regardless of the underlying approach. No additional specificity regarding evaluation methodology beyond what is stated in the solicitation will be provided at this time.

With respect to AI integration within the Application Layer, does the Government have a preference for solutions that leverage Army-provided or Government-authorized AI services rather than embedding vendor managed AI model endpoints, in order to support data sovereignty and streamline the ATO process? (ref:

Section 3, AI Capabilities)

See the answers to Questions 7 and 8.

Given the audit and protest requirements inherent in acquisition, does the Government prioritize Application Layer solutions that provide “glass box” traceability—specifically, the ability to link AI-generated outputs or risk indicators directly to citations in source materials such as FAR clauses, policy guidance, or vendor proposals?

(ref: Section 3, AI Capabilities)

The term "acquisition" as used in this solicitation refers to the Army's internal acquisition management processes and workflows, not to the source selection or contract award process. Offerors are encouraged to review the Problem Statement and Required Solution Attributes as defined in the solicitation to ensure proposed capabilities align with the Government's intended scope.

For the Application and Automation Layer, is a fully adjudicated DoD Impact Level 5 (IL5) ATO required at the time of Phase 1 Solution Brief submission, or will the Government consider solutions architected for IL4/FedRAMP Moderate with a defined roadmap to achieve IL5 during the prototyping or execution phase? (ref:

Section 3, Security)

See the answer to Question 4.

While the target architecture depicts the Application Layer integrating through the enterprise Data Brokerage Layer, does the Government view it as acceptable during transition or advantageous for Application Layer solutions to possess optional native API connectors to authoritative systems to enable early value delivery while the Data Brokerage Layer is being established? (ref: Figure 1)

The target architecture envisions integration through the Data Brokerage Layer. Direct connections from the Application Layer to authoritative systems are not consistent with the architecture outlined in the solicitation.

Offerors should design their proposed solutions to integrate through the Data Brokerage Layer accordingly.

16 Is there an existing acquisition data model or semantic layer the Acquisition Data Nexus (ADN) want adopted, or should offerors propose one? (Section 3, Required Solution Attributes)

Offerors are not required to adhere to a particular data model. The expectation is that data within the Data Brokerage Layer has the capability to be extracted from and placed into the authoritative acquisition systems. If an offeror elects to propose a data model, the Government requests that the offeror clearly identify whether the proposed model is based on open standards or is proprietary.

17 Will the Government provide API specs, interface control documents, or a sandbox/test environment for Phase 2/3? If not, what integration assumptions should be used in Phase 1? (ref: Section 6, Solution Submission)

Given the mutability of data formats and potential future changes to authoritative acquisition systems, it may be advantageous for offerors to demonstrate flexibility in data connectivity and integration approaches. Offerors should articulate how their proposed solution can adapt to evolving interfaces and data standards rather than relying on fixed integration specifications.

18 Can the government please provide data retention and volume target statistics to help with scale of the solution?

The Government does not have predetermined data retention or volume targets at this time. The solution should be architected to be elastic and capable of dynamically scaling to accommodate evolving data volumes and retention requirements as the enterprise matures. Offerors should clearly annotate any volume-related assumptions in their ROM.

To ensure Offerors can accurately assess potential or actual conflicts of interest, please clarify the solution provider's technical teams will not be required/not receive access to unencrypted government procurement data.

Access to government procurement data will be dependent on the resulting system architecture proposed by the offeror. Offerors should address data access considerations in their OCI analysis as described in Section 8 of the solicitation.

20 Do current API’s exist for PMRT, VCE, and ACWS? If yes, can you please describe the formats and data interchange protocols used by these API’s? If no, what formats and data interchange protocols are desired?

The systems referenced in the solicitation are exemplars of the types of authoritative acquisition systems the solution would need to integrate with. The primary objective is to demonstrate the ability to rapidly establish new and different types of data connections. See also the answer to Question 17.

21 Can you provide more information on the is the current Identity, Credential, and Access Management (ICAM) system(s) associated with PMRT, VCE, and ACWS? The Government is not providing additional ICAM details at this time.

22 Is the intention for the above ICAM to be GFE? The ICAM services will be the currently enterprise-deployed ICAM solutions.

23 What AI capabilities are you seeking? The Government requests that the offeror resubmit this question with additional specificity to enable a meaningful response.

24 Does PMRT, VCE, and ACWS contain structured, unstructured data or both? (Provide data types for each system.)

The authoritative acquisition systems referenced in the solicitation contain both structured and unstructured data. Offerors should not limit their proposed solutions to the specific systems named in the solicitation; the solution should accommodate a variety of data types across diverse systems.

25 Re-entering data can lead to discrepancies. Have the sources for the authoritative data / source of truth for each overlapping data entity been clearly identified?

A primary objective of the proposed solution is to reduce the need for users to manually enter data into multiple systems, which is a key source of data discrepancies. Offerors should describe how their proposed solution addresses this challenge.

The data is currently distributed. It is our understanding that the government desires a data mesh environment that keeps the data distributed and the government does not desire to ingest the data into a new consolidated environment. Can you please confirm and offer additional details?

The Government desires an environment that facilitates the efficient extraction and insertion of data from and into authoritative acquisition systems, reducing the need for duplicative data entry and manual processes.

Offerors should describe how their proposed solution achieves this objective.

Please provide Appendix A template; that is referenced in 6.1.1 Solution Brief Content, item e. Affirmation of Business Status Certification (two-page limit each, using Appendix A template; incorporate in the single .pdf submission)

An Appendix A Template has been added to the Attachments section of the SAM.gov posting.

28 Can the solution utilize data adapters/connectors on "source systems" or will ALL data access need to be API-based?

The specific integration mechanism will depend on the authoritative acquisition system. However, API-based data access is the anticipated approach. Offerors should describe their proposed integration methodology in their submissions.

29 Will the Government consider if a solution is already available under existing Army Enterprise Agreements (ELAs) to expedite the award and ensure the solution meets the requested accelerated delivery timelines?

The Government will evaluate proposed solutions holistically, including the feasibility and achievability of proposed timelines, in accordance with the evaluation criteria stated in the solicitation.

30 Does the solicitation requirements involve a fixed, known quantity of data products that need to be produced, or must the platform be able to handle completely ad-hoc and random data requests?

The platform should demonstrate the flexibility to rapidly implement new data products as needs arise. A fixed, predetermined set of data products is not envisioned.

What are the mandated data exchange standards (e.g., specific API specifications, data schemas, or protocols) for the Application Layer (Appian) to post transactional updates back to the Data Brokerage Layer and/or existing Systems of Record (PMRT, VCE, ACWS)?

The data exchange standards will be dependent on the requirements of the authoritative systems the solution interacts with.

32 What is the level of configurability for end users to modify to process flows? Should they be able to build new work flows and/or edit existing processes?

The Government envisions a solution that provides users the ability to build new workflows and modify existing workflows as organizational needs evolve. Offerors are encouraged to describe how their proposed solution supports this capability.

33 Does the Government intend to prioritize solutions that can leverage existing ATOs, enterprise cloud environments, and pre-approved Army security baselines to minimize re-authorization timelines?

The Government will evaluate proposed solutions holistically, including the feasibility and achievability of proposed timelines. Offerors are encouraged to clearly articulate their proposed approach and associated timeline considerations. Solutions with existing authorizations or those further along in the authorization process may present a shorter path to operational deployment.

34 Does the Government anticipate that ADN will require persistent, end-toend workflow orchestration (intake, validation, adjudication, audit, and reporting), or is the requirement limited to generating discrete data products?

The ability to ingest and structure acquisition artifacts may be a component of the end solution. However, the primary intent of the Application and Automation Layer is to provide a flexible platform that enables Portfolio Acquisition Executive (PAE) organizations to define and implement their own business processes and workflows. The Government does not prescribe a specific orchestration model; offerors are encouraged to articulate how their proposed solution enables flexibility in workflow definition and execution.

35 To what extent should authorized government users be able to configure, modify, or create workflows, business rules, and data models without vendor or systems integrator intervention?

The Government values solutions that enable authorized users to configure, modify, or create workflows, business rules, and data models with minimal dependency on vendor or systems integrator intervention. The specific extent of user configurability will be informed by the proposed technical approach and is not prescribed as a fixed requirement at this time. Offerors are encouraged to articulate their approach to user empowerment within their proposed solutions.

36 Is the Government seeking a platform-based approach that can be reused across multiple missions, organizations, and use cases over time, rather than a single-purpose solution tied to one program?

The Government is interested in solutions that demonstrate adaptability across multiple missions, organizations, and use cases. However, the solicitation does not prescribe a specific platform architecture.

Offerors are encouraged to articulate how their proposed solution provides flexibility and reusability within the context of the stated problem and desired solution attributes.

37 Will the ASA(ALT) partner applications be propagating the data exposed via rest API? This will be dependent on the authoritative acquisition systems involved.

38 Is the goal of ASA(ALT) to offer a semantic layer to facilitate the integration of the partner applications? The Data Brokerage Layer is intended to facilitate integration and interoperability between the various authoritative acquisition systems and the Application and Automation Layer.

39 What is the Intended number of total Data products that will be implemented? And time frame? The solution should be elastic and capable of dynamically scaling to meet need. Offerors should clearly annotate any assumptions in their ROM.

What is the Intended number of transactional queries per hour during peak operating hours:

a. Small Queries

b. Moderate Queries

c. Big (Complex/Large) Queries

The solution should be elastic and capable of dynamically scaling to meet need. Offerors should clearly annotate any throughput-related assumptions in their ROM.

41 Will there be analytical type queries? That may be driven by AI sourcing

The Government recognizes the potential value of analytical query capabilities, including those that may be supported by AI. Offerors are encouraged to describe any analytical or AI-driven query capabilities within their proposed solutions. The Government will evaluate such capabilities in the context of the overall technical merit of the solution.

42 Will the ASA(ALT) consider accepting induvial proposals from each (ie: DATA) of the 3 sections outline in the

REQUIRED SOLUTION ATTRIBUTES

Yes. A company may submit separate Solution Briefs for the Data Brokerage Layer, the Application and Automation Layer, and/or a combined solution. Each submission must be a complete, standalone Solution Brief that meets all submission requirements outlined in the solicitation. Offerors must clearly indicate which layer(s) each submission addresses. See also the answer to Question 1.

Army Vantage / ADP Alignment - Please confirm whether the ADN Data Brokerage Layer is expected to operate within or alongside Army Vantage / Army Data Platform (ADP). If not required to use enterprise services, please clarify how ADN should synchronize ontologies and data pipelines with Vantage/ADP to avoid duplication.

The specific relationship between ADN and existing enterprise data platforms will be informed by the proposed solutions and the Government's broader enterprise architecture decisions. Offerors should focus their proposals on addressing the problem statement and desired solution attributes as defined in the solicitation.

PMRT / VCE / ACWS Technical Interfaces - Will the Government provide API documentation, schemas, and test environments for PMRT, VCE, and ACWS during Phase 1–2? Please define the expected bidirectional data operations and minimum latency or update frequency requirements.

The systems referenced in the solicitation are exemplars of the types of authoritative acquisition systems the solution would need to integrate with. The Government is not providing API documentation, schemas, or test environments at this time. The primary objective is to demonstrate the ability to rapidly establish new and different types of data connections. See also the answer to Question 17.

Authoritative System Responsibilities - Please confirm current Government/contractor technical authorities for PMRT (AFLCMC/IDS), VCE (ACC/DSA), and ACWS (PEO EIS/Appian/Synergy) for coordination during design and testing. Please confirm these are the responsible teams / contractors?

The Government is not in a position to confirm specific organizational responsibilities for individual authoritative systems at this time. Offerors should focus their proposed solutions on demonstrating the flexibility and adaptability to integrate with a variety of authoritative systems as described in the solicitation. Coordination with relevant stakeholders will be addressed during subsequent phases as appropriate.

Visualization Layer Data Interface – Will the data visualization layer connect directly to the Data Brokerage Layer, or will data used in visualizations come from the Authoritative Layer? If the Brokerage Layer feeds visualizations, which visualization platforms (e.g., Power BI/Tableau/Qlik) and what interface/auth standards (API type, ICAM, cARMY/IL5 constraints) must we support?

The visualization layer is outside the scope of this Call. Offerors should focus on the Data Brokerage Layer and/or the Application and Automation Layer as described in the solicitation.

Will the government confirm if PMRT is primarily a data visualization tool or if it has data collection capabilities, built on top of data brokerage capabilities. Does the Government intend for PMRT to maintain its status as an “authoritative” system if the data brokerage and application layers are removed or modified?

The Government is not in a position to provide detailed characterizations of individual authoritative systems at this time. The specific systems referenced in the solicitation are illustrative of the types of systems the solution would need to integrate with. Offerors are encouraged to focus on demonstrating a flexible integration approach consistent with the desired solution attributes described in the solicitation.

Canonical Acquisition Data Standards - What mandatory enterprise data standards (e.g., PDS, PPBE/financial taxonomies, PIEE/FPDS metadata) must the ADN brokerage enforce, and should the ontology be aligned to Vantage/ADP canonical models.

The applicable data standards will be dependent on the specific authoritative systems the Data Brokerage Layer is interacting with. Offerors should describe how their proposed solution adapts to the data standards of the systems it integrates with.

cARMY IL5 Requirements & ATO Path - Must all ADN components be deployed entirely within cARMY IL5 at initial release, or is a phased IL4→IL5 approach acceptable? Please define the expected ATO model (e.g., cATO) and any required ECMA baselines.

Offerors should clearly identify their target deployment environments in their proposed solutions. See also the answers to Questions 4 and 6.

50 ICAM Integration Mandates - Which specific Army E ICAM services must the brokerage and applications integrate with at go live, and what identity/attribute models must be enforced for RBAC/ABAC?

The specific ICAM services and identity/attribute models will be informed by the enterprise-deployed ICAM solutions in use at the time of implementation. Offerors are encouraged to describe how their proposed solution integrates with standard enterprise identity management frameworks. See also the answer to Question 22.

51 Zero Trust Expectations - What Zero Trust capabilities must ADN meet at initial operational capability, and which DoD ZT milestones (e.g., FY27 target levels) must the solution demonstrate?

Proposed solutions should align with applicable DoD Zero Trust policies and guidance. Specific Zero Trust capability requirements will be informed by the enterprise security posture and applicable policy at the time of implementation. Offerors are encouraged to describe how their proposed solution supports Zero Trust principles in their submissions.

Government Provided Test Environment - For Phase 2, will ACC APG provide an IL5 test enclave and representative PMRT/VCE/ACWS datasets, or must offerors provision their own IL5 environment and create synthetic datasets?

Details regarding the format, logistics, and any Government-provided resources for Phase 2, if conducted, will be provided in an invitation letter to offerors selected to proceed. Offerors should focus their Phase 1 submissions on addressing the evaluation criteria as stated in the solicitation.

Phase 2 Primary Evaluation Priorities - Beyond technical merit, is the Government prioritizing solutions that reuse enterprise services (e.g., Vantage/ADP, ICAM, cARMY integration services) over custom components? If so, please confirm how this affects Phase 1 scoring.

Phase 1 Solution Briefs will be evaluated in accordance with the evaluation criteria defined in Section 6.1.2 of the solicitation. Evaluation criteria for Phase 2, if conducted, will be provided in the Phase 2 invitation letter. No additional specificity regarding evaluation methodology beyond what is stated in the solicitation will be provided at this time.

The solicitation says, " Submittals must use a standard, readable font (i.e., not requiring magnification)...Offerors are strongly encouraged to use diagrams, graphics, and concise text to effectively convey complex information." In order to help graphics and figures fit better on the page, would the Government confirm that a font smaller than Arial 12 can be used for these?

The solicitation requires the use of 12-point Arial font for Solution Brief body text. For graphics, figures, tables, and diagrams, a smaller font size may be used provided the content remains clearly legible without magnification, consistent with the solicitation's requirement for a standard, readable font. The Government retains sole discretion in determining whether submitted content meets the readability standard. Offerors should ensure all submitted content is easily readable.

55 What is the estimated timeframe for Phase 1 evaluations, invitations to Phase 2/3, and final award(s)?

The Government does not have a specific timeline to provide for Phase 1 evaluations or subsequent phase invitations at this time. Offerors will be notified in writing of their evaluation results as soon as practicable, as stated in the solicitation.

56 What is the period of performance assumption Offerors should use to develop their ROM?

The solicitation does not prescribe a specific period of performance. Offerors should propose a period of performance that is realistic and achievable for their proposed solution and clearly annotate any assumptions used to develop the ROM and schedule, as instructed in Section 6.1.1(d).

57 What is the estimated number of users for the Data Brokerage Layer and the Application & Automation layer?

The Government does not have specific user count estimates to provide at this time. The solution should be architected to be elastic and capable of dynamically scaling to meet evolving user demand across the enterprise. Offerors should clearly annotate any user-related assumptions in their ROM.

58 For the Data Brokerage Layer, please clarify what the Government means by "bi-directional integration." If it means a writeback, please provide some examples of what this looks like.

Bidirectional integration, as referenced in the solicitation, refers to the capability to both retrieve (read/extract) data from and send (write/update) approved data to authoritative acquisition systems through the Data Brokerage Layer. Offerors should describe how their proposed solution enables both directions of data flow while maintaining data integrity and appropriate approval workflows.

59 Please confirm if the Government is expecting a data catalog where the users can see and download data in bulk?

The Data Brokerage Layer, as described in the solicitation, is focused on data integration, orchestration, and access management. It does not include visualization or user-facing application interfaces. Offerors should describe data access and delivery capabilities within the context of the desired solution attributes outlined in the solicitation.

60 Please clarify what the Government means by "Allows seamless integration of innovative Artificial Intelligence (AI) capabilities"? Please provide examples.

See the answers to Questions 7 and 8. The Government is interested in solutions that can incorporate AI capabilities to enhance data integration, automation, and decision support. Offerors are encouraged to describe how their proposed solution enables AI integration and the specific benefits such capabilities provide in relation to the objectives of this Call.

61 What specific software or platforms are running PMRT, VCE, and ACWS? We need these details to figure out the most secure way to plug into them and pull data.

The specific systems referenced in the solicitation are illustrative of the types of authoritative acquisition systems the solution would need to integrate with. The Government is not providing detailed technical specifications for individual systems at this time. Offerors should focus on demonstrating flexible integration capabilities that can adapt to a variety of systems and data formats. See also the answers to Questions 17 and 20.

62 Are there any systems besides those three that we need to include for the Data Nexus project?

The systems referenced in the solicitation are exemplars of the types of authoritative acquisition systems that exist within the enterprise. The solution should be architected to accommodate integration with additional systems as requirements evolve. See the answer to Question 20.

63 Which ICAM (Identity, Credential, and Access Management) provider do you use to manage user logins and permissions? See the answers to Questions 21 and 22.

64 Since the project requires IL5 security standards, will we be building this in Azure, AWS, or a hybrid of both?

See the answers to Questions 4 and 6. Offerors should clearly articulate their proposed deployment environment and describe how their solution meets applicable security requirements. The Government has not prescribed a specific cloud service provider for this effort.

65 Can the Government provide additional clarification on the intended role of semantic support within the Data Brokerage Layer?

The Data Brokerage Layer, as described in the solicitation, is intended to serve as a secure, API-driven data backbone that abstracts users and applications from direct interface with authoritative systems. Semantic support capabilities, if proposed, should be described in the context of enabling data integration, orchestration, and interoperability across diverse authoritative systems.

To provide an accurate ROM we would need to know the number of Integrations required as well as the integration profiles & complexity. Since this level of detail is not present in the requirements document, would the government accept a simple base level ROM?

Yes. The Government understands that detailed integration specifications are not available at this phase.

Offerors should develop their ROM based on reasonable assumptions and clearly annotate those assumptions as instructed in Section 6.1.1(d).

Would the Government accept 3 separate responses from a Company? Example, a Company submits a response for the “Data Brokerage Layer” only and “Application & Automation Layer” Only, and a combined solution response? Yes, see the answer to Question 42.

68 To accurately depict a ROM, we need to understand how many users and what their roles will be. How many users are there and what are their roles?

See the answer to Question 57. The Government does not have specific user counts or role definitions to provide at this time. Offerors should develop their ROM based on reasonable assumptions and clearly annotate those assumptions as instructed in Section 6.1.1(d).

69 What distinguishes a well-scoped prototype submission from one that is considered overly broad or unnecessarily complex?

Offerors should propose a solution that is directly responsive to the problem statement and desired solution attributes defined in the solicitation. The Government will evaluate Solution Briefs against the evaluation criteria in Section 6.1.2. Offerors are encouraged to present a focused, feasible, and achievable approach that demonstrates clear relevance to the Call for Solution.

70 How does the Government anticipate maintaining consistency and integration discipline as new applications and workflows leverage the ADN environment?

The target architecture described in the solicitation envisions a Data Brokerage Layer that functions as a secure, API-driven data backbone, abstracting applications from direct interface with authoritative systems. This architectural approach is intended to provide a standardized integration framework. Offerors are encouraged to describe how their proposed solution supports integration discipline and consistency across the enterprise.

71 Does the government expect this logic to be attribute-based access control (ABAC) down to the specific data field level, or is role-based access control (RBAC) at the portfolio level sufficient?

The solicitation calls for the capability to enforce flexible business rules that allow users to view and edit data based on their organizational assignment and program responsibilities. The specific access control model (ABAC, RBAC, or a combination thereof) is not prescribed. Offerors should describe their proposed access control approach and how it satisfies the desired solution attributes outlined in the solicitation.

If different vendors are selected for the Data Brokerage Layer and the Application Layer, who will function as the lead system integrator? Will the Data Brokerage awardee be contractually required to expose specific SDKs to the Application Layer awardee?

The Government reserves the right to issue multiple awards from this Call for Solution, as stated in the solicitation. Integration responsibilities and contractual arrangements between awardees, if multiple awards are made, will be addressed by the Government during subsequent phases. Offerors should focus their Phase 1 submissions on clearly describing their proposed solution and its interoperability capabilities.

73 Will the Government provide an existing cARMY IL5 boundary for deployment, or must the solution obtain a new ATO?

See the answers to Questions 4 and 6. Deployment environment details will be addressed during subsequent phases. For Phase 1, offerors should describe their proposed deployment approach and clearly articulate the current authorization status of their solution.

74 Which ICAM authority is authoritative for role assignment (Army Enterprise Identity, Azure IL5, CAC/PIV)? See the answers to Questions 21 and 22.

75 How many distinct PAE workflow variants must be supported at initial deployment? (Re: Application & Automation Layer)

The Government does not prescribe a specific number of PAE workflow variants at this time. As stated in the solicitation, the solution should accommodate different business processes across various acquisition domains.

Offerors are encouraged to describe how their proposed solution provides the flexibility to support multiple, distinct PAE workflows.

76 Will the brokerage layer be responsible for schema transformation between authoritative systems?

The Data Brokerage Layer, as described in the solicitation, is intended to handle data integration and orchestration between authoritative systems and the Application Layer. The specific approach to schema transformation or data normalization is not prescribed. Offerors should describe how their proposed solution manages data interoperability across diverse authoritative systems.

77 What retention period is required for transaction-level audit logs?

The Government does not prescribe specific retention periods for audit logs at this time beyond what is already outlined in published policy, regulations, and laws. Offerors should describe their proposed approach to audit logging and data retention, and any assumptions should be clearly annotated.

78 How many total PAEs and subordinate organizations must the architecture support at Full Operational Capability (FOC)? The Government does not prescribe a specific number of PAEs at this time. The solution should be scalable to accommodate multiple PAEs and their subordinate programs simultaneously, as stated in the solicitation.

79 Are standardized dashboards required across PAEs, or can each PAE define independent reporting structures? The visualization layer is outside the scope of this Call. See the answer to Question 46.

80 Will external Army systems require direct API access to the brokerage layer?

The Data Brokerage Layer is intended to function as a secure, API-driven data backbone. The specific integration requirements for external Army systems will be informed by the enterprise architecture and evolving requirements. Offerors should describe how their proposed solution supports scalable, secure API-based access.

81 Are there security requirements mandating logical or physical separation between layers?

The solicitation envisions a layered architecture with clear separation between the Data Brokerage Layer and the Application and Automation Layer. Specific security separation requirements will be informed by applicable DoD security policies and the proposed deployment environment. Offerors should describe their proposed approach to architectural and security separation between layers.

82 Does the Government require an existing IL5 ATO at time of submission, or is a path to ATO sufficient? See the answer to Question 4. An existing ATO is not required at the time of Phase 1 submission.

83 Is PDF file format acceptable to the Government for submission? Yes, PDF file format is preferred as stated in the Call.

84 Does the Government have an email size limit for messages with attachments? If so, what is that limit? Soultion Brief PDFs are not expected to near the size limitations for email attachments. The Contracting/Agreements Officer and Specialist listed in the solicitation will provide a confimation receipt of submitted solutions briefs, and can coordinate submission of larger files using a DoD SAFE dropoff if needed.

85 Would the Government allow a font size smaller that 12-point Arial for tables and graphics? Is use of Arial Narrow acceptable to the Government?

See the answer to Question 54. The solicitation specifies 12-point Arial font for body text. Tables, figures, and graphics may use a smaller font size provided the content remains clearly legible without magnification.

Regarding font family, the solicitation specifies Arial; offerors should use Arial font for body text as instructed.

86 Are API specifications and interface control documents available for PMRT, VCE, and ACWS? Can these be shared with potential offerors to inform technical approach and ROM development?

See the answers to Questions 17 and 20. The Government is not providing API specifications or interface control documents for specific systems at this time. The systems referenced in the solicitation are exemplars, and the primary objective is to demonstrate the ability to rapidly establish new and different types of data connections.

87 What data exchange protocols do PMRT, VCE, and ACWS currently support (REST, SOAP, other), and what is the expected frequency of synchronization (real-time, batch, event-driven)?

See the answers to Questions 17 and 20. The specific data exchange protocols will be dependent on the authoritative systems. Offerors should demonstrate flexibility in supporting a variety of data exchange protocols and synchronization patterns.

88 Which specific Army ICAM system(s) and authentication protocols (SAML 2.0, OAuth 2.0, CAC/PIV) are required for integration? See the answers to Questions 21 and 22.

89 Are there existing data dictionaries, semantic models, or common data schemas for acquisition data that the solution should adopt?

See the answer to Question 16. Offerors are not required to adhere to a particular data model. Existing data standards will be dependent on the specific authoritative systems the solution interacts with.

90 When data conflicts occur between systems, what is the system of record hierarchy for resolving discrepancies?

Data conflict resolution will be dependent on the specific authoritative systems and their established data governance policies. Offerors should describe how their proposed solution manages data integrity and supports configurable conflict resolution mechanisms.

91 Are there existing API gateways, enterprise service buses, or middleware currently in use that solutions must integrate with?

The Government is not providing detailed information regarding existing enterprise integration infrastructure at this time. Offerors should describe a flexible integration approach that can adapt to existing and evolving enterprise infrastructure.

92 Is an existing Authority to Operate (ATO) at IL5 acceptable, or must a new ATO be obtained specifically for this implementation? If new, what is the expected timeline? See the answer to Question 4.

93 What are the specific cARMY hosting requirements (dedicated instance, multi-tenant restrictions, CSP preferences, specific regions)? See the answers to Questions 4 and 6. Specific hosting requirements will be addressed during subsequent phases. Offerors should describe their proposed deployment approach and any associated assumptions.

94 Are there specific NIST 800-53 overlays or additional security controls beyond standard IL5 requirements?

The Government does not have specific additional security control overlays to provide at this time beyond applicable IL5 requirements. Offerors should describe how their solution meets standard IL5 security requirements and any additional security capabilities their solution provides.

95 Are there security or policy restrictions on AI/ML capabilities, particularly regarding model training on government data?

See the answers to Questions 7 and 8. Offerors should describe their proposed approach to AI/ML integration, including how government data is handled in the context of AI capabilities. Proposed solutions must comply with all applicable data protection and security requirements.

96 What is the anticipated total user population across all PAEs, and how many concurrent users are expected during peak usage?

See the answer to Question 57. The Government does not have specific user population estimates to provide at this time. The solution should be elastic and capable of dynamically scaling to meet need.

97 How many distinct PAEs will use the solution initially, and can you provide examples of how business processes differ (e.g., C2/CC2 vs. Maneuver vs. Fires)?

The Government does not prescribe a specific number of initial PAEs at this time. As stated in the problem statement, each PAE has distinct business processes. Offerors are encouraged to describe how their proposed solution accommodates diverse workflows across acquisition organizations.

98 What is the expected volume of API transactions per day and estimated total data storage requirement? See the answers to Questions 39 and 40. The solution should be elastic and capable of dynamically scaling to meet need. Offerors should annotate any volume-related assumptions in their ROM.

99 What are the required API response times, uptime SLAs, and other critical performance metrics?

The Government does not prescribe specific SLAs at this time. Offerors are encouraged to propose performance parameters that support timely, reliable access to acquisition data and clearly annotate any performance-related assumptions.

100 Does the Army acquisition enterprise currently use ServiceNow in any capacity, and are there existing Army-wide instances this solution should integrate with or remain separate from? The Government is not providing these specific details at this time.

If an offeror has stronger capabilities in one layer (e.g., Application & Automation) versus the Data Brokerage Layer, is a partial solution acceptable, or would the Government consider awarding different layers to different vendors?

See the answers to Questions 1 and 2. Yes, the Government will consider solutions that address a single layer.

The Government reserves the right to award different layers to different vendors. Offerors must clearly indicate which layer(s) their proposed solution addresses.

Does the Government prefer commercial-off-the-shelf (COTS) solutions with configuration over custom development? Is use of existing commercial integration platforms (iPaaS) acceptable for the Data Brokerage Layer?

The Government will evaluate all Phase 1 Solution Briefs in accordance with the evaluation criteria set forth in the solicitation, regardless of the underlying technical approach. Offerors are encouraged to clearly articulate how their proposed solution meets the desired solution attributes, whether through commercial off-the-shelf solutions, integration platforms, custom development, or a combination thereof.

103 Is the Government considering multiple awards for different layers/capabilities, or a single prime contractor?

What is the anticipated contract period of performance and value range?

As stated in the solicitation, the Government reserves the right to issue multiple awards from this Call for Solution. The Government does not prescribe a specific period of performance or contract value range at this time. Offerors should propose a period of performance and ROM that is realistic and achievable for their proposed solution.

104 If selected for Phase 2 pitch, will offerors have access to a Government network environment for live demonstrations, or should demonstrations be prepared for internet-only/offline presentation?

Details regarding the format and logistics of Phase 2 Pitch Sessions, if conducted, will be provided in an invitation letter to offerors selected to proceed to Phase 2. Offerors are encouraged to focus their Phase 1 submissions on clearly articulating their proposed solution in accordance with the evaluation criteria outlined in the solicitation.

105 For Phase 1 ROM, should pricing include infrastructure/hosting costs and ongoing O&M, or are those Government-provided/separate?

Yes. Offerors are encouraged to include all costs necessary to deliver the proposed solution in their ROM, including infrastructure, hosting, and ongoing operations and maintenance costs as applicable. Offerors should clearly annotate any assumptions used to develop the ROM, including assumptions regarding Government-furnished versus offeror-provided resources, as instructed in Section 6.1.1(d).

106 Is there a list or can you provide examples of vendor apps or products the PAEs are using as their own tools? The Government is not providing a list of vendor applications or products currently in use by PAEs at this time.

107 Is there an all-encompassing list of Acquisition Data Authoritative Systems required for this effort? No. The systems referenced in the solicitation are exemplars. See the answer to Question 20.

108 For this list of authoritative systems – what technologies are these systems built upon? (Ex. SAP, Oracle, etc) Examples of authoritative acquisition systems have been provided in the solicitation. Given the mutable nature of acquisition domain data and systems, the specific underlying technologies may change. Offerors should demonstrate flexibility in their ability to integrate with diverse technology platforms.

Does the…