Questions and Answers 24 Apr 26.xlsx

Sheet1

1. Can the government share more information on how the csv files will be evaluated?

For example, will the evaluation be quantitative in nature such as alert time stamps and volume of alerts?

2. Will qualitative data be evaluated? For example, relevance to the DOW wide enterprise, data quality, veracity, and signal to noise ratio.

3. How would the Government like to observe push alert confirmation (SMS, Email, Mobile) or keywords via the CSV files? Is the CSV meant to be supplementary to the presentation in terms of delivery method or does the CSV need to be standalone to prove each of the csv noted objectives in Table 2? 1. How will the CSV files be evaluated? Will it be quantitative?

The evaluation of the .csv files will be a comprehensive assessment composed of distinct quantitative and qualitative components. As a baseline, the Government expects the .csv files to reflect the complete, raw, and unedited production output of the system; manual curation to artificially inflate scores is strictly prohibited.

The Government will assess the .csv files on the following definitive objectives:

Quantitative Assessment:

Qualitative Assessment:

The following objectives will be evaluated based on the professional judgment of the Government's technical evaluation team, relying solely on the offeror's native data structure and any provided data dictionary (narrative explanations within the .csv are not permitted):

2. Will qualitative data be evaluated?

Yes, the evaluation of qualitative data is a critical component of the assessment. The evaluation criteria explicitly state that the .csv submissions will be evaluated on the following qualitative aspects:

3. How should push alert confirmation and keywords be demonstrated in the CSV files?

Table 2- Objectives/Delivery Method indicates that each objective related to the csv file also has a Presentation delivery method.

2. Is it the government's expectation that offerors will provide context for their csv submissions during the presentation? 1. No, the Government will not provide a .csv template, nor is there a mandatory schema or required column structure. The intent of Subfactor 2a is to evaluate the data made available by the offeror's proposed system or API. The Government expects the offeror’s native data structure to demonstrate how their system captures, organizes, and presents the data elements necessary to meet the evaluation objectives outlined in Table 2 (e.g., source references, timestamps, event details, translations).

2. The Government expects the .csv submissions for Subfactor 2a to demonstrate the system's capabilities independently based on the data provided. Offerors are permitted to provide context for their csv submission during the presentation as long it adheres to the overall slide length and time limit. Also, presentations must follow the objectives/delivery methods of table 2.

8 Atch 2 para 2.1 Evaluation Methodology (Step 3. Page 10)- Can the government provide clarification on how the csv files alone will be evaluated prior to the offeror's presentation in step 4? Subfactor 2a Live Area/Topic Specific Demonstration (.csv Submissions) will be evaluated using tables 3 and 4 of Atch 2 on the following objectives:

Per Step 3 of para 2.1, Offerors assigned a combined technical/risk rating of acceptable or higher will move onto Step 4.

reps and certs on sam.gov. Please confirm the offeror does not have to provide an entire copy of their reps and certs and can instead just comply with 52.212-3

the PAI Alerting Service to 'provide a menu of common interest profiles that automatically set information filters to tailor alerts, based on topics, geographic areas, or urgency of the event.' The corresponding evaluation criterion (Attachment 2, Table 2, Objective 15) describes this as 'Pre-configurability of Common Interest Profiles,' omitting the specific functional requirements the

the PAI Alerting Service to 'certify in writing compliance with data sources' terms of service.' The evaluation criterion for Table 2 Objective 2 (Attachment 2) references 'Compliance with Offeror's

during the Product Demonstration/Oral Presentation. Will the government confirm that this requirement means offerors must demonstrate their actual production environment currently in use by paying customers — including live, real-time data ingestion and alert generation — and that pre-staged scenarios,

By contrast the SOO states, "Certify in writing compliance with data sources’ terms of service."

Similarly, DoDD 3115.18 Section 1.2(j.) states, "j. DoD personnel will comply with terms of service, e.g., those of social media providers, and other contractual obligations..."

However, in Subfactor 2b: Product Demonstration/Oral Presentation on page 17 it states, "The Government intends to evaluate Offerors on Subfactor 2b on the following applicable objectives using the above technical/risk rating method in Table 3" and then goes on to list only those objectives denoted with "Presentation" in Table 2.

While the platform is procured as a general, commercially available alerting resource and is not an exclusive intelligence collection tool, the Publicly Available Information (PAI) alerts it generates may be utilized by authorized DoW personnel to inform their respective missions, provided such use is consistent with the data source's Terms of Service and applicable DoD policies. Solutions that demonstrate broad utility across diverse DoW missions will be evaluated favorably.

Acceptable approaches include, but are not limited to, the examples provided: text-based email or SMS summaries, compressed data payloads, lightweight API polling, or a specific "low-bandwidth/text-only" UI mode for the mobile or web application. Offerors should propose the technical method they believe best achieves reliable alerting in these degraded environments.

However, for the purposes of the Volume II Technical Evaluation, the Government requires a clear understanding of the offeror's data reliance chain to assess the reliability, veracity, comprehensiveness, and durability of the alerting product. While naming every specific data provider is not mandatory, proposals that rely solely on broad categories and fail to provide sufficient detail for the Government to fully evaluate the quality and scope of their data acquisition may be evaluated less favorably.

While the Government strongly encourages the provision of recorded or on-demand training modules as a highly valuable supplemental resource for the enterprise user base, asynchronous on-demand materials do not count toward fulfilling the minimum required cadence of live training sessions.

