Organograma funcional do PRAXIUM
Aqui está o organograma funcional (Toyota: simples, hierárquico, auditável) do PRAXIUM — e onde o mv_auditor.py entra como peça obrigatória.
Organograma funcional do PRAXIUM
Por que o mv_auditor.py é “necessário” nesse organograma
Ele é o único que fecha o ciclo com governança:
Sem auditor:
-
Você tem execução (o sistema roda)
-
Mas não tem prova (não sabe se está melhorando)
Com auditor:
-
Cada decisão vira: U(t), ΔU, status, evidência
-
O PRAXIUM deixa de ser “motor” e vira “sistema decisório”
Regra Toyota do encaixe do Auditor
O mv_auditor.py entra depois da política e antes do próximo loop, porque ele precisa:
-
ver o que foi decidido (POLICY / AI_POLICY)
-
ver o que aconteceu no mundo (STATE/OBS)
-
registrar resultado (AUDIT/LEDGER)
Se você colocar o auditor antes, ele não audita nada (não existe decisão aplicada).
Onde ele escreve e por quê
-
OUTPUT/AUDIT/AUDIT_<tick>.json
prova por tick (documento) -
OUTPUT/LEDGER/decision_ledger.jsonl
histórico contínuo (base de backtest e laudo)
Se você quiser o próximo passo “Toyota” sem risco:
eu te dou um RUN_MV_FULL_Toyota.bat com a ordem correta e com regra:
IA falha → segue, auditor nunca falha por arquivo vazio, e tudo gera evidência.
Comentários
Postar um comentário