Por que validar o IFC antes de entregar?

O projetista termina a modelagem, exporta o IFC e envia pro CDE. Ninguém roda nenhuma verificação no arquivo antes do upload. O gestor da informação recebe o IFC, abre no viewer, dá uma olhada rápida nos pavimentos, confere se "parece ok", e aceita a entrega. Dois meses depois o coordenador de instalações tenta federar o modelo e descobre que a hierarquia espacial está quebrada — IfcBuildingStorey sem relação com IfcBuilding, objetos sem pavimento associado. O modelo estrutural usa milímetros, o arquitetônico usa metros, o MEP usa centímetros. A federação explode em offsets de três ordens de grandeza.

Esse cenário tem um nome técnico: entrega de IFC sem validação pré-entrega. O arquivo saiu da ferramenta de autoria, percorreu o caminho até o CDE, transitou de estado de informação (WIP para Shared para Published) — e em nenhum momento ninguém verificou se o arquivo é sequer um IFC válido conforme o schema, se atende aos requisitos declarados no BEP/EIR, se as propriedades exigidas estão presentes com os nomes certos nos Psets certos.

Validação pré-entrega opera em três camadas distintas, cada uma com ferramenta e padrão próprio:

Camada 1 — Conformidade ao schema IFC. O arquivo .ifc é um arquivo STEP (ISO 10303-21). A primeira verificação é sintática: o parser consegue ler o arquivo sem erro? As entidades declaradas existem no schema referenciado no header (FILE_SCHEMA)? Os atributos obrigatórios estão presentes? Os tipos de dado estão corretos? Ferramentas como IfcOpenShell, FZKViewer, BIMServer e o próprio validador oficial da buildingSMART (IFC Validation Service) respondem essa pergunta em segundos. Se o arquivo não passa nessa camada, ele nem deveria entrar no CDE — é um arquivo corrompido ou malformado que vai quebrar qualquer consumidor downstream.

Camada 2 — Verificação de requisitos por IDS. O arquivo é sintaticamente válido, mas atende ao que foi contratado? As propriedades exigidas no EIR estão presentes? As classificações declaradas no BEP estão embarcadas? Os materiais esperados existem? Essa camada é coberta pelo IDS — buildingSMART IDS (ISO 29481-3). O IDS traduz os requisitos contratuais do EIR/BEP em specifications executáveis por rule engine sobre o IFC: cada specification tem applicability (a quais objetos aplica) e requirements (o que devem satisfazer). Rodar o IDS contra o IFC antes de entregar é o equivalente a rodar os testes unitários antes de fazer deploy.

Camada 3 — Verificação de processo conforme ISO 19650. O §5.6.3 da ABNT NBR ISO 19650-2:2022 exige que a parte contratada verifique a informação antes de compartilhá-la — "verificar a conformidade do modelo de informação com as normas e os métodos de produção de informação acordados". Não é sugestão. É requisito normativo. A validação pré-entrega é o mecanismo operacional que implementa esse requisito.

Nota de desambiguação: esta dor trata de não rodar a validação do arquivo IFC em si — o ato de verificar conformidade ao schema, checar requisitos via IDS, e confirmar aderência ao processo 19650 antes de enviar o arquivo. A dor sobre EIR sem verificação automatizada trata do problema anterior na cadeia: o requisito (EIR) não é verificável porque foi redigido em linguagem natural sem tradução para IDS. As duas dores são complementares: sem IDS o requisito é inexecutável; sem validação pré-entrega o IDS existe mas ninguém o roda.

1. 1

   Projetista exporta IFC e envia direto pro CDE sem rodar nenhuma ferramenta de verificação no arquivo antes do upload

2. 2

   Gestor da informacao aceita entrega BIM com base em review visual no viewer — 'abri, vi que tinha pavimentos, fechei'

3. 3

   Federacao quebra por problemas que teriam sido detectados em validacao sintatica basica: hierarquia espacial quebrada, unidades divergentes, entidades invalidas