While offerors may provide analytic enhancements that directly enrich the context of an event-based alert (e.g., geographic mapping of an incident, sentiment analysis, translation), the provision of investigative data such as individual entity records, phone numbers, residential addresses, or derogatory profiling information is likely out of scope for this requirement. Solutions that attempt to provide this type of investigative identity resolution will not receive additional evaluation credit and may introduce unacceptable privacy or compliance risks.

44 General Also, could you clarify whether all 3.5 million users will be designated as investigators, or if a portion of the user base will be utilizing these capabilities for law enforcement permissible purposes? If that's the case, do you think it would be advantageous for the government to have access to law enforcement record management systems for those users, such as calls for service, general crime events like assaults or thefts, and police narrative details? The premise of this question is incorrect based on the requirements outlined in the SOO. The Government is procuring a Publicly Available Information (PAI) alerting platform for general situational awareness across the Department of War (DoW) enterprise.

The SOO does not designate any portion of the user base as "investigators." Furthermore, integration with restricted or sensitive Law Enforcement Record Management Systems (RMS), Computer-Aided Dispatch (CAD) systems, or the provision of police narrative details is not a requirement of this solicitation and is likely out of scope. Offerors should base their technical solutions and pricing strictly on providing the PAI-based event alerting capabilities defined in the SOO.

Objective 10 addresses commercial solutions where external navigation mechanisms or active hyperlinks cannot be fully disabled. If an offeror's proposed commercial platform inherently includes active hyperlinks to source data, the system must, at a minimum, provide a prominent warning and require positive confirmation before the user leaves the secure platform interface to access the external source.

Para 1.12.2. Proposal Due Date: Table 1 Proposal Organization Para 2.2 Volume II Technical The instructions state that offerors are to provide a "product demonstration and oral presentation provided by MS ppt." However, the instructions also state that during the allotted 60 minutes, Offerors will "demonstrate the live capabilities of their product" to address the objectives labeled ‘presentation’ in Table 2.

This has created ambiguity regarding the government’s expectation for the format of the presentation and the role of the PowerPoint slides versus the live software demonstration. To ensure our response is compliant and directly aligned with the evaluation criteria, could the Government please clarify the following.

The Government anticipates the solution will be used in situations such as forward deployments utilizing constrained satellite links, disaster response zones with overwhelmed commercial cellular infrastructure, or areas with only legacy 2G/3G connectivity.

The tool is not required to provide live alerting capability during a complete communications blackout, nor is there a requirement for a fully functional offline "edge" application. The solution must, however, remain functional for alerting and basic interaction (such as reviewing recent text alerts) while operating within the constrained, limited-bandwidth scenarios described above.

The core deliverable of this contract is the timely provision of actionable alerts. While the Government expects an offeror’s underlying technical architecture to utilize multiple data sources and processing capabilities to generate those alerts, the strong preference is for the DoW user to be able to configure profiles and receive comprehensive alerting across all sources from a single, integrated user interface ("single pane of glass"). Proposals offering multiple, disconnected tools that require users to navigate separate interfaces depending on the use case will be evaluated less favorably than a unified alerting platform.

61 PWS §7 Security Instructions; PWS §8.2-8.3; SOO §V.14-16 Will use of the tool need to be obfuscated in any way, and will the tool and/or data need to operate within a classified environment or classified system? No. The proposed alerting tool is not required to be obfuscated (e.g., managed attribution, white labeling), nor is it required to operate within a classified environment (e.g., SIPRNet or JWICS).

The Government is procuring a commercially available alerting tool that resides on the unclassified internet. The platform must be fully accessible from standard, unclassified commercial and DoD networks (NIPRNet). The Government will utilize the required API to independently ingest alert data and manage any subsequent movement into classified environments itself via Government-owned Cross-Domain Solutions (CDS).

While obfuscation is not required, the offeror must implement standard commercial and DoD cybersecurity controls (e.g., TLS encryption) to safeguard the user's connection to the tool and protect all user data, Controlled Unclassified Information (CUI), and Personally Identifiable Information (PII) residing within the platform.

Therefore, a commercially available dataset must possess robust, comprehensive global coverage. The platform must demonstrate the agility and adaptability to ingest, filter, and translate regional or localized news and social media platforms wherever an event occurs, ensuring the DoW enterprise maintains uninterrupted situational awareness worldwide.

65 SOO §V.14-15; PWS §8.3; Additional Clauses With respect to privacy and security compliance, is any third-party assessment, formal certification, or authorization required at the time of proposal submission, at award, or only during performance? No. The evaluation of a proposed solution's security and privacy compliance will be conducted based on the information provided in the proposal at the time of submission. Offerors must certify in writing their compliance with key requirements such as the Privacy Act and DoDD 3115.18, but are not required to have third-party assessment, formal certification, or authorization at time of proposal.

For capabilities hosted in a cloud environment, the offeror must demonstrate how their solution meets the applicable federal and DoD cloud computing security regulations referenced in the SOO (e.g., DFARS 252.239-7010). While a specific third-party authorization (such as a FedRAMP ATO) is not explicitly required to be in-hand at the time of proposal submission to be considered for award, proposals that can demonstrate compliance through existing, authoritative third-party assessments will provide a higher degree of confidence to the Government and may be evaluated more favorably. Any required authorizations must be obtained and maintained throughout the period of performance.