# METODOLOGIA DE HONESTIDADE — validação, procedência e frescor dos dados da entrega CBRE Novaterra x iAgroSat · análise / beta privado · agosto de 2026 Aplica-se a tudo o que a frente CBRE entrega: PDFs (`deliverable/`), site estático (`web/`), SIG com login (`cbre.iagrointel.com`), CSV/GeoJSON e o próprio banco (schema `cbre`). ## 1. Política (numerada, vinculante) 1. **Triagem: sinal, não prova.** Todo resultado analítico (score, ranking, veredito, "parado", "verificar") é sinal para orientar diligência, nunca conclusão sobre o imóvel, o proprietário ou o processo. O rodapé de todo produto repete isso. 2. **Pesos declarados, não calibrados.** Os pesos do score da grade e os presets do motor multicritério são escolhas do projeto (`cbre.fatores`, `research/12`), visíveis, alteráveis pelo usuário e sem pretensão de ótimo. Nenhum peso é apresentado como "medido". 3. **Preço pedido ou praça não é transação.** `cbre.anuncios.preco_brl` e as praças de `cbre.leilao_detalhe` são o que o vendedor ou o edital pedem. Nunca se deriva "valor de mercado" deles. "Fora do mercado" só se afirma contra itens com coordenada (1.199 de ~70 mil) e é piso fraco. 4. **CAR é autodeclarado.** Divisa do imóvel CAR não é matrícula; área é a declarada; gleba (mancha da grade) não é lote, lote não é matrícula. Nunca se afirma titularidade. 5. **Código, não pessoa.** O imóvel é identificado pelo código CAR; leilão pelo número do processo e pelo comitente pessoa jurídica ou juízo. Nome, CPF, telefone e e-mail de pessoa física não entram no banco, no site nem no PDF. Contato com proprietário é ato da CBRE, com base legal própria (LGPD). 6. **Ausência não é certidão.** "Sem embargo", "sem UC", "sem processo ANM" significam ausência na base consultada, na data de acesso. Nunca "certidão negativa". 7. **Método e confiança por zona.** Cada polígono de zoneamento carrega `metodo` (wfs, shp, app_json, georref_pdf, ocr_texto, wms_getfeatureinfo) e `confianca` (alta, média, baixa). "Galpão entra" é leitura da lei com artigo citado (`zoneamento_parametros.artigo_fonte`), não parecer nem consulta prévia; sigla ambígua recebe a leitura mais restritiva. 8. **Veto explicável.** Todo veto (grade, imóvel, mineração) tem motivo em texto na linha (`veto_motivo`, `veto_principal`, `mine_motivo`) e regra declarada em `cbre.fatores.veto_regra`. Não há veto sem frase. 9. **Sobreposição não é irregularidade.** Cruzar imóvel com processo ANM, embargo, UC ou zona de proteção descreve coincidência espacial; nunca acusa. Extrato de leilão nunca julga o devedor. 10. **Satélite é indício.** MapBiomas, NDVI e a série mensal Sentinel-2 leem cobertura, não uso legal; não distinguem cava de terraplenagem; várzea é proxy (GLO-30 + BC250), não mancha oficial. Nada foi visto em campo. 11. **Dado aberto, robots respeitado.** Só fontes públicas; portais que bloqueiam (Cloudflare/403) ficam de fora e são nomeados como lacuna, não contornados. Uma requisição por fonte nas verificações de frescor. 12. **Número sem procedência não sai.** Todo número em PDF, site ou fala tem tabela, script e data; o que não se conseguiu estabelecer fica NULL com motivo (`catalogo_camadas.motivo_null`), nunca preenchido por suposição. ## 2. Como o catálogo, o dicionário, o registro de validação, os hashes e o frescor fazem a política valer | Instrumento | Onde | O que garante | Regra que sustenta | |---|---|---|---| | Catálogo de camadas | `cbre.catalogo_camadas` (≈ 70 linhas), `deliverable/CATALOGO_DADOS.md`, `catalogo.html` | uma linha por tabela/raster usado: fonte, URL, licença, data do dado, data de acesso, script gerador, linhas medidas, hash, método, confiança, limites, cadência, próxima verificação, responsável, último resultado | 6, 7, 11, 12 | | Dicionário de campos | `cbre.dicionario_campos` (200 campos das 9 tabelas que o cliente vê) | cada campo com significado em linguagem simples, unidade, domínio, exemplo e origem — o leitor não precisa adivinhar o que `galpao_entra=conferir` ou `mine_veredito=atencao_anm` querem dizer | 3, 4, 7, 8 | | Registro de validação | `cbre.validacao` (origem `doc` = verificações feitas na construção, com número; origem `auto` = bateria semanal) | cada verificação com esperado, medido, resultado (passa/atenção/falha), data, script e evidência; nada é "validado" sem linha aqui | 1, 12 | | Hash de export determinístico | `catalogo_camadas.sha256` + `sha256_cmd`; `pipeline/qa/hash_tabela.sh` | prova de que a tabela entregue é a tabela medida: `COPY (SELECT * ... ORDER BY pk) TO STDOUT \| sha256sum`, reproduzível por qualquer auditor com acesso ao banco; a bateria recalcula duas vezes e compara com o catalogado | 12 | | Frescor | `cbre.frescor`; `pipeline/qa/frescor_check.py` (mensal) | para cada `fonte_url`, ETag/Last-Modified ou hash do corpo, comparado ao anterior; `mudou=true` abre tarefa de reingestão; host bloqueado é declarado, não adivinhado | 6, 11 | | Cadência | `frescor_periodo` + `proxima_verificacao` no catálogo; cron `qa_run.sh` (domingo 05:30) e `frescor_check.py` (dia 1, 06:00), ao lado do cron de leilões (06:40 diário) | a data de acesso envelhece de forma visível; o site mostra "última validação" por camada | 6, 12 | | Dado pessoal | verificações `auto`: regex de CPF e "Nome:" em `anuncios.titulo/raw`, `leilao_detalhe.*`, colunas de identificação nas tabelas de imóvel | falha bloqueia publicação | 5 | | Rodapé único | `web/build_web.py` FOOT_TXT; `style_cbre.py` | o mesmo texto de ressalva em todas as páginas e PDFs | 1, 3, 4, 6 | Resultado por camada: `passa` (tudo dentro do esperado), `atencao` (fora do esperado com explicação registrada — não bloqueia, mas aparece), `falha` (bloqueia a publicação da camada até correção), `nao_validado` (catalogada sem verificação — aparece assim no site). ## 3. Documento de Validação (modelo) Preencher um por camada ou por entrega, guardar em `research/QA_.md` (automático) ou `deliverable/VALIDACAO__.md` (humano). ``` DOCUMENTO DE VALIDAÇÃO — Data: Rodada: Tabela(s): cbre.<...> Hash (sha256, export determinístico): <64 hex> Linhas: Fonte: <órgão, conjunto, URL> Data do dado: Data de acesso: Licença: <...> Script gerador: Método: Confiança declarada: O QUE FOI MEDIDO CONTRA O QUÊ (referência) ESPERADO MEDIDO RESULTADO passa/atenção/falha ... Limites que permanecem: Ação se atenção/falha: Prazo: <...> Próxima verificação: Cadência: Assina: Em: Evidência: ``` ## 4. O que uma auditoria do cliente recebe 1. `deliverable/CATALOGO_DADOS.md` (+ `catalogo_camadas.csv`, `dicionario_campos.csv`, `validacao.csv`) — catálogo, dicionário e registro completos, gerados do banco. 2. `deliverable/SHA256SUMS.txt` e os hashes por tabela com o comando que os reproduz (`hash_tabela.sh`). 3. `deliverable/DOSSIE_GUARULHOS.md` — fontes, método em uma linha por etapa e o bloco de reexecução (`84b → 80 → run_chain4.sh → mapas → build_docs.py`). 4. Os scripts geradores em `pipeline/`, `mercado/`, `web/` (código aberto ao auditor), com logs `*.log` por etapa. 5. `research/QA_.md` de cada rodada semanal e a série `cbre.frescor` mensal. 6. Este documento, com a política numerada, e a página `catalogo.html` do site com "última validação" por camada. 7. O que NÃO recebe: dado pessoal, preço "de mercado", certidão, parecer urbanístico, laudo — porque não produzimos. ## 5. Operação - `bash pipeline/qa/qa_run.sh` — roda a bateria, grava `cbre.validacao`, atualiza hashes e resultado no catálogo, reexporta MD/CSV/JSON e publica o JSON no site. - `python3 pipeline/qa/frescor_check.py` — verificação de fontes (mensal). - `python3 pipeline/qa/catalogo_export.py` — só reexportar. - `python3 web/build_web.py` — reconstrói o site, inclusive `catalogo.html` (lê `data/catalogo.json`). - Ao criar tabela nova em `cbre`: inserir a linha em `cbre.catalogo_camadas` no mesmo commit (sem linha, a bateria a lista como "não catalogada"). ## 6. Análise sob demanda de uma área (31/08/2026) — e a Prova do método O cliente entrega uma área (desenha, solta um pino, manda KML/KMZ/GeoJSON/SHP zipado/GPKG/GML, ou cola coordenadas) em `analisar.html` e recebe a leitura **calculada na hora**, no PostGIS, contra as mesmas camadas do mapa. Detalhe e reexecução em `research/34_ANALISE_SOB_DEMANDA.md`. **Três selos, e todo valor tem um:** - **medido no polígono** — a conta foi feita com a geometria do usuário contra o vetor da fonte (zona, macrozona, perímetro urbano, inundação, UC/APRM/RBCV, embargo, mineração ANM, CAR, lote, matrícula, anúncio, leilão, estoque, renda por setor, tributação municipal, rede MT e subestação). - **herdado da célula de 250 m** — o valor vem da grade (`cbre.hex`, `hex_fav`, `hex_fatores_extra`, `acesso_polos`), ponderado pela área de interseção de cada célula com o polígono: relevo, cobertura MapBiomas, tempo roteado aos 14 polos, roubo de carga, densidade, MVA da subestação. Carrega o erro dessa escala e diz que carrega. - **declarado** — regra, peso ou parâmetro escrito por nós. Nunca medição. **A Prova do método** vem junto de cada leitura, e é a parte que não se esconde: 1. **Critério → função de pertinência.** O grau 0-100 de cada fator é uma função **linear por partes com âncoras declaradas** — conjunto difuso no sentido estrito (pertence em grau, não por sim/não). As âncoras são lidas de `cbre.fatores` (coluna `transformacao`) e mostradas junto do texto verbatim. 2. **Agregação.** Soma ponderada dos graus (WLC), **compensatória**, rodando por baixo de restrições **não-compensatórias** (o veto): `favorabilidade = (Σ w·g ÷ Σ w) × (1 − fração vetada)`. A tela mostra a contribuição `grau × peso` de cada fator, ordenada, para aquela área. 3. **Veto por objeto.** `cbre.veto_regras_urbano` inteira, com `vale_para_rural`, `vale_para_urbano` e `motivo_da_diferenca`: o imóvel rural e o lote urbano **não** são vetados pelas mesmas regras, e por isso a leitura de uma área desenhada devolve **duas** notas. 4. **Procedência por valor**, com a ficha de `cbre.catalogo_camadas` de cada camada usada. 5. **Reexecução**: `sha256` da entrada canônica + o comando que reproduz a leitura. **Regra de exibição (dono, 31/08):** mostra-se o **método** por inteiro e guarda-se a **resposta**. As listas completas ficam trancadas; nada sobre como um número é feito fica escondido. **Pesos por uso.** Além dos presets de industrial e logística, há **varejo/comercial**, **escritório** e **data center**. Eles são **primeira versão para discussão**: os critérios desses usos ainda não foram levantados com o time da CBRE, e a tela diz isso em toda parte onde eles aparecem. Como todos os outros, os pesos são **declarados**, nunca medidos. ## 7. Situação de uso do imóvel CAR (31/08/2026) — um imóvel em atividade nunca parece disponível Regra do dono, depois de clicar num imóvel com **NDVI 0,86** (claramente plantado) que a tela mostrava como oportunidade: **um imóvel em plena atividade agrícola não pode aparecer como se estivesse disponível.** `cbre.imovel_situacao_uso` (4.346 imóveis, `pipeline/9s_situacao_uso.sql`, relatório `research/35`) dá a cada imóvel um rótulo derivado **só do que já estava medido**: MapBiomas 2024 por imóvel e a série de NDVI de pico de 2026. As **regras são avaliadas em ordem** (a primeira que fecha manda) e os limiares são **declarados**, não calibrados em campo: | # | rótulo | condição | limiares (declarados) | |---|---|---|---| | 1 | **sem dado** | menos de 4 anos MapBiomas OU ndvi_pico_2026 nulo | `n_anos_mapbiomas < 4 OU ndvi_pico_2026 IS NULL` | | 2 | **mineração** | veredito de mineracao ou classe 30 do MapBiomas em 2024 | `mine_veredito = 'veto_mineracao' OU pct_mining_2024 >= 0,10` | | 3 | **construído/urbanizado** | area majoritariamente urbanizada ou com edificacao industrial OSM | `pct_urban_2024 >= 0,50 OU pct_osm_edif_ind >= 0,10` | | 4 | **silvicultura** | plantio florestal comercial em 2024 | `pct_silvi_2024 >= 0,30` | | 5 | **em uso agrícola** | lavoura declarada pelo MapBiomas, ou ciclo de cultura visivel no NDVI, ou uso agropecuario majoritario | `lavoura_2024 >= 0,20 OU (ndvi_pico_2026 >= 0,70 E amplitude_2026 >= 0,15 E pct_forest_2024 < 0,60) OU (pct_mosaico_2024 >= 0,50 E pct_forest_2024 < 0,40 E ndvi_pico_2026 >= 0,60)` | | 6 | **sem cultura há N safras** | sem lavoura em nenhum ano amostrado e NDVI de pico baixo em 2026 | `ndvi_pico_2026 < 0,55 E lavoura < 0,05 em 2014/2018/2021/2024 E pct_forest_2024 < 0,40 E pct_urban_2024 < 0,20 E (pasto+mosaico+nao_vegetado)_2024 >= 0,50` | | 7 | **pasto** | pastagem majoritaria em 2024 | `pct_pasture_2024 >= 0,30` | | 8 | **vegetação nativa** | formacao florestal/natural majoritaria em 2024 | `pct_forest_2024 >= 0,60` | | 9 | **mosaico/indefinido** | o resto: uso agropecuario indistinto (classe 21) ou cobertura mista | `nenhuma das regras 1-8 fecha` | Distribuição medida (4.346 imóveis): vegetação nativa · 1718 · em uso agrícola · 1129 · mosaico/indefinido · 838 · pasto · 325 · silvicultura · 138 · construído/urbanizado · 128 · mineração · 63 · sem cultura há 12 safras · 7. **Como aparece no produto.** O rótulo abre o popup do imóvel (antes de qualquer outra coisa), com o NDVI e o ano — “em uso agrícola (NDVI 0,86, pico 2026)” — e vira um chip na linha de cada lista. A lista da Linha 1 abre **só com os plausíveis**; há um interruptor explícito **“incluir imóveis em uso”**, desligado por padrão. **E a frase que tem de estar na tela:** imóvel em uso **não é descartado** — o cliente pode procurar o proprietário com uma oferta —, mas isso é **outro movimento**, com outro prazo, e por isso não entra na mesma lista. **Nunca dizemos que um imóvel está “disponível”**: o vocabulário é **candidato** ou **alvo**. **O que isto não é:** não é vistoria, não é intenção de venda do proprietário e não é 2025-26 no MapBiomas (a coleção para em 2024; obra ou lavoura iniciada depois disso só aparece pelo NDVI). Limiares sujeitos a ajuste pela CBRE. ## 8. O lote urbano vazio conferido na imagem (31/08/2026) — o número caiu, e isso é o produto `research/36_LOTE_VAZIO_SENTINEL.md` · `cbre.v_lote_vacancia_s2` · `pipeline/cadastro/60_lote_s2_serie.py`. O número de cabeceira da Linha 1 era **232 lotes / 289,9 ha**, apurado por cadastro fiscal + pegada de edificação + OSM. Faltava a fonte que não depende de ninguém ter cadastrado nada: **a imagem**. A série Sentinel-2 **2017-2026** de cada lote (janela seca de maio a setembro, 10 m, mediana das cenas do ano) foi lida lote a lote. Resultado: **13 lotes saíram** — a série mostra mudança persistente compatível com obra que **nenhum cadastro registrou**. O número publicado passou a **219 lotes / 273,1 ha** (São Paulo 178, Guarulhos 41). Isso é o produto funcionando, e por isso a queda aparece escrita na tela, não em silêncio. **A régua não foi escolhida a olho.** 150 lotes comprovadamente construídos passaram pela mesma máquina e deram a **distribuição nula medida**; os limiares são os percentis dela, **declarados**: `mudou` = ΔNDBI ≥ +0,13 **ou** ΔNDVI ≤ −0,16 **ou** Δsolo exposto ≥ +0,19 (os p95), **com persistência** em todos os anos válidos a partir do ano indicado; `estável` = |ΔNDVI| ≤ 0,12 **e** |ΔNDBI| ≤ 0,09 **e** |Δsolo| ≤ 0,16 (os p90); o resto é `inconclusivo`. **Falso positivo medido: 2,7 %** (4 de 150). **A lista tem graus, não carimbo:** `vazio` **96 / 110,0 ha** (as quatro fontes concordando — é o núcleo e o que a lista abre) · `vazio_superficie_nao_vegetada` **60** (série estável, mas o chão já é seco/exposto: pátio, aterro ou terra batida — não é obra nova, é motivo de olhar a imagem) · `vazio_inconclusivo_s2` **63** (série curta, sinal sem persistência, ou polígono publicado pequeno demais) · `construido` **13** (fora de toda contagem). O popup mostra a série ano a ano (NDVI, NDBI, solo exposto, nº de cenas) e o ano da mudança. ⛔ **A população de Guarulhos por área aproximada (312 lotes por Voronoi na quadra) saiu do site.** Reprovou no próprio teste: 309 dos 312 leem como não vegetados porque a fatia mede a **quadra**, não o lote. ⛔ **8 lotes têm polígono suspeito** — o polígono publicado tem de 2 % a 45 % da área declarada no cadastro (mediana dos 232 = 1,000). Ficam marcados, entram como inconclusivos e **não se ordena por área sem conferir**. ⛔ **O maior lote (Guarulhos, 245.788 m², ZUD3) não está no núcleo**: não muda há dez anos, mas está **não vegetado desde 2017** — nunca apresentar como terra limpa. **O que isto não é:** não é vistoria, não é alvará, não é certidão de uso do solo e não é prova de disponibilidade. É triagem: sinal, não prova. NDBI e solo exposto são **proxies** de superfície impermeável e de solo descoberto, não detectores de edificação. ## 9. Comunidades urbanas e ZEIS (31/08/2026) — a camada com a regra de enquadramento mais estrita A camada de **favelas e comunidades urbanas** (IBGE, Censo 2022) e de **ZEIS** entrou no motor como o fator 26. Ela é diferente das outras em uma coisa: **a maneira de dizer faz parte do método**, e a regra é vinculante em toda tela, todo popup, todo PDF e toda conversa. **O que a camada é.** Censo e planejamento urbano. Ela diz **onde a fonte oficial reconhece uma comunidade** e **onde a lei municipal prende a destinação do solo** a Habitação de Interesse Social. **O que pontua, e é o único lado duro.** A **sobreposição**: alvo dentro de comunidade = posse do chão já constituída por moradia consolidada; alvo dentro de ZEIS = restrição legal de uso, lida artigo por artigo na lei do município (`cbre.com_zeis_regra`). **O que não pontua, e está escrito na tela.** A **proximidade**. Ela é ambígua, e a leitura mais direta dela é **oferta de mão de obra** a pé ou por transporte curto, que é o que operador logístico procura. Distância e população no entorno ficam medidas e visíveis, e fora do score. **Onde mora a segurança.** No **fator 12**, medido de boletim de ocorrência georreferenciado da SSP-SP (research/16), e em lugar nenhum mais. Esta camada não é, e nunca é apresentada como, medida de risco. **O que não se escreve, nunca.** "Risco de invasão", "área perigosa", ou qualquer construção que leia como juízo sobre quem mora ali. Critério que não couber em redação neutra fica de fora, e o motivo de ter ficado de fora vai escrito no relatório (research/38, seção 9). **Dado de pessoa.** Nenhum. `nome` é o topônimo do núcleo publicado pela própria fonte. As colunas de endereço que as fontes municipais publicam não foram ingeridas, e a camada de cortiço de São Paulo, que traz endereço residencial, não foi sequer baixada. ## 10. Nome do módulo: "Radar de remembramento" (31/08/2026, comentário nº 37) O módulo se chamava **"radar de assemblagem"**. "Assemblagem" é decalque do inglês *assemblage*; o termo brasileiro para juntar imóveis vizinhos num só é **remembramento** — o inverso do desmembramento. No registro de imóveis o ato correspondente é a **fusão de matrículas contíguas do mesmo proprietário** (Lei 6.015/1973, art. 234), e é assim que o cartório o classifica. **Nome publicado, em toda tela, PDF, catálogo e conversa:** **"Radar de remembramento"**, com o subtítulo obrigatório **"compra sucessiva de lotes na mesma quadra"**. **A precisão que vai junto, e não é cosmética.** O remembramento propriamente dito é **ato de registro** e nasce na matrícula. **Nós não lemos matrícula** — o inteiro teor é pago e nunca foi buscado. Logo **não observamos a fusão**: observamos, no microdado de ITBI de São Paulo, a **compra sucessiva de lotes distintos dentro da mesma quadra fiscal**, que **costuma preceder** o remembramento. Consequências que ficam escritas onde o número aparece: 1. Nem toda compra sucessiva vira remembramento (pode virar loteamento, revenda, ou nada). 2. Um remembramento pode ocorrer **sem nenhuma compra na janela** — herança, cisão societária, dação. 3. **Não verificamos se os lotes são confrontantes**: sabemos apenas que partilham a quadra fiscal. 4. O ITBI não traz adquirente (sigilo fiscal): o sinal é de **concentração de negócio na quadra**, não de comprador único e muito menos de identidade. **A tabela continua sendo `cbre.assemblagem`.** Renomear tabela em produção é risco sem ganho: o rótulo publicado vive no `COMMENT ON TABLE` (`valor/32_rotulo_remembramento.sql`) e em `cbre.catalogo_camadas.descricao_simples`, que são o que o catálogo e o site leem. ## 11. Auditoria de geometria das camadas publicadas (31/08/2026, comentário nº 38) Carlos apontou, com um clique no mapa em (-23,00691 · -47,384548), um polígono que "aparenta ser espúrio", e fez a pergunta certa: **o defeito está na base original ou na base compilada para o sistema?** As duas coisas foram medidas, em **EPSG:31983**, em toda camada que o mapa serve (`pipeline/qa/geom_audit_20260831.py` no banco, e o mesmo teste sobre os arquivos publicados). Testes: `ST_IsValid`; **distância máxima ao centroide ÷ √área > 3** (vértice fora de lugar); **perímetro ÷ (4·√área) > 5** (fio saindo do polígono); vértices repetidos; centroide fora do retângulo de estudo; e área calculada contra a área que a fonte declara. **O que ele viu está na FONTE.** É a matrícula **56039 do Registro de Imóveis de Capivari** (`onr_id` 3314756), do "Mapa do Registro de Imóveis" do ONR. O polígono real tem poucos milhares de m² em Capivari; **um vértice do primeiro anel está a 60,8 km dali**, formando um triângulo degenerado que atravessa a região metropolitana. O defeito já vem assim do ONR: o **`SHAPE__Area` publicado pela própria fonte** é 9.193.031 m², coerente com o vértice errado, não com o imóvel. Nossa compilação só simplificou (35 → 25 vértices) — **não criou o pico**. E o pico é a única razão pela qual esse imóvel entrou no estudo: a lasca cruza o município de São Paulo, e é por junção espacial que atribuímos município. **Excluído da camada publicada** (`cbre.onr_matricula.geom_pico`, `pipeline/qa/50_geom_qa.sql`); a lista de matrícula urbana vai de **78 para 77** objetos. O mesmo teste acha **17 casos em 32.905** matrículas do ONR no país (0,05 %), alguns com vértice a mais de 4.000 km — todos da fonte, todos agora marcados. **O que era NOSSO, e foi corrigido.** Na exportação, a geometria era arredondada para **4 casas decimais (≈ 11 m)** *depois* de simplificada. Arredondar sem *snap* dobra o anel sobre si mesmo: medido, **23 de 3.729** imóveis em `imoveis_outros.geojson`, **123 de 934** em `anm_processos`, **82 de 559** em `inundacao` e **31 de 47** em `macrozoneamento` saíam **inválidos do nosso exportador, estando válidos no banco** (teste: com 4 casas 0 de 23 sobrevivem; com 5 casas, 19; com `ST_ReducePrecision` na mesma grade, 23 de 23). Correção: `cbre.geom_pub()` quantiza a geometria **na mesma grade em que ela vai ser escrita**, antes do `ST_AsGeoJSON` — sem custo de tamanho. Efeito visual era um contorno que se cruza, não um vértice longe; mesmo assim é defeito nosso e está consertado. **O que é fiel à fonte e fica como está, declarado.** Feição multiparte com razão alta e **compacidade baixa** não é pico: é um desenho com várias partes espalhadas. É o caso das 260 feições de `inundacao` (setores de risco dissolvidos por fonte × classe × município), das 87 de `comunidades`, das 77 quadras do Radar de remembramento (lotes distintos da mesma quadra), das 11 subestações fora do retângulo (a rede vizinha atende a área) e dos 410 anúncios fora dele (carteiras nacionais de LOG CP, Bresco e Herzog, que a fonte publica no país inteiro). Também seguem declarados os **8 lotes do GeoSampa** cujo polígono tem de 2 % a 45 % da área do cadastro (seção 8) e as autointerseções que vêm do **SIGMINE/ANM** e do **SICAR**. O `Cartório Teste` do ONR (92 registros, 124.961 ha) **continua fora de toda camada publicada** — conferido. **Passa a ser verificação permanente**: `pipeline/qa/qa_checks.py`, bloco "geometria", roda no cron de domingo sobre toda camada que o cliente vê e acende quando um vértice fora de lugar aparece. **Linha de base do teste, declarada (31/08/2026).** Em carta oficial o polígono **longo e fino é legítimo**: zona que segue corredor de via, setor de risco ao longo do córrego, núcleo em faixa. Medido: das 919 feições de `zoneamento` que acendem o teste, **617 têm menos de 1.000 m² e só 2 são multiparte** — são lascas e corredores da própria carta. Por isso o teste tem duas severidades: nas **listas de objeto** (`imoveis_candidatos`, `glebas_candidatas`, `estoque_logistico`, `assemblagem`) a base é **0** e qualquer caso é **falha**; na **cartografia de fonte** (`zoneamento` 919 · `inundacao_oficial` 43 · `com_zeis` 8 · `com_favela` 5 · `macrozoneamento` 4) o que se vigia é a **mudança** contra a base publicada acima. `onr_matricula` fica com base **17** — os 17 defeitos da fonte já marcados em `geom_pico` e fora do mapa; o 18º acende.