Meu modelo BIM é lindo, mas o orçamentista não consegue tirar quantitativo — por quê?

O modelo chega bonito. Federado, coordenado, sem clashes graves, geometria consistente entre disciplinas. O contratante gosta do que vê no visualizador, o BIM Manager fica orgulhoso, o coordenador aprovou a entrega. Uma semana depois o orçamentista abre o mesmo modelo pra extrair quantitativo — e descobre que não há o que extrair. Objetos sem código de material. Portas sem tipo classificado. Paredes sem IfcElementQuantity completo. Pset_WallCommon carregado com LoadBearing e IsExternal — nenhuma propriedade que amarre o elemento a uma composição de custo. A operação de take-off que deveria ser automatizada vira digitação manual, elemento por elemento, planilha Excel de novo.

O que o BIM Manager chama de "modelo pronto" e o orçamentista chama de "modelo vazio" é o mesmo modelo. A discordância não é sobre qualidade — é sobre propósito de uso não declarado. A ABNT NBR ISO 7817-1:2024 (Building information modelling — Level of information need — Part 1: Concepts and principles) resolve essa ambiguidade explicitamente, e a Nota EX4 da Cláusula 6.3.3 é praticamente uma resposta direta a esse cenário:

"For quantity take-off purpose, the information content for all objects can include e.g. a type name, the breakdown structure code and/or volume and area." — ISO 7817-1:2024, §6.3.3, EXAMPLE 4

A norma cita quantity take-off como propósito de uso e enumera as propriedades alfanuméricas mínimas que o modelo deve carregar quando esse é o propósito: type name, breakdown structure code, volume, area. Se essas propriedades não estão no modelo, o modelo simplesmente não foi calibrado pra esse propósito — o LOIN alfanumérico foi omitido no requisito de troca de informação, e o modelador não tinha como saber que precisava embarcar.

O erro não é técnico do modelador. É estrutural da cadeia contratual. A LOIN (do inglês Level of Information Need — Nível de Necessidade de Informação, ABNT NBR ISO 7817-1) é um framework tridimensional (§6.1) com três dimensões independentes: geometrical information (§6.2), alphanumerical information (§6.3) e documentation (§6.4). Modelo "pronto" é modelo com LOIN calibrado por propósito, por elemento, por marco de entrega, por ator. Modelo entregue com LOIN geométrico alto (parede detalhada em 3D com material aparente) e LOIN alfanumérico zero (parede sem código de plano de contas, sem quantitativos estruturados, sem classificação vinculada) é modelo pronto pra visualização — não pra orçamentação.

A cadeia canônica que essa página institui: EIR declara propósito 5D → LOIN alfanumérico calibrado ao propósito (Cláusula 5.2 da 7817-1 exige declaração de propósito) → breakdown structure code embarcado (Nota EX4 da §6.3.3, ancorado em ABNT NBR 15965 no contexto brasileiro) → IDS (do inglês Information Delivery Specification — Especificação de Entrega de Informação, ISO 29481-3) codifica em regra verificável → BEP (BIM Execution Plan) incorpora IDS como anexo vinculante → modelo verificado por rule engine antes do aceite. Sem essa cadeia, o modelo continua bonito e inútil pro 5D.

1. 1

   Modelo aprovado na coordenação e rejeitado no orçamento · a mesma entrega recebe aceite do coordenador (clash detection ok, geometria coerente) e rejeição do orçamentista (não dá pra extrair quantitativo). Sinal direto de LOIN geométrico adequado + LOIN alfanumérico ausente pro propósito 5D. Os dois olham o mesmo IFC — e o gap entre eles é o propósito de uso não declarado no EIR.

2. 2

   `IfcElementQuantity` vazio ou incompleto em elementos que deveriam ter quantitativo · parede sem GrossVolume, sem NetVolume, sem GrossSideArea. Laje sem GrossArea. Viga sem Length. A norma ISO 16739-1:2024 estrutura essas propriedades canonicamente (Pset_WallCommon, Pset_SlabCommon, Pset_BeamCommon) — mas o modelador só preenche o que o EIR pediu explicitamente. EIR sem propósito 5D declarado = quantitativos vazios.

