Information Delivery Specification: requisitos que una máquina puede comprobar
El requisito ocupaba una línea del BEP: «Los equipos deberán contener la información necesaria para mantenimiento». Nadie podía estar en desacuerdo y nadie podía comprobarlo de la misma manera. Instalaciones entregó fabricante y modelo; explotación esperaba código, ubicación, garantía y sistema; coordinación revisó una muestra y encontró valores en tres conjuntos de propiedades. La frase era correcta como intención y bastante inútil como prueba.
Information Delivery Specification, o IDS, permite expresar requisitos alfanuméricos de información de forma legible para personas e interpretable por software sobre modelos IFC. Su valor no está en transformar cualquier petición en XML, sino en obligarnos a declarar a qué objetos aplica, qué información esperamos y qué condiciones consideramos válidas. La máquina ejecuta esa definición; no la inventa.
Tabla de contenidos
El equipo empezó traduciendo «información necesaria»
Explotación eligió un caso pequeño: unidades de climatización destinadas a mantenimiento. Para cada una necesitaba identificador de activo, fabricante, modelo y pertenencia a un sistema. Algunas propiedades eran obligatorias en la entrega final; otras solo cuando el equipo ya estaba seleccionado.
La aplicabilidad se definió con entidades y clasificaciones acordadas. No bastaba con buscar cualquier objeto cuyo nombre incluyese «climatizador». El requisito debía reconocer los elementos a través de información estable en el IFC.
Los responsables prepararon ejemplos. Un equipo genérico en fase de diseño podía quedar fuera de la regla final. Una unidad instalada sin código debía fallar. Un fabricante vacío no era igual que una propiedad ausente. Esta conversación hizo más por la calidad que añadir otra página de recomendaciones.
La especificación separó aplicabilidad y requisito
En IDS, una parte determina qué objetos entran en la comprobación; otra describe qué deben cumplir. Esa separación evitó una confusión frecuente: marcar como error todos los elementos que no tienen una propiedad, aunque nunca debieran tenerla.
La aplicabilidad podía utilizar facetas como entidad, clasificación, propiedad, material o relación, dentro del alcance soportado. Para las unidades se combinó entidad y clasificación. Después, los requisitos exigían propiedades y relaciones concretas.
El equipo mantuvo nombres comprensibles y descripciones que explicaban intención. El archivo debía poder revisarse sin descifrar únicamente etiquetas técnicas. Que una máquina lo lea no excusa escribirlo como una amenaza.
La primera regla mostró la diferencia entre presencia y valor
Exigir que exista la propiedad Fabricante no garantizaba que estuviese informada. El requisito debía especificar cardinalidad y, cuando correspondía, restricciones sobre el valor. Para códigos se definió un patrón; para sistemas, una relación esperada.
No todas las propiedades tenían un catálogo cerrado. El nombre comercial podía aceptar texto no vacío. El código de estado sí utilizaba valores controlados. Intentar convertir cada campo en enumeración habría creado mantenimiento innecesario.
Las unidades y tipos de dato también importaban. Comparar números sin conocer unidad puede producir resultados convincentes y equivocados. El equipo alineó los requisitos con cómo llegaba la información en IFC y probó exportaciones reales.
El XML fue el formato, no el lugar de la decisión
La especificación podía editarse mediante una herramienta compatible o generarse desde un flujo controlado. El XML resultante contenía metadatos, especificaciones, aplicabilidad y requisitos. El equipo no editaba etiquetas a ciegas como proceso habitual; revisaba una representación comprensible y validaba el archivo contra su esquema.
El control de versiones conservaba cambios y responsable. Modificar una propiedad o un valor permitido podía alterar cientos de resultados. Por eso el IDS tenía el mismo cuidado que otros artefactos de requisitos.
Los comentarios del BEP no desaparecieron. La explicación humana seguía describiendo propósito y responsabilidad; el IDS formalizaba la parte comprobable. El documento y la regla se referenciaban para no evolucionar por separado.
La validación se ejecutó sobre el IFC entregado
El modelo de autor podía mostrar todos los parámetros y aun perderlos al exportar. El validador recibió el IFC final, aplicó las especificaciones y produjo resultados por objeto y requisito.
Cada fallo necesitaba contexto: identificador, entidad, propiedad o relación, valor encontrado y condición. Un porcentaje global ayudaba a resumir, pero no a corregir. El informe permitía volver al modelo de origen y revisar mapeo o datos.
Después de corregir, se exportaba y validaba de nuevo. IDS comprobaba el artefacto de intercambio, no la buena intención del archivo nativo.
Un requisito que no seleccionaba nada no aprobaba el modelo
En una prueba, la clasificación de las unidades no coincidía con la aplicabilidad. La especificación evaluó cero objetos. Un sistema ingenuo podía mostrar cero fallos y provocar una celebración corta.
El flujo añadió comprobaciones sobre el número de elementos aplicables. Si se esperaban unidades y no aparecía ninguna, el resultado era una alerta de cobertura. También se mantenían IFC mínimos con objetos conocidos para probar la especificación.
La ausencia de candidatos podía indicar que el proyecto no tenía esos equipos o que la regla estaba mal conectada con el modelo. La máquina no conocía cuál de las dos historias era cierta; coordinación debía investigarlo.
IDS comprobó información, no diseño geométrico completo
El estándar se centra en requisitos de información que pueden expresarse mediante sus facetas y restricciones. No sustituye una comprobación geométrica completa de distancias, recorridos o interferencias. Tampoco interpreta por sí solo la normativa.
Podía exigir que una puerta tuviese una prestación o clasificación. Decidir si esa prestación era suficiente para su posición podía requerir sectorización, uso y una regla externa más compleja. IDS aportaba una pieza de evidencia.
Esta limitación era saludable. Evitaba prometer un único archivo que validase el edificio entero. Geometría, información e intención necesitan herramientas y responsabilidades distintas.
IFC y bSDD ocuparon papeles complementarios
IFC transportaba objetos, propiedades y relaciones. IDS declaraba qué parte debía estar presente y bajo qué condiciones. bSDD podía aportar vocabularios y referencias compartidas para clasificaciones y propiedades cuando el flujo lo utilizaba.
Conectar un diccionario no garantizaba que todos los modelos aplicasen los términos correctamente. El equipo debía acordar versiones y mapeos. Las referencias externas también necesitaban mantenimiento.
La combinación reducía ambigüedad cuando se gobernaba bien. Sin esa gobernanza, podía añadir tres identificadores distintos a una propiedad que seguía sin estar informada.
La versión oficial importó más que el número más alto
El equipo utilizó una versión estable y soportada por sus herramientas, comprobando documentación y esquema. No adoptó una beta solo porque su numeración pareciese posterior. Productores y validadores debían interpretar la misma especificación.
Las pruebas de interoperabilidad formaron parte del despliegue. Un IDS creado en una herramienta se validaba en el flujo receptor con modelos conocidos. Las diferencias se documentaban antes de bloquear entregas.
Actualizar requería revisar cambios del estándar y compatibilidad. El archivo seguía siendo texto, pero su semántica dependía de una versión. XML no inmuniza contra el tiempo; solo envejece con una expresión muy seria.
El flujo de aprobación impidió que cualquiera cambiase las reglas
Los autores de requisitos proponían cambios. Coordinación revisaba aplicabilidad y resultados. El responsable de información aprobaba la versión usada como gate. Los equipos recibían la especificación y ejemplos antes de la entrega.
Durante una fase de transición, algunas condiciones generaban advertencias. Cuando se demostraba que datos, exportadores y validadores respondían de forma consistente, pasaban a bloqueo. Este periodo evitaba estrenar requisitos críticos el día de publicar.
Las excepciones se documentaban fuera del IDS con alcance y aprobación. Modificar la regla general para aceptar un caso particular habría debilitado todas las entregas.
Los errores mejoraron la especificación
Varios fallos iniciales eran falsos positivos: equipos provisionales entraban en una regla de activos definitivos. Se afinó aplicabilidad. Otros revelaron propiedades duplicadas en distintos conjuntos. El equipo eligió una ubicación canónica.
También aparecieron falsos negativos. Un patrón de código permitía cadenas técnicamente válidas pero inexistentes en el registro de activos. IDS comprobaba formato; otra integración debía comprobar existencia. El informe dejó clara la diferencia.
Las métricas incluían objetos aplicables, fallos por requisito, no evaluables y excepciones. El objetivo no era alcanzar cien por cien a cualquier precio, sino mejorar datos y detectar reglas mal formuladas.
Cuándo otra solución resulta más adecuada
Para una comprobación puntual y pequeña, una revisión manual o una consulta puede ser suficiente. Para lógica geométrica, cálculos complejos o cruces con sistemas externos, Python u otra herramienta puede complementar el IDS.
Si el requisito cambia cada semana o nadie puede explicarlo con ejemplos, conviene estabilizarlo antes. Formalizar demasiado pronto puede dar autoridad técnica a una decisión inmadura.
IDS aporta más cuando los requisitos se repiten, se intercambian entre organizaciones y necesitan trazabilidad. No elimina el coste de redactar, probar y mantener. Lo hace visible y reutilizable.
La máquina comprobó una promesa que las personas habían aclarado
La siguiente entrega del proyecto incluía unidades identificadas, propiedades en ubicaciones acordadas y relaciones con sistemas. Los fallos restantes se devolvieron con evidencia. Explotación podía revisar qué recibiría sin muestrear a ciegas.
Information Delivery Specification funciona bien cuando conecta una intención humana con una prueba limitada y explícita. Define aplicabilidad, requisitos y valores; prueba cobertura; valida el IFC final; y conserva versión y responsabilidad.
Si el requisito sigue diciendo «información necesaria», todavía no necesitas abrir un editor IDS. Necesitas una conversación. La buena noticia es que, después, el XML será bastante menos misterioso que la frase original.
Respuestas