Federal Records Management

Toolkit for Managing Electronic Records

Executive Summary

  1. Records Management Conceptual Model. Read this section to learn about the FBI's overall objective to identify, acquire, and deploy a fully integrated application that combines electronic workflow, imaging, and management of documents, e-mails, evidence, and records. Topics covered include: 1.1 Sources of FBI Records; 1.2 Metadata Capture, including: 1.2.1 Scenarios, 1.2.2 Sources, 1.2.3 Classification, and, 1.2.4 Search; 1.3 System Conceptual Model, including: 1.3.1 System Framework, 1.3.2 Record Creation, 1.3.3 Content and Structure Capture, 1.3.4 Record Declaration, 1.3.5 Records Retrieval, and 1.3.6 Long-term Storage.
  2. Records Management Architecture . Read this section for an overview of the RMA system architecture and vision of how the application will fit within the environment and will be used. Topics covered include: 2.1 Design Principles;  2.2 N-Tier Design; and, 2.3 Architecture Components  
  3. User Classes. Read this section to learn about types of users, and the functionality required by those users.  Topics covered include:   3.1 Administrative staff; 3.2 Agents; 3.3 Management; 3.4 DocLab Staff; and, 3.5 RMD Staff.


Appendix A: Assumptions and Constraints
Appendix B: System Capabilities and Functionality
Appendix C: Quality and Performance Attributes
Appendix D: Security, Privacy, Integrity, and Continuity
Appendix E: Glossary of Terms
Appendix F: Acronyms
Appendix G: FBI Metadata Requirements


Table 3-1: General Requirements
Table 3-2: Capture Requirements
Table 3-3: Retrieval Requirements
Table 3-4: Retention Requirements
Table 3-5: Administration Requirements
Table 3-6: Example Performance Goals


Figure 3-1: FBI RM N-Tier Architecture
Figure 3-2: RMA Conceptual Model
Figure 3-3: Metadata Capture Scenarios
Figure 3-4: System Concept
Figure 3-5: Content and Metadata Flow
Figure 3-6: System Framework
Figure 3-7: RMA Integration
Figure 3-8: General N-tier Architecture
Figure 3-9: Components of the Records Management Architecture

Executive Summary

The senior leadership of the Federal Bureau of Investigation (FBI) recognizes the critical link between accomplishing the Bureau's missions and effectively managing the organization's records. The strategic goal for Records Management (RM) is to establish a state-of-the-art recordkeeping system. The Business Concept of Operations dated December 20, 2004 describes the conceptual model for the system from a business perspective. This System Concept of Operations (ConOps) provides an overview of the architecture and technical environment for the system.

Current System and Situation

The FBI's current recordkeeping system is paper-based and decentralized. This makes the RM lifecycle a costly and inefficient process. The FBI uses hundreds of computer applications that can produce records. The decentralized, stove-piped maintenance processes for these applications can cause significant delays in records processing and retrieval, make internal and external information sharing difficult, and impede the ability of employees to do work. Most FBI systems that generate records are not capable of identifying records eligible for transfer or destruction based on records retention schedules and disposition instructions. In this case, records disposition depends on manual processes from FBI employees. Currently, there are no enterprise-wide capabilities to export records and metadata in a format acceptable to the National Archives and Records Administration (NARA) or to maintain a record of all transfers and destructions.

Justification for Change

Since 9/11, the FBI has been changing from a reactive organization to one that is more proactive. Currently, the number one priority of the FBI is to prevent the next terrorist attack. In this new environment, efficiency is paramount and the FBI cannot afford unnecessary delays in the management of information. The shortcomings of the current paper-based, decentralized system translate into additional costs and decrease the effectiveness with which the FBI operates. Sound records management accountability is essential to support the FBI's mission.


In addition to protecting vital records and helping to ensure Continuity of Operations, there are significant benefits that can be achieved by managing records electronically. Higher quality and more current information can be accessed to support more efficient and effective work processes. Potential benefits include more consistent development and maintenance of institutional knowledge, increased collaboration across the enterprise, faster decision-making and responsiveness to change, improved public service quality, more effective management of information as an asset, enhanced promotion of organizational learning and understanding, and reduced cost of operations.1

In addition, as the rate of Information Technology (IT) change accelerates, there are increasing concerns about the government's ability to manage and preserve its records and to meet accountability and archival obligations. Using an enterprise Records Management Application (RMA) that is integrated within the Enterprise Architecture (EA) can address specific concerns such as preventing the loss of records that should be kept for legal and accountability purposes, achieving confidence in the authenticity and reliability of records, eliminating confusion between record versions, maintaining context to understand records properly, and controlling and planning for technological change that could make records inaccessible or incomprehensible. 2

RM Conceptual Model

The FBI's overall objective is to identify, acquire, and deploy an application that combines electronic workflow, imaging, and management of documents, e-mails, evidence, and records. To achieve this objective, the Records Management Division has developed an enterprise RM model that provides the framework for storing, accessing, and managing the FBI's documentation, regardless of format, media, source, or location. In this model, an enterprise RMA will provide lifecycle management of the Bureau's records.

From the user perspective, employees with the proper authorization will have access to FBI electronic records and information at their desktop. This desktop access will provide a more robust, user-friendly environment to create, access, and share information. The capabilities will also include creation, receipt, processing, dissemination, use, storage and final disposition of records.

In the model, an RMA enabled by a metadata repository will allow users to search and cross-index information without accessing the legacy applications. The RMA and metadata repository will also support the FBI's DocLab paper records conversion projects and enable the ordering of documents in both paper and electronic form from the FBI's Paper Repository. By capturing required metadata, all documentation that may be created or received through the FBI's investigative or business processes can be electronically managed in a legally acceptable manner, while safeguarding privacy and other sensitive information.

To be successfully implemented and effectively used by the Bureau, the RMA must integrate with existing and future systems within the Target EA. The integration of records, documents, data, evidence, and Freedom of Information and Privacy Act (FOIPA) management in a single solution is key to achieving the FBI's vision of efficient and effective document management.

Objectives of the System Concept of Operations

This System ConOps provides an overview of the RMA system architecture and vision of how the application will fit within the environment and be used. The integration of the RM architecture with the EA will be more fully and explicitly described during Task 4 (Integrate with FBI Enterprise Architecture). By integrating the RM architecture with the EA initiative we will provide traceability from and to the high-level business goals and processes.

1.0 Records Management Conceptual Model

