Por que o IDS aprovou o modelo sem verificar nada?

Cem por cento de aprovação sobre zero elemento testado.

O IDS rodou, o relatório saiu limpo, o gestor assinou o aceite. Três meses depois alguém abre o modelo para extrair quantitativos e descobre que metade das paredes não tem classificação. Como o IDS aprovou?

Não aprovou. O IDS não testou. A applicability — a metade da specification que seleciona quais elementos do modelo serão verificados — não casou com nenhum elemento. Zero elementos selecionados. Zero elementos testados. Zero reprovações. Resultado: aprovado por vacuidade.

Na lógica do IDS (buildingSMART IDS 1.0), cada specification tem duas metades: applicability seleciona, requirements verifica. Na faceta Entity, o Name casa por correspondência exata em maiúsculas — não há herança automática. Se a applicability pede IFCELEMENT ou IFCBUILTELEMENT, seleciona zero elementos: entidades abstratas não podem ser instanciadas em nenhum modelo. É o caso puro de aprovação por vacuidade. Caso análogo entre versões de schema: modelo IFC2x3 com IfcWallStandardCase contra IDS escrito para IFC4 pedindo IFCWALL — IfcWallStandardCase é depreciado em IFC4 e IFC4X3, mas a entidade não casa, e zero elementos entram no filtro. Se a applicability pede Classification de um sistema que ninguém embarcou, o mesmo. Se pede Property em Pset que não existe como seletor, o mesmo.

O perigo é que o relatório não diz "não testei nada". Diz "aprovado". A ausência de reprovação não é evidência de conformidade — é evidência de que o teste não aconteceu. E o aceite do modelo se baseia em um veredito que não verificou nenhum elemento.

A §5.6.3 da ABNT NBR ISO 19650-2 exige verificação da garantia da qualidade antes da troca. Verificação que seleciona zero elemento não é verificação. É um relatório cosmético que autoriza entrega incompleta.

1. 1

   Relatório limpo demais · o IDS roda e o resultado é cem por cento de conformidade, sem nenhuma ressalva. Nenhum projeto real passa assim na primeira entrega.

2. 2

   Zero elementos testados · o relatório mostra conformidade mas a contagem de elementos verificados é zero ou ausente.

3. 3

   Resultado idêntico em modelos diferentes · o mesmo IDS roda em dois modelos distintos e dá o mesmo resultado perfeito. Sinal de que não está filtrando.

4. 4

   Propriedade faltando apesar de aprovado · inspeção manual encontra ausências que o IDS deveria ter pego. A regra existe, mas a applicability não selecionou o elemento.

5. 5

   Aprovação instantânea · o rule engine retorna em milissegundos em modelo com milhares de elementos. Rápido demais para ter testado algo.

1. 1

   Entity abstrata ou sem correspondência · a applicability pede entidade abstrata como IFCELEMENT ou IFCBUILTELEMENT, que não pode ser instanciada em nenhum modelo — zero elementos. Ou pede IFCWALL em modelo IFC2x3 que exportou IfcWallStandardCase (depreciado em IFC4/IFC4X3). A faceta Entity casa por correspondência exata, sem herança.

2. 2

   Classification de sistema ausente · a applicability filtra por Classification com um sistema que não foi embarcado no IFC. Nenhum elemento tem a classificação esperada.

3. 3

   ifcVersion incompatível · o IDS declara ifcVersion IFC4X3 e o modelo é IFC2x3 (ou vice-versa). O rule engine rejeita silenciosamente a specification inteira.

4. 4

   Pset usado como seletor não existe no modelo · a applicability filtra por Property em Pset customizado que o projetista não criou. Zero elementos têm esse Pset.

5. 5

   IDS copiado de outro projeto sem calibrar · a specification foi colada de uma biblioteca genérica sem conferir se as entidades e classificações do modelo alvo existem.

1. 1

   Aceite baseado em teste inexistente · a entrega foi aceita com base em um relatório que não verificou nenhum elemento. A decisão não tem base.

2. 2

   Falsa segurança institucional · a equipe confia que o IDS é barreira de qualidade, mas a barreira está aberta. Erros passam em todas as entregas seguintes.

3. 3

   Propagação do vício · se o IDS base está com applicability quebrada, toda specification derivada dele herda o mesmo defeito. O problema se multiplica.

4. 4

   Auditoria retroativa inviável · quando o problema é descoberto, os modelos já foram aceitos e as decisões tomadas. Refazer a verificação não desfaz o aceite.

5. 5

   Descrédito da verificação automatizada · quando a equipe descobre que o IDS não testava nada, perde confiança no método. O custo de reconquistar é alto.

Curto prazo (30 dias):

1. Auditar a applicability de cada specification. Rodar o IDS contra o modelo atual e anotar quantos elementos cada specification selecionou. Specification com zero é defeito.

2. Corrigir a Entity. Alinhar a entidade da applicability com a que o modelo realmente exporta. Se o modelo usa IfcWallStandardCase, o IDS pede IfcWallStandardCase — não IfcWall genérico que não casa.

3. Conferir ifcVersion. Alinhar a versão declarada no IDS com o schema real do modelo entregue.

Médio prazo (60-90 dias):

4. Instituir teste de sanidade do IDS antes de colocar em produção. Rodar contra modelo de referência incompleto e confirmar que reprova.

5. Exigir contagem de elementos no relatório. O veredito sem contagem é ambíguo — aprovado com zero testados não é aprovado.

6. Vincular o IDS ao modelo alvo. A applicability é calibrada para o modelo real, não copiada de biblioteca genérica sem conferência.

1. 1

   Specification com zero elementos é defeito · o IDS só entra em produção depois de rodar contra o modelo alvo e selecionar elementos em cada specification.

2. 2

   Teste contra modelo sabidamente errado · antes de usar o IDS para aceite, rode contra modelo propositalmente incompleto. Se aprovar, o IDS tem defeito.

3. 3

   Relatório com contagem, não só veredito · o relatório de verificação mostra quantos elementos cada specification testou. Aprovado com zero testados não é aprovado.

4. 4

   Applicability calibrada para o schema real · a entidade, a classificação e a versão do schema na applicability são conferidos contra o modelo alvo antes do primeiro aceite.

• buildingSMART IDS 1.0Information Delivery Specification. Cada specification tem applicability (seletor de elementos) e requirements (regras a verificar). Se a applicability não casa com nenhum elemento, os requirements são vacuamente verdadeiros — aprovação sem teste. A faceta Entity é a única sem cardinalidade, e a ausência de herança automática obriga enumeração explícita de todas as subentidades. A contagem de elementos selecionados é o primeiro controle de sanidade.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.6.3 exige verificação da garantia da qualidade antes da troca. Verificação que seleciona zero elementos não cumpre a verificação — é relatório cosmético. §5.2.1 c) exige critério de aceitação por requisito.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. §6.3.3 institui aprovação documentada e acordada antes da troca. O registro da verificação precisa incluir evidência de que os elementos foram efetivamente testados, não só o resultado.
• ISO 16739-1:2024Industry Foundation Classes (IFC4x3). A entidade declarada na applicability do IDS deve corresponder à entidade real no modelo: IfcWall, IfcWallStandardCase, IfcSlab — cada uma é tipo distinto no schema, e a seleção é por correspondência exata.
• ABNT NBR ISO 7817-1:2024Level of information need (LOIN). O LOIN define quanta informação e para qual propósito. O IDS traduz esse LOIN em regra verificável — mas a regra só funciona se a applicability selecionar os elementos certos.