BIM Naming Conventions and File Standards: A Practical ISO 19650 Guide

A naming convention is the least glamorous document on a project and the first one that saves you when things go wrong. It is invisible when it works. Files land in the right folder, a coordinator can tell what a model is from its name alone, and nobody spends a Friday afternoon hunting for the current version of the structural model. It becomes very visible when it is absent. Two people edit two files both called “Building_Final_v2”, a consultant issues a model with no way to tell which floor it covers, and someone builds a set of drawings from a superseded file that was never meant to leave the office.

For a working BIM professional, a naming standard is not paperwork. It is the addressing system that lets a Common Data Environment function, lets automated checks run, and lets a team of people who have never met agree on what a file is without opening it. This guide covers the standard that most of the industry has converged on, the ISO 19650 information container approach, and shows how to turn it into folder structures, model names, and Revit view and sheet standards you can actually enforce.

Why naming is a coordination problem, not a filing problem

It is tempting to treat naming as housekeeping, something you tidy up at the end. That framing is wrong. On a BIM project, the file name is metadata that other people and other software read to make decisions. A coordinator filters a federated model by discipline using the role field in the file name. A document controller routes a file to the right review workflow using its status code. An automated script archives superseded files by reading their revision. When the name carries no reliable information, all of that work falls back to a human opening files and guessing, which does not scale past a handful of models.

The cost of a bad convention compounds. Early in design it is an annoyance. By the time you have twelve consultants, four hundred sheets, and a monthly issue to the client, an inconsistent naming scheme means nobody trusts the file server, everyone keeps private copies, and the single source of truth quietly stops being single. Getting this right at kickoff is one of the highest-leverage things a BIM lead does, and it costs almost nothing except discipline.

What a naming standard actually governs

A complete project standard covers more than model files. Before writing rules, list every kind of artifact the project produces and decide how each is named. On a typical Revit-based project that means:

• Information containers (files): models, drawings, schedules, specifications, reports, and any file exchanged through the CDE.
• Model internals: worksets, view names, sheet numbers, view templates, and the central file itself.
• Content: loadable families, project parameters, and shared parameters.
• Folders: the directory structure of the CDE and any local working areas.

The file-level convention gets the most attention because it is contractual, but the internal Revit standards are where a modeler spends every day. A perfect file name wrapped around a chaotic model with views called “Copy of Copy of Level 1” has only solved half the problem.

The ISO 19650 information container ID

ISO 19650 is the international standard for managing information over the life of a built asset. It does not dictate one universal naming string, but it defines the concept of an information container (any named, structured set of information, which in practice usually means a file) and requires that each one has a unique, systematic identifier. The most widely adopted implementation is the convention set out in the UK National Annex to BS EN ISO 19650-2, itself descended from BS 1192. It builds the identifier from a fixed set of fields separated by a delimiter, usually a hyphen:

Project - Originator - Functional Breakdown - Spatial Breakdown - Type - Role - Number

A real container ID looks like this:

ARCH01-AGN-XX-ZZ-M3-A-0001

Read left to right, that string tells you the project, who produced it, what part of the building and which level it covers, that it is a 3D model, that it came from the architectural discipline, and that it is the first in its sequence. You know all of that before opening anything. That is the entire point.

Field by field

Field	Purpose	Example values
Project	Short code for the whole project	ARCH01, HQ, a job number
Originator	The organization that authored the file	AGN, XYZ (3 to 6 characters)
Functional breakdown (Volume/System)	Which zone, block, or system	XX (all/none), 01, ZZ
Spatial breakdown (Level/Location)	Which floor or location	00 ground, 01 first, ZZ all levels, XX not applicable
Type	The kind of information	M3 3D model, M2 2D model, DR drawing, SP specification, RP report, SH schedule
Role	The originating discipline	A architect, S structural, M mechanical, E electrical, C civil
Number	Sequential identifier within the set	0001, 0002