The FBI's overall objective is to identify, acquire, and deploy a fully integrated application that combines electronic workflow, imaging, and management of documents, e-mails, evidence, and records. With respect to the end-user, the goal is to give the FBI's personnel a more robust, user-friendly environment to create, access, and share information, thereby completing work more efficiently and accurately.

FBI employees with the proper authorization will have access to FBI electronic records and information at their desktop and will be able to capture records from FBI applications with minimum intrusion on their normal work processes. Most of the RM aspects will be transparent to the end-user because they will be incorporated into normal workflow routines. The RMA will be integrated into the desktop operating environment to provide users with instant access to meaningful information about how they can identify official records and evidence through both on-line and browser-enabled transactions. Users will be able to view records, even if the FBI no longer supports the program that created the records.

The figure below illustrates the basic n-tier design (see Sections 1.3 and 2.0 for more detailed design descriptions).

Figure 3-1: FBI RM N-Tier Architecture

FBI RM N-Tier Architecture

In this environment, the RMA will provide an integrated electronic document and records management solution capable of managing the full range of FBI information including electronic and paper documents and records, evidence, images, video, sound, and other information objects in a variety of formats. The RMA will facilitate desktop capability for the creation, receipt, processing, dissemination, use, storage, and final disposition of records. The RMA enabled by a metadata repository will allow users to search and cross-index information without accessing the legacy applications.

Figure 3-2: RMA Conceptual Model

RMA Conceptual Model

The figure above provides a more detailed illustration of the conceptual model. The RMA and metadata repository will also support the FBI's DocLab paper records conversion projects and enable the ordering of documents in both paper and electronic form from the FBI's Paper Repository. For access to physical records, employees will request and gain access using a single streamlined process minimizing complexity, time, and cost. This conceptual model provides the framework for storing, accessing, and managing the FBI's documentation, regardless of format, media, source, or location. The RMA enabled by the metadata repository will provide lifecycle management of the Bureau's records.

The envisioned environment provides the FBI with a target that will guide the remaining tasks for the implementation of a records management application. This environment should be viewed as the end-goal of the overall project. The FBI will have to develop a migration strategy and plan for the existing IT environment. This technology is sufficiently mature to allow its introduction into the current IT environment without having to make significant changes. The migration strategy and plan is beyond the scope of this project. However, information in this document can be used in their development and some of the issues will be addressed in the Transition Strategy.

The RMA environment will enable FBI staff to manage (i.e., file, store, organize, track, share, retrieve, re-use, receive, and disseminate) electronic and paper documents and publications throughout their lifecycle (creation to final disposition). By integrating document authoring tools, document management systems, legacy applications, and long-term retention systems, the FBI will meet the objectives identified.

1.1 Sources of FBI Records

Defined in simplistic terms, an electronic record is simply the computerized version of a paper record. Paper records are currently being captured and managed within the FBI. Converting an electronic document to paper form creates many of the current FBI records. There are many different sources of FBI records. However, this project focuses on records associated with the creation of documents within the FBI. The following sources generate FBI records.

  • Paper: Information is created internally and received from sources outside of the FBI in paper form. It is possible that these paper documents will become FBI records.
  • Desktop applications: Many of the FBI records are produced by desktop applications. These applications include word processors, spreadsheets, and e-mail.
  • Bureau systems: IT systems such as financial, human resources, and other databases also generate FBI records. The capture and management of these records must be incorporated into the RMA and the defined architecture must be flexible enough to allow capture of these records in the future.

1.2 Metadata Capture

The main driver of success for the enterprise RM system will be the successful capture of required metadata. Bureau metadata requirements have already been identified by RMD (Appendix G: FBI Metadata Requirements). These metadata requirements need to be incorporated during the requirements phase of the IT Lifecycle Management for any application that will not fully integrate with the RMA. Integration with the RMA is the preferred capture method because RM software that meets the Department of Defense standard DoD 5015.2 automatically appends metadata to electronic information when the information is either saved or sent. Metadata will be required for all electronic information that has the potential to become a record in the future.

1.2.1 Capture Scenarios

The figure below illustrates the three general metadata capture scenarios.

Figure 3-3: Metadata Capture Scenarios

Metadata Capture Scenarios

Scenario 1: Metadata from Paper Records. In Scenario 1, the metadata will come from paper records. Paper records can come from two sources: a document can be received in hard copy format (e.g., a fax from a local law enforcement office) or the document can be generated by an application that has not achieved Electronic Recordkeeping Certification (ERKC). For paper documents that are digitized, some metadata may eventually be captured automatically. Digitized documents will be stored in a content repository. Paper documents will be stored in the Paper Repository. In either case, metadata will be entered through a browser template and stored in the metadata repository. Planning for this scenario is necessary because some information will always be received in hard copy. In addition, some applications will not be able to integrate with the RMA or meet ERKC requirements and, therefore, will have to maintain paper records.

Scenario 2: Metadata from Records Generated by Integrated Applications. In the second scenario, metadata will come from records that are generated from applications that are fully integrated with the RMA. The RMA will capture and export the metadata automatically to the metadata repository. Users will be able to access record content from their desktops.

Scenario 3: Metadata from ERKC Applications. In the third scenario, metadata will come from records generated by ERKC applications. The native application will capture and export the metadata to the metadata repository automatically. The record content will be managed by the native application. Planning for this scenario is necessary because some applications in use at the FBI will not be capable of integrating with the RMA in the short or near-term. However, these applications may be capable of being modified to meet the ERKC requirements and capture the required metadata.

In all three scenarios, metadata capture is the key to effective RM. Most records will eventually fall under Scenario 2. The FBI should continue to migrate in that direction with progressively fewer records being generated in paper form or managed by the redundant capabilities provided by ERKC applications. In the short to medium term, this conceptual model provides a realistic view of how Bureau records will have to be managed. The transition to this conceptual model will be described in more detail in Task 5: Transition Strategy.

1.2.2 Capture Sources

Metadata will be captured from the following sources.

  • Authoring tools: Desktop tools, such as Word, have templates used to standardize the document creation process. This data can be used to populate metadata fields.
  • Documents: Information embedded within the document itself can be used to populate metadata fields. For example, To, From, Date, and Subject fields in e-mail messages can be automatically migrated.
  • System generated: Many metadata fields are created within the system and require no user intervention. For example, who filed the document and when it was last modified can be identified automatically within the application.
  • Workflow: Metadata about where the document came from through the workflow can be included automatically as the steps in the workflow are completed. For example, a document can be routed for review through an automated workflow sequence. The reviewers and the sequence of review can be captured automatically as metadata.
  • Manual data entry: Some data entry of metadata information is unavoidable. The system will be designed to capture information about paper records and scanned images, both of which will require some manual data entry. In addition, all applications within the authoring environment may not be integrated with the RMA and will require more of the metadata fields to be entered manually.

