Contexto multi-fonte

Um contexto do DATTA pode reunir grafo, índices de busca, tabelas analíticas e fluxos de eventos, e toda a plataforma passa a enxergar esse conjunto como um domínio único. Dados reais raramente moram numa fonte só, mas até então cada contexto apontava para exatamente uma base de grafo — combinar fontes exigia contorno manual. Com o modelo multi-fonte, você declara no cadastro do contexto quantas fontes heterogêneas precisar (Neo4j + OpenSearch + Trino + Kafka) e busca, chat, triagem e painéis passam a considerar todas elas.

Conceito

Antes do modelo multi-fonte, "contexto" era sinônimo de "domínio" e de uma única base de grafo (relação 1:1:1). Agora um contexto pode referenciar várias fontes de tipos diferentes. Exemplos:

Onde configurar

Em Sistema›Contextos, ao criar ou editar um contexto, o formulário traz o bloco "Fontes de dados deste contexto", com quatro seções colapsáveis:

1. Bancos Neo4j — as bases de grafo descobertas pela plataforma.
2. Índices OpenSearch — os índices datta_* disponíveis (os índices internos do sistema já vêm filtrados).
3. Tabelas/Schemas Trino — exibidos no nível catalog.schema.
4. Tópicos Kafka — os tópicos não-internos.

Cada seção tem um campo de busca para filtrar e um checkbox por item. Para OpenSearch há ainda um campo adicional onde você pode informar um padrão manual (ex.: datta_meucontexto_*). O contador no topo resume a seleção: "X fonte(s) selecionada(s) (Y Neo4j, Z OS, W Trino, V Kafka)".

O índice de ingestão segue a convenção. A fonte OpenSearch primária do contexto define onde a ingestão grava — e a plataforma recusa salvar, com mensagem em português, se o valor divergir da convenção datta_{nome normalizado}. Motivo: a ingestão grava sempre no índice da convenção, então um padrão customizado faria os documentos "sumirem" da busca. Deixe o campo em branco (ou selecione o índice da convenção) ao salvar. Fontes OpenSearch adicionais (não-primárias) continuam livres para a composição multi-fonte.

Índice criado pelo formulário já nasce com busca vetorial. O botão que cria uma fonte nova cria o índice antes do próprio contexto — e o ajuste de busca vetorial de um índice (index.knn) só vale se vier na criação; não se liga depois. Desde 24/09/2026 o índice criado ali já nasce com ele. Um índice criado antes disso pelo mesmo botão recebe documentos, mas nenhum deles aparece na busca semântica; o reparo é o reindex do runbook de operações do OpenSearch (seção de índices sem busca vetorial), e com o índice vazio basta recriá-lo.

Exemplo prático — adicionar uma fonte analítica a um contexto

O contexto "CNPJ" já tem o grafo e a busca, e agora o time quer cruzar com a tabela de eventos societários no Trino:

1. Em Sistema›Contextos, selecione "CNPJ" e abra a edição.
2. No bloco "Fontes de dados deste contexto", abra a seção Tabelas/Schemas Trino e busque por "cnpj".
3. Marque iceberg.public.cnpj_eventos — o contador passa a incluir a nova fonte.
4. Salve. Em até ~2 minutos as consultas da plataforma passam a considerar a nova fonte do contexto.

Contextos antigos migram sozinhos

Contextos criados antes do modelo multi-fonte não têm a lista de fontes no cadastro. Ao serem carregados, a plataforma popula a lista sinteticamente:

• uma entrada Neo4j a partir da base de grafo já configurada (papel "primary");
• uma entrada OpenSearch a partir do padrão de índice já configurado (papel "primary").

Importante: essa migração acontece apenas em memória. O cadastro só é regravado quando um administrador salva qualquer contexto (criar novo ou editar existente). Isso torna o rollback trivial — basta voltar à versão anterior da plataforma, e a configuração original é lida intacta.

Forçar a persistência da migração

Edite qualquer contexto pela interface e clique em Salvar. O cadastro é regravado com as fontes populadas para todos os contextos carregados em memória.

Propagação das alterações

Depois de editar as fontes de um contexto, os módulos da plataforma atualizam sua visão em janelas curtas:

Não é preciso reiniciar nada: aguarde a janela e repita a consulta. Para antecipar, a plataforma expõe um recurso de invalidação do agregador de fontes usado por integrações — veja a referência de API.

Se precisar confirmar o comportamento, os registros de log da plataforma mostram: a migração de contextos legados no carregamento, o registro dos mapeamentos contexto → base de grafo na inicialização do roteamento e os acertos de cache do agregador de fontes.

Limitações da versão atual

• Sem endereço Neo4j externo. As múltiplas bases de grafo vivem no cluster primário da plataforma; apontar para um Neo4j externo por endereço próprio é evolução planejada.
• Trino no nível schema. A seleção é por catalog.schema; as tabelas são resolvidas dinamicamente pelo Trino quando referenciadas em SIQL.
• Tópicos Kafka são listados e registrados na configuração do contexto, mas o consumo em tempo real pelas telas de busca é evolução planejada.
• Releitura a cada ~2 min para o roteamento ao grafo. Edições são raras e não justificam um canal de eventos dedicado; no pior caso, uma nova fonte Neo4j fica visível ao roteamento em até 2 minutos.
• Sem "Atualizar dados" por URL. Contexto com mais de uma fonte Neo4j (um banco por origem) não tem uma URL que represente todos os seus dados: o botão Atualizar de Sistema›Contextos abre o modal com "Atualizar agora" e "Agendar" desabilitados e o aviso "o contexto possui mais de uma origem de dados". Cada origem se atualiza pela carga correspondente no DATTA Extract — veja gerenciar contextos.

Base do código processual

