Meu modelo abre bonito, mas não declara unidade, projeto nem coordenadas — como detectar o que deveria estar e não está?

O modelo IFC chega ao coordenador. Ele abre no visualizador. Aparece bonito na tela. Geometria coerente, disciplinas federadas, renderização aceitável. Nenhum erro vermelho. Nenhum aviso amarelo. Aparente completude. O coordenador aprova a entrega. Duas semanas depois, quando o modelo entra em fluxo real — cálculo de área pra memorial descritivo, federação com estrutura, exportação pra CMMS, análise de acessibilidade — descobre-se que o modelo não declara em que unidade suas medidas estão (IfcSIUnit ausente). Não declara em que projeto pertence (IfcProject sem Name preenchido). Não declara onde está no mundo (IfcMapConversion e IfcProjectedCRS ausentes). A hierarquia espacial está incompleta (elementos sem IfcRelContainedInSpatialStructure apontando pra IfcBuildingStorey). Tudo isso invisível na inspeção visual. Tudo isso passou pelo aceite.

Este é o cenário canônico da falha silenciosa em auditoria BIM. Ferramentas genéricas de coordenação (BCF — do inglês BIM Collaboration Format) detectam interferências geométricas — quando dois elementos colidem no espaço. Softwares de visualização detectam inconsistências óbvias — quando algo aparece deslocado do resto. Mas nenhum deles verifica o que deveria estar declarado e não está. A ausência de uma propriedade obrigatória não gera erro no visualizador; gera silêncio. E o silêncio passa despercebido.

O documento de referência do Manzione Certify (motor de auditoria proprietário da Coordenar) formaliza esse princípio como diferencial doutrinário:

"A ausência da declaração é o próprio achado. O Certify não verifica só o que está no modelo — verifica também o que deveria estar e não está. Se o BEP exige um nível de georreferenciamento e o modelo não o declara, a omissão vira não-conformidade explícita. É justamente a classe de falha que passa invisível em qualquer inspeção visual." — Manzione Certify · Documento de proveniência conceitual

A norma técnica que fundamenta essa disciplina existe. A ISO 16739-1:2024 (Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries — Part 1: Data schema) especifica canonicamente o que um container IFC deve declarar pra ser considerado válido — não apenas geometricamente coerente, mas estruturalmente completo. IfcProject como raiz da estrutura de projeto (§5.1.3.51). IfcSIUnit e IfcUnitAssignment como declaração canônica das unidades usadas (§5.1.3.100). IfcSpatialStructureElement como base da hierarquia Projeto › Terreno (IfcSite) › Edifício (IfcBuilding) › Pavimento (IfcBuildingStorey) (§5.1.3.86). IfcMapConversion e IfcProjectedCRS como declaração de georreferenciamento absoluto (§5.1.5). IfcGloballyUniqueId como identidade estável de cada IfcRoot (§5.1.3.44). Nada disso é opcional pra um modelo produzido em conformidade com a norma — mas nada disso é verificado por inspeção visual, e a ausência sistemática passa despercebida projeto após projeto.

A tese central desta página: auditoria BIM séria verifica o que deveria estar declarado, não apenas o que está. O piso universal inegociável — o mínimo que qualquer modelo BIM tem que atender pra ser processável, federável, auditável — não pode ser deixado à sorte da inspeção visual. Precisa de método normativo automatizado, executável por rule engine sobre o IFC, com veredito objetivo. Sem esse piso declarado como requisito e verificado como gate técnico, todo o resto da cadeia BIM opera em cima de container instável — e o custo aparece downstream, na federação que quebra, no CMMS que não importa, na extração de quantitativo que diverge, no handover que não acontece.

1. 1

   Modelo aceito na coordenação e rejeitado no primeiro uso real · coordenador aprova entrega no visualizador; duas semanas depois, quando o modelo é usado pra federação, extração ou análise, descobre-se que unidade não está declarada, projeto está com Name vazio, hierarquia espacial incompleta. Aceite formal foi cego pra ausências estruturais.