1.2.3 Classification

A browser-based template will be used when automatic metadata capture is not possible. The template will be populated with existing Bureau information including the Classification Number, Classification, Program, and associated security and access codes. The current disposition authorities will be used to set the length of time for retaining business information, and provide legal authority for keeping, transferring, or destroying business information at the end of the retention period.

The file categories will be organized by the Program/Program Codes section of FBI Investigative Classifications. The taxonomy will be based on the Federal Register Thesaurus with the terms organized into a subject tree. Using the browser template, responsible business program managers will address the topics within their purview. At a minimum, the responsible program manager will verify the security and access restrictions for the file topics and crosswalk the topics to not more than four of the topics from the subject tree of the Federal Register Thesaurus.

Using the completed templates, the RMA will be programmed to automatically complete as many of the metadata fields as possible. The Enterprise Architecture Performance Reference Model identifies the sign-off junctures in business process. These are the junctures where electronic information becomes official record and the mandatory metadata will be appended.

1.2.4 Search

The RMA search tool will provide for the intelligent storage and rapid retrieval of documents and records. When processing user queries, the search tool will verify user access to determine which information, servers, and directories to search; use the metadata associated with the electronic information to identify and organize search results; provide full search results with drop down lists of categories of information pertinent to the query; and produce only information that the user is authorized to access. With this metadata model in place, the RMA can electronically manage all documentation that may be created or received through the FBI's investigative or business processes in a legally acceptable manner, while safeguarding privacy and other sensitive information.

1.3 System Conceptual Model

The overall vision, as illustrated in the figure below, is a records-centric environment that supports the creation of an enterprise RMA that manages the records-based knowledge of the FBI. This vision is consistent with current industry trends for the development of integrated enterprise IT environments.

Figure 3-4: System Concept

System Concept

Within the RMA, both metadata and record content flow among the various system components. The figure on the following page depicts a logical view of this flow. Icons in the figure represent logical and not physical components within the architecture. For example, the document, records, and archives repositories may physically reside on the same server and be managed by the same software application.

The vision described is an n-tier architecture, with thin clients communicating through application servers to data servers. The most likely structure of this n-tier architecture, given current market trends, is a browser-based client communicating with a back-end database through a web server. Most documents are created within the FBI on authoring desktop computers using standard FBI authoring tools such as Word and Excel. When they are in the stage of temporary drafts under development, documents may reside on the network file system and are managed by users employing standard Windows file management tools such as Explorer and native authoring application file management. While in the network file system, document content is passed back and forth between user desktops and network servers, but there is no metadata transfer.

At the point in the authoring process where documents are ready to be shared with others or where versions need to be created and maintained, users can transfer documents to the records management repository through a browser interface. When they transfer documents from a network file system or document management system to the RMA, users may be required to manually input certain metadata describing the record. Electronic records from other FBI applications such as a future electronic case file and electronic records from sources external to the FBI may be added to the RMA through manual or automated interfaces. Paper documents, if they do not exist in electronic form, may be scanned into the RMA.

Records will flow into the system from several sources. For example, end users can declare records from within an electronic document management system and move documents into the records management application. This process would transfer existing document metadata automatically from the document management system to the records management application. Additional systems metadata can be captured at the time of records declaration. However, the user declaring the record may also have to enter some records metadata manually at the time of declaration.

Figure 3-5: Content and Metadata Flow

Content and Metadata Flow

In accordance with the retention schedule, records are moved from the RMA to the electronic archives for long-term retention. For those records available to the public, a browser-based search and retrieval application will exist to allow access to the records management application.[ 3]

1.3.1 System Framework

The system framework establishes the technical design principles. In addition to establishing principles for general design requirements such as flexibility and scalability, the system framework provides standards and guidelines for each phase of the RM lifecycle. The system framework also identifies technology components that will be used throughout the records management lifecycle. This system framework is illustrated graphically in the figure below.

Figure 3-6: System Framework

System Framework

1.3.2 Record Creation

Documents can be created in two ways. Documents can be created in the authoring environment (e.g., Word or Excel), stored in the network directory structure, and submitted to the RMA. Documents can also be created in the RMA environment, using the profile information from the authoring tool templates to populate the RMA. If a document is submitted to the RMA after creation, profile fields for the document will be completed by the end-user. All necessary profile fields for both document management and records management will be completed when the document is placed into the RMA. However, the implementation of the system must allow for the capture of metadata throughout the lifecycle of the record.

1.3.3 Content and Structure Capture

Record content and structure will also be captured by the RMA. Content is the text and graphics that make up the document, while structure is the context within which the record exists. The structure of a record may encompass more than one document. The content of hard copy records will not be stored in the content repository but the associated metadata and location information will be stored in the metadata repository. When content is captured, a full-text index will be generated and stored within the control of the RMA. Records content will come from the following sources.

  • Electronic documents: Electronic documents from authoring tools will be captured in the RMA. These documents will come into the RMA along with the associated metadata. Once electronic documents are declared records, the associated metadata will transfer to the records management application, while the content of the document will remain in the document repository.
  • Imported electronic documents: The system will also provide for the capture of existing electronic documents that may be received from outside sources. During the input process, metadata will be captured along with the content of the document.
  • Scanned paper documents: Hard copy paper documents will be scanned into the system and the associated metadata will be manually entered. Once the scanned documents are in the system, they will behave as electronic documents in that their metadata will be transferred to the RMA, while the image itself will remain in the document repository.

1.3.4 Record Declaration

In-process documents should be transferred to RMA control when those documents meet the criteria for records. While a fully automated process is desirable, this may require user intervention to indicate that a document has become a record and transferred to institutional control. Depending on the level of integration between the native application and the RMA, this may require only a mouse click at the time of saving the document, or may require additional steps. When declared, the content may remain within the native system (e.g., ERKC systems) [ 4]. The metadata will be captured in the metadata repository.

Other records will exist in paper or other human readable formats. Paper records may be included directly in the records management application. At the time paper records are scanned into the system and indexed, they will be declared as FBI records. For paper records not scanned into the system or records in other human readable formats, records will be declared when the metadata is entered in the system.

1.3.5   Records Retrieval

