Say it plainly, because it saves a lot of wasted effort: ISO-19650-2 names information containers, not objects inside them.

A container is a file:

• A model.
• A drawing.
• A schedule.

The well-known field string

[Project]-[Originator]-[Volume]-[Level]-[Type]-[Role]-[Number] names 'that'.

It's explained fully here:

https://bimcopilot.com/blog/iso-19650-made-simple-bim-2026

'No one ever explained it better 😉'.

A Revit family is not a container in that sense. It's a piece of library content that lives inside your models and your library. ISO-19650 sets the principles. Structured-Field-based-Self-describing-Classified. But the convention for naming the object itself comes from its companion standards.

There are three that matter in 2026, and a practice should know which does what.

ISO-19650 is the umbrella.

These three are how you name and classify the things underneath it.

Here’s the system:

• Family Name carries identity.
• Type Name carries variation.

Family Name Formula

[Category]_[Function]_[Descriptor]_[Host/Placement]_[Manufacturer/Std]

(last segment optional)

Examples

• Door_Single_SolidCore_WallHosted_Generic
• Window_Fixed_ThermalBreak_WallHosted_Generic
• Casework_BaseCabinet_2Door_FloorBased_Generic
• Furniture_Desk_Workstation_Freestanding_Generic



Why this works

• Category-first improves search and browser grouping
• Function and descriptor make it usable across teams
• Host/placement reduces wrong placement errors
• Manufacturer is optional (use only when it truly matters)

Two changes catch practices out. Both are about building on something that isn't current.

BS 8541 is gone. For a decade, UK object naming pointed at BS-8541.

The library object standard, in several parts. As of May 2024 it was superseded by BS EN ISO-22014:2024, which is identical to ISO-22014:2024 and consolidates the old multi-part British standard into one international standard.

If your practice template still cites BS-8541, it cites a withdrawn document. The naming logic carried over, but the reference changed.

ISO-22014 keeps the field idea: a library object is named from Source, Type and Subtype, separated by underscores, with the Type and Subtype drawn from IFC (BS EN ISO 16739-1). So `NBL_LightFixture_CeilingPendant` reads as 'source NBL, an IfcLightFixture, ceiling-pendant subtype'.

Searchable by source, by type, or down to the exact object.

I know this gets confusing. But stay with me.

The NBS BIM Object Standard is still alive, and more granular. NBS keeps its own object standard, now at v2.2 (July 2023), and every object in the NBS National BIM Library within NBS Source is certified against it. Its file-and-object name carries five fields:

```

[Role]_[Source]_[Type]_[Subtype/ProductCode]_[Differentiator]

```

• Role - the discipline that owns the object (A, S, M, E…)
• Source - the manufacturer, or your library code for generic content
• Type - the primary object category, IFC-based
• Subtype / Product Code - the variant, or the manufacturer's product code
• Differentiator - distinguishing dimensional information, with its unit of measure

Classify with Uniclass 2015:

• Naming tells a human what the object is.
• Classification tells a 'machine'.
• Uniclass 2015 is the UK classification system.

Twelve tables, maintained by NBS, updated every quarter.

For families you mostly use the Products table (Pr) and the Systems table (Ss). The code rides on the family as a parameter, not in the name. It's what lets software join your family to a specification or a cost plan.

A practice should pick a lane and write it into the BEP:

ISO-22014 as the international baseline, the NBS standard where you want manufacturer-grade rigour, Uniclass on everything. Then never deviate.

Type names are where most teams get chaotic:

sizes, materials, ratings, and options get mixed randomly.

Type Name Formula

[Size]_[Material/Finish]_[Performance]_[Option]

Keep it consistent, and don’t include what you can schedule from parameters.

Examples

• Door Type: 0900x2100_PaintGrade_FD60_Acoustic
• Window Type: 1500x1200_Alu_Thermal_UValue1p4
• Furniture Type: 1600x800_Laminate_CableTray_YES

Pro tip: if a parameter already exists (e.g., Fire Rating), don’t duplicate it in the name unless your team depends on name-based search. Duplicate data increases drift.

If you have many types, consider a Type Catalog workflow so the same family can be loaded with consistent type definitions. Autodesk specifically documents type catalogs as a method for managing families with many types. 

Before any field syntax, the alphabet. These rules are the same across ISO-22014, the NBS standard and ISO-19650, and they exist so software never trips over a name.

