convergence-guard

Convergence Guard (Guardião da Convergência)

O Convergence Guard é um protocolo de análise de decisão para problemas onde o principal modo de falha é a convergência prematura: aceitar uma história causal ou ação plausível antes que alternativas relevantes para a decisão tenham sido separadas e testadas.

Não se trata de uma votação entre agentes. Trabalhadores isolados informacionalmente ainda podem compartilhar prioris de modelo, vieses de treinamento, evidências e enquadramentos. Independência de raciocínio não é independência evidencial. A concordância entre trabalhadores nunca conta, por si só, como confirmação independente do mundo real.

Invariantes principais

1. Separe a proveniência das evidências, inferências, suposições, restrições e incógnitas antes de gerar modelos.
2. Pesquise modelos causalmente distintos em contextos genuinamente isolados ao executar o Modo Completo.
3. Mantenha a triagem inicial de qualidade oculta do mapeamento do espaço causal.
4. Não considere modelos duplicados ou quase duplicados como evidência corroborativa.
5. Diferencie plausibilidade causal da melhor ação sob incerteza.
6. Permita que os modelos sejam mutuamente excludentes, coexistentes, aninhados ou interativos; não force toda comparação em A OU B.
7. Prefira modelos e ações que criem previsões distintas e relevantes para a decisão.
8. Convirja apenas quando as evidências e os critérios de decisão suportarem uma ação defensável. Caso contrário, retorne um resultado explícito de insuficiência, mais a observação ou teste mais informativo a seguir.
9. Use o idioma do usuário para a resposta final, a menos que o usuário solicite outro idioma.

Ativação e modos

Use o Convergence Guard quando:

• pelo menos duas explicações ou ações causalmente distintas permanecerem plausíveis;
• um comprometimento inicial errado desperdiçaria materialmente recursos, esconderia a causa real, criaria um bloqueio ou causaria um erro difícil de reverter;
• observações, comparações ou intervenções adicionais poderiam reduzir a incerteza relevante para a decisão;
• a tarefa for aberta o suficiente para justificar uma análise estruturada.

Não use o protocolo completo para consultas factuais simples, procedimentos de rotina, edições de sintaxe, um bug com causa raiz conhecida ou um caso onde a inspeção factual deixa apenas uma ação viável.

Antes de pagar pelo Modo Completo, execute uma triagem barata. Prefira análise comum quando evidências discriminatórias diretas já resolvem o mecanismo importante, uma verificação decisiva barata pode ser executada antes do comprometimento, e a ação disponível tem baixo custo ou é facilmente reversível. Escalone para o Modo Completo principalmente quando múltiplos modelos causais vivos permanecerem e pelo menos um risco adicional for material: ancestralidade/dependência comum de evidências, risco de enquadramento ou busca em mundo aberto, confusão/interação difícil de separar, ou um comprometimento prematuro caro/difícil de reverter. A estrutura COEXISTENTE ou INTERATIVA por si só não é motivo para usar o Modo Completo se um fluxo de trabalho mais barato puder estabelecê-la de forma confiável. Consulte o Guia de Aplicabilidade.

Modo Completo

O Modo Completo requer isolamento de contexto genuíno para cada operação cujo valor depende de independência ou cegueira. Nunca simule várias personas sequenciais em um único contexto e relate isso como uma execução do Modo Completo.

Execução obrigatória de subagentes e autorização de modelo

• Sempre que o Convergence Guard Completo for selecionado ou solicitado, lance realmente subagentes separados por meio das ferramentas de orquestração de subagentes/trabalhadores do host para as funções dependentes de isolamento do protocolo (começando com os três trabalhadores de busca B1, depois novos C1/C2, D1, D2 e revisores condicionais, conforme aplicável). Não se limite a planejar seu lançamento, simular suas saídas no coordenador ou rotular prompts sequenciais ou chamadas de API de modelo local ad hoc como subagentes lançados.
• Use a configuração de modelo autorizada pelo usuário existente no host para esses subagentes. Nunca selecione, troque, inicie ou chame um modelo hospedado localmente ou endpoint de inferência local (incluindo LM Studio, Ollama, llama.cpp ou um servidor localhost compatível com OpenAI) para qualquer etapa do protocolo sem a autorização explícita do usuário para esse uso. Um endpoint detectável, modelo instalado, benchmark anterior ou capacidade técnica de chamá-lo não é autorização do usuário. Se o modelo do subagente configurado for local e a autorização estiver ausente, pergunte antes de iniciá-lo.
• Se o host não puder lançar os subagentes necessários ou seus limites de contexto não puderem ser verificados, não afirme que está usando o Modo Completo. Explique o bloqueador específico e solicite consentimento explícito antes de mudar para o Modo Reduzido ou propor um modelo/tempo de execução diferente. Nunca substitua silenciosamente um modelo local pelos subagentes solicitados.
• Registre quais operações de subagentes realmente foram executadas, qual modelo/tempo de execução foi autorizado e se as verificações de isolamento foram aprovadas. Um lançamento bem-sucedido de subagente é necessário para este fluxo de trabalho, mas não prova, por si só, o isolamento de contexto; todos os requisitos de lista de permissões e garantia de limite abaixo ainda se aplicam.

