saber_vendor_responses_redacted.pdf

Relevant

SOO

Question Government Response

1.0

The scope of the prototype system is to collect a Subject’s information, executes a background investigation and records an adjudication decision. Continuous vetting is not in scope of the prototype. (4.2 states that vendor to build a prototype software product, which addresses the need to consolidate all parts of the personnel vetting process). Please confirm.

This prototype system is intended to focus on the holistic process of vetting an applicant through the entire lifecycle, from their initial processing for a clearance through investigation, adjudication, and maintenance. Enrollment in continuous evaluation through integration with existing Government systems will be a part of the prototype, but the prototype itself will not be expected to be performing continuous vetting. However, good engineering practices should be used to ensure that the system remains flexible in the face of potential future requirements.

1.0 The prototype requires integration with a wide variety of U.S. Government and commercial databases, could you specify which mandatory data sources from Government and commercial will be required for the prototype?

The complete list of databases/APIs will be provided post-award, but an order-of-magnitude estimate is 5-15 sources, a mix of both commercial and government.

1.0

Is average turnaround time [for completing an investigation and suitability/security eligibility determination] the primary KPI the Government seeks to improve?

Turnaround time for completing an investigation and making an eligibility determination is a very important KPI, but it must be balanced against the accuracy and comprehensiveness of the investigation, system scalability, user experience, and more.

1.0 Has the Government identified a target average turnaround time [for completing an investigation and suitability/security eligibility determination]?

Yes; through an integrated approach involving reforms to policy, process, and software, the Government expects this prototype solution to play a significant role in reducing the turnaround time for investigations and eligibility determinations, from 1+ year to a matter of days or weeks.

1.0

Which information systems currently in place does DSS intend to replace as a result of NBIB realignment?

The prototype system is not intended to replace any existing system from NBIB. Consistent with guidance published in the President's Reform Plan and Reorganization Recommendations, the SABER prototype will explore innovative, bold, transformative reforms to the way the personnel vetting mission is carried out. Importantly, SABER will be a testbed for new technologies that can be used without hindering or otherwise impacting ongoing initiatives. This prototype will also be used by DDS and the Undersecretary of Defense for Intelligence to assist in meeting the requirements of the National Defense Authorization Act as mandated by Congress.

1.0 When can we expect to be notified of participation in the technical challenge and onsite interview?

The Government estimates technical challenge notification to occur by April 11th, with onsite interviews occurring between April 21st and 22nd. Scheduling details for the onsite interview will be released with the technical challenge notification, if selected.

1.0 Can the government provide an understanding of the expected legacy integrations within the proposed award period?

The prototype solution may integrate with existing background evaluation systems for the purposes of synchronizing information about the test population between the prototype and the systems of record, however, the Government does not anticipate more than one or two of these integrations.

1.0 If legacy system integrations are required, can the government support additional engineering hours for discovery and integration with these NBIS systems? (e.g. e-

QIP)?

Yes, though the Government expects to provide most of this.

1.0

How does the work being implemented by other organizations like NBIS, OPM, etc.

impact this initiative? Will those organizations continue to own some part of the Background Investigation program or suite of systems?

The prototype system is not intended to replace any existing system from NBIB. Consistent with guidance published in the President's Reform Plan and Reorganization Recommendations, the SABER prototype will explore innovative, bold, transformative reforms to the way the personnel vetting mission is carried out. Importantly, SABER will be a testbed for new technologies that can be used without hindering or otherwise impacting ongoing initiatives. This prototype will also be used by DDS and the Undersecretary of Defense for Intelligence to assist in meeting the requirements of the National Defense Authorization Act as mandated by Congress.

1.0

There is a portion of background investigation work which includes writing the policy and vetting the questions that are asked as well as the language. Is this also being pulled under DOD/DSS? Are any parts still owned by OPM?

The policies that dictate investigation processes and priorities, including the questions asked of subjects, are defined through coordination between the Suitability Executive Agent (OPM), and the Security Executive Agent (Director of National Intelligence), with input from many other agencies. This prototype may inform changes to personnel vetting policies, which the Defense Digital Service will work to suggest and implement as appropriate.

1.0

What is the DSS mitigation plan to address the controls on content and wording currently inherited from the Paperwork Reduction Act (PRA) and other legacy policy?

The Defense Digital Service is intimately familiar with the PRA and legacy policy surrounding background investigation processes. A primary objective of SABER is to serve as a platform for experimentation to help guide the Suitability Executive Agent (OPM) and Security Executive Agent (DNI) in making new policy decisions where necessary. DDS will work in coordination with the Defense Security Service and the Under Secretary of Defense for Intelligence on the development of new policies.

1.0

