Meu EIR virou papel morto: como saber se o modelo entregue está em conformidade?

O contratante escreve um EIR de 40 páginas — matriz de responsabilidades, tabela de propriedades por objeto, marcos de entrega, critérios de aceitação. O projetista assina o contrato e começa a modelar. Três meses depois entrega o primeiro marco: um IFC. O gestor da informação abre o modelo, olha, dá scroll. A única forma de saber se o requisito foi cumprido é abrir objeto por objeto no viewer e comparar com o Word.

Ninguém faz isso. Se a matriz do EIR pede FireResistance em todas as paredes com função corta-fogo, o gestor pega uma amostra de cinco paredes, confere no Solibri ou no BIMcollab, e assume que o resto está certo. Se falta a propriedade em 30% das paredes, ele descobre um ano depois quando o coordenador de instalações tenta rodar uma consulta pra o laudo de acessibilidade e o resultado vem incompleto.

Esse cenário tem um nome técnico: EIR não-executável. Requisitos escritos em linguagem natural, prosa contratual, sem representação computacional que permita a máquina responder "isso está conforme? sim ou não". O modelo pode ter tudo. O modelo pode não ter nada. Não há como saber sem inspeção manual — e inspeção manual em modelo federado com milhares de objetos é matematicamente inviável.

Existe uma resposta canônica pra esse problema desde junho de 2024, quando a buildingSMART publicou como padrão oficial o IDS 1.0 — Information Delivery Specification. IDS é o formato de arquivo (.ids) que traduz o EIR contratual em regras verificáveis executáveis por rule engine sobre o IFC. Cada exigência do EIR — cada propriedade, cada classificação, cada material, cada relacionamento entre objetos — vira uma specification no IDS. Cada specification tem duas partes: applicability (a quais objetos a regra se aplica) e requirements (o que esses objetos devem satisfazer).

O IDS não substitui o EIR. Ele o executa. O EIR continua sendo o documento contratual em linguagem natural, escrito pra ser lido por humanos — advogado, sponsor, cliente final. O IDS é a mesma exigência escrita em XML normativo, compilada contra o schema XSD oficial (Schema/ids.xsd no repositório buildingSMART/IDS), pra ser executada por qualquer software que implemente o padrão. Quando o projetista entrega o IFC, o gestor da informação roda o IDS contra o modelo e recebe um relatório: quantos objetos passaram, quantos falharam, em quais propriedades exatas cada objeto falhou. Verificação automatizada, exaustiva (não amostral), rastreável, replicável.

1. 1

   Reuniões de review de entrega BIM que duram horas e terminam em 'acho que tá certo' sem métrica objetiva

2. 2

   Checklists de aceitação preenchidos em amostra ('confirmei em cinco paredes, presumo que as outras estão iguais')

3. 3

   EIR e BEP citam propriedades exigidas mas não indicam Property Set exato nem tipo de dado — 'a parede deve ter resistência ao fogo' sem dizer nome do Pset, nem se é IfcText, IfcLabel, IfcTimeMeasure ou enum

4. 4

   Disputas contratuais que dependem de 'abrir o modelo pra provar' o que foi ou não foi entregue

5. 5

   Coordenador de instalações descobre no meio do projeto que o modelo estrutural não tem uma propriedade que era pré-requisito da análise dele — e essa propriedade estava no EIR desde o começo

6. 6

   Cliente final pede uma consulta simples ('todas as portas corta-fogo com resistência ≥ 60 min') e o resultado vem com metade dos objetos sem propriedade preenchida

7. 7

   Quando o gestor tenta verificar cumprimento do EIR, ele exporta lista de objetos pra Excel, faz VLOOKUP manual, e demora dois dias por marco de entrega

8. 8

   Ninguém no time consegue explicar em uma frase o que exatamente foi verificado antes da última entrega ser aceita — 'a gente conferiu, ficou ok'

Causa 1 · EIR redigido em linguagem contratual, não em linguagem computacional. Advogado escreve pra outro advogado. "O modelo deve conter as propriedades necessárias à análise de desempenho térmico" é uma frase válida em um contrato. É inexecutável como regra de verificação. Nem o nome exato do Pset está definido, nem os elementos aos quais a regra se aplica, nem os valores mínimos aceitáveis, nem o que acontece se uma propriedade for texto livre vs. enumeração fechada. O EIR fica no plano do desejo. A entrega fica no plano da conveniência.