2. 2

   IFC federado com fator 1000 de deslocamento silencioso · container A declara `IfcSIUnit` como milímetros, container B não declara nada e o software de coordenação assume metros por default. Na federação, um dos modelos aparece 1000× maior — mas nenhum alerta apareceu porque não houve erro, houve omissão.

3. 3

   Modelo sem `IfcProject.Name` preenchido · a raiz da estrutura de projeto existe como entidade (IfcProject) mas o atributo Name está vazio ou com valor default do software de autoria ("Project Number"). Coordenador não nota porque o visualizador mostra o projeto normalmente. Documentação e handover downstream ficam sem identificação de projeto.

4. 4

   Elementos órfãos sem `IfcRelContainedInSpatialStructure` · paredes, portas, componentes MEP que não têm relação de containment espacial declarada. Aparecem no visualizador (têm geometria e posição), mas não estão hierarquicamente localizados no pavimento correto. Consulta filtrada por pavimento omite esses elementos silenciosamente.

5. 5

   Modelo sem georreferenciamento (`IfcMapConversion` ausente) · BEP exige georreferenciamento absoluto (obra pública com fiscalização, projeto de infraestrutura, integração com GIS). Modelo entregue não declara `IfcMapConversion` nem `IfcProjectedCRS`. Coordenador não vê ausência porque visualizador funciona sem essa informação — mas integração com GIS descobre no momento crítico.

6. 6

   Modelo em IFC2x3 sendo auditado como se fosse IFC4x3 · auditor aplica regras de georreferenciamento canônico (`IfcMapConversion` foi introduzida no IFC4) sobre modelo entregue em IFC2x3. Regra falha porque o schema não tem a entidade — mas o modelo poderia estar em conformidade com o piso IFC2x3. Auditoria mal calibrada reprova por algo que não podia ser testado, ou aprova por não conhecer o gap.

7. 7

   `IfcUnitAssignment` declara unidades mas valores dos elementos usam outra escala · container declara `LENGTHUNIT` como milímetros, mas paredes têm valores geométricos em metros (números pequenos que só fariam sentido se fossem em metros). Divergência entre declaração e valor real do dado. Ninguém verifica — coordenador confia na declaração, software 5D confia na declaração, ambos calculam errado.

8. 8

   Modelo sem `IfcGloballyUniqueId` estável entre revisões · cada rodada de exportação IFC gera GUIDs novos pros mesmos elementos (bug de mapeamento de identidade no software de autoria, ou modelador que deleta e refaz em vez de editar). BCF apontando pra elementos da rodada anterior fica órfão. Rastreabilidade entre revisões colapsa. Ver a página irmã da Clínica do IFC sobre BCF órfão.

9. 9

   Handover BIM → CMMS/CAFM falha porque modelo não tem propriedades operacionais declaradas · BEP exigiu handover pro CMMS na operação. Modelo entregue foi visualmente ok — arquitetura completa, MEP detalhado. Mas equipamentos MEP não têm `Pset_Manufacturer`, `Pset_Warranty`, `Pset_ServiceLife` declarados. Ausência sistemática invisível no visualizador — CMMS não importa. Ver a página irmã da Clínica Digital Twin sobre handover.

10. 10

    Coordenador BIM entrega laudo "modelo ok" sem ter verificado piso universal · laudo escrito à mão em Word/planilha, baseado em inspeção visual + relatório de clash detection. Nunca verificou se o modelo declara unidade, projeto, hierarquia. "OK" tem escopo indefinido — quando questionado meses depois, coordenador não consegue defender o que testou porque não testou o piso.

11. 11

    Auditor externo pede evidência de verificação normativa e recebe screenshot · auditor pergunta "como você garantiu que o modelo declara unidade canônica?" — resposta é screenshot do Solibri mostrando o modelo aberto. Não é evidência auditável. Rule engine que executa verificação por regra normativa produz relatório reproduzível; inspeção visual não.

