Por que o meu IDS nunca reprova nada?

Se tudo é opcional, o IDS é formulário.

O IDS rodou, os elementos foram selecionados, o relatório saiu cheio de linhas verdes. Cada propriedade exigida: aprovada. Cada classificação: aprovada. O gestor lê cem por cento e assina. Mas nenhuma daquelas regras podia reprovar. Todas estavam com cardinalidade optional.

No schema do IDS (buildingSMART IDS 1.0), cada faceta de requirements — Property, Attribute, Classification, Material, PartOf — pode ter cardinalidade required, optional ou prohibited. Quando a cardinalidade é optional, a ausência da informação é resultado válido: o elemento passa com a propriedade e passa sem ela. Quando todas as facetas de uma specification são opcionais, nenhum estado do modelo pode gerar reprovação. O IDS não é barreira — é formulário de registro.

A distinção com a dor anterior importa. Lá, o IDS aprovava porque a applicability não selecionava elementos — zero testados. Aqui, os elementos são selecionados, as regras rodam, o relatório parece detalhado. Mas aprovam porque não podem reprovar. O resultado é o mesmo — aceite sem verificação real — mas a causa é outra, e o relatório completo torna o defeito mais difícil de detectar.

A §5.2.1 c) da ABNT NBR ISO 19650-2 exige critério de aceitação por requisito de informação. Requisito opcional não é critério. É permissão para entregar qualquer coisa.

1. 1

   Zero reprovações em entregas consecutivas · três ou mais entregas passam sem nenhuma ressalva. Nenhum projeto real tem conformidade perfeita em todas as fases.

2. 2

   IDS com dezenas de regras e nenhuma falha · o relatório mostra muitas specifications verificadas e zero não-conformidades. A quantidade de regras esconde que nenhuma é obrigatória.

3. 3

   Relatório verde em modelo sabidamente incompleto · o modelo tem propriedades faltando ou classificação ausente, mas o IDS aprova. A equipe sabe que falta informação, o IDS diz que está tudo certo.

4. 4

   Cardinalidade não revisada · ninguém na equipe sabe qual é a cardinalidade de cada faceta no IDS. O XML foi escrito ou copiado sem conferir.

5. 5

   IDS idêntico para fases diferentes · o mesmo IDS roda no anteprojeto e no executivo sem ajuste. Informação que deveria ser obrigatória no executivo continua opcional.

1. 1

   Cardinalidade default como optional · o editor de IDS ou o template usado gera facetas com minOccurs zero por padrão. Quem não altera herda o default — e o default não reprova nada.

2. 2

   Confusão entre applicability e requirements · o redator coloca facetas de seleção nas requirements e facetas de exigência na applicability. A lógica inverte e o IDS se torna inoperante.

3. 3

   Cópia de IDS sem calibrar cardinalidade · o IDS veio de biblioteca genérica ou de outro projeto. As facetas estavam opcionais por segurança, e ninguém revisou antes de colocar em produção.

4. 4

   Medo de reprovar na primeira entrega · o redator marca tudo como opcional para não gerar atrito. O IDS entra em operação sem capacidade de reprovar.

5. 5

   Sem revisão de cardinalidade por fase · a mesma specification serve para anteprojeto e executivo. O que era aceitável como opcional no início deveria ser required no aceite final.

1. 1

   Barreira de qualidade inexistente · o IDS existe, a equipe confia nele, mas nenhum defeito é pego. A barreira está aberta e ninguém sabe.

2. 2

   Aceite contratual sobre verificação nula · a entrega é aceita com relatório IDS que não podia reprovar. O aceite não tem base técnica.

3. 3

   Descrédito quando o defeito aparece · quando alguém descobre que o IDS nunca reprovava, a credibilidade da verificação automatizada cai. Reconstruir confiança é mais caro que construir.

4. 4

   Escalada silenciosa de lacunas · cada entrega passa sem verificação real. As lacunas de informação se acumulam e só aparecem no uso do modelo — orçamento, manutenção, laudo.

5. 5

   Falsa evidência de conformidade · o relatório verde vira prova em auditoria ou disputa. Mas a prova é de que o IDS rodou, não de que a informação foi verificada.

Curto prazo (30 dias):

1. Auditar a cardinalidade de cada specification. Abrir o XML do IDS e listar a cardinalidade de cada faceta em requirements. Marcar as que estão opcionais mas deveriam ser obrigatórias.

2. Corrigir para required as facetas críticas. Propriedade contratada, classificação exigida, material declarado — se o LOIN pede, a cardinalidade é required.

3. Testar contra modelo incompleto. Rodar o IDS corrigido contra modelo de teste com lacunas propositais e confirmar que reprova.

Médio prazo (60-90 dias):

4. Criar versionamento por fase. Manter versões do IDS com cardinalidade progressiva: anteprojeto (mais opcional), projeto legal, executivo (mais obrigatório).

5. Instituir revisão de cardinalidade. Antes de qualquer IDS entrar em produção, a equipe confere faceta a faceta se a cardinalidade reflete o LOIN da fase.

6. Exigir relatório com distinção de cardinalidade. O relatório de verificação mostra separadamente regras obrigatórias e opcionais.

1. 1

   Required é o default para informação contratada · propriedade, classificação ou material exigidos no EIR entram no IDS como required, não optional. Optional é exceção justificada.

2. 2

   Cardinalidade evolui com a fase · o mesmo requisito pode ser optional no anteprojeto e required no executivo. O LOIN da fase define a cardinalidade.

3. 3

   Teste de sanidade antes de publicar · o IDS só entra em produção depois de reprovar modelo propositalmente incompleto. Se aprova tudo, tem cardinalidade errada.

4. 4

   Relatório separa obrigatório de opcional · o veredito por specification mostra quantas regras eram required e quantas eram optional. Aprovado com zero required não é verificação.

• buildingSMART IDS 1.0Information Delivery Specification. A cardinalidade das facetas de requirements (required, optional, prohibited) determina se a ausência de informação é falha ou estado válido. A faceta Entity, usada na applicability, é a única sem cardinalidade. Nas demais, required é a condição para que o IDS funcione como barreira.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.2.1 c) exige critério de aceitação por requisito de informação. Requisito com cardinalidade optional não é critério — é sugestão. §5.6.3 exige verificação da garantia da qualidade antes da troca.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. §11.2 define o nível de informação necessária (LOIN). O LOIN é a origem da cardinalidade: informação que o LOIN declara necessária entra no IDS como required.
• ISO 16739-1:2024Industry Foundation Classes (IFC4x3). A informação verificada pelo IDS vive no IFC: IfcPropertySet, IfcClassificationReference, IfcMaterial, IfcRelDefinesByProperties. Se a faceta é optional, a ausência dessas estruturas é resultado válido.
• ABNT NBR ISO 7817-1:2024Level of information need (LOIN). Define quanta informação para qual propósito. O LOIN é o que separa informação obrigatória de informação desejável — e essa distinção é o que a cardinalidade do IDS deve refletir.