3. 3

   Nenhum objeto tem propriedade de classificação por plano de contas ou SINAPI · o orçamentista abre o modelo e procura por Pset customizado com CódigoSINAPI, CódigoPlanoContas, CódigoTCPO — nada. A NBR 15965 codifica esses campos como classificação estruturada (Tabela 3E Elementos, Tabela 0P Propriedades) — mas se o EIR nunca declarou que o LOIN alfanumérico da entrega inclui breakdown structure code, o modelador não embarcou.

4. 4

   Type name genérico ou ausente em famílias que compõem custos distintos · todas as paredes de alvenaria classificadas como "Wall_Basic" no Revit, sem distinção entre alvenaria de bloco cerâmico, alvenaria de bloco de concreto e drywall — que têm composições SINAPI diferentes. Type name é o primeiro campo que a Nota EX4 da §6.3.3 da 7817-1 exige pro propósito quantity take-off. Type name genérico = agregação impossível.

5. 5

   BEP menciona "LOD 400" ou "LOI alto" mas não diz uma palavra sobre uso 5D · o BEP tem um parágrafo sobre "Nível de Detalhe/Informação" com número global — não distingue geometria de alfanumérica, não menciona quantity take-off como propósito, não amarra propriedade alguma a uso específico. Sintoma clássico do vocabulário LOD substituindo LOIN sem substituir o método (ver a página 'LOIN não é LOD' na Clínica de Gestão da Informação).

6. 6

   Orçamentista mantém planilha paralela de "propriedades que falta no modelo" · a cada projeto novo, o orçamentista abre um Excel e lista o que precisou completar manualmente: código de plano de contas por família, composição SINAPI correspondente, unidade de medição, fator de perda. Conhecimento tácito não retorna pro modelo. Toda re-extração recomeça a planilha.

7. 7

   Modelo tem 40+ Psets customizados mas nenhum contempla propósito 5D · o BIM Manager esforçado carregou Pset_TermalPerformance, Pset_AcousticPerformance, Pset_SustainabilityCertification, Pset_LEED_v4 — tudo relevante pra análises específicas. Nada relevante pra orçamento. LOIN alfanumérico existe, mas nunca foi calibrado pro propósito de uso 5D.

8. 8

   Cliente pergunta "quanto custa esse projeto pelo BIM?" e a resposta é "não dá pra tirar do modelo" · contratante fez o investimento em BIM contando que o modelo alimentaria o orçamento. Descobre no fim do projeto executivo que precisa contratar orçamentação separada, manual, sem uso do modelo. Pergunta se o BIM valeu a pena. Difícil defender o investimento sem evidência de propósito 5D atendido.

9. 9

   Software 5D importa o IFC e mostra a lista de elementos sem valor unitário associado · Vico, iTWO, Cubicost, CostX abrem o IFC, listam os elementos por família, mas cada linha aparece com "Aguardando classificação" ou similar. O software espera que o modelo traga a amarração — e o modelo não trouxe. A ferramenta oferece classificar manualmente ali (ver a página irmã sobre softwares 5D cúmplices).

10. 10

    Não existe data template ISO 23387 referenciado em nenhum entregável · a Cláusula 6.3.1 da 7817-1 recomenda que alphanumerical information seja representada por ou vinculada a data template conforme ISO 23387. Nenhum data template amarrado ao projeto significa que as propriedades são inventadas por projeto — sem reutilização, sem comparabilidade, sem base compartilhada. Para 5D, isso é caro: cada projeto novo reinventa Psets.

