Interoperabilidade é uma capacidade demonstrada para um uso definido, não um atributo automático de qualquer arquivo com extensão IFC; a entrega precisa combinar requisitos explícitos, versão identificada, validação e aceitação pelo destinatário.
Abrir não é o mesmo que poder usar
Quando um software exporta um arquivo IFC e outro software consegue abri-lo, há um sinal de transporte. Ainda faltam perguntas decisivas: os objetos relevantes chegaram com identidade e relações compreensíveis? As propriedades, classificações, unidades e localizações necessárias para o uso foram preservadas? O destinatário consegue realizar a coordenação, o quantitativo, a análise ou o planejamento que motivou a entrega? Sem essas respostas, “compatível com IFC” pode ser uma frase ampla demais para orientar compra ou contrato.
A buildingSMART descreve IFC como um padrão aberto, internacional e neutro de fornecedor para descrição digital do ambiente construído. O esquema codifica identidade, características e relações. Essa definição explica por que a extensão do arquivo não resolve tudo: o significado depende de qual versão, quais entidades, quais propriedades e quais relações são exigidas pelo caso de uso.
Declare o caso de uso antes de pedir o arquivo
Uma troca para coordenação espacial pode aceitar um conjunto de informações diferente de uma troca para quantitativos, planejamento, fabricação, operação ou análise estrutural. Em vez de perguntar apenas “entrega IFC?”, o contratante pode formular perguntas verificáveis: qual decisão o destinatário precisa tomar, quais objetos e atributos são indispensáveis, qual versão do esquema será usada, em que estágio o arquivo será entregue e como o receptor registrará exceções?
Esse enquadramento evita dois erros opostos. O primeiro é exigir dados sem finalidade, produzindo um modelo pesado e difícil de manter. O segundo é aceitar uma exportação genérica que não permite o uso esperado. A especificação deve ser proporcional: suficiente para a tarefa, compreensível para quem produz e testável para quem recebe. O detalhamento pode mudar entre disciplinas e fases, desde que o acordo registre essas diferenças.
Versão e visão de troca importam
A base pública da buildingSMART lista múltiplas versões de IFC e identifica o IFC 4.3 ADD2 como publicação oficial associada à ISO 16739-1:2024. Isso não obriga todo projeto a migrar automaticamente, nem torna versões anteriores inúteis. Mostra que a versão é parte da identidade da entrega. Quem produz e quem recebe precisam registrar qual esquema e qual recorte de implementação foram testados, porque mudanças de versão podem alterar disponibilidade e interpretação de dados.
Também é necessário saber se há uma visão de referência ou outro recorte aplicável ao uso. A documentação da buildingSMART relaciona views a finalidades específicas, como coordenação de projeto ou alinhamentos em infraestrutura. Usar esses recursos sem verificar sua adequação pode gerar falsa segurança. A troca deve ser tratada como contrato de informação: a equipe concorda sobre o que espera e registra o que não foi atendido.
Validação precisa testar informação, não só sintaxe
Um validador sintático pode detectar se o arquivo respeita regras formais do esquema. Essa checagem é importante, mas não confirma que o conjunto atende ao caso de uso. A Information Delivery Specification (IDS), da buildingSMART, é apresentada como uma forma legível por máquina para definir requisitos de troca, incluindo objetos, classificações, propriedades, valores e unidades. Ela pode apoiar uma verificação mais precisa entre o que foi pedido e o que foi entregue.
IDS não elimina julgamento profissional, nem substitui análise de responsabilidade técnica. Um resultado de validação deve ser lido com o contexto: requisitos foram definidos corretamente? Itens ausentes são críticos para a finalidade? Há uma exceção aceita? A equipe precisa guardar a versão do requisito, o arquivo analisado, o relatório e a decisão sobre pendências. Sem essa trilha, uma aprovação posterior fica difícil de explicar.
Um exemplo de aceite que detecta a lacuna
Imagine uma troca hipotética para conferir portas por pavimento. O destinatário precisa identificar cada porta, sua localização e uma propriedade previamente acordada. O arquivo abre e a geometria aparece, mas parte das portas não tem localização ou traz a propriedade em campos diferentes. A entrega pode estar formalmente legível e ainda impedir a tarefa. Um relatório útil aponta os objetos afetados, o requisito não atendido e a decisão sobre correção ou exceção.
Esse exemplo mostra por que o aceite deve ser combinado antes da exportação. No desenvolvimento do VORTEX, relacionar arquivo, propósito e revisão é uma direção de arquitetura; suporte a IFC, IDS ou software específico depende de comprovação própria. Para o leitor, o próximo passo é pedir um pequeno arquivo de teste e verificar a tarefa real antes de assumir compatibilidade.