4. 4

   Erros de schema IFC descobertos somente quando consumidor downstream (simulador termico, extrator de quantitativos, CMMS) rejeita o arquivo com mensagem de erro

5. 5

   Ninguem no time consegue dizer qual foi a ultima vez que um IFC foi validado contra o schema antes de ser publicado no CDE

6. 6

   BEP e EIR exigem propriedades especificas mas ninguem roda IDS contra o arquivo pra confirmar que estao presentes antes da entrega

7. 7

   Transicao de estado no CDE (WIP para Shared para Published) acontece sem nenhum gate tecnico automatizado — depende de aprovacao humana sem criterio verificavel

8. 8

   Quando o coordenador detecta problema no IFC, o projetista tem que reexportar, reenviar, e o ciclo de correcao leva dias em vez de minutos

Causa 1 -- Exportacao IFC tratada como ato mecanico, nao como entrega tecnica. Na cabeca do projetista, "exportar IFC" e clicar em File > Export > IFC > OK. O arquivo gerado e imediatamente enviado pro CDE. Nao ha etapa intermediaria de verificacao — nao porque o projetista seja negligente, mas porque o workflow nao tem essa etapa formalizada. O BEP nao define checklist de pre-entrega. O contrato nao exige report de validacao. A ferramenta de autoria nao forca verificacao antes de salvar.

Causa 2 -- Confusao entre "abrir no viewer" e "validar". Muitos times acreditam que abrir o IFC no Solibri, no BIMcollab ou no BIM Vision e ver que "o modelo aparece" e suficiente. Aparecer no viewer prova que o parser do viewer conseguiu ler o arquivo. Nao prova que o arquivo e conforme ao schema. Nao prova que as propriedades exigidas estao presentes. Nao prova que a hierarquia espacial esta correta. Viewer e ferramenta de visualizacao, nao de validacao.

Causa 3 -- Ausencia de ferramenta de validacao no pipeline. A maioria dos pipelines BIM nao inclui ferramenta de validacao sintatica. O IfcOpenShell valida schema em segundos. O IFC Validation Service da buildingSMART roda online. Mas nenhuma dessas ferramentas esta integrada ao fluxo de trabalho — ninguem configurou script, webhook ou CI/CD que rode automaticamente ao receber um IFC no CDE.

Causa 4 -- IDS existe mas ninguem o roda antes de entregar. Mesmo em projetos que ja possuem arquivo .ids — porque o gestor da informacao fez a traducao do EIR — a rodada de verificacao so acontece depois da entrega, se acontece. O projetista nao tem acesso ao .ids do projeto, ou tem mas nao sabe rodar. A verificacao e tratada como etapa do recebedor, nao do entregador. Isso inverte a responsabilidade: quem detecta o defeito e quem recebe, nao quem produz.

Causa 5 -- ISO 19650 ss5.6.3 ignorada operacionalmente. A norma e clara: a parte contratada deve verificar a conformidade da informacao antes de compartilha-la. Na pratica, nenhum time verifica o cumprimento desse requisito. Nenhum auditor pergunta "voce validou o IFC antes de enviar?". O requisito normativo existe no papel — nao no workflow.

• Defeito empurrado pro recebedor. O projetista entrega IFC com erro. O gestor da informacao descobre o erro. O projetista reexporta. O gestor revalida. O ciclo se repete ate funcionar. Custo: dias de ida-e-volta que seriam evitados com validacao no lado do produtor.
• Federacao corrompida por arquivo malformado. Um unico IFC com hierarquia espacial quebrada ou unidades inconsistentes pode corromper a federacao inteira — gerando offsets geometricos, pavimentos fantasma, objetos flutuando fora do terreno.
• Consumidores downstream que falham silenciosamente. Simulador termico que ignora objetos sem propriedade termica em vez de acusar erro. Extrator de quantitativos que pula elementos sem Pset de custo. O resultado sai incompleto sem que ninguem perceba que a causa raiz e um IFC nao validado.
• Violacao de requisito normativo. A ABNT NBR ISO 19650-2:2022 ss5.6.3 exige verificacao antes do compartilhamento. Em auditoria formal, a ausencia de evidencia de verificacao pre-entrega e nao-conformidade documentavel.
• Retrabalho exponencial em fases avancadas. Erro de schema detectado na fase de entrega final custa ordens de grandeza mais que o mesmo erro detectado na exportacao. O custo de correcao sobe com o numero de disciplinas que ja consumiram o IFC defeituoso.