The exact code lists (which type codes and role codes are valid) come from the project’s information standard, agreed in the BIM Execution Plan. Do not invent them per file. The two placeholder codes worth memorizing are XX, meaning “not applicable” or “multiple,” and ZZ, meaning “all.” A whole-building architectural model that spans every level is XX-ZZ in the two breakdown fields, which is the most common combination you will type.

Status and revision: the metadata that is not in the file name

The container ID identifies the file. It does not tell you whether the file is safe to build from. That is the job of two more pieces of metadata that ISO 19650 tracks alongside the container, usually as columns in the CDE rather than characters in the file name: suitability status and revision.

Suitability (also called status) codes describe what a container may be used for at a given moment:

Code group	Meaning	Typical codes
Work in progress	Being developed, not shared	S0
Shared (non-contractual)	Issued for others to use, not yet approved	S1 coordination, S2 information, S3 review and comment, S4 stage approval
Published (for use)	Authorized and accepted	A1, A2 and similar authorized codes

Revision tracks versions over time. The common convention uses a preliminary series during design (P01, P02, P03) and a contractual series once a container is published for construction (C01, C02). A file can be revised many times at status S2 before it is ever published. Keeping status and revision as CDE metadata rather than baking them into the file name is deliberate: it means the container ID stays stable while the file moves through its lifecycle, and it lets you filter a whole issue by status without parsing file names.

Folder structure: the four CDE states

ISO 19650 organizes information around a Common Data Environment with four states that a container moves through. Your folder structure should mirror these states directly, because the folder a file sits in should tell you what you are allowed to do with it:

1. Work in Progress (WIP): each team’s private working area. Files here are S0 and belong to the author. Nobody else builds on them.
2. Shared: files a team has checked and released for others to use for coordination or information. Moving a file from WIP to Shared is a deliberate act with a check attached, not a passive sync.
3. Published: the authorized, approved information issued for a purpose (construction, manufacture, client sign-off). This is contractual.
4. Archive: a full history of everything that was ever shared or published, so any past issue can be reconstructed.

A workable folder layout follows the same shape, with discipline subfolders inside WIP and clear gates between the states:

/PROJECT
  /1-WIP
    /Architecture
    /Structure
    /MEP
  /2-Shared
  /3-Published
  /4-Archive

The gates between folders are where quality lives. A file does not drift from WIP to Shared; someone runs the model check, confirms the status, and moves it. If you use a hosted CDE such as Autodesk Construction Cloud, BIM 360, or Trimble Connect, these states are built into the platform’s workflow and permissions rather than raw folders, but the four-state model is the same underneath.

Naming inside the Revit model

The file convention governs what leaves the office. Inside the model, a parallel set of standards governs what your team touches every hour. These are not covered by ISO 19650, but a good project standard defines them so every model in the federation feels the same.

Central file: name it to match its information container ID so there is no translation step at issue time. A central model named ARCH01-AGN-XX-ZZ-M3-A maps cleanly to the file you publish.

Worksets: use a consistent, sortable scheme such as a prefix that groups related elements, for example INT_Partitions, INT_Doors, EXT_Facade, SHELL_Structure. Avoid one modeler inventing “Manish’s walls” while another uses “Walls-New”. Worksets are a shared namespace and should read like one.

Views: a view name should encode discipline or purpose, level, and view type, in that order, so views sort logically in the Project Browser. Something like A_L01_FloorPlan or Coord_L03_3D beats “Level 1 Copy 3”. Decide whether views are grouped by a browser organization scheme early, because renaming three hundred views later is grim.

Sheets: follow a discipline-and-series numbering scheme such as A-101, A-102 for architectural plans, S-201 for structural sections, M-401 for mechanical. The first character is the discipline, the first digit the drawing type, the rest a sequence. This is the one internal standard clients most often specify, so check the appointment before you invent your own.

Families and parameters: name loadable families as Category_Description_Size or, where a manufacturer matters, Manufacturer_Category_Description. Keep shared parameter names free of software-specific abbreviations and version numbers, because a shared parameter name is effectively permanent once it is scheduled and tagged across a project.

Building your convention step by step

