Estratégia de programação do PRAXIUM — evolução paralela, baixo risco e sem aprisionamento a um LLM

Ideia central: eu não faria agora um “módulo Ollama” nem começaria a construir o LLM próprio. Faria primeiro uma fronteira cognitiva estável do PRAXIUM. Tudo o que pensa linguisticamente — Ollama hoje, GPT eventualmente, outro modelo amanhã e o futuro modelo PRAXIUM — entra pela mesma porta e obedece ao mesmo contrato.

Isso permite desenvolver PRAXIUM, motores determinísticos e LLM próprio simultaneamente, sem um depender da implementação interna do outro.

O que já foi provado reforça essa direção: o E2E chega realmente a Hub → Router → CORE sem LLM, mas a capacidade nativa é limitada e a governança atual mistura trabalho cognitivo com requisitos de execução operacional. O diagnóstico anterior também mostrou que PTC-EXE/TST está sendo exigido num caminho cognitivo read-only embora tenha semântica de execução/teste operacional.

1. Eu adotaria esta arquitetura

                         DANTE / JANELINHA
                                │
                                ▼
                         ENTRADA PRAXIUM
                                │
                                ▼
                              CORE
                                │
                    classifica a necessidade
                                │
             ┌──────────────────┴──────────────────┐
             │                                     │
             ▼                                     ▼
     CAPACIDADES NATIVAS                  PORTA COGNITIVA PRX
             │                                     │
     matemática / regras                    contrato único
     lógica / motores                              │
     busca / memória                               ▼
             │                              PROVIDER ROUTER
             │                         ┌────────┼─────────┐
             │                         ▼        ▼         ▼
             │                      Ollama    GPT/API   Outro
             │                         │
             │                         └──── futuro ───────► PRX-LLM
             │                                     │
             └──────────────────┬──────────────────┘
                                ▼
                       RESULTADO CANDIDATO
                                │
                                ▼
                             SÓCRATES
                         crítica independente
                                │
                                ▼
                              CORE
                         decisão/autorização
                                │
                    ┌───────────┴───────────┐
                    │                       │
              cognitivo/read-only       operacional
                    │                       │
              gate cognitivo             PTC completo
                    │                       │
                    └───────────┬───────────┘
                                ▼
                              AURORA
                    coordenação/continuidade
                                │
                              CURADOR
                    memória/proveniência
                                │
                                ▼
                            RESPOSTA

Há um detalhe crucial: Aurora, Sócrates e Curador não devem ser reescritos para servir ao Ollama. A porta cognitiva deve adaptar o modelo ao PRAXIUM — nunca adaptar o PRAXIUM ao modelo.

2. A peça central: uma Porta Cognitiva, não um “módulo Ollama”

Eu usaria conceitualmente algo como:

PRX_COGNITIVE_PORT

O nome pode mudar depois. O importante é a função.

Ela possuiria apenas dois contratos estáveis:

CognitiveRequestV1
CognitiveResponseV1

Por exemplo:

{
  "contract": "CognitiveRequestV1",
  "prx_run_id": "PRX-...",
  "task": "interpretar_argumento",
  "input": "...",
  "context_refs": [],
  "constraints": [],
  "expected_output": "PRX_SEMANTIC_V1",
  "risk": "low",
  "tools_allowed": [],
  "provider_policy": "auto"
}

E o retorno:

{
  "contract": "CognitiveResponseV1",
  "prx_run_id": "PRX-...",
  "provider": "ollama",
  "model": "qwen2.5-coder:3b",
  "result": {},
  "uncertainties": [],
  "limitations": [],
  "provenance": {},
  "llm_called": true
}

Repare no que não aparece:

approved = true
authorized = true
execute = true
canonicalize = true

O provider não recebe autoridade.

Ele entrega um resultado candidato.

3. CORE deve conhecer o contrato — não os modelos

Esse é um dos pontos que mais reduzem erro.

Não quero encontrar daqui a seis meses coisas assim espalhadas pelo projeto:

if provider == "ollama":
    ...
elif provider == "openai":
    ...
elif provider == "praxium_llm":
    ...

dentro de server.py, Router, Aurora, Janelinha, Curador etc.

Isso vira uma armadilha de manutenção.

Quero:

response = cognitive_port.process(request)

E só a Porta Cognitiva sabe qual provider foi utilizado.

Assim:

CORE ────────────────┐
Sócrates ────────────┤
Aurora ──────────────┤
Curador ─────────────┤── entendem contrato PRX
Janelinha ───────────┘

          não precisam entender Ollama/OpenAI/etc.

4. Cada modelo vira apenas um adaptador

Internamente:

CognitiveProvider
        │
        ├── OllamaProvider
        ├── OpenAIProvider
        ├── ExternalProvider
        └── PraxiumInternalProvider

Todos implementam aproximadamente:

supports(request)
invoke(request)
normalize(response)
health()
capabilities()

O futuro LLM do PRAXIUM não ganha tratamento especial.

Ele simplesmente implementa:

PraxiumInternalProvider

Isso é extremamente importante porque permite começar a construí-lo antes de ele estar pronto.

No começo:

PRX_INTERNAL_LLM = unavailable

Depois:

PRX_INTERNAL_LLM
capabilities:
  intent_detection

Mais tarde:

intent_detection
semantic_parsing
entity_relations
summarization
generation
reasoning_support

O restante do PRAXIUM não muda.

5. Separar capacidade de provider

Outra proteção importante.

O CORE não deveria perguntar:

“Uso Ollama ou GPT?”

Ele deveria perguntar:

“De que capacidade preciso?”

Por exemplo:

CAPABILITY:
semantic_interpretation

O registry responde:

core_native             não suporta
PRX_INTERNAL_LLM        parcial
Ollama                  suporta
GPT                     suporta

Então a política escolhe.

Isso permite que, no futuro, seu próprio modelo comece substituindo somente algumas funções.

Exemplo de evolução

Hoje:

interpretação      → Ollama
síntese            → Ollama
linguagem          → Ollama

Depois:

interpretação      → PRX-LLM
síntese            → Ollama
linguagem          → PRX-LLM

Mais tarde:

interpretação      → PRX-LLM
síntese            → PRX-LLM
linguagem          → PRX-LLM
Ollama             → contingência
GPT                → especialista externo

Não haverá uma migração traumática. O modelo PRAXIUM ocupa progressivamente capacidades.

6. Dois planos: processamento e controle

Eu faria essa separação rigorosamente.

Plano de processamento	Plano de controle
CORE nativo	CORE autoridade
Motor matemático	Sócrates
Reason DNA	PQR
Ollama	PTC
GPT	PRX-QA
futuro PRX-LLM	Aurora/controle operacional
busca/memória	proveniência/auditoria

O lado esquerdo produz.

O lado direito controla.

Nunca fazer:

Ollama produz
↓
Ollama avalia
↓
Ollama autoriza

Nem no futuro:

PRX-LLM produz
↓
PRX-LLM se aprova

Essa independência é uma das melhores proteções arquiteturais que podemos dar ao PRAXIUM.

7. Resolver também cognitivo × operacional

A descoberta da Fase 3 é importante demais para ser ignorada.

Hoje existe algo equivalente a:

raciocínio lógico
↓
PTC exige execução
↓
PTC exige teste de executor
↓
bloqueio

Precisamos ter dois contratos de autoridade, sem eliminar o PTC:

COGNITIVO / READ-ONLY
resultado
→ crítica independente
→ validação cognitiva
→ gate cognitivo

OPERACIONAL / EFFECTFUL
decisão
→ autorização
→ execução
→ teste
→ receipt
→ PTC
→ gate operacional

Isso não significa criar dois PRAXIUM.

É apenas o CORE sabendo:

QUE TIPO DE TRABALHO ESTOU CONTROLANDO?

8. Rastreabilidade obrigatória

Toda solicitação cognitiva deve carregar o mesmo:

PRX_RUN_ID

E também:

cognitive_call_id
provider_requested
provider_effective
model_effective
capability_requested
reason_for_provider
input_digest
output_digest
llm_called
fallback_used
validation_result
latency

Isso elimina exatamente ambiguidades que já apareceram nos testes, como:

provider = ollama

sem sabermos se o Ollama foi efetivamente chamado.

A Fase 3 já mostrou por que IDs exclusivos e correlação causal são essenciais.

9. Como reduzir drasticamente a chance de erros

Aqui eu seria conservador.

Não faria uma grande reforma de uma vez.

A sequência que considero mais segura é:

