Nomenclatura de archivos según ISO 19650: lo que fija la norma y lo que decide el BEP

Qué es el identificador de un contenedor de información

Build Digital, la iniciativa irlandesa que explica la serie, define el contenedor de información como cualquier fichero único: información estructurada, como un modelo geométrico o una tabla, y no estructurada, como un PDF, un escaneado, una foto o un vídeo. Cada contenedor se identifica con un identificador único y con metadatos como el estado, la revisión y la clasificación.

Conviene separar desde el principio tres cosas que muchas convenciones mezclan:

El identificador no cambia durante la vida del contenedor. El estado y la revisión sí. Si el estado forma parte del nombre, cada cambio de estado crea en la práctica un fichero distinto, y el rastro de versiones se rompe.

Lo que fija la ISO 19650 y lo que no

La consecuencia práctica: si dos proyectos tuyos nombran los ficheros de forma distinta, no hay contradicción con la norma, hay dos BEP distintos. Y si un BEP dice «nomenclatura según ISO 19650» sin más, no ha declarado nada, porque la norma no trae esa lista. Es la misma idea que recoge la guía de la ISO 19650 para el BIM Manager.

El ejemplo del anexo nacional británico

El Reino Unido publica la parte 2 de la norma con un anexo nacional. BSI lo presenta como las recomendaciones propias del Reino Unido para la gestión de la información en los proyectos, no como parte del texto internacional. En 2021 lo revisó, y según su ficha los cambios fueron, entre otros: una tabla nueva que resume los códigos de campo del identificador del contenedor y su propósito, la retirada de las longitudes recomendadas de cada campo, el cambio de nombre de varios campos para hacerlos más claros, listas de códigos más breves y una lista simplificada de códigos de estado para el entorno común de datos.

El anexo es de pago. Según las explicaciones públicas de esa revisión, como la de Symetri de agosto de 2021, el orden de los campos pasó a ser este:

Antes de 2021 los campos eran proyecto, originador, volumen o sistema, nivel o ubicación, tipo, rol y número. Symetri explica el motivo del cambio: muchos ficheros acababan con «ZZ» o «XX» en los campos de volumen y de ubicación, para decir «varios» o «no aplica», y el número quedaba como único campo que los distinguía.

Irlanda tiene su propio anexo nacional, publicado por NSAI en febrero de 2021, que según NSAI contiene los parámetros técnicos irlandeses sobre la identificación de campos y los contenedores de información. Son dos países vecinos con dos anexos propios, y ninguno es el texto internacional. En España y en Latinoamérica, el anexo británico solo aplica si tu contrato o tu BEP lo adoptan.

Cómo se declara una convención de nombres en el BEP

Esta lista es criterio nuestro. Una convención está declarada cuando el BEP deja escrito:

1. Los campos y su orden, con el significado de cada uno.
2. El separador, un solo carácter que no pueda aparecer dentro de ningún código.
3. Para cada campo, una lista cerrada de códigos o un formato exacto: letras o dígitos, longitud y si van en mayúsculas. Lo habitual es todo en mayúsculas, pero un campo puede tener su propia regla si el BEP lo dice.
4. Qué se escribe cuando un campo no aplica o cubre varios valores, si el proyecto lo admite, y cuándo está permitido.
5. Quién mantiene cada lista, cómo se pide un código nuevo y qué versión de la lista está vigente.
6. Dónde van el estado y la revisión: en los metadatos del CDE o añadidos al nombre, con su formato y su lista.
7. A qué se aplica: a los ficheros, y si las vistas, los planos o los tipos de familia siguen otra convención, cuál.
8. Ejemplos válidos y no válidos, para que nadie tenga que interpretar.

Un ejemplo inventado, sin valor normativo

Lo que sigue es un ejemplo inventado para ver cómo se lee una convención ya declarada. Sus campos y sus códigos son de ejemplo: no salen de ninguna norma ni de ningún anexo, y no conviene copiarlos, porque tu proyecto tiene sus propios campos y sus propias listas. Separador: guion. Todo en mayúsculas. Estado y revisión, solo en los metadatos del CDE.

Con esa convención, HSP-BTR-Z01-P02-PL-ST-0004 se lee como el plano de estructura número 4 de la zona 1, planta 2, producido por la empresa BTR. Y estos nombres no son válidos:

• HSP-BTR-Z1-P02-PL-ST-0004: la zona lleva un dígito y el formato pide dos.
• HSP-BTR-Z01-P02-PL-ES-0004: «ES» no está en la lista de disciplinas.
• HSP-BTR-Z01-P02-PL-ST-0004-C01: lleva la revisión en el nombre y esta convención la deja en los metadatos.
• HSP_BTR_Z01_P02_PL_ST_0004: el separador no es el declarado.

Errores típicos al fijar la nomenclatura