• Letters (A–Z), numbers (0–9), the hyphen (-) and the underscore (_) only. Nothing else.
• The underscore separates fields. It's the delimiter the machine tokenises on.
• The hyphen separates words inside a field — or use CamelCase. `InternalSingle`, not `Internal Single`.
• No spaces. Ever. A space is the single most common reason a script or schedule breaks.
• No special characters — no `&`, `/`, `@`, `#`, `(`, `)`, `.` except before the file extension.
• The name must be self-describing — It should make sense on its own, without the folder it sits in.
• Keep it sensible in length — and front-load the meaning, so a truncated name still reads.

A name that obeys these is one a person can read and a machine can parse.

A name that breaks them is a bug in the code.

Most teams name the family file and stop.

That's one of three layers, and the other two are where the data actually lives.

• Layer 1 - the family file name (`.rfa`). The object standard field string. This is what you see in the library and the Project Browser. It identifies the family.
• Layer 2 - the type name (inside the family). The variant: size, fire rating, finish, option. One family holds many types, and each type needs to decode on its own.
• Layer 3 - the category, subcategory and parameters. The Revit category that drives schedules and IFC export, the subcategories that control graphics, and the parameters, including the Uniclass classification, that turn the name into structured data.

Get all three right and a family is legible top to bottom: a human reads the name, a scheduler reads the type, a machine reads the data. Get only the first and you've labelled a box without saying what's inside it.

The next three sections take each layer in turn, threading one imaginary family. An internal doorset, through all of them.

Use the NBS five-field string as the working convention.

It's the most complete, and it collapses to the ISO-22014 three-field version when you need it.

```

[Role]_[Source]_[Type]_[Subtype]_[Differentiator]

```

Role - the discipline that owns the object.

Keep these consistent with your ISO-19650 role codes so the whole project speaks one language:

Source - where it came from. A manufacturer name for product content (`Lumora`, `Geberit`), or your practice library code for generic content (`BIMCP`). Pick one code per source and never spell it two ways.

Type - the kind of object, taken from IFC. `Door`, `Doorset`, `Luminaire`, `Window`, `Wall`. This is the field that lets someone pull every object of a type in one query.

Subtype - the variant that the Type alone doesn't capture. `InternalSingle`, `RecessedLED`, `CavitySliding`. CamelCase, no spaces.

Differentiator - distinguishing dimensional or descriptive information 'with its unit', where the family needs it at file level. Often you leave this off the file name and let the types carry size. One family, many sizes. This keeps the library tidy.

Worked example - an architect's internal doorset:

```

A_BIMCP_Doorset_InternalSingle.rfa

```

Decoded:

• Role [A] - architecture-authored.
• Source [BIMCP] - from the BIMcopilot library.
• Type [Doorset] - an IfcDoor - type doorset.
• Subtype [InternalSingle] - single-leaf internal subtype.

The ISO-22014 three-field form of the same object drops the role and the library prefix:

```

BIMCP_Doorset_InternalSingleLeaf

```

One family file. Sizes come next, as types.

Not as twelve near-identical files.

Inside that one doorset family sit every size and fire rating you offer.

Each is a type, and a type name has to decode on its own, because it's what lands in a door schedule.

A reliable pattern is descriptive fields, fixed order, zero-padded numbers:

```

Type_Subtype_WidthxHeight_Variant

```

Worked example — types inside `A_BIMCP_Doorset_InternalSingle`:

Three working rules for type names:

• Zero-pad numbers (`0826`, not `826`) so they sort correctly in every schedule and script.
• Fix the dimension order and write it into the BEP - width × height for openings, width × depth × height for objects. Use `Width` for left–right, `Depth` for front–back, `Height` for the Z. Reserve `Length` for line-based families.
• Encode options you can decode — `FD30`, `FD60`, finish codes, hardware sets. In a fixed position, so a schedule or a script can read the variant straight off the type.

For families with a large size matrix — frames, structural sections, fixings — drive the types from a type catalogue (a `.txt` file alongside the `.rfa`) rather than loading hundreds of types into every model. It loads faster, keeps the file light, and stops one-off types breeding inside projects.

The name identifies the family. The category, subcategory and parameters are what make it behave and what make it data.

