Due-diligence FAQ — respostas honestas para avaliação técnica e comercial¶

Status: Documento de auditoria. Linguagem direta; pontos fracos declarados explicitamente. Última revisão: 2026-07-22 (números de modelo re-gerados automaticamente a cada retrain por scripts/sync_claim_surfaces.py). Autoridade: complementa docs/POSITIONING.md, EULA.md e DPA-LGPD.md. Em caso de conflito, prevalecem os documentos contratuais.

Executive summary¶

TELECOM TOWER POWER é uma plataforma SaaS de planejamento RF posicionada explicitamente como screening top-of-funnel para ISPs regionais, neutral hosts, integradores e consultorias — não como substituto do stack interno de operadoras Tier-1 (Atoll/Planet/Asset). Esta declaração de escopo é contratual (docs/POSITIONING.md, EULA.md) e não retórica.

Os engines implementados são reais e auditáveis: ITU-R P.1812 (itu_p1812.py), Longley-Rice/ITM via adapter NTIA (rf_engines/itmlogic_engine.py), Sionna RT v2 promovido em 2026-05-13, motor de interferência multi-operador, e Dijkstra multi-hop.

O modelo aprendido em produção é a cadeia P.1812/P.1411 + resíduo LightGBM, treinada com dados reais de drive-test (71.965 observações; 5G NR n78 3,5 GHz + LTE B28 700 MHz/B1/B3/B7 (Vivo, TIM, Claro), suburbano/urbano de Brasília): 7,86 dB de RMSE em CV espacial (folds h3_res8, k=5), banda calibrada do artefato de ±12,56 dB — em produção, a banda efetivamente aplicada é de ±14,57 a ±22,12 dB conforme a classe de sinal (override de campo, origem: recalibração automática de campo, aplicado em 2026-09-07; verificação ao vivo: GET /coverage/effective-band), grau triagem (screening) dentro do envelope — verificável ao vivo, sem autenticação, em GET /coverage/claim-readiness e GET /coverage/promotion-readiness. Fora do envelope calibrado, o fallback ridge (~14,9 dB CV) responde com recusa de extrapolação e é declarado auxiliar, nunca única fonte para parecer assinado.

Os pontos fracos materiais e honestos são cinco: (1) bus factor com um único mantenedor visível e sem SLA contratual de horas-resposta para tiers abaixo de Enterprise; (2) calibração do modelo aprendido em uma única região (Brasília/Centro-Oeste) — validação cross-region com drive-test independente ainda não publicada; (3) PDFs com manifest SHA-256 e HMAC opcional, porém sem assinatura ICP-Brasil — auditoria LAI/ANATEL exige carimbo complementar fora do TTP; (4) SOC 2 com políticas internas escritas e um drill de DR registrado (2026-04-30), porém sem auditoria Tipo II por terceiro independente; (5) ausência de cases públicos com nome de cliente + desvio medido vs. campo. Nenhum desses é fatal; todos são negociáveis em contrato e este documento descreve o caminho de mitigação para cada um.

1. Protótipo vs. produção — a identidade real¶

O que "protótipo modular" significa. O termo vem do README e é literal: o repositório público é o núcleo lógico completo (engines de propagação, ML, billing Stripe, auth Cognito, audit log, batch SQS/Lambda). Não é uma fork pública reduzida — é o mesmo código que roda em ECS Fargate (ecs-task-definition.json, task definition :151). O que não está no repositório público são apenas:

credenciais e segredos em AWS SSM SecureString,
artefatos treinados (coverage_model.npz referencia MODEL_S3_URI; modelo Sionna em s3://telecom-tower-power-results/models/sionna/current/),
o dataset histórico de link_observations em RDS.

Esse pattern é normal para SaaS B2B; não existe fork interna escondida.

"Live em produção desde 29/04/2026" com linguagem de protótipo no README — é uma inconsistência editorial, não comercial. docs/POSITIONING.md e o EULA já reposicionam o produto como production-grade dentro do escopo declarado. A palavra "protótipo" no README é dívida de redação e está rastreada para remoção.

Auditabilidade ANATEL/FUST/LAI. O ponto crítico não é o código público — é o conteúdo do PDF gerado. Hoje o PDF inclui versão de modelo (ridge-v1/sionna-v2), inputs e timestamp, mas não inclui hash SHA-256 do conteúdo nem assinatura digital externa. Para LAI/FUST formal isso é insuficiente — você precisa complementar com assinatura ICP-Brasil fora do TTP. Gap conhecido, mitigação documentada no contrato.

Caminho para correção urgente. Mantenedor único visível (Daniel). Sem SLA contratual de horas-resposta no EULA para tiers abaixo de Enterprise. Risco real, ver §6.

2. Precisão técnica e modelos de propagação¶

O número procurement-relevante é o do artefato servido, verificável ao vivo. Dentro do envelope calibrado (5G NR n78 3,5 GHz + LTE B28 700 MHz/B1/B3/B7 (Vivo, TIM, Claro), suburbano/urbano de Brasília), a cadeia P.1812/P.1411 + resíduo LightGBM reporta 7,86 dB de RMSE em CV espacial (folds agrupados h3_res8, k=5 — sem vazamento espacial) com banda calibrada do artefato de ±12,56 dB — em produção, a banda efetivamente aplicada é de ±14,57 a ±22,12 dB conforme a classe de sinal (override de campo, origem: recalibração automática de campo, aplicado em 2026-09-07; verificação ao vivo: GET /coverage/effective-band) — calibração sobre 71.965 obs. reais; grau triagem (screening) (gate sole-source: <8 dB e ≥5.000 obs. reais — status ao vivo em GET /coverage/promotion-readiness). Fora do envelope, o fallback ridge reporta ~14,9 dB de CV e recusa extrapolação.

Para comparação: ATOLL/Planet sem calibração local costumam entregar 8–14 dB em ambientes brasileiros mistos; modelos físicos puros (Hata, ITM default), 12–18 dB. Se o caso de uso exige o grau sole-source hoje, o produto não atende — use como triagem, não como decisão final; o gate é público e re-avaliado a cada retrain.

FSPL+Fresnel vs. P.1812 vs. Longley-Rice. O repositório implementa os três:

itu_p1812.py — ITU-R P.1812-5 implementação completa.
rf_engines/itmlogic_engine.py — adapter sobre o pacote NTIA itmlogic.
Caminho /analyze legacy ainda usa FSPL+penalty Fresnel (com cap de 40 dB pós-2026-04-29 para evitar RSSI unphysical).

Diferença esperada em terreno brasileiro irregular:

Modelo	Erro típico NLOS
FSPL + Fresnel	10–25 dB
ITU-R P.1812-5	6–10 dB
Longley-Rice / ITM	~8 dB

Para qualquer parecer assinado, use P.1812 ou ITM, nunca FSPL isolado.

SRTM 30 m (não 90 m como o pitch ocasionalmente cita). Para Mata Atlântica densa ou Serra do Mar, mesmo 30 m sub-estima clutter por falta de copa. O sinal Planet NDVI v2 (planet_ndvi.py) está integrado ao Sionna v2 mas tem peso baixo enquanto não houver drive-test real. Comparação direta com LiDAR local nunca foi publicada. Gap real.

Clutter ANATEL + MapBiomas + ITU chuva. MapBiomas: implementado (mapbiomas_clutter.py). ITU-R P.838 (chuva): existe via cálculo de rain_zone. Dataset ANATEL clutter proprietário 1 m: não implementado — docs/POSITIONING.md declara isso abertamente.

Explicações Bedrock/Claude. Risco jurídico é do engenheiro que assina. O EULA tem cláusula explícita de limitação de responsabilidade para análises geradas; usuário é responsável final. Se a explicação contém inconsistência técnica e o parecer é assinado sem revisão, a responsabilidade é do signatário — exatamente como qualquer ferramenta CAD/RF profissional.

Retrain e risco de drift. O retrain roda sobre o acervo real de link_observations (ingestão HMAC de drive-tests com gates de plausibilidade e dedup) com salvaguardas automáticas em cadeia: quarentena/recalibração de viés por submitter e por torre, promoção de candidato somente com melhora comprovada em holdout replay de linhas não-vistas, monitor de drift de covariáveis (PSI) e banda conformal medida ao vivo com alertas Prometheus. Candidato reprovado não substitui o incumbente; cada decisão fica registrada nos runs do GitHub Actions:

(a) validação antes de promover: holdout replay comensurável + gate de PSI — implementado e exercitado em produção;
(b) detecção de outlier por origem: gates de viés por submitter e por torre (quarentena/recalibração) — implementado;
(c) rollback: deploy watchdog com rollback automático de release degradada — implementado.

Gaps conhecidos e rastreados.

3. Dados de torres — qualidade, atualidade, completude¶

~140.906 torres (verificação de 2026-04-30). Completude realista dos campos por torre:

Campo	ANATEL licenciadas (~105k)	OpenCelliD (~35k)
Coordenadas	alta (com deslocamentos ocasionais em torres antigas)	média
Altura	alta	baixa
Potência ERP	alta	ausente
Azimute	parcial	raro
Tilt	parcial	raro

Estimativa honesta: menos de 50% das torres têm os quatro campos críticos confiáveis simultaneamente. Defaults conservadores (altura=30 m, omni) são aplicados quando faltam — aceitável para screening, ruim para parecer.

OpenCelliD em região remota. Em Norte/Centro-Oeste interior, taxa de torres ausentes estimada em 20–40%. Coordenadas erradas: comum em ANATEL antigas (deslocamento de centenas de metros). O nearest-neighbor retorna a mais próxima conhecida — pode ser inexistente em campo. Não há flag de confiança por torre exposta na API. Gap.

Atualização 4x/dia de ANATEL (XLSX LAI) + 4x/dia de OpenCelliD é suficiente para varredura inicial e insuficiente para greenfield em região com construção recente — a cadência do nosso cron não acelera a curadoria manual a montante, que é quem realmente governa quando um site novo aparece na base. Plano B: cadastro manual via POST /towers. Controle de qualidade no insert do usuário: validação de schema apenas. Cliente inserir lixo é risco real — quando dados reais começarem a alimentar o retrain, isso vira contaminação. Mitigação no roadmap.

Indígena/remoto sem candidatas. Sistema retorna vazio. Documentação de plano B: cadastrar manualmente ou subir CSV. Sem integração com bases comunitárias.

4. Limites de plano, performance e escalabilidade¶

Limites enforced em telecom_tower_power_api.py (TIER_LIMITS, ~L1082):

Tier	Calls/mo	Batch/job	Towers/key	PDFs/mo
Free	200	0 (gated off)	20	5
Starter	3.000	100	100	50
Pro	25.000	2.000	500	500
Business	150.000	5.000	sem cap	5.000
Enterprise	500.000	10.000	10.000	100.000

Pro/Business processando 5–10k receivers de uma vez. Pro recusa com HTTP 400 explícito e mensagem parseável; Business aceita 5k; 10k em Business exige split client-side. Nunca enfileira silenciosamente — fail-fast com mensagem determinística (docs/POSITIONING.md).

End-to-end real para 200 torres neutral-host. Estimativa honesta:

/coverage/predict cacheado: ~150 ms; cold: 2–4 s.
Batch 200 em Pro: 5–10 min wall time.
Geração de PDF: ~30 s.
Revisão humana: 2–6 horas.

O bottleneck honesto é a revisão humana — não a infraestrutura.

Dijkstra multi-hop sugerindo rotas inviáveis. Risco real. O custo do edge inclui margem de link, mas com --threshold-db mal calibrado o solver retorna rotas com 0,1 dB de margem. O relatório mostra margem por hop; o engenheiro precisa revisar. Não há gate automático "rejeitar se margem < X dB" por default no Dijkstra de produção — o _UNCOVERED_PENALTY_DB=200.0 existe apenas no GA optimizer (scripts/optimize_sites.py). Gap.

PDFs auditáveis. Hoje contém: versão de modelo, timestamp, inputs. Não contém: hash SHA-256 do conteúdo, assinatura digital, lista exaustiva de fontes de dados externas e suas datas. Para LAI você complementa manualmente. Gap confirmado.

5. Modelo comercial e ROI¶

ROI publicado em roi-by-segment: 27× Pro, 29× Enterprise, 7× consultoria, 6× Tier-2/3 regional. Marcado bottom-up e não-contratual.

Se ganho real for 30% do prometido. Mesmo a 30%, em horizonte de 5 anos uma assinatura Business (R$ 15.588/ano) não cruza o TCO de um seat perpétuo Atoll/Pathloss (R$ 200–500 k upfront + 18–22%/ano manutenção). O risco real não é "ROI 30%" — é ROI zero caso o output não seja aceito pelo cliente final por falta de validação independente (§7).

Consultoria com picos. Custo efetivo por análise: Business R$ 1.299/mês ÷ 50 análises = R$ 26/análise; ÷ 5 análises = R$ 260/análise. Stripe billing portal permite downgrade prorated; pausa de até 90 dias/ano documentada no DPA. Para uso esporádico, o pattern correto é Starter R$ 79/mês + burst para Pro em janelas de projeto.

"Fair use" do Ultra. O EULA define limite numérico real (Ultra = 1M calls/mo, 50k batch rows). "Fair use" é copy de marketing; o número no código é o que prevalece. Upgrade forçado unilateral: não permitido pelo EULA; fornecedor pode rescindir com aviso padrão SaaS.

Free tier real. 200 calls / 5 PDFs / sem IA. Estritamente para avaliação. Lock-in por workflow existe se cliente integrar via API custom, mitigado pelos exports padronizados (KML/SHP/CSV/PDF). Modelos treinados não são exportáveis — coverage_model.npz permanece propriedade do TTP, o que é razoável comercialmente.

6. Maturidade, governança, segurança, riscos¶

SOC 2. Políticas em docs-site/docs/compliance/soc2/ (14 políticas, matriz de controles, índice de evidências, gap analysis, system description) são políticas internas escritas, não auditadas por terceira parte independente. Não existe relatório SOC 2 Tipo II emitido por auditor. Política interna ≠ atestado de auditor — sem dissimulação.

DR / BCP testado. Drill executado em 2026-04-30: S3 restore → fresh PostgreSQL 18, PASS. Um drill registrado. Cadência trimestral/anual recorrente: não há evidência publicada. Gap real.

Bug bounty informal 90 dias. SECURITY.md define ACK 72h / disclosure 90d / safe harbour. Sem programa pago, sem HackerOne/Bugcrowd. Para infraestrutura crítica é fraco; é honesto sobre o que é, e é fraco.

Dependência AWS. Bedrock, ECS Fargate, Lambda, ElastiCache Redis, S3, SSM, Cognito. Custo de migração realista: 4–8 semanas de engenharia. O repositório tem docker-compose.onprem.yml (sinal de awareness) e docs operations/onprem-deployment, mas sem runbook operacional para GCP/Azure. Outage regional sa-east-1: TTP fica fora — sem multi-region active-active hoje.

Bus factor. Real. Um mantenedor visível. Sem SLA contratual de horas-resposta para Business; Enterprise tem SLA negociado caso-a-caso. Recomendação para uso crítico: negocie SLA explícito + escrow de código + identificação de plano B em contrato.

Stripe / Cognito. Subprocessadores declarados no DPA-LGPD.md. Mudança de termos: força maior padrão de mercado.

ANATEL. Não "certifica" ferramentas — aceita o estudo técnico se a metodologia for justificável. P.1812-5 e Longley-Rice são modelos aceitos pela ITU; FSPL+Fresnel é aceito apenas para LOS. O risco prático não é "ANATEL rejeitar TTP"; é fiscal pedir memorial de cálculo e o signatário precisar mostrar input/output/versão por enlace. O PDF atende parcialmente (sem hash, sem assinatura). Sem precedente público de uso em fiscalização contestada.

Cartas de aceitação FUST / Wi-Fi Brasil / integradora. Não existem publicadas hoje. docs/POSITIONING.md não cita nenhum cliente real nominal. Este é provavelmente o maior gap comercial do produto — competência técnica não vende RFP grande sem prova social.

O que parceiros valorizam vs. sub-estimam. Valorizam: velocidade, preço, API moderna, posicionamento honesto. Sub-estimam: precisão real em Mata Atlântica/Amazônia, aceitação regulatória em campo, bus factor de fornecedor único.

8. Síntese para decisão estratégica¶

8.1 Cinco riscos materiais não-transferíveis sem mitigação contratual¶

Bus factor / continuidade — exigir SLA contratual de horas-resposta + cláusula de escrow de código com terceira parte.
Modelo ML treinado só em sintético — exigir que o relatório por enlace identifique fonte (physics vs ml) e usar somente physics (P.1812 ou ITM) para qualquer parecer assinado até haver validação cross-region com drive-test real publicada.
PDF sem hash/assinatura externa — exigir contratualmente hash SHA-256 + input completo no PDF, ou complementar com assinatura ICP-Brasil fora do TTP.
Sem cases públicos com nome + desvio medido vs. campo — exigir piloto controlado antes de compromisso >R$ 50k/ano.
SOC 2 não auditada por terceiro — aceitável para Starter/Pro; para Enterprise exigir Tipo II real ou cláusula de auditoria direta.

8.2 Critério objetivo para piloto de 20–30 enlaces¶

Aprovação: desvio médio absoluto ≤ 8 dB vs. medição de campo em ≥ 80% dos enlaces.

Desvio médio	Decisão
≤ 8 dB	Aprovar para screening + apoio a parecer (com revisão Atoll/Planet no final)
8–12 dB	Usar apenas como screening top-of-funnel; nunca como link budget final
> 12 dB	Rejeitar para o segmento testado

Esse threshold é coerente com o mapeamento de confidence no código (8 dB → 0,9; 13 dB → 0,75).

8.3 Resposta a "por que não planilha + campo + Atoll pontual?"¶

Porque o ganho real do TTP não é substituir Atoll — é eliminar a etapa de planilha (varredura de 200–2.000 candidatos antes de selecionar 20 para análise fina). Use TTP como filtro top-of-funnel e mantenha Atoll/Planet para o memorial final do projeto vencedor. É exatamente o posicionamento de docs/POSITIONING.md e é a posição mais defensável.

8.4 Pior cenário realista em 12–18 meses¶

Fornecedor descontinua, engenheiro indisponível por 30–60 dias, ou modelo apresenta viés sistemático em uma região. Mitigação contratual:

Escrow de código em notário.
Devolução de dados em formato aberto (CSV/SHP) — já são export padrão.
Cláusula de "nunca para parecer final" no procedimento interno do cliente.

Você perde velocidade, não dados. Prejuízo reputacional fica com o signatário do parecer, não com o TTP — por isso a regra "nunca como única fonte".

8.5 O que mudaria a decisão de adesão¶

SOC 2 Tipo II auditada por terceiro independente.
3+ cases públicos com nome de cliente + desvio medido em campo.
SLA contratual: ACK 4h / fix crítico 24h / uptime 95% auditável.
Cláusula de escrow de código em notário.
Validação cross-region do modelo ML com link_observations reais (não sintético).
Roadmap público versionado (GitHub Issues ou Projects público).

9. Síntese final¶

O produto é tecnicamente honesto no que entrega: ITU-R P.1812-5, ITM/Longley-Rice, Sionna RT v2, motor de interferência multi-operador, batch assíncrono real, governança documentada (ainda que não auditada por terceiro), e é explícito sobre o que não é — não substitui o stack interno Tier-1, e isso está em contrato.

As fraquezas reais são: bus factor, ML treinado apenas em sintético, ausência de cases públicos, PDF sem assinatura externa, SOC 2 não auditada. Nenhuma é fatal; todas são negociáveis em contrato.

Recomendação: use como screening de funil sob contrato com escrow e SLA explícitos, nunca como única fonte para parecer assinado, e exija piloto controlado de 20–30 enlaces antes de qualquer compromisso anual significativo.