11. 11

    Modelo de arquitetura entregue sem classificação alguma, sob argumento "quem classifica é o orçamentista" · papel de arquiteto/coordenador termina no aceite formal — cabe ao orçamentista atribuir a classificação de custo depois. Argumento falso: a Cláusula 5.4 da 7817-1 exige que os atores (information receivers e information providers) sejam declarados no requisito de LOIN. Se o EIR declarou o orçamentista como receiver, é o modelador (provider) quem entrega classificado. Se não declarou, ninguém tinha responsabilidade — e a dor é sistêmica.

12. 12

    `Pset_QuantityTakeOff` mencionado no BEP mas ausente ou vazio no IFC entregue · o BEP referencia bibliotecas de propriedades pra 5D (Pset_QuantityTakeOff, IfcQuantityLength, IfcQuantityArea, IfcQuantityVolume — todos canônicos no schema IFC), mas o modelo entregue não os preenche. Requisito escrito no BEP sem verificação no aceite (§7 da 7817-1 sobre verification and validation) = requisito inexistente na prática.

1. 1

   **Causa 1 · EIR nunca declarou propósito de uso 5D explicitamente** · a Cláusula 5.2 da ISO 7817-1 é explícita: *"the purposes for information delivery shall be considered"*. Cada propósito de uso — visualização, clash detection, quantity take-off, análise energética, operação — exige LOIN calibrado diferente pro mesmo elemento. Se o EIR listou "clash detection" e "coordenação" mas nunca escreveu "quantity take-off" ou "5D" ou "orçamentação" como propósito, o modelador não tinha requisito pra embarcar propriedade alguma além do necessário à coordenação. O modelo entrega o que foi pedido — e nada mais.

2. 2

   **Causa 2 · LOIN aplicado como índice único global, sem separação de dimensões** · o BEP declara "LOD 400 em todas as disciplinas" ou "LOI alto pra estrutura" sem distinguir as três dimensões que a Cláusula 6.1 da 7817-1 institui como independentes: geometrical (§6.2), alphanumerical (§6.3) e documentation (§6.4). Uma parede pode ter LOIN geométrico alto (detalhamento 3D preciso) e LOIN alfanumérico baixo (sem propriedades de orçamento) — a norma permite, mas o índice único obscurece essa combinação. Resultado: LOIN geométrico atendido, LOIN alfanumérico ausente por omissão estrutural.

3. 3

   **Causa 3 · Ausência de breakdown structure code embarcado no modelo** · a Nota EX4 da §6.3.3 da 7817-1 cita "breakdown structure code" como conteúdo canônico pra propósito quantity take-off. No contexto brasileiro, esse código canonicamente adere à ABNT NBR 15965 (Sistema de classificação da informação da construção, 7 partes) — Tabela 3E Elementos (`3E 14 08 02 00 00` para paredes de vedação, por exemplo) ou Tabela 3R Resultados dos trabalhos (`3R 10 30 58 02 00` para revestimento galvanizado cromado). Sem esse código na propriedade estruturada do objeto, a agregação por composição de custo é impossível — o software 5D não tem chave pra amarrar linha de orçamento a elemento.

4. 4

   **Causa 4 · Modelador segue template de família sem calibrar Psets ao propósito 5D** · as famílias-padrão do Revit (e equivalentes) exportam para IFC com Psets padronizados do buildingSMART (Pset_WallCommon, Pset_DoorCommon, etc.) — todos calibrados para propósito geral. Nenhuma família nativa vem com Pset customizado que amarre a família à composição SINAPI ou a código de plano de contas. Sem intervenção deliberada da equipe (biblioteca corporativa padronizada, parâmetros customizados obrigatórios), o modelo entrega Pset padrão — que não serve pra 5D.

5. 5

   **Causa 5 · Data templates ISO 23387 não são adotados institucionalmente** · a Cláusula 6.3.1 da 7817-1 recomenda: *"Alphanumerical information should be represented by or linked to a data template according to ISO 23387."* Data templates são estruturas reutilizáveis de propriedades por tipo de objeto — se a organização mantém biblioteca de data templates conformes ISO 23387 pra suas famílias recorrentes (portas, janelas, paredes, componentes MEP), cada projeto novo instancia essas propriedades automaticamente. Sem data templates institucionais, cada projeto reinventa Psets — e reinventa a omissão do 5D.