End-users will be able to view a hierarchical file structure to browse and retrieve documents from a visual representation of the records classification scheme. Users will also use an application search engine to search fields in the RMA repository and may also perform full-text searches on records content. The results of these queries will be displayed and the user will have the option to view the content of the document (if it exists electronically and if the user has appropriate access privileges). If the record only exists in hard copy form, users will be able to submit requests for the record or a copy of the record from their desktop.

1.3.6 Long-term Storage

Retention and disposition rules in the records management application will determine when a record is eligible to be transferred to long-term storage or destroyed. Transfer to long-term storage will involve encapsulating the content and metadata in an appropriate long-term storage media such as PDF. The record will then be moved to a long-term storage application environment. It is anticipated that metadata concerning the record will remain in the metadata repository to permit access to the record as necessary.

2.0 Records Management Architecture

The envisioned architecture provides for an integrated environment that manages records from the point of creation through final disposition. The overall RM architecture must allow for a system that can achieve this vision. Specifically, the architecture must address the electronic document management, records management, and imaging modules of FBI's integrated records management application. A conceptual view of the RMA integration with associated applications has been provided in the figure below.

Figure 3-7: RMA Integration

RMA Integration

This integration takes into account that the records management application will manage most records, including images, generated at the application level. The application will manage all document types including e-mail, word-processing documents (MS Word), spreadsheets (MS Excel), presentation files, and scanned images. Metadata pointers will allow users to access records from their desktop.

2.1 Design Principles

The design principles of the envisioned records management system include the following.

  • Longevity: It must be possible to preserve a record in a form that can be physically preserved and maintained and accessible so records can be found. Records must be readable in their original format and it must be possible to produce exact duplicates of the original. The context of the record must also be maintained.
  • Preservation of evidence: A key reason for preserving records is to document the official activities of the FBI. The RMA must preserve this evidence and prevent alteration of the records of the FBI.
  • Knowledge sharing: The content of records must be accessible in a machine-readable form to allow the re-use of the information.
  • Disposal: Those records that no longer need to be preserved should be destroyed. The system must also ensure that those records that should be kept are preserved and can be transferred to NARA or other long-term storage as required.
  • Capture: The system must support the capture of a record at any point in the lifecycle of the document. While there is evidence that capturing a record at its point of creation improves the quality of the content of the record, the system must allow records to be captured long after they have been created.
  • Support FBI culture: Several aspects of the FBI's culture must be reflected in the systems architecture. This culture includes supporting a distributed and highly mobile work force, providing ease of use features to minimize training requirements, and allowing for the automated capture of records where possible.

In addition to the principles defined above, the design must:

  • Be flexible to adapt to changing mission requirements
  • Be extensible to support future growth within the FBI
  • Support remote connectivity of a large user base
  • Use industry standard interfaces to support integration with existing applications within the FBI and future applications that may be deployed

2.2 N-Tier Design

As illustrated in the figure on the following page, the design is an n-tier architecture that divides the records application into distinct parts:

  • Client desktop
  • Web Servers
  • Application servers
  • Messaging servers
  • Metadata servers
  • Content servers

Each tier may use different hardware and software to fulfill its particular application role. The client tier is responsible for the personal productivity and authoring applications. Specifically, the client tier is responsible for the presentation of data, generating user events, and controlling the user interface. The primary interface will be thin clients using web browsers for retrieval and submission of records. Web servers are responsible for the graphical interface.

The application tier protects data from direct access by users. It also translates client data requests and data inputs into the specific language required by the data server, aggregates query results, and returns output in a form intelligible to the thin client application (e.g., an HTML document). Application servers create and execute program logic to communicate with the program controlling the data source. In addition, the application server may receive input from the client tier and return information to the clients. Messaging servers receive and transmit data between various applications.

The data tier is responsible for data storage. In addition to relational and object-oriented databases, existing legacy database systems often exist in this tier. Metadata servers contain the record and user metadata. Content servers and other storage devices contain the record content.

Figure 3-8: General N-tier Architecture

General N-tier Architecture

The boundaries between the tiers are logical. It is possible to run all tiers on the same physical machine. However, in an actual implementation, one or more client installations would likely be separate from the machine (or machines) running the other tiers. More importantly, the system must be structured logically with clear definition of the software boundaries between the different tiers.

The current environment is primarily a mix of two-tier and n-tier environments. The n-tier architecture for the FBI RMA will add additional layers to handle most of the systems processes. The advantage is that the middle tiers acts as brokers between the client machines and the RMA, enabling more efficient connections for multiple users and legacy applications which must be integrated into the RMA.

The biggest advantage of an n-tiered configuration for the FBI RMA is remote access. With an n-tier configuration, users simply connect to the web server layer via a browser. This is a key requirement for the FBI, which has many staff in remote locations who will need access to documents in the FBI RMA. To implement the RMA across the Bureau, future systems must also be able to accommodate an n-tier model. Since most of the electronic document management systems and records management software vendors have adopted an n-tier standard architecture, detailed design and planning should anticipate an eventual migration to this envisioned architecture.

2.3 Architecture Components

The figure below depicts the basic components of the RMA architecture. Five basic components exist within the architecture including the authoring tools, document management system, records management system, long-term storage, and records retrieval. The RMA itself includes the records repository with corresponding document and records management applications, and a system for long-term preservation and management of all records. The existing document management and envisioned records management applications should integrate to form the institutional repository and the two systems should share a common interface, common search capabilities, and will appear as a single system to end-users. In broad terms, the document management system will manage work-in-progress and the records management system will manage information from the point it is declared a record of the FBI. Such distinctions should be transparent to RMA end-users.

Figure 3-9: Components of the Records Management Architecture

Components of the Records Management Architecture

The authoring component includes the desktop authoring tools, e-mail system, and file storage system used to save the elements of a record. Ideally, the authoring components are integrated with the RMA to support records capture at the point of creation. However, the architecture must be flexible enough to allow the document authoring to occur outside of the control of the RMA.

Document Management

In addition to search and retrieval facilities, the environment provides a variety of capabilities, including the tracking of multiple versions of the same document through its creation, review, and revision as well as the creation and management of the components of compound documents. The implementation of these advanced authoring features should be addressed in future planning documents.

Records Management

The RMA provides the control and administrative features essential to automating the management of records in electronic and paper form. These features include the ability to automate retention and disposition, to organize content according to a document classification scheme that enhances the functions provided by departmental file plans, and to enable paper and electronic documents to be managed in an integrated fashion.

Long-term Retention

A record's disposition schedule determines how a record is processed after a defined period of time has elapsed. The outcome is the requirement to move designated records into long-term storage. It is a critical component that the architecture must allow. The long-term storage solution must ensure preservation of content, account for technology obsolescence, mitigate media degradation, and provide platform independence.

