O IDS pode exigir um Pset que não existe no padrão?

O IDS transformou o seu desvio em cláusula contratual.

O IDS exige que toda porta tenha a propriedade AcousticRating no Pset Pset_Custom_Acoustic. O rule engine reprova cem por cento das portas. O projetista abre a documentação IFC, procura Pset_Custom_Acoustic e não encontra — porque não existe. É um Pset inventado pelo redator do IDS, que virou regra de verificação, que virou critério de aceite, que virou cláusula contratual. O desvio de um indivíduo agora obriga toda a cadeia.

No IFC (ISO 16739-1:2024), existem dois tipos de Property Set: os padronizados (Pset_ definidos no schema, como Pset_DoorCommon, Pset_WallCommon) e os customizados (criados pelo usuário, com qualquer nome). Os Psets padronizados são interoperáveis: qualquer software que implemente o schema IFC sabe que Pset_DoorCommon.FireRating é resistência ao fogo de uma porta. Os Psets customizados dependem de acordo prévio: se o IDS exige Pset_Custom_Acoustic.AcousticRating, o projetista precisa saber que esse Pset existe, que deve ser criado manualmente, e que o software de autoria não vai gerá-lo automaticamente.

O buildingSMART IDS 1.0 permite que a faceta Property referencie qualquer Pset — padronizado ou customizado. Não há restrição no schema. Isso significa que o redator pode criar regra para Pset que não existe em nenhum padrão, e o rule engine vai cobrar a presença desse Pset como se fosse obrigatório. A liberdade do IDS é poder. O problema é quando esse poder transforma convenção local em exigência universal.

A questão não é se Psets customizados são proibidos — são legítimos e às vezes necessários. A questão é se foram acordados. A §5.2.1 c) da ABNT NBR ISO 19650-2 exige critério de aceitação declarado. Pset inventado sem acordo não é critério — é surpresa.

1. 1

   Reprovação por Pset que ninguém conhece · o IDS reprova porque o Pset exigido não existe no modelo. A equipe procura na documentação IFC e não encontra.

2. 2

   Pset com nome fora do padrão · o IDS exige Pset com nome que não segue a convenção Pset_ do schema. É Pset inventado.

3. 3

   Software não gera o Pset automaticamente · o projetista não consegue exportar o Pset exigido porque o software de autoria não o reconhece.

4. 4

   Requisito que veio de um projeto anterior · o Pset foi criado em outro projeto por conveniência e migrou para o IDS atual sem revisão.

5. 5

   Ninguém sabe quem criou o Pset · não há registro de quem definiu o Pset customizado, quando, ou com base em qual requisito.

1. 1

   Redator usou Pset local como se fosse padrão · o redator do IDS tinha o Pset customizado no seu software e assumiu que todo mundo teria. Não é padrão — é configuração local.

2. 2

   Sem mapeamento para Pset padronizado · a propriedade exigida existe em Pset padronizado do schema, mas o redator criou Pset customizado duplicando a informação.

3. 3

   Cópia de IDS sem limpar Psets locais · o IDS foi copiado de outro projeto que usava Psets customizados específicos. Ninguém removeu ou adaptou.

4. 4

   Requisito vago traduzido em Pset inventado · o EIR pedia informação genérica e o redator criou Pset e propriedade do zero, sem consultar o schema IFC.

5. 5

   Sem revisão de Psets antes de publicar · ninguém conferiu se os Psets exigidos pelo IDS são padronizados ou customizados, e se os customizados foram acordados.

1. 1

   Reprovação de entrega completa · o projetista entregou tudo o que o schema padronizado pede, mas o IDS reprova por Pset que não existe no padrão. A entrega é completa e reprova.

2. 2

   Retrabalho manual para criar Pset · o projetista precisa criar o Pset customizado manualmente, elemento a elemento. Trabalho que o software não automatiza.

3. 3

   Interoperabilidade quebrada · Pset customizado não é reconhecido por softwares que seguem o schema padrão. A informação fica legível só para quem combinou.

4. 4

   Convenção local vira exigência contratual · o que era prática de um escritório se torna regra de verificação em contrato. A cadeia inteira fica refém de decisão local.

5. 5

   Disputa contratual sem base normativa · o contratante alega não-conformidade por Pset inventado. O fornecedor alega que o Pset não existe no padrão. Não há árbitro objetivo.

Curto prazo (30 dias):

1. Auditar os Psets do IDS. Listar todos os Psets referenciados na faceta Property e classificar como padronizado ou customizado.

2. Substituir customizados por padronizados. Onde a propriedade exigida existe em Pset padronizado, trocar a referência no IDS.

3. Documentar os customizados restantes. Para cada Pset customizado que sobrou, registrar no BEP o nome, as propriedades, o tipo de dado e o motivo.

Médio prazo (60-90 dias):

4. Acordar Psets customizados antes do IDS. Incluir no BEP a lista de Psets customizados exigidos, com aprovação da equipe, antes de o IDS entrar em produção.

5. Manter biblioteca de Psets customizados. Se a organização tem Psets próprios recorrentes, versioná-los e distribuir com o IDS.

6. Conferir que o software exporta. Validar com o projetista que o mapeamento de exportação gera os Psets customizados exigidos.

1. 1

   Pset padronizado primeiro · o IDS usa Pset padronizado do schema IFC sempre que possível. Pset customizado é exceção, não regra.

2. 2

   Customizado é acordado, não imposto · Pset customizado entra no BEP antes de entrar no IDS. A equipe sabe que existe e sabe como gerar.

3. 3

   Sem duplicação · Pset customizado não duplica propriedade que já existe em Pset padronizado. Uma informação, um lugar.

4. 4

   Rastreabilidade do Pset ao requisito · cada Pset customizado tem dono, versão e link ao requisito do EIR ou LOIN que o originou.

• buildingSMART IDS 1.0Information Delivery Specification. A faceta Property aceita qualquer propertySet — padronizado ou customizado. O IDS não distingue. A responsabilidade de usar Psets acordados é do redator.
• ISO 16739-1:2024Industry Foundation Classes (IFC4x3). Os Psets padronizados (Pset_WallCommon, Pset_DoorCommon etc.) são definidos no schema e reconhecidos por qualquer software que implemente o IFC. Psets customizados dependem de acordo prévio.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.2.1 c) exige critério de aceitação por requisito. Pset inventado sem acordo não é critério declarado — é surpresa na verificação.
• ABNT NBR ISO 7817-1:2024Level of information need (LOIN). O LOIN define qual informação é necessária. Se a informação exige Pset customizado, o LOIN deve registrar, e o BEP deve acordar.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. §11.2 define o nível de informação necessária. Informação fora do padrão IFC é legítima, mas precisa de acordo documentado — não de imposição via IDS.