Resumo Curador v1 (corrigido, operacional e pronto pro PRAXIUM)

 

Resumo Curador v1 (corrigido, operacional e pronto pro PRAXIUM)

1) Contexto

Estamos construindo o PRAXIUM como diretor soberano (governança/execução/auditoria) de um “teatro de máscaras”, onde os motores são papéis/roteiros que produzem saídas variáveis (interpretação/IA), e o sistema aprende no tempo: hipótese → evidência → revisão → confirmação.

2) Tese central

O objetivo não é “a resposta certa”, e sim a resposta mais provavelmente correta, com:

  • evidência anexada

  • grau de confiança

  • risco se estiver errada

  • plano de confirmação futura

  • revisão ao longo do tempo

3) Soberania e papéis

PRAXIUM (kernel) = autoridade administrativa (não improvisa no poder)

  • Roteia tipos (type → motor)

  • Executa (subprocess/stdin→stdout ou runner de roteiro)

  • Controla locks/concorrência

  • Registra ledger append-only + resultados

  • Aplica consequências: PROCESSED / MANUAL / QUARANTINE

  • Decide promoção/rebaixamento de memória

Curador = bibliotecária/união (improvisa no conteúdo, não no poder)

  • Resume/normaliza

  • Compila múltiplos resultados

  • Indexa, deduplica, versiona

  • Prepara “pacotes de memória” e propõe promoção (nunca pune)

Sócrates = auditor/crítico

  • Detecta contradições, buracos lógicos, falta de evidência

  • Aplica tríade Bem/Belo/Justo

  • Emite veto/alertas e recomenda rechecagem (não move arquivo)

4) Regra de ouro do sistema

Motores só sugerem + evidenciam. PRAXIUM decide e executa.
Especialmente:

  • Só o PRAXIUM coloca em QUARANTINE

  • Curador/Sócrates retornam recommendation + reasons + evidence_refs

  • O kernel aplica a política e registra no ledger

5) O gargalo real (confirmado)

O gargalo do sistema é resumo + compilação + memória evolutiva.
Sem isso, você produz volume e não produz aprendizado.
Logo: Curador deve ser uma suíte forte (summarize/compile/index/promote-proposal), mas sem virar “kernel paralelo”.

6) Determinismo: onde ele existe e onde não existe

  • Conteúdo (LLM/roteiros): pode variar; não há uma única resposta em domínios interpretativos.

  • Processo (governança): deve ser rígido/determinístico naquilo que é soberano:

    • schema mínimo

    • regra de conflito de type

    • cálculo de consenso/divergência

    • critérios de escalonamento (MANUAL/QUAR)

    • promoção de memória

7) Consenso como método (não como “verdade”)

Para avaliações interpretativas, o sistema deve trabalhar por consenso controlado:

  • Rodadas múltiplas (K=3 ou K=5) e/ou papéis diferentes

  • Saída estruturada (JSON) para comparar

  • Agregador determinístico calcula:

    • consensus_score, conflict_score, evidence_score, failure_count

  • Divergência alta ou contradição central → MANUAL (não finge certeza)

8) Contratos e estrutura para inserir motores sem mexer no run.py

Types exatos + manifest/registry como fonte soberana:

  • Cada motor declara:

    • type, script/entry, timeout, priority, enabled

  • Regra dura de conflito:

    • type duplicado → QUARANTINE por padrão

    • override só com prioridade explícita + log no ledger

    • empate de prioridade → erro (nunca “escolhe na sorte”)

9) Unidade mínima de memória (o que faltava antes)

Memória não pode ser “texto solto”. Precisa de CLAIM (hipótese versionada):

  • claim_id

  • statement

  • confidence

  • truth_status: DRAFT | SUPPORTED | VERIFIED | CONTESTED | RETIRED

  • evidence_refs[]

  • assumptions[]

  • review_after (rechecagem futura)

  • supersedes/superseded_by

Regra: nada vira memória estável sem status + evidência + revisão.

10) Fluxo mínimo saudável (sequencial hoje, paralelizável amanhã)

Fase A — Execução (PRAXIUM)

  1. roda motor do type

  2. salva RESULT bruto + ledger

Fase B — Curadoria (Curador)
3. curator.ingest (normaliza + resumo + tags + extrai CLAIMs DRAFT)
4. curator.compile (junta N results em bundle + dedup + índice)

Fase C — Auditoria e promoção
5. socrates.audit (contradições/riscos/evidência)
6. PRAXIUM decide:

  • PROCESSED / MANUAL / QUARANTINE

  • promove para memória (se passar thresholds)

  • agenda revisão futura

11) Conclusão do “estado do projeto”

Já temos o esqueleto soberano (execução + ledger + motor externo provado).
O que falta para “fazer o que é preciso” (aprendizado real):

  • registry/manifest determinístico (sem mexer no run por motor)

  • ResultEnvelope v1 e Claim v1

  • Curador compile + Sócrates audit + política de promoção/revisão


Pendências objetivas para fechar (3 decisões rápidas)

  1. A memória padrão será CLAIMs (recomendado) ou resumos por documento?

  2. K padrão do consenso: 3 ou 5?

  3. Sócrates tem veto duro (FAIL → MANUAL/QUAR) ou só pesa no placar?

Se você responder só com: CLAIM / 3 / veto (ou suas escolhas), eu adapto o resumo para virar uma “Constituição v1” com regras numéricas (thresholds) pronta para entrar no PRAXIUM.

Comentários

Postagens mais visitadas deste blog

A NOVA FRONTEIRA DA CRISPR: O CORAÇÃO SOB EDIÇÃO

200 Anos de Crise: da Guerra do Ópio ao Leviatã Digital

Futuro 1.0 — O Dia em que o Mundo Acelerou