Our research has determined that [PRA] restrictions provide a major blocker to readability/usability for the intake of background investigation information from a Subject. Does the DSS team have access and authority to evaluate these blockers and make recommendations?

The user research and usability testing methods used for the development of the prototype will take into consideration PRA restrictions, and the Defense Digital Service team will use all access and authorities available to conduct robust vetting of the prototype.

1.0 Who can help us navigate and improve policy? Can we apply user research to this area as well?

The Defense Digital Service team will be partnering with the selected vendor(s) to assist them in understanding the current policy landscape. We look forward to partnering to apply user research in this area.

1.0

Who acts as the product owner on this project? What access do they have to stakeholders who can unblock the team? Does this have Joint Staff or high-ranking General support?

The Defense Digital Service is providing product leadership on this project. DDS has extensive access to high-ranking Government officials, both inside the Department of Defense and at other agencies relevant to this process. This project is primarily sponsored by executive leadership in the the Office of the Under Secretary of Defense for Intelligence and the Defense Security Service.

1.0 Who are the IT and security stakeholders? Will we have access to them from day 0?

How much attention will they pay to this effort?

Engineers from the Defense Digital Service will be the primary IT and security stakeholders for the prototype project, and will be intimately involved with the project from kickoff through delivery.

1.0

What kind of access to users do we expect? Is there already a group identified for an MVP/pilot? Or is that work that still needs to be done? Any candidates?

We expect to have access to all necessary user groups for successful prototype design and development. The pilot population has yet to be defined for the MVP, and the vendor will work together with the Defense Digital Service in this area. Once a decision is reached, the Defense Digital Service will conduct the necessary coordination to ensure access to the desired user groups.

1.0

Is there a vision? Are there articulated goals in terms of impact? Who is bought in at which level?

User research, as a component of the user-centered design approach, to this point has identified several areas of opportunity for this prototype as outlined in the SOO; the selected vendor(s) will have the flexibility to conduct further research necessary to understand details of the project scope. Executive-level leadership from across the Department of Defense is bought in on this prototype effort.

1.0 Are there user research artifacts and example stories? Yes; a variety of user centered design research artifacts, from user journey maps and personas, to user stories and academic studies, will be made available by the Government upon award. The Government anticipates the selected vendor may wish to conduct additional user research as well.

1.0

The SABER Statement of Objectives states that the “project will be executed in a manner consistent with best practices from the Digital Service Playbook and the TechFAR Handbook.” The TechFAR Handbook states “Agile software development is intended for activities that require significant software design and development.

Many IT needs can be met with commercially available off-the-shelf items and commoditized services, such as subscription services for software licenses, with little or no development work. In those cases when development is not needed, the Government is best served by purchasing commercially available off-the-shelf items.” Considering this information, why is the government focusing its efforts on a development project instead of the implementation of existing commercial products that can be configured to fulfill the requirements?

DoD received mandates from the President and Congress to work with the Security and Suitability/Credentialing Executive Agents to revamp the fundamental approach and supporting policy framework, overhaul the business process, and modernize the information technology architecture for the Federal government's vetting of the Nation's trusted workforce. While market research indicated that there are a variety of commercially available case management or customer relationship management systems related to personnel vetting, the products currently are not flexible enough to address the specific mandates from the President and Congress to achieve bold and transformational reform. As such, the Department determined that utilizing other transactional authority in 10 U.S.

Code § 2371b to create a prototyping platform capable of rapid iteration to enable the testing of bold and transformational reforms that would best meet government requirements for this particular acquisition.

1.0

Given the TechFAR guidance, would the Government consider accepting RWP responses proposing the use of a commercially available off-the-shelf item that can be configured to fulfill the SABER objectives and requirements? If not, will the Government be performing separate market research to evaluate the availability of such commercial item solutions that meet SABER objectives?

Yes. The government will evaluate all RWP responses according to the evaluation criteria and process outlined on https://dds.mil/opportunities/saber/. Additionally, as the Government prototypes both policy and technology changes to the DoD vetting process, it will continue to evaluate the market for the potential for commercial items solutions that might meet the Department's overall requirements as they are developed.

1.0

What market research was completed by OUSD(I), DSS, or DDS that determined commercial items could not meet the SABER's objectives, as required by 10 U.S.

Code § 2377?

DoD received mandates from the President and Congress to work with the Security and Suitability/Credentialing Executive Agents to revamp the fundamental approach and supporting policy framework, overhaul the business process, and modernize the information technology architecture for the Federal government's vetting of the Nation's trusted workforce. While market research indicated that there are a variety of commercially available case management or customer relationship management systems related to personnel vetting, the products currently are not flexible enough to address the specific mandates from the President and Congress to achieve bold and transformational reform. As such, the Department determined that utilizing other transactional authority in 10 U.S.

