BIM File Naming Convention: ISO 19650 Fields, Codes, and a Worked Example

What Is a BIM File Naming Convention?

A BIM file naming convention sets consistent rules for identifying digital project information, including Revit models, drawings, schedules, and reports. The goal is to make files traceable across disciplines, exchanges, and revisions. A useful name identifies the information container; associated metadata explains its current purpose, status, and relationship to the project.

Without agreed rules, “Level1_Final” could describe a local working version rather than an authorized issue. BIM naming standards reduce that ambiguity, but names cannot establish whether files are approved for construction.

The project BIM execution plan (BEP), information requirements, and document-control procedures should specify the expected structure, code lists, ownership, and revision process. ISO 19650 is an international information-management framework, not a universally mandated ten-field filename. Particular naming conventions become enforceable through project requirements or organizational procedures, subject to applicable contracts. A BIM execution plan example shows how such requirements become project-specific entries.

Which Fields Appear in an ISO 19650 Naming Structure?

A widely used UK-origin seven-field pattern identifies the project, originator, volume or system, level or location, information type, role, and unique number. It is useful for explaining BIM file naming rules, but it should not be presented as the only internationally valid ISO 19650 format. Current project conventions may be different.

This pattern is also available as a template in Autodesk Docs. Its default related attributes include Status, Revision, and Classification rather than treating them as three additional required filename segments. Some projects append them to exported names, but that is a configured project rule, not something to assume from the seven-field example.

The code lists and unique identifiers must be documented. Seven hyphenated strings alone do not prove compliance.

Which Codes Identify Levels, Locations, and File Types?

Location and type codes let a reader distinguish a floor-specific drawing from a model covering several zones. Older UK-style examples use ZZ for multiple or general locations and M3 for a three-dimensional model, but exact definitions vary with the adopted schedule. Teams should publish the allowed values rather than guess them from familiarity.

These codes are not globally compulsory. Newer schemes may combine building and floor information in a spatial breakdown field and rename Type as Form.

How Do Status and Revision Codes Work?

Status identifies the permitted use of an information container, while revision distinguishes successive controlled issues. A shared model for coordination is not automatically authorized for construction. In many ISO 19650-based CDE configurations, both values are stored as related attributes instead of being embedded in the filename, allowing the container identity to remain stable.

Confirm the project status table and authorization rules. A CDE can preserve revision history without changing a Revit model's base filename.

How Do You Build a BIM File Name Step by Step?

Start with the project's approved naming template, select one value for each required field, and check the resulting identifier for uniqueness. For a seven-field example, PRJ-ARC-ZZ-01-M3-A-0001.rvt could identify an architectural 3D model associated with Level 01. The example only works if the project has defined those codes.

• Confirm the project identifier and the originator's registered code.
• Select the volume or system and level or location values from the agreed lookup lists.
• Choose the information type and discipline codes for the actual container.
• Allocate a unique number without embedding unrelated revision claims.
• Check the extension, status, and revision metadata before sharing.

Read the result from left to right: PRJ identifies the job, ARC the organization, ZZ the selected volume designation, 01 the level, M3 the model type, A the discipline, and 0001 the unique sequence. The extension identifies the native file format; it is not one of the seven fields.

An ISO 19650 naming convention example is helpful only when its definitions are visible. For a building-wide model, Level 01 might be misleading; choose the agreed multi-level value instead. For a drawing, the project may require a different Type field and number series. Never silently invent codes during an exchange.

How Should Revit Working Models and Shared Files Be Named?

A Revit file naming convention should distinguish stable model identification from the workflow used to publish or exchange information. Some teams keep a practical internal working name and apply the project's agreed container identifier to deliverables. Others use the same controlled name throughout. Neither approach is mandatory for every Revit collaboration environment.

A central or cloud-hosted model may have linked models, worksharing settings, and publishing dependencies. Renaming it casually can disrupt established references. Follow the relevant Revit and CDE procedures when a name must change, and coordinate the update with all teams consuming the model.

A submitted RVT, exported IFC, and PDF drawing may represent related information but should not automatically receive identical identifiers. Their type, scope, status, and revision metadata need to match the information being delivered. A BIM file naming standard governs exchanges; it does not make the contents of a model accurate or coordinated.

What Changed in the UK National Annex to ISO 19650-2?

The UK National Annex update in 2021 changed its recommended information-container identification pattern from volume and level fields toward functional and spatial breakdowns. It also used Form and Discipline in place of the older Type and Role terminology. These are UK-specific recommendations, not a worldwide revision requiring US projects to rename all existing files.

Older UK-style format: Project – Originator – Volume/System – Level/Location – Type – Role – Number.

Updated UK recommendation: Project – Originator – Functional Breakdown – Spatial Breakdown – Form – Discipline – Number.

Functional breakdown describes what area of work or information purpose a container concerns; spatial breakdown identifies where it applies. This distinction can help an infrastructure team organize geographic segments that do not fit neatly into building-floor codes. Field lengths and detailed values are established through project documentation.

For US teams, the relevant question is which conventions the contract and project information requirements adopt. NBIMS-US Version 4 includes project BIM execution planning and references ISO 19650 information management, but it does not make the updated UK naming pattern compulsory for all American projects.

How Do You Apply and Enforce Naming Rules in a CDE?

A common data environment can enforce naming rules through ordered attributes, permitted codes, required metadata, and selected folders. Administrators first define the project naming policy, then configure and test it before broad adoption. Software validation helps catch noncompliant names, but people must still confirm that the selected codes accurately describe the submitted information.

In Autodesk Docs, project administrators can create a naming standard from an ISO 19650 template, a blank configuration, or an imported standard. The current workflow uses Files, Settings, Compliance, and Naming Standards. The selected convention can be applied to specified folders, while Status, Revision, and Classification remain separately managed related attributes.

A practical implementation follows five steps:

• Agree project fields, separators, allowable codes, and exceptions with the delivery team.
• Document the required structure in project information-management requirements.
• Configure naming attributes, related metadata, and folder enforcement in the CDE.
• Test sample RVT, IFC, PDF, and document files for compliant naming and correct metadata.
• Review noncompliant submissions and revise code lists only through a controlled process.

Folder rules do not guarantee that codes are semantically correct. A valid-looking filename may still identify the wrong level, discipline, or revision. Automation can validate syntax and permitted values, but issue authorization and technical review remain separate responsibilities.

Use a naming pattern that project participants can apply and audit. Define the fields, code lists, and revision controls in advance, following the project's adopted ISO 19650 requirements.