Gravidade 3-4. Entregar IFC sem validar nao gera falha imediata visivel — o arquivo chega no CDE, o viewer abre, o gestor ve geometria na tela. O dano e diferido: erro silencioso que se propaga downstream ate explodir em federacao, simulacao, extracao de quantitativos ou auditoria formal. Gravidade 3 quando o projeto esta em fase inicial e ha tempo pra implantar rotina de validacao. Gravidade 4 quando o projeto esta em fase avancada com multiplos marcos aceitos sem validacao, e os consumidores downstream ja herdaram defeitos nao detectados.

O IFC entregue esta em conformidade quando passou por tres camadas de validacao antes de ser compartilhado no CDE, e cada camada gerou evidencia rastreavel:

• Camada 1 — Conformidade ao schema. O arquivo foi validado sintaticamente contra o schema IFC declarado no header (FILE_SCHEMA). Zero erros de parser, zero entidades invalidas, zero atributos obrigatorios ausentes, zero tipos de dado incorretos. Ferramenta: IfcOpenShell, FZKViewer, IFC Validation Service da buildingSMART, ou equivalente.
• Camada 2 — Verificacao de requisitos por IDS. O arquivo foi verificado contra o .ids do projeto — que traduz os requisitos do EIR/BEP em specifications executaveis conforme buildingSMART IDS (ISO 29481-3). Taxa de conformidade: zero violacoes nao-justificadas por specification. Ferramenta: IDS-Audit-tool, BlenderBIM Ifctester, ACCA usBIM.IDS, Solibri IDS module, ou implementador conforme.
• Camada 3 — Aderencia ao processo ISO 19650. A verificacao pre-entrega esta formalizada como requisito do BEP, conforme ABNT NBR ISO 19650-2:2022 ss5.6.3. O projetista verifica antes de compartilhar. O gestor verifica antes de aceitar. Cada verificacao gera report arquivado no CDE.

Curto prazo (semanas 1-4):

• Definir checklist de validacao pre-entrega e publicar como anexo do BEP. Conteudo minimo: validacao sintatica (parser), verificacao de hierarquia espacial, verificacao de unidades, rodada de IDS (se disponivel). Template padrao distribuido a todos os projetistas.
• Rodar validacao sintatica (IfcOpenShell ou IFC Validation Service) nos ultimos 3 IFCs publicados no CDE. Gerar baseline de qualidade: quantos erros de schema existem nos arquivos ja aceitos? Documentar em ata.
• Instalar ferramenta de validacao sintatica na maquina de cada projetista BIM e treinar uso basico (10 minutos, um comando CLI ou um botao no plugin). Objetivo: zero fricao, zero desculpa.

Medio prazo (meses 2-4):

• Integrar validacao sintatica ao fluxo do CDE via webhook, script CI/CD ou plugin. Objetivo: cada upload de IFC dispara validacao automatica; resultado e anexado ao arquivo como metadado; transicao de estado bloqueada se validacao falhar.
• Distribuir o .ids do projeto a todos os projetistas. Treinar cada BIM Manager de disciplina em rodar IDS contra o proprio modelo antes de submeter. Validacao IDS deixa de ser responsabilidade exclusiva do recebedor.
• Criar dashboard de qualidade por disciplina: taxa de conformidade ao schema e ao IDS por projetista, por marco, com tendencia temporal. Gestao visual que cria pressao saudavel de qualidade.
• Formalizar no BEP a clausula de validacao pre-entrega conforme ABNT NBR ISO 19650-2:2022 ss5.6.3, incluindo lista de ferramentas aceitas e formato de report exigido.

