Answers - CJIS DISE QnA.xlsx
XLSX spreadsheet 43 KB Posted
- Attached to
- RFI - CJIS Decentralized Info Sharing
- Solicitation number
- Not on record
About this file
This file is a Questions and Answers document for the FBI Criminal Justice Information Services (CJIS) Decentralized Information Sharing Environment (DISE) Request for Information (RFI). The document addresses inquiries submitted by potential vendors regarding the CJIS Division's initiative to identify capabilities for a national decentralized information sharing environment. The RFI seeks solutions that would enable states to analyze and share information from Computer-Aided Dispatch (CAD) systems, Law Enforcement Records Management Systems (LERMS), and other criminal justice and public safety information systems without requiring data centralization at the national level.
The Q&A document provides clarifications on various aspects of the RFI, including technical requirements, system architecture considerations, data sharing methodologies, and vendor capability expectations. This document serves as supplementary guidance to the original RFI solicitation and helps prospective respondents better understand the FBI CJIS Division's objectives and requirements for the decentralized information sharing initiative. As a Questions and Answers document supporting a pre-solicitation RFI, it does not establish specific response deadlines, pricing terms, or award information, but rather facilitates vendor understanding of the government's needs prior to any formal solicitation release.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| CJIS Decentralized Information Sharing - Final.pdf |
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
| Question # | Question | FBI Response |
| 1 | Does the Government envision a single prime integrator model for the DISE program, or does it anticipate a multi-vendor ecosystem governed by a federated governance model that permits best-of-breed component providers? Understanding the intended contract architecture will help industry frame its teaming strategies and technical approaches accordingly. | The FBI envisions that each organization (states/federal agencies/etc.) will have the ability to own and operate their own systems, resulting in a multi-vendor ecosystem relying upon open standard data formats and interfaces. As states elect to join the information sharing environment, they will be required to implement data and interface standards using technology providers of their choice. |
We also envision that the FBI may need to provide some states with a "basic" capability for implementing their node. Such a capability could provide states with a starter pack, allowing them to participate with a low cost of entry. We envision this basic capability to be an isolated area on a cloud environment. We would expect the basic capability to implement the standard data formats and interfaces when interacting with the other nodes in the environment. For this basic capability, it is important for states to access their tenant via their existing identity management systems.
As states develop the need for a more robust or unique capability, then they can implement their own node with advanced features.
| 2 | What is the anticipated data classification level for information processed and stored within the DISE environment — Controlled Unclassified Information (CUI), Law Enforcement Sensitive (LES), or a higher classification tier? Clarity on the classification ceiling will directly inform the security architecture, cloud impact level (FedRAMP High vs. IL4/IL5/IL6), and the applicable overlay controls under the CJIS Security Policy. | This environment will be unclassified, operating on the management, analysis, and exchange of criminal justice information. All IT assets operating under the management of the FBI CJIS Division will adhere to the FBI standards for federal systems. All IT assets owned and operated by states will adhere to the CJIS Security Policy. |
| 3 | Are there existing state-level Computer-Aided Dispatch (CAD) and Law Enforcement Records Management System (LERMS) integration standards — such as the National Information Exchange Model (NIEM) or the Global Justice XML Data Model (GJXDM) — that the DISE environment must support or adopt? Defining interoperability standards upfront will shape API design, data normalization pipelines, and onboarding playbooks for participating state and local agencies. | We envision that the work to develop the data formats and interface standards required to support this decentralized information sharing concept would be part of the scope within this effort. The FBI, in conjunction with its technology provider and the CJIS Advisory Policy Board (APB) would perform work to develop those formats and standards. |
| 4 | Does the Government intend for the DISE national node to be hosted within existing FBI on-premises infrastructure, in a FedRAMP High-authorized commercial cloud environment, or through a hybrid architecture that spans both? The hosting decision will materially influence network topology, latency requirements, and the approach to zero-trust network segmentation across federated participants. | We envision that the national node (operated by the FBI CJIS Division) would reside in FedRAMP High-authorized commercial cloud environments. |
| 5 | What is the approximate number of state and jurisdictional participants anticipated for the initial pilot phase versus Full Operational Capability (FOC)? Understanding the participant ramp will enable industry to size data ingestion pipelines, identity federation services, and operational support models commensurate with phased deployment. | We envision that when finished, the national decentralized information sharing environment will have a node for all states and territories. Each node will be sized differently based on the number of participating agencies covered by that node. Nationally, there are approximately 18,000 criminal justice agencies that would fit into this environment. We expect that these agencies would be represented by approximately 100 nodes. |
In the initial implementation, we envision a set of early adopters to implement approximately 15-20 nodes. We also expect many early adopters to begin with a "basic" capability for their node that is provided by the FBI solution, choosing later to stay with the basic capability or to implement their own solution with expanded capabilities for their unique requirements.
| 6 | Is there an existing knowledge graph technology preference, a commercial off-the-shelf (COTS) incumbent, or a legacy system that the DISE solution must integrate with or replace for entity resolution, link analysis, and investigative data correlation? Awareness of any technology constraints or preferences will inform the solution’s graph database architecture and the migration strategy for existing data assets. | The solution does not need to rely on existing tools or constraints for developing the DISE solution. |
| 7 | Which National Crime Information Center (NCIC) message keys and file types are envisioned for integration within the DISE investigative data sets? Identifying the relevant NCIC transaction sets (e.g., QH, QW, QV, QI, or others) will enable industry to design compliant query/response interfaces and ensure alignment with NCIC Modernization and the CJIS APB-approved messaging standards. | The intent is to allow a state to integrate its analytics node with their state NCIC capabilities to bring other criminal justice information into their analytics environments. We envision that this would include all inquiry messages to allow for the data collection and analysis to take place. |
| 8 | Do the 15 pages include or exclude a cover page and table of contents? | The entire response needs to be 15 pages inclusively. |
| 9 | May tables and figures and their captions be smaller than 12 point font, such as 10 point Arial? | Yes |
| 10 | Do states currently have any shared infrastructure, or would each state node need to be built from scratch? | There is a variety of shared infrastructure facilitating information sharing among the states. We do not necessarily envision the DISE solution using or residing on those current platforms. |
| 11 | Is the preferred deployment model cloud-native, on-premise, or hybrid — and does that vary by state? - | We do not have a preferred deployment model to leverage on each state and will vary greatly depending on each state's technology, policy, and infrastructure. We envision that the FBI provided "basic capability" would be provided as a cloud-based solution. |
| 12 | Is there an existing data integration platform in use at any state nodes today that we'd need to coexist with or replace? | We do not have knowledge of each state's data integration platform, capabilities, or the need to coexist of replace such a platform or capability |
| 13 | How many distinct CAD and LERMS vendors/systems are in use across the anticipated states, and do you have a current inventory? | We do not know the number of distinct CAD and LERMS systems that are in use across the anticipated states, and do not have an inventory. |
| 14 | What data volumes (records per day, total data size) are expected from CAD/LERMS systems per state? | We do not have this information. We do know that the National Data Exchange (N-DEx) system just surpassed two billion documents and is sized to process ten million documents per day. |
The number could be quite different in each state depending on the type of data that the state wants to analyze and share. We expect that the state will want to perform intra-state analysis on more of its data types than it shares with the other nodes in the decentralized information sharing environment.
| 15 | Are the data sources primarily structured relational databases, or do they include unstructured/semi-structured formats? – What data formats do you prefer to use? | The structure of the data will vary between states, vendor, data source, and processing output. We envision the solution will rely on a set of open standards that will allow interoperability between nodes. How that interface works beyond that is part of this information gathering in this RFI. |
| 16 | What do you mean by knowledge graph information? Could you provide additional details on the intended knowledge graph capabilities and expectations for the associated APIs and overall API architecture? | A knowledge graph is a structured database that represents information as a network of interconnected real-world entities (like people, places, or concepts) and their relationships. |
As for additional information, it is common for a single data analytics system to create a knowledge graph based on the information it has collected and analyzed. We envision a decentralized data ecosystem that will allow nodes to share the knowledge graph it has built with those built by other nodes int he decentralized data sharing environment. The development of those associated APIs and overall API architecture is included in the scope of this effort.
| 17 | When you reference knowledge graphs, are you envisioning a specific graph technology (e.g., RDF/SPARQL, property graphs, Neo4J, Amazon Neptune, Microsoft Azure Cosmos with graph API or Stardog) or is the technology stack still open for evaluation or to be determined? | The technology stack is open for evaluation. Connectivity, usage, standards, and technology are all open to evaluation. |
| 18 | Is the knowledge graph requirement primarily for investigative link analysis, or does it also need to support real-time queries? | We envision that the knowledge graph created in each node could be used to support real-time queries and alerts across the decentralized information sharing environment, supporting investigations and general awareness across jurisdictional boundaries. |
| 19 | Are you looking for part of the solution to be anthological? | We are not sure that we understand this question. If the question was meant to be "ontological", then we think the answer is yes. Specifically, we think that part of the solution is to define the formal, machine-readable specification of concepts, categories, and relationships within a specific domain. |
| 20 | Will the API layer need to align with an existing API management platform or governance framework, or is selection and implementation of that capability part of the scope? | We believe that the selection and implementation of that capability is part of the scope. |
| 21 | Are there FedRAMP authorization requirements for federal/state compliance standards that need to apply to any cloud-hosted components? | Yes - any IT asset owned / operated by the FBI CJIS Division must be FedRAMP High. |
| 22 | Are there incumbent vendors currently providing any portion of this capability who would be competitors or potential teammates? | No Answer |
| 23 | Does the Government anticipate participating jurisdictions owning and operating their own state-level nodes/tenant environments, a centrally managed shared-services operational model, or a hybrid federated architecture? | The FBI envisions that each organization (states/federal agencies/etc.) will have the ability to own and operate their own systems, resulting in a multi-vendor ecosystem relying upon open standard data formats and interfaces. As states elect to join the information sharing environment, they will be required to implement data and interface standards using technology providers of their choice. |
We also envision that the FBI may need to provide some states with a "basic" capability for implementing their node. Such a capability could provide states with a starter pack, allowing them to participate with a low cost of entry. We envision this basic capability to be an isolated area on a cloud environment. We would expect the basic capability to implement the standard data formats and interfaces when interacting with the other nodes in the environment. For this basic capability, it is important for states to access their tenant via their existing identity management systems.
As states develop the need for a more robust or unique capability, then they can implement their own node with advanced features.
24 Does the Government anticipate future acquisition approaches utilizing centralized Federal funding models, decentralized state participation models, hybrid funding approaches, or shared-services operational structures? We envision a hybrid funding approach, where the FBI provides the national-level node that is responsible for FBI, DOJ (and potentially all federal) data along with a basic cloud-based offering for states to have their own private analytics area that provides a "basic" analytics capability.
If a state wishes to build a more featured system unique to their environment, then they would fund their own advanced node that would comply with the data formats and interfaces required to participate with the other nodes in the decentralized information sharing environment.
| 25 | Should respondents assume eventual nationwide operational participation across state, local, federal, and tribal entities, or a more limited operational coordination scope? | For purposes of the RFI, it would be useful to describe an eventual nationwide operational participation. An implementation plan that described how to start small and scale over time would also be welcome. |
| 26 | Should respondents assume future operational environments aligned with CJIS Security Policy requirements, FedRAMP-authorized cloud operational environments, and Zero Trust operational principles for conceptual planning purposes? | Yes - this would be a good assumption to make. |
| 27 | Does the Government anticipate standardized API governance and interoperability frameworks across participating jurisdictions, or operational flexibility allowing jurisdiction-specific interoperability implementations? | We envision that each node in the decentralized information sharing environment will use standard data formats and interfaces to communicate with the other nodes when sharing analytic/informational products. We also envision a solution that would allow each node to have intra-state flexibility to process its own documents and data formats internal to the state. |
| 28 | Does the Government envision federated graph querying, graph synchronization, graph summarization, centralized graph aggregation, or hybrid operational intelligence coordination models? | For purposes of this RFI, we are open to thoughts and suggestions from industry on how to approach this problem. We know that we have a goal to share analytical/informational products across participating nodes. We have not yet decided up on an architectural approach for how to achieve that goal. |
| 29 | For conceptual planning purposes, how many pilot participants (states, tribal entities, local agencies, or federal partners) should respondents assume for initial capability planning and architecture sizing? | The RFI doesn't specify a pilot program or an implementation plan. For conceptual planning purposes, we could assume an initial effort to pilot the concept with 10-15 states and the national level node as described in the RFI. Each state node would be responsible for its local agencies, which vary per state. |
| 30 | Does the Government anticipate dissemination management and operational governance policies being centrally coordinated, state-managed, or implemented through hybrid governance models? | We envision that each node will be responsible for dissemination management for its data, determining which subsets of data and knowledge / information products get shared with the other nodes. Finally, we envision that the governance and policies for establishing sharing guidelines would be coordinated via the CJIS Advisory Policy Board (APB). |
| 31 | For conceptual planning purposes, should respondents assume participating jurisdictions may include highly heterogeneous operational environments, including legacy CAD/RMS platforms and varying interoperability maturity levels? | Yes - We envision that each node will have to integrate with many systems operating within its jurisdiction. We also believe that will be a highly heterogeneous operating environment with many different products and interoperability maturity levels. |
We envision that the FBI would provide states with a basic analytics package that they could use as a starter pack. While not required to use it, states may find significant utility in solving some of those internal interoperability challenges. We are interested in understanding what tools and capabilities could be provided to states via that basic offering.
| 32 | Does the Government anticipate permitting multiple hosting approaches (state-hosted, federally hosted, hybrid cloud, or shared operational environments) depending upon participating jurisdiction requirements and governance considerations? | Yes - we envision that each state could elect to implement and host its own node. However, we want to provide states with a "basic analytics" option to help them get started. It would provide them with a no cost entry point, allowing them to establish a tenant (or private space) on a cloud-based offering at no cost to the state. If the state starts with the basic option and later elects to build a more custom analytics system, then they can do that and use the standard data formats and interface to communicate and share information with other nodes. |
| 33 | Is NCIC integration expected during initial pilot activities or during later operational deployment phases? | We envision that the NCIC integration would be part of a minimally viable product to be available during any pilot activities. |
| 34 | Does the Government anticipate the future requirement including enterprise sustainment services such as operational monitoring, onboarding support, workflow administration, analytics support, governance administration, production operations, and enterprise operational coordination activities? | As we explore this concept, we have not finalized an operating model and would be interested in seeing different options. Options could include (1) a model where the product is delivered to the FBI to be deployed and operated or (2) a model where the offeror operates and manages the entire capability under a Software as a Service (SaaS) type of structure. |
| 35 | Would the Government consider phased and modular acquisition approaches supporting reference architecture development, pilot-state onboarding, interoperability validation, incremental operational expansion, and scalable modernization sequencing prior to enterprise-scale operational deployment? | Yes. We envision multiple phases to explore and build out the concept. |
| 36 | Does the Government anticipate prioritizing pilot-state onboarding, interoperability validation, analytics enablement, dissemination management, operational intelligence coordination, or national-level operational visibility during the initial implementation phases? | At this time of concept exploration, we have not set the priorities for initial implementation phases. We are interested in learning about suggested priorities and implementation phases as part of this RFI. |
| 37 | Does the government envision the state-level nodes as a managed service procured and operated by a prime contractor or the FBI on behalf of states, or does the government anticipate states deploying and operating nodes within their own infrastructure or virtual private cloud environments under a common interoperability and standards framework? | We envision that the FBI would provide the national-level node and a "basic" option for states to configure their own tenant to establish their own private area for intra-state analytics. If the state wants to go beyond the basic level analytics and build their own node, then they would use standard data formats and interfaces to interact with the other nodes within the environment. |
| 38 | Has the government identified a preferred ontology, semantic data model, or knowledge representation standard for the knowledge graph capabilities described in requirements 2(f), 2(g), and 3(d), such as NIEM, the Unified Cyber Ontology (UCO), STIX/TAXII, or an existing CJIS-defined model? Or is the government seeking respondent recommendations on appropriate standards to achieve consistent entity resolution and relationship representation across state nodes? | No. We have not decided on specific standards. We see the development and/or selection of data and interface standards as work to be performed as part of this effort. |
| 39 | Is the national-level node described in requirement 3 intended to be operated directly by the FBI under a government-owned, contractor-operated (GOCO) model, or is the government seeking a fully contractor-operated managed service? Additionally, will the national node be required to maintain its own independent FedRAMP authorization, or will it operate within an existing FBI or DOJ authorization boundary? | We have not decided up on a specific operating model for this requirement. We would be interested in learning about potential operating models to understand the art of the possible in this area. |
| 40 | Could the government detail the technologies, data formats, and integration requirements for the systems the decentralized environment must interface with? | We cannot detail those items at this time. We know that each state has many different products and technologies that must integrate with the state node, and we have not identified standard data formats or interfaces for the communications required between nodes in the decentralized information sharing environment. We believe that the work to identify and develop these specifications is part of the scope for this effort. |
| 41 | Does the government intend to leverage a cloud-based infrastructure as a repository for storing and managing data that is not already hosted in existing systems, in support of the decentralized information-sharing environment? | Yes, we envision solutions that incorporate cloud-based infrastructure. |
| 42 | Does the government require a visualization or business intelligence layer for data analysis and reporting? | The DISE is intended to allow for the sharing of data in a decentralized manner and not meant to provide a visualization toolset. Depending on solution, a business intelligence layer may be necessary for preserving and protecting data security and governance, but is not necessary for the proposal. |
| 43 | Does the government require that the new national-level information sharing environment access relevant available data from the state Uniform Crime Reporting (UCR) program, or will it reshape how that program collects and disseminates data? | The DISE goal is to provide information sharing capabilities to include crime data collections. Including Crime data information could change how the government gathers, analyzes, and disseminate analytical products. The goal is to move from centralized collection of raw data to a request based, standardized format and content request based model. |
| 44 | Could the government describe the data formats that states use to collect and store Computer-Aided Dispatch (CAD) and Law Enforcement Records Management System (LERMS) information? | These data and metadata standards will need to be created as part of the DISE concept. These standards will need to be create to encompass all of the current data needs and be extensible enough to support future needs. |
| 45 | Does the government intend to leverage existing state access control mechanisms for the new national-level information sharing environment, or will the solution be required to implement a new unified method across all states? | We believe that existing state access control mechanisms would suffice and that that products resulting from this effort would integrate into existing state identity management systems. For example, if a state was using the basic analytics package provided by the FBI solution, then they would access their own private cloud area using their local credentials. |
| 46 | Does the government intend for states to use the new national-level information sharing environment to write back data updates to their source systems? | The goal of the DISE is to decentralize information sharing between states and federal agencies, but to also allow state to state communications. Information received from the DISE is still subject to data security and standards regarding updating source information. |
| 47 | Could the government describe the type of knowledge graph information created by in-state analysis, and which technologies are currently used? | We believe that the work to design and implement these technologies is part of the scope of this effort, and do not have a list of current technologies. |
| 48 | Could the government describe the type, volume, etc. of investigative data sets that is intended to be integrated from the new national level node with the National Crime Information Center (NCIC)? | There are two major topics for consideration in the NCIC integration. |
The first is to allow the state and national analytics nodes to integrate with NCIC to pull in data for analysis. The state nodes would do this by interacting with the state's NCIC message switch.
The second is to allow states to interact with the analytics systems via their NCIC switch, allowing NCIC users to get access to the analytics data via their normal NCIC access. The intent here is to provide the desired analytics data to the NCIC audience without requiring them to go log into an analytics system.
We do not have types or volumes specified at this time.
49 Could the government describe the message key requirements that are intended for integrating investigative datasets from the new national level node with the National Crime Information Center (NCIC)? There are two major topics for consideration in the NCIC integration.
The first is to allow the state and national analytics nodes to integrate with NCIC to pull in data for analysis. The state nodes would do this by interacting with the state's NCIC message switch.
The second is to allow states to interact with the analytics systems via their NCIC switch, allowing NCIC users to get access to the analytics data via their normal NCIC access. The intent here is to provide the desired analytics data to the NCIC audience without requiring them to go log into an analytics system.
| 50 | For the RFI response may vendors use 10pt font for tables, headers, footers, and captions? | Yes |
| 51 | Does the government envision the "National Node" running in an already existing and configured cloud and/or on-premise environment? | The location of the "National Node" can be assumed to be a configurable environment securely available by the states. There should be no assumptions about using a pre-existing environment except that the environment can exist and be configured and accessed for the point of supporting the node. |
| 52 | Is it expected that an already existing user authentication mechanism will be used for this system? | There are no expectations of integrating with existing authentication mechanisms but the proposed mechanism needs to support role based and attribute based access control schemes at varying levels of data and system access. |
| 53 | Does the government have a specific set of standards that must be supported for data sharing and manipulation? The RFI references "industry standards" and "commodity, standards-based formats" but does not specify which ones. For example, NIBRS, NIEM, JSON-LD, REST, GraphQL, SOAP, and XML. | The government does not wish to endorse a specific standard because we do not want to limit possibilities based on existing biases towards current technologies and standards. Assume that a standard can be found or created to support the exchange of information and the submission should include any assumptions on those data standard in the proposal. |
| 54 | What is the highest classification level for data stored on the state/local/tribal level? What is the highest classification level for data that is stored at the Federal level? | The DISE would operate at the unclassified level. This solution is meant to allow information sharing between CJIS and our federal, state, local, and tribal partners. |
| 55 | Does the government have a specific set or types/groups of COTS, GOTS, open source, or hybrid tools for analytics and analysis, including use of AI/ML, LLMs, etc? | No. Please assume that you should provide the tools for analytics and analysis as part of the effort. |
| 56 | Is there an existing standard for the information described by the knowledge graph (2f,2g)? | No. We envision that the work to develop and identify the standard data formats and interfaces are part of the effort. |
| 57 | Does the government envision fine-grained access controls on data, data sets, and APIs being managed and propagated from nodes below the state level? | Yes. We envision that each state will have its own set of data sharing policies and procedures for both intrastate and interstate sharing. As such, there will be a need for customizable data sharing policies for data, data sets, and APIs. |
| 58 | Will states be required to enroll and make their data available for this new system? | No, states will not be required to participate. For the purposes of the RFI, the assumption is that states are willing to participate in the DISE. |
| 59 | Is it expected that the state-level node will interact with existing state-level reporting systems or be fed extracts from them? | The RFI made no assumptions on interactions with current state level infrastructure and also does not assume the methods for states to provide access to their data repositories. |
| 60 | Is there an expectation that computing and networking equipment will be purchased for each state-level node? | No, we do not have an expectation that computing and networking equipment will be purchased for each state. |
We do envision that states would have the option to create their own private area on a cloud-based solution to analyze their own data and then share some portion of the data and/or information products created during analysis of that data with other nodes.
| 61 | Related to "For purposes of this document, the definition of decentralized information sharing environment is an information sharing environment that enables data analytics and information sharing but does not require all data to be uploaded into a centralized data repository." | ||
| Is it acceptable for some portions of data to be in a centralized data repository? If so, which portions of data can be stored in a centralized manner? | Our desire in this concept is to minimize the need for any data type to be centralized in any node. However, during this time of concept exploration, we are open to hearing different views and approaches. | ||
| 62 | Does this effort include developing a standard for all "state, local, federal, and tribal partner nodes" to share data or will firm be expected to only implement an existing standard(s)? | Yes, we envision that the work to identify and develop standard data formats and interfaces is part of the scope of this effort. | |
| 63 | What type of support is required for the UCR program? | At a minimum, we think that the state nodes should be able to integrate with the state UCR system to facilitate data analytics. |
There may be a need in this concept for the FBI to provide states with integration support for data sets and systems within their state. That could be applicable here if a state needed help with data integration and publication/reporting of state crime data.
| 64 | Can the Government please clarify if #2 "Evidence to show that your company can provide the requested services and/or products required…" includes some or all of the requirements from the "CONTEMPLATED REQUIREMENT" section? | We would like to know if you have the technical ability, personnel, and experience required to perform the work to help us develop and implement the concept described in the section of the RFI document labeled "Contemplated Requirement". |
| 65 | For published events, is there any expectation where an agency at a national or state level can subscribe to another state's events with dissemination permissions? | Yes, this is a good example of the requirement described in 2(d) of the contemplated requirements section of the RFI. |
| 66 | What knowledge graph standards or technologies are envisioned? The RFI requires knowledge graph creation, merging, and sharing across states but provides no specification for graph database standards, ontologies, or schema requirements. | We envision that the work to identify and develop standard data formats and interfaces is part of the scope of this effort. |
| 67 | What does "heterogeneous technology environment" mean in practice? Are there minimum interoperability requirements or certification processes for vendors operating within this environment? | By describing "heterogeneous technology environment", we only intended to indicate that this decentralized information sharing environment would involve multiple organizations. As such, the cross-jurisdictional sharing of information should be based on standards to allow each organization to make its own choices on implementation. If a state chooses to implement its own node, then they should be able to do so and still be able to interact with the other nodes using standard data formats and interfaces. |
| 68 | What is the expected hosting model? The RFI mentions "government cloud-hosted services" — does this require GovCloud (AWS, Azure, etc.), an on-premises government data center, or a hybrid approach? | We have not decided upon a specific hosting or operating model, but we would not expect to install hardware into an on-premises government data center and it would require a Government cloud solution for commercial cloud offerings. |
The operating model could be a Software as a Service (SaaS) type of model or a product that is provided to, and operated by the FBI. We are interested in learning more about the options.
| 69 | What version of the CJIS Security Policy applies? Given this is a CJIS Division initiative, what specific CJIS Security Policy requirements must the solution meet, and are there additional security overlays? | The current CJIS Security policy would apply. It is available on the FBI website. The CJIS security policy would apply to any state owned and operated system. All FBI systems (to include any basic analytics system provided to the states by the FBI) would adhere to FBI standards for systems such as NCIC, N-DEx, and NGI. |
| 70 | Is FedRAMP authorization required, and at what impact level (Low, Moderate, High)? | Yes - FBI solutions would be required to use services authorized at FedRAMP High. |
| 71 | What FISMA compliance level is required? | While we haven't yet done a FIPS-199 assessment, we anticipate a MEDIUM level for an analytics system as described in this concept? |
| 72 | What data quality standards are expected for CAD and LERMS data before it is published to the national environment? | We envision that the development and identification of all standard data formats and interfaces are part of the scope of this effort. |
| 73 | How many states are anticipated to participate, and will there be a phased rollout or pilot program? | The RFI doesn't specify a pilot program or an implementation plan. For conceptual planning purposes, we could assume an initial effort to pilot the concept with 10-15 states and the national level node as described in the RFI. Each state node would be responsible for its local agencies, which vary per state. |
| 74 | What are the expected data volumes (record counts, transaction volumes, data sizes, growth projections) across participating states? | We do not have this information. We do know that the National Data Exchange (N-DEx) system just surpassed two billion documents and is sized to process ten million documents per day. |
The number could be quite different in each state depending on the dynamics within that state.
| 75 | What are the performance requirements for API response times, system availability/uptime (SLA), and query latency? | The DISE proposal will need to offer solution that are resilient and extensible. The specific requirements on latency, SLA, and uptime will need to support the proposed solution. |
| 76 | What does "real-time" mean for the event subscription/alerting capability? Is there a maximum acceptable latency for cross-state notifications? | After review, we didn't see the term real-time mentioned in the body of the RFI. We have not yet defined a maximum acceptable latency requirement for cross-state notifications or other system metrics, and are open to recommendations or suggestions for these types of metrics. |
| 77 | What data retention and purging policies apply to data shared at the national node versus data retained at state nodes? | For the DISE solution, data retention and data lifecycle will need to be negotiated per each data product and are greatly dependent on the types of data being shared. |
| 78 | What specific CAD and LERMS vendors/platforms are currently in use across participating states, and are there known integration challenges? |
What is the current NCIC integration architecture, and what constraints exist for the "new message keys" referenced in the RFI?
Are there existing data exchange standards (e.g., GJXDM, NIEM) already in use across state systems that must be supported?
Will the solution need to integrate with other federal systems beyond NCIC (e.g., N-DEx, RISS, HSIN)? There are many CAD and LERMS vendors/platforms that are in use across the participating states. Most of these have several integration methods, but challenges do exist in the areas of data integration and standards.
For purposes of the RFI, we purposely avoided the idea of asking for compliance with existing standards. We envision that the work to develop and identify the standard data formats and interfaces required to implement the concept is part of the scope of this effort.
While there may be future integration points, we envision that the initial operating capability will not need to consider other federal integration points.
| 79 | What is the target implementation timeline from contract award to initial operating capability and full operational capability? | At the time of this RFI, we have not established an implementation timeline and would be open to suggested phases. |
| 80 | What is the governance model for the national-level node — will it be managed by FBI/CJIS, a shared governance board, or another entity? | We envision that the national node would be operated by the FBI CJIS Division under the guidance of the CJIS Advisory Policy Board (APB). It would be responsible for the FBI data at a minimum, but could also include data from other Dept. of Justice (DOJ) and other federal agencies wishing to participate but not wishing to operate a node. |
| 81 | What training and change management support is expected for state-level users and administrators? | We envision that any solution would require a training program to help state, local, federal, and tribal partners integrate data, perform analysis, and establish data dissemination policy for their data products. We believe that this program would be part of the scope of this effort. |
| 82 | Does the FBI anticipate the need for the creation an overarching environment, analysis tools and data formats to support the analysis of state, local and tribal data and is it anticipated this system will include a charge model to subsidize its operations? | Requirement 3(a) from the RFI describes a centralized node that serves as a centralized analytical tool to do this effort. However, there is also a concept that each node can access data from all of the other nodes. Future concept exploration is needed to identify features that can only be accessed from the national node. |
We do not envision a charge model for this capability.
| 83 | Is there a default assumption of vendor-agnostic or open source technologies? | There is no assumption of technologies to be used. The standards-based interaction between nodes is needed to allow nodes to make their own technology choices and still be able to participate. For the FBI operated components (national node and basic analytics option for states), the technologies would be provided as part of this effort. |
| 84 | In Section 1(b), you mention that each state-level node should be capable of integrating and analyzing information from a variety of systems. Can you provide additional detail regarding whether data transformation, normalization, and orchestration are expected to occur locally within each participating state environment prior to dissemination? | Each state will be responsible for curating data within that state. |
If the state elects to use the FBI-provided basic analytics option to implement their node, then it is expected that they would use tools provided by this effort to perform that work.
| 85 | In Sections 1 and 3, you describe a national-level decentralized information-sharing ecosystem spanning state, local, federal, and tribal partners. Can you provide additional information regarding the anticipated scale of the environment, ex. approximate numbers of participating agencies, source systems, interfaces, daily transactions, and expected data exchange frequencies? | There are approximately 18,000 law enforcement agencies in the United States. We envision that there will be somewhere between 60 and 80 nodes, each responsible for the data from the agencies within its area of responsibility. We do not have estimates for number of data transactions, interfaces, and data exchange frequencies. |
| 86 | In the Introduction and Section 2(f-g), you reference entity resolutions, relationships, link graphs, and the merging of knowledge graph information across participating nodes. Can you provide additional clarifi cation regarding where investigative identity reconciliation and entity resolution are expected to occur, such as within individual state nodes, centrally at the national level, or through a federated combination of both approaches? Can you also provide additional information regarding the investigative entity domains expected to participate in matching and mastering processes, ex. persons, aliases, organizations, vehicles, locations, devices, or incidents? | We envision that each node in the decentralized information sharing environment will create knowledge products such as entity resolutions, knowledge graphs, etc. It is these knowledge products that will be shared between nodes. We do not expect all of the knowledge products to be shipped to a national node for sharing. Rather, we envision that nodes will share these knowledge products in a federated way. |
The data analyzed would include persons, organizations, vehicles, locations, devices, weapons, drugs, and other entity types.
| 87 | In Section 1(c), you mention that states should maintain dissemination and access control over shared datasets. Can you provide additional clarifi cation regarding whether participating states are expected to maintain ownership and stewardship of mastered entities while selectively sharing investigative relationships and knowledge externally? | We envision that each node will maintain ownership and stewardship (to include dissemination responsibilities) for all data to include source documents and the knowledge products generated from analysis. In doing this, nodes will selectively share investigative relationships and knowledge with other nodes. | |
| 88 | In Sections 1(b-d) and 2(a-b), you reference heterogeneous environments, standards-based information exchange, and state-level analytics across multiple criminal justice systems. Can you provide additional detail regarding expected data quality, standardization, and validation requirements across participating systems? | We envision the work to establish standardized data formats and interfaces to be part of the scope for this effort. | |
| 89 | In the Introduction and Section 2(a), you reference decentralized information sharing across heterogeneous environments. Can you provide additional information regarding whether metadata is expected to remain decentralized within each participating state while still supporting centralized or federated discovery capabilities? Can you provide additional clarifi cation regarding expected lineage, traceability, audit, and reporting requirements across ingestion, transformation, publication, dissemination, and investigative consumption workflows? | We do envision that metadata would remain decentralized within each node, expecting that the nodes within the decentralized information sharing environment communicate with each other often. | |
| 90 | In Section 1(c), you mention that states should maintain dissemination and access control over shared datasets. Can you provide additional clarifi cation regarding whether participating states are expected to maintain ownership and stewardship of mastered control over shared datasets. Can you provide additional clarification regarding whether participating states are expected to maintain independent governance ownership, stewardship, and dissemination policy management for shared | ||
| investigative datasets and data products? | Yes, we do envision that participating states would maintain independent governance ownership, stewardship, and dissemination policy management for all datasets and data products. | ||
| 91 | In section 1(a), will each state require its own isolated instance, or is a multi-tenant | ||
| deployment with row-level security acceptable for data separation between nodes? | We envision that each state will have its own isolated instance (if using the basic analytics option provided by the FBI) or could choose to build its own node to address more unique requirements. In both scenarios, the communications between the state node and the other nodes in the environment must use standard data formats and interfaces. | ||
| 92 | In section 1 and 3, is the solution expected to be deployed on-premise within each | ||
| state's infrastructure, in a state-managed cloud, or centrally hosted by the FBI? | The FBI would provide the national node and a basic analytics option for state nodes. We have not yet determined a hosting model for these. |
States not electing to use the basic analytics option will decide on how to host their node based on state policy.
| 93 | In section 1 and 3, what are the network connectivity assumptions between state | |
| nodes and the national-level node — air-gapped, private WAN, or internet-based? | We envision that all communications between nodes could use internet-based communications with industry standard encryption and authentication methods. | |
| 94 | In section 1 and 3, what identity provider is used for authentication — Active | |
| Directory, PIV/CAC, or a federal SSO standard? | Each node will need to integrate with the identity provider in use by the state or federal agency using industry standard protocols and adhering to security standards for the agency. Security standards would be the CJIS Security Policy for states and federal security policies for federal agencies. | |
| 95 | In section 1(b), will analysts query CAD/LERMS systems live, or will a solution | |
| connect to a curated data layer prepared upstream? | We envision that each node in the decentralized information sharing environment will perform its own analysis and generate knowledge products. |
While we have not specified how each node will interact with the data owners, we expect the work to develop and identify those data integration approaches is part of the scope of this effort.
| 96 | What role does the FBI envision for NIEM as the shared semantic layer or ontology across participating state nodes? | For purposes of this RFI, we did not want to restrict concept exploration with existing standards. Therefore, we are interested in understanding the possibilities for data sharing between nodes and will focus on the development of standard data formats and interfaces as part of this effort. |
| 97 | Does the FBI envision a single unified platform responsible for both real-time, event-driven alerting and large-scale batch analytics, or is there openness to a layered architecture in which purpose-built technologies handle each workload type independently? | The FBI envisions that each organization (states/federal agencies/etc.) will have the ability to own and operate their own systems, resulting in a multi-vendor ecosystem relying upon open standard data formats and interfaces. As states elect to join the information sharing environment, they will be required to implement data and interface standards using technology providers of their choice. |
We also envision that the FBI may need to provide some states with a "basic" capability for implementing their node. Such a capability could provide states with a starter pack, allowing them to participate with a low cost of entry. We envision this basic capability to be an isolated area on a cloud environment. We would expect the basic capability to implement the standard data formats and interfaces when interacting with the other nodes in the environment. For this basic capability, it is important for states to access their tenant via their existing identity management systems.
As states develop the need for a more robust or unique capability, then they can implement their own node with advanced features.
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 .