O que é

Além das fontes de dados do contexto (grafo de processos, índices de busca, etc.), um contexto pode declarar uma base de grafo separada com o código processual — os artigos de lei e as decisões relacionadas a cada artigo. Exemplos típicos: cpc (Código de Processo Civil), cpp, cdc.

Essa base alimenta o copiloto de Recurso: ao montar uma peça recursal, ele identifica os artigos citados no texto do processo e enriquece a instrução enviada ao modelo com o caput de cada artigo e até 4 jurisprudências recentes por artigo (tribunal, relator, data, ementa). A peça sai com fundamentação legal real, em vez de o modelo "lembrar" o conteúdo do artigo.

O campo é opcional: fica vazio quando o contexto não gera recurso (ex.: um contexto de assistência social ou de CNPJ). Num contexto de processo judicial, vazio não quer dizer "não se aplica": o "Gerar recurso" desse contexto passa a consultar o CPC (seção abaixo).

Onde editar

Em Sistema›Contextos, ao criar ou editar um contexto, preencha o campo de texto "Base do código processual (opcional)":

• Exemplos (placeholder): cpc, cpp, cdc.
• Texto de ajuda: "Banco Neo4j com os artigos e a jurisprudência do código que rege os processos deste contexto (ex.: cpc, cpp, clt) — é o que o “Gerar recurso” consulta. Em branco, o recurso de um contexto de processo judicial usa o Código de Processo Civil (banco “cpc”); deixe em branco só quando o contexto não gera recurso."
• Valor esperado: o nome da base de grafo que contém os artigos e as jurisprudências do código aplicável. É uma base de contexto, não de sistema — por isso não leva o prefixo datta-.

O comportamento de gravação é o seguinte:

• O nome é normalizado pelas mesmas regras do banco do contexto (minúsculo, sem acento, espaço ou underscore): CLT é gravado como clt. O que não sobra como nome válido de banco é recusado, e também os bancos de sistema (datta-*, neo4j, system) — a mensagem nomeia o campo e diz o que informar. Antes o texto era gravado cru, com maiúscula ou underscore que o Neo4j não aceita em nome de banco.
• Normalizar garante um nome válido, não um banco existente: quem digita o nome do código em vez do nome do banco (Código de Processo Civil vira codigodeprocessocivil) grava um banco que não existe, e o "Gerar recurso" desse contexto sai sem artigos e sem jurisprudência. Por isso o salvamento confere a lista de bancos do Neo4j e, se o banco não está lá, devolve um aviso (não recusa — o banco pode ser carregado depois), com o nome gravado e, quando ele difere, o texto que você digitou. Se a lista de bancos não puder ser lida no momento, nada é avisado: o salvamento não espera pelo Neo4j nem afirma o que não conferiu.
• Na criação, a base só é definida quando o cadastro traz um valor não-vazio.
• Na edição, um valor vazio limpa o campo; a ausência do campo no cadastro enviado preserva o valor atual do contexto.
• Na leitura, o campo aparece apenas quando está preenchido (é omitido quando vazio).
• Salvar um contexto de processo judicial sem a base não é recusado, mas devolve um aviso em português: na criação ele aparece no cartão "Contexto criado", em "Ficou pendente:"; na edição, numa notificação. O aviso de banco inexistente (acima) aparece nos mesmos lugares.
• Numa edição que também troca o nome interno do contexto, uma base inválida é recusada antes da troca: o contexto não é renomeado e nenhuma outra alteração é aplicada.

O mesmo cadastro é acessível a integrações — veja a referência de API.

O que acontece quando o campo está vazio

O copiloto de Recurso resolve a base dinamicamente por contexto, lendo o campo das configurações do contexto. Se o contexto não define o campo (ou as configurações estão momentaneamente indisponíveis, ou o recurso chega sem domínio), o copiloto recorre a um fallback documentado e registra um alerta:

Contexto '{dominio}' sem 'codigoProcessualDatabase' — usando fallback '{db}'

O fallback é a base cpc, por ser o código processual mais geral. Ele é último recurso: o caminho normal é sempre a resolução dinâmica, nunca um nome de base fixado no código. O recurso continua sendo gerado — o que muda é de onde vêm artigos e jurisprudência. O alerta existe para o operador corrigir o cadastro do contexto — e, para os contextos de processo judicial, o próprio cadastro já avisa na tela quando o campo fica vazio (acima).

Relação com "Regras Não Aplicáveis (Sem Contexto)"

Quando a triagem (e o copiloto) não consegue fundamentar uma regra por falta da base legal, as regras voltam como "sem contexto" — exibidas no detalhe da auditoria como "Regras Não Aplicáveis (Sem Contexto)" / "Itens sem contexto suficiente para análise", e o veredito da triagem pode ficar Inconclusivo.

Uma base do código processual ausente, ou apontando para uma base sem artigos e jurisprudências, é uma das causas desse sintoma: sem a base, o copiloto cai no cpc e, se o contexto não for cível, a fundamentação pode não casar com o processo.

Ao investigar muitas "regras sem contexto" num contexto específico, verifique:

1. O campo "Base do código processual (opcional)" está preenchido em Sistema›Contextos?
2. A base apontada existe e contém artigos e jurisprudências?
3. Os registros de log mostram o alerta de fallback acima?

Veja também o detalhe da auditoria do processo para a semântica de "sem contexto" / "Inconclusivo" no laudo.

Propagação

Como as demais configurações de contexto, a base do código processual é lida com cache (mesma janela de até ~60 s da seção Propagação das alterações acima). Após editá-la, aguarde a expiração do cache — ou force a invalidação — para o copiloto enxergar o novo valor.

Veja também

• Detalhe da auditoria do processo
• Perfis e permissões
• Referência de API