12. 12

    Modelos de disciplinas diferentes usando unidades diferentes na mesma federação · arquitetura em milímetros, estrutura em metros, hidráulica em centímetros. Cada software de autoria default diferente, ninguém padronizou no BEP. Federação junta os três — resultado geométrico é catástrofe silenciosa. `IfcUnitAssignment` divergente entre containers é sintoma detectável, mas ninguém verifica.

13. 13

    `IfcSite.RefLatitude` e `RefLongitude` ausentes ou default · georreferenciamento aproximado (equivalente ao IFC2x3) não foi declarado — modelo entregue tem site sem coordenadas geográficas, ou com coordenadas 0.0 default do software. Análise de energia, orientação solar, integração com mapa municipal — todos falham silenciosamente.

1. 1

   **Causa 1 · Auditoria BIM baseada em inspeção visual, sem verificação normativa** · o método canônico brasileiro pra "auditoria BIM" ainda é dominado pela inspeção humana no visualizador. Coordenador abre o modelo, gira, procura por interferências óbvias, aprova. Nenhuma verificação sobre o que o modelo declara — porque inspeção visual não vê ausência, só vê presença. Ferramenta de rule engine capaz de verificar declarações (Solibri, buildingSMART IDS, IDS Auditor, ACCA usBIM.IDS, IfcOpenShell, ou motor proprietário como Manzione Certify Hub) raramente é institucionalizada como gate técnico obrigatório.

2. 2

   **Causa 2 · BEP não declara piso universal como requisito verificável** · a §5.1.4 c) da ABNT NBR ISO 19650-2:2022 exige que a parte requerente estipule "o método de atribuição para o nível de informação necessária". Muitos BEPs no mercado brasileiro tratam o "nível de informação" como LOD/LOI genérico, sem descer ao piso universal — `IfcProject.Name` preenchido, `IfcSIUnit` declarada, hierarquia espacial completa, georreferenciamento quando exigido. Sem declaração explícita no BEP, o modelador não tinha requisito pra garantir — e nada foi verificado no aceite.

3. 3

   **Causa 3 · Software de autoria exporta IFC com defaults que geram ausências invisíveis** · Revit, ArchiCAD e outros softwares BIM têm configurações padrão de exportação IFC que geram containers tecnicamente válidos mas com propriedades canônicas ausentes ou com valores default. `IfcProject.Name` vem com "Project Number" ou "0001". `IfcSite.RefLatitude` vem como 0.0. `IfcUnitAssignment` vem com unidade default do software (metros, mesmo em projeto brasileiro que trabalha em milímetros no autoria). Modelador não intervém porque a exportação "funciona" — visualizador abre, coordenador aprova. Ausência estrutural gerada sistematicamente por default de ferramenta.

4. 4

   **Causa 4 · Ausência de gate técnico contratual com rule engine antes do aceite formal** · a Cláusula 7 da ABNT NBR ISO 7817-1:2024 institui que o LOIN deve ser especificado de forma que suporte processos de verificação e validação, manuais ou automatizados. A §5.6.3 da 19650-2:2022 institui rejeição do container que falhar na verificação. Sem gate técnico institucionalizado (rule engine executado antes do aceite formal), essas cláusulas ficam declarativas — o aceite formal continua cabendo no juízo do coordenador na frente do visualizador.

5. 5

   **Causa 5 · Nenhuma IDS existente pra verificar piso universal** · IDS (Information Delivery Specification, ISO 29481-3) é o formato canônico pra codificar requisitos de container BIM em regras verificáveis por rule engine. Muitas organizações que adotaram IDS a usam apenas pra verificar propriedades customizadas em elementos específicos ("cada IfcDoor deve ter FireRating"). Poucos escrevem IDS pra verificar o piso universal ("IfcProject deve ter Name preenchido", "IfcSIUnit deve ser declarado no IfcUnitAssignment", "cada IfcElement deve ter IfcRelContainedInSpatialStructure apontando pra IfcBuildingStorey", "IfcMapConversion deve existir quando georreferenciamento é exigido"). Ausência de IDS de piso universal é gap institucional recorrente.

