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)
-
roda motor do
type -
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)
-
A memória padrão será CLAIMs (recomendado) ou resumos por documento?
-
K padrão do consenso: 3 ou 5?
-
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
Postar um comentário