Mapear os pontos atuais onde server.py, prax_orchestrator.py, Router e código de provider chamam Ollama/LLM; sem modificar nada.
Definir CognitiveRequestV1, CognitiveResponseV1 e CognitiveProvider em isolamento e escrever testes de contrato.
Criar primeiro OllamaAdapter usando exatamente o comportamento existente — nenhuma inteligência nova.
Colocar a Porta Cognitiva em shadow mode: observar o que faria, enquanto o caminho atual continua valendo.
Comparar caminho atual × porta nova por PRX_RUN_ID; somente se forem equivalentes, promover uma capacidade pequena.
Migrar apenas uma capacidade, provavelmente interpretação linguística, e repetir E2E.
Depois adicionar provider externo opcional pela mesma interface.
Abrir o slot PraxiumInternalProvider, mesmo inicialmente sem implementação, permitindo que o futuro LLM seja desenvolvido paralelamente.
Só então migrar novas capacidades gradualmente, uma por vez.

Isso é essencialmente uma migração por estrangulamento, não uma substituição de arquitetura.

10. Como o PRAXIUM pode evoluir em paralelo

Essa arquitetura permite quatro linhas trabalhando simultaneamente:

LINHA A — PRAXIUM CORE
governança
roteamento
memória
Reason DNA
motores
QA

LINHA B — CAPACIDADES NATIVAS
matemática
lógica
investimentos
análise determinística
motores especializados

LINHA C — INTERMEDIAÇÃO LINGUÍSTICA
Ollama
GPT/API
outros providers

LINHA D — PRAXIUM INTERNAL LLM
dataset PRX
interpretação
semântica
treino/fine-tuning
avaliação
modelo próprio

Todas convergem para o mesmo contrato cognitivo.

Essa é a grande vantagem.

A equipe que estiver construindo o futuro LLM não precisa esperar o CORE.

Quem estiver desenvolvendo o CORE não precisa esperar o futuro LLM.

Quem desenvolver novos motores não precisa saber qual LLM está ativo.

E o PRX-QA pode avaliar todos pelos mesmos critérios.

11. O futuro LLM PRAXIUM pode nascer pequeno

Eu evitaria o objetivo inicial:

“vamos construir nosso próprio grande LLM”.

É grande demais e cria risco de anos de trabalho antes de obter valor.

Faria:

PRX-LING-01
intenção

↓

PRX-LING-02
entidades e relações

↓

PRX-LING-03
tradução humano → semântica PRX

↓

PRX-LING-04
semântica PRX → linguagem humana

↓

PRX-LING-05
contexto e enredo

↓

PRX-COG
modelo cognitivo mais completo

Enquanto isso:

Ollama = professor/provedor transitório
GPT = recurso externo opcional
PRX-LLM = cresce progressivamente

E podemos gerar dados de alta qualidade para o futuro modelo:

entrada humana
↓
interpretação do provider
↓
decisão PRAXIUM
↓
crítica Sócrates
↓
correção
↓
resultado observado

Esse material é potencialmente muito mais valioso para o futuro PRX-LLM do que simplesmente acumular conversas.

12. Minha recomendação arquitetural final

Eu congelaria estas cinco regras como canônicas:

PROVIDER ≠ AUTORIDADE

GERAÇÃO ≠ VALIDAÇÃO

CAPACIDADE ≠ PROVIDER

TODO PROVIDER ENTRA PELO MESMO CONTRATO

O FUTURO PRX-LLM DEVE SUBSTITUIR CAPACIDADES PROGRESSIVAMENTE, NÃO O PRAXIUM INTEIRO

Isso cria uma arquitetura na qual:

             PRAXIUM permanece
                    │
              capacidades mudam
                    │
        ┌───────────┼────────────┐
        ▼           ▼            ▼
     Ollama        GPT        PRX-LLM
     transitório   opcional    crescente

Minha escolha técnica

Não criaria agora um subsistema paralelo.

Criaria uma interface estreita dentro do caminho já existente, reutilizando o Router/CORE e encapsulando progressivamente as chamadas de provider que já existem.

Assim preservamos o princípio do projeto:

partir do que existe, provar antes de substituir e nunca confundir existência com funcionamento.

E esse desenho deixa aberto exatamente o futuro que você quer: PRAXIUM evoluindo de um sistema que hoje utiliza LLMs para um sistema que, progressivamente, desenvolve suas próprias capacidades cognitivas — sem precisar ser reconstruído quando isso acontecer.

Pesquisar este blog

Assistente-inteligente