Naming Is Information Management: A Practical Tool for Structuring BIM Information from the Start

A project does not lose continuity only when a clash reaches the construction site or when a model no longer reflects what has been built. Continuity is also lost when a technical decision becomes trapped inside a file that nobody can identify with confidence.

FinalModel, FinalModelNew, CorrectedModel, FinalModelUseThisOne.

Names like these may appear harmless while the team is small and the author still remembers the file's history. Technical information, however, does not remain within one person's memory. It moves from engineering to modelling, coordination, construction, testing, commissioning and handover. Its identity, context and permitted use must survive every transition.

Naming a file is therefore not a minor administrative task. It is an initial information-management decision.

Disorder does not begin in the folder

When a team cannot identify the current file, the folder structure or platform often receives the blame. Yet an organised folder cannot correct an ambiguous information container.

A model may be stored in the correct location and still fail to answer basic questions:

• Which project and organisation does it belong to?
• Which building, system, section or level does it represent?
• Is it a model, drawing, report or technical specification?
• Which discipline is responsible for it?
• Can it be used for coordination, review or construction, or only as reference information?
• Which revision does it replace and how significant was the change?

Without agreed answers, teams rely on interpretation, messages and informal memory. The consequence is not merely documentary: people may review superseded information, duplicate work or construct decisions that have already changed.

The file name as an initial metadata layer

A structured name acts as an initial metadata layer. It does not replace the information managed within a Common Data Environment —CDE—, but it helps preserve context when a container is downloaded, shared or viewed outside its original platform.

The Manual de Nomenclatura de Documentos al utilizar BIM, published by buildingSMART Spain, proposes the following sequence:

Project–Originator–Volume/System–Level/Location–Type–Discipline–Number–Description–Status–Revision

The first seven fields are required within the proposal. Description is optional. Status and revision may be included in the name or managed as metadata where the CDE supports it.

| Field | Question it helps answer | | --- | --- | | Project | Which project, contract or appointment does it belong to? | | Originator | Which organisation produced the information? | | Volume or system | Which main subdivision of the asset does it represent? | | Level or location | Where is the information located? | | Type | What kind of information container is it? | | Discipline | Which technical domain does it belong to? | | Number | How is it distinguished from equivalent containers? | | Description | How can a person recognise it quickly? | | Status | For what purpose is it available? | | Revision | Which version does it replace and what level of change does it represent? |

The objective is not to create long file names. It is to establish consistent identifiers that are readable by people and processable by applications.

Document type is not file format

One important distinction is the difference between content and its technological format.

M3D may identify a three-dimensional model. .rvt, .ifc and .nwd identify formats in which that content may be produced or exchanged. The format can change while the nature of the container remains the same.

For this reason, the SORA generator keeps document type inside the identifier and treats the file extension as a separate value.

Status does not mean percentage complete

In an information-management process, status communicates the purpose for which a container may be used.

• S0: work in progress that must not yet be shared outside the task team.
• S1: information shared for coordination.
• S2: information shared for a specific activity.
• S3: information available for review and comment.
• S4: information submitted for review and authorisation by the lead appointed party.
• S5: information submitted for validation against the appointing party's requirements.
• AF: published information, where F represents the project-defined stage or milestone.
• AR: archived information that must not be modified.

Examples such as A1, A2 or A3 do not have a universal meaning. Each project must define its published-stage codes. The code alone does not create an approval workflow; it must be linked to responsibilities, reviews and decisions within the CDE.

Based on an ISO 19650-aligned proposal, not a universal naming standard

Precision matters. The ISO 19650 series establishes information-management principles and processes, but it does not prescribe this spreadsheet or a single global naming sequence.

The buildingSMART Spain manual provides a proposal aligned with those principles and primarily adapted to the Spanish market. It may be useful in other Spanish-speaking contexts, but project teams should assess its terminology and coding against local requirements.

The final convention must establish:

• the fields and their order;
• the consistent length of each field;
• the approved code lists;
• the meaning of published-stage codes;
• which values remain in the name and which are managed as metadata;
• who creates, reviews, authorises and changes each container;
• and how the convention connects to the information standard, EIR, BEP and CDE procedures.

A convention that is too complex may be ignored. One that is too simple may not provide enough control. Proportionality is part of sound governance.

Turning technical guidance into a usable tool

Based on these principles, we developed SORA NG – ISO 19650 Edition, a free Excel generator that turns the proposal into a guided, adaptable workflow. The current spreadsheet interface is in Spanish; an English interface has not been published yet.

Version 1.2 allows users to:

• configure project and originator codes;
• define volumes, systems, levels and locations;
• consult an initial selection of document types and disciplines;
• extend those lists according to project agreements;
• generate an identifier automatically;
• separate document type from file extension;
• preserve leading zeros in numbers and revisions;
• validate field lengths and prohibited characters;
• stop generation when invalid fields remain;
• flag names exceeding the manual's recommended 60 characters;
• and document the scope, sources and limitations of the adaptation.

One example produced by the tool is:

PRJ001-ORG-E01-P01-M3D-MIC-001-CoordinationModel-S0-0100.rvt

It may be read as a three-dimensional information-modelling container, created by ORG for PRJ001, covering building 1 and level 1, still at work-in-progress status and revision 0100.

The included catalogues are an initial operational selection. They do not reproduce the manual's annexes in full and do not replace the code lists agreed for a specific project.

What a naming convention cannot solve

The generator does not replace information requirements, the BIM Execution Plan, CDE permissions and workflows, technical review of the content, asset and system classification, multidisciplinary coordination or the contractual responsibilities of those producing, authorising and accepting information.

Its role is specific: reduce ambiguity at the source and make information easier to identify, search, filter and automate through consistent rules.

One component of SORA's technical continuity

SORA does not treat BIM as an isolated modelling service or as the end point of a model. Our current specialisation integrates Electrical Engineering, BMS/BAS/EPMS, BIM and Information Management to maintain continuity across:

Engineering → Information → Coordination → Construction → Commissioning → Handover

Within that sequence, naming has a specific function: maintaining the identity and traceability of the containers carrying technical decisions.

An electrical feeder may change during coordination. A BMS point may be revised during submittals. Equipment may be relocated in the field. Updating geometry is not enough; the context, status, revision and correspondence between engineering, models, construction information and closeout documentation must also be preserved.

This tool does not represent SORA's entire technical-continuity system. It demonstrates one of the principles supporting it: information must remain recognisable, verifiable and fit for its intended use throughout the project lifecycle.

Naming does not solve all information governance. It does, however, prevent continuity from depending solely on the person who still remembers where the file was saved.

References

• buildingSMART Spain, Manual de Nomenclatura de Documentos al utilizar BIM.
• buildingSMART Spain, ISO 19650 series resources.
• ISO, ISO 19650-4:2022 — Information exchange.