6. 6

   **Causa 6 · Cultura brasileira de "modelo bonito é modelo bom"** · a percepção dominante no mercado ainda equipara qualidade visual a qualidade estrutural do modelo. Renderização caprichada, texturas realistas, animação fluida — tudo isso passa uma sensação de completude que não corresponde à realidade normativa. Modelo pode ter tudo isso E não declarar unidade, projeto, hierarquia, coordenadas — e ninguém percebe até quebrar em uso real. Cultura só muda com institucionalização de gate técnico contratual que force a verificação normativa como pré-requisito de aceite.

7. 7

   **Causa 7 · Coordenador BIM sem formação em schema IFC canônico** · coordenador BIM brasileiro típico foi formado em softwares de autoria (Revit, ArchiCAD, Tekla) e em ferramentas de coordenação (Navisworks, Solibri, BIMcollab). Poucos têm formação profunda em ISO 16739-1:2024 (o schema IFC) — o que significa que não sabem quais entidades são canonicamente exigidas, o que cada uma declara, e como verificar cada uma. Sem esse conhecimento, o coordenador não consegue nem escrever um checklist manual do piso universal — muito menos escrever IDS.

8. 8

   **Causa 8 · Verificação por Uso do Modelo não é aplicada — ferramenta genérica trata tudo igual** · ferramenta de coordenação/auditoria genérica aplica os mesmos testes independente do propósito de uso do modelo. Modelo pra "documentação" recebe os mesmos testes que modelo pra "orçamento 5D" ou "handover pra CMMS" — o que não faz sentido normativamente. A Cláusula 5.2 da ABNT NBR ISO 7817-1 exige declaração de propósito; cada propósito tem seu piso próprio de informação canônica. Motor de auditoria calibrado por Uso do Modelo (como o Manzione Certify Hub) executa o conjunto pertinente ao uso declarado; ferramenta genérica ou aplica tudo (reprova por algo irrelevante) ou aplica nada (aprova por não testar o relevante).

9. 9

   **Causa 9 · Ausência de auditoria sistêmica do próprio motor de auditoria** · quem audita o auditor? Ferramenta de auditoria BIM que tem bugs silenciosos — verificação que passa sempre, regra que deveria falhar e não falha, "luz-verde-mentirosa" — não é detectada por ninguém. O usuário confia no laudo porque não tem alternativa. Motor de auditoria maduro precisa ter auditoria sistêmica do próprio código, com casos-teste que caçam ativamente esses padrões. Ausência disso é vulnerabilidade estrutural do processo — a confiança no laudo depende de confiança na ferramenta, e ninguém verifica a ferramenta.

10. 10

    **Causa 10 · Não conhecimento das diferenças entre versões de IFC (2x3 vs 4 vs 4x3)** · auditor que aplica regras de IFC4/4x3 (georreferenciamento canônico via `IfcMapConversion`, coordenadas absolutas via `IfcProjectedCRS`) sobre modelo entregue em IFC2x3 encontra ausência que não é falha do modelador — é limitação da versão de schema. Modelo pode estar em conformidade com o piso IFC2x3 (que usa `IfcSite.RefLatitude/RefLongitude` como georreferenciamento aproximado). Auditor sério declara os limites do que foi medido — inclusive limites impostos pela versão de IFC entregue. Motor mal calibrado promete o que o modelo não permite verificar, e vira frágil.

1. 1

   Aceite formal cego pra ausências estruturais do modelo · coordenador aprova entrega no visualizador; ausências invisíveis não foram testadas nem detectadas. Aceite formal fica sem base normativa auditável — quando questionado meses depois, coordenador não consegue defender tecnicamente o que testou porque nunca testou o piso universal.