Code § 2371b to create a prototyping platform capable of rapid iteration to enable the testing of bold and transformational reforms that would best meet government requirements for this particular acquisition.

1.0

Has the government made a determination that existing commercial items do not exist or could not be modified to meet the requirements of this prototype?

DoD received mandates from the President and Congress to work with the Security and Suitability/Credentialing Executive Agents to revamp the fundamental approach and supporting policy framework, overhaul the business process, and modernize the information technology architecture for the Federal government's vetting of the Nation's trusted workforce. While market research indicated that there are a variety of commercially available case management or customer relationship management systems related to personnel vetting, the products currently are not flexible enough to address the specific mandates from the President and Congress to achieve bold and transformational reform. As such, the Department determined that utilizing other transactional authority in 10 U.S.

Code § 2371b to create a prototyping platform capable of rapid iteration to enable the testing of bold and transformational reforms that would best meet government requirements for this particular acquisition.

1.0

Has the development of this RWP incorporated review of market research prepared for previous RFIs related to the National Background Investigation Bureau, including Solicitations “PL83240005” and “841812431_DISA_NBIS”?

DoD received mandates from the President and Congress to work with the Security and Suitability/Credentialing Executive Agents to revamp the fundamental approach and supporting policy framework, overhaul the business process, and modernize the information technology architecture for the Federal government's vetting of the Nation's trusted workforce. While market research indicated that there are a variety of commercially available case management or customer relationship management systems related to personnel vetting, the products currently are not flexible enough to address the specific mandates from the President and Congress to achieve bold and transformational reform. As such, the Department determined that utilizing other transactional authority in 10 U.S.

Code § 2371b to create a prototyping platform capable of rapid iteration to enable the testing of bold and transformational reforms that would best meet government requirements for this particular acquisition.

1.0 Please provide a list of the referenced government / commercial databases that the prototype will be integrated with.

The complete list of databases/APIs will be provided post-award, but an order-of-magnitude estimate is 5-15 sources, a mix of both commercial and government.

1.0 & 4.1.2

The 'Data rights' section and the 'Digital Services Playbook' calls for open source software. Would a commercial proprietary offering with open source components be an acceptable solution?

The Government may require that the custom software developed under this project be available for public release as open source software. The Government is open to integration of proprietary commercial off-the-shelf components, as appropriate, subject to negotiation of suitable data rights.

1.0 & 4.1.2

Are you open to us leveraging Open Source code? Very! In fact, per §4.1.2 of the SOO, the Government may require that additional software developed under this contract be released as open source code.

1.0 & 8.0 Can DDS provide a complete list of applications that the new prototype solution will need to integrate with?

The complete list of databases/APIs will be provided post-award, but an order-of-magnitude estimate is 5-15 sources, a mix of both commercial and government.

3.0 Does the Government plan to provide the "existing Government-provided research" ahead of the prototype development and/or the technical challenge?

The Government intends to provide said research to the selected vendor during prototype development, but not ahead of the technical challenge. The Government encourages the use of all publicly available research and findings on the matter.

3.1 Is there a posting somewhere of all other questions from vendors? Yes. All answers will be posted at https://dds.mil/opportunities/saber/questions/.

3.1 Do descriptions of relevant experience for key personnel count toward total page count of no more than 10 pages?

Yes. The Government holds a firm 10-page limit on the page count.

3.1 The SABER SOO states the response should be submitted by March 26th. Could you please clarify the time deadline for submissions?

White papers must be submitted to the Government by 11:59:59PM EDT on March 26, 2019.

3.1 Given that all of these questions have significant material impact to our OTA white paper response, can you please indicate when the Government will be providing answers?

Yes. All answers will be posted at https://dds.mil/opportunities/saber/questions/ .

3.1 If the answers are not forthcoming within the next 24 hours, would the Government consider an extension of the 26 March white paper submission deadline?

Yes; the deadline has been pushed back to match the original amount of time for vendors to respond after the responses are posted. Please visit https://dds.mil/opportunities/saber for more information.

3.2

The award recipient is to build prototype software which meets general and technical requirements as listed in the Statement of Objectives. Certain types of data used for background investigations, such as credit risk and employment data are regulated by federal law and contract data usage rights.

Question: Will the Defense Security Services (DSS) allow flexibility in the Technical Challenge Demonstration and Review in the demonstration of capability involving data deliverables where federal law permits screening for employment purpose but not as a test?

The Technical Challenge Demonstration is intended as a demonstration of the vendor(s)' competency, not a demonstration of a working prototype. It will intentionally be focused outside of the background investigation field and will not require access to any data other than test data provided by the Government as part of the challenge.

