Por que o IDS não acha a informação que está no modelo?

O requisito está certo. Só está na faceta errada.

O IDS exige que toda parede tenha material declarado. A verificação reprova cem por cento das paredes. Mas o material está lá — só que não na faceta Material, e sim como propriedade em Pset_WallCommon ou como atributo do tipo. O IDS procurou no lugar errado a informação que o projetista preencheu no lugar certo.

No schema do IDS (buildingSMART IDS 1.0), cada faceta verifica uma camada diferente do IFC. A faceta Property verifica valores em IfcPropertySet e IfcPropertySingleValue; a faceta Classification verifica IfcClassificationReference; a faceta Material verifica IfcMaterialLayerSetUsage ou IfcMaterialConstituentSet; a faceta Attribute verifica atributos diretos da entidade; a faceta Entity verifica o tipo da entidade. Se o redator pede material na faceta Property, o IDS procura em IfcPropertySet uma propriedade chamada "material" — e não encontra, porque o dado vive na associação de material do IFC, não em propriedade.

O caso do PredefinedType é análogo e mais comum. O IDS pede PredefinedType como Attribute direto, mas em muitos modelos o tipo predefinido vem do IfcRelDefinesByType — o PredefinedType do type object. A cascata de resolução do IFC (ISO 16739-1:2024) é: primeiro IfcRelDefinesByType, depois o PredefinedType do tipo associado; se USERDEFINED, o campo ElementType do tipo; senão, o PredefinedType do próprio objeto; se USERDEFINED, o campo ObjectType. O IDS que não segue essa cascata reprova elementos que têm o tipo predefinido correto — só que em outro lugar.

Em IFC2x3, o problema se agrava com entidades mapeadas. O modelo tem IfcFlowTerminal associado a um IfcAirTerminalType, mas o IDS escrito para IFC4 pede IfcAirTerminal — entidade que existe no IFC4 como subtipo, mas no IFC2x3 o mapeamento passa pela tabela de correspondência type/occurrence.

A §5.6.3 da ABNT NBR ISO 19650-2 exige verificação da garantia da qualidade. Verificação que procura no lugar errado não é verificação com garantia — é teste mal escrito que gera reprovação falsa.

1. 1

   Reprovação em massa de informação presente · o modelo tem a informação, mas o IDS reprova. A equipe confere manualmente e confirma que o dado existe — só que em outra camada.

2. 2

   Falha só em PredefinedType · o IDS reprova elementos que têm tipo predefinido via IfcRelDefinesByType, mas não como atributo direto.

3. 3

   Material reprovado mas está no modelo · o material foi atribuído via IfcMaterialLayerSetUsage, mas o IDS buscou em Property.

4. 4

   Classificação reprovada mas está embarcada · o IfcClassificationReference existe, mas o IDS buscou em Property ou Attribute.

5. 5

   Resultado diferente conforme o verificador · um rule engine reprova, outro aprova o mesmo modelo com o mesmo IDS. A interpretação da faceta varia entre implementações.

1. 1

   Redator não conhece a estrutura do IFC · quem escreveu o IDS não sabe a diferença entre propriedade, atributo, classificação e material no schema IFC. A faceta foi escolhida por intuição.

2. 2

   Cascata de PredefinedType ignorada · o IDS pede PredefinedType como atributo direto, mas o valor vem do tipo associado via IfcRelDefinesByType. A cascata de resolução não foi considerada.

3. 3

   Mapeamento IFC2x3 para IFC4 não aplicado · entidades que mudaram de nome ou de hierarquia entre versões do schema não foram traduzidas. O IDS pede IfcAirTerminal, o modelo tem IfcFlowTerminal com IfcAirTerminalType.

4. 4

   Cópia entre IDS sem adaptar facetas · a specification foi copiada de outro IDS que usava a faceta correta para outro contexto. No contexto novo, a faceta não é a certa.