You do not need to author a standard from a blank page. Most of the time you are adopting the ISO 19650 UK convention and filling in the project-specific codes. A practical sequence:

1. Check the appointment and any client EIR. The Exchange Information Requirements or client BIM standard may mandate a convention. If it does, that wins. Do not build a parallel one.
2. Agree the codes in the BIM Execution Plan. Fix the project code, the originator codes for every appointed party, and the valid type and role code lists. This belongs in the BEP so it is contractual and shared.
3. Set the delimiter and field lengths. Decide the separator (a hyphen is standard) and the character count for each field, then never vary it. Fixed-width fields are what make automated parsing possible.
4. Define the folder structure and CDE states. Map WIP, Shared, Published, and Archive to actual folders or platform workflows, and name the gate checks.
5. Build a project template. Bake the view naming, sheet numbering, workset scheme, and browser organization into a Revit template so every new model starts compliant instead of being corrected later.
6. Write one page of examples. A single reference sheet with five correctly named files, annotated, teaches the convention faster than the full standard document. People copy examples; they skim rules.

Enforcing the standard

A convention nobody follows is worse than none, because it creates false confidence. Enforcement is where most standards quietly fail, so plan for it:

• Templates do the heavy lifting. If the correct sheet numbers, view names, and worksets already exist in the project template, compliance is the path of least resistance rather than an extra task.
• Check at the gate. Make correct naming a condition of moving a file from WIP to Shared. A file that does not parse cleanly does not get shared. Tie this to your model check.
• Audit periodically. Once a project has volume, run a scheduled check that lists files, views, or sheets that break the pattern. On a hosted CDE this can be automated; even a simple script that flags non-conforming names catches drift early.
• Assign an owner. Someone, usually the BIM coordinator or information manager, owns the standard and answers the “what do I call this” questions. Without an owner, small ambiguities get resolved five different ways.

Common mistakes

These are the failures that show up on real projects, in rough order of how often they cause pain:

• Putting status and revision in the file name. This makes the container ID unstable and produces Model_S2_Rev_P03_FINAL_v2 monsters. Keep status and revision as CDE metadata, not filename characters.
• Variable-width or optional fields. If the level field is sometimes two characters and sometimes three, no script can parse it. Fixed widths are non-negotiable for automation.
• Inventing codes per file. A modeler under deadline guesses a type code that is not on the agreed list. Now the filter misses their file. Fix the code lists once, in the BEP.
• Renaming after publish. A container ID, once issued, is effectively permanent. Renaming breaks references, links, and the audit trail. Treat published names as immutable.
• Ignoring the client’s convention. Building an elegant internal standard when the appointment mandated a different one means renaming everything at handover. Read the requirements first.
• No archive discipline. If superseded files are deleted rather than archived, you cannot reconstruct a past issue, which is exactly what you need when a dispute arises.

A note on national and regional variation

The UK National Annex convention is the most detailed and most widely copied, but it is not universal. Different countries implement ISO 19650 with their own national annexes and code lists. Germany, for example, has adopted DIN EN ISO 19650 but does not mandate a single file naming convention equivalent to the UK annex; the exact scheme is set per project in the information standard, so you confirm it in the project documentation rather than assuming a national default. The principle holds everywhere: unique, systematic, fixed-field container IDs, tracked through a four-state CDE. The specific codes are a project decision. Always confirm which annex or client standard applies before you lock your convention.

Where to start

If your projects run on ad hoc naming today, do not try to retrofit a perfect standard overnight. Start with the next new project. Adopt the ISO 19650 container ID, agree the codes in the BEP, build them into a Revit template, and write the one-page example sheet. On existing projects, resist the urge to rename published files; instead, apply the convention to new containers and let the old ones age out through the archive. The goal is not a beautiful document. It is a project where anyone can look at a file name and know exactly what they are holding, without opening it and without asking.

Naming conventions sit at the heart of how real BIM teams stay coordinated, which is exactly the kind of workflow the Archgyan courses are built around. If you want to go deeper into BIM coordination and the standards that hold a project together, explore the Archgyan course library and build the habits that make you the person a team can rely on.