diff --git a/README.md b/README.md
index 4ec0417..b76f793 100644
--- a/README.md
+++ b/README.md
@@ -211,71 +211,157 @@ Consulte a referência oficial de [Event Handlers](https://community.bohemia.net
 
 ## Modelos, LODs e Object Builder
 
-O BRAF usa modelos `.p3d`, materiais `.rvmat`, texturas `.paa` e animações `.rtm`. A geometria visual não substitui automaticamente as geometrias de colisão, visão, balística, física ou navegação.
+O BRAF usa modelos `.p3d`, materiais `.rvmat`, texturas `.paa` e animações `.rtm`. Um modelo não é apenas a malha visível: os LODs determinam renderização, visão, colisão, penetração, PhysX, flutuação, navegação, sombras e pontos de integração com a configuração. Uma malha que parece correta pode continuar sem colisão, deixar a IA enxergar através dela, tornar a tripulação invulnerável ou falhar na água.
 
-O [Object Builder](https://community.bohemia.net/wiki/Object_Builder) faz parte do Arma 3 Tools e é utilizado para editar modelos, configurar LODs, propriedades nomeadas, materiais e visualizar o resultado com Buldozer.
+O [Object Builder](https://community.bohemia.net/wiki/Object_Builder) é parte do Arma 3 Tools, sucessor do Oxygen 2, e cria, edita e grava P3D **não binarizado (MLOD)**. Ele não é uma ferramenta para editar um P3D binarizado de release. No BRAF, modelos, texturas, materiais e animações existentes continuam protegidos: esta documentação explica o fluxo, mas não autoriza substituir, recriar ou sobrescrever um binário sem escopo explícito.
 
-### LODs principais
+### Contrato entre P3D, `model.cfg` e `config.cpp`
 
-| LOD | Função | Cuidados principais |
+| Camada | Define | Deve coincidir com |
 |---|---|---|
-| Resolution | Geometria visível em diferentes distâncias | Use LODs realmente diferentes e remova detalhes pequenos progressivamente; cópias idênticas não trazem ganho |
-| View Pilot | Visão de piloto ou motorista | Deve refletir o que o ocupante realmente vê |
-| View Gunner | Visão do atirador | Verifique torre, óptica, arma e animações relacionadas |
-| View Commander | Visão do comandante | Verifique posição, escotilhas e instrumentos |
-| View Cargo | Visão de passageiros | Verifique proxies e visibilidade dos ocupantes |
-| Geometry | Colisão geral e interação com objetos sem PhysX | Componentes fechados, convexos e simples; a massa e o centro de massa importam |
-| Fire Geometry | Colisão com projéteis e foguetes | Use geometria simplificada, materiais de penetração e proxies necessários para ocupantes |
-| View Geometry | Oclusão e linha de visão | Deve bloquear corretamente visão do jogador e percepção da IA |
-| Geometry PhysX | Colisão e simulação física de veículos | Mantenha simples; massa e distribuição de massa afetam diretamente o comportamento |
-| Geometry Buoyancy | Volume de deslocamento de objetos flutuantes | Componentes convexos, simples e não intersectados; requer teste em água |
-| Roadway | Superfície onde unidades caminham ou ficam | Não sobreponha Geometry; use superfície compatível e divida objetos muito grandes |
-| Memory | Pontos de controle | Inclui armas, faróis, fumaça, escapamento, luzes, eixos e pivôs |
-| LandContact | Pontos de contato com o solo | Essencial para veículos e comportamento de contato |
-| Hit-points | Pontos de partes destrutíveis | Deve corresponder aos hitpoints declarados na configuração |
-| Paths | Navegação da IA em interiores | Use pontos e seleções adequados ao espaço navegável |
-| Shadow Volume | Sombra dedicada | Mantenha fechado, triangulado e separado por complexidade adequada |
-| Wreck | Modelo ou geometria após destruição | Deve corresponder à propriedade de dano e à configuração do objeto |
+| `.p3d` | LODs, seleções nomeadas, eixos, proxies, materiais, pontos do Memory LOD e geometria | nomes usados por `model.cfg`, `hiddenSelections[]`, `memoryPoint*`, torres, hitpoints e efeitos |
+| `model.cfg` | `CfgSkeletons`, `CfgModels`, seções, ossos e animações do modelo | nome do P3D sem extensão, seleções, eixos e controladores reais |
+| `config.cpp` / `.hpp` | `model =`, classe de veículo, `AnimationSources`, `hiddenSelections[]`, posições de entrada, turrets, hitpoints, efeitos e User Actions | caminhos, seleção, ponto de memória e fonte de animação existentes no modelo |
+| `.rvmat` / `.paa` | material e aparência visual; material de dano no Fire Geometry | faces e seleções do LOD correto, além de caminhos com capitalização real |
 
-A documentação oficial de [LOD](https://community.bohemia.net/wiki/LOD) descreve os tipos, limitações e fallback entre LODs. Os valores abaixo são orientações de trabalho, não substituem validação:
+`CfgModels` é a interface entre o P3D e a engine: a classe deve usar o nome do arquivo do modelo sem `.p3d`, declarar suas `sections[]`, associar o `skeletonName` e conter as `Animations`. `CfgSkeletons` descreve cada osso e sua relação pai/filho. Já `AnimationSources` pertence à classe do objeto em `config.cpp`: ela fornece controladores nativos ou fontes `user` para as animações declaradas no `model.cfg`. A referência oficial de [Model Config](https://community.bohemia.net/wiki/CfgModels) detalha essa separação entre trabalho de arte e configuração.
 
-- mantenha um único UV map quando a ferramenta e o asset exigirem isso;
-- não trate `decimate = 0.5` como regra universal: preserve a silhueta e a função de cada LOD;
-- use componentes `ComponentXX` fechados e convexos onde a engine exige geometria válida;
-- a massa e a distribuição da massa são importantes para objetos PhysX;
-- Fire Geometry precisa de material de dano/penetração apropriado;
-- proxies de ocupantes devem existir nos LODs relevantes para evitar ocupantes invulneráveis ou invisíveis à IA;
-- não presuma que Geometry, View Geometry e Fire Geometry podem compartilhar exatamente a mesma malha;
-- valide o modelo no Object Builder/Buldozer e depois no jogo.
+O repositório aplica esse contrato em várias famílias — `braf_air`, `braf_air2`, `braf_armored`, `braf_boat`, `braf_ships` e `source\braf_tracked` têm `model.cfg`. Um exemplo pequeno e útil é `braf_boat\BRAF_VLPV`: o `model.cfg` define esqueleto, `propeller`, `rudder`, `drivewheel` e `hatch`; `VLPV_base.hpp` declara a fonte `openhatch`, as seleções de textura e os pontos de água, motor, carga e entrada. Use-o para entender o vínculo entre os arquivos, não para copiar nomes ou propriedades para outro veículo.
 
-### Named Properties
+### Fluxo seguro no Object Builder
 
-Named Properties são configuradas no Object Builder e normalmente devem ser escritas em minúsculas; a documentação de [Arma 3 Named Properties](https://community.bohemia.net/wiki/Arma_3%3A_Named_Properties) explica o comportamento da ferramenta e do binarizador.
+1. Confirme que abriu a fonte MLOD correta e identifique o addon proprietário, o `model.cfg`, a classe de veículo e todos os consumidores antes de alterar qualquer seleção.
+2. Trabalhe por LOD. Não use a Resolution LOD como substituta automática para Geometry, Fire Geometry, View Geometry, PhysX, Buoyancy ou Roadway.
+3. Crie e mantenha seleções nomeadas para partes móveis, retexturáveis, hitpoints, proxies e eixos. Trate o nome como contrato: preserve grafia e capitalização já usadas pelo modelo e pela configuração.
+4. Em LODs físicos, valide topologia antes de adicionar proxies: `Structure > Topology > Find Non-Closed`, `Close`, `Structure > Convexities > Find Non-Convexities` e `Component Convex Hull`; depois use `Structure > Check Faces` para localizar faces ou texturas inválidas. A referência de [Validating Geometries](https://community.bohemia.net/wiki/Validating_Geometries) descreve essas verificações.
+5. Revise massa e distribuição de massa no Geometry LOD; em objetos PhysX elas afetam inércia, contato e estabilidade.
+6. Use Buldozer como prévia visual de LODs, materiais, proxies e animações. Ele é configurado pelo Arma 3 Tools/P drive; a documentação oficial registra que iniciar o Object Builder diretamente pela Steam pode impedir a conexão com Buldozer.
+7. Teste no jogo cada comportamento físico e de gameplay. Um P3D abrir no Object Builder ou renderizar no Buldozer não prova colisão, dano, PhysX, flutuação, Roadway, IA ou multiplayer.
 
-Propriedades comuns incluem:
+O Object Builder aceita P3D MLOD e outros formatos de importação, mas sua saída é P3D não binarizado. Não use isso como atalho para editar um asset de runtime, nem use packing ou binarização como teste de comportamento neste projeto.
 
-- `lodnoshadow` para controlar sombra em LODs de resolução;
-- `canocclude` e `canbeoccluded` para oclusão;
-- `sbsource` para a fonte de sombra;
-- `autocenter` e `reversed` quando o asset realmente precisa dessas propriedades;
-- `aicovers` quando o objeto deve ser considerado cobertura pela IA;
-- `buoyancy = 1` no Geometry LOD de objetos flutuantes.
+### LODs de visualização e interior
 
-Não adicione propriedades apenas por copiar outro modelo. Uma propriedade como `autocenter`, especialmente em veículos aquáticos, pode alterar o comportamento físico. O resultado só é considerado validado após teste do modelo no jogo.
+O valor numérico de uma Resolution LOD não escolhe uma distância fixa no Arma 3. A engine seleciona LODs conforme distância, qualidade gráfica, carga e outras condições. Portanto, forneça níveis com complexidade realmente decrescente; cópias idênticas aumentam tamanho, memória e carregamento sem ganho. Proxies precisam existir em cada Resolution LOD onde devam aparecer, e uma seleção vazia usada por animação ou pela engine pode causar falha quando o LOD se torna ativo. Consulte [LOD](https://community.bohemia.net/wiki/LOD) para o comportamento de seleção.
 
-### Geometry Buoyancy, Roadway e navios
+| LOD | Responsabilidade | Verificação obrigatória |
+|---|---|---|
+| Resolution | Modelo externo visível; a Resolution LOD de maior detalhe deve preservar silhueta, materiais, seleções e proxies necessários | detalhe cai progressivamente, não há cópias idênticas, UV/material e proxies permanecem válidos |
+| View Pilot | Interior visto por piloto/motorista | painel, visibilidade, mãos/controles, portas e partes ocultas não invadem a câmera |
+| View Gunner | Interior e partes vistas pelo atirador | torre, arma, óptica, miras e eixos acompanham a posição do gunner |
+| View Commander | Interior da posição do comandante | escotilhas, ópticas e instrumentos respeitam a câmera e a animação |
+| View Cargo | Interior visto por passageiros | proxies de carga, posições, abertura de portas e visibilidade por assento |
+| View Pilot/Gunner/Commander/Cargo Geometry e Fire Geometry | Geometria específica das posições internas quando a proteção, oclusão ou dano diferir por ocupante | teste primeiro pessoa, dano recebido e linha de visão em cada assento afetado |
+| Shadow Volume / Shadow Buffer | Sombra dedicada nas resoluções próprias | não duplique LODs de mesma resolução, mantenha a forma simples e revise artefatos em luz forte |
+| Wreck | representação após destruição, quando a classe/configuração a usar | modelo, material, hitpoints e transição de dano correspondem ao comportamento configurado |
 
-Para embarcações e veículos anfíbios:
+`LodNoShadow = 1` é a propriedade documentada para Resolution LODs. Para transparências que recebam sombras ambientais de modo incorreto, a BIKI indica `Forcenotalpha = 1` no Geometry LOD — nunca como correção automática para qualquer material alfa. Use a grafia da propriedade documentada ou já empregada pelo asset; não normalize propriedades por estética.
 
-- o Geometry LOD deve conter a propriedade `buoyancy = 1` quando o objeto deve flutuar;
-- o Geometry Buoyancy deve ser simples, convexo e sem interseções entre componentes;
-- a massa do Geometry e a configuração do veículo devem ser coerentes;
-- o PhysX Geometry e o Roadway devem ser testados separadamente;
-- o Roadway não deve atravessar o Geometry de forma a causar tremores;
-- navios longos podem precisar ser divididos em segmentos ou child P3Ds, cada um com geometria e roadway válidos;
-- proxies visuais não substituem automaticamente a geometria física do objeto principal.
+### LODs físicos, dano e visibilidade
 
-Use as [Ships Config Guidelines](https://community.bohemia.net/wiki/Arma_3%3A_Ships_Config_Guidelines) junto com a inspeção dos P3Ds reais. Packing ou binarização não provam que flutuação, colisão, roadway ou ocupantes estão corretos.
+| LOD | Responsabilidade | Regras práticas e riscos |
+|---|---|---|
+| Geometry | Colisão quando pelo menos um objeto não é PhysX; por exemplo, contato soldado-veículo | use `ComponentXX` consecutivos, componentes fechados e convexos, massa válida e espessura física suficiente; a engine usa massa e distribuição para inércia |
+| Geometry PhysX | Malha de simulação física do veículo | mantenha muito simples, triangulada e coerente com o centro de massa; não a trate como cópia de alta fidelidade do visual |
+| Geometry Buoyancy | Volume de deslocamento para embarcações e anfíbios | poucos componentes convexos, fechados, triangulados e sem interseções; volume e posição alteram a flutuação |
+| Fire Geometry | Impacto de balas, foguetes e penetração | componentes fechados/convexos, material de dano/penetração aplicado, complexidade baixa; se ausente, a engine recorre a View Geometry e depois Geometry |
+| View Geometry | Oclusão visual e linha de visão da IA | deve representar volumes que realmente bloqueiam visão; se ausente, Geometry é usada como fallback |
+| Hit-points | vértices nomeados não conectados que localizam partes destruíveis | nomes, posição e espaçamento devem corresponder a `HitPoints` da classe e ao Fire Geometry |
+| LandContact | vértices únicos de contato com solo | cada ponto precisa apoiar o veículo conforme sua simulação; não confunda com flutuação naval |
+
+Para Geometry e Fire Geometry, a validação de convexidade não é opcional. O Object Builder pode gerar `ComponentXX` por `Structure > Topology > Find Components`; valide antes de inserir proxies. A BIKI também recomenda manter o Geometry LOD dentro do limite de tamanho: a referência histórica aponta instabilidade em torno de 50–60 m a partir da origem para a geometria, com variação por contexto. Não use esse número como limite garantido; trate-o como gatilho para testar e, quando necessário, dividir a composição.
+
+Fire Geometry requer atenção adicional:
+
+- inclua proxies de motorista e passageiros nesse LOD quando a tripulação deve receber dano; sem eles, ocupantes podem se tornar invulneráveis;
+- aplique material físico de dano/penetração, não apenas o `.rvmat` visual;
+- mantenha faces e componentes simples; a referência BIKI cita menos de 3.500 pontos como orientação;
+- evite placas de Fire Geometry quase sobrepostas: o passo de simulação do projétil pode ignorar a segunda camada.
+
+View Geometry não é decoração. Ela impede jogador e IA de enxergarem através do objeto. `canocclude` e `canbeoccluded` são propriedades de Geometry/View Geometry para casos específicos de oclusão; use-as somente quando a forma de oclusão não representar a forma visível, como vegetação perfurada. A página de [Named Properties](https://community.bohemia.net/wiki/Arma_3%3A_Named_Properties) deve prevalecer sobre valores copiados de outro modelo.
+
+### Memory, Roadway, Paths e proxies
+
+| LOD/elemento | Uso | Contrato de integração |
+|---|---|---|
+| Memory | pontos de arma, escapamento, fumaça, luz, efeito de água, entrada/saída, carga, câmera, PIP, eixo e ação | o texto em `memoryPoint*`, `memoryPoints*`, posição de User Action, torre ou efeito deve ser o nome da seleção do Memory LOD |
+| Eixo no Memory | dois vértices com uma seleção nomeada formam eixo de rotação/translação | `axis =` de `model.cfg` deve apontar para essa seleção quando `memory = 1`; com `memory = 0`, o eixo pertence ao LOD do modelo |
+| Roadway | superfície onde unidades ficam em pé e caminham | não pode sobrepor Geometry, ou o personagem oscila; é necessário abaixo de pontos de escada; textura da superfície também influencia o efeito sonoro de passos |
+| Paths | rede de navegação de IA em interiores/estruturas | malha conectada, `posXX` para paradas e `inXX` para entradas; deixe folga de paredes e mantenha os caminhos cerca de 10 cm acima da superfície caminhável |
+| Proxy | referência a outro P3D, ocupante, arma ou acessório | inclua-o nos LODs visuais em que deve aparecer e nos LODs físicos que realmente exigem sua presença; proxy visual não garante colisão, Roadway, dano ou PhysX |
+
+O Roadway torna uma superfície caminhável para unidades. Não deixe Roadway e Geometry ocuparem o mesmo volume; isso causa oscilação. A BIKI relata instabilidade para componentes do Roadway a aproximadamente 36 m da origem, variando com mapa/célula, e limite menor quando o Roadway contém elementos animados. Para plataformas, pontes e navios extensos, teste cada segmento e prefira uma composição de P3Ds menores quando a superfície exceder esse comportamento estável.
+
+Memory LOD é também a origem de muitas falhas aparentemente "de configuração". No BRAF, a classe de VLPV, por exemplo, aponta para pontos de efeito de água e motor, carga sling e entrada de piloto/carga. Um nome ausente ou em outra grafia resulta em efeito, entrada ou interação ausente. Partículas e certos pontos de arma podem ignorar deslocamento animado e usar a posição padrão do Memory LOD; confirme no jogo, não apenas no Buldozer.
+
+### `model.cfg`, esqueleto e animações
+
+| Elemento | Papel |
+|---|---|
+| `CfgSkeletons` | declara ossos e hierarquia pai/filho em `skeletonBones[]`; o filho acompanha a transformação do pai |
+| `CfgModels` | associa o modelo ao `skeletonName`, declara `sections[]`/`sectionsInherit` e contém `class Animations` |
+| `selection` | parte móvel ou osso/seleção existente no P3D |
+| `axis`, `begin` e `end` | eixo local ou pontos que definem direção da animação; normalmente um eixo de dois pontos no Memory LOD |
+| `source` | controlador nativo ou fonte declarada em `AnimationSources` no `config.cpp` |
+| `memory` | informa se o eixo está no Memory LOD; o padrão documentado é verdadeiro |
+| `minValue`, `maxValue`, `angle0`, `angle1` | mapeiam entrada do controlador para fase, rotação ou deslocamento |
+| `sourceAddress` | define como entrada fora do intervalo é tratada, como loop, clamp ou espelhamento |
+
+Os tipos usuais são `rotation`, `rotationX/Y/Z`, `translation`, `translationX/Y/Z`, `hide` e `direct`. Para uma porta, torre, leme, hélice ou trem de pouso, confirme na sequência: seleção existe no LOD visível; a seleção física acompanha a animação quando necessário; eixo está no lugar e orientação corretos; `model.cfg` aponta para ambos; a fonte existe em `AnimationSources` ou é um controlador nativo; a ação, script ou sistema do veículo altera a mesma fonte.
+
+Se uma animação muda colisão ou proteção, copie a seleção para os LODs físicos atingidos, especialmente Geometry e Fire Geometry. Para animações de personagem, não trate `model.cfg` como substituto de `.rtm`, `CfgMoves` e `CfgGestures`: a referência de [Animations – Arma 3](https://community.bohemia.net/wiki/Arma_3%3A_Animations) separa animações simples de modelo das animações de estado de personagens.
+
+### Propriedades nomeadas
+
+Named Properties pertencem ao LOD, não à classe de veículo. Adicione somente uma propriedade com comportamento conhecido e aplicável ao tipo de asset.
+
+| Propriedade | LOD usual | Uso correto |
+|---|---|---|
+| `LodNoShadow = 1` | Resolution | controla contribuição de sombra da Resolution LOD; não pertence a Shadow Volume |
+| `Forcenotalpha = 1` | Geometry | correção específica para artefato de sombra ambiente através de material alfa |
+| `canocclude` / `canbeoccluded` | Geometry e View Geometry | ajusta participação na oclusão; útil apenas para formas cuja oclusão não representa o objeto visível |
+| `buoyancy = 1` | **Geometry**, não Geometry Buoyancy | habilita o uso de Geometry Buoyancy para barcos e anfíbios |
+| `autocenter` | Geometry, quando o tipo de modelo exigir | altera referência/origem física; nunca defina `0` ou `1` por cópia, nem use como solução genérica de flutuação |
+| `aicovers`, `sbsource`, `reversed` e outras | somente no LOD e caso documentados para o asset | mantenha a semântica existente e confirme na BIKI/vanilla antes de introduzir |
+
+Não existe conjunto universal de properties para todos os modelos. Em especial, propriedades de origem e massa podem ter efeitos opostos entre acessórios, veículos terrestres, aeronaves, barcos e estruturas. Uma alteração de `autocenter`, `buoyancy`, material físico ou componentes de Geometry exige inspeção do P3D real e teste no jogo.
+
+### Embarcações, anfíbios e navios
+
+Para `braf_boat`, `braf_ships` e qualquer veículo anfíbio:
+
+- coloque `buoyancy = 1` no **Geometry LOD**, não no Geometry Buoyancy;
+- modele Geometry Buoyancy com poucas faces, componentes convexos e fechados, triangulação válida e sem volumes internos, interseções ou contatos desnecessários entre componentes submersos;
+- faça a forma e o volume do LOD de buoyancy se aproximarem do casco que desloca água; massa e centro de massa do Geometry precisam ser coerentes com esse deslocamento;
+- mantenha Geometry PhysX separado da geometria visual e teste massa, estabilidade, contato, inclinação e dano em água;
+- mantenha efeitos de motor abaixo da linha d'água quando a configuração do veículo assim exigir; pontos de água, propulsão e esteira também são Memory points que precisam coincidir com a configuração;
+- não use LandContact como evidência de que o navio flutua: o comportamento na água depende de Geometry, PhysX e Buoyancy;
+- trate cada seção de uma embarcação modular como unidade física própria. Proxies podem resolver a aparência, mas não substituem Geometry, Fire Geometry, View Geometry ou Roadway válidos em cada área onde esses comportamentos são necessários.
+
+A documentação de [Ships Config Guidelines](https://community.bohemia.net/wiki/Arma_3%3A_Ships_Config_Guidelines) alerta que navios grandes pressionam limites de tamanho, vértices, luzes, PhysX e Roadway. Como orientação, uma embarcação acima de aproximadamente 100 m pode exigir divisão em P3Ds/componentes menores. Isso não é uma licença para fragmentar qualquer modelo: primeiro defina a responsabilidade de cada seção, suas origens, LODs físicos e critérios de teste. Nunca conclua que uma composição funciona apenas porque o visual aparece.
+
+### Diagnóstico por sintoma
+
+| Sintoma | Camada a investigar primeiro |
+|---|---|
+| modelo aparece, mas pessoa atravessa ou colide de forma errada | Geometry, componentes convexos, massa, Geometry PhysX e tamanho/origem |
+| bala atravessa blindagem ou ocupante não recebe dano | Fire Geometry, material de penetração, proxies de ocupante, Hit-points e configuração de dano |
+| jogador ou IA enxerga através do objeto | View Geometry, `canocclude`/`canbeoccluded` e LOD de visão da posição afetada |
+| personagem cai, vibra ou não caminha no convés | Roadway, sobreposição com Geometry, distância da origem, escadas e Paths |
+| porta, torre, leme ou hélice não anima corretamente | seleção, eixo, `memory`, `CfgSkeletons`, `CfgModels`, `AnimationSources` e fonte usada pela classe |
+| luz, fumaça, entrada, arma ou efeito de água está ausente | seleção no Memory LOD e string exata da propriedade `memoryPoint*`/`memoryPoints*` |
+| barco afunda, inclina ou muda comportamento após dano | `buoyancy = 1`, Geometry Buoyancy, massa/distribuição, Geometry PhysX, volumes intersectados e configuração naval |
+| textura variante não troca | seleção no P3D, `sections[]` do `model.cfg`, `hiddenSelections[]`, material e caminho real do asset |
+
+### Validação mínima antes de considerar um modelo pronto
+
+1. **Mapa de contratos:** confirme caminho do P3D, classe `CfgModels`, `skeletonName`, seções, seleções, eixos, proxies, `AnimationSources`, `memoryPoint*`, hitpoints e materiais.
+2. **Object Builder:** revise LOD por LOD, named properties, massa, componentes, faces e topologia. Valide Geometry e Fire Geometry antes de inserir proxies.
+3. **Buldozer:** percorra Resolution, todas as câmeras internas, sombras, materiais, proxies e cada fase de animação.
+4. **Jogo:** teste colisão soldado/veículo, impacto e dano da tripulação, linha de visão da IA, assentos, torres, portas, efeitos, hitpoints, Roadway, Paths e, quando aplicável, PhysX, água e flutuação.
+5. **Relato honesto:** diferencie checagem textual, validação estrutural no Object Builder, prévia no Buldozer e evidência no jogo. Binarização, packing ou geração de PBO não provam nenhum desses comportamentos — e não são executados como validação neste repositório.
+
+Referências oficiais: [Object Builder](https://community.bohemia.net/wiki/Object_Builder), [LOD](https://community.bohemia.net/wiki/LOD), [LOD resolutions](https://community.bohemia.net/wiki/LOD_resolutions), [Model Config](https://community.bohemia.net/wiki/CfgModels), [Animations – Arma 3](https://community.bohemia.net/wiki/Arma_3%3A_Animations), [Named Properties – Arma 3](https://community.bohemia.net/wiki/Arma_3%3A_Named_Properties), [Validating Geometries](https://community.bohemia.net/wiki/Validating_Geometries) e [Ships Config Guidelines](https://community.bohemia.net/wiki/Arma_3%3A_Ships_Config_Guidelines).
 
 ## Texturas, materiais, sons e caminhos