Estados do Contêiner Informativo ISO 19650: WIP, Compartilhado, Publicado, Arquivado – Guia Completo

Quem trabalha com um CDE conforme a ISO 19650 acaba se deparando, mais cedo ou mais tarde, com uma pergunta aparentemente banal: “em que estado está este arquivo?”. A resposta não é técnica. É normativa, contratual, operacional.

Os estados do contêiner informativo são as quatro fases do ciclo de vida de uma informação de projeto definidas pela norma ISO 19650: Work in Progress (WIP), Shared, Published, Archived. Cada estado determina quem pode ver, modificar e utilizar o contêiner informativo, com regras de transição rastreadas e autorizadas.

Compreender como funcionam esses estados é o passo chave para transformar um CDE de um simples arquivo em ferramenta de governança. Neste artigo, explicamos em detalhe o que significa cada estado, como ocorrem as transições e como um CDE evoluído gerencia operacionalmente esses passos.

Se você não leu nosso artigo introdutório sobre o CDE conforme a ISO 19650, recomendamos que comece por lá: aqui entramos no detalhe operacional de um dos seus aspectos mais técnicos.

O ciclo de vida do contêiner informativo: quatro estados, um processo

A ISO 19650-1 (§12) define quatro estados principais que cada contêiner informativo atravessa durante o projeto. Não se trata de uma sequência rígida: um contêiner pode voltar a estados anteriores se forem encontradas deficiências, e nem todos os contêineres chegam até a arquivação ao mesmo tempo.

Os estados são:

• Work in Progress (WIP) – em elaboração interna à equipe que produz o conteúdo;
• Shared – compartilhado com outras equipes ou disciplinas para coordenação;
• Published (ou Published for use) – publicado e aprovado para uso contratual;
• Archived – arquivado como referência histórica.

Cada estado é caracterizado por quatro elementos: quem tem acesso ao contêiner, o que pode fazer, como ocorre a transição para o próximo estado, por que o contêiner se encontra nessa fase.

O esquema geral do ciclo

A transição entre estados ocorre através do processo CRA (Check, Review, Approve) – verificação, revisão e aprovação – normatizado pela ISO 19650-2. Cada transição deixa um rastro no audit trail do CDE.

Esquema geral do ciclo dos estados de um CDE

Estado 1 — Em desenvolvimento/Work in progress (WIP): a área de trabalho da equipe

O Trabalho em Andamento é o estado inicial de cada contêiner informativo. É o espaço onde a equipe que produz o conteúdo – tipicamente uma Task Team na terminologia ISO 19650 – trabalha livremente sem expor o material a outros.

Quem acessa o WIP

Somente os membros da Task Team que está produzindo o contêiner informativo. Outras disciplinas, o cliente, o verificador, as outras equipes não têm visibilidade sobre o conteúdo em WIP.

O que pode ser feito

No WIP, a equipe mantém o pleno controle operacional sobre o contêiner informativo, com a liberdade de:

• criar, modificar, excluir conteúdos livremente;
• testar soluções, iterar, cometer erros;
• colaborar internamente na equipe sem formalidades;
• associar metadados preliminares, mas ainda não definitivos.

Características operacionais

O WIP é o único estado em que o contêiner informativo pode ser excluído (antes da compartilhamento formal). Uma vez que o contêiner passa para Shared, cada modificação produz uma nova revisão rastreada.

Código de adequação típico

O código de adequação associado é geralmente S0 (Status inicial) ou equivalente, que indica que o contêiner ainda não foi submetido a verificação interna.

A transição para Shared

Quando a Task Team considera que o contêiner está pronto para ser compartilhado com outras disciplinas, inicia o processo de check interno (auto-verificação técnica). Somente após a verificação positiva o contêiner pode transitar para Shared. Esta transição é normalmente autorizada pelo Task Team Manager ou pelo BIM Coordinator.

Estado 2 — Shared: o compartilhamento para coordenação

O estado Shared marca a transição do uso interno para o uso interdisciplinar. O contêiner agora é visível para as outras equipes de projeto e para o Lead Appointed Party (o sujeito coordenador de toda a encomenda informativa).

Quem acessa o contêiner Shared

Quando um contêiner passa para o estado Shared, sua visibilidade se estende a:

• a Task Team que o produziu (com direitos de modificação limitados);
• as outras Task Teams do projeto (em leitura, para coordenação);
• o Lead Appointed Party (para revisão e verificação);
• o cliente (Appointing Party) dependendo das regras do Capitolato Informativo.

