SYMBIONTES™

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.

posições e recursão de escala (direção de 02/10/2026)
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_ELABORACAO

M2

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)
função de passagem (figura-mãe, 29/09/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"
Planos propostos em outubro de 2026 (candidatos). Um plano não recebe moeda nem amadurece por bucket.
Plano transversalFunçãoNatureza
Π1 · MembranaFronteira S/H: visibilidade e passagem.vale para todos os cofres; evolui por emenda, não por bucket
Π2 · Controle e evidênciaSTOP, lease com batimento, chave de efeito, crachá, recibo, readback, observador independente.idem
Π3 · QuadradoA infraestrutura em que S e H operam: bases, armazenamento, execução, conectores.idem; não é um cofre
Π4 · Custo como dadoToda execução registra o que custou.idem

M3

Missão: estados, eventos e invariantes

máquina de estados da missão (fila da Central, esquema v0.4; versão simplificada, inferência editorial)
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álido

FATO 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).

gramática do crachá (versão cr1)
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 deduzidos

M5

Tempo como dimensão arquitetural

separações obrigatórias (modelo aceito em 27/09/2026)
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_util

FATO 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)
Doutrina do Limiar: o haltereUm haltere: peso esquerdo para ações livres e reversíveis, barra fina no meio quase vazia, peso direito para laboratório pleno; cinco testes acima decidem o regime; um portão de não liberado à esquerda.T0 autoridade e escopoT1 reversibilidadeT2 multiplicaçãoT3 quem paga o erroT4 observabilidadeunidade: ação + contexto + alcance + versãoLIVRE ABAIXOELÁSTICOreversível, observável, erro pago por quem ageexecução direta, com contençãoquase nada no meio · LAB-CURTO · PENDENTE (decisão humana)LABORATÓRIO ACIMALAB-PLENOmultiplica (playbook, loop, integração)ou o erro é pago por terceiroNÃOLIBERADOsem T0unidade: ação situada (a v0.1 falava em propriedade do artefato) · travas: laboratório com validade, portão auto-ajustável, entropia orçadaparâmetros de piloto: 7 dias como teto de T1, 20 ciclos como gatilho de revisão; sem validação estatística
Figura 1. FATO REGISTRADOA forma de haltere: ações baratas e reversíveis correm livres; ações que multiplicam, que não se revertem ou cujo erro é pago por terceiro vão a laboratório; o meio é quase vazio. Os cinco testes decidem o regime.
roteamento em dois eixos (v1.0) · leitura editorial, não o texto da doutrina
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ística

FATO 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

critério cofre × plano (03/10/2026, candidato)
é_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 letra
moedas e ciclo (direção de 23–26/09/2026)
Moeda 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
Escala conceitual inicial registrada em 23/09/2026. Os critérios de passagem ainda precisam ser tornados mensuráveis; nenhum nível foi atribuído ao sistema inteiro.
NívelDefinição registrada para o cofre de coordenação
BagunçaIniciativas e agentes dispersos, com coordenação improvisada.
BronzeUm primeiro ciclo completo funciona, com acompanhamento humano.
PrataOs ciclos se repetem com responsabilidades, registros e tratamento de falhas.
OuroA operação integra diferentes funções e incorpora melhorias com resultados medidos.
DiamanteA 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

camadas e régua
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_ancestrais

FATO 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.

regra dos 9
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 real

M10

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ípioTexto registrado
1Separação estrutural, integração funcionalO 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.
2Membrana governadaToda troca entre núcleo e hospedeiro deve ser seletiva, rastreável, revogável e proporcional à função exercida.
4Evolução por expansãoNovos aprendizados não devem sobrescrever automaticamente capacidades anteriores.
5Plasticidade limitadaO simbionte deve adaptar sua manifestação ao contexto sem perder identidade; a adaptabilidade possui custos de complexidade, teste, manutenção e governança.
6Acomodação antes da assimilaçãoSoluções locais devem ser testadas como configurações, módulos ou protocolos condicionais antes de serem incorporadas ao núcleo.
7Reserva evolutivaCapacidades sem uso atual podem permanecer latentes quando houver potencial futuro, origem rastreável e custo controlável.
11Escala analíticaMacro: arquitetura, recipientes e relações. Médio: modelos, fluxos, propriedades e padrões. Micro: casos, documentos, mensagens e conteúdo detalhado.
12Checkpointing cognitivoOs gatilhos de macroetapa, volume de evidências, tempo e degradação funcionam como radar de continuidade e não como encerramento automático.
19Camadas epistêmicas do hospedeiroDistinguir estado constitucional vigente, estado histórico recebido, estado operacional atual, diferenças entre arquitetura e implantação e lacunas autenticamente desconhecidas.
20Leitura antes da intervençãoLer, garimpar, extrair, organizar, confrontar, debater, validar, aprofundar e somente depois executar.
emendaDuas moedas, fractalO 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)

Constituição Técnica v0.1 (22/07/2026)
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