AIDP - Questions and Feedback Submission_DRAFT CFS 1.xlsx
XLSX spreadsheet 40 KB Posted
- Attached to
- Project Manager Intelligence Systems & Analytics (PM IS&A) Army Intelligence Data Platform (AIDP) RFI #4
- Solicitation number
- ACCAPGAIDPRFI4
About this file
This is a Questions and Answers document from the Army Intelligence Data Platform (AIDP) Call for Solution (CfS) process, addressing industry feedback on Draft CfS #1. The document captures detailed government responses to vendor inquiries across all major solicitation sections, providing critical clarification on program scope, technical requirements, and evaluation criteria for the AIDP-Next system.
The program seeks a complete, integrated solution for next-generation intelligence data platform capabilities across classified networks (JWICS, SIPRNet) with cloud-to-edge architecture supporting disconnected, degraded, intermittent, and limited (DDIL) environments. The government plans to select no fewer than two vendors for a competitive prototyping phase before up-selecting to one primary vendor for operational production. Key technical requirements include a modular, open architecture with common data layer supporting multiple intelligence disciplines (All-Source analytics, geospatial services, terrain analysis, collection management, pattern matching, weather effects, and library services); Zero Trust security posture; DevSecOps integration; and interoperability with legacy and future Department of War systems including NGC2, TITAN, and coalition networks. The prototyping period has a maximum 12-month timeline, with the government preferring shorter schedules where feasible. Government responses indicate flexibility on vendor approaches for data storage architecture, API standards, licensing models, and cloud provider selection, while maintaining requirements for complete solution delivery addressing all capabilities in Section 4 of the CfS. The government will establish product roadmaps with selected vendors during prototyping and work with the AIDP-Next User Community to scope detailed implementation approaches, edge configurations, performance thresholds, and security frameworks during the prototyping and execution phases.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| AIDP - CfS Draft 2 20260706.docx | DOCX document | |
| AIDP - Product Demo Plan.docx | DOCX document | |
| AIDP - Questions and Feedback Submission Sheet.xlsx | XLSX spreadsheet | |
| AIDP - GFI List.docx | DOCX document | |
| AIDP RFI 4 Instructions_20260706.pdf | ||
| AIDP - CfS Draft 2 20260706.docx | DOCX document |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Sheet1
| DRAFT CFS #1 QUESTIONS AND FEEDBACK | ||
| PAGE # REFERENCE FROM DRAFT CFS #1 | QUESTIONS/FEEDBACK FROM INDUSTRY | GOVERNMENT FEEDBACK/RESPONSE |
| 19 | We offer a commercial software technology but do not have a contract or ATO. If selected, would the Army AIDP-N begin a pilot program using the current system while a Prime conducts the ATO work to deploy to classified systems? | The Government will work with the selected vendors to establish an ATO during the Prototyping period. |
| 19 | How many different programs to you anticipate selecting for pilots? | AIDP-Next is one program. The program's plan is to select no less than two vendors for a competitive prototyping phase before up-selecting to one primary vendor for operational production. |
| Page 8, Section 5.1.1 | If a vendor has a ready to field commercial solution that can be deployed in the current AIDP environment, would the government accept a partial solution? | The AIDP-Next program is seeking complete solutions for all capabilities described in the Call for Solution. |
| 18 | Can a small business submit software for the pilot if they are not able to find a Prime company for the hardware to team with before the RFP date? | The AIDP-Next program is seeking complete solutions for all capabilities described in the Call for Solution. |
| 8 | Regarding the statement "Partial Solutions will not be considered" on Page 8, will the government allow multi-vendor proposals to meet stated requirements? If yes, would the government please add language to this section on Page 8 clarifying that multi-vendor solutions are acceptable. | Multi-vendor solutions may be acceptable if submitted by a single vendor seeking to the prime contractor when the combined technologies meet the request for a full solution. |
| 6 | We encourage adding a requirement for NetOps management software in section 6 (Core Services) on page 6 - to help users maintain situational awareness of current data network conditions. | The Government will take this request under consideration. |
| 6 | Is the government interested in software capabilities ensuring the data network is operational, and to monitor its performance? | The Government will take this request under consideration. |
| 6 | We encourage adding a requirement for Day 0 provisioning in section 6 (Core Services) on page 6 - to support rapid deployment of tactical infrastructure to support AIDP. | The Government will take this request under consideration. |
| 6 | Does the government have interest in solutions offering rapid deployment of new tactical kits ; such as Day 0 provisioning? | Additional capabiltiies may be considered on top of the established baseline requirements. |
| 11 | Regarding the statement "The Government may provide sample data sets, operational scenarios, or specific tasks " on page 11, is it possible for interested vendors to receive this information before the Demonstration phase? Providing this information to vendors as soon as possible, in advance of the demonstration phase, will allow time for a better, more comprehensive and compliant solution to stated requirements. | This is being addressed in the Draft CfS #2. |
| Are COTS (Commercial off-the-shelf) software products acceptable for consideration by the government? | Yes, pending the ability to make minor modifications to the COTS products as necessary to meet the Government's requirements. | |
| The timeline slide from the industry day shows CSO to be issued soon. Have these dates shifted? Can the government provide an updated timeline? | The Government anticipates award this FY. | |
| 7 | Section 7 describes a range of mission-dependent capabilities including Geo Services, Terrain Analysis, Intelligence Support to Targeting, Collection Management, Pattern Matching, Weather Effects, and Library Services. The evaluation criteria assess "Relevance and Technical Merit" and "Innovation and Feasibility" holistically across the full solution. May offerors address Section 7 requirements by describing how their proposed solution provides the data infrastructure layer that enables mission-dependent services, including integration with existing Army-fielded systems, rather than by implementing those mission services as standalone capabilities within the proposed solution? Or does the Government require that all Section 7 capabilities be delivered as native features of the proposed solution? | The AIDP-Next program is seeking complete solutions for all capabilities described in the Call for Solution. Multi-vendor solutions may be acceptable if submitted by a single vendor seeking to the prime contractor when the combined technologies meet the request for a full solution. |
| 10 | The evaluation criteria state that solutions prototypeable in less than 12 months may be of greater interest. Can the Government clarify whether the Minimum Viable Capability Release threshold referenced in the Schedule criterion corresponds to all capability areas described in Sections 1–7, or whether an MVP scoped to core platform capabilities with a defined roadmap for remaining capabilities would satisfy this threshold? | AIDP-Next needs to meet all of the requirements laid out in Section 4 "Desired Solution Objective" of the CfS. The Government will work with the prototype vendors to establish a Product Roadmap for MVCR #1 based on their current capabilities. |
| 5.2 Step 2 - Pg 11 | If selected for the Demo, what data sources/data formats will be provided by the Army to feed the live demonstration? | This is being addressed in the Draft CfS #2. |
| 5.2 Step 2 - Pg 11 | For the Cloud demonstrations, will the Gov provide the cloud environment for Contractors to use or will Contractors use their company demonstration accounts? | Contractors will use their company's cloud services for demonstrations. |
| 5.1.3 - Pg 10 | What is the expected timeframe between White Paper submission and demonstration? | 2-4 weeks. |
| Entire draft CFS | We note that the entire draft CFS has been marked CUI/NOFORN. Will the Government consider portion markings for the final CFS so we can be assured that when we reference an interface we are assigning the correct markings in our White Paper response? | The Government will take this request under consideration. |
| 3 | In Section 2, paragraph 2, bullet #2, does the term "rapidly adapt" imply rapid releases of new software/modules to achieve the objective or dynamic reconfiguration in the field? | The Government will consider both approaches. |
| 3 | In Section 2, paragraph 3, bullet #2, does the term "flexible" in the expectation that different deployment might include different sub-modules of AIDP-Next, and not all deployments would include the same configurations/capabilities? | This is correct. |
| 4 | In Section 3, paragraph 2, can the Government expand on the "other warfighting functions" that AIDP-Next would need to be interoperable with? | The Army Warfighting Functions are detailed in ADP 3-0 "Operations". |
| 8 | In Section 4, under the solution objective list, #6 Core Services, (d) Data Logging/Alerting, can the Government clarify if the logging and alerting should include logging and alerting on types of processed intelligence events in addition to the system health/security metrics described in the objective. | This bullet is specifically referring to System Events, however the Government is interested in how Intelligence Event alerting can support the intelligence process. |
| 13 | In Section 5.2.2, does the "Foundational and Core Services" refer specifically to those 11 services listed in Section 4, specific objective #6 (Core Services) or some other subset of the Section 4 specific objectives? | The subset of capabilities to be evaluated during the Product Demonstration will be included in Draft CfS #2. |
| Pg 6, Section 4 "Desired Solution Objective", paragraph 6a. | Is legacy systems integration an aspect of the desired specific solution objective? Recommendation that the specific solution objective should include the ability to support legacy systems integration. | AIDP-Next needs to be flexlible and adaptable to integrate with both legacy and future DoW systems. |
| Pg 8, Section 5 "Call for Solutions Process" | Is past perfomance an evaluated criteria during the call for solutions evaluation? Recommendation that past performance of a commercial solution and prototype fielding should be an evaluated criteria during the call for solutions process. | This is covered under the draft CfS #2 - White Paper Submission Section. |
| RFI#3, Pg 3, Section 6 "Partnering Opportunity" | Will the AIDP Next Team conduct another data call for companies interested in partnering opportunities? | No. |
| AIDP-Next Industry Day QA, p. 3; AIDP-Next CfS Draft (CUI), p. 4 | Prototype Scope. Given the Government’s identification of Hydra as the current government-defined OpenAPI and its indication that additional interface details will be provided in the bidders library, will the bidders library provide enough detail to validate third-party application interoperability end-to-end during prototyping, including representative publish/query flows, payload examples, and any applicable conformance or versioning guidance? | The final CFS will include a bidders library that will provide enough information to facilitate an interface with Hydra as part of the Product Demonstrations. Add'l information will be provided post award during the prototyping phase. |
| AIDP-Next CfS Draft (CUI), pp. 5-6; AIDP-Next RFI 3 Info and Instructions, p. 3 | Sandbox Access. In addition to the Government-furnished datasets planned for demonstration activities, will prototype participants have access to a test environment, sandbox, or representative endpoints sufficient to validate third-party application interoperability as part of prototype demonstrations? | No |
| AIDP-Next CfS Draft (CUI), p. 4; AIDP-Next Industry Day Slides, pp. 11, 16 | Open Integration. The Government’s emphasis on modular open systems architecture is well aligned with analyst-facing capabilities delivered through open, well-documented integration frameworks. We recommend continued emphasis on stable, standards-based interoperability so mature mission applications can integrate rapidly without custom point-to-point development. | N/A |
| AIDP-Next CfS Draft (CUI), pp. 3-4; AIDP-Next Industry Day Slides, pp. 11, 18 | Analyst Utility. AIDP-Next will benefit from architectures that combine open interfaces with established analyst workflows, reducing training burden and accelerating operational utility. Validation of third-party analytic application interoperability during prototyping would provide a practical demonstration of both architectural openness and analyst utility. | N/A |
| AIDP-Next CfS Draft (CUI), pp. 5, 10 | Interagency & Multinational Interoperability: The draft CFS identifies Joint and Coalition partner interoperability as an overarching objective. What requirements are anticipated for interoperability with Interagency (particularly Law Enforcement Agencies) and non-traditional multinational partners? Ubiquitous interoperability: Within the Competition space and with the NSS focus on the Western Hemisphere and continued priority to INDOPACOM, support to MDO means interoperability with Latin American, Asian, and other non-traditional foreign partners will be necessary, as will interoperability with non-IC Law Enforcement agencies at all levels. | No Law Enforcement agencies have been identified at this time. |
| AIDP-Next CfS Draft (CUI), pp. 5 | Workflow Innovations and Backward Compatibility: What are the backward compatibility requriements for new capabilities supporting analytical workflows? Seamless data discoverability and usabilty: Legacy data stores and products can provide depth of understanding to analysis as well as analytical start points for future planning and MDO operations. New products introduced into the AIDP-Next ecosystem should be able to find, process, and use all available data seamlessly in existing and new analytical workflows. | AIDP-Next needs to be flexlible and adaptable to integrate with both legacy and future DoW systems. |
| AIDP-Next CfS Draft (CUI), pp. 8, 10, 16 | Call for Solutions Process: For enhanced capabilities within mature toolsets/capabilities, is there an alternative to the identified Step 4 (Prototype Award) that would allow the capability to be rapidly introduced into the AIDP ecosystem? Expedited innovation: For mature capabilities in established use cases (eg. other DoD platforms, Law Enforcement, partner nation) that are not currently in the existing AIDP ecosystem, the prototyping phase may be unnecessary, or another contracting mechanism may be more appropriate to rapidly operationalize the capability. | The AIDP-Next program is a separate product from the current AIDP system. |
| AIDP-Next CfS Draft (CUI), pp. 12 | Field Service Engineer Support: What are the anticipated government-directed FSE requirements (number, locations, echelon supported, deployability) and will intuitive/low-burden capabilities be prioritized over FSE-intensive capabilities? Minimized FSE support: Costs are reduced by adoption of mature, stable, intuitive capabilities that can immediately support user requirements with minimal training and FSE support, particularly in LSCO enviroments or competition environments requiring small and lower visibilty footprints. | The government will take this request under consideration. |
| pages 3-7 | Are there mandated technologies for cloud providers, databases, and tools? | AIDP-Next needs to be flexlible and adaptable to integrate with any cloud service provider, external databases, and external tools. |
| Section 5.1.2; page 10 | Is there is a mandated cloud provider? If so, will the Government please provide the Government pricing so that each offeror has fair and equal cloud provider costs? | AIDP-Next needs to be flexlible and adaptable to integrate with any cloud service provider. |
| Section 5.1.2; page 10 | If there is a mandated cloud provider, please confirm the Government prices have been negotiated through the period of performance. | AIDP-Next needs to be flexlible and adaptable to integrate with any cloud service provider. |
| Section 5.1.2; # 2, page 9 | Section 5.1.2 , # 2 "Affirmation of Business Status Certification Volume," states "Affirmation of Business Status Certification Volume: Include a separate Affirmation of Business Status Certification form for each company/vendor participating in the prototype project." Can the government confirm that they want an "Affirmation of Business Status Certification form" from each teammate of the offeror? | The draft CfS has been updated to remove this item. |
| Section 5.3.1; page 12 | In the RSP response, can offerors please be afforded the opportunity to identify any GFx/associated need dates to help solidify schedule and price of response? Can the GFx list be not counted toward page count and added as an attachment, as needed? This will assist the Govt in understanding viability of solution, material dependencies and can be transferred as an attachment to the agreement for execution management. | Industry cannot assume that GFx will be available and should propose and price their solution accordingly. |
| Page 4, Section 3 | What are the specific operational scenarios or use cases the solution is expected to address across multiple security domains and partner environments? | AIDP-Next will be used operationally by U.S. Army intel professionals globally in support of real world operations, exercises, and training. The solution must operate on JWICS and SIPRNet prior to production and fielding. Additionally, it may be required to interoperate and/or operate on/with lower security domains and with mission partners' networks. |
| Page 4, Section 3 | Please identify specific challenges or pain points in the current user experience that the solution should address? Also, what do you like/love about your current system? | N/A |
| Page 4, Section 3 | What types of intelligence data sources and formats are expected to be integrated into the solution? | AIDP-Next needs to be flexlible and adaptable to integrate with a multiude of DoW Data Sources. |
| Page 4, Section 3 | What are the key functionalities or design principles required for the modern data interface? | The functionalities and design principles are identified in section 4 of the CfS. |
| Page 4, Section 3 | Please identify specific platforms, frameworks, or technologies that must be used or avoided in the architecture design? | The Government will not specify specific solutions to be used or avoided. |
| Page 4, Section 3 | What specific examples or scenarios does the government Forsee DDIL environments has posed challenges in the past? Details of requirements and scenarios for Tactical Edge Node configurations in DDIL environments will help ensure the solution addresses operational needs effectively. | AIDP-Next needs to be able to continue operations while operating in DDIL conditions, and be able to seamlessly reintegrate with the enterprise when fully reconnected. |
| Page 4, Section 3 | Please elaborate on the "swivel chair" interoperability challenge and how it currently impacts operations? Clear standards for data and system interoperability should be established to address challenges with "swivel chair" operations and integration of third-party systems. | AIDP-Next needs to be modular and adapatble to be able to be integrated into external systems (such as Mission Command) to allow for a user to perform selected intelligence capabilities while connected to the external system. |
| Page 4, Section 3 | How does AIDP Next fit into the broader mission-driven technology ecosystem, and what dependencies or integrations are critical? Streamlining workflows and aligning them with doctrinal processes where possible will enhance operational efficiency and consistency. | The AIDP-Next User Community will be directly involved in Product Roadmap Planning, Testing, and Execution to maximize operational efficiency and consistency. |
| Page 5, Section 4 | Which items are threshold requirements, which are objective goals, and which are just examples? | AIDP-Next needs to meet all of the requirements laid out in Section 4 "Desired Solution Objective" of the CfS. The Government will work with the prototype vendors to establish a Product Roadmap for MVCR #1 based on their current capabilities. |
| Page 5, Section 4 | Does the section intentionally collapse the current data platform effort and later applications/services efforts into one requirement set? | The intention for AIDP-Next, through open modular system architecture approach, is for intelligence applications/services to be integrated onto the solution when it is advantageous to the government. |
| Page 5, Section 4 | Generally, what requirements must be implemented natively vs what the government would accept via federation to authoritative external services? | The AIDP-Next program is seeking complete solutions for all capabilities described in the Call for Solution. |
| Page 5, Section 4 | What counts as acceptable evidence in a response: architecture narrative, prototype, benchmark, roadmap, demo, or fielded example? | Please follow the instructions within the CfS. |
| Page 5, Section 4 | What distinguishes a merely compliant response from a compelling one in this section? | The Government will evaluate the content of the Vendor's response. Please provide as much detail as required to facilitate shared understanding of your approach. |
| Page 5, Section 4.1.c | Does the data layer require only syntactic interoperability or also semantic interoperability? | The Government is looking for Vendor approaches in this area. |
| Page 5, Section 4.1.c | To what extent is 'data duplication' to be avoided? For example, can the same data be instantiated in different formats in service to different workflows/operational requirements? Recommend addressing this desired outcome via entity linking, storage optimization, and federation requirements. For example, DDIL and high availability often requires significant amounts of data duplication | AIDP-Next should minimize duplication of data wherever possible. |
| Page 6, Section 4.3 | How should these development services support multi-vendor insertion and 3rd party development? Recommend asking vendors to differentiate how development and support for mission services (packaging, updating, deploying, etc.) differs from core platform services. | AIDP-Next needs to be modular and adapatble to support 3rd party integration. The Government will take this recommendation under consideration. |
| Page 5, Section 4.5.a | Foundation' services are referenced, where are these enumerated/explained/defined? | Foundation Services are also known as Core Services, the Government will address this in the Final CfS. |
| Page 6-7, Section 4.6 and 4.7 | What concrete outputs should each service produce: layers, alerts, objects, recommendations, reports, APIs, tasking options, etc.? Important to know what roles are in scope for each service; and, what data types and volumes each service must handle at each echelon? | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. |
| Page 6-7, Section 4.6 and 4.7 | How should each service be tailored by mission profile and echelon? | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. |
| Page 6-7, Section 4.6 and 4.7 | Recommend clarification from vendors how these services reuse the common data layer, common workflows and common UI patterns. | The Government will take this request under consideration, however the Government is interested in vendor approaches that result in software design modularity and reduction of duplicative software services. |
| Page 6-7, Section 4.6 and 4.7 | Is 'pattern matching' materially different from 'correlation and combination'? | Yes, please reference FM 2.0. |
| Page 6-7, Section 4.6 and 4.7 | What minimum offline/DDIL behavior is required for each services? | AIDP-Next needs to be modular and adatpable to support multple Edge Configuraitons. The AIDP-Next User Community will be directly involved in scoping the Edge Configurations. |
| Page 6-7, Section 4.6 and 4.7 | What level of human review, override, and auditability is required for automated outputs? | The Government is looking for Vendor approaches in this area. |
| Page 6-7, Section 4.6 and 4.7 | What explainability, confidence scoring, provenance, and traceability are expected? | The Government is looking for Vendor approaches in this area. |
| Page 6, Section 4.6.a | Is the government asking vendors to align to doctrine, source-system, semantics, a formol ontology baseline, or some hybrid? | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. |
| Page 6, Section 4.6.a | Are vendors expected to surface and resolve definitional conflicts explicitly during onboarding? | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. |
| Page 6, Section 4.6.a | How will doctrinal updates be reflected when changes can break fielded mission services? | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. |
| Page 6, Section 4.6.a | What governance process approves: semantic extensions, term changs, depreciations, breaking changes? | The AIDP-Next Governance process is still being established in coordination with the AIDP-Next User Community. |
| Page 6, Section 4.6.a | Recommend clarification on how software release and update cycle will be handled vs semantics updates? Example, cadence, authority, etc. | The AIDP-Next Governance process is still being established in coordination with the AIDP-Next User Community. |
| Page 6, Section 4.6.a | What is the adjudication process when two authoritative data sources define the same term differently? | The AIDP-Next Governance process is still being established in coordination with the AIDP-Next User Community. |
| Page 6, Section 4.6.a | Recommend the requirements point to a semantic compatibility strategy for Joint, IC and Coalition data | The Government will take this request under consideration. |
| Page 7, Section 4.6.h | Is this a user-facing capability, or intended as a service-orchestration capability? | The Government is looking for Vendor approaches in this area. |
| Page 7, Section 4.7 | For each listed mission-dependent service, is the government asking for: |
• native platform functionality,
• third-party integration support,
• a reference implementation,
| • or merely proof that the platform can host/enable that service later? | The AIDP-Next program is seeking complete solutions for all capabilities described in the Call for Solution | ||
| Page 7, Section 4.7 | Is this section asking offers to deliver the listed services as part of an initial data platform prototype, or to provide the APIs, data contracts, and integration framework that later mission services will use? | AIDP-Next needs to meet all of the requirements laid out in Section 4 "Desired Solution Objective" of the CfS. The Government will work with the prototype vendors to establish a Product Roadmap for MVCR #1 based on their current capabilities. | |
| Page 7, Section 4.7 | Should this section primarily evaluate the platform’s ability to support mission services, rather than requiring the initial vendor to be best-in-class in every mission application area? | AIDP-Next needs to meet all of the requirements laid out in Section 4 "Desired Solution Objective" of the CfS. The Government will work with the prototype vendors to establish a Product Roadmap for MVCR #1 based on their current capabilities. | |
| Page 7, Section 4.7 | Is library services a mission-dependent service or part of data integration/sourcing? | The Government is looking for Vendor approaches in this area. | |
| Page 7, Section 4.7 | Is collection management/intelligence support to targeting in scope, or should it be framed as an integration point to external systems? | AIDP-Next needs to deliver the All Source components of Collection Management and Intelligence Support to Targeting as defined in FM 2.0. | |
| Page 7, Section 4.7 | Are there mission-service gaps that are not named here that matter to objectives? Examples: workflow orchestration, releasability/dissemination, mission-product templating? | The Government is looking for Vendor approaches in this area. | |
| Page 7, Section 4.7.a | Which geospatial functions are required, and which are just examples? | AIDP-Next needs to provide geospatial functions in support of the All Source tasks identified in FM 2.0. | |
| Page 7, Section 4.7.a | Are geo services expected to be native analytic functions, map services, or orchestration around external GIS components? | The Government is looking for Vendor approaches in this area. | |
| Page 7, Section 4.7.a | What minimum standards, APIS and data formats are actually required? | The bidders library will provide enough information to facilitate the Product Demonstrations. Add'l information may be provided as part of the prototyping phase. | |
| Page 7, Section 4.7.a | Are Geo outputs expected to be sharable objects in the common data layer? | The Government is looking for Vendor approaches in this area. | |
| Page 7, Section 4.7.b | What does "capitalize on existing toolsets" mean in practice? | AIDP-Next needs to leverage external systems (such as WEG, MEPED, etc.) to populate the library services. | |
| Page 7, Section 4.7.b | Recommend clarification about licensing, update cadence, and data rights | The Government is looking to understand the Vendor's approach to these areas. | |
| Page 7, Section 4.7.c | What specific products are expected? overlays, routes, risk areas, mobility corridors, etc.? | AIDP-Next needs to provide terrain analytics to support the All Source tasks identified in FM 2.0. | |
| Page 7, Section 4.7.c | How should terrain analysis integrate with geo services and weather effects? | AIDP-Next's terrain analysis services should utilize the geospatial services to perform their tasks. | |
| Page 7, Section 4.7.c | What accuracy, timeliness, and edge-device behavior are expected? | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. | |
| Page 7, Section 4.7.d | Is the intended scope limited to intelligence enrichment, or does it extent into nomination, prioritization, and assessment workflows? | AIDP-Next needs to support the Intelligence Support to Targeting tasks identified in FM 2.0. | |
| Page 7, Section 4.7.d | What approvals and audit trails are required | The Government is looking for Vendor approaches in this area. | |
| Page 7, Section 4.7.d | Should the system emphasize interoperability with external targeting systems or end-to-end functionality? | The Government is looking for Vendor approaches in this area. | |
| Page 7, Section 4.7.d | Are there policy or scope concerns with automation in this area? | The Government is looking for Vendor approaches in this area. | |
| Page 7, Section 4.7.e | Is the platform expected to plan, task, monitor, assess, and re-task collection; or, only visualize and share collection-based data | The Government is looking for Vendor approaches in this area. | |
| Page 7, Section 4.7.e | What sensor/tasking systems must it integrate with? | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. | |
| Page 7, Section 4.7.e | What dissemination workflows are implied by "across all warfighting functions"? | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. | |
| Page 7, Section 4.7.e | How should collection management behave in DDIL conditions? | The Government is looking for Vendor approaches in this area. | |
| Page 7, Section 4.7.f | Is the intent anomaly detection, link discovery, rules-based matching, ML based discovery, or all of the above? | The Government is looking for Vendor approaches in this area. | |
| Page 7, Section 4.7.f | What analyst controls are required to tune thresholds, review hits, suppress, false positives, and provide feedback? | The Government is looking for Vendor approaches in this area. | |
| Page 7, Section 4.7.f | What explainability and confidence information must accompany automated findings? | The Government is looking for Vendor approaches in this area. | |
| Page 7, Section 4.7.f | How will the government evaluate effectiveness without proscribing specific algorithms? | The AIDP-Next User Community will be directly involved in evaluating effectiveness and providing feedback through the Prototyping and Execution phases of the program. | |
| Page 7, Section 4.7.g | Is this meant to be a standalone service or a shared input to geo, terrain, collection, and targeting workflows? | The AIDP-Next Mission Dependent Services should interact with one another when appropriate. | |
| Page 7, Section 4.7.g | What weather effects matter? Examples: mobility, visibility, ISR performance, aviation, fires, maritime, sensor degradation? | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. | |
| Page 7, Section 4.7.g | What special and temporal resolution is required, per weather effect? | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. | |
| Page 7, Section 4.7.g | What outputs are expected? | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. | |
| Page 7, Section 4.7.g | What historical and offline/cached weather capability is needed? | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. | |
| Page 9, Section 5.1.2.1; Page 10 Section 5.1.3 | How is "innovative" defined in the context of the proposed solution and in context to DoW environment? Are there specific criteria or benchmarks for measuring innovativeness? The requirements outlined in the white paper content are comprehensive, but some terms (e.g., "innovative approach," "mission requirements") could benefit from clearer definitions to ensure consistency among vendor submissions. | DoW = Department of War. The Government will take this request under consideration. | |
| Page 9, Section 5.1.2.1 | What details may be provided to clarify the level of granularity expected for the proposed agile software development (DevSecOps) approach? For example, should vendors include specific tools, methodologies, or timelines? | The Government is looking for Vendor approaches in this area. | |
| Page 9, Section 5.1.2.1 | What specific types of third-party capabilities should the architecture be designed to integrate? Are there examples or categories of third-party systems that need to be considered? | AIDP-Next needs to be able to integrate 3rd party capabilities in support of future data, anaytics, and application/capability requirements. | |
| Page 9, Section 5.1.2.1 | Are there specific military communications hardware systems that the solution must be compatible with? If so, please describe. | The requirements for operating in DDIL environments could be expanded to include specific challenges or scenarios that the solution must address. | |
| Page 9, Section 5.1.2.1 | Please clarify what is meant by "data-driven, Cloud-to-Edge platforms"? Are there specific data processing capabilities or architectures that are critical to the requirement? | The Government is looking to understand the Vendor's prior experience in these areas. | |
| Page 10, Section 5.1.2.3 | Please clarify if there are specific guidelines or templates for presenting the Rough Order of Magnitude (ROM) price and notional schedule? | Vendor templates that meet the intent of the request are acceptable. | |
| Page 10, Section 5.1.2.3 | Please specific criteria or factors the Government will use to evaluate the feasibility of the ROM price and schedule? The requirement for a notional schedule within 12 months is clear, but additional guidance on what constitutes a "notional schedule" (e.g., format, level of detail) would help vendors create submissions that meet expectations. | Vendor templates that meet the intent of the request are acceptable. | |
| Page 10, Section 5.1.2.3 | For solutions that can be prototyped in less than 12 months, what additional considerations or benefits will the Government take into account? | The Government may find solutions that are able to be prototyped in a shorter period of time to be of greater interest. | |
| Page 10, Section 5.1.2.3 | The text highlights the need to address prototype vs. lifecycle costs but does not specify how much detail is required for lifecycle costs. Providing a framework or example may help vendors submit more targeted responses. | The Government is interested in understanding anticipated lifecycle cost drivers. | |
| Page 10, Section 5.1.2.3 | Please clarify what level of detail is required for the comparison between prototype and lifecycle costs? Are there specific cost categories that must be included | A summary level breakout of anticipated as key cost elements and their roll up for both the prototype and lifecycle phase. | |
| Page 10, Section 5.1.2.3 | For the licensing structure, what licensing models (e.g., subscription-based, perpetual licensing) that the Government prefers? The licensing structure requirement could benefit from clarification on whether vendors should assume single-user, enterprise-wide, or other licensing models when providing costs. | The Government is open to to all potential licensing models. | |
| Page 10, Section 5.1.2.3 | How should vendors describe how they will ensure compliance with the Government’s data rights requirements? If so, what level of detail is expected? | The Government is looking to undertand the vendor's approach to Data rights over data, software, and services. | |
| Page 10, Section 5.1.2.3 | How will the Government assess a vendor's acknowledgment of these data rights? Is a formal statement sufficient, or is additional documentation required? | Vendor templates that meet the intent of the request are acceptable. | |
| Page 10, Section 5.1.3 | Beyond the 12-month timeline, will the Government prioritize solutions with faster prototyping schedules even if they involve higher costs or additional risks? Clarifying how the Government will weigh shorter prototyping timelines against other factors such as cost and risk would help vendors make informed decisions when proposing accelerated schedules. | The Government will consider all aspects of the vendor's proposals as part of the evaluation. | |
| Page 10, Section 5.1.3 | How will data rights assertions be evaluated in the context of the overall submission? Will the Government prioritize solutions that minimize restrictions on data usage? Providing a template or example for addressing data rights assertions could ensure vendors provide the detailed information the Government needs to understand potential impacts or limitations. | The Government will consider all aspects of the vendor's proposals as part of the evaluation. | |
| Page 11, Section 5.2.1 | Please clarify what specific criteria will be used to determine which vendors are invited to Step 2 – Product Demonstrations? Are there any weighted factors from Step 1 evaluations that will influence this decision? Providing more transparency on the selection criteria for Step 2 invitations would help vendors understand how their submissions will be evaluated and improve alignment with Government priorities. | This is being addressed in the Draft CfS #2. | |
| Page 11, Section 5.2.1 | Vendors not invited to Step 2 how does the government plan to provide specific feedback on why their white paper was not selected, and will they have an opportunity to improve and resubmit at a later date? Offering feedback to uninvited vendors would help improve future submissions and foster a more collaborative process. Clarification on resubmission opportunities would also provide vendors with a clear path forward. | The Government will take this request under consideration. | |
| Page 11, Section 5.2.1 | Please clarify how vendors should specific configurations or system requirements (e.g., hardware, software, network) that will be necessary to facilitate live demonstrations of both cloud-hosted and edge-hosted capabilities? Including a detailed agenda and specific requirements in the product demonstration invitation would ensure vendors are adequately prepared and reduce the risk of logistical or operational issues during the demonstration. | This is being addressed in the Draft CfS #2. | |
| Page 11, Section 5.2.1 | Please clarify if the Government furnish sample data sets, operational scenarios, or specific tasks in advance of the demonstration, or will vendors need to request/adapt to scenarios provided during the session? | This is being addressed in the Draft CfS #2 | |
| Page 11, Section 5.2.1 | Please clarify the types of data (e.g., structured, unstructured, real-time) or operational environments (e.g., DDIL, tactical edge) that vendors should prioritize in their demonstrations? | This is being addressed in the Draft CfS #2 | |
| Page 11, Section 5.2.1 | What types of Government-Furnished Information (GFI) will be provided for Step 2 demonstrations, and how far in advance this information will be made available to vendors? | This is being addressed in the Draft CfS #2 | |
| Page 12, Section 5.3.1 | Under what circumstances would the Government request oral presentations in addition to or in place of written proposals? Will vendors receive specific guidance on the format and content of oral presentations if requested? | Oral presentations may be used at the discretion of the Government and largely driven by responses received to the CfS. Further information will be provided if oral presentations are used. | |
| Page 13, Section 5.3.2.1 | Providing specific examples or evaluation criteria for mission effectiveness would help vendors better articulate how their solution aligns with this requirement. | The AIDP-Next User Community will be directly involved in evaluating effectiveness and providing feedback through the Prototyping and Execution phases of the program. | |
| Page 13, Section 5.3.2.1 | For the non-traditional participation/cost-share requirement, what constitutes "significant extent" of contribution from a non-traditional defense contractor? Will additional guidance or examples be provided? | This language comes from 10 U.S.C. § 4022(d)(1). A "significant extent" is not specifically defined as it may vary from solution to solution. Note: this applies to a OTA award. The Government's intention and preference is to award a FAR-based contract for AIDP-Next. However, an OTA may be awarded if deemed necessary for the solution. | |
| Page 13, Section 5.3.2.1 | Please clarify the what government considers detailed system architecture and does this include specific diagrams, models, or technical specifications? If so, can the Government provide a preferred format or level of detail? | Vendor templates that meet the intent of the request are acceptable. | |
| Page 13, Section 5.3.2.1 | Please clarify if the government has specific milestones, deliverables, or metrics that should be included in the detailed project schedule/plan? | The Government is looking to understand the vendor's schedule of meeting the requirements in Section 4 of the CfS. | |
| Page 13, Section 5.3.2.1 | Under what circumstances would the Government choose to request Oral Presentations instead of or in addition to the written submission? Will vendors receive specific guidance on the expected content and format of the presentation? Clarifying when and why Oral Presentations might be requested, and providing guidance on their format, would help vendors prepare effectively for this scenario. | If Oral presentations are requested, additional information will be provided by the Government. | |
| Page 13, Section 5.3.2.1 | Including a template or example of an SOW would reduce ambiguity and ensure vendors include all required elements in their submissions. | The Government will take this request under consideration. | |
| Page 15, Section 5.3.3.1 | Providing examples or templates of the expected level of detail in the price breakdown would help vendors align their proposals with the Government's expectations. | The Government will take this request under consideration. | |
| Section 3 - Problem Statement (pg. 3) | Can the Government clarify the expected architectural approach for enabling seamless operations across Top Secret and Secret domains, including whether a specific cross-domain solution (CDS) or guard architecture is mandated? Forces clarity on the hardest integration boundary, shaping toward scalable, standards-based solutions. | AIDP-Next needs to be flexlible and adaptable to integrate with current and future cross domain solutiuons. | |
| Section 3 (p.3) | What systems are prioritized for initial integration (e.g., TITAN, NGC2, Vantage, coalition systems)? Drives scope prioritization and reduces vendor overengineering. | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. | |
| Section 4.1(c) (p.5) | How does the Government define the “common data layer,” including expectations for schema ownership, normalization, and authoritative data sources? Anchors the requirement toward a unified data model, favoring enterprise-grade platforms. | The Government is looking for Vendor approaches in this area. | |
| Section 3 (p.3) | What baseline assumptions should vendors use for compute, storage, and bandwidth constraints at Tactical Edge Nodes in DDIL environments? Ensures solutions are operationally viable, not cloud-dependent. | AIDP-Next needs to be flexlible and adaptable to support multiple edge configurations of varying sizes. | |
| Section 4.1(a) (p.5) | Are vendors required to align with specific MOSA standards (e.g., FACE, SOSA), or is vendor-defined modularity acceptable? Shapes toward open architecture ecosystems, not proprietary lock-in. | The Government is looking for Vendor approaches in this area. | |
| Section 4.1(b) (p.5) | What performance thresholds (latency, throughput, sync intervals) are required at the tactical edge? Introduces quantifiable evaluation criteria, exposing weak solutions. | The AIDP-Next User Community will be directly involved in evaluating effectiveness and providing feedback through the Prototyping and Execution phases of the program. | |
| Section 6(i)-(j) (p.16) | Should vendors propose Government-owned schemas or vendor-defined schemas with transition rights? Protects IP while aligning to Government long-term ownership concerns. | The Government is looking for Vendor approaches in this area. | |
| Section 4.1(d) (p.5) | Are specific standards (e.g., STANAG, OGC, NIEM) required for Joint and Coalition interoperability? Ensures alignment with coalition mission requirements. | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. | |
| Section 4.2(a) (p.6) | What level of Zero Trust maturity is required at initial deployment versus future increments? Aligns solution to incremental delivery vs overengineering. | The Government will work with the selected vendors to establish an ATO POAM, to include Zero Trust, during the Prototyping period. | |
| Section 4.2(b) (p.6) | Are specific encryption and key management frameworks required for TS/Secret data? Clarifies compliance baseline and avoids rework. | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. | |
| Section 4.2(c) (p.6) | Should vendors integrate with existing Continuous ATO pipelines or establish new ones? Positions toward DevSecOps maturity and faster deployment. | The Government is looking for Vendor approaches in this area. | |
| Section 4.3(a) (p.6) | Are there preferred DevSecOps toolchains (e.g., Platform One, Iron Bank) vendors should align to? Aligns with DoD enterprise DevSecOps ecosystems. | The Government is looking for Vendor approaches in this area. | |
| Section 4.3(c) (p.6) | Does the Government prefer REST, GraphQL, or event-driven APIs as the primary integration approach? Shapes toward modern, scalable architectures. | The Government is looking for Vendor approaches in this area. | |
| Section 4.5(b) (p.7) | Has the Government defined user personas or conducted HSI studies to guide UI/UX requirements? Positions toward adoption-focused solutions, a known Army gap. | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. | |
| Section 4.6(a) (p.7) | Which intelligence disciplines or data sources are prioritized for initial onboarding? Focuses vendors on mission-critical data first. | AIDP-Next will initially focus on All-Source analytics and the AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. | |
| Section 4.6(b) (p.7) | Does the Government prefer graph-based, relational, or hybrid data storage architectures? Influences core system design decisions. | The Government is looking for Vendor approaches in this area. | |
| Section 5.2.1 (p.11) | Are vendors expected to demonstrate both cloud and edge capabilities during Step 2 product demonstrations? Clarifies demo preparation and resourcing strategy. | This is being addressed in the Draft CfS #2. | |
| Section 6(i)-(j) (p.16) | Can the Government clarify expectations for vendor IP versus Government rights for derived analytics, models, and transformations? Protects long-term platform value and differentiation. | The Government is looking to undertand the vendor's approach to Data rights over data, software, and services. | |
| General | Are there any Organizational Conflict of Interest (OCI) concerns or restrictions regarding teaming with current AIDP incumbent contractors or vendors supporting related PM IS&A programs? | All requirements for OCI are listed in the draft CfS. Vendors should submit a certification as well as a mitigation plan, if needed. | |
| Section 2, Page 2 | What is the relationship between AIDP Next and the current/legacy AIDP platform? Will AIDP Next replace existing AIDP, or will there be a transition/integration period requiring backward compatibility? | The AIDP-Next program is a separate product from the current AIDP system. The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. | |
| Section 3, Page 3 | Are there specific NGC2 (Next Generation Command and Control) interface specifications or API standards already defined that AIDP Next must comply with? | AIDP-Next needs to be modular and adapatble to be able to be interface with current and futures external systems (such as NGC2). | |
| Section 4.1.b, Page 5 | What are the specific bandwidth constraints that Tactical Edge Node configurations will be tested against for DDIL environments (e.g., No Bandwidth, 64 Kbps, 128 Kbps, 256 Kbps)? Will the Tactical Edge Node configurations be tested with no bandwidth for an extended period, so the Government can observe how the system recovers? | Offerers should consider current Army DDIL constraints as general guidance. |
The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program.
| Section 4.1.d, Page 5 | Which specific security domains must the solution support for cross-domain data ingress/egress (e.g., SIPR, JWICS, specific Coalition partner networks)? Are there existing Cross Domain Solutions the platform must integrate with? | The AIDP-Next User Community will be directly involved in scoping the approach for implementation through the Prototyping and Execution phases of the program. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .