Due Diligence FAQ¶

Audience: procurement, security, legal e engenharia técnica do cliente em avaliação formal antes de assinar contrato. Authority: este documento, em conjunto com POSITIONING.md, EULA, DPA-LGPD e SECURITY.md, forma a resposta consolidada a auditorias de aquisição. Last reviewed: 2026-07-22 (números de modelo re-gerados automaticamente a cada retrain por scripts/sync_claim_surfaces.py).

Honestidade técnica vence marketing. Se uma pergunta abaixo não tiver resposta direta no produto, ela é declarada como gap e não como feature.

1. Natureza do produto¶

1.1 O repositório público é "simulação/protótipo". O que estou contratando?¶

O repositório github.com/danielnovais-tech/TELECOM-TOWER-POWER é a implementação clean-room dos engines de propagação, do worker de interferência, do planejador multi-saltos e dos pipelines de dados. A SaaS em produção (api.telecomtowerpower.com.br) executa o mesmo código com:

secrets gerenciados (AWS SSM Parameter Store),
banco PostgreSQL gerenciado (RDS),
cache Redis dedicado por tier,
artefatos ML hot-pulled de S3,
observabilidade (Prometheus + Grafana + Alertmanager + Jaeger).

Não há "núcleo proprietário escondido". As diferenças entre o repositório público e a SaaS são integração e operação, não capacidade de cálculo.

1.2 Como reconciliam "todas as features em produção desde abril/2026" com o status "GA single-link / coverage raster pendente" de alguns engines?¶

A tabela canônica de status por engine vive em docs-site/docs/operations/technical-validation-and-limitations.md. Resumo:

Engine	Status	Evidência
FSPL (Friis)	GA — engine de referência	`rf_engines/fspl_engine.py`
ITU-R P.1812-7	GA — engine de referência para NLOS	`rf_engines/itu_p1812_engine.py` + dep `Py1812`
ITM / Longley-Rice	GA via `itmlogic==1.2`	`rf_engines/itmlogic_engine.py`
Sionna RT 2.x (single-link)	GA	`rf_engines/sionna_rt_engine.py`
Sionna RT coverage raster (mass)	Roadmap	gated by `SIONNA_RT_DISABLED=1` por padrão até artefato benchmark validado
Residual LightGBM	GA — em produção, grau de triagem dentro do envelope calibrado (métricas vivas: `GET /coverage/claim-readiness`)	`rf_engines/residual_model.py`
MapBiomas clutter no edge cost do repeater	Parcial — extrator GA, integração no Dijkstra é roadmap	Detalhe em POSITIONING.md §10.2
Rain attenuation P.530/P.838 no edge cost	Roadmap	Detalhe em POSITIONING.md §10.2

Concordância cross-engine validada em 5 macrorregiões BR: P.1812 vs ITM dentro de ±0.5–3 dB em 5/5 enlaces de teste cobrindo CO, SE, N, NE e zona marítima, incluindo um NLOS over-horizon de 173 km.

2. Precisão técnica¶

2.1 O RMSE publicado é aceitável para tender / licenciamento ANATEL?¶

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.

2.2 SRTM 90 m é suficiente para zona de Fresnel em terreno acidentado?¶

Não universalmente. Em Serra do Mar, Mantiqueira, Caparaó, Espinhaço, knife-edges críticos para Fresnel podem ser mascarados a 90 m. Esse risco está explicitamente listado em technical-validation-and-limitations.md §5. NASADEM 30 m e ALOS PALSAR 12,5 m estão no roadmap de elevação. O plan_repeater aplica penalidade conservadora de knife-edge para enviesar a saída no lado seguro.

2.3 Como testo se as explicações em linguagem natural via Bedrock (Claude) estão tecnicamente corretas?¶

Três salvaguardas existem:

O modelo só recebe números calculados pelos engines determinísticos como input — ele explica, não calcula.
Toda explicação inclui referência ao engine que produziu o número (engine: itu-p1812 ou engine: itmlogic), permitindo reproduzir o número fora do LLM.
O cliente pode desabilitar o componente Bedrock por tenant via flag BEDROCK_DISABLED=1 — os endpoints determinísticos continuam funcionando sem o LLM.

Se ainda houver dúvida de alucinação, o /coverage/engines/compare retorna os números crus de N engines lado a lado, sem narrativa.

3. Qualidade dos dados¶

3.1 Qual é a freshness real da base de torres?¶

