Os entregáveis (E1–E11)

Portal soberano de LLM: identidade, RAG governado, inferência em hardware próprio e trilha de auditoria imutável — aceite do dono em 2026-09-17. Clique no ID para abrir a ficha completa em evidencias.html — dossiês, notas do auditor e todos os vídeos. As provas estão nos próximos slides.
IDEntregávelAceite VídeosProva
E1Dossiê de escopo e governança✓ 2026-09-17prova documental ↓
E2Ambiente dedicado alugado e isolado✓ 2026-09-17prova documental ↓
E3Portal seguro de uso✓ 2026-09-1766 vídeos ↓
E4Identidade, papéis e revogação✓ 2026-09-1788 vídeos ↓
E5Base de conhecimento governada✓ 2026-09-1788 vídeos ↓
E6Orquestração e inferência soberana✓ 2026-09-1722 vídeos ↓
E7Portal de saída não contornável✓ 2026-09-1755 vídeos ↓
E8Stop Chain / fail-closed✓ 2026-09-1711 vídeo ↓
E9Trilha de auditoria imutável✓ 2026-09-1722 vídeos ↓
E10Pacote de validação e baseline✓ 2026-09-1711 vídeo ↓
E11Automação, operação e handover✓ 2026-09-17prova documental ↓

Provas em vídeo — E3 a E5

E3Portal seguro de uso3 de 6 vídeo(s) · os mais curtos · +3 na ficha
E4Identidade, papéis e revogação3 de 8 vídeo(s) · os mais curtos · +5 na ficha
E5Base de conhecimento governada3 de 8 vídeo(s) · os mais curtos · +5 na ficha

Provas em vídeo — E6 a E10

E6Orquestração e inferência soberana2 de 2 vídeo(s) · os mais curtos
E7Portal de saída não contornável3 de 5 vídeo(s) · os mais curtos · +2 na ficha
E8Stop Chain / fail-closed1 de 1 vídeo(s) · os mais curtos
E9Trilha de auditoria imutável2 de 2 vídeo(s) · os mais curtos
E10Pacote de validação e baseline1 de 1 vídeo(s) · os mais curtos

Provas documentais — E1, E2, E11

E1 — Dossiê de governança assinado

Papéis, corpus e métricas M1–M8 aprovados pelo dono.

refs/governance-mvp-v1.html

E2 — Topologia observada + dossiê

Diagrama zoomável na página: 20 jails, PF por jail, 8 bridges.

refs/DOSSIER-MVP-V1-e2-ambiente-alugado.html

E11 — Código e runbooks de operação

./infra, Pulumi Clojure, contratos assinados, runbooks.

refs/DOSSIER-MVP-V1-e11-operacao.html

E2 · chatsubo-network-architecture.svg

100% scroll para zoom · arraste para mover · ⛶ tela cheia
chatsubo_network_architecture Chatsubo · network architecture · hardening and isolation · declared planes + observed state · 2026-09-22 13:12 UTC cluster_ingress Ingress peers (not Chatsubo) cluster_chatsubo Chatsubo · prod_machine · FreeBSD 64.176.23.125 (vtnet0) · 20 jails · 8 bridges + lo1 cluster_host HOST SURFACE · host PF is NAT-only by design the perimeter is the cloud firewall + per-jail PF cluster_relays PLANE-CROSSING RELAYS · socat on the host lo1 and VNET cannot talk directly cluster_lo1 lo1 PLANE · 127.77.0.0/24 · host alias 127.77.0.1 loopback jails with NO bridge — unreachable from any VNET jail cluster_vnet VNET PLANES · bridge0–bridge6 · 172.31.100–106.0/24 one disjoint bridge + epair per jail · host gateway .1 cluster_slurm TRUSTED SLURM PLANE · bridge9 · 172.31.110.0/24 sandbox domain removed (eb85c03d) · jail PF closes host probes cluster_enverge Enverge DGX Spark cluster the operator's own inference hardware browser Browser / API client cloudfw Vultr cloud firewall · THE OUTER PERIMETER exactly 4 rules (opentofu/chatsubo-vultr/main.tf) 80/443 → 0.0.0.0/0 22 → two pinned /32s, nothing else browser->cloudfw public TCP 80 / 443 relay Vultr relay · 216.238.118.15 public ingress + wg2 spoke hub wg0 UDP 51820 · wg2 UDP 51822 cloudfw->relay 80/443 only 22 gated to two /32s chatsubo_host ✓ nginx · TLS termination · vtnet0 80 / 443     chatsubo… → 127.77.0.11:8080     grafana… → 127.77.0.21:3000 · htpasswd 401     keycloak… → 172.31.105.2:8080 ✓ sshd · deploy receiver · vtnet0 22 · forced command ✓ wg0 · management VPN · 10.222.0.14/32 ✓ alloy · log shipper :9200 → loki PF NAT on vtnet0 for the VNET and Slurm planes relay->chatsubo_host PF DNAT + SNAT over wg0 · 10.222.0.14 neotek NeoTek · 10.222.0.254 wrkflw deploy sender neotek->chatsubo_host SSH TCP 22 pinned host key forced command chatsubo_lo1 ✓ openwebui_linux · 127.77.0.11:8080 ✓ postgres · 127.77.0.2:5432 ✓ redis · 127.77.0.3:6379 ✓ tika · 127.77.0.4:9998 ✓ searxng · 127.77.0.5:8888 ✓ openterminal · 127.77.0.12:8000 ✓ grafana · 127.77.0.21:3000 ✓ loki · 127.77.0.22:3100 ✓ prometheus · 127.77.0.23:9090 chatsubo_host->chatsubo_lo1 Host: chatsubo… TCP 8080 Host: grafana… TCP 3000 chatsubo_host->chatsubo_lo1 alloy → loki 3100 grafana → 3100 / 9090 chatsubo_vnet ✓ small-pine · bridge0 · 172.31.100.2:8080 · health {"ok":true}     ingress allowlist = 172.31.100.1 only (the host gateway)     egress allowlist = exactly 10 named peers, nothing else routable     → kafka · qdrant · datomic 5432/4334 · openldap · keycloak · minio ✓ kafka · bridge1 · 172.31.101.2:9092 ✓ qdrant · bridge2 · 172.31.102.2:6333 ✓ datomic · bridge3 · 172.31.103.2:5432,4334 ✓ openldap · bridge4 · 172.31.104.2:389,636 ✓ keycloak · bridge5 · 172.31.105.2:8080,9000 ✓ minio · bridge6 · 172.31.106.2:9000 · never dials out every jail: block in all + an explicit per-peer allowlist chatsubo_host->chatsubo_vnet Host: keycloak… TCP 8080 straight to VNET chatsubo_slurm ○ slurm-accounting · 172.31.110.2:3306 ○ slurm-dbd-trusted · 172.31.110.3:6818,6819 ○ slurm-trusted-controller · 172.31.110.6:6817     scontrol ping UP · stage1 State=DOWN (admission closed on purpose) ✓ slurm-spoke-gateway · 172.31.110.9 + wg2 10.24.0.2     wg2 lives INSIDE this jail     blocks Spark↔Spark (10.24.0.0/24 → 10.24.0.0/24) chatsubo_host->chatsubo_slurm bridge9 chatsubo_relays ✓ inference relay · lo1 → VNET     127.77.0.1:8080 → 172.31.100.2:8080 ✓ LDAP relay · lo1 → VNET     127.77.0.1:636 → 172.31.104.2:636 ✓ openterminal relay · VNET → lo1 (reverse)     172.31.100.1:8000 → 127.77.0.12:8000 chatsubo_relays->chatsubo_lo1 8000 chatsubo_relays->chatsubo_vnet 8080 / 636 source becomes .1 the only ingress chatsubo_lo1->chatsubo_relays OpenAI /v1 8080 LDAPS 636 chatsubo_vnet->chatsubo_relays terminal I/O → 172.31.100.1:8000 sparks spark01 · enverge.dev · SSH 22 · wg2 10.24.0.11 · vLLM model jobs spark02 · wg2 10.24.0.12 · air-gapped (every SSH login ever came from spark01) no third-party API and no NeoTek small-infer router anywhere in this path chatsubo_vnet->sparks SSH 22 → 35.189.126.228 sbatch · squeue · scancel model tunnel chatsubo_slurm->chatsubo_vnet job events 9092 chatsubo_slurm->sparks wg2 UDP 51822 srun 60001–60128 sparks->relay wg2 peer proof Why this is hardened and isolated # Invariant 1 One public ingress. The Vultr cloud firewall admits 80/443 and nothing else; SSH 22 only from two pinned /32s. 2 The real perimeter is per-jail, not the host. Every jail runs block in all plus an explicit allowlist. 3 small-pine egress is exactly 10 named peers ( small_pine_egress_peers ). Anything unlisted is unroutable. 4 small-pine ingress is 172.31.100.1 only — the host gateway, reached through the inference relay. 5 Eight disjoint address planes: bridge0–bridge6 plus Slurm bridge9, each its own /24 with an epair per jail. 6 lo1 has no bridge at all. Its nine jails are loopback-only and unreachable from any VNET jail. 7 Planes cross only through three host socat relays — each a single named port pair, no routed path between planes. 8 The Slurm plane is trusted-only: the sandbox domain is removed and jail PF closes every host-originated probe. 9 Inference is sovereign: DGX hardware reached by pinned SSH and the wg2 overlay — no third-party API, no NeoTek router. 10 spark02 is air-gapped, and the spoke-gateway blocks Spark↔Spark, so one compromised node cannot reach its sibling. legend Mark / line Meaning declared AND observed live (jail up, TCP probe open) declared, but probe closed by design — the closed probe IS the isolation ━━ user / API traffic ━━ Small Pine backend + plane-crossing relay ━━ WireGuard overlay (wg0 host · wg2 in-jail) ━━ trusted Slurm control plane ┅┅ deployment / control red box outer perimeter (Vultr cloud firewall) orange box Small Pine integration boundary green box lo1 loopback plane — no bridge amber box isolated Slurm plane; a closed host probe is the design rose box sovereign inference hardware (operator-owned)
O mapa real da rede: um ambiente dedicado e isolado, com a inteligência rodando em hardware próprio. Uma única porta aberta para a internet, cada serviço separado dos demais e nenhuma dependência de provedor externo.

Além de mais hardware

Melhorias que mudam o produto ou a garantia que ele oferece — não apenas capacidade. Cada uma com o estado real hoje.

Por que esta stack

O que cada tecnologia resolveu no produto — sem jargão — e o que ela entregou na prática. Superfícies públicas: chatsubo.ianfernandez.tec.br · keycloak.ianfernandez.tec.br · grafana.ianfernandez.tec.br — todo o resto é rede interna ou túnel privado.
FreeBSD

FreeBSD

Por que precisou: Separar cada serviço num compartimento próprio, dentro de uma única máquina, sem precisar de várias máquinas.

Deu certo: Um serviço com problema não derruba os outros, e cada um só fala com quem deve — tudo num servidor só, mais barato de manter e com muita segurança. É o sistema usado em servidores pelo mundo — um UNIX moderno e consagrado.

Clojure

Clojure

Por que precisou: Construir o sistema de forma que cada mudança seja testável e não quebre o que já funciona.

Deu certo: O produto cresceu para ~96 módulos sem virar uma bola de neve — dá para mexer numa parte sem medo de estragar outra. Linguagem super estável, que não quebra seus contratos — é a que o Nubank usa.

Datomic

Datomic

Por que precisou: Guardar o histórico de tudo que acontece no sistema, sem nunca sobrescrever o que já foi registrado.

Deu certo: Qualquer ação pode ser consultada depois, como era e quando foi — a base da trilha de auditoria que não pode ser apagada. Banco imutável do mesmo autor do Clojure, usado por grandes empresas onde histórico é coisa séria.

Pathom 3

Pathom 3

Por que precisou: Ferramenta de grafo de decisão que facilita entregar a informação certa: a tela pede só o que precisa e o sistema descobre sozinho o caminho para montar a resposta, sem criar uma saída nova para cada pergunta.

Deu certo: Uma única porta de leitura para tudo, e a permissão vale para a informação inteira — não precisa liberar tela por tela. Biblioteca brasileira do ecossistema Clojure, feita para isso e usada em produção.

Keycloak

Keycloak

Por que precisou: Ter um login único e seguro, usando as contas que a empresa já tem, em vez de criar senhas novas para cada pessoa.

Deu certo: A pessoa entra uma vez e usa o portal, os painéis e a administração com a mesma conta — e sair de um lugar encerra o acesso. Produto da Red Hat, padrão de mercado em login corporativo.

Grafana + Loki + Prometheus

Grafana + Loki + Prometheus

Por que precisou: Ver a saúde do sistema — o que está lento, cheio ou falhando — em telas prontas, sem depender de alguém olhar logs na mão.

Deu certo: O operador enxerga o estado de tudo num só lugar e percebe um problema antes de virar incidente. É o padrão de mercado em monitoração — praticamente toda empresa de tecnologia usa.

Slurm + vLLM

Slurm + vLLM

Por que precisou: Organizar a fila de quem pede inteligência artificial e atender várias pessoas ao mesmo tempo no mesmo hardware.

Deu certo: Muitos usuários usam juntos sem travar, e o hardware caro é aproveitado ao máximo em vez de ficar ocioso. O Slurm é o escalonador dos maiores supercomputadores do mundo; o vLLM é o motor de inferência aberto mais usado.

sem
logo

Kafka

Por que precisou: Acompanhar o que acontece com cada tarefa de IA — quando termina, em qual máquina — sem que nada sensível (código, caminhos, segredos) vaze junto.

Deu certo: Um canal de eventos enxuto e privado: só o essencial de cada tarefa concluída, e a operação enxerga o ciclo de vida sem expor conteúdo. A trilha de auditoria e o replay de sessão rodam em outros componentes — o Kafka é o canal de eventos, não o cofre.

Open WebUI

Open WebUI

Por que precisou: Ter uma interface de conversa pronta — chat, envio de arquivo, escolha de modelo — sem precisar construir uma do zero.

Deu certo: O produto ficou utilizável rápido, com cara de produto, e o esforço foi para o que é exclusivo dele, não para reinventar um chat. Uma das interfaces abertas de IA mais usadas, com comunidade enorme.

WireGuard

WireGuard

Por que precisou: Conectar com segurança as máquinas e as pessoas ao sistema, por um canal privado, mesmo de longe.

Deu certo: Operações e testes atravessam a internet por um túnel fechado — nada sensível trafega aberto. VPN moderna, já dentro do kernel do Linux e adotada como padrão do mercado.

sem
logo

Presidio + OpenMed

Por que precisou: Apagar dados pessoais — nome, CPF, telefone — antes de guardar ou mostrar qualquer conteúdo.

Deu certo: Mesmo que alguém envie um documento com dados sensíveis, eles não entram na base nem aparecem nas respostas. O Presidio é da Microsoft; o OpenMed é da NVIDIA, especializado em dados de saúde.