6. 6

   **Causa 6 · Software de autoria não sugere propriedades de orçamento por padrão** · Revit, ArchiCAD e outros softwares BIM têm parâmetros nativos calibrados pra design e documentação — comprimento, largura, altura, material aparente, código de tipo interno da família. Nenhum sugere ativamente "código SINAPI", "código plano de contas", "unidade de medição SINAPI". O BIM Manager que quer aplicar LOIN alfanumérico pro 5D precisa criar parâmetros compartilhados customizados, atrelá-los às famílias, garantir preenchimento — trabalho que a ferramenta não facilita.

7. 7

   **Causa 7 · Cadeia LOIN → IDS → BEP → verificação nunca foi implementada** · a cadeia canônica que a 7817-1 (§7 verification and validation) antecipa e que a ISO 29481-3 operacionaliza é: LOIN declarado por elemento e propósito → IDS traduz em regra verificável (`propriedade X deve existir com valor no domínio Y`) → BEP incorpora IDS como anexo vinculante → rule engine (Solibri, buildingSMART IDS, IDS Auditor) executa verificação no modelo antes do aceite. Se qualquer elo dessa cadeia está quebrado, o LOIN alfanumérico pro 5D não é auditado — e não sendo auditado, não é entregue.

8. 8

   **Causa 8 · BEP genérico copiado de template não trata propósito 5D específico** · templates de BEP disponíveis no mercado brasileiro (BIM Fórum, buildingSMART regional, editais anteriores) foram redigidos antes da 7817-1 e tratam LOD/LOI como índice global. Cada projeto novo instancia o template e herda a omissão do propósito 5D. Reescrever o template pra incluir seção específica de "LOIN alfanumérico pra propósito quantity take-off, calibrado por família de objeto, com breakdown structure code exigido" é trabalho estrutural que a maioria das organizações ainda não fez.

9. 9

   **Causa 9 · Orçamentista não participa da definição do EIR** · a Cláusula 5.4 da 7817-1 exige declaração de atores (information receivers e information providers). Se o orçamentista é receiver do modelo pra propósito 5D, deveria participar da definição do EIR — declarando quais propriedades ele precisa, em qual marco, em qual estrutura. Na prática, EIR é escrito por gestor de projeto e BIM Manager sem consulta a orçamentista — resultado: EIR omite requisitos que só o orçamentista sabe articular.

10. 10

    **Causa 10 · Cultura de "modelo é responsabilidade do projetista, orçamento é responsabilidade do orçamentista"** · a divisão de responsabilidade tradicional trata modelo e orçamento como artefatos separados, produzidos por equipes distintas em fases distintas. A promessa do BIM 5D — modelo alimenta orçamento — só se realiza se essa fronteira é explicitamente rompida no requisito de informação. Sem intervenção contratual e cultural, a fronteira sobrevive e o modelo não serve pro orçamento.

1. 1

   Investimento em BIM sem retorno em orçamentação · contratante pagou por modelo BIM contando com o benefício de orçamento automatizado — e descobre que precisa contratar orçamentação manual paralela. ROI do BIM se desloca pra baixo, a promessa comercial se degrada, adoção futura fica desincentivada. A dor é dupla: custo do BIM + custo do orçamento tradicional que o BIM deveria ter eliminado.

2. 2

   Orçamento produzido sem rastreabilidade ao modelo · quando o orçamentista completa manualmente as propriedades ausentes, o resultado é orçamento que não retorna pro modelo. Numa revisão de projeto, o modelo é reeditado — mas a amarração custo↔elemento vive só na planilha do orçamentista. Ao reextrair, tudo se reinicia. Sem rastreabilidade, cada rerodada é retrabalho total.

