CORPUS / 02
Estados, regras, eventos, permissões e interfaces.
O programa pede que cada ideia tenha uma representação paralela em linguagem de código: estados, regras, eventos, permissões e interfaces. Esta página reúne essas representações. Os blocos de código são especificações legíveis, não software em execução; onde um mecanismo está implementado e testado, isso é dito.
Versão 0.6.0 · atualizada em 04/10/2026 · Corte de leitura e medição: 04/10/2026, horário da Bahia. · Histórico de versões
M1
Entidades e posições relativas
FATO REGISTRADOS (simbionte), H (hospedeiro) e SH (a relação organizada) são posições relativas à relação observada, não rótulos de espécie. No caso fundador, H é uma pessoa situada que decide e responde, e S é um sistema artificial. Em outras escalas, a mesma empresa pode ocupar H de um conjunto maior, e a coordenação de uma escala pode ocupar S da escala seguinte.
type Posicao = 'S' | 'H' | 'SH' // relativa à relação observada
Quadrado Q_n := { S_n, H_n, ponte_S, ponte_H, membrana } // o conjunto observado na escala n
SH_n := coordenação de Q_n (não é um terceiro executor)
// passagem de escala
H_(n+1) := Q_n // o conjunto inteiro passa a ser hospedeiro da escala seguinte
S_(n+1) := SH_n // a coordenação anterior passa a ser o simbionte da escala seguinte
SH_(n+1) // existe só se houver nova composição
// restrição humana expressa: "a regra pode se repetir, mas exige limite"
limite_de_recursao := EM_ELABORACAOM2
Membrana e passagem
Membrana governada — Toda troca entre núcleo e hospedeiro deve ser seletiva, rastreável, revogável e proporcional à função exercida.
Constituição Cognitiva do Simbionte v0.4, §2 (16/07/2026)
atravessa_membrana(ator) :=
ator == Central // o nó que acessa os dois lados
OU ato_expresso_do_fundador // decisão humana registrada
// o que a membrana não é
// - não é hierarquia: Central e Operacional são pares com atribuições delimitadas
// - não é ACL: política de acesso e permissões observadas são evidências distintas
// - não é status: "status é rótulo; capacidade é membrana"| Plano transversal | Função | Natureza |
|---|---|---|
| Π1 · Membrana | Fronteira S/H: visibilidade e passagem. | vale para todos os cofres; evolui por emenda, não por bucket |
| Π2 · Controle e evidência | STOP, lease com batimento, chave de efeito, crachá, recibo, readback, observador independente. | idem |
| Π3 · Quadrado | A infraestrutura em que S e H operam: bases, armazenamento, execução, conectores. | idem; não é um cofre |
| Π4 · Custo como dado | Toda execução registra o que custou. | idem |
M3
Missão: estados, eventos e invariantes
estados := RASCUNHO | AUTORIZADA | EM_EXECUCAO | EM_AUDITORIA | DEVOLUTIVA | AGUARDA_DECISAO_HUMANA | BLOQUEADA
| CONCLUIDA | CANCELADA | REJEITADA | FALHA // terminais
// transições abaixo: leitura editorial do esquema, não o texto da fonte
RASCUNHO ──autorizar(humano)──► AUTORIZADA
AUTORIZADA ──reservar(lease)──► EM_EXECUCAO
EM_EXECUCAO ──devolver(recibo)──► DEVOLUTIVA
DEVOLUTIVA ──aceitar(humano)──► CONCLUIDA | ──recusar──► REJEITADA | ──reabrir──► AUTORIZADA
* ──precisa_de_decisao──► AGUARDA_DECISAO_HUMANA // silêncio e prazo vencido não são resposta
invariantes
I1 uma mão por vez: lease curto com batimento; expirado, qualquer IA pode retomar e complementar
I2 chave_de_efeito única por efeito lógico; retentativa reconcilia pelo ID original antes de repetir
I3 recibo + readback no destino: "SUCCEEDED não prova efeito"
I4 executor ≠ revisor ≠ aceitador; o executor não aprova a própria entrega
I5 silêncio ≠ aceite; ratificação tácita foi removida em 03/10/2026
I6 quem pega, avisa: nenhuma posse sem crachá válidoFATO REGISTRADOA continuidade entre executores foi promulgada em 27 de setembro de 2026 como emenda canônica, depois de o fundador avaliar que a fila tinha ficado segura demais: quando uma IA pegava a missão e a conversa morria, as outras não retomavam e a missão ficava parada marcada como em execução. A emenda introduziu lease curto com batimento, ponto de retorno devolvível, lease por lote e a regra de que uma pergunta nunca trava: há resposta por omissão, só nas classes de risco R0/R1, e delegação vira subficha.
FATO REGISTRADOEm 4 de outubro de 2026, a fila tinha 588 missões: 231 concluídas, 214 em devolutiva, 73 canceladas, 45 autorizadas, 11 aguardando decisão humana, 9 rascunhos e 5 rejeitadas; nenhuma em execução, em auditoria, em falha ou bloqueada no instante da contagem. A distribuição completa está na página de métricas.
M4
Identidade do executor
FATO REGISTRADOA regra “quem pega, avisa” exige que o executor se identifique por plataforma, plano e modo antes de tomar posse de qualquer objeto. O crachá foi adotado informalmente em 28 de setembro de 2026 e validado em 29/09 com um validador que bloqueia crachá malformado antes da posse (20 de 20 casos de teste).
cracha := 'cr1' '|' fornecedor '|' produto '|' plano '|' conta '|' modo '|' posto '|' modelo '|' execucao '|' origem
modo ∈ { interativo, agendado }
posto ∈ { EXECUTOR, ARQUIVISTA, TRIAGEM, FISCAL, PULSO, PAR-TECNICO, ... }
execucao := 'loc:' identificador_local_da_execucao
origem := 'conversa=' ref ';pai=' missao_mae ';fonte=' autoridade_usada
// campos desconhecidos recebem o literal 'desconhecido'; nunca são inferidos
// o validador verifica só a gramática; conta, plano e modelo não são deduzidosM5
Tempo como dimensão arquitetural
gatilho // o que dispara (relógio, evento, pedido humano)
rotina // a definição recorrente
ocorrencia // a instância prevista de uma rotina num instante
tentativa // a execução concreta de uma ocorrência; retentativa recebe ID próprio e mantém a ocorrência
efeito // o que mudou no destino, com recibo e readback
politica_de_atraso(ocorrencia) ∈ { recuperar, pular_com_recibo, escalar }
// nunca omitir silenciosamente trabalho atrasado
// marcos verificados como fatos separados
configuracao_relida < primeiro_disparo < uso_da_instrucao < entrega_utilFATO REGISTRADOEsse modelo é o motivo de o painel de métricas distinguir, para cada rotina, se a configuração foi relida, se o primeiro disparo foi observado e se houve entrega útil. Em 4 de outubro de 2026, as nove vigílias por cofre do assento Central tinham configuração conferida e primeiro disparo observado; entrega útil ainda não tinha sido avaliada.
M6
Roteamento do limiar
Doutrina do Limiar v1.0, validada em 29 de setembro de 2026 depois de um teste cego em três rodadas entre duas IAs de fornecedores distintos, de uma rodada de contraditório e de três ensaios de mecanismo. Responde à pergunta: quando laboratório, quando execução direta?
Não é extremo nem meio-termo: é um limiar (barbell). Livre abaixo, laboratório acima, quase nada no meio.
Doutrina do Limiar v0.1 (28/09/2026)
unidade := acao_situada = ⟨ acao, contexto, alcance, versao ⟩ // nunca o artefato isolado
T0 autoridade e escopo // pré-condição: sem mandato, NAO_LIBERADO
T1 reversibilidade // detecção + interrupção + recuperação; 7 dias é teto, não garantia
T2 multiplicação // a ação replica (playbook, loop, integração)?
T3 quem paga o erro // Central | equipe | terceiro
T4 observabilidade e contenção
autorizacao(acao) := // eixo 1: mandato; nunca se mistura com o regime
se ¬T0 → NAO_LIBERADO
senão → LIBERADA
regime(acao) := // eixo 2: só para ação liberada; mapeamento abaixo é inferência
se T2 ∨ T3 = terceiro → LAB_PLENO
senão se T1 ∧ T4 → LAB_CURTO ou ELASTICO (execução direta, observada)
senão → PENDENTE // decisão humana
travas anti-fossilização: laboratório com validade · portão auto-ajustável · entropia orçada
parametros_de_piloto: N = 20 ciclos como gatilho de revisão (não de rebaixamento); sem validação estatísticaFATO REGISTRADOO contraditório da primeira rodada impediu que a doutrina virasse permissão: “a unidade correta é ação mais contexto mais alcance mais versão, e não o artefato isolado”, e “a metáfora elastoplástica ajuda a explicar, mas não demonstra segurança”. A segunda rodada acrescentou os testes T0 e T4 e definiu laboratório como experimento delimitado para reduzir incerteza decisiva. A ideia de laboratório como propriedade do artefato, e não fase da empresa, vem da v0.1; a primeira rodada corrigiu a unidade para a ação situada.
M7
Cofres, planos, moedas e maturidade
é_cofre(x) :=
recebe_deposito_proprio(x) // moeda ou objeto versionável
∧ amadurece_por_bucket(x) // Bagunça → Bronze → Prata → Ouro → Diamante
∧ tem_par_S_H_quando_aplicavel(x)
∧ tem_missao_dona_e_continuidade(x)
é_plano(x) := vale_para_todos_os_cofres(x) ∧ ¬recebe_moeda(x) ∧ define_invariantes(x) ∧ evolui_por_emenda(x)
cofres := { C1 contexto e casos, C2 método e playbooks, C3 capacidades e agentes, C4 coordenação e empresa agêntica,
C5 voz e interlocução, C6 possibilidades de novos contextos, C7 ferramentas e integrações,
C8 arquitetura e evolução das relações, C9 Moving UP, C10 publicações, marketing e tráfego }
"Cofre N" sem letra := o par H_N + S_N // cada lado escreve-se com a letraMoeda 1 := resolver um caso específico, com resultado verificável, atualizando o contexto
Moeda 2 := depositar no playbook como se resolveu e o aprendizado sobre casos dessa natureza
Moeda 3 := transformar aprendizado em capacidade repetível (agente)
SEM_MOEDA := desfecho válido; não se cunha moeda para demonstrar atividade
// moeda é o que se deposita, nunca um cofre; níveis de bucket não são cofres novos
// "o método viaja, o dado fica" (emenda canônica das duas moedas, 19/09/2026)
maturidade(objeto) ∈ { Bagunça, Bronze, Prata, Ouro, Diamante } // por objeto, não selo global
Bronze ≠ VALIDATED ≠ CANONICAL ≠ autorização_de_execucao| Nível | Definição registrada para o cofre de coordenação |
|---|---|
| Bagunça | Iniciativas e agentes dispersos, com coordenação improvisada. |
| Bronze | Um primeiro ciclo completo funciona, com acompanhamento humano. |
| Prata | Os ciclos se repetem com responsabilidades, registros e tratamento de falhas. |
| Ouro | A operação integra diferentes funções e incorpora melhorias com resultados medidos. |
| Diamante | A empresa sustenta o aperfeiçoamento ao longo do tempo, com confiabilidade e autonomia dentro das alçadas definidas. |
M8
Registro epistêmico e doutrina da evidência
registro_epistemico := Fato | Evidência | Inferência | Hipótese | Intuição | Decisão // proposta de 18/07/2026
regua_das_devolutivas := FATO (fonte citada) · DECISÃO (ato do fundador) · INFERÊNCIA · PREFERÊNCIA · LACUNA
// doutrina da evidência e do acesso (14/09/2026, candidata)
observacao ≠ relato ≠ inferencia ≠ proposta ≠ decisao
negativa_qualificada(x) := "não encontrado em <escopo> na <data>" // nunca "não existe"
prova_proporcional(afirmacao) := força da prova ∝ consequência da afirmação
politica_de_acesso ≠ permissoes_observadas
aninhamento_de_paginas ⇏ leitura_dos_ancestraisFATO REGISTRADOExemplo de aplicação, registrado numa reconciliação de 27 de setembro de 2026: “evidência = divergência textual observada; modelo = proposta de separação de medidas; hipótese = benefício de adaptação governada; analogia = elastoplasticidade; decisão normativa = nenhuma; publicação = nenhuma”.
M9
Comando por magnitude
Regra de decisão interna promulgada em 26 de agosto de 2026 (doutrina 1.0). Só o princípio é publicado.
magnitude_normalizada(v) := 9 se 8,6 ≤ v ≤ 9,4
// o 9 não é um resultado; é um comando contextual
// a direção do comando depende do que está sendo medido (polaridade do contexto)
// abaixo de 8,6 não há rejeição: há ausência de comando
// multicamada: sem média, sem anulação entre camadas
// todo valor registrado declara a sua fonte: ⟨ camada, condição, valor, comando ⟩
abertos := { precedência entre camadas conflitantes, significado do 10 } // deferidos ao primeiro caso realM10
Invariantes constitucionais vigentes
Constituição Cognitiva do Simbionte v0.4, consolidada em 16 de julho de 2026 e única constituição vigente desde 17/07, com emenda canônica das duas moedas em 19/09. Vinte e um princípios; os de carga teórica estão abaixo.
| § | Princípio | Texto registrado |
|---|---|---|
| 1 | Separação estrutural, integração funcional | O núcleo do simbionte e cada hospedeiro devem permanecer distintos em identidade, custódia, dados, constituição e evolução, mas integrados por canais governados de troca. |
| 2 | Membrana governada | Toda troca entre núcleo e hospedeiro deve ser seletiva, rastreável, revogável e proporcional à função exercida. |
| 4 | Evolução por expansão | Novos aprendizados não devem sobrescrever automaticamente capacidades anteriores. |
| 5 | Plasticidade limitada | O simbionte deve adaptar sua manifestação ao contexto sem perder identidade; a adaptabilidade possui custos de complexidade, teste, manutenção e governança. |
| 6 | Acomodação antes da assimilação | Soluções locais devem ser testadas como configurações, módulos ou protocolos condicionais antes de serem incorporadas ao núcleo. |
| 7 | Reserva evolutiva | Capacidades sem uso atual podem permanecer latentes quando houver potencial futuro, origem rastreável e custo controlável. |
| 11 | Escala analítica | Macro: arquitetura, recipientes e relações. Médio: modelos, fluxos, propriedades e padrões. Micro: casos, documentos, mensagens e conteúdo detalhado. |
| 12 | Checkpointing cognitivo | Os gatilhos de macroetapa, volume de evidências, tempo e degradação funcionam como radar de continuidade e não como encerramento automático. |
| 19 | Camadas epistêmicas do hospedeiro | Distinguir estado constitucional vigente, estado histórico recebido, estado operacional atual, diferenças entre arquitetura e implantação e lacunas autenticamente desconhecidas. |
| 20 | Leitura antes da intervenção | Ler, garimpar, extrair, organizar, confrontar, debater, validar, aprofundar e somente depois executar. |
| emenda | Duas moedas, fractal | O princípio das duas moedas aplica-se de forma fractal às escalas do programa; Moeda 1 resolve um caso, Moeda 2 deposita no playbook como se resolveu. |
M11
Cadeia de transformação (documento fundador, histórico)
contexto → conhecimento → decisão → missão → execução → evidência → memória institucional
memorias := { constitucional, organizacional, operacional, episódica, probatória, semântica }
principios 8–10:
8. não confundir metáfora com capacidade técnica
9. fazer o núcleo funcionar no contexto do hospedeiro
10. crescer de forma fractal sem multiplicar desorganização