Dossiê de demonstração — Aurora Logística (KYC/KYB)

O ativo de demonstração do vertical KYC/KYB: um dossiê de abertura de conta PJ inteiramente fictício, com 23 documentos coerentes entre si e os achados plantados que fazem a demonstração contar a história completa — da divergência societária ao beneficiário final escondido quatro níveis abaixo.

Todos os documentos carregam o aviso de dado fictício no cabeçalho. Empresas, pessoas e valores são inventados; os dígitos verificadores de CNPJ/CPF são válidos apenas para exercitar a validação da plataforma. Em estande ou apresentação, diga em voz alta que o dado é fictício.

A história

Aurora Logística e Participações Ltda (CNPJ 12.345.678/0001-95) abre conta. Nenhum sócio direto passa de 25%:

Mas a cadeia continua: Ricardo Andrade Meira detém 75% da Vega Investimentos, que detém 75% × 24% = 18% da Aurora via Andrômeda — e mais 65% da Cassiopeia, ou seja 13% por um segundo caminho. Total efetivo: 31%, por dois caminhos distintos, na quarta camada da cadeia — e a declaração de beneficiário final afirma que ninguém atinge 25%. Essa é a divergência que a triagem deve acender e a evidência lado a lado deve mostrar.

O que está plantado

O ramo da Delta é deliberado e parece descuido, então vale explicar. Ela é sócia de 18% e o dossiê não traz nem o contrato social dela nem o cartão CNPJ — um dossiê real chega assim com frequência. O efeito é o que o analista precisa ver: há um pedaço da cadeia societária que não se fecha, e o laudo diz qual é. Ele não desloca o clímax — a omissão de beneficiário final do Ricardo segue sendo o achado principal, e a Delta é o segundo, que mostra a diferença entre documentos que se contradizem e documento que não existe. Fechar o ramo custaria os dois achados e quebraria os "vinte e três documentos" que o roteiro fala em voz alta.

Como carregar

O fixture versionado é o gerador (scripts/demo/dossie-aurora/gerar-dossie.py), não os arquivos: as datas das certidões são relativas ao dia da carga, para que "vencida há 11 dias" seja verdade no dia da demonstração.

# In-cluster (S2S) — o seed gera os 23 documentos e os envia pela INGESTÃO
# REAL (lote com CNPJ-alvo → NER → reconciliação → cruzamento → triagem):
CONTEXTO=OnboardingPJ \
DATTA_INTERNAL_TOKEN=<token S2S> \
./scripts/seed-dossie-aurora.sh

Pré-requisitos: um contexto do tipo Dossiê Cadastral (KYC/KYB) e os modelos BPMN publicados (onboarding-pj-kyb com auto-início, pendencia-compliance). O datta:contexto dos arquivos-semente já é OnboardingPJ, que é o default do seed-dossie-aurora.sh. Se o contexto cadastrado tiver outro nome, ajuste o atributo antes de publicar — com um nome que não existe, a fase de triagem falha com "contexto não cadastrado". O seed também semeia os prompts KYB do contexto (NER, triagem e sistema — sem isso o NER cai no prompt jurídico default e o grafo societário não nasce), garante os 44 critérios KYB (scripts/criterios-kyb-exemplo.json) e registra o dossiê de demonstração no Knowledge Catalog.

O seed não grava nada por fora: todo o grafo (empresas, sócios, percentuais, certidões, procurações) nasce do NER sobre os documentos, como num dossiê real.

Recarregar exige purgar

O identificador do documento é o hash SHA-256 do conteúdo, e o conteúdo deste fixture muda a cada dia — as datas são relativas à --data-base, por desenho. Reexecutar o seed em outro dia, ou depois de mexer no gerador, acumula um segundo dossiê em vez de substituir o primeiro, e a triagem passa a ler as duas versões juntas.

Medido em 2026-08-11: uma reexecução após corrigir as certidões deixou 43 documentos e 45 chunks (eram 23 e 24), e o laudo seguiu citando as certidões velhas — vencidas — que o gerador tinha acabado de corrigir.

Para substituir de verdade:

PURGAR=1 ./scripts/seed-dossie-aurora.sh

PURGAR=1 chama o purge do contexto (a mesma operação da tela, com cascata das instâncias BPM) antes de carregar. Sem a variável o script apenas avisa ao encontrar dossiê anterior — nunca apaga nada sozinho.

Roteiro de demonstração (3 minutos)

1. Onboarding PJ → dossiê da Aurora → aba Critérios: a divergência societária em vermelho, com a evidência lado a lado (contrato social × declaração de beneficiário final).
2. Aba Grafo societário: a cadeia se desenha; o caminho até Ricardo acende — 31% por dois caminhos, nenhum sócio direto acima de 25%.
3. Pendências de Compliance: certidões e critérios reprovados numa lista; a certidão trabalhista já com tratamento registrado em processo BPM — quem decidiu, quando e por quê.

O roteiro roda pelo console, não pela instância do fluxo: a resolução de beneficiário final e a leitura do dossiê são consultas próprias do console, independentes de o processo BPM ter avançado.

Por que nenhuma certidão nasce vencida

Medido no cluster em 2026-08-11: o gateway Gw_Completo do modelo exige statusTriagem == 'CONFORME' para seguir à fase de UBO. Uma certidão vencida fecha o critério KYB-COMP-3 em ANOMALIA, e o fluxo entra no ramo "Incompleto" → Solicitar documentos → Documentos recebidos → completude de novo, sem nunca alcançar T_Ubo. O laudo parava nos 3 critérios da fase de completude em vez dos 44, e a parte societária — o clímax do roteiro — não acontecia no fluxo.

Por isso as certidões do dossiê vencem em breve, nunca no passado: dentro da janela de alerta (30 dias, DIAS_ALERTA_PADRAO) elas continuam aparecendo no Painel de Pendências, que era o papel delas no roteiro, sem reprovar a completude.

O gate segue com a semântica atual: qualquer anomalia de completude bloqueia. Distinguir documento ausente de documento presente porém vencido exigiria um sinal de severidade que a triagem ainda não emite — temAnomaliaCritica não serve, é derivado de contagem (anomalias >= 3).

Operar sem internet (feira, estande, ambiente isolado)

A plataforma é on-premises por desenho, mas isso não basta para garantir que a demonstração sobreviva à queda do Wi-Fi. Os provedores de LLM, NER, embedding e rerank são ajustes por contexto, não do chart — e um contexto criado sem escolher provedor nasce em gemini, que sai do cluster. É a escolha certa em produção com rede e a errada no estande.

O modo de falha é o pior possível: tudo passa no ensaio, com Wi-Fi, e quebra na frente do comprador. Meça antes:

CONTEXTO=OnboardingPJ DATTA_API_URL=http://<gateway>:7070 DATTA_JWT=<accessToken> \
  ./scripts/demo/preflight-offline.sh

O script só lê — não altera nada — e verifica cinco pontos:

Códigos de saída: 0 aprovado, 1 há dependência de internet no caminho vivo da demonstração, 2 erro de configuração do próprio script.

O que o preflight não cobre. Ele mede o caminho da demonstração, não o cluster inteiro: telemetria, atualização de base negativa pública e qualquer pipeline agendado continuam querendo rede, e falham em silêncio sem afetar a demonstração. Desligue os agendamentos antes do evento se quiser o log limpo.