3. 3

   Impossibilidade de auditar orçamento contra modelo · auditor externo (interno da construtora, órgão fiscalizador em obra pública, banco financiador em obra financiada) pede evidência de que cada linha do orçamento corresponde a elemento auditável no modelo. Se as propriedades de amarração não existem no IFC, a auditoria falha — orçamento vira caixa preta.

4. 4

   Divergência sistêmica entre projeto executivo e orçamento · quando o modelo evolui (mudança de projeto, revisão do executivo, adaptação por incompatibilidade em obra), o orçamento produzido em planilha externa não acompanha automaticamente. A cada revisão, a lacuna cresce. No canteiro, a divergência gera pedido de aditivo, discussão contratual, e retrabalho de compatibilização.

5. 5

   Bloqueio da progressão pra propósitos avançados (5D + 4D + operação) · sem LOIN alfanumérico calibrado no 5D, os propósitos subsequentes ficam também bloqueados. BIM 4D (planejamento com custo) exige amarração custo↔elemento estruturada. Handover pro CMMS/CAFM em operação exige propriedades operacionais — que também dependem de LOIN alfanumérico declarado. Uma omissão upstream trava toda a cadeia downstream.

6. 6

   Perda de competitividade em concorrências que exigem BIM 5D operacional · editais públicos e privados sofisticados começam a exigir demonstração de que o modelo BIM entregue permite orçamentação automatizada — não só entrega de "modelo BIM". Fornecedores que persistem em modelos LOIN geométrico alto/alfanumérico zero perdem qualificação técnica em rodadas competitivas.

7. 7

   Impossibilidade de conformidade normativa em obras públicas · obras públicas brasileiras cada vez mais adotam SINAPI/TCPO como referência obrigatória (Decreto Federal 11.888/2024 sobre BIM em obras públicas e desdobramentos estaduais/municipais). Modelo BIM sem amarração a código SINAPI/TCPO por elemento fica inelegível pra fiscalização automatizada — órgão de controle rejeita o modelo como evidência.

8. 8

   Custo escondido de manter equipe de orçamento paralela · a construtora ou incorporadora que investiu em BIM contando com racionalização da equipe de orçamento descobre que continua precisando da equipe completa — pra completar manualmente o que o modelo não trouxe. Custo estrutural mantido, benefício prometido não realizado.

9. 9

   Vulnerabilidade em disputa contratual sobre "cumprimento do requisito BIM" · se o requisito BIM foi escrito genericamente ("modelo BIM entregue conforme ISO 19650"), o contratado pode alegar que entregou modelo BIM válido — e a ausência de propriedades pra 5D não seria descumprimento. Contratante fica sem base contratual pra rejeitar. Se o requisito tivesse declarado LOIN alfanumérico pra propósito 5D com breakdown structure code obrigatório, a rejeição seria objetivamente ancorada.

10. 10

    Perpetuação da narrativa "BIM não funciona pra orçamento no Brasil" · cada projeto que entrega modelo bonito e inútil pro 5D reforça a percepção de mercado de que "no Brasil não dá pra fazer BIM 5D de verdade". A percepção é falsa (o problema é estrutural do requisito, não da tecnologia) mas se propaga — bloqueando adoção futura e mantendo o setor preso em orçamentação manual.

Gravidade 3-4. É gravidade 3 quando o projeto ainda está em fase de projeto (o requisito pode ser reajustado e as propriedades podem ser adicionadas em iteração), e sobe pra 4 quando a entrega já aconteceu e o modelo passou pra fase de obra — nesse ponto, adicionar propriedades pra 5D exige reabrir o modelo, redistribuir responsabilidades, e o ROI do BIM prometido já está comprometido. Em obras públicas com fiscalização automatizada via SINAPI/TCPO, a gravidade é sempre 4 desde o início — o requisito de amarração normativa não é opcional.

Todos os testes abaixo aplicam-se a qualquer entrega BIM cuja proposta de uso inclua propósito 5D (quantitativos, orçamentação, medição). Baseiam-se nas cláusulas da ABNT NBR ISO 7817-1:2024 e da ABNT NBR 15965 (Sistema brasileiro canônico de classificação da informação da construção).

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

