Por que a coordenação BIM roda sobre versões diferentes de cada disciplina?

Você federou o modelo de março com o de maio.

A reunião de coordenação abre o modelo federado e começa a apontar interferências. O que ninguém confere é a data de cada contêiner que entrou ali. Arquitetura subiu a versão da semana passada, estrutura mandou por e-mail a de um mês atrás, instalações pescou um arquivo do drive pessoal sem saber de quando é. O federado que está na tela nunca existiu como projeto — é uma colagem de momentos diferentes.

Coordenar sobre isso é decidir sobre um edifício que não existe. A interferência apontada pode já ter sido resolvida na versão nova que ninguém carregou. A que parece resolvida pode voltar, porque a correção estava numa revisão que ficou de fora. E a próxima rodada oficial traz tudo de volta como se fosse novidade.

A ISO 19650 existe justamente para isso não acontecer. Cada informação é um contêiner com estado e código de revisão (§12.1 da 19650-1); os estados distinguem o que está compartilhado (§12.4) do que está publicado (§12.6). Federar para coordenar significa puxar cada disciplina de um estado conhecido do CDE — não do anexo mais recente que alguém achou.

Isto não é o modelo estar deslocado no espaço, que é outra dor da Clínica do IFC. Aqui a geometria de cada disciplina pode estar perfeita. O que está errado é o tempo: cada uma é de uma data.

1. 1

   Ninguém sabe a data de cada contêiner · pergunta-se de quando é o modelo de estrutura na federação e a resposta é um encolher de ombros. A data não viajou junto com o arquivo.

2. 2

   Disciplinas vindas de canais diferentes · uma do CDE, outra do e-mail, outra do drive pessoal. Cada origem, uma versão, sem um estado comum que as una.

3. 3

   A correção sumiu na federação · a disciplina jura que corrigiu, e corrigiu mesmo — só que numa revisão que não foi a carregada na coordenação.

4. 4

   Interferência que ressuscita · o mesmo conflito volta rodada após rodada porque a federação insiste em usar uma versão antiga de uma das partes.

5. 5

   Federado sem registro de composição · não existe uma lista de quais revisões entraram no federado daquela rodada. Reproduzir a reunião depois é impossível.

1. 1

   Federação fora do CDE · os modelos não são puxados de um estado formal do ambiente comum de dados, mas de e-mail, drive pessoal ou transferência avulsa. Sem estado, não há como saber o que é vigente (§5.1.7 da 19650-2).

2. 2

   Estados de informação não usados · o CDE existe, mas ninguém distingue em andamento, compartilhado e publicado (§12.2, §12.4 e §12.6 da 19650-1). Tudo é só arquivo, e o mais recente é uma questão de sorte.

3. 3

   Sem código de revisão por contêiner · os arquivos não carregam código de revisão nem estado (§12.1 da 19650-1), então a data de corte de cada disciplina é invisível na hora de federar.

4. 4

   Rodadas sem data de corte comum · não se combinou até quando cada disciplina publica para entrar na rodada. Cada uma entrega no seu ritmo, e a federação mistura tempos.

5. 5

   Composição do federado não registrada · ninguém anota quais revisões formaram o modelo federado da reunião, então não há a que voltar quando a dúvida surge.

1. 1

   Decisão sobre projeto inexistente · a coordenação resolve, prioriza e atribui sobre uma combinação de versões que nunca foi o projeto real. Boa parte do esforço se perde.

2. 2

   Reincidência estrutural de conflitos · enquanto a federação misturar tempos, a mesma interferência vai voltar toda rodada, sem que a correção jamais pegue.

3. 3

   Correção aplicada sobre versão obsoleta · a disciplina ajusta o arquivo antigo que estava na federação, e o ajuste morre porque a versão vigente é outra.

4. 4

   Rastreabilidade impossível · quando a obra questiona uma decisão, não há como reconstruir qual versão de cada disciplina embasou aquela reunião.

5. 5

   Quantitativo e planejamento contaminados · extrações e sequências construtivas tiradas de um federado desalinhado no tempo carregam o erro adiante, para o 5D e o 4D.

Curto prazo (30 dias):

1. Declarar o CDE como única origem da federação. Nenhuma disciplina entra na coordenação vinda de e-mail ou drive pessoal (§5.1.7 da 19650-2).

2. Exigir estado e revisão em cada contêiner. O modelo que não tem código de revisão e estado não entra na rodada (§12.1 da 19650-1).

3. Fixar a data de corte da rodada. Combinar até quando cada disciplina publica para que a federação seja de um só momento.

Médio prazo (60-90 dias):

4. Registrar a composição de cada federado: a lista de revisões que formaram o modelo daquela rodada, arquivada junto da ata.

5. Usar os estados de informação de fato (§12 da 19650-1): a coordenação parte do compartilhado, a entrega parte do publicado, e ninguém coordena sobre em andamento alheio.

6. Amarrar correção e reexportação: issue só fecha quando a disciplina publica a versão corrigida no CDE, e a rodada seguinte já parte dela.

1. 1

   Federação sempre do CDE · a rotina de coordenação puxa cada disciplina de um estado formal (compartilhado ou publicado), nunca de canal avulso.

2. 2

   Data de corte por rodada · combina-se até quando cada disciplina publica, e a federação passa a ser de um único momento do projeto.

3. 3

   Composição registrada · cada federado guarda a lista de revisões que o formaram, tornando a reunião reproduzível e auditável.

4. 4

   Correção volta ao CDE · nenhuma issue fecha sem a versão corrigida publicada, e a próxima rodada parte dela, não da antiga.

• ABNT NBR ISO 19650-1:2018Conceitos e princípios. §12 define os estados da informação — em andamento (§12.2), compartilhado (§12.4), publicado (§12.6), arquivado (§12.7) — e as transições com portão. §12.1 estabelece o código de revisão e de estado por contêiner e a capacidade de auditar o uso da informação. §3.3.12 define o contêiner de informação.
• ABNT NBR ISO 19650-2:2018Fase de entrega. §5.1.7 exige estabelecer o CDE do projeto e as suas regras, incluindo o controle de versões e o acesso. §5.6.3 exige a verificação da garantia da qualidade antes da troca — o que inclui conferir a consistência da federação usada em coordenação.
• ABNT NBR ISO 16739-1:2024Industry Foundation Classes (IFC). Cada modelo de disciplina é um contêiner geométrico e semântico; a coordenação depende de que todos representem o mesmo momento do projeto para que a federação faça sentido.
• buildingSMART BCF (BIM Collaboration Format)Formato aberto de intercâmbio de interferências. A pendência de coordenação referencia a versão e o elemento sobre os quais foi levantada, ajudando a evitar correção sobre revisão obsoleta.