Records Retrieval

When all components are combined, the RMA will allow users to create, file, store, locate, and retrieve records and facilitate the re-use of information contained in those records. The RMA will also provide functionality to allow users to search, locate, and retrieve records regardless of where they are stored. Several methods of searching must be provided including searching by all metadata fields as well as searching by the content of the records themselves. The search facilities must provide an intuitive interface that will provide both novice and advanced user functionality to help them locate and retrieve records. In addition to searching existing metadata and records content, a hierarchical view of records should be provided that will allow users to navigate and locate records using the file-defined classification scheme.

3.0  User Classes

Among the user classes, there is common functionality such as retrieving records, viewing records, adding notations, adding records to the RMA, indexing records and sending records to another user.  As much as possible, this functionality should be implemented in the same manner for all users to minimize training and support of the system and to provide a common look and feel to all users.  A standard web portal will be used as the basic user interface.  Simple customizations will be made to facilitate queries to allow for local scanning and introduction of documents into the system and to simplify re-classification and organization of records. The functionality required by the various users is described in the following paragraphs.

3.1  Administrative staff

The functions that will be performed by the administrative staff in the field offices include:

  • Create new electronic records as needed
  • Electronically file records from case files, if requested
  • Scan and index documents received in the field office and file in the appropriate electronic folder
  • Retrieve records requested and route to the designated recipient

3.2 Agents

Agents will be primary users of the RMA. They will retrieve records primarily and use the records in the course of investigations. They will require the capability to quickly identify and navigate to a record in the RMA. Since they will also work closely with a future electronic case file, they will also require the capability to navigate quickly between the RMA and the electronic case file. Both applications should be available on the screen at the same time.

3.3 Management

Managers need to have the same capability as agents and administrative staff because they sometimes perform the same functions. In addition, they need additional administrative capabilities to manage workflows and retention requirements. Access to this information will be restricted to the field office to which the manager is assigned.

3.4 DocLab Staff

The DocLab staff will be a primary source of documents for the document management system. The user interface for these users will need to support the indexing of documents as they are entered into the system and the retrieval of documents that have been filed for a client. Tasks performed by the DocLab team include retrieving documents for review, creating electronic documents for filing, indexing new documents, adding documents to the RMA, allowing access to documents by another user, and sending documents to another user.

3.5 RMD Staff

RMD staff requires the same functionality as other users. In addition, the RMD staff requires the capability to manage retention requirements, determine records security, and approve records disposition.

Appendix A: Assumptions and Constraints

In this section we identify the assumptions that affect the development and operation of the RM application and the constraints imposed on the design, development, and operation of the application because of conditions beyond the control of the project.


Assumptions include:

  • Management commitment and support will continue
  • Sufficient FBI IT personnel and other personnel resources will be available to complete the project
  • One Project Manager will be appointed with the authority to coordinate all related efforts
  • Project dependencies identified as part of the larger EA effort will be completed
  • The application and database consolidation effort will continue in parallel
  • The RAS will receive the government and contractor cooperation and participation required to keep the project on schedule
  • System requirements will be base lined so design and development can remain on schedule


Constraints include:

  • Process documentation is limited and sometimes does not exist
  • Database, application, and system documentation is limited and sometimes does not exist
  • Comprehensive application inventory needs to be finalized

Appendix B: System Capabilities and Functionality

The primary source for system requirements is the Federal Bureau of Investigation Enterprise Records Management Application High-Level Functional Requirements, dated February 2003. In addition, any RMA must meet the functional and technical requirements specified in DoD 5015.2. The tables below provide additional functional requirements that are the required and desirable features of an FBI RMA. Additional requirements may exist that are not applicable to this System ConOps.

Functional requirements will be categorized as:

  • General: Overall system requirements related to the environment within which the RMA will operate
  • Records declaration and capture: Requirements related to the identification and capture of records, whether electronic or paper
  • Records retrieval: Requirements related to searching, locating, and retrieving captured records, whether electronic or paper
  • Long-term retention: Requirements related to the preservation of records in accordance with the rules of the FBI
  • Administration: Requirements related to maintenance, reporting, and system support


A set of requirements exists that determines the basic environment within which the RMA will operate. These requirements define how the RMA should function within the FBI's existing infrastructure.

Table 3-1: General Requirements

Requirement Priority (M=mandatory, D=desirable)

Compliance with the DOD 5015.2 standard.


Architecture must be both flexible and extensible to support anticipated growth and changes in the business environment within the FBI.


Integration with the EDMS and FBI authoring tools (MS Office) so that to an end user, the RMA appears transparent.


Provide a standard Windows user interface for the records application.


Provide a web interface for the records application.


Intuitive navigational tools that minimize the requirement for end-user training.


Provide the ability to link related records or record components captured in the system.


Provide ability to generate bar codes from user-defined fields, as well as user-customized labels.


Provide the ability to read and accept standard bar code formats for all numeric data entry fields.


Records Declaration and Capture

The RMA will manage the content of electronic records to allow access to authorized users within and potentially outside the FBI. The content of electronic records will come from a variety of sources in a variety of ways. In addition to capturing records content, the system will capture metadata. This metadata will include all information about the record necessary for the system to perform the required management functions. Like content, metadata about records will be captured using a variety of sources and methods. Metadata capture will include information about records that do not have content in the data tier, such as archived paper or other non-electronic media.

The table below defines the requirements for capturing records.

Table 3-2: Capture Requirements

Requirement Priority (M=mandatory, D=desirable)

All record formats can be captured and retrieved, including the formats used by FBI authoring tools, electronic documents in other formats received by the FBI from outside sources, e-mail (including header information and attachments, with the relationship among elements of the e-mail maintained), scanned paper documents, and other documents in human readable formats


Bulk loading of data (file plan, content, metadata, users, departments) from external sources is supported.


Provide ability to allow different departments to use different names for the same metadata field.


Provide the ability to capture metadata automatically from the case/document management system, from interfaces to other FBI systems, through scanning and optical character recognition, or through manual data entry.


System should be able to store and manage record content in native format or in an alternative format such as PDF or XML.


Provide the ability for authorized users to edit metadata if necessary.


Provide the ability to capture and link version information about related records.


Provide the ability to designate FBI records automatically through pre-defined rules or manually by end-user intervention through an easy-to-use interface.


Provide the ability to capture and track hard-copy records at the accession, box, or file levels.


Records Retrieval