• Category — get this right first, because it drives everything downstream. A doorset belongs in the Doors category, a light fitting in Lighting Fixtures. The category determines how the family schedules, how it tags, and which IFC class it exports as (`IfcDoor`, `IfcLightFixture`). A family modelled in the wrong category. A door built as generic model, is invisible to the schedule that needs it and exports as the wrong thing. No name can rescue a miscategorised family.

• Subcategory — the layer below, for graphics. Name subcategories consistently so visibility and line weights stay predictable across the library: `Panel`, `Frame`, `Glass`, `Ironmongery` inside a door; `Elevation Swing` for the 2D. Consistent subcategory names mean a view template controls the whole library at once.

• Parameters — where the name becomes structured data. Name shared parameters from a single practice register, in a fixed style, and reuse the same parameter across families so a schedule built once works everywhere. For the doorset:

A note from the NBS standard worth copying: suffix material parameters with `_mtrl` so every material reads consistently and a script can find them. Small rule, large payoff at audit time.

That `Classification_Uniclass_Pr` value is the quiet hero. `Pr_30_59_24` is a globally consistent code for 'doorset'. With it on the family, software can join your door to its specification clause, its cost line and its embodied-carbon figure — without anyone reading the name at all. That's the line between a label and data.

Naming reads best as a finished thing. Here are two imaginary families, named through all three layers — one architectural, one a manufacturer product.

Family A — Internal single doorset (architecture, library content)

Family B — Recessed LED panel luminaire (electrical, manufacturer product)

Read either table top to bottom and there's nothing left to ask. The file says what and who. The types say which size and which variant. The category and classification say how it behaves and how a machine should treat it. That is a family named to standard. It took no longer than naming it badly would have.

Here's the part that changed.

Naming used to be about helping the next human find the file. It's now about whether software can use your library at all.

A name is only data if it's structured. `Door1_FINAL` carries nothing a machine can act on. It's a string a person has to interpret. `A_BIMCP_Doorset_InternalSingle` carries meaning in fixed positions. A script tokenises on the underscore and reads four facts: discipline `A`, source `BIMCP`, type `Doorset`, subtype `InternalSingle`. No file opened. No human asked.

That single property. Predictability, is what every layer of automation is built on:

• Scripts and add-ins read patterns. A pyRevit or Dynamo routine can audit every family name against the register, flag the ones that break it, and rename in bulk. It can only do that if there's a pattern to check against.
• Schedules write themselves from decodable types. When `0926x2040_FD30` decodes the same way every time, a door schedule is parsed, not typed. The same logic finds every `FD30` in the model for a fire-strategy check.
• Classification joins your model to everything else. The Uniclass code on the family is a key. Software uses it to link the family to its specification, its cost, its carbon. The joins that make a model worth more than its geometry.
• AI agents act on structure, not soup. An agent asked to 'list every recessed luminaire below 4000K and check its emergency variant' can do it when families read as `E_*_Luminaire_RecessedLED` with a `Colour_Temperature` parameter. Faced with `light`, `light2` and `copy of light`, it guesses, and a guess in a model is a defect.

The rule underneath all of it: AI amplifies whatever order or disorder it finds. A consistent, classified library is training-grade, query-ready data. The model grounds itself in facts.

An inconsistent one is noise the model has to reason through, and it reasons wrong. Naming is no longer housekeeping you do when there's time. It's the data-preparation step that decides whether automation helps you or hallucinates at you. We go deeper on the scripting side in the:

pyRevit field manual - https://bimcopilot.com/blog/pyrevit-automation-where-to-start.

A convention that lives in a PDF and dies in practice is worth nothing.

The naming holds only if the library around it is organised to protect it.

• Folder structure mirrors the name. Group the library by discipline and type, the same fields the names start with. Finding `A_*_Doorset_*` should be a matter of walking two folders, not searching.
• One register, one source of truth. Role codes, source codes, type abbreviations, parameter names and Uniclass mappings live in a single document. Referenced by the BEP, not reinvented per project.
• One gatekeeper for new content. Every family entering the library passes one check against the register before it's published. Manufacturer downloads get renamed and reclassified on the way in. Never trusted as delivered.
• No duplicates, ever. Two families that do the same job, named two ways, is how a library rots. One job, one family, many types.
• Version the library, not the file name. Revisions belong in your CDE and metadata, not bolted onto the family name as `_v2_FINAL`. The name describes the object; the system tracks the version.