Curto prazo (30-60 dias — reconstruir o LOIN alfanumérico pro 5D):

1. Auditar o modelo atual contra a Nota EX4 da §6.3.3 da 7817-1. Aplicar os Testes 1 a 6 ao projeto vigente. Documentar percentuais: quantos elementos têm type name distintivo, quantos têm breakdown structure code embarcado, quantos têm IfcElementQuantity preenchido. Baseline objetivo antes de qualquer intervenção.

2. Reescrever o EIR incluindo propósito 5D explícito. Adicionar seção "Propósito de uso: quantity take-off / orçamentação". Declarar os quatro pré-requisitos (purpose, milestone, actor, object). Declarar receiver como orçamentista ou equipe de orçamento (nomeada por função ou por empresa contratada). Sem EIR reescrito, nenhuma intervenção downstream se sustenta contratualmente.

3. Adicionar seção específica no BEP: LOIN alfanumérico pra propósito 5D. Seção separada do LOIN geométrico (que já existe). Declarar por família de objeto quais propriedades alfanuméricas são obrigatórias, ancoradas em breakdown structure canônica (NBR 15965 ou SINAPI/TCPO). Sem seção estruturada, LOIN pro 5D fica implícito e omitido.

4. Escrever IDS mínima pro propósito 5D. Codificar em IDS (ISO 29481-3, formato XML da buildingSMART) os requisitos alfanuméricos por família: "cada IfcWall deve ter Pset_CustomBudget.CodigoSINAPI preenchido", "cada IfcSlab deve ter Qto_SlabBaseQuantities.GrossArea calculado". Rodar a IDS no modelo atual com IDS Auditor ou buildingSMART IDS pra medir o gap objetivamente.

5. Adicionar breakdown structure code nas famílias-chave do projeto. Priorizar as famílias que representam maior fração do orçamento (paredes, lajes, vigas, instalações prediais, revestimentos). Adicionar parâmetro compartilhado com código NBR 15965 ou SINAPI correspondente, preencher, exportar pra IFC via mapeamento de Pset customizado. Piloto antes de escalar pra todas as famílias.

Médio prazo (60-180 dias — institucionalizar LOIN alfanumérico pro 5D):

6. Adotar biblioteca corporativa de data templates conforme ISO 23387. Reunir as famílias recorrentes da organização (30-50 tipos que cobrem 80% dos projetos). Redigir data template pra cada uma, incluindo propriedades pra propósitos múltiplos (visualização, clash detection, quantity take-off, operação). Data templates viram base institucional — cada projeto novo instancia, não reinventa.

7. Padronizar biblioteca de famílias corporativa com Psets customizados pro 5D. As famílias-padrão do Revit e equivalentes são atualizadas pra carregar parâmetros compartilhados que exportam pra IFC como Pset customizado (Pset_CustomBudget, Pset_CustomClassification). Modelador novo entra na organização e usa famílias já calibradas — não precisa customizar por projeto.

8. Integrar orçamentista no processo de definição de EIR desde o início. Institucionalizar participação de representante da equipe de orçamento na fase de determinação das necessidades (§5.1 da ABNT NBR ISO 19650-2). Fluxo estabelecido: orçamentista lista propriedades que precisa como receiver, BIM Manager traduz em LOIN + IDS, contratante formaliza no EIR. Sem essa integração cultural, a omissão do 5D permanece sistêmica.

9. Estabelecer rotina de verificação por IDS antes do aceite formal. Cada entrega BIM passa por execução de IDS via rule engine, com relatório automatizado que lista propriedades ausentes ou em desacordo. Aceite formal só acontece após IDS ok — modelo com falhas volta ao modelador. Isso operacionaliza a §7 da 7817-1 no fluxo real.