Users must be able to search and retrieve records that have been captured and stored in the system. Retrieval requirements include the following.

Table 3-3: Retrieval Requirements

Requirement Priority (M=mandatory, D=desirable)

Search and locate records by any metadata field using Boolean search criteria on one or a combination of metadata fields.


Provide for full-text searches for all electronic records within the RMA.


Provide both simple and advanced search functionality from the user desktop, including combined metadata and full-text searches.


Searches should distinguish between versions of records.


The format of search results can be customized by end-users.


Provide the ability for end-users, from their desktops, to place requests for records or copies of records located in the paper-based repository.


Validate the record's integrity at the time of retrieval.


Search and retrieval must be within the context of define security policies and procedures.


Long-Term Retention

Key requirements for the RMA relate to long-term records retention. Important aspects of long-term retention include the ability to schedule records, identify records for disposition, and change the disposition schedule.

Table 3-4: Retention Requirements

Requirement Priority (M=mandatory, D=desirable)

Administer retention and retirement of records in conformance with FBI and NARA rules and regulations.


Present file plan filtered by department or function.


Link related components of a record.


Retention scheduling by time or event or both.


Allow global changes to the file plan.


Allow modification to records retention as required.


Provide the ability to suspend the destruction of records.


Provide for periodic media refresh.


Allow records to be exported from one type of media to another.


Provide the ability to retain records in a format that can endure changes in the technology deployed by the FBI.



The RMA must provide a secure environment that protects the records of the FBI in accordance with the rules of the FBI and other Federal agencies. System management must include robust functionality to ensure data integrity and protection, and to ensure optimal system performance.

Table 3-5: Administration Requirements

Priority (M=mandatory, D=desirable)

The content of a record is not modifiable.


Provide the ability to assign security at the user and group levels for different types of records, and for individual records.


Support for security and access requirements integrated with the EDMS.


Predefined, automatic, and ad hoc audit, security, retention scheduling, and disposition reports.


Provide users with the ability to define and save ad hoc reports.


Provide users with the ability to generate reports from queries.


Provide for FBI defined standard reports available to all users.


Provide an audit trail of all activities including records capture, retrieval, metadata edits, and preservation activities.


Provide the ability to automatically create backup copies of records content and metadata that can be stored offline and at offsite locations.


Provide the ability to be operational 24 hours a day, 7 days a week.


System administration tasks must not require shutdown of the system.


System must provide the ability to restore operation of the system from backup copies and subsequent audit trails.


Appendix C: Quality and Performance Attributes

In this Appendix we describe the quality and performance attributes of the system:  scalability, availability, integrationextensibility, and performance characteristics.


The FBI has a long-term goal of using the RMA to manage records in both investigative and administrative units. The architecture enables growth to support a large number of users and documents. It will provide a flexible solution to accommodate a centralized, distributed or hybrid deployment. The architecture should provide high availability to ensure that data and systems are available to users when called upon, without delay or interruption in service. The RMA be implemented using a phased integration and deployment strategy (to be described in Task 5: Transition Strategy) while remaining open to support and to adapt to integration with business units. As with all hardware and software, the RMA architecture should be analyzed and potentially enhanced prior to deployment to additional users. Enhancements such as a distributed repository design may be appropriate when introducing geographically distributed users.


Since the RMA will serve as the FBI's primary record management system for its users, the system will be available at least 99 percent of the time during normal business hours, except during scheduled downtime for maintenance. In addition, RMA will provide limited record generation and retrieval (from local drives) when the user is offline, and enable automatic synchronization of content when the user reconnects.


THe RMA should employ a service based architecture to enable integration with current and future systems.  Nearly any system application should be able to call RMA records management services to store and retrieve records. The service layer effectively becomes the integration point. Systems integrating with the RMA will not need to account for the complexities of the underlying record storage architecture or the content management tools.

In addition, the RMA will integrate with Microsoft Word, Excel, PowerPoint, Outlook, and Windows Explorer to tightly control the retrieval and storage of documents generated through these desktop tools. This is necessary since end users create content in these applications, and the RMA system should seek to reduce the number of steps users must take to submit or retrieve content. The RMA also will integrate with the DocLab desktop scanning application to store scanned documents/images.


The RMA should be designed in a way that allows future addition of functionality without requiring a radical re-architecture of the system. This upholds the principle that initial phases of the RMA should provide the foundation for future RMA phases, as opposed to requiring future projects to tear down and rebuild the system to accommodate more users and features. The RMA architecture facilitates extensibility through the following design features.

  • Components: Functionality is built as small, stand-alone units that can be connected to solve complex requirements.
  • Services: Functionality is offered in the form of services to establish a contract between the calling system/application/component and the RMA. Each service requires some input and provides some behavior and result.
  • Layers: Components and solutions are layered to hide implementation details and to establish a consistent and predictable interaction between layers, components, and solutions.
  • Decoupling: Complex functionality has been broken up into small manageable components that can be called independently or as part of a larger/complex solution.

Performance Characteristics

The RMA architecture will leverage COTS built-in capabilities to provide a level of performance that results in minimal degradation as usage and volume increases. In addition, the RMA architecture will provide a level of performance that meets stated FBI business requirements regarding response time and other factors.

System volume information will be used to size several components of the system including storage volume, size of the subsystems, and number and size of RMA servers that must be configured. The FBI will need to analyze historical data (e.g., average page size and number of document versions) to determine approximate storage requirements. This analysis should also incorporate a growth factor (e.g., 10 percent per year) and long-term retention requirements. The RMA will require a disk array that is modular so that additional storage may be added as needed. Once the records are in the system, retrieval time for viewing records in the system should be optimized. Example performance goals for the user functions are listed below for network access from the assigned RMA server.

Table 3-6: Example Performance Goals

Performance Goal Description Influencing Factors Ave Time Max Time

View next record from search

Present attributes of the record - name, any additional information as determined by detail design

5 sec.

5 sec.

Retrieve record from search

Time from click on object to retrieve to display of first page of first document

Dependent on activity of the system and size of the documents

10 sec

20 sec.

Find specified record in system

Time from click on query form until list of records matching query is displayed

Dependent on number of records matching query and the activity on the system

5 sec.

20 sec.

Retrieve record for viewing

Click on object in the results from query until first page of the document is displayed

Dependent on size of record and location of the record (remote versus local)

10 sec.

30 sec.

View next page of record

Page down from open page

Dependent on size of pages and other applications running on the workstation (may require memory caching on workstation)

1 sec.

2 sec.