O que pode ser feito

No estado Shared, o contêiner informativo se torna uma ferramenta de coordenação entre disciplinas, portanto pode ser utilizado para:

• consultar o contêiner para atividades de coordenação;
• anotar, comentar, abrir questões (tipicamente via BCF);
• verificar coerência, detecção de conflitos, coordenação disciplinar;
• solicitar modificações à Task Team produtora por meio do processo formal.

No estado Shared, o conteúdo não pode ser usado para construção ou para decisões contratuais: é material de coordenação, não material publicado.

Códigos de adequação típicos

O estado Shared prevê diferentes códigos de adequação dependendo do propósito do compartilhamento:

• S1 – Adequado para Coordenação;
• S2 – Adequado para Informação;
• S3 – Adequado para Revisão Interna e Comentários;
• S4 – Adequado para Aprovação de Fase;
• S6/S7 – Adequado para Autorização PIM / Autorização AIM.

Cada código tem implicações contratuais e operacionais diferentes, e deve ser coerente com a fase do projeto.

A transição para Published

Se o contêiner passar pelo processo de verificação e aprovação (Check, Review, Approve) conduzido pelo Lead Appointed Party e/ou pelo Appointing Party, transita para Published. Se, por outro lado, forem encontradas não conformidades, o contêiner retorna para WIP com as indicações de correção (rework loop).

Estado 3 — Published: o recipiente aprovado para uso

O estado Published marca a aprovação oficial do recipiente informativo por parte da Appointing Party (o contratante). A partir deste momento, o recipiente tem valor contratual e pode ser utilizado para as decisões operacionais do projeto — projeto executivo, construção, testes, gestão.

Quem acessa o Published

O acesso em leitura é tipicamente estendido a todos os envolvidos no projeto, de acordo com as regras do Capitolato Informativo. Os direitos de modificação são, por outro lado, extremamente limitados: um recipiente Published não pode ser modificado diretamente. Qualquer alteração requer a abertura de uma nova revisão, que reinicia o ciclo a partir do WIP.

O que se pode fazer

Uma vez alcançado o estado Published, o recipiente informativo assume um papel diferente em relação às fases anteriores e pode:

• utilizar o recipiente para atividades contratuais, construção, gestão;
• consultar de forma definitiva e autoritária;
• citar em documentos contratuais e comunicações formais;
• NAO modificar diretamente: é necessário abrir uma nova revisão.

Códigos de adequação típicos

• A1-AN – Authorized for [scope] (autorizado para um propósito específico);
• B1-BN – Partially signed-off (parcialmente aprovado, com reservas);
• CR – As Constructed Record (registro do construído);
• PR – Published Record (publicação final de arquivo).

O código especifica o âmbito de uso autorizado: por exemplo, A1 pode significar “Authorized for Construction”, CR “As-built record”, etc.

Códigos de revisão

Paralelamente aos códigos de adequação, as revisões do recipiente são rastreadas com códigos de revisão:

• P01, P02, P03… – revisões na fase de projeto (Pré-construção)
• C01, C02, C03… – revisões na fase de construção (Construção)

A combinação de código de adequação e código de revisão identifica de forma única o estado semântico do recipiente: “S2-P03” significa “adequado para informação, terceira revisão pré-construção”.

A transição para Archived

Ao término do uso operacional do recipiente informativo – tipicamente ao final da fase do projeto ou ao final do contrato – o recipiente é arquivado. Isso não significa removê-lo: significa congelá-lo em um estado de leitura permanente.

Estado 4 — Archived: a referência histórica imutável

O estado Archived conserva o recipiente informativo como referência histórica. É o estado final do ciclo de vida, mas não implica obsolescência: ao contrário, representa a memória autoritária do projeto.

Quem acessa o Archived

O acesso é tipicamente garantido em leitura a todos os que tinham direito de visibilidade sobre o recipiente Published. O arquivamento não elimina os direitos de consulta, mas bloqueia qualquer modificação.

O que se pode fazer

No estado Archived, o recipiente informativo perde toda função operacional ativa e é mantido como evidência estável do percurso informativo do projeto, onde se pode:

• consultar o recipiente para referência histórica, auditorias, contenciosos;
• exportar para transferências a sistemas terceiros (ex. CAFM na fase de Facility Management);
• NAO modificar, NAO excluir: o recipiente está congelado.

Por que o arquivamento é crítico