10. Reeducar equipes internas (modeladores, coordenadores, orçamentistas) em LOIN 7817-1 aplicado ao 5D. Workshops estruturados: por que LOIN substitui LOD, como calibrar por propósito, como escrever LOIN alfanumérico específico pro 5D, como traduzir em IDS. Adoção só escala se equipes compartilham vocabulário e método — não bastam mudanças unilaterais de template.

1. 1

   Todo EIR novo declara propósitos de uso separadamente, incluindo 5D quando aplicável · não há mais EIR redigido sem seção explícita de propósitos de uso. Cada propósito (visualização, clash detection, quantity take-off, análise energética, operação) recebe declaração dos quatro pré-requisitos da Cláusula 5 da 7817-1. LOIN calibrado por propósito — não índice único global.

2. 2

   Biblioteca corporativa de data templates ISO 23387 mantida institucionalmente · a organização mantém biblioteca de data templates atualizada, referenciada em todos os projetos. Novos data templates entram por processo formal (revisão técnica, homologação, versionamento). Sem essa infraestrutura institucional, o LOIN alfanumérico é reinventado a cada projeto — insustentável.

3. 3

   Famílias corporativas padronizadas com Psets pra propósito 5D · biblioteca de famílias Revit/ArchiCAD/equivalente é padronizada com parâmetros compartilhados que exportam pra IFC como Pset customizado calibrado ao 5D (código SINAPI, código plano de contas, unidade de medição, fator de perda). Modelador novo usa família calibrada — não customiza por projeto.

4. 4

   IDS pra propósito 5D versionada em par com o BEP · toda entrega BIM tem IDS pra 5D versionada e vinculada ao BEP. Quando o LOIN alfanumérico do BEP muda, a IDS muda. Quando o modelo é submetido, a IDS roda. Ciclo operacional que a §7 da 7817-1 antecipa e que a ISO 29481-3 formaliza.

5. 5

   Rule engine executado como gate técnico antes de todo aceite formal · nenhuma entrega BIM é aceita formalmente sem passagem por rule engine (Solibri, buildingSMART IDS, IDS Auditor, ACCA usBIM.IDS). Relatório automatizado listando propriedades ausentes ou em desacordo é arquivado no CDE como evidência auditável. Aceite formal só depois de IDS ok.

6. 6

   Orçamentista integrado como information receiver desde a definição do EIR · representante da equipe de orçamento participa da fase §5.1 da ABNT NBR ISO 19650-2 (determinação das necessidades), declarando propriedades que precisa como receiver do modelo pra propósito 5D. Sem essa integração, a omissão do LOIN alfanumérico permanece sistêmica.

7. 7

   Peer review de LOINs alfanuméricos pro 5D por revisor treinado · toda seção de LOIN alfanumérico pro 5D passa por revisão de dupla treinada em 7817-1 + NBR 15965. Ausência de breakdown structure code, ausência de referência a data template ISO 23387, ausência de amarração a IDS — todos são motivo de rejeição imediata em revisão.

8. 8

   Modelo entregue vem sempre com relatório de verificação IDS anexo · cada entrega BIM contém, junto com o IFC, o relatório automatizado da IDS executada. Relatório mostra: propriedades verificadas, aprovadas, rejeitadas; percentual de conformidade; elementos que não passaram. Contratante recebe evidência auditável — não modelo bonito com dúvida sobre conformidade.

9. 9

   Onboarding de novos membros inclui LOIN alfanumérico pro 5D · todo modelador, coordenador e orçamentista novo passa por formação obrigatória em ABNT NBR ISO 7817-1 + ABNT NBR 15965 + ISO 23387, com foco no propósito 5D. Certificação interna baseada em evidência de aplicação prática — não certificado de curso apenas.

10. 10

    Auditoria trimestral de LOINs alfanuméricos vigentes contra a 7817-1 e a NBR 15965 · a cada 3 meses, amostra de LOINs vigentes é auditada formalmente contra as normas. Auditoria higiene de processo — mantém método calibrado, detecta desvios cedo, alimenta melhoria contínua do template corporativo.