5. 5

   Sem validação cruzada modelo-faceta · ninguém conferiu se a faceta escolhida corresponde à camada onde o dado efetivamente vive no IFC do modelo alvo.

1. 1

   Reprovação falsa gera retrabalho desnecessário · o projetista refaz o que já estava certo porque o IDS reprovou por faceta errada. Trabalho duplicado sem ganho de qualidade.

2. 2

   Descrédito do IDS · quando a equipe percebe que o IDS reprova informação que está no modelo, perde confiança. O IDS vira burocracia.

3. 3

   Aprovação falsa no sentido inverso · se o IDS busca em faceta onde o dado não deveria estar e por acaso não encontra, aprova por ausência. A faceta errada pode tanto reprovar o certo quanto aprovar o errado.

4. 4

   Inconsistência entre verificadores · cada rule engine interpreta a faceta de maneira ligeiramente diferente. O resultado muda conforme a ferramenta, sem que o IDS tenha mudado.

5. 5

   Disputa técnica sem resolução objetiva · projetista diz que entregou, contratante diz que o IDS reprovou. A discussão não é sobre o dado, é sobre onde o IDS procurou.

Curto prazo (30 dias):

1. Listar as reprovações falsas. Rodar o IDS atual e separar as reprovações onde a informação existe no modelo mas em camada diferente da que a faceta verifica.

2. Corrigir a faceta. Para cada caso, trocar a faceta por aquela que corresponde à camada real do dado: Material, Classification, Attribute ou Property conforme o IFC.

3. Tratar PredefinedType pela cascata. Se o IDS verifica PredefinedType, ajustar para que a regra considere a resolução via tipo associado.

Médio prazo (60-90 dias):

4. Criar mapa faceta-camada. Documentar, por tipo de informação verificada, qual faceta do IDS corresponde a qual camada do IFC.

5. Instituir revisão cruzada. Antes de publicar o IDS, uma segunda pessoa confere se cada faceta bate com a camada real do modelo alvo.

6. Testar em dois verificadores. Rodar cada IDS novo em pelo menos dois rule engines antes de colocar em produção.

1. 1

   Faceta nasce do modelo, não do requisito · o redator abre o IFC alvo, identifica onde a informação vive, e escolhe a faceta correspondente — não pela intenção, pelo dado.

2. 2

   PredefinedType pela cascata · verificação de tipo predefinido segue a resolução IFC: IfcRelDefinesByType, tipo associado, ElementType, objeto, ObjectType. Nunca só atributo direto.

3. 3

   Mapeamento entre versões de schema · se o IDS e o modelo usam versões diferentes do IFC, a tabela de mapeamento de entidades é aplicada antes de escrever a faceta Entity.

4. 4

   Teste duplo antes de publicar · cada IDS novo roda em dois rule engines contra o modelo alvo antes de entrar em produção.

• buildingSMART IDS 1.0Information Delivery Specification. As seis facetas (Entity, Attribute, Classification, Property, Material, PartOf) verificam camadas distintas do IFC. Escolher a faceta errada faz o IDS procurar no lugar errado e reprovar informação que está presente.
• ISO 16739-1:2024Industry Foundation Classes (IFC4x3). A informação no IFC vive em camadas: propriedades em IfcPropertySet, classificação em IfcClassificationReference, material em IfcMaterialLayerSetUsage ou IfcMaterialConstituentSet, tipo predefinido via IfcRelDefinesByType com cascata de resolução.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.6.3 exige verificação da garantia da qualidade antes da troca. Verificação que reprova informação presente por faceta errada não é garantia — é teste com defeito.
• ABNT NBR ISO 7817-1:2024Level of information need (LOIN). O LOIN define qual informação é necessária, mas a tradução para faceta IDS exige saber onde essa informação vive no IFC — o LOIN não resolve isso.
• ISO 29481-3Information delivery manual, Part 3. Formaliza o IDS. A responsabilidade de mapear faceta para camada IFC é do redator do IDS, não do rule engine.