2. 2

   Federação BIM quebra silenciosamente em uso downstream · modelos federados com unidades divergentes (arquitetura em milímetros, estrutura em metros), com hierarquia espacial incompleta, com georreferenciamento ausente. Coordenação visual "funciona" — mas primeira análise real (área, quantitativo, energia, GIS) revela o container instável. Custo de retrabalho é sempre downstream, sempre caro, sempre atribuído ao modelador — quando a causa foi ausência de gate técnico upstream.

3. 3

   Handover BIM → operação (CMMS/CAFM/digital twin) impossível · operação recebe modelo pra alimentar CMMS. Modelo tem geometria completa mas equipamentos sem propriedades operacionais declaradas (`Pset_Manufacturer`, `Pset_Warranty`, `Pset_ServiceLife`), sem `IfcGloballyUniqueId` estável entre revisões, sem containment espacial completo. Handover falha, ROI do BIM na operação nunca aparece. Ver as páginas irmãs da Clínica Digital Twin.

4. 4

   Auditoria de compliance em obra pública ou financiada rejeita entrega · órgão fiscalizador ou banco financiador exige rastreabilidade normativa demonstrável. Laudo baseado em inspeção visual não passa — não é reproduzível, não cita norma, não aponta elemento. Perda de qualificação técnica em rodadas competitivas, bloqueio de desembolso, atraso contratual.

5. 5

   Perícia técnica em disputa contratual sem evidência defensável · contratante alega descumprimento do requisito BIM. Contratado alega entrega conforme. Sem laudo objetivo ancorado em norma, com prova por elemento, a disputa vira palavra contra palavra. Auditor tradicional apresenta screenshot; a parte adversária apresenta contra-screenshot; perito não tem base pra decidir. Laudo baseado em rule engine com evidência auditável (elemento + regra + resultado) resolve; laudo baseado em inspeção visual, não.

6. 6

   Bloqueio da progressão pra propósitos avançados (5D, 4D, operação) · todo propósito downstream (BIM 5D, BIM 4D, handover operacional, análise de valor) depende de container BIM auditavelmente válido no piso universal. Se o piso está incompleto, os propósitos avançados operam em cima de container instável. Investimento em BIM 5D/4D/operação nunca amortiza — ROI se dilui em retrabalho.

7. 7

   Reforço do ciclo estrutural que trava adoção madura de BIM no Brasil · cada projeto que aceita inspeção visual como "auditoria BIM" reforça a percepção de mercado de que "BIM no Brasil é imaturo". Percepção falsa (a tecnologia e as normas existem; o gap é institucional) que se propaga — bloqueando adoção madura. Ciclo se auto-sustenta enquanto contratantes não exigirem gate técnico normativo como pré-requisito de aceite.

8. 8

   Custo escondido no ciclo de vida completo do ativo · container BIM com ausências estruturais aceitas na entrega se propaga pra fase operacional — manutenção não consegue consultar modelo, retrofit não sabe quanto material tem instalado, análise de ROI operacional não tem base. Custo cascade que aparece anos depois, atribuído a problemas operacionais, sem que a causa upstream (ausência não detectada no aceite) seja identificada.

9. 9

   "Luz-verde-mentirosa" — aprovação sistêmica por engano · ferramenta de auditoria genérica ou mal calibrada pode passar silenciosamente containers que deveriam falhar. Auditor confia no laudo; contratante confia no auditor; ninguém percebe. Modelo entra em uso real e falha — atribuição de responsabilidade fica difusa. Auditoria sem meta-auditoria do próprio processo é vulnerabilidade estrutural do sistema todo.

10. 10

    Impossibilidade de comparabilidade entre projetos e organizações · sem verificação normativa padronizada do piso universal, cada projeto tem "aceite BIM" com escopo diferente. Comparar qualidade entre fornecedores, benchmark entre organizações, evolução ao longo do tempo — tudo impossível. Ausência de método canônico verificável impede aprendizado sistêmico do setor.