• ABNT NBR ISO 7817-1:2024Building information modelling — Level of information need — Part 1: Concepts and principles. Referência canônica desta página. Cláusulas críticas: 5.2 (purpose), 5.5 (breakdown structure), 6.1 (três dimensões), 6.3 (alphanumerical information), 6.3.3 Nota EX4 (quantity take-off cita type name + breakdown structure code + volume + area), 7 (verification and validation). Norma que institui o LOIN como framework tridimensional calibrado por propósito.
• ABNT NBR ISO 19650-2:2022Delivery phase of the assets. Cláusulas §5.1 (Determinação das necessidades — inclusive §5.1.2 EIR e §5.1.4 padrões de informação com método de atribuição para o nível de informação necessária) e §5.2.1 (Definição dos requisitos de informação da parte requerente) — base para incluir propósito 5D no EIR e integrar orçamentista como information receiver.
• ISO 29481-3Building information models — Information delivery manual — Part 3: Data schema (mvdXML e IDS). Formaliza a Information Delivery Specification (IDS) — ferramenta que traduz LOIN alfanumérico em regras verificáveis por rule engine. Elo central da cadeia LOIN → IDS → BEP → verificação instituída pela §7 da 7817-1.
• ISO 23387:2020Building information modelling (BIM) — Data templates for construction objects used in the life cycle of built assets — Concepts and principles. Referenciada explicitamente pela Cláusula 6.3.1 da 7817-1 como base pra alphanumerical information. Data templates dão reutilização institucional das propriedades — sem eles, o LOIN alfanumérico é reinventado a cada projeto.
• ABNT NBR 15965-1:2011Sistema de classificação da informação da construção — Parte 1: Terminologia e estrutura. Norma brasileira canônica de classificação (7 partes). Base normativa pra breakdown structure code exigido pela Nota EX4 da §6.3.3 da 7817-1 quando o contexto é obra brasileira. Estrutura Grupo.Nível1.Nível2.Nível3.Nível4.Nível5.Nível6.
• ABNT NBR 15965-3:2014Sistema de classificação — Parte 3: Processos da construção. Codifica Tabela 1F (Fases) e Tabela 1S (Serviços da construção). Item canônico crítico: `1S 10 80 00 00 00` = Orçamentação, `1S 40 75 02 00 00` = Medição. O próprio sistema brasileiro reconhece orçamentação e medição como serviços classificáveis — validando o propósito 5D como categoria normativa.
• ABNT NBR 15965-5:2022Sistema de classificação — Parte 5: Resultados da construção. Codifica Tabela 3E (Elementos da construção — sistemas construtivos por função/forma) e Tabela 3R (Resultados dos trabalhos — organizados por atividade e recurso). Base pra breakdown structure code que amarra elemento do modelo a composição de custo.
• ISO 12006-3:2022Building construction — Organization of information about construction works — Part 3: Framework for object-oriented information. Framework language-independent que serve explicitamente como ponte entre sistemas de classificação (ISO 12006-2 / ABNT NBR 15965) e produtos (ISO 16739-1 / IFC). Base tecnológica do buildingSMART Data Dictionary (bSDD).
• ISO 16739-1:2024IFC — Industry Foundation Classes for data sharing in the construction and facility management industries — Part 1: Data schema. Base semântica sobre a qual objetos, propriedades e relações são declarados. Contempla `IfcElementQuantity` (Qto_WallBaseQuantities, Qto_SlabBaseQuantities, Qto_BeamBaseQuantities), `IfcClassification` reference e Psets padronizados — infraestrutura sobre a qual o LOIN alfanumérico pro 5D é implementado.
• ABNT NBR ISO 12006-2:2018Construção de edificação — Organização de informação da construção — Parte 2: Estrutura para classificação. Framework normativo de classificação sobre o qual a ABNT NBR 15965 é estruturada. Referenciada pela §5.1.7 da ABNT NBR ISO 19650-2 como padrão de classificação para o CDE do projeto.