Naming conventions get filed under paperwork. Something a document controller enforces, something that shows up in a BIM Execution Plan as a box to tick, easy to treat as the least interesting part of any BIM process. That reputation is undeserved, and understanding why requires looking at what a filename is actually doing on a project running through a Common Data Environment.
A filename isn't just a label a person reads to recognize a file. On a project of any real size, it's the only thing standing between a person, or a script, and a specific piece of information buried inside thousands of others. ISO 19650-1 defines an information container, in clause 3.3.12, as a named persistent set of information retrievable from within a file, system, or application storage hierarchy. Retrievable is doing real work in that definition. A container that can't be reliably identified by its name isn't fully meeting what the standard expects of it, no matter how good the content inside it is.
ISO 19650-2 requires that every information container carry a unique ID, built from an agreed and documented convention, made up of fields separated by a consistent delimiter, with each field's value drawn from an agreed and documented codification standard. The base standard doesn't fix what those fields are. That detail is left to national annexes and to each project's own information standard.
In the UK, following the 2021 revision to the National Annex, the recommended field order is Project, Originator, Functional Breakdown, Spatial Breakdown, Form, Discipline, and Number. A real filename built on that structure might look like:
STJ-CDE-RAD-L03-DR-S-1001Read field by field: STJ identifies the project, a new hospital scheme. CDE identifies the originator, the organization responsible for producing this container. RAD identifies the functional breakdown, the radiology department within the building. L03 identifies the spatial breakdown, level three. DR identifies the form, a drawing rather than a model or a report. S identifies the discipline, structural. 1001 is the running number distinguishing this container from others of the same type.
Every one of those seven fields answers a specific question about the container without anyone having to open it. That's the entire value proposition. A person or a system scanning a document register can filter, sort, and locate containers purely from the name, because the name itself carries structured data, not just a description.
It's worth being precise about something easy to overstate: ISO 19650 itself does not mandate this exact seven-field sequence as a universal rule. What it requires is that a project have a consistent, documented structure, agreed before information starts flowing, and applied without exception across every organization contributing to that project. The UK National Annex's specific field order is one national implementation of that requirement, and it changed noticeably with the 2021 revision, which loosened field-length restrictions and reordered fields to work better for infrastructure projects where concepts like "level" don't always apply cleanly. Other countries adopting ISO 19650 build their own annexes with their own field structures, and even within a single country, a project's own information standard can define project-specific codes on top of whatever the national annex suggests.
The requirement isn't the specific field order. The requirement is that a project pick one, document it, and hold every contributor to it without exception.
Here's the part that makes this more than administrative housekeeping. A naming convention only delivers its value if every organization on a project builds their filenames using the exact same field order. The moment two firms diverge, even slightly, the failure that follows isn't loud. It's silent.
Picture a second firm on the same hospital project, a facade consultant, who builds their filenames with fields in a different order, originator first, then project, then discipline, then everything else. Their filename for a facade panel drawing might come out as CDE-STJ-F-DR-L03-EXT-0450. Structurally it looks the same as the structural team's filename, seven fields, hyphen-delimited, alphanumeric codes. But a script or a person relying on position rather than an explicit field map, assuming the first field is always the project code, would read CDE as a project identifier on this file and STJ as an originator code, both wrong, both silently wrong. No error gets thrown. The parser doesn't crash. It just returns a result that looks entirely plausible and is completely incorrect.
This is the exact shape of failure that makes inconsistent naming dangerous rather than merely untidy. A filtering query that pulls "all containers for project STJ" would miss every container the facade consultant produced, not because the data doesn't exist, but because the field carrying that data sits in a different position in their name. Nobody gets an error message. Someone just quietly works from an incomplete document set, and the gap is only discovered later, if it's discovered at all.
A consistent, well-documented naming convention solves exactly one problem: making a container's structured metadata reliably parseable by name alone. It says nothing about whether the content inside that container is actually correct. A structural drawing named with a flawless, perfectly ordered filename can still describe a beam that doesn't match what's really specified, or reference a revision number that no longer corresponds to the current design intent inside it. The name is a label applied to the container from outside. It carries no information about whether the data on the inside is true, which is the same boundary this whole module keeps circling back to at a different layer each time.
Comments use a free GitHub account — takes under a minute to create, and keeps discussions spam-free and permanently archived.