DISR CSO AOI QA 19 May.xlsx
XLSX spreadsheet 24 KB Posted
- Solicitation number
- H9241525X0002
- Issued by
-
United States Special Operations Command
About this file
This file is a Questions and Answers (Q&A) document for the United States Special Operations Command's (USSOCOM) Digital Intelligence, Surveillance and Reconnaissance (D-ISR) Commercial Solutions Opening (CSO) Area of Interest (AOI). The opportunity seeks innovative commercial solutions for agile software development in intelligence mission software, focusing on integrating commercially and publicly available information with classified intelligence data across multiple network domains. Key technical requirements include leveraging DevSecOps pipelines, containerized applications, data engineering services, and AI capabilities, with a preference for specific programming languages like React, Python, Flask, and FastAPI.
Vendors must submit a 6-page white paper by June 6, 2025, at 5:00 PM EST, demonstrating their current solution against the government's technical attributes. The solicitation is structured as an Other Transaction Authority (OTA) agreement with a potential follow-on production award up to $100 million. The prototype demonstration period is estimated at 8 weeks, with the entire process spanning 3-5 months. At least one non-traditional defense contractor is required for successful prototypes. The government will use existing DevSecOps platforms on NIPR, SIPR, and JWICS, including Platform One, DAFCloudworx, AAP, and Clairvoyant, with a focus on developing Government Off-the-Shelf (GOTS) software.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| DISR CSO AOI QA Final 29 May.xlsx | XLSX spreadsheet | |
| DISR CSO AOI 19 May 2025 - Final.docx | DOCX document | |
| DISR CSO AOI QA May142025.xlsx | XLSX spreadsheet | |
| DISR CSO AOI 06 May 2025 - Final.docx | DOCX document | |
| Attachment 01 Go_ No-Go Matrix 6 May 25.rtf | RTF text file |
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
| Industry Question | USG Response | ||||
| While reviewing the SAM.GOV posting for the subject AoI, I noted a discrepancy between the two documents posted with the opportunity. Specifically, the "DISR+CSO+AOI+06+May+2025+-+Final" indicates the following in the Purpose section: "This Other Transaction Authority (OTA) Agreement is focused on new, novel, or disruptive commercial solutions with architectures and technical attributes that can be demonstrated during an estimated 3 to 5-month period with the intent of a follow-on production award through an agile methodology via the DoD Software Acquisition Pathway (DODI 5000.87)." While the "Go No-Go" document indicates: "Submission of a white paper that demonstrates how the offeror plans to meet an 8-weeks prototype demonstration schedule in accordance with AOI Technical Attributes." Can you please clarify the relationship of the 3 to 5-months stipulated in one document with the 8-weeks listed in the other? | The two documents are referring to different processes, but I see how it can be confusing. The 3-5 month period is meant to reflect the entire process prior to production OTA award including white paper, white paper evals, prototype solicitation and award, and prototype performance. 8 weeks is the intended PoP of the prototype project itself once awarded. | ||||
| I am writing to seek clarification regarding the requirements outlined in the CSO for the Digital - Intelligence Surveillance and Reconnaissance (D-ISR) capability. The solicitation emphasizes the importance of leveraging modern software development methodologies, including DevSecOps pipelines, agile development, and human-centered design processes, to accelerate the delivery of integrated solutions. Additionally, the technical attributes highlight the need for containerized applications, data engineering services, and integration of artificial intelligence capabilities. Given the focus on these elements, I would like to confirm whether the Government is seeking a cloud-based software development environment as part of the proposed solution or if the emphasis is solely on the execution of software development activities within existing Government-provided infrastructure. Specifically: 1) | Should the proposal include the design, development, and deployment of a cloud-based environment to support software development activities, such as DevSecOps pipelines, containerization, and AI/ML integration? 2) | Or is the expectation that the performer will utilize existing Government-provided infrastructure and focus exclusively on delivering software development capabilities and services? We are an awardee on two CSOs delivering similar cloud-based capabilities for DevSecOps pipelines so understanding this distinction will help ensure our proposal aligns with the Government’s intent and addresses the requirements effectively. | The expectation is that the performer will leverage existing Government-provided infrastructure and focus exclusively on delivering software development capabilities and services. | ||
| We’re currently evaluating a potential submission and wanted to respectfully request a brief clarification regarding the stated existing DevSecOps infrastructure and pipelines currently supporting the D-ISR program. Specifically, we are interested in understanding: | |||||
| • | The platforms and tools currently in place for DevSecOps (e.g., CI/CD toolchains, container orchestration platforms, code repositories). | ||||
| • | The deployment environments required (e.g., cloud, on-prem, and on-platform at the edge). | ||||
| • | The flexibility available in integrating or adopting alternative secure DevSecOps platforms that are well established in DoD. | ||||
| This context would help us tailor our proposed capability in a way that ensures the greatest alignment and compatibility with the current mission environment. | The government has established DevSecOps platforms on NIPR, SIPR, and JWICS the performer will use. These have been in use for several years and the government is not looking to migrate to a new solution, but may consider it if the platform is more performant and/or more cost effective. The existing platforms being used are Platform One, DAFCloudworx, AAP, and Clairvoyant. Development is a mixture of cloud based and local development. Staging environments are cloud based and mimic the production environment. | ||||
| In reviewing the PEO SDA CSO PM Intel Digital ISR Area of Interest opportunity on SAM, there is a discrepancy between the due date/time of the Phase I white paper submissions. In the cover description on SAM, the due date is listed as Friday, June 6th at 5pm EST. |
However, in the first attachment (DISR CSO AOI 06 May 2025-Final) at the bottom of Page 3 under the Event Timeline section the 6-page Phase I whitepaper submission is listed as being due 12 noon EST Friday, June 6th.
| Can you please provide confirmation of the correct time the Phase I whitepaper is due on Friday, June 6th? | White paper submissions are due June 6th 2025 at 1700. | |
| Our team has experience delivering AI/ML-enabled solutions through agile software development pipelines, and we are very interested in learning more about SDA’s goals for this effort. |
| While we haven’t had the chance to connect before, we would appreciate the opportunity to introduce our technical team and discuss how our experience might align with your mission needs. If you have availability this week, we’d be glad to set up a brief call at your convenience. | Unfortunately, the Government is unable to take individual meetings with regard to the Area of Interest posting. This would be an unfair advantage to other interested parties. If interested in this opportunity, please submit a white paper per the instructions. | |
| We are evaluating our position with regard to submitting a White Paper for the D-ISR Technical Area of Interest and have a few questions: |
| 1. | When do you anticipate requiring resumes for the "integrated support" and "Requirement Capture and Development" requirement? | |
| 2. | Our AI processor is hardware agnostic, Edge compatible and works with legacy systems. It will work with a GPU but it is not necessary. Do you require the use of a GPU? | |
| 3. | What timeline is required to "Ramp Up" our capability following award in order to comply with the 20 plus projects per quarter? | 1. The Government may request resumes during the production phase but at this time not a requirement. 2. The government team has access to GPU but would entertain a solution that is not GPU dependent. 3. 60 days. |
| Quick question about this area of interest. Is the program team open to meeting with industry during the solicitation period? If not, should questions be submitted in writing to the Contracting Officer and Program team? If those instructions are in there and I missed it, my apologies. |
| We are hoping to gain clarification on a specific requirement in the technical attributes section that appears overly restrictive. Based on our experience deploying on government-provided infrastructure, we are aware of alternative approaches that also meet operational and security needs. We’d appreciate the opportunity to better understand the intent of this requirement as we evaluate the opportunity and determine our next steps. | Please submit your questions to Josh, Nicole and myself cced. At this time, we are not meeting with industry. | ||
| We respectfully request clarification on how the response should be submitted, i.e. email, uploaded into SAM.gov, etc. Can you please provide guidance on how the white paper should be submitted? | White papers may be emailed to Josh Cales and Christie Orlando at Joshua.v.cales.ctr@socom.mil and Christie.r.orlando.civ@socom.mil | ||
| As a COTS Program, I’m in a bit of weird spot sometimes, so when I saw “Non-Traditional Defense Contractor Requirement” verbiage in the RFI, I was curious if all respondents must meet the NTDC requirement against this RFI. |
I also saw this was an AOI against the 2025 CSO, but this had some vague language about a possible OT or FAR based award down the road. So I was also wondering if this is a CSO or an OTA.
I had spoken to a few folks at SOF Week when this dropped last week, but trying to understand if this is against a current program as it does mention its aim is to “enhance the velocity of the program”. Is that Program the D-ISR Program of record, and is the request essentially asking for software and capabilities AND engineering services against those capabilities to enhance the D-ISR program? All respondents do not need to be. The Government will need to have at least one non-traditional defense contractor for successful prototypes. You can also team with a non-traditional defense contractor to meet that requirement.
This action would be for an OT. It is nice to have the flexibility to award a FAR contract but that is not the intent for this action.
This is a new requirement supporting program management office Intel under PEO-SDA and J2. This is capability based to enhance the D-ISR requirement.
| In regard to | ||
| • | Paragraph 2a. Required Technical Attributes | |
| o | sub-bullet #4 Software Development |
why does it appear that React, Python, and Flask, Application Programming Interface (FastAPI), and Streamlit the only options allowed?
Will the government consider a submission that includes other containerized, modern, enterprise programming languages that meet DOD security standards, meet the functional needs of the platform or mission, and supports the interoperability requirements of SOCOM?
TLDR:
shouldn't mainstream enterprise programming languages that meet the DOD security standards be allowed? If the solution meets the functional or operations needs of the platform, and it supports any interoperability requirements SOCOM has, then isn't the goal of real modernization achieved for the SOCOM mission?
Additional context Great programming is about using the right language for the right job. An enterprise solution necessitates using a few languages. We use Python and understand why this would be one of the preferred languages; however, SOCOM should know that best-of-breed engineers are polyglots and optimize code utlized by workload. Other languages that are extremely common in the DoD/enterprise world include:
| 1. | Go (Golang) |
| 2. | NodeJS |
| 3. | Typescript |
| 4. | ...all of which are used in DoD/IC for TS/SCI applications today. |
| • | For ML-based solutions Python is the best choice because of the speed at which you can get the solution built. |
| • | For distributed systems, APIs, and micro servicesm then Go is the best choice. Go is built around those things, and while you won’t be able to slap together quick solutions as Python might let you for smaller-scale stuff, in the long run Go will stay consistently manageable while Python libraries might begin to trip over themselves and become increasingly hard to trace/maintain. |
| 2. | As part of this area of interest, is SOCOM considering COTS purpose-built by a govtech for this type of mission? | 1. | The government already has the security posture for these languages/frameworks and CtF’s/ATO’s in place. Getting new ATO’s is a time consuming and laborious process that is not conducive the rapid development and fielding required by SOCOM’s mission. The government is also not interested in refactoring dozens of existing applications into a new code base. |
| 2. | Software developed under this OTA will be considered GOTS. | ||
| 1. | Will this new requirement be expected to develop completely new applications and software, or develop enhancements and tools against existing baseline software utilized by the TSOCS and the D-ISR program? |
2. With respect to this being Software development work against the D-ISR program and requirements, what are the existing Software baseline/tools that are expected to be developed against on this program?
3. Will the government entertain software as part of the submission (ie existing ISR software utilized and deployed by SOCOM that the D-ISR program can develop against to enhance emerging ISR data and capability requirements?)
4. Will the DevSecOps team be developing against GOTS or COTS software? 1. Both
2. Existing tools are built with the following frameworks and technologies (not exhaustive but representative) – React, Streamlit, FastAPI, Flask, Ollama, Postgres, Elastic.
3. Yes, but the program has a substantial preference for GOTS software
4. GOTS
Based on the requirements for the white paper, along with the Go/No Go criteria, we believe the current page count may be insufficient to meet the government’s requirements and provide an easy-to-understand solution. For example, Go/No Go Criteria #3 (Software Component Assessment) requires a “comprehensive assessment” for 7 distinct functional requirements that on its own could take 6 pages to properly cover. Also, Go/No Go Criteria #4 (SBOM) requires a "detailed inventory of all software components," a list that could take up several pages by itself. We don’t question the need for this information, however, adequately complying with these and all the other requirements will take more than 6 pages.
We would recommend one of three COAs:
1. Remove the criteria to provide the detailed information for the Go/No-Go criteria until after the submission of an initial white paper and after down selection.
2. Exclude the information required for the Go/No-Go criteria from the page count, and have offerors develop their own method or template to cover it. This would be like a configuration management plan that would be expected from a company during the execution of the contract.
3. Increase the page limit to 25 pages.
| In all cases, would the government consider allowing offerors to provide the SBOM in MS Excel Spreadsheet format? | We will exclude information necessary to meet the requirements of the go/no go matrix from the page count. | ||
| For ease of readability and formatting, would the government please consider allowing graphics and tables to be presented in a smaller font such as 8pt ? | No | ||
| Can we include the SBOM (including naming each OSS component) -but- only summarize the assessments as a collective set? This would allow us to meet the page count requirement. | We will exclude information necessary to meet the requirements of the go/no go matrix (ie the SBOM) from the page count. |
File details come from the government source that posted it. Updated .