ISO 19650 naming: what actually applies to DWG blocks

Where the confusion usually starts

ISO 19650 gets referenced constantly on BIM projects, and it's genuinely common for that reference to get applied a bit too literally to things it was never really written to govern, individual DWG blocks being one of them. The standard's naming convention, the long structured string covering project, originator, volume, level, type, role, number, classification, was designed for information containers, sheets, models, documents, not for a single reusable piece of geometry like a door block or a north arrow symbol sitting inside a shared library.

I get asked fairly often whether a downloaded block needs a full ISO 19650 compliant file name before it can be used on a compliant project, and the honest answer is almost always no, not the individual block itself, though the drawing or model it ends up inside absolutely does need to follow that convention once it becomes a project deliverable.

What the standard actually governs versus what it doesn't

ISO 19650 is fundamentally about information management at the container level, who's responsible for producing what, when it's shared, what status it carries, and how it's named so it can be tracked through that process. A block sitting inside a shared library, an iron gate, an arrow, a workstation footprint, isn't itself an information container in that sense, it's raw content that gets inserted into containers, the drawing sheet, the model file, that are what actually get named and tracked under the standard.

This distinction matters practically, because trying to apply full ISO 19650 naming to every individual block in a library produces an unmanageable mess, you'd be renaming a two seater workstation block differently for every single project it ever gets used on, which defeats the entire purpose of having a reusable library in the first place.

What genuinely does carry over from the standard

A few principles from ISO 19650 are worth applying to block library management even though the literal naming string doesn't fit, specifically the emphasis on a single source of truth, clear ownership, and status tracking. Your office's block library should have one authoritative, current version of each recurring block, a named party responsible for maintaining it, and some way of signaling whether a given block has been checked and approved versus still under review, which mirrors the standard's work in progress, shared, published logic even without using its exact naming string.

Classification is the other piece that genuinely does transfer, once a block is used inside a BIM deliverable, it should carry an appropriate classification code, Uniclass being the system most commonly paired with ISO 19650 on UK projects, so the object is identifiable within structured data exchange regardless of what its source block file happened to be named.

Where the naming convention does apply directly

The moment a block gets inserted into an actual project deliverable, a floor plan sheet, a furniture layout drawing, that container does need to follow whatever naming convention the project's BIM execution plan specifies, typically the full ISO 19650 structured string if the project is formally compliant. So a drawing sheet showing a coordinated furniture layout built from downloaded workstation and conference table blocks needs a proper compliant file name, even though the individual blocks that populate it never did.

This is the practical line to draw, source library content stays under your office's own simpler standard, project deliverables that content ends up inside follow the project's formal ISO 19650 convention, and confusing the two is where a lot of unnecessary renaming effort gets wasted on content that never needed it.

A realistic setup that satisfies both without overcomplicating things

In practice this looks like two parallel systems that meet at the point of insertion. Your office block library keeps simple, descriptive internal naming, easy for anyone to find and understand at a glance. Every project deliverable file that uses that content follows the project's ISO 19650 convention as normal, with no expectation that the block's own filename traveled along with it in any formal sense.

The bridge between the two is documentation, not naming, a short note in your office CAD standard explaining that library content is exempt from full ISO 19650 naming but everything built from it isn't, which heads off exactly the kind of confused question that otherwise eats up time in a coordination meeting nobody wanted to spend on file naming philosophy.

A quick reference on what needs full naming and what doesn't

A simple way to keep this straight without re-litigating it on every project:

- Individual library blocks, doors, windows, furniture, symbols: simple internal naming, not full ISO 19650 strings - Drawing sheets and models built using that content: full project naming convention if the project is ISO 19650 compliant - Classification codes, Uniclass or equivalent: applied once content enters a BIM deliverable, not at the raw block stage - Status tracking, work in progress, shared, published: worth applying informally to library management even without the exact terminology

At the end of the day the standard exists to make information traceable and trustworthy across a whole project team, and applying its full weight to a reusable door block does nothing to serve that goal, it just adds friction to a workflow that was never the standard's actual target.

A short example of what happens when the line gets blurred

I worked with a team once where a well meaning coordinator decided, reasonably enough on its face, that consistency meant applying the full project naming convention to every file touching the project, including the office's internal block library. The result was a library where a simple door block ended up with a naming string over sixty characters long, encoding project codes and revision markers for a piece of content that gets reused identically across dozens of unrelated projects and was never going to carry project specific information in the first place.

Within a few months, nobody could find anything in the library without opening files individually to check what was actually inside, because the descriptive part of what used to be a simple name like DOOR_SINGLE_900 was now buried behind a long compliance string that told you everything except what the block actually was. Rolling that back to a simple internal naming convention for library content, while keeping full compliant naming for actual project deliverables, took about a day of renaming but immediately made the library usable again. The lesson wasn't that ISO 19650 naming is bad, it's an excellent standard for what it was built to govern, the lesson was that applying it somewhere it wasn't designed to apply just adds friction without adding any of the traceability benefit it's meant to provide.