NARA-aligned file naming for federal agencies — the 2026 standard

What NARA actually requires (and doesn't)

The single most common misreading of NARA guidance, in our experience working with agency records officers, is the belief that NARA prescribes a file naming convention. It does not. NARA prescribes what a federal record has to be able to do, and the agency chooses the implementation.

NARA's actual requirements, in summary:

• Identifiable as records. The file is marked or organised in a way that distinguishes it from non-record content (working copies, personal files, duplicate drafts).
• Associated with a records schedule. Each record can be tied to a specific GRS item or agency- specific Records Control Schedule item, which determines retention period and disposition.
• Accompanied by sufficient metadata. Discovery, retention, and eventual transfer to NARA require metadata fields documented in NARA's transfer guidance for permanent electronic records.
• Preserved in a format NARA accepts. NARA publishes acceptable file formats for permanent electronic records. Agencies have to either preserve in an accepted format or migrate at the point of transfer.
• Findable for FOIA, litigation, and audit. The corpus has to be searchable by topic, date range, and custodian within reasonable response times.

Nowhere in that list is a specific naming convention. Conventions are the agency's tool for satisfying the requirements above — and well-designed conventions make every one of those requirements easier to demonstrate to an auditor or NARA appraiser.

The regulatory stack: M-19-21, M-23-07, GRS, agency schedules

Four layers govern how agencies handle federal records. Each has a different relationship to file naming.

M-19-21 and M-23-07

OMB/NARA Memorandum M-19-21 (June 2019) directed federal agencies to transition to managing records in electronic format, with paper-based records-management practices phased out. M-23-07 (June 2022) updated the deadlines and detailed the operational requirements. The substantive effect on file naming is that paper-era practices — file- cabinet labels, sign-out cards, manual cross-references — no longer cover the corpus. The file name itself is now the primary records-management surface. If the name does not let a records officer identify the records series, the agency is not equipped to demonstrate compliance.

General Records Schedule (GRS)

NARA maintains the GRS, which covers records common across federal agencies — administrative, personnel, financial, IT-operations, procurement. The GRS is organised into items (e.g. GRS 5.1, item 010) each with a defined retention period and disposition. The bulk of files in any agency's Drive fall under GRS items.

Agency-specific records schedules

Mission-specific records — the things the agency does that no other agency does — are governed by a Records Control Schedule the agency files with NARA. The RCS defines its own items, retention periods, and disposition. A naming convention has to be able to flag both GRS items and agency-specific items without conflict.

NARA Bulletins

Bulletins are the operational guidance layer. The two most relevant to naming are:

• NARA Bulletin 2013-02 — the Capstone approach for email, which captures senior officials' email as permanent records based on role rather than per-message classification.
• NARA Bulletin 2014-04 — metadata guidance for transferring permanent electronic records to NARA, defining the metadata fields the transferred records must carry.

Records officers should always verify against the current published versions at archives.gov rather than relying on third-party summaries (including this one).

What a NARA-aligned file name has to do

Five functional requirements emerge from the regulatory stack. A naming convention satisfies NARA when its names meet all five.

1. Identify the records series. A records officer should be able to look at the file name (or one metadata field cross-referenced from the name) and determine the GRS item or agency RCS item that governs the file.
2. Carry an unambiguous date. ISO 8601 (YYYY-MM-DD) is the standard choice. The date represents the content date (when the document was signed, the period it covers, the event it documents), not the file's last-modified date.
3. Communicate the subject. The name describes the content in enough detail that an analyst, a FOIA officer, or an AI agent can identify candidate files without opening them.
4. Survive technical constraints. Names stay under 255 characters, use only characters that survive cross-platform transfer (alphanumeric, hyphen, underscore, period for the extension), and avoid reserved Windows filenames.
5. Support audit. The name and an accompanying audit log together establish chain of custody — who created the record, who renamed it (if anyone), under what records schedule.

A recommended naming convention

The following convention satisfies all five functional requirements above. It is the convention PLUMdata defaults to for federal-agency deployments, and it adapts cleanly to most agency-specific records schedules.

Structure:

YYYY-MM-DD_<series-code>_<subject>_<modifier>.<ext>

Example, GRS-governed:

2026-03-14_GRS-5.1-010_quarterly-expenses-q1_signed.pdf

Example, agency-specific RCS:

2026-04-02_ABC-200-12_grant-award-buildco-project-northstar.pdf

Rules:

• Date first. Sorts chronologically by default in every file system, simplifies FOIA date-range queries, and survives migration between platforms.
• Series code second. Either the GRS item number (formatted as GRS-X.Y-NNN) or the agency-specific RCS item (formatted as AGENCY-NNN-MM, where AGENCY is the agency's standard short code).
• Subject in lowercase, hyphen-separated. Improves cross-platform predictability and reads cleanly in URLs, command-line tools, and search-result snippets.
• Modifier optional. draft, signed, amended, final — use only when a meaningful distinction exists.
• No spaces, no special characters. Alphanumeric plus - and _ only. The separator inside fields is -; between fields is _.
• Maximum 200 characters before extension. Leaves headroom for path length on Windows clients.

Embedding the records-series identifier

The hardest design decision is where the records series identifier lives. There are two viable approaches.

Approach A: in the file name

The series code appears as a field in the name itself (2026-03-14_GRS-5.1-010_...). Advantages: the schedule is visible wherever the file is, including in exported lists, FOIA productions, and AI-agent retrievals; the corpus is auditable without opening platform metadata.

Disadvantages: file names get longer; reclassification requires a rename (which is recoverable, but generates audit traffic).

Approach B: in platform metadata

The series code lives in a Drive Label (Google Workspace) or a Sensitivity Label / column (Microsoft 365), not in the file name itself. The name carries date + subject only. Advantages: shorter names; reclassification edits one metadata field, not a rename.

Disadvantages: metadata doesn't always travel with the file across platforms or in exports; the schedule becomes invisible to anyone reading file names without platform access.

Recommendation

Approach A is the safer default for agencies completing the M-19-21 transition. It produces names that are self-describing in any context, including when files are exported for FOIA, litigation, or transfer to NARA. Approach B is reasonable in mature environments where the platform metadata layer is robust and migration risk is low — but it depends on platform features that vary in completeness across vendors.

Most agency-of-record deployments PLUMdata sees use a hybrid: series code in the name and mirrored as a Drive Label, so the metadata layer can be queried programmatically without parsing names.

Email records and the Capstone approach

NARA Bulletin 2013-02 introduced the Capstone approach: the email of designated senior officials is preserved as permanent records based on role rather than per-message classification. The bulletin substantially simplifies email records management — the agency does not have to classify individual messages — but it has implications for how file naming interacts with email.

• Capstone-preserved email itself stays in the email platform's archive. The naming convention does not apply to the messages; the platform handles them as a managed corpus.
• Email exported to Drive or DMS for working purposes — for example, an attached document a project team is editing — does follow the agency's naming convention. The name should carry a source indicator (e.g. _email-export in the modifier field) so the relationship to the underlying email record is preserved.
• Attachments extracted from email and worked on independently become their own records and are named per the convention, with metadata linking back to the source message ID where the agency's platform supports it.
• Non-Capstone email (agencies that have not adopted Capstone, or non-Capstone accounts within a Capstone-adopting agency) still requires per-message or per-folder classification, and the naming convention applies to any exports.

CUI markings in file names

The Controlled Unclassified Information program, run by NARA's Information Security Oversight Office under 32 CFR Part 2002, defines marking requirements for CUI documents. The marking belongs in the document's banner line and footer, and is mirrored in platform sensitivity-label metadata. The default position is that CUI markings do not go in file names.

Reasons to keep CUI markings out of file names:

• Redundant marking is a marking error. CUI guidance treats the banner line and metadata label as the authoritative marking. A third marking in the name introduces drift when one of the three is updated and the others are not.
• File names appear in unrelated contexts. Auto-completion in email composers, recent-files lists, shared link previews, and analytics dashboards all surface file names. A CUI marking in the name leaks the control level into surfaces that are not themselves CUI- appropriate.
• Cross-platform transfer drops names but keeps content markings. If a file is moved to a platform that strips or transforms file names, the banner-line marking and metadata label persist; a name-only marking does not.

The exception is when the agency's local CUI marking guide explicitly directs filename inclusion (some IC and DoD components do). In those cases follow the agency policy and document the deviation from the default in the naming-convention written standard.

Migrating to electronic records: order of operations

Agencies completing the M-19-21 / M-23-07 transition typically combine three workstreams: a drive migration (often consolidating shared drives, network shares, and legacy DMS content into Google Workspace or Microsoft 365), a naming-convention rollout, and an RMA deployment. The order matters.

1. Inventory the source estate. Identify every shared drive, network share, and legacy system in scope. Capture file counts, type breakdowns, age distribution, and the records officer's estimate of which records series are present.
2. Design the naming convention. Per this guide. Document it as a one-page standard the records officer signs off on.
3. Apply the convention on the source platform. Rename files in place before migration. Migrating chaos produces migrated chaos.
4. Deduplicate and classify. Resolve version sprawl. Apply sensitivity labels and series codes.
5. Migrate the clean estate. The migration tool handles a corpus that already carries its records- management metadata.
6. Wire the records-management application. The RMA assumes responsibility for retention, disposition, holds, and transfer.
7. Deploy AI agents (if applicable). Against the migrated, named, classified corpus — never against a corpus mid-rename.

Skipping step 3 (rename in place before migration) is the single most common reason agency migrations overrun schedule and budget. The renames have to happen eventually; doing them first roughly halves the migration's wall-clock time and avoids re-indexing on the destination platform.

Records-officer checklist

Use this checklist to verify a proposed naming convention before rollout. If any row fails, the convention is not yet NARA-aligned.

Common pitfalls

• Treating NARA guidance as prescriptive on names. NARA reviews the result, not the convention itself. Agencies that wait for "NARA approval" of a naming convention wait indefinitely.
• Assuming modified-date is content-date. A document signed in 2023 and last edited in 2026 has a content date of 2023. The name should reflect 2023.
• Putting CUI in file names without policy cover. Generates a marking deviation that auditors will surface.
• Renaming during migration rather than before. Doubles the migration work and breaks cross-references that exist at the source.
• Confusing the naming layer with the records- management application. A naming convention does not perform disposition. Both are required; one does not replace the other.
• Skipping the records-officer sign-off. The records officer is the accountable party. A convention rolled out without their formal approval creates audit risk regardless of how well-designed it is.

Where PLUMdata fits

PLUMdata is the data-management layer between Drive content and the agency's records-management application. It is not an RMA and does not perform disposition or retention. What it does:

• Learns the agency's naming convention. A short onboarding with the records officer produces the written standard, including the records-series identifier scheme.
• Applies the convention with supervised approval. Every rename is previewed; the records officer or a designee approves file by file or folder by folder.
• Maintains an audit log. Previous name, new name, schedule item, approver, timestamp — exported to the agency's system of record.
• Reversible at every step. Full undo at every level of the rollout, so a misclassification discovered downstream is recoverable.
• Private by design. Files are processed in-session, never stored, never used to train AI — aligned with the agency's data-handling requirements.
• Hands off cleanly to the RMA. Once content is named, the agency's RMA takes responsibility for retention, disposition, holds, and eventual transfer to NARA.

Start with a scan of a single shared drive →

Frequently asked questions