![](media/image1.png){width="6.000694444444444in"
height="1.7965277777777777in"}

Electronic records Archives

Introduction to Policies, Templates, and Requirements Concepts

(TEMP v1.0)

(WBS #1.1.15)

for the

National archives and

Records administration

electronic records archives

program MANAGEMENT office

(NARA ERA PMO)

Final

December 5, 2003

Introduction to Policies, Templates, and Requirements Concepts

[]{#__RefHeading___Toc58297000 .anchor}Signature Page

Program Director,

I recommend approval of the Introduction to Policies, Templates, and
Requirements Concepts (TEMP).

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Dyung Le, Date

ERA Program

Approved,

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Kenneth Thibodeau, Date

ERA Program Director

[]{#__RefHeading___Toc58297001 .anchor}Document Change Control Sheet

**Document Title:** Introduction to Policies, Templates, and
Requirements Concepts (TEMP)

  ---------- ---------------------- --------------- -------------------------
  **Date**   Filename/version \#    **Author**      **Revision Description**

  12/05/03   ERA.DC.TEMP.1.0.DOC    Jon Valett/Ken  Final
                                    Thibodeau       

                                                    

                                                    

                                                    

                                                    

                                                    

                                                    

                                                    

                                                    

                                                    
  ---------- ---------------------- --------------- -------------------------

> TABLE OF CONTENTS

Signature Page [i](#__RefHeading___Toc58297000)

Document Change Control Sheet [ii](#__RefHeading___Toc58297001)

1.0 Purpose [1](#purpose)

1.1 Introduction [1](#introduction)

1.2 ERA Program Overview [2](#era-program-overview)

2.0 Document Assumptions [2](#document-assumptions)

3.0 Acronyms and Definitions [3](#acronyms-and-definitions)

4.0 Templates [3](#templates)

5.0 Linking Policies, Business Rules, Templates, and Requirements
Concepts
[4](#linking-policies-business-rules-templates-and-requirements-concepts)

6.0 Hypothetical Cases [5](#hypothetical-cases)

6.1 Deriving Control Requirements from Policies
[5](#deriving-control-requirements-from-policies)

Policies for Schedule Federal Records
[5](#policies-for-schedule-federal-records)

Business Rules and Templates for "Schedule Federal Records"
[6](#business-rules-and-templates-for-schedule-federal-records)

6.2 Application of Templates to the Lifecycle of Records
[7](#application-of-templates-to-the-lifecycle-of-records)

7.0 Conclusion [9](#conclusion)

List of Tables

Table 3-1: Acronyms List [3](#__RefHeading___Toc58291282)

Introduction to Policies, Templates, and Requirements Concepts

# Purpose

The purpose of this paper is to provide an introduction to the concept
of templates and how they relate to policies and requirements. The paper
does not completely define the concept, nor does it attempt to fully
articulate all its nuances. It is only meant to provide background
information to more fully understand concepts that are introduced in
other Electronic Records Archive (ERA) documents.

## **Introduction**

The ERA system will perform two (2) main functions in support of the
National Archives and Records Administration's (NARAs) mission. It will
contribute to NARA's lifecycle management of records of all kinds, and
it will ingest, manage, store, preserve and provide access to electronic
records which are transferred to NARA's physical or legal custody. Given
the high level of anticipated workload for the system, and the need for
efficiency, the ERA system should be highly automated. Automatic
execution of processes and transactions in both of the system's main
functions must conform to NARA policies and prescribed procedures. For
this to happen, the policies and procedures need to be implemented
within the system.

In this paper, a procedure can be defined as an established course of
action or a way of carrying out a business process. The procedures for
NARA's major processes within the scope of the system: Records
Management, Preservation, Archival Storage, Ingest, and Access, will be
supported by the workflow and related document management and records
management components of the system. These management processes, and the
system components which support them, involve transactions about
records, rather than processing of records themselves. In other words,
these components will support the production, receipt, use, and
management of *NARA's records* about the lifecycle management of the
records of other records creators. For example, the workflow component
of the system will enable agency officials to submit requests to
transfer federal records to a Federal Records Center or the National
Archives. The workflow component will be able to check automatically
whether the official is authorized to transfer records of the specified
agency, and whether the records schedule item cited in the request is in
fact authorized and applies to the agency, and possibly to the records
as described in the request. Workflow will automatically route requests
through proper channels in NARA and will support necessary messaging
between NARA and the agency about the transfer. These capabilities will
be applicable to all records. However, the workflow component of ERA
will not itself process any actual transfers of records. The ERA system
will interface with other systems that are used in support of the
processing of non-electronic records. The ERA system will actually
process electronic records, but that will be accomplished by system
components other than workflow. Therefore, other methods must be
employed to ensure that processing and management of electronic records
conforms to NARA policies.

This document describes a method for mapping NARA policies to the way
the ERA system will process and manage electronic records. There are two
(2), equally important elements in a mapping of policies to
requirements. Requirements determine where there is a need or
opportunity to apply policy, and policies determine what must or must
not be achieved at those points. This document does not profess to
contain definitive statements of NARA policies. Rather, it includes
illustrative statements of policy, which are only hypothetical, but
present a method for articulating policies in a manner that can be
implemented in the system. The design of the ERA system must be
policy-neutral; that is, the system should facilitate the implementation
of NARA's policies, whatever they may be, and it should make it just as
easy to change that implementation in response to subsequent changes in
policies.

The requirement for a policy-neutral system is an ideal, which should
guide design and development but cannot be fully achieved. In
particular, even before reaching the design stage of system development,
the possibility of policy neutrality is significantly constrained by the
things, such as records, records schedules, reference requests, etc,
that are represented in the system and by the way they are represented.
For example, if the representation of the standard form used for
transferring records to the National Archives in the system did not
include information indicating what restrictions on access apply to the
records, then the system would have no way of knowing that there are
such restrictions, so NARA policies regarding such restrictions would be
unimplementable. The things that need to be in the system, and the way
they need to be represented derive from the requirements assigned to the
system. Therefore, this document adheres closely to the requirements
defined in the *ERA Requirements Document (RD)*. In effect, NARA made
policy decisions in identifying and validating the ERA requirements.
Other policies have to be aligned with these decisions.

The remainder of this document describes the concept of templates,
relates the concept to business rules and requirements, and provides
examples of how templates may be used within the ERA system.

## ERA Program Overview 

ERA will be a comprehensive, systematic, and dynamic means for
preserving virtually any kind of electronic record, free from dependence
on any specific hardware or software. The ERA, when operational, will
make it easy for NARA customers to find records they want and easy for
NARA to deliver those records in formats suited to customers\' needs.

# Document Assumptions

The following assumptions were made during the development of this
document.

-   The TEMP's intended audience is the ERA development contractor and
    the ERA Program Management Office (PMO).

-   The TEMP is meant to provide guidance for the proposal phase of the
    ERA program. The concepts embodied in the TEMP are expected to be
    further refined and explored during the Analysis and Design Phase of
    the ERA program.

# Acronyms and Definitions

**Table 3-1, Acronyms List**, contains a list of acronyms used herein.

  -----------------------------------------------------------------------
  **ACRONYM**       **DEFINITION**
  ----------------- -----------------------------------------------------
  ConOps            Concept of Operations

  ERA               Electronic Records Archives

  FRC               Federal Records Centers

  NARA              National Archives and Records Administration

  PMO               Program Management Office

  RD                Requirements Document

  TEMP              Introduction to Policies, Templates, and Requirements
                    Concepts
  -----------------------------------------------------------------------

[]{#__RefHeading___Toc58291282 .anchor}Table 3-1: Acronyms List

# Templates

From a practical perspective, policies provide guidance in specific
cases, but they cannot prescribe every eventuality. Both the limitations
of NARA's knowledge about electronic records across the Government and
continuing change in information technology indicate that there will be
many specific cases which NARA cannot foresee in their entirety. A
method for both identifying and managing such cases is through the use
of 'templates'. The concept of a 'template' was adopted by the
Integrated Product Teams responsible for drafting the ERA *Concept of
Operations (ConOps)* and *Requirements Document (RD)*. This concept was
intended to be an abstract manner of expressing requirements that apply
to electronic records without prejudicing the selection of technology to
implement these requirements. While not explicit, it reflected a
preference for preserving electronic records in a self-describing form;
that is, where a record includes internal marks which identify the
elements of content of the record and their organization within the
record, which can be evaluated without the need for external references.
A self-describing record may be linked to an external model, a
"template", which specifies and characterizes the elements that are
either required or permitted in a record of that type. This is the
concept of a "compliant" self-describing record. The *RD* states that
NARA will apply templates to a wide variety of its assets. This broad
application of templates is necessary to optimize the potential for
automation in ERA. The application of the concept of 'template' to the
lifecycle management of records is simply recognition of
long-established practice. For example, Standard Forms 135 and 258, for
transfer of record to a Federal Records Center (FRC) and offers to the
National Archives, respectively, are templates for those types of
transactions. The ERA system will extend these existing models, which
relate only to information about the transaction and the actors
involved, to cover the sets of electronic records involved in those
transfers. The use of templates for sets of records is necessary
because, in order for ERA to provide access to sets, such as series and
file units, of electronic records, it will have to have a way to
identify the records which belong in any set and a way to virtually
arrange the records according to their original order.

Automation is likely to entail changes in existing templates. For
example, as long as records schedules are interpreted by humans, it is
possible to write disposition instructions in a way that allows a person
of average intelligence to interpret them. However, to automate the
execution of those instructions, it is necessary to formulate them in a
manner which enables them to be translated correctly and unambiguously
into executable form.

NARA expects to implement a hierarchical scheme for managing templates.
There will be two (2) independent hierarchies of templates,
corresponding to the two (2) basic classes of objects to which templates
are applied: records themselves, and lifecycle management processes
related to records. In each, higher level templates will tend to be more
general in their articulation and broader in their application. Lower
level templates will be expressed more precisely and applied more
narrowly. The top layer(s) of each template hierarchy will consist of
one (1) or more templates established by NARA and constituting standards
for the domain to which they apply. For example, templates related to
lifecycle management processes should be subdivided according to the
different types of processes. For the disposition process, the top level
template for disposition agreements would apply to all possible
disposition agreements and would include broad requirements, such as the
identity of the records creator and the records covered by the
agreement, and articulation of a disposition instruction which indicates
the type(s) of disposition actions which will be taken in implementing
the agreement. At the next lower level, there would be a template for
each of the different types of disposition agreements NARA uses: deed of
gift, deposit agreement, and Federal records schedule. Another level
down from Federal records schedules, NARA would specify templates for
agency records schedules and General Records Schedules. Similarly,
standard templates for records and sets of records would be subdivided
based on type of record or type of record set.

Below the NARA standard templates, agencies, and other records creators,
may define more precise templates that apply specifically to their
records, at varying levels of granularity. Any agency template must
conform to the relevant NARA standard template. That is, the agency
template must include all the elements required by the NARA standard, it
must identify and describe any elements qualified as optional in the
standard, using the specifications for characterizing optional elements
set out in the standard template, and it must exclude any elements
precluded by the NARA standard. Agency templates may also include
additional elements which are not referenced in the NARA standard but
are important for agency purposes. For such elements, agency templates
must simply conform to NARA standards for articulating templates for
transactions, records, or record sets. Once an agency has established
and registered with NARA a conforming template, it may refine that
template at lower levels, without limit, to describe subsets of its
records, provided that conformance with the relevant NARA standard
template can be traced from top to bottom of the hierarchy in all cases.

# Linking Policies, Business Rules, Templates, and Requirements Concepts

This document applies the following concepts to the ERA system:

-   **Policy**: a management direction concerning users or use of the
    system or objects that enter, exist in, or exit from the system.

-   **Business Rule**: An executable command within the system that
    implements a policy or a domain requirement, either uniformly or
    under specified conditions.

-   **Template**: a static prescription concerning required, allowed or
    excluded attributes and operations for objects or classes of objects
    in the system.

-   **Other Control**: another method used to implement a policy in a
    system; e.g., user access right, security, and standard.

These concepts can be mapped to the ERA requirements by starting with
the high level functional requirements; stating policies that apply to
each function; identifying the business objects that are involved in
carrying out the functions; articulating specific business rules that
apply a policy to a class of objects; and then determining how that rule
can be implemented in a template or another type of control.

NARA's policies, principles, and business rules should be implemented in
ERA for each of the NARA mission processes grouped under the following
headings in the *RD*:

-   Records Management

-   Preservation

-   Archival Storage

-   Ingest

-   Access

# Hypothetical Cases

This section provides illustrative examples of how NARA's policies,
business rules, and templates could be implemented in ERA. The first
illustrates the derivation of business rules and requirements for other
controls from NARA policies. The second illustrates the role of
templates in an empirical scheduling scenario based on a hypothetical
series of records.

## Deriving Control Requirements from Policies

This case starts with hypothetical policies applicable to the top level
ERA requirement, "ERA1 The system shall manage the disposition of
records." It focuses on the specific management process, "Schedule
Federal Records." The policy statements are used to derive general
business rules needed to implement them in the system. Then, elements
that need to be in templates in order for the business rules to execute
are identified. In some instances, more precise business rules can be
tied to the application of templates, such as for special cases, for
handling exceptions to more general rules, or for specifying terms or
conditions linked to the general rules.

### Policies for Schedule Federal Records {#policies-for-schedule-federal-records .unnumbered}

-   All Federal records must be retained and destroyed in accordance
    with an authorized records disposition schedule.

-   Schedules for specific sets of records are proposed by the creating
    agency.

-   Schedules for abstract classes or sets of records are proposed by
    NARA.

-   Records schedules are authorized by NARA.

-   Archival appraisal is a prerequisite for authorization.

-   Transfer of physical and/or legal custody of records to NARA should
    be specified in an authorized schedule.

### Business Rules and Templates for "Schedule Federal Records" {#business-rules-and-templates-for-schedule-federal-records .unnumbered}

*Policy*: Federal records must be retained and destroyed in accordance
with an authorized records schedule

-   *Business Rule*: Any transaction in ERA to bring Federal records
    into the system or remove them from it must conform to an authorized
    schedule item

```{=html}
<!-- -->
```
-   *Template*: The template for Records Schedule would include a
    'schedule item' element which would specify how the records covered
    by the item are to be identified. A schedule item would include a
    sub-element, 'disposition rule,' which would indicate if the records
    are temporary or permanent and could provide for transfer to an FRC.
    For permanent items, the default rule would require stipulating when
    records should be accessioned into the National Archives. For both
    transfer and accessioning actions, the template would require
    specification of what subset of the records covered by the item
    should be included in a single transfer.

    -   *Business Rule Condition*: For permanent records to be
        transferred to an FRC, that transfer must precede, by a minimum
        of x years, accessioning into the National Archives.

    -   *Template*: The template for Disposition Rule should include an
        element specifying how long permanent records are to be stored
        in an FRC before they are offered to the National Archives.

    ```{=html}
    <!-- -->
    ```
    -   *Business Rule Exception*: NARA may authorize ad hoc transfers
        of unscheduled records to an FRC or the National Archives.

        -   *Template*: The template for Records Center Transfer should
            include an optional element for authorization, by an
            appropriate NARA official, of transfer of unscheduled
            records.

*Policy*: Schedules for specific, empirical classes or aggregates of
records are proposed by the creating agency

-   *Business Rule*: schedules proposed by an agency must be submitted
    by the agency's records officer.

    -   *Template*: The Records Schedule Template must include an item
        identifying the records officer.

    -   *Other control*: authority list of designated records officers.

-   *Business Rule*: Items in an agency records schedule must
    unambiguously map to one (1) or more sets of records defined in the
    agency's recordkeeping system.

    -   *Template:* The 'Item' element in the Records Schedule Template
        must specify what records are covered by the item in accordance
        with the records classification scheme and, if applicable, with
        organizational location within the agency. The Template for
        Records Classification Scheme must include an element which
        uniquely identifies each aggregate of records and is identical,
        or unambiguously mapped to, the identification of the records in
        the Records Schedule Item Template.

-   *Business Rule*: a series or sub-series of records must have one (1)
    and only one (1) disposition rule.

    -   *Template*: the description of a set of records in a Records
        Schedule or in a linked Records Classification Scheme must be
        sufficient to enable ERA to check if any proposed schedule item
        duplicates another item in any authorized schedule applicable to
        the same organization.

## **Application of Templates to the Lifecycle of Records**

This case uses a hypothetical body of records, the correspondence files
of an agency head. This series of records has existed since the agency
was created. It is divided into two (2) subsets: routine or "bulk"
correspondence and special correspondence. Routine correspondence
consists of mail from the general public which either requires no
response or is appropriate for a standard response, such as agency
leaflets or form letters. Special correspondence is correspondence which
requires a specific response. Both sets are filed by subject. Currently,
special correspondence is kept as scanned images of both the incoming
and response, and a database is used to identify both and to track
assignments and status in preparation and sending of the response.
Routine incoming correspondence is kept on paper. Rather than keep a
copy of the response to an incoming routine message, the agency
annotates the incoming letter to identify the response provided and the
date it was sent. It also retains exemplary copies of each form letter
and leaflet. In the case of letters which receive a standard response,
the database identifies which response was sent. The agency's records
schedule designates all the special correspondence as permanent. A
statistical sample of routine correspondence is kept permanently. The
rest is destroyed three (3) years after receipt. The records covered by
the two (2) permanent Schedule Items are transferred to the National
Archives in annual files. The agency records schedule needs to be
updated to reflect the fact that special correspondence is now kept as
digital images and to provide for disposition of the database. This
example traces the revision of the schedule as it would occur in the ERA
system.

The process begins with the agency's records officer logging onto the
ERA system and retrieving the Schedule Item for the correspondence files
and indicating a change is needed in the Sub-Item for special
correspondence. The template for Agency Records Schedule requires that
the Description of permanent Records identify whether the Records are
Hard Copy or Electronic Records. The records officer changes the
designation of special correspondence from Hard Copy to Electronic
Records. The template requires that the Data Format(s) of Electronic
Records scheduled for transfer to NARA be specified, so the system
prompts the user to enter that information. From Authority Lists
provided by the system, the user selects both TIFF images and relational
database as Data Formats. NARA's business rules for transfer of
Electronic Records require an associated Preservation and Access Plan
which stipulated how NARA will preserve the Records to support required
Reference Services for as long as needed. The system provides the user
with a draft Preservation and Access Plan, based on the NARA standard
template for a Preservation and Access Plan for Permanent Electronic
Records, and prompts the user to enter additional specifications related
to each Data Format; for example, it asks whether the TIFF images are in
single page or multi-page files, and it asks the user to identify
required and optional technical specifications for the database and the
format in which each of these will be transferred. The system also
requests the user to select a Transfer Mechanism (physical media or
online transfer) which will be used to move the Electronic Records from
the agency's system to ERA. These technical specifications are entered
into a proposed Preservation and Access Plan for the sub-series of
special correspondence.

At this point, the system modifies its representation of the record set
for special correspondence to create three (3) lower level sets:

-   The hard copy files which were maintained from the start of the
    series until the switchover to scanned images;

-   The scanned images, which have the switchover as start date and
    which are designated as a successor to the hard copy files; and

-   The database, which has the same start date as the images.

The system prompts the user to update the Disposition Instruction for
this Sub-Item. The records officer reviews the current instruction and
determines that no change is required: the records will continue to be
sent to NARA in annual batches. The records officer logs off.

The system then alerts the NARA appraiser responsible for the agency
that a change has been proposed to the Records Schedule. The system
presents both the proposed Schedule Item and the draft Preservation and
Access Plan to the appraiser. The appraiser determines that the change
is not in the nature of the Records, but in the way the Records are
kept; therefore, the permanent value of the sub-series does not need to
be reappraised. In reviewing the draft Preservation and Access Plan,
however, the appraiser determines that additional information is needed.
For example, in order to reconstitute subject files, and even to link an
incoming letter with its response, NARA needs to know whether the images
of the letters are stored as binary objects within the database, or
separately. The first alternative is NARA's standard method for
re-establishing Record Aggregates which include document images and
related data. Using this approach, queries against the database would be
sufficient to identify and retrieve and incoming/response pair and to
reconstitute the subject File Units. However, the appraiser learns that
the image files of special correspondence are stored outside of the
database. NARA needs to affirm that the database contains pointers to
the images stored elsewhere and what type of pointer is used. If the
pointer is a persistent identifier that is inextricably linked to the
image file, NARA will be able to use the pointers to retrieve related
letters and File Units. However, if the pointers are platform dependent,
such as physical addresses or directory paths in the agency's system,
the pointers will have to be replaced with persistent identifiers, and
the correct identifier will have to be embedded in the metadata of each
image file. The records officer informs the appraiser that the database
entry for each item of correspondence contains the directory path to the
file where the letter is stored. This constitutes an exception to the
applicable NARA Preservation Standard, so the appraiser asks for the
assistance of a preserver in negotiating with the agency terms and
conditions for the Schedule Item which will enable transfer of the
Records from the agency's system to NARA and re-establishment in ERA of
the Record Aggregates in the sub-series. Upon completion of the
negotiation, the terms and conditions are included in the Schedule Item,
and corresponding methods specified in the Preservation and Access Plan.

# Conclusion

This document suggests three (3) approaches NARA can use to develop
standard templates for use in the ERA system. The first approach is to
delineate different domains in which templates will be used. **Section
4** of this document suggests two (2) basic domains: record objects and
records lifecycle management processes, and it suggests further
subdivisions of these domains. Each domain will be the locus of a
hierarchy of templates. The second and third approaches are illustrated
in the two (2) examples in **Section 6**. They are, in effect, methods
for specifying the content of templates within a domain. The first
method is a top-down approach which starts with NARA policy, articulates
the business rules that need to be executed to implement the policy in
the system, and then identifies elements that need to be in templates to
ensure that the rules can be executed in individual cases. The second is
a bottom-up approach which describes scenarios for use of the system and
identifies the role template(s) play in carrying out the scenario.
Logically, the top-down method is most suitable for articulating
templates in the lifecycle management process domain, while the
bottom-up approach is appropriate for articulating templates in the
record objects domain. However, the examples show that both methods can
yield refinements in either domain.