Validacao pre-entrega nao e etapa opcional que depende de disciplina individual — e infraestrutura de processo que deve ser tao automatica quanto o build de software. Prevencao:

• Validacao sintatica no pipeline, nao na cabeca do projetista. Webhook no CDE ou script CI/CD que roda IfcOpenShell sobre cada IFC no momento do upload. Se o arquivo nao passa no parser, o upload e rejeitado automaticamente. Projetista recebe mensagem com lista de erros e corrige antes de reenviar. Zero intervencao humana no gate.
• IDS distribuido como "contrato executavel" do projeto. O .ids nao fica so com o gestor da informacao. E publicado no CDE como artefato de referencia e distribuido a cada projetista no kickoff. O projetista roda o IDS contra o proprio modelo antes de exportar — assim como desenvolvedor roda testes antes de commitar.
• Clausula contratual de validacao pre-entrega. EIR e BEP exigem explicitamente que cada entrega seja acompanhada de report de validacao sintatica + report de verificacao IDS. Sem reports, a entrega nao e aceita. Clausula transforma validacao de boa pratica em obrigacao contratual.
• Cultura de "defeito zero na origem". Treinamento institucional que muda a mentalidade de "exportar e enviar" para "exportar, validar, corrigir, enviar". O custo de correcao no lado do produtor e ordens de grandeza menor do que o custo de correcao no lado do consumidor.

• ISO 16739-1:2024 (IFC4x3)Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries — Part 1: Data schema. Define o schema normativo contra o qual a conformidade sintatica do arquivo .ifc deve ser verificada. Cada entidade, atributo e tipo de dado tem definicao formal no schema EXPRESS.
• buildingSMART IDS (ISO 29481-3)Information Delivery Specification — padrao buildingSMART para traducao de requisitos contratuais (EIR/BEP) em specifications executaveis por rule engine sobre IFC. Cada specification tem applicability e requirements construidos com facets (Entity, Attribute, Classification, Property, Material, PartOf). Formato .ids validavel contra XSD normativo.
• ABNT NBR ISO 19650-2:2022Organizacao e digitalizacao das informacoes sobre edificacoes e obras — Parte 2: Fase de entrega dos ativos. O ss5.6.3 exige que a parte contratada verifique a conformidade do modelo de informacao com as normas e os metodos de producao de informacao acordados antes de compartilhar — base normativa para validacao pre-entrega.
• ABNT NBR ISO 19650-1:2022Conceitos e principios. Estabelece o Common Data Environment (CDE) como ambiente unico de gestao da informacao e define estados de informacao (WIP, Shared, Published, Archive) cuja transicao deve ser controlada por verificacao formal.
• ISO 10303-21:2016Industrial automation systems and integration — Product data representation and exchange — Part 21: Implementation methods: Clear text encoding of the exchange structure (STEP). O arquivo .ifc e um arquivo STEP. A validacao sintatica basica e a verificacao de conformidade com esta norma de encoding.
• IDS-Audit-tool v1.0.0 (out/2024)Ferramenta oficial buildingSMART de auditoria de arquivos .ids conforme XSD normativo. C# .NET, MIT License. Verifica conformidade do .ids em si; para verificar IFC contra IDS usar implementadores como BlenderBIM Ifctester, ACCA usBIM.IDS, Solibri IDS module.
• IfcOpenShellBiblioteca open-source (LGPL) para leitura, escrita e validacao de arquivos IFC. Modulo ifcopenshell.validate verifica conformidade sintatica contra schema EXPRESS. Ferramenta de referencia para validacao pre-entrega em pipeline automatizado.