Do ponto de vista normativo e contratual, o estado Archived é a evidência objetiva do que foi produzido, aprovado e utilizado durante o projeto. É a base documental para:

• Auditorias de conformidade (ISO 9001, ISO 19650-5, segurança)
• Contenciosos contratuais entre contratante e partes contratadas
• Verificações de terceiros (testadores, órgãos de controle)
• Transferência informativa para o Facility Management (handover)
• Avaliação ambiental pós-construção (LCA, verificação de EPD).

Como um CDE evoluído gerencia operacionalmente os estados

A norma descreve os estados, mas é a plataforma CDE que os torna operacionais. Os comportamentos que diferenciam um CDE maduro de uma solução de armazenamento em nuvem dizem respeito precisamente à gestão dos estados.

Visualização clara do estado

Cada recipiente informativo deve exibir de forma imediata e não ambígua seu estado atual, com etiquetas textuais. Um CDE evoluído oferece vistas filtráveis por estado, de modo que o CDE Manager possa monitorar em tempo real a distribuição dos recipientes ao longo do ciclo.

Transições reguladas por workflow

A passagem entre estados não ocorre por ação arbitrária: é o resultado de um workflow estruturado que o CDE ativa automaticamente. O workflow identifica os envolvidos (por função ou por usuário), notifica-os, coleta as aprovações e registra a transição no audit trail.

Uma plataforma CDE evoluída permite configurar workflows diferentes para diferentes tipos de recipientes: um modelo IFC estrutural seguirá um workflow diferente de um documento contratual, e um CDE maduro permite definir esses fluxos de forma granular.

Permissões condicionadas ao estado

O acesso e as ações permitidas dependem do estado: um usuário pode ter direitos de modificação sobre o recipiente em WIP, mas apenas de leitura quando passa para Shared. O CDE deve gerenciar essa matriz de permissões dinâmica de forma automática, sem exigir intervenções manuais a cada transição.

Versionamento coerente com os estados

Cada transição de estado pode gerar uma nova versão do recipiente. Em particular, o retorno de Shared para WIP após uma revisão gera uma nova versão do conteúdo, mantendo a anterior visível como referência histórica. Quando uma revisão é carregada, o workflow em andamento na versão anterior é interrompido no estado em que se encontra e permanece consultável como arquivo do processo. Na nova versão, pode iniciar um novo processo coerente com o conteúdo atualizado.

Formulários associados aos estados

Um CDE evoluído permite associar formulários estruturados (checklists, fichas de verificação, validações técnicas) aos estados do recipiente. Um formulário pode ser preenchível apenas quando o recipiente está em Shared, ou se tornar obrigatório antes de autorizar a passagem para Published. Isso permite condicionar as transições à coleta de dados estruturados, não apenas a uma aprovação genérica.

Códigos de adequação: o guia de referência

Os códigos de adequação são o complemento semântico dos estados. Enquanto o estado diz “onde” está o recipiente no ciclo, o código de adequação diz “para o que” é adequado naquele momento.

Tabela completa dos códigos de adequação ISO 19650

Nota sobre a variabilidade

Os códigos de adequação aqui listados são os recomendados pelos padrões UK BIM Framework e amplamente adotados como referência internacional. A ISO 19650 não impõe os códigos exatos: cada organização ou projeto pode adotar sua própria convenção, desde que definida no Capitolato Informativo.

Códigos de revisão: a rastreabilidade das versões

Além dos códigos de adequação, os códigos de revisão rastreiam a versão do recipiente. A convenção mais comum:

• P01, P02, P03… para revisões na fase de projeto (pré-construção);
• C01, C02, C03… para revisões na fase de construção (construção);
• algumas organizações adicionam D01 para as revisões após a entrega ao cliente (deployed).

A combinação “Adequação – Revisão” (ex. “S2 – P03”, “A1 – C02”) identifica de forma única o estado semântico do recipiente em um momento específico.

Como são geridos no CDE

Um CDE evoluído gera automaticamente os códigos de revisão, incrementando-os a cada nova versão, evitando erros de nomenclatura manual. O sistema também deve impedir a “reutilização” de códigos já usados (ex. pular de P01 para P03 sem passar por P02), para manter a coerência e rastreabilidade.

Erros comuns na gestão dos estados

Após anos de implementação do CDE em projetos AEC, emergem alguns erros recorrentes que é bom conhecer para evitá-los:

• Confundir Shared com Published: Shared não é publicado. Não tem valor contratual, não pode ser usado para decisões operacionais, não justifica a construção. Usar um recipiente Shared como se fosse Published é uma das causas mais frequentes de contenciosos.
• Pular a fase Shared: algumas equipes carregam diretamente recipientes em estado Published sem passar por Shared. Isso elude o processo de coordenação interdisciplinar e pode levar a conflitos não detectados, incongruências entre disciplinas, falta de alinhamento aos requisitos informativos.
• Tratar o arquivamento como cancelamento: o recipiente arquivado não deve ser cancelado: deve ser congelado em modo somente leitura. A eliminação definitiva pode violar obrigações de conservação contratuais e normativas, e comprometer a capacidade de defesa em caso de contencioso.
• Modificar diretamente o Published: um recipiente Published não pode ser modificado; cada mudança requer uma nova revisão que percorre o ciclo. Modificar “silenciosamente” um recipiente Published (frequentemente para “pequenas correções”) anula a rastreabilidade e mina a validade de todo o processo informativo.
• Permissões não coerentes com o estado: permitir que uma Task Team modifique livremente um recipiente Shared, ou pior, Published, de outra disciplina é um erro grave de configuração do CDE. As permissões devem ser condicionadas ao estado e segregadas por função.

Os 10 requisitos de uma plataforma CDE conforme ISO 19650

A gestão correta dos estados é apenas um dos dez requisitos fundamentais de uma plataforma CDE conforme. Se você está avaliando uma plataforma ou quer verificar a conformidade da que está usando, preparamos uma ferramenta gratuita:

Experimente o simulador interativo dos estados — Visualize o ciclo de vida do recipiente informativo, clique em cada estado para descobrir permissões, atores, códigos e transições. Ideal para formação da equipe e integração de novos usuários.

O CDE como ecossistema: a gestão de estados nas plataformas reais

As plataformas CDE avançadas implementam a gestão de estados com modalidades que vão além da mera etiquetagem. No ecossistema usBIM da ACCA, por exemplo, usBIM.platform — o CDE em conformidade com a ISO 19650 — gere os estados do contentor informativo como elementos ativos do workflow, com transições reguladas, visualização clara do estado de progresso e rastreabilidade completa.

Em torno do usBIM.platform, o ecossistema oferece ferramentas específicas para as atividades realizadas nos diferentes estados:

• No WIP, a equipe utiliza o usBIM.editor para editar arquivos IFC e pode vincular arquivos BIM e arquivos de documentos (PDF, DWG, Word, Excel, PowerPoint) diretamente ao modelo BIM;
• no Shared, entram em ação usBIM.clash para a coordenação, usBIM.bcf para o issue tracking interdisciplinar, usBIM.compare para a comparação entre revisões, usBIM.federation para a federação dos modelos disciplinares;
• para a qualidade da informação que condiciona a passagem ao estado Shared e Published, intervém usBIM.dataquality com a validação IDS de acordo com os requisitos do Caderno de Encargos Informativo;
• no Published e no Archived, a plataforma garante acesso apenas de leitura, audit trail completo, versionamento coerente e exportação para sistemas downstream (ex. usBIM.maint para Facility Management na fase de handover).

O valor reside no facto de que os estados não são apenas geridos pela plataforma, mas orquestrados com as aplicações especializadas: cada estado ativa automaticamente as ferramentas e os workflows apropriados, reduzindo o risco de erros operacionais.

Perguntas frequentes (FAQ)

O que são os estados do contêiner informativo?

Os estados do contêiner informativo são as quatro fases do ciclo de vida de uma informação de projeto definidas pela ISO 19650: Work in Progress (WIP), Shared, Published, Archived. Cada estado determina quem pode ver, modificar e utilizar o contêiner, com regras de transição rastreadas e autorizadas.

Quais são os quatro estados ISO 19650?

Os quatro estados são: Work in Progress (WIP), em trabalho interno à equipe; Shared, compartilhado para coordenação interdisciplinar; Published, aprovado para uso contratual; Archived, arquivado como referência histórica imutável.

O que significa WIP no CDE?

WIP (Work in Progress) é o estado inicial do contêiner informativo, onde apenas a equipe produtora (Task Team) tem acesso. Neste estado, é possível modificar e excluir livremente o conteúdo. É o único estado em que o contêiner pode ser eliminado antes da compartilhamento formal.

Qual é a diferença entre Shared e Published?

O contêiner Shared é compartilhado entre disciplinas para coordenação, mas não tem valor contratual. O contêiner Published é formalmente aprovado pelo contratante (Appointing Party) e pode ser usado para decisões operacionais, construção, contratualização. Shared não equivale a Published.