• Copiar una convención sin adaptarla. Los campos que no tienen sentido en tu proyecto acaban rellenos con un código de relleno, y el nombre deja de distinguir nada. Según Symetri, ese abuso de «ZZ» y «XX» fue el motivo de cambiar los campos del anexo británico en 2021.
• Códigos sin lista cerrada. Si cada equipo escribe la estructura como «E», «EST» o «STR», ningún filtro ni ninguna búsqueda encuentra todos los ficheros de estructura.
• Mezclar revisión y estado. Son preguntas distintas: qué versión es y para qué se puede usar. En el mismo campo, nadie sabe si un cambio de código es una versión nueva o un cambio de estado.
• Meter en el nombre lo que es un metadato. Fechas, iniciales de quien lo editó, «final», «definitivo» o «v2 bueno» envejecen en cuanto el fichero cambia.
• Listas sin responsable. Si nadie mantiene la lista, cada equipo añade códigos por su cuenta y la lista deja de ser cerrada.
• «Según ISO 19650» como única declaración. No hay nada contra lo que comprobar.

Cómo se comprueba que un nombre sigue la convención

Una convención declarada se convierte en una regla escrita: un patrón con los campos y el separador, y para cada campo su lista de códigos o su formato, con la regla de mayúsculas. Con eso, cada nombre se contrasta de forma determinista: mismo nombre, misma regla, mismo resultado. Y el resultado dice qué campo falla, no solo que el nombre está mal.

Hay tres cosas que conviene tener claras:

• Lo que la regla no decide. Un plano de arquitectura nombrado con la disciplina «E» pasa el patrón sin problema. Que el código corresponda de verdad al contenido es criterio de quien revisa.
• Lo que no se puede comprobar. Si un campo no tiene lista ni formato declarados, lo honesto es decir que ese campo no se pudo comprobar. Ni aceptar cualquier valor ni aplicar una lista que el proyecto no declaró.
• Contra qué versión. Es criterio nuestro: contra la versión del BEP y de las listas vigente en la fecha del intercambio, o la que el control de cambios del BEP fije para ese hito. Un fichero se produce durante semanas, y «cuando se produjo» no dice cuál.

Es la primera capa de la lista de la guía de control de calidad del modelo BIM antes de compartirlo. Lo que el BEP tiene que dejar escrito para que se pueda hacer está en la guía del plan de ejecución BIM (BEP).

Qué hace OrionBIM aquí y qué no

Nuestro criterio es el de esta guía: la nomenclatura la declara el BEP de cada proyecto, ninguna se da por buena por defecto y la ISO 19650 no es una plantilla de nombres.

OrionBIM tiene una comprobación de los nombres de los elementos del modelo de Revit (vistas, láminas, niveles, grupos de trabajo y otros) contra los patrones que declara el BEP del proyecto; esta guía no la describe. Cómo comprueba OrionBIM el nombre de los archivos tampoco se describe aquí: esta guía explica cómo se comprueba un nombre en general.

Además, hace la comprobación normativa:

• Lee el modelo de Revit en vivo, con su propio complemento, y lo contrasta regla por regla con las reglas de la normativa del país donde se construye. Cada regla cita su fuente y el texto literal del que sale el umbral, y se comprueba que ese texto existe en la norma. Que el umbral coincida con él lo tiene que confirmar una persona, y a 1 de octubre de 2026 esa revisión de las reglas ya cargadas sigue en curso.
• Devuelve uno de cuatro resultados: OK, Revisar, Fuera de rango o No auditable. Los produce un evaluador determinista; ninguno lo decide una IA. Mientras esa revisión sigue en curso, OrionBIM muestra como «Revisar» todo resultado que el evaluador habría dado como OK o Fuera de rango.
• No rellena huecos. El resultado es «No auditable» cuando no hay una regla aprobada para ese país o esa norma, cuando el modelo no trae el dato que la regla necesita o cuando la comprobación no se pudo ejecutar. A 1 de octubre de 2026, OrionBIM solo tiene reglas de República Dominicana, y ninguna del nuevo Código de Construcción está aprobada.
• Exige firma humana para publicar: que exista el veredicto, que no sea «No auditable» y que lo firme una persona. No sustituye la autorización y la aceptación que fije el proyecto.

Si quieres ver cómo queda escrita una comprobación con su cita, puedes ver cómo emite OrionBIM un dictamen.

Fuentes

1. ISO 19650-2:2018 - Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 2: Delivery phase of the assetsOrganización Internacional de Normalización (ISO), consultada 2026-10-01
2. BS EN ISO 19650-2:2018 & Revised NABSI, consultada 2026-10-01
3. ISO 19650 File Naming UpdateSymetri (23 de agosto de 2021), consultada 2026-10-01
4. 'BIM' National Annex published and available to purchaseNational Standards Authority of Ireland (NSAI), 22 de febrero de 2021, consultada 2026-10-01
5. Information Container-Based Collaborative WorkingBuild Digital, consultada 2026-10-01