Faxed record available to recipient

Fax received at fax server to delivery to "mailbox" of recipient

Dependent on performance at Fax Server, time to index and volume of faxes

30 minutes

60 minutes

Appendix D: Security, Privacy, Integrity, and Continuity

The FBI community executes the Federal law enforcement policies of the United States, often working with highly sensitive information of great sensitivity. Protecting the Bureau's information resources is critical to its mission.

Due to the requirement that the networks and applications be TS/SCI compliant for the RMA, the RMA will adhere to the FBI Trilogy network solution. This solution will allow the RMA to use an existing solution rather than purchasing and deploying its own, which is costly and time consuming. This will also provide the tools necessary to secure the IT infrastructure and provide the capability to exchange information with other federal agencies securely. This also enable users within the Bureau to encrypt sensitive records using a robust encryption algorithm.

Security Objectives

The following are six objectives of technology security.

  • Confidentiality: Protects information from unauthorized disclosure.
  • Data and System Integrity: Protects data from unauthorized alteration. By ensuring that it remains intact, data can be trusted for use.
  • Availability: Ensures that data and systems are available to users when called upon, without delay or interruption in service, processing or communications.
  • Authentication:Determines a user's identity with certainty. This is particularly important when the user accesses the network from an untrusted network.
  • Access Control: Makes data and systems accessible to the appropriate personnel, in an approved manner, using approved access levels.
  • Non-Repudiation: Connects data, a transmission or action on the system with certainty to a particular user.

Security Requirements

The following high-level security requirements are centered on access controls, perimeter controls, data labeling, and system integrity. Technical security requirements that may be associated with a specific application, such as an audit log for a transaction system, are not included within the scope of this document.

The RMA should adhere to the security, LAN, WAN, and telecommunication guidelines of the FBI Enterprise Architecture. This may include, but is not limited to, FBI offices located overseas. The architecture must be compliant with guidance on handling information up to and including Top Secret.

Security Drivers

Federal laws and directives, such as the OMB memorandum, "Incorporating and Funding Security in Information Systems Investments" (February 28, 2000), impact the design of the RMA Security Architecture and strongly influence the application of security to information technology. Additional security drivers include the following.


  • FIPS 140-2: This standard is applicable to all federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106.
  • Common Criteria: The Common Criteria represents the outcome of a series of efforts to develop criteria for evaluation of IT security that are broadly useful within the international community.
  • 800-18: This standard is the guide for developing security plans for Information Technology Systems.
  • PDD-63 (Presidential Decision Directive 63): This Directive set a goal of a reliable, interconnected, and secure information system infrastructure. The Directive significantly increased security to government systems by establishing a national center to respond to attacks and to ensure the capability to protect critical infrastructures from intentional acts.

Appendix E: Glossary of Terms[ 5]

Application. The software product that results from the creation of a program, often used as a synonym for the programming (source) code that creates it.

Audit Trail. An electronic means of tracking interactions with records within an electronic system so that any access to the record within the electronic system can be documented as it occurs or afterward. May be used to identify unauthorized actions in relation to the records (e.g., modification, deletion, or addition).

Content. The subject matter of a document.

Create. In electronic records, the action or result of filing a new record and its associated metadata.

Destruction. In records management, the primary type of disposal action. Methods of destroying records include selling or salvaging the record medium and burning, pulping, shredding, macerating, or discarding it with other waste materials.

Disposition. Range of processes associated with implementing retention, destruction, or transfer decisions. Those actions taken regarding records no longer needed for the conduct of the regular current business of the organization.

Document. Official records, personal papers, classified information in written form, other written materials, and copies thereof, regardless of form, content, or ownership. Structured units of recorded information, logical or physical, not fixed as records.

Electronic Record. Record or electronic storage media, produced, communicated, maintained and/or accessed by means of electronic equipment.

Electronic Recordkeeping System. An electronic system in which records are collected, organized, and categorized to facilitate their preservation, retrieval, use, and disposition.

Electronic Records Management. This technology enables an organization to assign specific life cycles to individual documents. The records can come from multiple channels including e-mail, Web pages, scanned documents, custom applications, fax documents, and paper. Most products can be used as stand-alones but they are usually matched with Integrated Document Management products.

Enterprise Architecture. A strategic information asset base, which defines the mission, the information necessary to perform the mission, the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to the changing mission needs. An enterprise architecture includes a baseline architecture, target architecture, and a sequencing plan.

Format. For electronic records, format refers to the computer file format described by a formal or vendor standard or specification. For non-electronic records, the format refers to its physical form

Lifecycle. The records lifecycle is the life span of a record from its creation or receipt to its final disposition. It is usually described in three stages: creation, maintenance and use, and final disposition.

Media Type. The material or environment on which information is inscribed.

Metadata. Metadata is structured data about data; it is a term that describes or specifies characteristics that need to be known about data in order to build information resources such as ERK systems and support records creators and users.

Recordkeeping System. A manual or automated system in which records are collected, organized, and categorized to facilitate their preservation, retrieval, use, and disposition.

Records. All books, papers, maps, photographs, machine readable materials, or other documentary materials, regardless of physical form or characteristics, made or received by an agency of the United States Government under Federal law or in connection with the transaction of public business. Documents created, received, and maintained as evidence and information by an agency, organization, or person, in pursuance of legal obligations or in the transaction of business. Documentation of the organization, functions, policies, decisions, procedures, and essential transactions.

Records Capture. The recognition of a record resulting in its inclusion in a system that manages records operations.

Records Center. An establishment maintained and operated by the Archivist or by another Federal agency primarily for the storage, servicing, security, and processing of records which need to be preserved for varying periods of time and need not be retained in office equipment or space.

Records Maintenance and Use. Any activity involving location of records of a Federal agency or the storage, retrieval, and handling of records kept at office file locations by or for a Federal agency.

Records Management. The field of management responsible for efficient and systematic control of the creation, receipt, maintenance, use and disposition of records, including processes for capturing and maintaining evidence and information of business activities and transactions in the form of records.

Alternative definition: The planning, controlling, directing, organizing, training, promoting, and other managerial activities involved with respect to records creation, records maintenance and use, and records disposition in order to achieve adequate and proper documentation of the policies and transactions of the Federal Government and effective and economical management of agency operations.

Records Management Application. Software used by an organization to mange records. An RMA's primary management functions are categorizing and locating records and identifying records due for disposition. RMA software also stores, retrieves, and disposes of electronic records stored in its repository.

Records Retrieval. The process of recalling specific records from storage.

