Voltar ao blog de BIM e IFC
Entrega e ISO 19650 · 2026-08-07 · 10 min
Critérios de aceitação de IFC: como aceitar ou rejeitar um modelo sem discussão
"Este modelo é inutilizável" contra "o modelo está bom" é uma discussão sem fim. Uma tabela de aceitação de uma página, acordada antes da primeira entrega, transforma isso numa checagem de cinco minutos com um resultado documentado.
Critérios de aceitação de IFC: como aceitar ou rejeitar um modelo sem discussão — IFC Viewer Online article cover
Em todo projeto há um momento em que um coordenador abre um modelo entregue, passa vinte minutos descobrindo que ele não pode ser usado, e escreve um e-mail que começa com "infelizmente". O que acontece depois disso depende quase inteiramente de uma coisa: se alguém escreveu, com antecedência, como é uma entrega aceitável.
Se escreveram, o e-mail é curto, factual e incontroverso. Se não escreveram, o e-mail é o primeiro passo de uma negociação sobre de quem são os padrões que valem, e ela vai se repetir em cada marco pelo resto do projeto.
Aceitação é um checklist, não uma opinião
A mudança de mentalidade é pequena e muda tudo. Revisar uma entrega não é avaliar qualidade — é aplicar critérios acordados a um arquivo. Isso tem três consequências que vale a pena explicitar:
- O revisor não precisa de nenhuma autoridade além da tabela acordada. Ele não está julgando a competência de quem fez o modelo; está reportando um resultado.
- Quem fez o modelo consegue prever o resultado antes de entregar. Tudo que é previsível pode ser evitado, que é justamente o ponto.
- A discordância, quando acontece, é sobre os critérios — uma conversa que pode ser tida uma vez, com calma, em vez de todo mês no meio de uma entrega.
Você não pode rejeitar uma entrega por não cumprir um padrão que quem enviou nunca aceitou. Só pode rejeitá-la por não cumprir aquele que os dois aceitaram.
A tabela de critérios de aceitação
Este é o artefato. Dez linhas, uma página, anexada ao BEP ou ao EIR. A terceira coluna está vazia de propósito — o projeto a preenche antes da primeira entrega, e é nesse ato de preencher que o acordo de fato acontece.
| Critério | Rejeitar se… | Posição do projeto |
|---|
| Integridade estrutural | Qualquer constatação de schema ou espacial em severidade erro | Rejeitar / aceitar com nota |
| Health Score | Abaixo do limiar acordado | Limiar: __ /100 |
| Cobertura de checagem | Qualquer checagem reportada como não executada ou falha | Rejeitar / re-execução necessária |
| Estabilidade de identificadores | Rotatividade de GUID acima de uma porcentagem acordada entre revisões | Rotatividade máxima: __ % |
| Nomenclatura | Nome do arquivo não segue a convenção acordada | Rejeitar / renomear e registrar |
| Georreferenciamento | Modelo fora do ponto de referência compartilhado do projeto | Rejeitar |
| Unidades | Unidades de comprimento não métricas | Rejeitar |
| Classificação | Elementos sem referência de classificação | Aplica-se a partir da fase: __ |
| Conjuntos de propriedades | Psets exigidos ausentes para o nível de necessidade de informação declarado | Cronograma de Pset: __ |
| Espaços | Espaços sem nome, nome longo ou área | Aplica-se a partir da fase: __ |
O objetivo dela não é ser rigorosa — é ser decidida. Uma tabela flexível que todos aceitaram vale mais do que uma rigorosa que chegou junto com o e-mail de rejeição.As três primeiras linhas são as que mais pesam, e também são as mais deixadas de fora com frequência. As cláusulas que as colocam no BEP desde o início estão em Cláusulas do BEP que realmente evitam entregas ruins de IFC.
A linha 3 merece sua própria seção: cobertura de checagem
A maioria das tabelas de aceitação verifica os resultados de uma execução de validação. Quase nenhuma verifica se a execução de fato aconteceu, e essa é uma brecha grande o bastante para uma entrega inteira passar por ela.
Uma checagem que não rodou parece exatamente com uma checagem que passou: as duas produzem zero constatações. Um arquivo grande estoura o tempo limite, um worker trava, uma checagem que depende de geometria desiste silenciosamente — e o relatório volta limpo, com um score perfeito. A entrega é aceita, tendo sido verificada só de nome.
| Estado de cobertura | O que significa | Ação de aceitação |
|---|
| Rodou | A checagem foi concluída. Zero constatações significa zero constatações. | Confie no resultado. |
| Não rodou | Foi tentada mas não produziu um resultado — geralmente por tempo limite ou execução cancelada. | Rode de novo antes de aceitar. Nunca leia isso como aprovação. |
| Falhou | A checagem deu erro. | Reporte isso. Um score calculado sobre checagens falhas não é comparável a uma execução limpa. |
Revisando uma entrega em cinco minutos
- Abra o contêiner e rode o conjunto de regras do projeto. Menos de um minuto para a maioria dos modelos disciplinares.
- Verifique a cobertura primeiro, os resultados depois. Se algo não rodou, pare — você ainda não tem uma revisão.
- Leia o score contra o limiar, depois as constatações em severidade erro. Todo o resto é uma nota, não um bloqueio.
- Compare com a revisão anterior. As novas constatações são a história; as resolvidas são o comprovante de que a última revisão foi levada em conta.
- Registre o resultado no transmittal ou no comentário da CDE — score, conjunto de regras, cobertura, e qualquer constatação aceita por acordo.
O passo 1 é a mesma rotina que quem enviou deveria ter rodado antes de entregar; como verificar um modelo IFC antes da entrega mostra isso passo a passo do lado de quem envia. Quando os dois lados rodam as mesmas checagens, a revisão deixa de ser uma inspeção e vira uma confirmação.
Como escrever a rejeição
O tom importa tanto quanto o conteúdo, porque quem recebe o e-mail geralmente já está atrasado e raramente tem culpa pessoal no problema. Três regras: nomeie o critério, não o modelo. Dê a causa, não só o sintoma. Diga o que está bloqueado e por quanto tempo.
Hi {name},
We've run the agreed pre-acceptance check on {filename} (rev {n}) and it
comes back at {score}/100, below the {threshold} we set in clause {x} of
the BEP.
The two findings driving that are:
- {rule id} — {plain description} ({n} elements)
- {rule id} — {plain description} ({n} elements)
Both look like export settings rather than modelling, so they should be
quick — the report is attached with the element references.
We'll hold coordination on this container until the next issue.
Note o que está ausente: qualquer adjetivo sobre o modelo, e qualquer especulação sobre por que aconteceu. Um número, dois identificadores de regra, uma causa provável e uma consequência. É uma mensagem que ninguém precisa se defender, e é por isso que ela gera ação em vez de escalar o conflito.
Quando aceitar um modelo que falhou
Às vezes a resposta certa é sim mesmo assim — a informação ausente está fora do nível de necessidade de informação daquela fase, ou um fornecedor ainda não entregou, ou a alternativa é parar o projeto. Aceitar uma entrega que falhou é uma decisão legítima. Aceitá-la em silêncio não é.
Uma constatação dispensada precisa de três coisas anexadas: um motivo, uma pessoa que concordou, e uma data. Essa é toda a diferença entre uma constatação aceita e uma constatação ignorada, e é o que evita que o mesmo problema seja redescoberto como uma crise duas fases depois.
Essas dispensas pertencem ao transmittal, junto com o relatório e tudo mais que acompanha o contêiner — veja o que entregar junto com um modelo IFC.
Critérios de aceitação de IFC: como aceitar ou rejeitar um modelo sem discussão