O que é o processo CRA?

O CRA (Check, Review, Approve) é o processo de verificação, revisão e aprovação que regula as transições entre os estados do contêiner informativo. É normatizado pela ISO 19650-2 e é o mecanismo pelo qual um contêiner passa de Shared para Published.

Um contêiner Published pode ser modificado?

Não, um contêiner informativo em estado Published não pode ser modificado diretamente. Cada alteração requer a abertura de uma nova revisão que reinicia o ciclo do estado WIP. Isso garante a rastreabilidade e a imutabilidade contratual das versões publicadas.

O que acontece quando uma nova versão de um arquivo é carregada no CDE?

Quando uma nova versão de um contêiner informativo é carregada, a versão anterior é mantida no histórico. Se havia um fluxo de trabalho em andamento na versão anterior, este é tipicamente interrompido no estado em que se encontra e permanece consultável como referência histórica, enquanto na nova versão pode iniciar um novo processo.

O arquivamento no CDE é a mesma coisa que a exclusão?

Não, arquivar um contêiner informativo significa congelá-lo em leitura permanente. Não deve ser excluído: o contêiner arquivado representa a evidência objetiva do que foi produzido e aprovado durante o projeto, e é fundamental para auditorias, contenciosos, transferências para o Facility Management.

Quem autoriza as transições entre estados?

As autorizações dependem da transição: a passagem de WIP → Shared é tipicamente autorizada pelo Task Team Manager ou pelo BIM Coordinator. A passagem de Shared → Published é autorizada pelo Lead Appointed Party e/ou pelo Appointing Party (contratante). A passagem de Published → Archived ocorre de acordo com as regras do Capitolato Informativo, geralmente no final da fase ou do contrato.

O que são os Task Team, Lead Appointed Party e Appointing Party?

São os três níveis de papéis informativos definidos pela ISO 19650-1. O Appointing Party é o contratante que solicita as informações. O Lead Appointed Party é o principal responsável designado (ex. empreiteiro geral) que coordena as outras partes. Os Task Teams são as equipes de trabalho específicas que produzem os contêineres informativos (ex. equipe estrutural, equipe MEP).

Como se gerencia o rework de um contêiner informativo?

Se durante a verificação de um contêiner Shared forem encontradas não conformidades, o contêiner retorna ao estado WIP com as indicações de correção. O Task Team faz as modificações e coloca o contêiner de volta em Shared como uma nova revisão. O ciclo CRA reinicia. Todo o percurso — incluindo o fluxo de trabalho interrompido — permanece consultável no audit trail.

Como se visualizam os estados no CDE?

Uma plataforma CDE evoluída deve mostrar o estado de cada contêiner informativo de forma imediata e não ambígua, tipicamente com códigos de cores, etiquetas textuais e suitability code visíveis diretamente na lista de arquivos. Deve também oferecer vistas filtráveis por estado e um painel de projeto com a distribuição agregada dos estados.

O que acontece se um contêiner nunca alcançar o estado Published?

Nem todos os contêineres chegam a Published. Alguns podem permanecer em WIP ou serem excluídos antes do compartilhamento. Outros podem ser compartilhados, mas depois superados por versões subsequentes que são publicadas em seu lugar. O importante é que o audit trail registre o percurso efetivamente seguido por cada contêiner.

Glossário essencial

Appointing Party – Contratante, sujeito que solicita as informações do projeto.

Archived – Estado final do contêiner informativo: arquivado em leitura como referência histórica.

CDE – Common Data Environment. Ambiente de Compartilhamento de Dados conforme ISO 19650.

Contêiner informativo – Unidade básica de informação no CDE, com metadados estruturados.

CRA – Check, Review, Approve. Processo de verificação, revisão e aprovação.

Lead Appointed Party – Parte encarregada principal, coordenador da contratação informativa.

Published – Estado do contêiner informativo aprovado para uso contratual.

Revision code – Código que identifica a versão do contêiner (P01, P02, C01, C02…).

Rework – Retorno do contêiner ao estado WIP após uma revisão negativa.

Shared – Estado do contêiner compartilhado para coordenação interdisciplinar.

Suitability code – Código de adequação que indica o propósito de uso do contêiner (S0-S7, A1-AN, B1-BN, CR, PR).

Task Team – Equipe de trabalho que produz um contêiner informativo específico.

WIP – Work in Progress. Estado inicial do contêiner, em trabalho interno à equipe.