Records Storage Facility. A records center or a commercial records storage facility (i.e., a facility used by a Federal agency to store Federal records, whether that facility is operated and maintained by the agency, by NARA, by another Federal agency, or by a private commercial entity).

Records Systems. Information systems that capture, maintain, and provide access to records over time.

Repository of Electronic Records. A direct device on which the electronic records and associated metadata are stored.

Retention Period. The time period records are kept according to operational, legal, regulatory, and fiscal requirements.

Scanning. Imaging is a form of scanning technology that refers to transforming a paper document into a digital image. Capturing and processing information contained in forms is another application of scanning technology. When a form is scanned, key fields are captured, verified, and written to a database. Forms capture relies on OCR, bar code recognition, and other recognition technology to capture the content.

Scheduled Records. Records whose final disposition has not been approved by NARA.

Service Component/Capability. A component (or capability) is a business-driven, functional capability that assists an organization with mission accomplishment and/or performance objectives.

Service Layers. The collection of business oriented service categories that align service/component capabilities to a level in which they support the objectives and performance of the business components.

Storage. Measures for keeping records under defined conditions and permitting their retrieval.

Structure. The use of headings and other devices to identify and label parts of a document, and the use of visual emphasis (e.g., bold and italicized font) to convey part of the meaning of the content.

Vital Records. Essential Bureau records needed to meet operational responsibilities under national security emergencies or other emergency or disaster conditions (i.e., emergency operating records) or to protect the legal and financial rights of the Government and those affected by Government activities (i.e., legal and financial rights records).

Work process management. This technology is also referred to as workflow, work management, and process automation software. These tools automate processes and the interrelationship between sub-processes, tasks, participants, and management. Most document management software includes some workflow functionality (e.g., review/approval routing and e-mail notification). If additional processing and control features are needed, some vendors integrate well with third-party workflow packages

Appendix F: Acronyms

ConOps - Concept of Operations

COTS - Commercial off the Shelf

DocLab - Document Conversion Lab

DoD - Department of Defense

EA - Enterprise Architecture

EDMS - Electronic Document Management System

ERKC - Electronic Recordkeeping Certification

FBI - Federal Bureau of Investigation

FOIPA - Freedom of Information and Privacy Acts

IT - Information Technology

NARA - National Archives and Records Administration

OMB - Office of Management and Budget

RM - Records Management

RMA - Records Management Application

RMD - Records Management Division

Appendix G: FBI Metadata Requirements

Individual Documents

Element Definition/ Description

Unique RMA Identifier

A unambiguous system-generated data element that identifies a particular record.

Contributor Record ID

Unique ID provided by the Contributing System that identifies a particular record within that system.

File Number

Identifies the classification, sub-classification (alpha), Office of Origin, and Case number


Number assigned to the document within the Case ID.

Document Type

Code indicating the type of document. "TYPE"

Document Date

Generally the date appearing on the face of the document. In the case of e-mail it is date sent.

To/ Addressee

The recipient(s) of the document.

From/ Author - Individual

The originator of the document. The individual who creates, sends, or signs the document.

From/ Author - Organization

The organization to which the originator of the document belongs.

Title/ Subject/ Topic of Document

Generally the "name" of the document (e.g., the title of an EC or memorandum, the subject line of an email, or the title of a report, briefing, or spreadsheet).

Description/Abstract/ Notes

A brief narrative description about the record, which usually contains keywords.

National Security Classification

Identifies the classification level for the security classification. The document classification reflects the highest classification in the document.

Other Restrictions

Identifies a record to which a legislative or regulatory restriction has been applied.

Record Status

Indicates the distinction between the official record, a copy, duplicates, etc. The default would be Records. Generally inherited from the file classification or file number.

Document Disposition

Those actions taken regarding Federal records after they are no longer required to conduct current Agency business. Generally inherited from the file classification or file number.

File Classification Disposition

The disposition assigned to the file classification number. Can be permanent, disposable, sample/select -undetermined, sample/select - permanent, sample/select - disposable, or unscheduled.

Selection Criteria

If the disposition is sample/select - permanent, this identifies the criterion/criteria used to make that determination.

Records Schedule Identification

Identification of the approved disposition authority. Generally linked from the file classification.

Entry Date

The date the record was entered into the system.

Batch Documents (Managed at the file level or higher)
Individually Entered Data Elements

Element Definition/ Description

File Number

Identifies the classification, sub-classification (alpha), Office of Origin, and Case number.

Volume Number/ Sub-part of the Case File

Identifies the location of the record within the sub-sets of a physical case file.

Batch Generated Data Elements

Element Definition/ Description

Record Status

Indicates the distinction between the official record, a copy, duplicates, etc. The default would be Records.

Document Disposition

Those actions taken regarding Federal records after they are no longer required to conduct current Agency business. Generally inherited from the file classification or file number.

File Classification Disposition

The disposition assigned to the file classification number. Can be permanent, disposable, sample/select -undetermined, sample/select - permanent, sample/select - disposable, or unscheduled.

Selection Criteria

If the disposition is sample/select - permanent, this identifies the criterion/criteria used to make that determination.


The length of time that a record must be kept before it is destroyed, which is determined by scheduling.

National Security Classification

Identifies the classification level for the security classification. The document classification reflects the highest classification in the document.

Other Restriction

Identifies a document to which a legislative or regulatory restriction has been applied. (i.e. Rule 6(e) , FOIA, litigation matters. )

Scanning Project ID

Identifies the title of the Scanning Project.

System Generated Data Elements

Element Definition/ Description

Unique RMA Identifier

A unambiguous system-generated data element that identifies a particular record.

Entry Date

The date the record was entered into the system.


[1]Public Record Office, United Kingdom, e-Government Policy Framework for Electronic Records Management, 2001, p. 6.

[2]Public Record Office, United Kingdom, Management, Appraisal and Preservation of Electronic Records, Vol. 1: Principles, 1999, p. 10.

[3] For security reasons, the physical setup for access to electronic records by the public might include a separate web server and database server containing the replicated subset of only those FBI records that have been approved for FOIPA public release.

[4] Technology can be deployed that would allow the content to be moved to the records management content repository. However, this adds complexity to the architecture and system design without necessarily providing additional benefits.

[5]These definitions were taken directly from three sources: Title 44, USC, Section 3301; Title 36, CFR, Chapter XII, Subchapter B; and Design Criteria Standard for Electronic Records Management Software Applications, Department of Defense, DoD 5015.2-STD, June 19, 2002.

Last modified at 03/15/2005 02:25 PM