GovKM Proposed Standards and Guidance
Keep Documents Identifiable When Names and Locations Change
Practical guidance for assigning stable document identities, distinguishing versions and copies, preserving references through moves, and documenting uncertain legacy files.
GovKM-proposed public draft. Published for public review. Not externally accredited or endorsed.
View the EICARS framework resourceDocument
EICARS implementation guidance
Checklist coverage: R01.1–R01.4 | Based on the GovKM-proposed EICARS v0.1 public draft | November 5, 2026
A document should remain identifiable after someone renames it, moves it to another folder, or transfers it to another system. Staff should also be able to distinguish its approved version from an earlier draft or a convenient copy. This helps an organization retrieve the right information, preserve required records, and explain what was used for a business action.
This guide describes practical ways to meet the four identity items in the EICARS public draft. Organizations can use existing applications, document libraries, records systems, or a controlled register. Select the approach that fits the information and its obligations. No AI system is needed.
Purpose and boundaries
The intended result is straightforward: an authorized person can identify an in-scope item and its relevant version without relying on a familiar filename, a particular employee, or an unchanged folder path.
Here, an artifact means an item of organizational information, such as a document, dataset, report, or case attachment. An identifier distinguishes the item within a defined collection. A version identifies a particular revision. A copy is another instance of an item or version. Its separate location does not by itself make it a new revision or a governing source.
This is implementation guidance. The published standard controls a conformance assessment. Examples, sample register columns, and demonstration methods below are suggestions, rather than additional legal requirements. Identification alone does not establish approval, decision authority, record status, or permission to access the item.
Choose a manageable starting scope
Begin with a defined collection, such as one policy library, an acquisition case series, or a set of operational reports. Name the responsible business owner and identify the staff who administer the repository and its records obligations. Record which items and systems the first implementation covers.
Inspect existing capabilities before introducing a new identifier. A document or record system may already assign a suitable ID. Check whether the ID is unique in the intended scope, remains available after changes, can be used by authorized users to locate the item, and can be retained or mapped during an export. Do not assume that every application’s internal number has these properties.
Responsibilities
On smaller screens, scroll the table horizontally to view every column.
| Role | Responsibility |
|---|---|
| Business owner | Defines the collection and confirms which documents and versions staff should use. |
| Records official | Determines applicable recordkeeping, preservation, retention, and disposition obligations. |
| Repository administrator | Checks identifier behavior, access, exports, moves, and version-history capabilities. |
| Content steward or designated staff member | Maintains references and reports duplicate or uncertain identity. |
| Reviewer | Examines evidence and performs representative checks before recording the scoped outcome. |
One person may hold several roles where organizational policy permits. Existing approvals and separation-of-duties requirements still apply.
R01.1 Assign a stable identity
Checklist outcome: Give each in-scope artifact a unique, persistent identity within a declared namespace, distinct from its location.
Define the collection in which identifiers are unique. This is the namespace. An identifier such as POL-0042 is useful only when its collection or organization is also clear. Record who assigns identifiers, how collisions are prevented, and what happens when an item is retired.
Use the application’s existing document or record identifier if its behavior meets the collection’s needs. Otherwise, a controlled list or register may be suitable for a small collection. Avoid independently maintained lists that can issue the same identifier twice. Keep the assigned identity stable through routine title and location changes.
Example: A facilities office assigns FAC-POL-0042 to a travel policy document. Its display title and storage path may change. Authorized users can still look up that identifier and locate the relevant document. A different policy receives a different identifier.
Evidence to retain: The identifier convention, collection scope, assignment responsibility, and representative examples showing unique assignment. Evidence should demonstrate actual behavior as well as the written rule.
R01.2 Distinguish versions and copies
Checklist outcome: Distinguish the artifact, its revisions, and its copies, and explain how users locate the intended source and version.
Decide how the repository identifies revisions and how an authorized user can select a specific one. Use existing version history where it is adequate. Where exports omit that history, retain the version information needed for the business task and applicable records obligations. A filename ending in “final” is insufficient evidence of approval or version.
Explain how staff identify the designated source. Copies distributed for convenience should retain enough information to identify their source and version. A copy may acquire its own recordkeeping significance through use, annotation, or a separate business transaction; records officials should determine its treatment. Do not automatically discard apparent duplicates.
Example: The policy remains FAC-POL-0042. The repository distinguishes revisions 2 and 3. A PDF distributed from revision 3 identifies that revision and points authorized users to the designated source. A reviewer examining an earlier decision can request revision 2 when the task requires it.
Evidence to retain: Version history or a version register, source designation, and representative distributed copies. Show that a reviewer can distinguish an earlier revision from the intended revision.
R01.3 Preserve references through moves
Checklist outcome: Preserve a resolvable reference or governed mapping through a rename, move, or migration; identify broken or unknown legacy mappings.
Before moving information, check what happens to existing references. Suitable approaches include a repository-managed stable reference, a maintained location register, or an approved migration crosswalk. Choose according to scale, access restrictions, and the capabilities of the participating systems. A reference should lead an authorized user to the intended item or provide a controlled way to request it.
Include necessary versions and associated metadata in migration planning. Reconcile the moved population with the approved scope and investigate omissions. If the target system assigns new internal IDs, preserve the old-to-new correspondence where needed, rather than assuming the old ID still works. Test the actual route users follow.
Example: The facilities library moves to another enterprise repository. Its approved migration record associates FAC-POL-0042 with the target location. Staff test that reference after the move, including access by an authorized reviewer and a denied-access case. Protected filenames and metadata should not be revealed through a public locator.
Evidence to retain: The approved move scope, any location mapping needed, reconciliation results, reference checks, and unresolved exceptions. Preserve access controls throughout the change.
R01.4 Document uncertain legacy identity
Checklist outcome: Record unresolved historical identity without inventing equivalence. Retain disposition references only where retention and privacy rules permit.
Older collections may contain similar files with incomplete histories. Record what is known and what remains uncertain. A case note can identify the affected items, the question requiring resolution, the available evidence, the responsible reviewer, and the status of the investigation. These are example administrative fields, not a required technical format.
A matching title is not sufficient evidence that two files are interchangeable. A content comparison can help investigate similarity, but does not establish approval, legal authority, or the business role of a copy. Keep uncertainty visible until a responsible official can make a supported determination. If the evidence cannot resolve the question, retain that limitation rather than presenting an unsupported match as established fact.
Example: Staff find two PDFs labeled “Travel Policy 2019” with different text and no reliable approval information. They record both locations and the unresolved question. They do not merge the files or select one solely because it has a newer upload date. The business owner and records official determine the next permitted action.
Evidence to retain: The case note, supporting records, reviewer determination or unresolved status, and any approved corrective action. Record only necessary personal or sensitive information. Do not keep deleted content or identifying references indefinitely merely to preserve a register.
A simple register when one is needed
A small collection may use an existing controlled list with columns for the item identifier, descriptive title, revision reference, designated source or location, responsible office, and unresolved issues. Use only the columns needed for the task. Record approval status only when supported by the organization’s approval evidence.
A register is helpful only if someone maintains it and users can rely on it. It does not replace a repository’s retention, security, legal-hold, or records-management functions. Larger collections may need existing automated repository capabilities rather than manual maintenance.
Evidence and completion checks
Agree the tested population, sample selection, expected results, and acceptance conditions before assessment. Use safe examples or approved test material for moves and access checks. Record the date, assessor, observed result, evidence reference, and any limitation for each check.
On smaller screens, scroll the table horizontally to view every column.
| Item | Suggested demonstration | Result to record |
|---|---|---|
| R01.1 | Identify several in-scope items, including items with similar titles. | The identity is unique within the declared collection; assignment rules and exceptions are documented. |
| R01.2 | Retrieve an earlier revision, the intended revision, and a distributed copy. | The reviewer can distinguish each and identify its designated source. |
| R01.3 | Rename or move an approved test item and follow the reference afterward. | The intended item and required version remain locatable by authorized users; restrictions remain enforced. |
| R01.4 | Inspect an uncertain legacy case and its handling. | Known facts, unresolved questions, responsibility, and supported decisions are visible. |
Where no uncertain legacy case exists in the assessed population, record that finding and demonstrate the handling procedure using an approved hypothetical example. Do not create false production history for a test.
Record a gap when a required outcome is not demonstrated. Assign a responsible owner and review date, then verify any correction. Passing these four checks does not establish conformance with all EICARS domains, certify legal compliance, or approve an AI deployment.
Common mistakes
- Using filenames or folder paths as the only identity.
- Reissuing an old identifier to an unrelated item.
- Assuming an application’s internal ID survives an export or migration without checking.
- Overwriting an earlier revision needed for an approved business or records purpose.
- Treating a similar-looking copy as an approved source.
- Deleting apparent duplicates before checking records obligations and holds.
- Publishing a locator that exposes protected document titles or metadata.
- Marking the collection complete while material exceptions remain unexplained.
Continue the checklist
Return to the EICARS standard to review the other domains. Source authority, approval, retention, security, and evidence requirements must also be addressed within the organization’s declared scope.
Implementation overview
Use this guide within a declared organizational scope. Assign responsible staff, inspect existing repository capabilities, implement suitable controls and retain evidence for R01.1–R01.4. The examples are suggested approaches; the EICARS standard governs a scoped conformance assessment.
Standards traceability and references
Version history
Version 0.1 — November 5, 2026. Initial public implementation guidance for EICARS R01.1–R01.4, published with Robert Noyes’s approval. Government references verified November 5, 2026. This guidance does not amend GovKM doctrine.