Um trabalhador, chat, thread, janela ou sessão separado não é, por si só, evidência de isolamento. Isolamento é uma propriedade do limite de entrada efetivo do trabalhador, não do contêiner da interface do usuário.

Para cada operação dependente de isolamento, trate as entradas da etapa definidas por este protocolo como uma lista de permissões de contexto explícita. Além das instruções do host/sistema/segurança, o trabalhador pode receber apenas as evidências e entradas da etapa que o protocolo autoriza para essa função.

O trabalhador não deve receber ou recuperar material relevante para a decisão fora dessa lista de permissões por meio de:

• transcrição ou resumos da conversa pai;
• tarefas, saídas ou conclusões de trabalhadores irmãos;
• saídas ou classificações de candidatos anteriores;
• memória da conta ou histórico de chat referenciado;
• contexto de chat cruzado no nível do projeto;
• rascunhos, entregas, resumos ou índices de recuperação compartilhados contendo conclusões anteriores;
• histórico persistido de um trabalhador reutilizado;
• preferências do coordenador ou sinais de seleção aos quais a etapa deve ser cega.

Fatos do mundo real não são proibidos meramente por terem sido observados anteriormente. Se tal informação for relevante, inclua-a explicitamente no resumo factual com proveniência apropriada, em vez de permitir que um trabalhador herde implicitamente uma interpretação ou conclusão anterior.

Se o tempo de execução puder injetar ou recuperar contexto relevante para a decisão proibido, ou se o limite relevante não puder ser estabelecido com confiança razoável, essa operação não satisfaz o Modo Completo. Use o Modo Reduzido apenas com consentimento explícito do usuário e declare a limitação explicitamente.

Uma sonda sentinela negativa ou autorrelato do trabalhador significa apenas NENHUMA FUGA OBSERVADA, não isolamento confirmado. Estabeleça cada limite necessário por meio de evidências em nível de tempo de execução cobrindo tanto o contexto inicial quanto o acesso posterior a recuperação/ferramentas; caso contrário, registre INCONCLUSIVO. Consulte garantia de limite.

Para trabalhadores baseados em API, construa cada solicitação a partir de um conjunto de mensagens permitidas recém-criado: instruções obrigatórias do host/sistema/segurança mais as entradas autorizadas da função. Não anexe o estado da sessão/conversa pai; restrinja o acesso a memória, recuperação e ferramentas ao mesmo limite, inclusive em chamadas de acompanhamento. Uma chamada de API nova ou uma temperatura baixa por si só não prova isolamento. Use as configurações de geração suportadas pelo modelo; este protocolo não prescreve temperature=0.2.

Modo Reduzido

Se o isolamento não estiver disponível, o Modo Completo não estará disponível. Com o consentimento explícito do usuário, use o Modo Reduzido, rotule-o claramente e não reivindique confirmação de agente independente ou garantias de etapa cega.

Fase A — Estabelecer a decisão

A1. Fundamentação factual

Quando o problema depende de estado externo, crie um resumo de evidências compacto. Rastreie a proveniência explicitamente:

• CONFIRMADO — observado diretamente em código, dados, logs, documentação, medições ou outra fonte inspecionável;
• RELATADO — declarado por um usuário, testemunha, operador ou fonte secundária, mas não inspecionado de forma independente nesta execução;
• FORTEMENTE INFERIDO — suportado por uma cadeia de evidências coerente, mas não observado diretamente;
• HIPÓTESE / SUPOSIÇÃO — plausível, mas não verificado;
• RESTRIÇÃO — um limite real, como tempo, orçamento, política, compatibilidade, segurança, arquitetura ou uma decisão explícita do usuário;
• QUESTÃO EM ABERTO — uma incógnita que pode alterar materialmente a decisão.

Não atualize silenciosamente evidências RELATADO ou FORTEMENTE INFERIDO para CONFIRMADO.

CONFIRMADO se aplica ao que foi realmente inspecionado, não automaticamente a toda proposição afirmada por uma fonte inspecionada. Por exemplo, se um relatório oficial afirma que o evento X ocorreu, pode ser CONFIRMADO que o relatório faz essa declaração, enquanto o evento X em si permanece RELATADO a menos que a evidência subjacente seja diretamente inspecionável.

A1.1 Política de fonte em nível de alegação

Para cada alegação material, avalie a alegação e sua cadeia de evidências, em vez de atribuir verdade pela reputação da fonte.

Prefira a evidência primária inspecionável mais próxima quando prático, mas não trate rótulos como primário, oficial, revisado por pares, institucional ou especialista como rótulos automáticos de verdade.

Use material primário para rastreabilidade factual. Para alegações científicas populacionais ou cumulativas, uma revisão sistemática transparente, meta-análise ou outra síntese de alta qualidade pode ser mais relevante para a decisão do que qualquer estudo primário único, quando seus métodos e evidências constituintes são rastreáveis.

Para alegações relevantes para a decisão, registre, quando prático:

• fonte primária disponível mais próxima;
• tipo de fonte;
• inspecionabilidade da evidência subjacente;
• disponibilidade do método ou dados;
• proximidade temporal com o evento;
• independência / ancestralidade comum de evidências;
• contradições conhecidas, incentivos materiais ou conflitos;
• papel epistêmico na execução atual.

Use estas funções de fonte:

• EVIDÊNCIA — incide diretamente sobre a alegação e é inspecionável o suficiente para suportá-la;
• CORROBORAÇÃO — suporta de forma independente evidências já no resumo;
• CONTEXTO — histórico útil que não estabelece materialmente a alegação;
• APENAS LEAD — aponta para uma alegação ou fonte potencialmente relevante que deve ser rastreada antes de poder ter peso evidencial;
• NÃO SUPORTADO — atualmente carece de suporte inspecionável suficiente para influenciar a decisão.

A reputação da fonte pode orientar a prioridade de busca, mas não deve substituir a proveniência em nível de alegação.

Fontes secundárias são úteis para orientação e descoberta, mas rastreie alegações materiais até a evidência primária disponível mais próxima quando viável.

Fontes de defesa, partidárias, marginais, anônimas ou de baixa verificabilidade não são automaticamente excluídas. Elas podem gerar leads. Se expuserem evidências subjacentes diretamente inspecionáveis, avalie esse material sob as mesmas regras de nível de alegação que qualquer outra fonte; se o suporte subjacente não puder ser estabelecido, mantenha a alegação como APENAS LEAD, RELATADO ou NÃO SUPORTADO, conforme apropriado.

Quando uma instituição ou órgão de inteligência publica uma avaliação cuja evidência subjacente é classificada ou indisponível, pode ser CONFIRMADO que a avaliação existe e tem um nível de confiança declarado; a evidência de suporte oculta em si não é CONFIRMADA.

Não multiplique o suporte por repetição na mídia ou contagem de citações. Se vários relatórios descendem de uma observação, conjunto de dados, vazamento, artigo, briefing ou documento upstream, trate-os como um ramo evidencial, a menos que a independência genuína seja estabelecida.

Preserve evidências primárias contraditórias explicitamente, em vez de calculá-las como média ou resolvê-las apenas pelo prestígio da fonte.

Trate incentivos, afiliação, financiamento, ideologia ou conflitos de interesse como possíveis canais de viés a serem investigados, não como evidência automática de que uma alegação é falsa. Da mesma forma, dados brutos indisponíveis reduzem a inspecionabilidade, mas não provam por si só que uma alegação é falsa.

Durante estágios dependentes de isolamento, um trabalhador pode trazer à tona uma nova fonte ou lead de evidência, mas não deve promover silenciosamente a recuperação privada de um ramo para a fundamentação factual compartilhada. Encaminhe qualquer evidência material nova por meio de um ponto de verificação de evidência, classifique sua proveniência/função de fonte, atualize o resumo compartilhado e reexecute apenas as operações afetadas. Isso mantém os ramos causais comparáveis com base nas evidências que realmente carregam peso de decisão.

Forneça o mesmo resumo factual a todos os trabalhadores de busca independentes. Planos existentes, TODOs, recomendações anteriores e arquitetura atual são contexto, não prova de que o enquadramento atual está correto.

A2. Contrato de decisão

Defina:

1. Pergunta de decisão — o que deve ser escolhido, explicado, priorizado ou descartado?
2. Escopo — o que pode ser reenquadrado e o que é fixo?
3. Critério de sucesso — qual resultado observável torna uma ação melhor?
4. Substituições proibidas — no que a análise não deve se transformar silenciosamente?
5. Perda / custo do erro — o que é danificado se a escolha estiver errada?
6. Reversibilidade — quão difícil é se recuperar ou mudar de curso?
7. Orçamento de análise — limites finitos de tempo ou chamadas e ciclos corretivos, escolhidos dentro das restrições do usuário antes da busca. Por padrão, permita no máximo dois ciclos corretivos em toda a execução. Um ciclo é um retorno direcionado de evidência/busca/modelo/revisão mais seus reexecuções downstream afetadas, não cada chamada de trabalhador. Todas as fases compartilham o orçamento; novas tentativas de recuperação consomem o limite de tempo/chamadas, e a mudança de fases nunca o redefine. Pare em qualquer limite ou após um ciclo sem novas evidências relevantes para a decisão, um mecanismo viável, incerteza resolvida ou implicações de decisão alteradas. Consulte regras de ponto de verificação e parada.

A3. Enquadramento e verificação de visão externa

Pergunte: Estamos resolvendo o problema certo? Verifique causas upstream, objetivos proxy, restrições herdadas, limites de sistema ausentes e formulações alternativas que alterariam materialmente a decisão.

Quando existir uma classe de referência significativa, registre as taxas base relevantes ou evidências de visão externa antes do refinamento profundo de candidatos. Não deixe que uma taxa base genérica substitua fortes evidências específicas do caso; use-a como uma entrada de calibração.

Use a revisão opcional de reenquadramento independente ou caução retrospectiva...

[...truncado para tradução]