O Servidor de Validação: Teste as Afirmativas de IA Contra a Realidade Antes que Seus Usuários o Façam

Há uma lição difícil em implantar agentes de IA em produção: confiança e precisão são completamente não correlacionadas.

Um LLM pode te dizer algo com absoluta certeza e estar completamente errado. Ele citará um commit que não existe. Ele afirmará que uma API está ativa quando está fora do ar há horas. Ele te dará um preço que mudou na semana passada. Isso não é um bug que você conserta com um prompt melhor. É uma propriedade estrutural de como esses modelos geram texto — eles produzem saídas plausíveis, não fatos verificados.

A correção que construímos é um Servidor de Validação: um servidor FastMCP que testa as afirmações desafiadas contra a realidade antes que possam causar danos.

A Perspectiva

O consenso captura desacordos. Múltiplos agentes revisando uma descoberta podem identificar lacunas lógicas, afirmações conflitantes e contexto ausente. Mas o consenso não captura a confabulação — o caso em que todos os agentes estão confiantes e todos estão errados.

Exemplo: um agente de pesquisa relata que um commit do GitHub a3f9b2c adicionou autenticação de usuário em 15 de março. O Auditor o revisa e diz "parece plausível". O Scout confirma que o repositório existe. Pontuação de consenso: 0.8 — confirmado.

Mas o commit não existe. A data está errada. O recurso não está naquele commit. Cada agente estava confiante e cada agente estava errado.

Você precisa de uma verificação da realidade. É isso que o Servidor de Validação faz.

O Que Ele Testa

O Servidor de Validação tem cenários para diferentes tipos de afirmações:

http_endpoint  → curl a URL, verifique código de status
network_reachability  → TCP conectar ao host:porta
api_json  → buscar JSON API, verifique valor do campo
price_check  → pesquisar web por corroboração
git_claim  → pesquisar git log por commit
web_claim  → Brave pesquisar para verificar fatos
shell_command  → executar comando arbitrário

Cada cenário tem um protocolo de validação definido. O Servidor de Validação não usa o mesmo LLM para se verificar — ele usa sistemas externos reais.

Como Funciona

Quando o Servidor de Consenso sinaliza uma descoberta como desafiada (pontuação 0.3–0.6), ele chama:

validate_challenged_findings(consensus_round_id)

Isso percorre cada descoberta desafiada, escolhe o tipo de cenário correto, executa o teste e envia o resultado de volta ao Servidor de Consenso:

{
  finding_id: "x402-pricing",
  scenario: "price_check",
  result: {
    claimed: "$0.03 por solicitação",
    actual: "preço não encontrado no site x402",
    corroborated: false,
    severity: "alto"  # afirmação de preço sem evidência
  },
  validated: true,
  passed: false
}

Se a descoberta falhar na validação, ela é rejeitada ou sinalizada para revisão humana. Nenhuma mentira confiante se torna uma recomendação de produto.

O Fluxo Completo

Agente de Pesquisa faz a afirmação
        ↓
Servidor de Consenso: Scout + Auditor + Dev votam
        ↓
Pontuação ≥ 0.6 → confirmado (vai para síntese)
Pontuação 0.3–0.6 → desafiado → Servidor de Validação
Pontuação < 0.3 → rejeitado
        ↓
Servidor de Validação testa a realidade
        ↓
Passa → confirmado (de volta ao consenso)
Falha → rejeitado ou revisão humana
        ↓
Síntese (Hemingway) → relatório final com níveis de confiança

Exemplo Real: Pesquisa de Endpoint x402

Executamos isso no ecossistema x402. O relatório de lacunas informou:

• "14 endpoints implantados em todo o marketplace x402"
• "carteira 0xf404... não recebeu transações"
• "Preço: $0.001–$0.05 por solicitação dependendo do endpoint"

Pontuações de consenso: todas acima de 0.6. Mas a fase de validação capturou:

• A carteira realmente havia recebido uma pequena transação (de um teste que esquecemos)
• Um endpoint estava retornando 403, não 200
• O preço para meeting-notes-summary era na verdade $0.001 no código implantado, não $0.03 como afirmado

Todos os três eram pequenos erros. Mas em um contexto de decisão de produto — "devo construir sobre x402 ou usar APIs tradicionais" — pequenos erros de preço se acumulam.

Implementação

O Servidor de Validação é um servidor FastMCP em agents/servers/validation_server.py, registrado como validation-server em openClaw.json:

quick_validate(claim, scenario_type, context)
  # Validação de uma só vez, sem necessidade de loop de consenso

define_validation(find_id, claim, scenario, ctx)
  # Defina uma validação para executar mais tarde

run_and_submit_to_consensus(val_id, round_id)