Qual versão do IDS vale para o aceite?

O IDS que vale é o do último e-mail.

O gestor envia o IDS por e-mail. O projetista roda a verificação e reprova. Alega que está usando a versão correta. O gestor confere e descobre que mandou a versão errada — ou que o projetista está com versão de dois meses atrás. Ninguém sabe qual é a versão vigente, quem a aprovou, quando foi publicada, ou se substituiu a anterior.

O IDS é contêiner de informação. Na ABNT NBR ISO 19650-1, contêiner de informação é qualquer conjunto nomeado de informação recuperável de dentro de uma hierarquia de armazenamento de informação (§3.3.12). O IDS cabe nessa definição: é arquivo nomeado, com conteúdo versionável, que alimenta decisão (o aceite). Como contêiner, precisa de estado (§12/§12.1 da 19650-1): trabalho em andamento, compartilhado, publicado, arquivado. E precisa de trilha: quem criou, quem aprovou, quando, qual versão substituiu.

IDS que circula por e-mail não tem estado. Não tem versão controlada. Não tem dono declarado. Não tem trilha de auditoria. É arquivo solto que alguém anexou. Quando existem três versões em três caixas de e-mail diferentes, a pergunta "qual IDS vale?" não tem resposta.

A §5.6.3 da ABNT NBR ISO 19650-2 exige verificação da garantia da qualidade antes da troca. Verificação com IDS sem versão controlada não garante qual critério foi aplicado. E a §6.3.3 da 19650-1 exige processos de aprovação documentados e acordados. IDS sem dono e sem aprovação não atende.

1. 1

   IDS enviado por e-mail · o IDS circula como anexo de e-mail, sem CDE, sem estado, sem versão controlada.

2. 2

   Versão errada em uso · o projetista usa versão desatualizada do IDS. Ninguém notificou a troca.

3. 3

   Ninguém sabe a versão vigente · dois gestores apontam versões diferentes como a correta. Não há registro único.

4. 4

   IDS sem dono declarado · ninguém é responsável pelo IDS: quem cria, quem revisa, quem aprova, quem publica.

5. 5

   Sem registro de alteração · o IDS mudou entre entregas mas não há log do que mudou, quando e por quê.

1. 1

   IDS fora do CDE · o IDS não é publicado no CDE como contêiner com estado. Vive em pasta local, e-mail ou drive compartilhado sem controle.

2. 2

   Sem processo de publicação · o IDS é criado e usado sem passar por ciclo de revisão, aprovação e publicação institucional.

3. 3

   Dono não designado · ninguém foi formalmente nomeado como responsável pelo IDS — quem cria é quem edita, e qualquer um altera.

4. 4

   Sem política de versionamento · não há convenção de versão (major.minor, data, hash) nem regra de quando o IDS muda de versão.

5. 5

   CDE não trata o IDS como contêiner · o CDE está configurado para modelos IFC e documentos, mas o IDS não foi incluído no fluxo de estados.

1. 1

   Aceite com versão errada · a entrega foi aceita com IDS desatualizado. O critério aplicado não é o vigente. O aceite é questionável.

2. 2

   Disputa sem referência · contratante e fornecedor usam versões diferentes do IDS. Sem versão controlada, não há como arbitrar.

3. 3

   Alteração sem registro · alguém mudou o IDS e não registrou. A equipe não sabe que os critérios mudaram.

4. 4

   Auditoria impossível · sem trilha de versão, não há como provar qual critério valia em qual data para qual entrega.

5. 5

   Retrabalho por versão conflitante · o projetista corrigiu com base em versão anterior. A nova versão exige coisas diferentes. O trabalho se perde.

Curto prazo (30 dias):

1. Publicar o IDS no CDE. Incluir o IDS como contêiner de informação com estado, versão e dono declarado.

2. Designar dono. Nomear formalmente o responsável pelo IDS: quem cria, quem revisa, quem aprova, quem publica.

3. Registrar a versão vigente. Identificar qual versão está em uso, confirmar que é a única, e notificar a equipe.

Médio prazo (60-90 dias):

4. Instituir política de versionamento. Definir convenção de versão, gatilho de atualização, aprovação e notificação.

5. Vincular o aceite à versão. Cada aceite de entrega registra qual versão do IDS foi usada na verificação.

6. Arquivar versões anteriores. Manter histórico de versões com log de alterações para auditoria retroativa.

1. 1

   IDS é contêiner no CDE · o IDS tem estado controlado no CDE: trabalho em andamento, compartilhado, publicado, arquivado. Não circula por e-mail.

2. 2

   Dono declarado · o IDS tem responsável formal. Criação, revisão, aprovação e publicação passam por essa pessoa.

3. 3

   Versão registrada em cada aceite · cada aceite de entrega registra a versão do IDS usada. Sem isso, a auditoria retroativa é impossível.

4. 4

   Log de alterações preservado · cada versão do IDS tem log do que mudou e por quê. Versões anteriores são arquivadas, não deletadas.

• ABNT NBR ISO 19650-1:2022Conceitos e princípios. §3.3.12 define contêiner de informação. §12/§12.1 institui estados de contêiner (trabalho em andamento, compartilhado, publicado, arquivado) e trilha de auditoria. O IDS é contêiner — precisa de estado, versão e trilha.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.6.3 exige verificação da garantia da qualidade antes da troca. Verificação com IDS sem versão controlada não garante qual critério foi aplicado. §6.3.3 exige processos de aprovação documentados e acordados.
• buildingSMART IDS 1.0Information Delivery Specification. O schema IDS tem atributo de versão na raiz. Usar esse atributo com política de versionamento institucional permite rastreabilidade do artefato.
• ISO 29481-3Information delivery manual, Part 3. Formaliza o IDS como especificação de entrega. A gestão do ciclo de vida do IDS — criação, revisão, publicação, arquivamento — não é coberta pela norma e depende da organização.
• ABNT NBR ISO 7817-1:2024Level of information need (LOIN). O LOIN evolui entre fases. Se o LOIN muda, o IDS muda. Sem versionamento, a equipe não sabe se o IDS reflete o LOIN vigente.