🌊 C.A.P.I.B.A. — Memória Persistente Causal

Causal, Asynchronous, Persistent, Immutable Block Architecture — a memória de longo prazo do PAEBIRU. Onde o kernel cuida da mensagem em trânsito, o capiba cuida da mensagem em repouso: como ela se torna dado, como o dado se torna conhecimento, e como o conhecimento se preserva no tempo causal.

flowchart LR
    subgraph Hot [Hot path · µs–ms]
        N[1. Nascente<br/>Ring Buffer / RAM]
    end
    subgraph Warm [Warm path · ms–s]
        C[2. Correnteza<br/>MmapStore / WAL<br/>Prolly Trees]
        M[3. Manguezal<br/>Arrow in-memory<br/>+ Zero-Trust filter]
    end
    subgraph Cold [Cold path · s–min]
        O[4. Oceano<br/>Iceberg + IPLD CIDs]
    end
    subgraph Volatile [Volatile · min–h]
        Ch[5. Chuva<br/>Compute-over-data<br/>→ Plasmídeo WASM]
    end
    N -->|Langevin Tick| C
    C -->|Pororoca Causal<br/>sync P2P| M
    M -->|Transmutação Analítica<br/>Parquet| O
    O -->|Compute-over-Data| Ch
    Ch -->|Precipitação<br/>Evolutiva| N

Princípio-guia: C.A.P.I.B.A. não é “um banco de dados” — é um ecossistema metabólico de dados com 5 estágios análogos ao ciclo hidrológico. Cada estágio tem temperatura termodinâmica, formato de representação e função diferentes. Nada “vira storage” por inércia; cada bloco é causalmente endereçado e tem uma vida útil declarada pelo seu MUS (Minimum Useful Survival).

1. Fronteira do BC

Membranas existem por uma razão: se o problema não é de dados, é de outro BC. Devolva o ticket; não estique a membrana.

2. Os 5 estágios

Cada estágio é um trade-off explícito entre latência, consistência e custo termodinâmico. A escolha do estágio é arquitetural, não operacional — não se move dado entre estágios por conveniência.

2.1 Nascente (Hot) — capiba::ring

• Função: captura de evento no momento de criação.
• Representação: ring buffer lock-free em RAM; ~µs de latência.
• Transição para o próximo: Langevin Tick — quando o bloco resfria (i.e., outros nós da sua vizinhança causal já o viram), é despejado no WAL.
• Consistência: estritamente local; sem replicação.
• Limite de tamanho: PAEBIRU_NASCENTE_RING_BYTES (default 256 MB).
• Anti-padrão: usar Nascente como fila durável. Não é.

2.2 Correnteza (Warm) — capiba::mmap::wal + capiba::prolly

• Função: buffer causal, replicável entre nós da LocalSyncDomain.
• Representação: MmapStore (WAL posix) + Prolly Tree indexada por DVV.
• Transição para o próximo: Pororoca Causal — batched sync P2P com delta-sync via Bloom filter.
• Consistência: causal (não cronológica).
• Filtros: StigmergicImmuneSystem — pacotes que violam invariante causal são desviados para o Manguezal como “lama tóxica”.
• MuleNodes (LoRa, ATmega): usam Pororoca com janelas Langevin estendidas, eventualmente consistente.

2.3 Manguezal (Cool) — capiba::arrow

• Função: análise intermediária + quarentena Zero-Trust.
• Representação: Apache Arrow in-memory; transações vetoriais columnares.
• Transição para o próximo: Transmutação Analítica — quando o bloco passa no filtro Zero-Trust (CDDL + validação semântica + ZK-PoL se houver geolocalização), é despejado em Parquet e preparado para o Oceano.
• Consistência: forte eventual; semântica “read-your-writes” no mesmo nó.
• Quarentena: blocos suspeitos → MacrophageVM (ver Tópicos em formalização) para síntese de anticorpos. Nunca se executa o conteúdo de um bloco em Manguezal sem passar pelo Portão 5 (CDDL).

2.4 Oceano (Cold) — capiba::iceberg + capiba::ipfs

• Função: cold storage soberano, auditável, replicado via erasure coding entre nós da Confederation Tier.
• Representação: Apache Iceberg (snapshot lineage) + IPLD CID v1 com multicodec + multihash (BLAKE3).
• Transição para o próximo: Erasure Coding + Sovereignty Gate — antes de descer, dados são auditados. Sovereignty Gate verifica soberania (não violação de jurisdição, não dado pessoal sem máscara, etc.).
• Consistência: eventual; snapshots imutáveis.
• Migração irreversível: uma vez no Oceano, o dado é tratado como fato histórico. Mudanças exigem novo bloco causal.

2.5 Chuva (Volatile) — capiba::compute

• Função: compute-over-data. Gradientes para treino federado; pesos viram plasmídeo (regra distribuída).
• Representação: trainer federado (FLAIR/Ising) que consome Iceberg manifest e emite WeightDelta.
• Transição para o próximo: Precipitação Evolutiva — WeightDelta vira plasmídeo WASM (ver Tópicos em formalização) com versão própria.
• Idempotência: aplicar o mesmo plasmídeo duas vezes = aplicar uma única vez. Chuva é convergente.
• Anti-padrão: Chuva que move o Oceano. Compute vai até o storage; storage nunca vai até o compute.

3. Modelo de dados canônico