3.2 Does the Government estimate an approximate level of effort required to complete the technical challenge to be approximately seven days for one FTE (e.g. ~56 hours)?

The Government cannot estimate an approximate level of effort required for the technical challenge, as the purpose of the challenge is to solicit diverse approaches to solving the problem to be provided. As a result, different approaches may require varying amounts of effort.

3.2 Can the government provide any additional detail as to the scope of the technical challenge to best align resource planning? Quantity of tasks to be requested or more detail regarding the the tasks to be completed?

No. Details of the technical challenge will only be released at the start of the challenge period to vendors who are selected for further evaluation.

3.2 Can the government provide any additional detail as to the timing of the technical challenge to best align resource planning?

The Government estimates technical challenge notification to occur by April 11th, with onsite interviews occurring between April 21st and 22nd. Scheduling details for the onsite interview will be released with the technical challenge notification, if selected.

3.2 Does the Government plan to provides SMEs to the teams as part of Technical Challenge?

No. The Technical Challenge must be performed entirely by the vendors selected to participate.

3.4

On FBO, the government indicates offerors will be evaluated on an integrated assessment of criteria, including “5. Affordability of proposed solution.” The template white paper template attached to the posting does not contain a section for offerors to provide affordability information.Would the government please clarify what information offerors should include to address this evaluation criteria and where in the template the government would like it addressed?

Please do not include pricing information in the white papers submitted to the Government. If selected for additional consideration, the Government will request a full proposal, to include pricing data (See SOO §3.4)

3.5 When do you expect to select? When do you expect to award? Is there flexibility to negotiate a contract start date in order to field the best delivery team?

The Government intends to select a vendor(s) around the last week of April. Contract award will take a few weeks, subject to proposal negotiations and availability of funds. The Government is open to negotiating a contract start date as part of the proposal process, to ensure vendors are able to align timelines appropriately.

4.1.1 If the level of security for this task is unclassified, how will the integration with certain sensitive or classified databases/systems/information sets be accomplished?

SABER will be kept at an "UNCLASSIFIED // FOR OFFICIAL USE ONLY" level and will not process any classified data.

4.1.2

Our team would like to learn more about the request to provide source code as outlined in 4.1.2. We understand the goal of creating an open and viable platform that can be leveraged and shared within government, and fully commit to sharing any “code” authored to support the specific solution for DSS. However, will the Government accept a solution that is built on a Platform-as-a-Service architecture such as Salesforce, ServiceNow or Appian as long as the application is architected in such a way that it can be packaged and released to other subscribers to the underlying platform?

The Government may require that the custom software developed under this project be available for public release as open source software. The Government is open to integration of proprietary commercial off-the-shelf components, as appropriate, subject to negotiation of suitable data rights.

4.1.2 Will the government clarify its stance on data rights to detail how it plans to accommodate a solution that takes advantage of existing software?

The Government may require that the custom software developed under this project be available for public release as open source software. The Government is open to integration of proprietary commercial off-the-shelf components, as appropriate, subject to negotiation of suitable data rights.

4.1.2

Will the government modify its solicitation to allow commercial items to compete by clarifying the data rights assertion to ensure a vendor's intellectual property can be protected in line with the requirements of FAR 12.211?

This procurement is being conducted under Other Transaction authorities; FAR Part 12 is a separate procurement structure that does not apply to this procurement. The Government, however, is open to integration of proprietary commercial off-the-shelf components, as appropriate, subject to negotiation of suitable data rights that could include substantially similar language to that found in FAR Part 12.

4.1.2

OEM COTS software products often come with certain data rights assertions, some of which may prevent us from offering unlimited copyright and/or open source code rights to the Government. Is it the government’s intent to have the prototype constructed completely from open source software products, or will the government consider an arrangement which protects the data and intellectual property rights of OEM software providers?

The Government may require that the custom software developed under this project be available for public release as open source software. The Government is open to integration of proprietary commercial off-the-shelf components, as appropriate, subject to negotiation of suitable data rights.

4.1.2 & 4.2.1

Please confirm that for the components in paragraph 4.2.1 that all three of the environments can include commercially available software products in a commercial cloud hosting environment and that the intellectual property terms discussed in

4.1.2 would cover only the code developed under this project and not include unlimited rights to any commercial software products that are part of any of the environments.

The Government may require that the custom software developed under this project be available for public release as open source software. The Government is open to integration of proprietary commercial off-the-shelf components, as appropriate, subject to negotiation of suitable data rights.

4.2 Can open source platforms like a DLT and/or a blockchain be used as part of the proposed solution?

The Government is open to considering all technologies as part of this prototype. Open source software may be used as part of the SABER prototype.