Gravidade 3-4. É gravidade 3 quando o projeto ainda está em fase de projeto (piso universal pode ser corrigido em iteração, rule engine pode ser institucionalizado como gate técnico antes do próximo aceite). Sobe pra 4 quando o modelo com ausências estruturais já foi aceito formalmente e passou pra fase de execução ou operação — nesse ponto, a ausência se propaga pra federação, handover, extração de quantitativo, análise de compliance; correção retroativa exige reabrir modelo, redistribuir responsabilidades, e ROI do BIM prometido já está comprometido. Em obras públicas com fiscalização automatizada, gravidade é sempre 4 desde o início — a verificação normativa do piso universal não é opcional, é condição de qualificação técnica.

Todos os testes abaixo executáveis por rule engine sobre o IFC entregue (Solibri, buildingSMART IDS, IDS Auditor, ACCA usBIM.IDS, IfcOpenShell, Manzione Certify Hub). Baseiam-se nas cláusulas da ISO 16739-1:2024 e da ABNT NBR ISO 19650-2:2022.

O problema é considerado resolvido quando todos os itens abaixo forem verdadeiros, em aderência direta à ISO 16739-1:2024, ABNT NBR ISO 19650-2:2022 e ABNT NBR ISO 7817-1:2024.

Curto prazo (30-60 dias — instaurar verificação normativa no projeto atual):

1. Auditar o container BIM atual contra os 8 testes desta página. Documentar percentuais: presença/ausência de IfcProject.Name, IfcUnitAssignment canônico, hierarquia espacial completa, containment de cada elemento, unicidade de GlobalIds, georreferenciamento declarado quando aplicável. Baseline objetivo antes de qualquer intervenção.

2. Redigir aditivo contratual (ou proposta de aditivo) declarando piso universal como requisito verificável. Aditivo incorpora §5.1.4 c) da 19650-2 operacionalmente — declara método de atribuição do nível de informação necessária, exige IDS de piso universal versionada, institui gate técnico de rule engine antes do aceite.

3. Escrever IDS mínima de piso universal. Codificar em IDS (ISO 29481-3, formato XML da buildingSMART) as regras: IfcProject.Name não-vazio; IfcUnitAssignment declarada com unidades canônicas; hierarquia espacial completa; cada IfcElement com containment; GlobalIds únicos; georreferenciamento declarado quando aplicável. Rodar IDS no modelo atual com IDS Auditor ou buildingSMART IDS pra medir gap objetivamente.

4. Executar auditoria por rule engine antes do próximo aceite formal. Ferramentas canônicas: Manzione Certify Hub (motor proprietário Coordenar, veredito 3-estados com prova por elemento), Solibri Model Checker (regras customizáveis), buildingSMART IDS Reference Implementation, IDS Auditor (open source), ACCA usBIM.IDS, IfcOpenShell/BlenderBIM Ifctester. Relatório arquivado no CDE como evidência auditável.

5. Documentar limites do que foi medido no laudo. Se o modelo é IFC2x3, laudo declara explicitamente que georreferenciamento é aproximado (não IfcMapConversion canônica do IFC4). Se ferramenta auditou piso universal + regras específicas do uso, laudo declara quais testes foram executados e quais foram omitidos. Auditor sério não promete o que não pode verificar.

Médio prazo (60-180 dias — institucionalizar auditoria normativa):

6. Adotar IDS de piso universal como template corporativo. IDS reutilizável entre projetos, versionada em repositório corporativo, atualizada quando ISO 16739-1 atualiza. Cada projeto novo instancia — não escreve do zero. Redução de custo de entrada e uniformização do rigor.

7. Padronizar configuração de exportação IFC nos softwares de autoria corporativos. Revit, ArchiCAD e demais configurados com templates de exportação que garantem IfcProject.Name, IfcUnitAssignment canônico, hierarquia espacial completa. Modelador novo usa configuração calibrada — não gera ausências estruturais por default do software.

8. Institucionalizar rule engine como gate técnico contratual. Nenhuma entrega BIM é aceita formalmente sem passagem por rule engine executando IDS de piso universal. Coordenador BIM não aprova federação que não passa IDS. Relatório automatizado arquivado no CDE como evidência.