A library organised this way compounds. Every project draws from clean content and returns clean content. A library left to organise itself decays into the junk drawer you opened this manual to escape.

The mistakes are predictable, which means they're preventable.

• Spaces and special characters. The number-one cause of broken schedules and failed scripts. Strip them on sight.
• Manufacturer names left as delivered.`LD-2247-X-REV3` means nothing in your model. Rename to the register on import.
• Type names that don't decode.`Type 1`, `Type 2`, `Standard` tell a schedule nothing. Encode the size and the variant.
• Wrong category. A door built as a generic model can't be scheduled or exported as a door. Category first, always.
• No classification. A family with no Uniclass code, is invisible to every downstream tool that joins on it.
• One mega-family doing everything. Sensible families with clear types beat a single monster with sixty parameters nobody maintains.
• Revisions in the name.`_FINAL_v3` is version control by superstition. Let the CDE track versions.

Before a family enters the library or the model, run it against this:

• → File name follows the standard — role, source, type, subtype, all valid codes
• → Only letters, numbers, hyphens and underscores — no spaces, no specials
• → Correct Revit category, with subcategories named to the register
• → Every type name decodes — size zero-padded, variant encoded, order fixed
• → Uniclass classification present and correct
• → Shared parameters named from the register; materials suffixed `_mtrl`
• → IFC export class set and correct
• → No duplicate of something already in the library

If you can't tick every box, it isn't ready to publish.

Does ISO 19650 specify a Revit family naming convention?

No. ISO 19650-2 names information 'containers'. Your files. Family and object naming lives in its companion standards: BS EN ISO 22014:2024, the NBS BIM Object Standard, and Uniclass 2015 for classification. ISO-19650 sets the principles; those standards set the family convention.

BS 8541 or ISO 22014 — which do I follow?

ISO-22014. BS EN ISO 22014:2024 superseded BS 8541 in May 2024. If your template still cites BS 8541, update the reference — it points at a withdrawn standard.

What's the difference between the file name and the type name?

The file name identifies the family (`A_BIMCP_Doorset_InternalSingle`). The type name identifies the variant inside it (`Doorset_InternalSingle_0926x2040_FD30`). One family holds many types. Both must decode on their own.

Where does the Uniclass code go — in the name?

No. The classification rides on the family as a parameter, not in the name. The name is for humans; the code is for machines. Keep them in separate places doing separate jobs.

Should I rename families I download from manufacturers?

Yes. to your register, on the way into the library. A manufacturer part number is meaningful to the manufacturer and to no one else on your project. Rename, reclassify, then publish.

Do I still need the NBS BIM Object Standard if I follow ISO-22014?

They sit together. ISO-22014 is the international baseline. The NBS standard is more granular on parameters, geometry and presentation, and is the UK benchmark for certified content. Many practices follow ISO-22014 for structure and the NBS standard for object quality.

How exactly does good naming help AI?

A structured name is data a machine can parse without opening the file; a free-text name is a string it has to guess at. Consistent names and classification let scripts audit, schedule and swap families in bulk, and let AI agents query the library reliably. Inconsistent names force the tools to guess. A guess in a model is an error.

The Bimcopilot Family Naming Register

gives your practice the whole system in one place: role and source codes, the type-name syntax, the parameter register, Uniclass mappings, and a pre-load checklist your team can follow. One source of truth, referenced by your BEP, instead of a convention that lives in someone's head.

Prefer it built around your library?

The Bimcopilot Library Audit takes your existing families, renames and reclassifies them to standard, strips the duplicates, and hands back a clean, machine-readable library. Wired so the next download arrives named correctly and your automation has clean data to run on.

A library a machine can read is a library that works for you. Let's build yours.

→ Talk to BIMcopilot about your family library https://www.bimcopilot.com

• ISO-19650 Fully Explained: The 2026 BIM Information Management Guide - https://bimcopilot.com/blog/iso-19650-made-simple-bim-2026
• How to Write a BIM Execution Plan (BEP) That Doesn't Get Rejected — The 2026 ISO 19650 Guide - https://bimcopilot.com/blog/how-to-write-a-bep-that-doesnt-get-rejected
• How to Use pyRevit: The 2026 Field Manual for Architects and BIM Managers - https://bimcopilot.com/blog/pyrevit-automation-where-to-start