4.2 “Award recipient will build a prototype software product, which addresses the need to consolidate all parts of the personnel vetting and security clearance adjudication process” Can we confirm that this covers the full gamut of investigations?

The Prototype will focus initially on new clearances at the Tier 5 level, but the Government may elect to prioritize the support of other forms of adjudications during the normal course of its oversight.

4.2

We believe that the cloud hosting controls at DoD Impact Level 4 requirement will greatly hinder the ability for the prototype application to be developed and delivered in a modern and iterative way. Can the government confirm that there will be an opportunity to discuss and shape the solution for infrastructure?

You're not going to get any argument from the Defense Digital Service team that the DoD IL-4 requirements can make things difficult to do in a timely manner! However, DDS has extensive experience in this area and anticipates the vendor having extensive opportunity to make decisions around the infrastructure solutions.

4.2

Facilitates Subjects’ enrollment in Continuous Evaluation; What is the expected timeline for the agency to support Continuous evaluation, is the expectation that these features will be outside of the initial 9 month period?

This prototype system is intended to focus on the holistic process of vetting an applicant through the entire lifecycle, from their initial processing for a clearance through investigation, adjudication, and maintenance. Enrollment in continuous evaluation through integration with existing Government systems will be a part of the prototype, but the prototype itself will not be expected to be performing continuous vetting. However, good engineering practices should be used to ensure that the system remains flexible in the face of potential future requirements.

4.2

What percentage of the work assigned to the team will be in supporting these experiments vs. building out new features and managing tech debt?

The prototype will be focused on building new features and performing experiments with changes to the vetting workflow. The selected vendor(s) will not be responsible for maintaining any existing systems except insofar as they may need to integrate with them.

4.2

We understand that the period of performance and the NTE budget are both defined by the government for this project. As these variables are defined, can the government confirm that there will be a regular evaluation of scope and definition of success so that we can maintain an agile delivery of the prototype as we continue to engage in research and discovery?

The Government is open to regular evaluation of scope and definition of success, so long as the prototype product meets the broad requirements specified in the SOO §4.2.1, "The final, shipped prototype is defined as the Minimum Viable Product capable of collecting Subject’s information for a specified population, executing a background investigation of a specified type (including automated record checks, deconfliction/entity resolution, and manual investigation notes entry), and recording an adjudication decision..."

4.2 Will the selected vendor have an opportunity to participate in the scoping process defining deliverables prior to them becoming part of the prototype definition?

Yes. The Defense Digital Service team will play an active role in coordinating scope and deliverables with the vendor

(s) at each step of prototype definition.

4.2

Is the government open to re-evaluating the period of performance based on discovery and agreed upon scope?

The period of performance is fixed as defined in the SOO, however, the Government is open to regular evaluation of scope and definition of success, so long as the prototype product meets the broad requirements specified in the SOO §4.2.1: "The final, shipped prototype is defined as the Minimum Viable Product capable of collecting Subject’s information for a specified population, executing a background investigation of a specified type (including automated record checks, deconfliction/entity resolution, and manual investigation notes entry), and recording an adjudication decision..."

4.2 How is the government considering limiting the use case for the initial prototype to focus on a single type of user and a minimal set of functionality?

The government intends to identify a target user population in coordination with the vendor, and to focus the scope of the prototype on delivering value to said user group.

4.2

Is this prototype to do the complete end to end background investigation and adjudication or just a specific portion of it?

As stated in the §4.2.1 of the SOO, the final, shipped prototype is defined as the Minimum Viable Product capable of collecting Subject’s information for a specified population, executing a background investigation of a specified type (including automated record checks, deconfliction/entity resolution, and manual investigation notes entry), and recording an adjudication decision subject to the software principles listed in the SOO.

4.2.1 What are some of the AI/Analytics requirements? Are AI/Analytics capabilities considered core to automate / improve efficiencies in some of the process?

The Government is open to considering all technologies as part of this prototype.

4.2.1 Would the prototype solution have access to historic background evaluation data?

What are the volumes and types of data that will be made available during the prototype phase?

The prototype solution may integrate with existing background evaluation systems, however, a migration of historical data from other background evaluation systems is not anticipated as part of this prototype.

4.2.1 In reference to: "Robust, secure integrations with various U.S. Government and commercial data" Question: What types of databases/APIs will we need to integrate with?

The complete list of databases/APIs will be provided post-award, but an order-of-magnitude estimate is 5-15 sources, a mix of both commercial and government.

4.2.1 In reference to: "Adaptable/compatible with all commercial/Government software and upgrades" Question: Can you please describe the software and upgrades further?

Good engineering practices should be used to ensure that the system remains secure, updatable, and flexible to future requirements.

4.2.1

