Ativos de demonstração das verticais — caso PLD e operação de crédito

Dois dossiês inteiramente fictícios que completam a história do dossiê da Aurora. O princípio de demonstração é explícito: um cliente fictício, três momentos, uma plataforma — a pior demonstração possível é mostrar três produtos desconectados.

Todos os documentos carregam o aviso de dado fictício no cabeçalho. Em estande ou apresentação, diga em voz alta que o dado é fictício.

A história, nos três momentos

Momento	Vertical	Quem	Fixture
1. A conta é aberta	KYC/KYB	Aurora Logística	`demo/dossie-aurora/`
2. Uma empresa da cadeia vira caso	PLD/FT	Cassiopeia, sócia de 20% da Aurora	`demo/caso-pld/`
3. A Aurora pede crédito	Crédito documental	Aurora Logística	`demo/operacao-credito/`

A continuidade não é retórica: os CNPJs e CPFs são os mesmos nos três fixtures, e make fixtures-demo-check reprova se divergirem. O beneficiário final que o KYB encontrou escondido quatro níveis abaixo — Ricardo Andrade Meira — é o mesmo que controla a investigada do caso de PLD.

Caso de PLD/FT — `CASO-2026-0417`

Investigada: Cassiopeia Administração e Participações. Doze documentos: abertura do caso, registro do alerta, ficha cadastral, extrato do período, troca de correspondência com o cliente, consultas societárias e de listas, e a análise preliminar.

Achado	Critério
Alerta com regra, data e valor registrados	PLD-ENQ-1 verde
Análise dentro do prazo (12 de 30 dias)	PLD-ENQ-4 verde
Cadastro desatualizado há 26 meses (política: 24)	PLD-CAD-1
R$ 4,2 mi movimentados contra R$ 380 mil de faturamento declarado	PLD-MOV-1
Aporte de R$ 1,8 mi sem origem comprovada	PLD-MOV-3
Investigada e contraparte controladas pela mesma pessoa	PLD-VIN-2
Mesmo endereço, telefone e contador de conta já comunicada ao Coaf	PLD-VIN-3
Beneficiário final comum a outro caso em aberto	PLD-VIN-4
Coincidência de nome em lista restritiva não confirmada	PLD-NEG-2 pendente

O último é o mais importante da demonstração, e é o único cujo resultado correto não é anomalia. Um homônimo sem confirmação documental tem de sair como pendente, com a ressalva explícita no laudo. É o que separa uma camada de investigação auditável de um gerador de acusações — e é a resposta pronta para a objeção "e se a IA alucinar?".

Operação de crédito — `EMP-2026-0912`

Tomadora: Aurora Logística. O contexto de dados é o Emprestimos, que já existia e foi reusado em vez de duplicado — por isso a chave do dossiê é EMP-2026-0912, no formato numeroPedido da âncora daquele contexto. Chave em outro formato entraria sem âncora e o dossiê não seria encontrável pela tela. Os critérios de crédito vivem no próprio Emprestimos (contexto de dados E de regra), com regrasContextos: ["Emprestimos"] — o mesmo padrão de auto-referência do PLD. Medido em produção em 2026-08-22: um contexto de regra separado exigiria que ele existisse como contexto, e criar um CreditoDocumental só para isso é o oposto de reusar o Emprestimos.

Dez documentos: aprovação interna, cédula de crédito bancário, procuração do signatário, anexo da frota alienada, comprovantes de registro, apólice, demonstrações financeiras e o checklist de formalização.

Achado	Critério
Prazo aprovado 36 meses × formalizado 48 meses	CRED-COE-2 crítica
Valor do principal coerente entre aprovação e instrumento	CRED-COE-1 verde
Averbação da cessão fiduciária sem comprovação e sem dispensa	CRED-CP-2
Alienação fiduciária sem comprovante de registro	CRED-GAR-4
Apólice do bem vencida antes da data prevista de desembolso	CRED-GAR-5
Procuração vencida na data da assinatura	CRED-POD-3

A divergência de prazo é o clímax deste ato. Formalizar condição diferente da aprovada é o achado que a auditoria interna procura, e é invisível para quem lê só o instrumento — só aparece com os dois documentos lado a lado, que é exatamente a tela de evidência do produto.

A procuração é uma armadilha de medição deliberada: ela está vigente na data da análise e vencida na data em que o instrumento foi assinado. Quem conferir "vigente hoje" a aprova; o critério cobra a vigência na data da assinatura.

Como carregar

O fixture versionado é o gerador, não os arquivos: as datas são relativas ao dia da carga, para que "alerta há 12 dias" seja verdade no dia da demonstração.

bash

DATTA_API_URL=http://<gateway>:7070 DATTA_JWT=<accessToken> \
  ./scripts/seed-demo-vertical.sh pld

DATTA_API_URL=http://<gateway>:7070 DATTA_JWT=<accessToken> \
  ./scripts/seed-demo-vertical.sh credito

Pré-requisitos, e eles não são criados pelo seed:

Para pld: um contexto chamado InvestigacaoPLD, do tipo Investigação PLD/FT, com regrasContextos: ["InvestigacaoPLD"].
Para credito: o contexto Emprestimos já existente, com regrasContextos: ["Emprestimos"] acrescentado (auto-referência).
Em ambos: o modelo BPMN correspondente publicado.

Cadastrar contexto exige CONFIG_EDIT — é ato de admin, e um token de serviço é recusado por desenho. Contexto sem regrasContextos fica com corpus de regras vazio: não há default por tipo, e a triagem não encontraria critério nenhum. O seed também semeia os prompts do contexto — sem eles o NER cai no prompt jurídico padrão e o grafo do caso não nasce.

Recarregar exige purgar

Mesma armadilha do dossiê da Aurora: o identificador do documento é o hash do conteúdo, e o conteúdo muda a cada dia. Reexecutar em outro dia acumula um segundo dossiê em vez de substituir o primeiro, e a triagem passa a ler as duas versões juntas. Para substituir de verdade, use PURGAR=1.

A âncora vem do NER, não do alvo do lote

A abertura de lote da tela de upload aceita um CNPJ-alvo e nada mais — ela ancora o lote inteiro numa empresa, o que serve ao dossiê cadastral. Aqui a âncora é outra: o caso, na investigação; e a declarada no cadastro do contexto, no crédito. Por isso o seed não informa alvo: a entidade âncora nasce do reconhecimento de entidades sobre os próprios documentos, e os prompts de cada vertical a declaram como primeiro tipo extraído. Generalizar o alvo do lote para qualquer par (rótulo, propriedade) está registrado como pendência no backlog.

O gate