Por que meu IFC não tem as propriedades que contratei?

Pedir a propriedade no contrato não coloca a propriedade no modelo. Só a verificação coloca.

O BEP listou as informações exigidas, o EIR detalhou, o contrato assinou. Chega o IFC: a geometria está lá, o modelo abre, o clash roda. Mas os campos que sustentam orçamento, manutenção e laudo estão vazios — ou preenchidos com outro nome, em outro Property Set, fora do padrão contratado. A informação que dá valor ao modelo é justamente a que faltou.

No IFC (ISO 16739-1:2024), a informação alfanumérica vive em IfcPropertySet (os Pset_ padronizados e os customizados), com valores em IfcPropertySingleValue, ligados ao elemento por IfcRelDefinesByProperties; quantidades vão em IfcElementQuantity. Se o Pset esperado não veio, ou veio vazio, ou com nome fora do padrão, a propriedade contratada não existe para quem consulta — mesmo que o modelo pareça completo.

O problema raramente é o projetista esquecer. É o requisito nunca ter virado teste. Sem nível de informação necessária (LOIN) declarado — quanta informação, para qual propósito (§11.2 da 19650-1; ABNT NBR ISO 7817-1) — e sem IDS (ISO 29481-3) que traduza esse LOIN em regra verificável, o BEP pede em prosa e ninguém confere. O rule engine só reprova o que foi especificado como regra.

Propriedade contratada é entregável, não gentileza. A §5.2.1 c) da 19650-2 exige critério de aceitação por requisito, e a verificação da garantia da qualidade confere antes da troca (§5.6.3). IFC sem as propriedades que o BEP pediu é entrega incompleta — só que a falta não aparece na tela, aparece na consulta.

1. 1

   Campos alfanuméricos vazios · o elemento tem o Pset esperado, mas as propriedades estão em branco. Estrutura presente, valor ausente.

2. 2

   Pset contratado não veio · o Property Set customizado exigido no BEP simplesmente não existe no IFC entregue.

3. 3

   Propriedade com nome fora do padrão · a informação está no modelo, mas sob outro nome ou outro Pset, fora do que foi contratado. Nenhuma consulta padronizada a encontra.

4. 4

   IDS falha por falta de propriedade · ao rodar a verificação, elementos reprovam porque a propriedade exigida não está presente ou está vazia.

5. 5

   Faltam fabricante, material ou código · campos que sustentam orçamento, compra e manutenção não vieram — o modelo serve para ver, não para operar.

1. 1

   LOIN não declarado · ninguém definiu quanta informação cada entregável precisa ter, para qual propósito e em qual fase (§11.2 da 19650-1; ISO 7817-1). Sem isso, o requisito é vago.

2. 2

   Requisito em prosa, não em regra · o BEP descreve as propriedades exigidas em texto, mas não há IDS (ISO 29481-3) que traduza isso em regra verificável sobre o IFC.

3. 3

   Preenchimento manual sem conferência · as propriedades dependem de o projetista lembrar de preencher campo a campo, e nada confere depois.

4. 4

   Mapeamento de export incompleto · os parâmetros do software não estão mapeados para os Pset e nomes IFC esperados, e saem vazios ou renomeados na exportação.

5. 5

   Aceite sem verificação de informação · o modelo é aceito pela geometria, sem checar se a informação alfanumérica contratada está presente (§5.2.1 c e §5.6.3 da 19650-2).

1. 1

   Orçamento e 5D travados · sem propriedade de material, classificação ou quantidade, a extração para orçamento não roda — ou roda sobre dado faltando.

2. 2

   Manutenção e FM sem base · ativo sem dados de fabricante, garantia e código não entra no sistema de manutenção. O modelo não serve para operar.

3. 3

   Laudo sem evidência · exigências técnicas (desempenho, segurança, acessibilidade) que dependem de propriedade preenchida não podem ser comprovadas.

4. 4

   Entrega juridicamente incompleta · a informação exigida no EIR não está presente sob o nome esperado. A leitura contratual é: não entregou.

5. 5

   Falha que só aparece na consulta · o modelo parece pronto na tela; a ausência de propriedade só emerge quando a informação é usada, tarde e no caminho crítico.

Curto prazo (30 dias):

1. Declarar o LOIN das propriedades críticas do EIR: quanta informação, para qual propósito, em qual fase (§11.2 da 19650-1; ISO 7817-1).

2. Traduzir esse LOIN em IDS (ISO 29481-3): Pset, nome, tipo de dado e cardinalidade de cada propriedade exigida.

3. Rodar a IDS contra o IFC atual e gerar o baseline de tudo que falta, por disciplina.

Médio prazo (60-90 dias):

4. Instituir o gate técnico: nenhuma entrega é aceita sem passar pela IDS, com relatório arquivado no CDE como evidência.

5. Mapear os parâmetros de cada software para os Pset e nomes IFC contratados, para que a exportação não gere campo vazio ou renomeado.

6. Versionar a biblioteca de IDS por tipologia, para que cada novo projeto puxe as regras vigentes em vez de reescrevê-las.

1. 1

   LOIN nasce com o requisito · cada propriedade exigida no EIR nasce com nível de informação necessária declarado — quanto, para quê, em qual fase.

2. 2

   Requisito é IDS, não prosa · o LOIN vira IDS verificável (ISO 29481-3), não texto que ninguém confere.

3. 3

   Gate técnico antes do aceite · nenhuma entrega passa sem a IDS aprovar; o relatório fica arquivado no CDE.

4. 4

   Export mapeado · os parâmetros do software são mapeados para os Pset e nomes contratados, sem campo vazio ou renomeado.

• ABNT NBR ISO 16739-1:2024Industry Foundation Classes (IFC). A informação alfanumérica vive em IfcPropertySet (Pset_ padronizados e customizados), com valores em IfcPropertySingleValue e ligação ao elemento por IfcRelDefinesByProperties; quantidades em IfcElementQuantity. É o alvo concreto que a IDS verifica.
• ABNT NBR ISO 7817-1:2024Level of information need (LOIN). Define como declarar quanta informação um entregável precisa ter, para qual propósito — a base para transformar um requisito vago em propriedade exigível e verificável. §7 institui a verificação e validação da informação.
• ISO 29481-3Information delivery manual, Part 3. Formaliza a IDS (Information Delivery Specification), que traduz o LOIN em regra verificável — Pset, nome, tipo de dado, cardinalidade — que o rule engine confere sobre o IFC antes do aceite.
• ABNT NBR ISO 19650-2:2018Fase de entrega. §5.2.1 c) exige critério de aceitação por requisito de informação; §5.6.3 institui a verificação da garantia da qualidade antes da troca. Propriedade contratada é requisito com critério, não gentileza.
• ABNT NBR ISO 19650-1:2018Conceitos e princípios. §11.2 define o nível de informação necessária (LOIN) como o mínimo suficiente para o propósito — informação além do necessário é desperdício, aquém é entrega incompleta.