Are we dealing with asking an API for more data about a person? Or are there large volumes of data processing needed?

The prototype must query APIs to gather data about individual subjects (people), as well as process data to de-duplicate potential derogatory information, perform identity resolution, as well as a variety of other data processing tasks. Though the Government does not anticipate large amounts of bulk data processing that would require the use of specialized tools such as map/reduce, etc., it remains open to considering all technologies as part of this prototype.

4.2.1 Can we get some examples of [U.S. Government and commercial] data sources or integration targets?

The complete list of databases/APIs will be provided post-award, but an order-of-magnitude estimate is 5-15 sources, a mix of both commercial and government.

4.2.1 Can we use login.gov? The Government is open to considering all technologies as part of this prototype.

4.2.1 Are there any restrictions on using hosted SaaS products such as CircleCI or CodeClimate to support this project?

The Government is open to considering all technologies as part of this prototype.

4.2.1

Can the government clarify which desktop and mobile platforms should be supported? Please include versions and browsers where applicable.

The prototype should be a mobile-responsive, web-based software application compatible with (at a minimum) the following browsers and platforms:

Google Chrome (latest) Firefox (latest) Internet Explorer (9.0+) Microsoft Edge (latest) Safari (latest) Mobile Safari (iOS 12+) Google Chrome (Android)

4.2.1 Does the government anticipate subjects to enter their biographic/SF86 data directly into SABER?

The Government anticipates that the prototype solution will experiment with different methods of collecting, confirming, and retaining subjects' biographical/SF-86 data. Some experiments may involve subjects entering the data directly into SABER, confirming retrieved data, and/or leveraging external systems to complete the SF-86.

4.2.1 Does the government anticipate the SABER platform to be able to generate reports of investigation (ROI)?

The Government anticipates that some form of finalized investigative and adjudicative products will be generated, though the form has not yet been decided.

4.2.1

Can the Government provide documentation on the full lifecycle of the Background investigation, or will the team need to perform Business Process analysis to flush out the to-be business process that will need to be automated?

Yes, the Government has documentation in a variety of formats, from its own user-centered design research. The Government anticipates the selected vendor may wish to conduct additional user research as well, as part of its own user-centered design approach to problem solving and prototype development. The Government will provide the vendor with this research upon award.

4.2.1 How many external data sources have been identified that are required to be integrated into the solution? Can it be assumed that all integrations will be done via RESTful services?

The complete list of databases/APIs will be provided post-award, but an order-of-magnitude estimate is 5-15 sources, a mix of both commercial and government. The Government expects integrations may include non-RESTful services.

4.2.1 Will data or data pertaining to a subject become classified during the [personnel vetting] process and need to transferring/integrated with a System on SIPR or

JWICS?

SABER will be kept at an "UNCLASSIFIED // FOR OFFICIAL USE ONLY" level and will not process any classified data.

4.2.1 Are the data sources available to vendor to use from the onset? The Government will ensure that the vendor has access to data sources as part of the regular agile prioritization process.

4.2.1 Is there a backlog of functionality already defined that this prototype will build out? Some amount of functionality has been developed, but the Government has intentionally not developed a full backlog as we want to involve the selected vendors in the prioritization and ideation process.

4.2.1 Are there any preferences for tools to manage the production environment (tools for monitoring, dashboard applications, etc.)?

The Government is open to considering all technologies as part of this prototype.

4.2.1

Can the Government please document and provide the high level requirements for a minimally viable product?

As stated in the §4.2.1 of the SOO, the final, shipped prototype is defined as the Minimum Viable Product capable of collecting Subject’s information for a specified population, executing a background investigation of a specified type (including automated record checks, deconfliction/entity resolution, and manual investigation notes entry), and recording an adjudication decision subject to the software principles listed in the SOO.

4.2.1 Will the Government provide synthetic data for demonstration and evaluation of the developed prototype or will the contractor be required to generate synthetic personnel data?

The Government will arrange for real personal data to be used as part of the experimentation with processes and procedures in the production environment. The vendor should create any synthetic data needed for development and/or testing environments.

4.2.1 Will the government be providing test data, or is the contractor expected to create test data?

The vendor should create any synthetic data needed for development and/or testing environments.

4.2.1 For automated records checks, what systems will the prototype need to interface with?

The complete list of databases/APIs will be provided post-award, but an order-of-magnitude estimate is 5-15 sources, a mix of both commercial and government. The Government expects integrations may include non-RESTful services.

4.2.1 For automated records checks, will the systems providing records be available to interface with the MVP or will simulation be required/allowed?

The Government will provide access to the necessary interfaces. In the event that a desired data source is unavailable during the 9 month contract term, simulation may be used at the direction of the Government.

