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.

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.

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 tem código processual associado (ex.: um contexto de assistência social ou de CNPJ).

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: "Base Neo4j de artigos + jurisprudência usada pelo copiloto de Recurso. Deixe em branco se não se aplica."
• 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:

• 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).

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.

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