Causa 2 · Ausência de tradução formal EIR → IDS. Mesmo quando o EIR é razoavelmente específico, ninguém faz a tradução pra o formato verificável. IDS 1.0 existe desde junho de 2024. O tooling existe (IDS-Audit-tool oficial da buildingSMART em C# .NET, BlenderBIM, IfcOpenShell, Solibri, ACCA usBIM.IDS, entre outros). Mas a etapa de autoria do arquivo .ids é frequentemente pulada — ou delegada a quem não tem competência técnica de mapear requisito contratual em faceta IDS.

Causa 3 · Verificação tratada como fase final, não como controle contínuo. O IDS é lido como "coisa que a gente roda antes da entrega final", quando na verdade é ferramenta de controle de qualidade contínuo. O projetista deveria rodar o IDS contra o próprio modelo antes de qualquer submissão pro CDE. O gestor da informação deveria rodar o IDS a cada estado de informação novo. Se a verificação só acontece no fim, o custo de conserto sobe exponencialmente.

Causa 4 · Confusão entre IDS, MVD e checagem semântica de rule engine proprietário. Muitos times acreditam que "já usam IDS" quando na verdade usam ruleset proprietário do Solibri, do Navisworks, ou do próprio ACC. Essas ferramentas são valiosas — mas os rulesets são vendor-locked, não são intercambiáveis, e não têm valor contratual porque o cliente não consegue verificar independentemente. IDS é vendor-neutral por design: qualquer implementador conforme lê o mesmo .ids e produz o mesmo resultado sobre o mesmo IFC.

Causa 5 · Falta de biblioteca institucional de IDS reutilizáveis. Cada projeto reinventa do zero — quando reinventa. Não existe uma biblioteca corporativa de IDS por tipologia (residencial, hospitalar, industrial), por disciplina, por estágio (concept, developed, technical), que possa ser puxada do repositório e customizada em minutos em vez de semanas. O custo de autoria trava a adoção.

• Aceite indevido de marco. O modelo entra em produção downstream sem que a conformidade tenha sido verificada exaustivamente. Erros descobertos meses depois viram retrabalho massivo em disciplinas dependentes.
• Disputa contratual sem árbitro objetivo. Quando o cliente questiona uma entrega, não há métrica documentada do que foi ou não foi verificado. O laudo depende da palavra do gestor. O contrato depende da palavra do advogado. A decisão depende de quem for mais persuasivo na reunião.
• Análises técnicas viciadas. Simulação térmica, análise estrutural, cálculo de acessibilidade, orçamento — todas dependem de propriedades presentes no modelo com nomes exatos. Se metade dos objetos não tem a propriedade, a análise roda em cima de amostra viciada e produz resultado que pode ser rejeitado por perito.
• Falha em auditoria externa. Cliente corporativo (grande construtora, concessionária, órgão público) tem cada vez mais adotado IDS como parte da governança BIM. Entregar modelo sem .ids conformado é sinal de operação amadora — perda de clientes, perda de contratos futuros.
• Escala impossível. Sem IDS, cada novo projeto exige o mesmo esforço manual de verificação. Time cresce, projetos crescem, tempo de gestor não cresce na mesma proporção. Ou você automatiza, ou o pipeline entope.

Gravidade 3-4. A ausência de IDS não gera falha imediata — o modelo continua abrindo, a federação continua rodando, o clash detection continua acusando interferências. O dano é diferente: erosão sistêmica da confiança contratual e da qualidade do modelo entregue. Gravidade 3 quando o projeto ainda está em fase inicial e há tempo para introduzir IDS. Gravidade 4 quando o projeto está em fase avançada, com vários marcos já aceitos sem verificação, e o cliente começa a auditar retroativamente.

O modelo entregue está em conformidade quando existe um arquivo .ids — versionado, publicado no CDE do projeto, referenciado formalmente no BEP e no EIR como artefato de aceitação — e cada marco de entrega gera um relatório de auditoria da IDS-Audit-tool (ou implementador equivalente) com taxa de conformidade objetiva declarada. A conformidade não é binária de projeto: é métrica por specification, por objeto, por marco. Padrão canônico Coordenar:

• 100% dos objetos dentro do applicability da specification devem satisfazer o requirements — ou a specification precisa ser redefinida (nem toda parede é LoadBearing; nem todo pavimento precisa da mesma propriedade). Meta de conformidade em regra ISO formal é zero violações — o critério ISO ancorado no diagnóstico técnico não admite tolerância estatística. Se a meta declarada for "95% ok", a specification está mal calibrada, não o modelo.
• Cardinalidades corretas em cada faceta: required para exigências contratuais, optional para informação desejável, prohibited para o que o modelo não pode conter (útil em EIRs restritivos — ex.: "nenhum objeto pode ter Pset_Custom_Legacy").
• Toda propriedade referida por Property facet indica Property Set exato (propertySet), nome exato (name, sem espaços divergentes ou variações de capitalização) e tipo de dado (dataType) ou classificação bSDD com URI persistente. Especificação ambígua é specification que passa modelo errado.
• Toda classification facet, quando referencia dicionário externo, usa URI bSDD (não string livre) — permite rastreabilidade cross-projeto.
• Relatório de auditoria arquivado no CDE junto com o IFC entregue, em formato aberto (HTML/XML/JSON), como parte integrante do estado de informação "Published".

Curto prazo (semanas 1-4):

• Autoria de um .ids mínimo viável cobrindo as 5-10 exigências mais críticas do EIR — georreferenciamento, propriedades obrigatórias em 3-5 tipos de objeto, classificação bSDD nas famílias principais.
• Rodar o IDS-Audit-tool oficial sobre o IFC atual do projeto e gerar o primeiro relatório baseline. Documentar a taxa de conformidade inicial em ata. Nenhuma pretensão de perfeição — é o número honesto de referência.
• Publicar o .ids e o report inicial no CDE, marcados como versão 1.0-baseline. Comunicar ao projetista que a partir do próximo marco, o IDS é parte da aceitação.

Médio prazo (meses 2-4):

• Expandir a cobertura do .ids para 60-80% das exigências do EIR (propriedades por família de objeto, materiais por elemento estrutural, relacionamentos PartOf para agrupamentos hierárquicos).
• Integrar a rodada do IDS no fluxo de aprovação do CDE: cada transição de estado (WIP → Shared → Published) só é aceita se o report do IDS estiver anexado com taxa de conformidade declarada e assinada digitalmente pelo autor.
• Treinar a equipe de projetistas em autoria e leitura de IDS — cada BIM Manager de disciplina precisa saber escrever specification simples, ler o report gerado, e resolver falhas antes de submeter.
• Criar biblioteca interna de IDS por tipologia (residencial, hospitalar, industrial, infraestrutura) — começando pelo tipo dominante da carteira.

IDS não é decisão de projeto — é infraestrutura permanente da operação BIM. Prevenção começa em três frentes simultâneas:

• Padronizar autoria de EIR e BEP já com pré-mapeamento pra IDS. Cada requisito escrito no EIR deve nascer com uma nota técnica interna: "Property facet, Pset X, name Y, cardinality required". O advogado escreve a linguagem contratual. O BIM Manager escreve a linguagem verificável em paralelo. Não há "traduzir depois".
• Biblioteca institucional versionada de IDS por tipologia — mantida no repositório Git da empresa, com CI/CD rodando exemplos e testes contra IFCs de referência. Cada projeto novo puxa a versão pertinente, customiza, e devolve melhorias como pull request. IDS deixa de ser artefato individual e vira ativo corporativo.
• Auditoria interna trimestral de aderência a IDS. Amostragem aleatória de modelos ativos, run automatizado, report distribuído aos gestores. Cria pressão saudável de qualidade sem depender de auditoria externa.

• buildingSMART IDS 1.0Information Delivery Specification — padrão oficial buildingSMART publicado em 3 de junho de 2024. Estrutura formal: root `<ids>` com metadados (`<info>`) e uma ou mais `<specification>`, cada uma com `<applicability>` (a quais objetos aplica) e `<requirements>` (o que devem satisfazer), ambas construídas com facets. Repositório oficial: github.com/buildingSMART/IDS.
• IDS · 6 facets normativosEntity (tipo IfcClass e predefinedType), Attribute (atributo definido no schema IFC), Classification (referência a sistema classificatório externo, com ou sem URI bSDD), Property (Pset + name + dataType + valor esperado), Material (nome ou URI bSDD), PartOf (relacionamento hierárquico com outro objeto). Cardinalidades: required, optional, prohibited.
• IDS Schema/ids.xsdXSD normativo que define validamente o formato .ids. Localização canônica: standards.buildingsmart.org/IDS/1.0/ids.xsd. Todo software conforme deve validar seus `.ids` contra este XSD antes de execução.
• IDS-Audit-tool v1.0.0 (out/2024)Ferramenta oficial buildingSMART de auditoria de arquivos .ids — verifica conformidade com XSD, coerência semântica entre facets, referências válidas ao schema IFC (2X3, 4, 4X3_ADD2). Linguagem C#/.NET, MIT License. Não valida IFC contra IDS — para isso, usar implementadores como BlenderBIM Ifctester, ACCA usBIM.IDS, Solibri.
• buildingSMART bSDDServiço online (bsdd.buildingsmart.org) que hospeda classificações e propriedades com URI persistente. IDS Property facet e Classification facet podem referenciar bSDD para garantir vocabulário canônico cross-projeto. API REST pública para consulta programática.
• ABNT NBR ISO 19650-1:2022Organização e digitalização das informações sobre edificações e obras — Parte 1: Conceitos e princípios. Estabelece Employer Information Requirements (EIR) e Exchange Information Requirements como base contratual. IDS é o formato canônico para tornar esses requirements executáveis.
• ISO 12911:2023Framework for the specification of information management according to ISO 19650 — define especificação de gerenciamento da informação em nível estrutural, contexto em que IDS opera como camada de expressão executável dos requisitos.
• ISO 23387:2022Data templates for construction objects used in the life cycle of built assets — General concepts and principles. Base para vocabulário compartilhado que o bSDD hospeda e que IDS referencia via Classification/Property facets.