4.2.1 For the integrations with various U.S. Government and commercial data sources, will those data sources be made available to the prototype?

The Government will provide access to the necessary interfaces. In the event that a desired data source is unavailable during the 9 month contract term, simulation may be used at the direction of the Government.

4.2.1 & 7.0

Will cloud infrastructure residing within the NIPR network boundary be provided for the prototype demonstrations given the requirement of leveraging IL-4 infrastructure?

Context: Per the DISA Cloud SRG, IL-4 data and services must reside within 1- a cloud environment with a provisional IL-4 FedRAMP accreditation AND 2- within the DISA NIPR network boundary monitored by the DISA Cloud Access Point (CAP).

Access to running services behind the CAP require agency sponsorship, credentials and enterprise services to consume.

Perhaps the SABER prototype is meant to be demonstrated within a cloud footprint with a provisional IL-4 and the network access remain external to NIPR IP space and therefore accessible through secure comms and credentials emulating NIPR boundary protections, adhering to IL-4 ATO requirements.

The Government will work with the selected vendor(s) to provide access to DoD networks as appropriate (e.g., DISA CAP, NIPRNet, etc.). As per SOO §7.0, the Vendor must procure or provide any necessary components of their development, test, and production environments through a commercial cloud provider. The commercial cloud platform must have a DoD IL-4 accreditation at time of award.

If you're not sure what any of the above means, don't worry! The only thing that must be included at the time of proposal is a choice of which commercial cloud providers that offer DoD Impact Level 4 (IL-4) accreditation you've selected. If you're not sure whether your favorite cloud provider is covered, ask them; many of the major cloud providers hold this certification. More information is available at https://iase.disa.mil/cloud_security/Pages/index.aspx.

4.2.2 Does the government anticipate that DoD CAF or other adjudicators to operate within the SABER platform or is the system designed to maintain the outcome of the adjudication rather than perform their job duties within the platform?

The Government anticipates that adjudicators will operate within the SABER platform to some extent, thought experiments will also cover automated adjudication through business rules.

4.2.2 Does the government anticipate the need for the SABER platform to allow a variety of ISP investigators to operate within the platform?

No; SABER will be a testbed for new technologies that can be utilized without hindering or otherwise impacting ongoing initiatives. Its focus is on experimenting with real cases to drive policy and technical decisions, not to sustain the operational needs of the DoD for investigations and adjudications.

4.2.2 Does the government anticipate the SABER platform to be the system for investigators to enter their investigative findings?

The Government anticipates that the prototype solution will experiment with different methods of collecting information from investigators, including direct entry into SABER.

4.2.2 How many potential users and different roles will be needed? The Government anticipates that several different types of user groups will be needed and will communicate full details to the selected vendor.

4.2.2

Is the expectation that this prototype system join existing systems, integrate existing systems or replace all systems for the personnel vetting process? Systems in question: eQIP, eAPP, DISS, JPAS, SWFT, MIRADOR.

The prototype system is not intended to replace any existing system from NBIB, NBIS, etc. The SABER prototype will explore innovative, bold, transformative approaches to the way the personnel vetting mission is carried out.

Importantly, SABER will be a testbed for new technologies that can be utilized without hindering or otherwise impacting ongoing initiatives. The SABER prototype is being developed in coordination with the Office of the Under Secretary for Defense for Intelligence and the Defense Security Service.

4.2.3

What is the "streamlined process [for ATO]" referenced here and what are the high level expectations for the vendor?

At a high level, the vendor will be required to produce a variety of documentation on the privacy and security approaches that they are taking for the development, hosting, and maintenance of the SABER prototype. Additionally, the vendor will be required to produce artifacts and specific documentation for the ATO in coordination with the Defense Digital Service. However, the Government does not anticipate requiring the vendor to complete the full Risk Management Framework (RMF) control documentation.

4.3 What are the reporting requirements associated with this OTA prototype? The reporting requirements are defined in §4.3 of the SOO.

5.0 After the 9 month period is over, would you like our team to provide maintenance for the project?

Per §5.0 of the SOO, the Government may award a follow-on contract for further development services, expansion of scope, and/or maintenance upon successful delivery of the prototype under this contract.

5.0 What is period of performance for this OTA and what are projected start and end dates?

The Government intends to select a vendor(s) around the last week of April. Contract award will take a few weeks, subject to proposal negotiations and availability of funds. The Government is open to negotiating a contract start date as part of the proposal process, to ensure vendors are able to align timelines appropriately.

6.0

Please clarify the following statement: "All contractor personnel must be capable of being cleared to enter a DoD space per applicable DoD and Pentagon Force Protection Agency standards." does this mean that background investigations of contractor personnel will be required? Will we be receiving CACs for critical staff who regularly enter DoD space?