9. Reeducar coordenadores BIM em schema IFC canônico. Workshops estruturados sobre ISO 16739-1:2024 — o que cada entidade declara, como verificar cada uma, como escrever IDS pra piso universal. Coordenador BIM que domina o schema consegue institucionalizar a verificação; sem esse domínio, a verificação depende de ferramenta.

10. Auditar sistemicamente o próprio motor de auditoria. Se a organização adota rule engine específico (Solibri, Certify Hub, IDS Auditor), executar periodicamente casos-teste conhecidos que deveriam falhar — pra detectar se o motor tem bugs silenciosos que passam "luz-verde-mentirosa". Manzione Certify é engenheirado com auditoria sistêmica do próprio código como princípio; ferramentas genéricas raramente têm esse rigor institucional.

1. 1

   BEP canônico declara piso universal como requisito verificável · todo BEP corporativo institui piso universal (IfcProject.Name, IfcUnitAssignment, hierarquia espacial, containment, GlobalIds, georreferenciamento quando aplicável) como requisito auditável, com IDS vinculada como anexo. §5.1.4 c) da ABNT NBR ISO 19650-2 operacionalizada — não apenas declaratória.

2. 2

   IDS de piso universal versionada em par com o BEP corporativo · toda entrega BIM tem IDS de piso universal versionada e vinculada ao BEP. Quando o BEP evolui, a IDS evolui. Quando o modelo é submetido, a IDS roda antes do aceite.

3. 3

   Rule engine executado como gate técnico institucional antes de todo aceite formal · nenhuma entrega BIM é aprovada sem passagem por rule engine executando IDS de piso universal. Manzione Certify Hub como ferramenta canônica da Coordenar; alternativas open (Solibri, IDS Auditor, IfcOpenShell). Relatório automatizado arquivado no CDE.

4. 4

   Configuração de exportação IFC padronizada nos softwares de autoria corporativos · Revit, ArchiCAD e demais configurados com templates que garantem preenchimento canônico do piso universal. Modelador novo usa configuração calibrada — não gera ausências estruturais por default.

5. 5

   Auditoria periódica de containers BIM ativos contra piso universal · a cada 3 meses, amostra de containers vigentes é auditada formalmente. Auditoria higiene de processo — mantém método calibrado, detecta desvios cedo.

6. 6

   Coordenadores BIM formados em schema ISO 16739-1:2024 · onboarding de novos coordenadores inclui formação profunda em schema IFC — entidades canônicas, o que cada uma declara, como verificar, como escrever IDS. Sem esse conhecimento, verificação depende de ferramenta e coordenador vira caixa preta.

7. 7

   Laudo de aceite declara escopo do que foi verificado e limites do que não pôde ser · toda entrega BIM produz laudo automatizado que lista: testes executados, testes com resultado APROVADO, testes com resultado REPROVADO, testes com resultado NÃO APLICÁVEL (por limitação da versão de IFC ou por ausência de pré-requisitos). Auditor sério declara escopo — não promete o que não mediu.

8. 8

   Meta-auditoria periódica do motor de auditoria adotado · se a organização adota rule engine específico, executa periodicamente casos-teste conhecidos que deveriam falhar — pra detectar bugs silenciosos que passam "luz-verde-mentirosa". Confiança no laudo depende de confiança na ferramenta; ferramenta precisa ser verificada.

9. 9

   Rastreabilidade elemento↔achado bidirecional no laudo · todo achado do laudo aponta o elemento específico (via GlobalId) + regra normativa + evidência. Rastreabilidade não depende de ferramenta proprietária — laudo é auditável independentemente.

10. 10

    Comparabilidade sistêmica entre projetos e organizações via IDS padronizada · IDS de piso universal reutilizada entre projetos permite comparar qualidade de container BIM entre fornecedores, benchmark entre organizações, evolução ao longo do tempo. Padronização normativa como base do aprendizado sistêmico do setor.

