Almost every design office knows this file: floor_plan_FINAL_v3_fixed(2).dwg. The name says nothing about whether it’s really the final version, who fixed it, or whether a site engineer is even allowed to build from it. And yet names like this keep circulating on shared drives, in email inboxes and shared folders for years.
Where the problem comes from
A hand-typed file name answers the question “what am I doing with this document right now”, not “what is this document”. That’s where FINAL, FINAL2, FINAL_fixed, to send, NEW come from — words that made sense to the author at the time, but stop making sense once the file reaches someone else, especially months later. On top of that, teams aren’t consistent with each other: an architect names files differently than a structural engineer, and a contractor differently than both.
What a convention looks like
A naming convention solves this by splitting the name into fixed fields, each answering one question. A typical ISO 19650-style layout looks like this:
ZDB-PCM-B1-00-DR-A-0012
- Project (
ZDB) — which project the document belongs to. - Author (
PCM) — which company produced it. - Zone (
B1) — which building or part of the site. - Level (
00) — which floor, orZZif the document covers the whole thing. - Type (
DR) — the kind of document, e.g. a drawing. - Discipline (
A) — the discipline, here architecture. - Number (
0012) — a sequence number within that combination of fields.
Revision (e.g. P03) and status live alongside the name, not inside it — they’re separate data, not another suffix bolted onto the filename.
Why it matters on site
A naming convention isn’t formality for its own sake. When a name is predictable, anyone — architect, structural engineer, site manager — can tell what a document is without opening it. You can also tell apart two files that differ in only one field, instead of guessing from a suffix which one is current. It’s also the foundation that makes revisions and statuses (WIP, Shared, Published, Archived) meaningful in the first place — without a stable name, you can’t track one document’s history over time.
How this works in DocuBIM
In DocuBIM you build a document’s name from your project’s convention fields instead of typing it by hand — the system fills in the author and the next number itself. You can’t accidentally create two documents with the same name, or save a file with “final” tacked on. The convention is set once, at the start of the project, and applies to every team working in the shared data environment.