A Tier 1 (NACI) check will be performed on all vendor personnel that require access to Government facilities. CACs may be issued at the Government's discretion to personnel that require frequent access to Government spaces.

6.0 Does the government anticipate personnel working on this contract will require a [Top Secret] clearance?

No. The Government does not anticipate requiring clearances for personnel working on this contract. They may be required, however, to receive a criminal background check (Tier 1 / NACI) if they need access to DoD facilities.

6.0 Is there a facility clearance required for this engagement? No, a facility clearance is not required for this engagement.

6.0 Will the scrum team members require a completed background investigation before they can support this project?

No, contractor clearances are not necessary before they can support this project. A Tier 1 (NACI) check will be performed on all vendor personnel that require access to Government facilities.

7.0 Who will be required to pay for hosting and software costs? Per §7.0 "Government-Furnished Equipment": the vendor is required to provide commercial cloud hosting and associated software as part of this contract. Costs for these materials should be included as part of the vendor's proposal.

7.0 What portions of the prototype solution will be provided as GFE? Please consider items such as DevSecOps tools, ITSM tools, help desk tools, application monitoring tools, application modeling tools, other software, licenses, and data sources.

As per §7.0 of the SOO, no Government Furnished Equipment will be provided. The Government will arrange to make the data sources available to the contractor.

7.0 Will the Government procure the cloud hosting environment or is this the responsibility of the vendor?

Per §7.0 "Government-Furnished Equipment": the vendor is required to provide commercial cloud hosting and associated software as part of this contract. Costs for these materials should be included as part of the vendor's proposal.

8.0

"The vendor will require access to unclassified U.S. Government and other commercial systems used to collect background information on Subjects during all parts of the process." How quickly would access to government and commercial systems be provided to vendor for the 9-month prototype development?

The Government will provide access to the appropriate commercial and Government systems throughout the course of the project. System access will be granted prior to the associated integration work. Negotiating SLAs or memorandums of agreement to obtain credentialed access to data sources is the responsibility of the Government.

8.0 Are there any content management and retention requirements for this solution? There are retention requirements for the prototype; further direction will be provided to the selected vendor.

8.0 Will the prototype under this effort be conducted entirely at the UNCLASSIFIED level with UNCLASSIFIED data sources?

Yes; SABER will be kept at an "UNCLASSIFIED // FOR OFFICIAL USE ONLY" level and will not process any classified data.

8.0 If GFE is not a requirement for administrative access to production environment, what mechanism is expected to be used to administer and or monitor the production systems?

Per §7.0 "Government-Furnished Equipment": the vendor is required to provide commercial cloud hosting and associated software as part of this contract. Costs for these materials should be included as part of the vendor's proposal. The vendor will be required to grant and limit access at the direction of the Government.

8.0

What are the Government requirements/policies for system audits? (specifically:

what is the USG process for auditing data and users?)

The Defense Digital Service will perform oversight through a variety of mechanisms including the regular agile reporting described in SOO §4.3.1. In addition, the Government will audit SABER as part of the process to obtain an Authority to Operate (ATO) as described in SOO §4.2.3.

n/a Do you have dedicated product leads who will be working on this project to coordinate between teams?

Yes, the Defense Digital Service will be providing dedicated technical product support throughout the contract term.

n/a Will we be supplementing your team, or will it be entirely our team? Though development is expected to be primarily led and conducted by the vendor, the Defense Digital Service will be providing additional personnel to assist in engineering architecture, navigating government requirements, system access, process analysis, user experience design, etc.

n/a

How will SABER be audited? The Defense Digital Service will perform oversight through a variety of mechanisms including the regular agile reporting described in SOO §4.3.1. In addition, the Government will audit SABER as part of the process to obtain an Authority to Operate (ATO) as described in SOO §4.2.3.

n/a

How does DSS intend for this system to augment, compliment or replace eApp? The prototype system is not intended to replace any existing system from NBIB, NBIS, etc. The SABER prototype will explore innovative, bold, transformative approaches to the way the personnel vetting mission is carried out.

Importantly, SABER will be a testbed for new technologies that can be utilized without hindering or otherwise impacting ongoing initiatives. The SABER prototype is being developed in coordination with the Office of the Undersecretary for Defense (Intelligence) and the Defense Security Service.

n/a

How does DSS intend for this system to augment, compliment, or replace DISS? The prototype system is not intended to replace any existing system from NBIB, NBIS, etc. The SABER prototype will explore innovative, bold, transformative approaches to the way the personnel vetting mission is carried out.

Importantly, SABER will be a testbed for new technologies that can be utilized without hindering or otherwise impacting ongoing initiatives.