Invariante fundamental: todo bloco carrega seu DVV. Nenhum bloco é persistido sem DVV válido (verificável contra qualquer peer da vizinhança causal).

4. Princípios operacionais (vinculantes)

1. Tempo causal, não cronológico. Ordenação por DVV. Instant::now() e timestamps de wall-clock nunca são fonte de verdade para ordenação.
2. Content addressing. Endereço é o par (BLAKE3(conteúdo), DVV). Mesmo conteúdo em maturidades diferentes = CIDs diferentes.
3. Apoptose saudável. MUS define a maturidade abaixo da qual o bloco evapora. Não é “limpeza” — é metabolismo.
4. Sovereignty Gate. Antes de Oceano, audit (CDDL + semântica + ZK-PoL se houver geolocalização).
5. Compute-over-data > move-data. Compute vai até o storage.
6. Quarentena imunológica. Manguezal é filtro Zero-Trust; lama tóxica → MacrophageVM.
7. Sincronização MuleNode. Pororoca Causal: batched, eventual, com _receipts_ imutáveis.
8. Backpressure de I/O. Profundidade finita no WAL; produtor adapta-se ao consumidor (jamais buffer infinito).

Violação de qualquer um destes princípios é regressão automática.

5. Tipos de operação

6. Tópicos a formalizar (vinculantes a médio prazo)

Estes tópicos precisam virar RFC ratificada antes de mudanças no contrato público do C.A.P.I.B.A.:

• Definição e motivação do C.A.P.I.B.A.; Prolly Trees
• CIDs IPLD + content addressing BLAKE3
• Apoptose — esquecimento saudável (MUS)
• Iceberg catalog no Oceano
• Landauer Gate — custo termodinâmico da retenção
• Fail-stop em 7 escalas (também C.A.P.I.B.A.)

A lista canônica e o estado de cada tópico vivem em RFCs em construção. Mudanças em qualquer um destes pontos exigem RFC ratificada (ver processo).

7. Relação com outros BCs

flowchart LR
    K[kernel<br/>mensagem em trânsito] -->|receipt| CAP[capiba<br/>mensagem em repouso]
    B[biology<br/>ABAPORU] -->|causal events| CAP
    E[economy<br/>Loteria Joule] -->|WeightDelta| CAP
    L[learn<br/>FedAvg] -->|gradient sync| CAP
    Z[zk<br/>ZK-PoL proofs] -->|sovereignty proofs| CAP
    CAP -->|compute-over-data| L
    CAP -->|stored receipts| E
    CAP -->|snapshots| AP[api<br/>query federada]

• kernel ↔ capiba: todo receipt soberano é persistido como CausalBlock; toda leitura de receipt é via DVV (não por timestamp).
• biology ↔ capiba: eventos de ABAPORU (crença, desejo, intenção) viram blocos causais; memória de longo prazo do agente = Nascente + Correnteza.
• learn ↔ capiba: trainer federado (Chuva) consome Iceberg (Oceano) e emite plasmídeo (precipitação).
• economy ↔ capiba: o DRE (Data Refinery Engine) usa C.A.P.I.B.A. como insumo canônico para o LandauerLedger.
• zk ↔ capiba: provas de ZK-PoL entram no Sovereignty Gate antes da migração para Oceano.

8. Quando não é C.A.P.I.B.A.

• “Mensagem demora para chegar” → kernel, não dados.
• “Modelo não converge” → learn, não dados.
• “Quem pode escrever X?” → economy + DAO, não dados.
• “Como assino bloco Y?” → kernel (segurança), não dados.

9. Padrões de mudança

Adicionar coluna a um schema Iceberg

1. Migration no DRE (capiba::dre::migrations).
2. Atualizar MusThreshold se a coluna afeta retenção.
3. Atualizar este documento.
4. Teste de round-trip causal (escreve → lê em DVV maior → compara).
5. make test + fuzzing de serialização Iceberg.

Adicionar política de apoptose (MUS)

1. Invariante formal em TLA+ (capiba/formal/).
2. Implementação em capiba::domain::apoptosis.
3. Teste property-based com maturidades aleatórias.
4. Verificar que a Landauer Gate não viola $k_B \cdot T \cdot \ln 2$.
5. Métrica Prometheus: paebiru_capiba_apoptosis_total.

Criar novo MuleNode adapter (CAN bus, Modbus)

1. Implementar capiba::ports::MuleTransport.
2. Adapter em capiba::adapters::mule::<tecnologia>.
3. Garantir no_std compatível.
4. cargo check --target thumbv7em-none-eabihf.
5. Atualizar este documento (tabela de estágios, se aplicável).

10. Checklist para mudanças em capiba

• A mudança é no C.A.P.I.B.A. e não em outro BC?
• Timestamps de wall-clock não são usados para ordenação (DVV)?
• Content addressing (BLAKE3/IPLD) é usado, não path?
• MUS/Apoptose foram considerados?
• Se toca rede/cripto, paebiru-security foi consultado?
• Se toca ML/inferência, paebiru-ai foi consultado?
• Testes property-based para invariantes causais?
• cargo test -p paebiru-capiba + --target thumbv7em-none-eabihf se aplicável?
• Documentação (este arquivo) atualizada?

Veja também

• Dicionário canônico · C.A.P.I.B.A.
• Skill paebiru-data — fonte operacional
• Math foundations · DVV
• Math foundations · Landauer
• Maturidade Causal · fila M/M/1
• Tópicos a formalizar — versões formais em construção