• ISO 16739-1:2024Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries — Part 1: Data schema. Norma canônica do schema IFC. Entidades críticas desta página: `IfcProject` (§5.1.3.51 — raiz da estrutura de projeto), `IfcSIUnit` e `IfcUnitAssignment` (§5.1.3.100 — declaração canônica de unidades), `IfcSpatialStructureElement` (§5.1.3.86 — hierarquia Projeto › Terreno › Edifício › Pavimento), `IfcRelContainedInSpatialStructure` (§5.1.3.63 — containment de elemento em pavimento), `IfcGloballyUniqueId` (§5.1.3.44 — identidade estável de cada IfcRoot), `IfcMapConversion` e `IfcProjectedCRS` (§5.1.5 — georreferenciamento absoluto em IFC4/4x3). Base normativa do piso universal.
• ABNT NBR ISO 19650-2:2022Delivery phase of the assets. Cláusulas críticas: §5.1.4 c) (método de atribuição para o nível de informação necessária — base pra declarar piso universal como requisito verificável), §5.1.7 c) (CDE com atributo de classificação — base pra arquivar evidência auditável), §5.6.2 (não gerar informação supérflua ou incompleta), §5.6.3 (verificar informação do container e rejeitar se falhar).
• ABNT NBR ISO 7817-1:2024Building information modelling — Level of information need — Part 1: Concepts and principles. Cláusula §7 — verification and validation (machine interpretable). Base normativa da exigência de que LOIN seja especificado de forma que suporte processos automatizados de verificação e validação. Cláusula §5.2 (purpose) — base pra calibrar auditoria por propósito de uso do modelo.
• ISO 29481-3Building information models — Information delivery manual — Part 3: Data schema (mvdXML e IDS). Formaliza a Information Delivery Specification (IDS) — ferramenta canônica pra codificar requisitos do piso universal em regras verificáveis por rule engine. Elo central da cadeia LOIN → IDS → BEP → verificação instituída pela §7 da 7817-1 e pela §5.6.3 da 19650-2.
• ABNT NBR ISO 19650-1:2018Parte 1: Conceitos e princípios. Definições canônicas: information container (3.3.12), information model (3.3.8), information exchange (3.3.7). Base conceitual sobre a qual §5.6.2 e §5.6.3 da 19650-2 operam. Framework de gestão da informação.
• ISO/IEC 17025General requirements for the competence of testing and calibration laboratories. Norma internacional de disciplina de laudo técnico de laboratório. Base conceitual do veredito de auditoria BIM: laudo tecnicamente defensável, com regras de severidade objetivas (piso reprova, ressalva registra, norma cita fonte), competência do auditor documentada, imparcialidade metodológica. Referenciada explicitamente na documentação de proveniência do Manzione Certify como fonte da disciplina de veredito.
• buildingSMART IDS 1.0buildingSMART International — Information Delivery Specification (release oficial junho/2024). Facets: Entity, Attribute, Property, Classification, Material, PartOf. Base técnica pra escrever IDS de piso universal verificável em rule engine open source (Ifctester, ACCA usBIM.IDS, IDS Auditor).
• Manzione Certify · Documento de proveniência conceitualDocumento didático interno da Coordenar formaliza princípios canônicos do motor de auditoria proprietário: (a) veredito 3-estados com regra de severidade tipo ISO/IEC 17025; (b) piso universal inegociável (IfcProject, IfcSIUnit, hierarquia espacial, GlobalId, coordenadas); (c) verificação por Uso do Modelo (8 usos canônicos); (d) "a ausência da declaração é o próprio achado" — verifica também o que deveria estar e não está; (e) rastreabilidade até o elemento via IfcGloballyUniqueId; (f) laudo assinado criptograficamente (Ed25519 + SHA-256), não-repúdio; (g) blindagem contra "luz-verde-mentirosa" via auditoria sistêmica do próprio código; (h) escopo declarado (edificação convencional — Certify Infra fora do escopo). Documento não contratual; catálogo canônico vigente em `config/references/test_catalog.yaml` do produto.