ANATEL ERBs (105.240 sites SMP/SME, planilha obtida via LAI): sincronização automatizada 4x/dia (00:05/06:05/12:05/18:05 UTC) pelo workflow .github/workflows/pull-anatel.yml, que re-ingere apenas quando o SHA do arquivo upstream muda.
ANATEL MOSAICO (base de licenciamento): carga manual, sem cron. É um artefato distinto da planilha LAI acima; não confundir as duas cadências (rastreado em #1746).
OpenCelliD (complemento crowd-sourced): sincronização 4x/dia (00:25/06:25/12:25/18:25 UTC) por .github/workflows/pull-opencellid.yml.
Total em produção (verificável agora): curl https://api.telecomtowerpower.com.br/health → towers_in_db: 140498.

3.2 Como tratam "torres fantasmas" / dados estale?¶

Cada tower carrega data_source (anatel_mosaico ou opencellid), last_seen_at e confidence. O endpoint /towers/nearest permite filtro min_confidence e max_age_days. OpenCelliD entries sem corroboração ANATEL têm confidence < 0.7 por construção — clientes que exigem dado regulatório-grade filtram para min_confidence=0.9 e ficam apenas com sites ANATEL.

3.3 Zonas de chuva ITU-R e clutter ANATEL/MapBiomas estão integrados ou são roadmap?¶

Climate region BR (ITU-R P.1812 N₀ + ΔN): integrado e ativo. Validado nos 5 testes cross-engine (CO/SE/N/NE/maritime — climate region detected per-tower).
MapBiomas clutter extractor: integrado para os engines Sionna; não está totalmente integrado no edge cost do plan_repeater — declarado em POSITIONING.md §10.2.
P.530 / P.838 rain term: roadmap (não integrado hoje no Dijkstra do repeater).

4. Limites e ICP¶

4.1 Limites de batch (500/10k torres/query) são gargalo para tender de portfólio inteiro?¶

Para portfólios > 10 mil torres em um único request, sim — a recomendação é o plano Ultra (10k/query) com paginação async via /jobs/{id}, ou Enterprise sob negociação. Para portfólios típicos de WISP regional (300–2.000 torres candidatas), o plano Pro (500/query) cobre sem paginação.

4.2 Plano Free (200 chamadas/mês) ou Starter (R$ 79) bastam para "link em segundos e portfólio em uma noite"?¶

Free (200 calls/mês): suficiente para POC, avaliação inicial, projetos acadêmicos, integrações de teste. Não é dimensionado para portfólio em produção.
Starter (R$ 79): ~5.000 calls/mês — suficiente para consultoria autônoma com 1–3 projetos concorrentes pequenos.
Pro / Business: dimensionado para WISP regional ou consultoria com pipeline contínuo.

5. Modelo comercial e ROI¶

5.1 O ROI 28× / payback 13 dias é contratual?¶

Não. É estimativa bottom-up baseada em premissas declaradas: custo de viagem de campo evitada (R$ 800–1.500), tempo de engenheiro RF reduzido (4–8 h por enlace), licença ATOLL/Planet evitada. Está documentado como non-contratual em POSITIONING.md §6. O que é contratual:

SLA de disponibilidade por tier (ver §6 abaixo).
Latência p50/p95 medida em produção (Prometheus público em prometheus.telecomtowerpower.com.br).
Penalidade por downtime acima do SLA (cláusula no EULA).

5.2 Fair-use "ilimitado" do Ultra tem throttling escondido?¶

O termo "ilimitado" no Ultra refere-se a uso justo dentro da capacidade dimensionada (rate limit 2000 req/min por API key). Acima disso, o sistema responde 429 Too Many Requests com header Retry-After. Não há renegociação automática de preço — clientes recorrentemente acima da capacidade são reclassificados para Enterprise com SLA dedicado.

6. Governança e risco operacional¶

6.1 SOC 2: auditoria externa ou auto-declarada?¶

Hoje: pacote de prontidão SOC 2 Type II autodeclarado, 76 controles, 5 critérios TSC (Security/Availability/Confidentiality/Processing Integrity/Privacy). Documentação completa em docs-site/docs/compliance/soc2/.

Auditoria externa Type I/II: target Q4 2026. O auditor será nomeado e o relatório publicado em compliance/audit/ quando concluído. Clientes Enterprise podem solicitar antecipadamente o "auditor walkthrough package" sob NDA.

6.2 Bus factor / code escrow¶

Manutenção: mantenedor principal nomeado em NOTICE e CONTRIBUTING.md. Sucessão técnica formal documentada para clientes Enterprise sob NDA.
Code escrow: disponível como add-on Enterprise via terceiro escrow agent (NCC Group ou Iron Mountain). Cláusula de release em caso de bankruptcy, dissolution, ou non-cure breach de SLA por > 90 dias.
License pivot automático: LICENSE.md estabelece relicensiamento automático para Apache-2.0 em 2026-05-01... [correção:] 2028-05-01. Mesmo sem escrow, em 2028 o código atual fica permanentemente sob licença permissiva.

6.3 Dependência sa-east-1: qual o plano se houver outage prolongada?¶

Risk acceptance: documentado em compliance/soc2/policies/06-business-continuity.md §5.
Warm standby: Railway (região US-East-2, secundária) com Route 53 health-check failover automático.
RTO/RPO por tier: Free 4h/24h · Starter 2h/12h · Pro 1h/4h · Business 30min/2h · Enterprise 30min/1h · Ultra 15min/15min.
Restore drill: verificado toda segunda-feira 07:15 UTC (workflow backup-restore-drill.yml), com row-count assertions em towers, api_keys, alembic_version.
Multi-region active/active: explicitamente fora de escopo atual e declarado como risco residual aceito.

6.4 Modelo de licença DOSP (Delayed Open Source Publication)¶

LICENSE.md: proprietária até 2028-05-01, depois Apache-2.0 automática. É decisão deliberada de monetização (modelo BUSL-like, similar a Sentry/CockroachDB/MariaDB MaxScale), não sinal de imaturidade. Para a contraparte, isso significa:

Hoje: uso comercial só sob EULA.
A partir de 2028-05-01: versão hoje em main passa a ser permissiva. Vendor lock-in tem horizonte finito e contratualmente determinado.

7. Aceitação regulatória¶

7.1 ANATEL/FUST aceitam parecer técnico gerado por API SaaS de terceiros?¶

Resposta honesta: Não há precedente formal de protocolo aceito junto à ANATEL sob a marca "Telecom Tower Power" — o sistema é jovem (lançamento abril/2026). O que é factível hoje:

PDF institucional emitido pelo TTP inclui assinatura do engenheiro responsável (CREA) do cliente — o parecer continua sendo do engenheiro, com o TTP como ferramenta.
Exportações em KML/SHP/GeoJSON são compatíveis com formato aceito pela ANATEL.
Resultados são reproduzíveis via API + engine: itu-p1812 documentado — auditável pelo regulador.

Para clientes que exigem track record formal de aceitação regulatória, recomenda-se POC paralelo (ver §9).

8. Síntese — três riscos materiais aceitos¶

A empresa contratante, ao assinar, está aceitando explicitamente:

Risco de single-region (sa-east-1) com warm standby Railway, RTO por tier conforme §6.3.
Risco de SOC 2 sem certificação externa concluída até Q4 2026 (mitigado por pacote de prontidão publicado e clientes Enterprise com walkthrough sob NDA).
Risco de cobertura RF parcial em regimes de chuva pesada (zonas ANATEL M/N/P) e vegetação densa Atlântica/Amazônica em links acima de 6 GHz — onde os termos P.530/P.833 ainda não entram no edge cost do plan_repeater.

Os três riscos estão documentados antes da assinatura, não descobertos depois.

9. POC de 30 dias (recomendado para contratos > R$ 50k/ano)¶

Cliente fornece 10 enlaces reais de seu portfólio com drive-test de RSSI medido. TTP executa predição via P.1812 e ITM, entrega:

Tabela predicted vs measured (dBm) com bias, MAE e RMSE por enlace.
Critério de aceite numérico — sugerido: RMSE ≤ 12 dB em ≥ 80% dos enlaces (negociável conforme banda e terreno).
Se reprovar, sem cobrança. Se aprovar, contrato anual com cláusula de re-verificação semestral.

Solicite via sales@telecomtowerpower.com.br referenciando "POC drive-test".

10. Exportação de dados e portabilidade (LGPD Art. 18)¶

Formato	Endpoint	Tier mínimo
JSON (raw)	`GET /tenant/export`	Free
KML	`GET /coverage/export?format=kml`	Starter
Shapefile (ZIP)	`GET /coverage/export?format=shp`	Pro
GeoJSON	`GET /coverage/export?format=geojson`	Free
PDF institucional	`POST /reports/generate`	Pro
Audit log completo (CSV)	`GET /tenant/audit?format=csv`	Business

Em caso de cancelamento, dump completo é entregue em até 7 dias úteis (Art. 18 LGPD) e dados primários são apagados em até 30 dias após confirmação do cliente (hard-delete automatizado, log de evidência preservado por 5 anos por requisito fiscal).

Contato para due diligence aprofundada¶

Engenharia / técnico: engineering@telecomtowerpower.com.br
Segurança / SOC 2 walkthrough (NDA): security@telecomtowerpower.com.br
Legal / contratos: legal@telecomtowerpower.com.br
DPO / LGPD: dpo@telecomtowerpower.com.br

Tempo médio de resposta para due diligence formal: 2 dias úteis.