- Introdução: O Fim da Era do Descarte
Por décadas, a engenharia de software foi intoxicada pelo dogma do "Fail Fast". Em sistemas de alto volume e baixo valor, como feeds sociais ou buscas públicas, falhar rápido é uma virtude de economia. Entretanto, para sistemas internos de alto valor informacional — CRMs, ERPs, fluxos financeiros e jurídicos — o "Fail Fast" não é eficiência; é negligência arquitetural.
Tratar uma ambiguidade semântica como um erro terminal é uma forma de falência semântica. O sistema comporta-se como um "porteiro cego": diante da menor incerteza, ele descarta o dado, ignorando que o valor real reside na intenção, não no transporte.
O "Manifesto Intent-Healing" redefine essa prioridade:
"Quando o dado vale muito, pense antes. Sistemas internos de verdade não precisam ser mais rápidos; precisam ser mais responsáveis. A responsabilidade começa quando o sistema para de perguntar 'isso está correto?' e passa a perguntar: 'o que você quis dizer, e vale a pena salvar?'"
- O Problema do Modelo Binário Tradicional
O modelo tradicional de Request/Response binário (sucesso ou erro 4xx/5xx) falha em representar a complexidade das organizações. Ele trata a intenção como algo descartável, ignorando que um erro técnico frequentemente carrega um contexto humano crítico ou uma consequência estratégica irreversível.
Análise de Valor vs. Risco:
- Sistemas de Baixo Valor (Edge/Public APIs): Focados em throughput. O descarte é um mecanismo de defesa contra spam e sobrecarga. Risco: Desprezível.
- Sistemas de Alto Valor (Core/Internal): Onde a integridade do dado é soberana. O descarte é um ato de irresponsabilidade operacional. Riscos: Impacto legal, perda de histórico organizacional insubstituível e custo financeiro de retrabalho humano.
- A Intenção (Intent) vs. A Requisição
Conforme a RFC-0001 e RFC-0002, uma requisição é meramente uma fonte de detecção, enquanto a Intenção (Intent) é a unidade lógica que buscamos materializar.
A Intent é encapsulada em um Intent Envelope, um registro append-only e imutável de história. Diferente de um payload comum, o Envelope exige blocos específicos para existir: Identidade, Contexto, Healing e Decisão. Enquanto o estado da intenção transita, sua história permanece preservada.
A regra normativa é absoluta: "A validação não condiciona a existência da Intent, mas sim sua materialização."
- A Anatomia da Antifragilidade: Do Transporte à Aplicação
A antifragilidade começa antes mesmo da semântica de aplicação, no TCRP (Transport Chunking & Reassembly Protocol). A primeira barreira contra o ruído é a identidade. Como dita a Regra de Ouro: "Chunk sem identidade é ruído. Ruído não atravessa boundary."
Uma vez que o transporte é garantido de forma determinística e idempotente, a Intent entra no fluxo canônico de quatro etapas:
- Detectar: Identificação da intenção, mesmo que em estado bruto (Detected).
- Curar (Healing): Ações sistemáticas para reduzir ambiguidades e completar dados.
- Validar: Verificação final contra políticas de domínio (a autorização).
Materializar: Execução do efeito colateral e registro da decisão terminal.
Healing: O Coração da Recuperação Semântica
O Healing (Cura), definido na RFC-0005 e RFC-HSP-01, é o processo de tornar a Intent legitimamente validável. Ele difere radicalmente de um retry técnico ou de uma correção silenciosa — o que seria um Bypass Cognitivo inaceitável. No HSP, "Healing prepara, Validação autoriza".
Tipo de Healing Descrição e Resolução Semântica
Normalização Correções de formato (datas, encoding, capitalização) sem alterar o sentido.
Completação Preenchimento de dados ausentes via defaults ou inferência autorizada por política.
Correção Semântica Ajuste de valores inválidos usando mapeamentos de domínio e sinônimos.
Desambiguação Resolução de múltiplos significados, frequentemente via intervenção humana.
Enriquecimento Adição de metadados externos que auxiliam a decisão, sem alterar a Intent original.
Aviso de Governança: Healing sem política é mutação arbitrária. O processo é finito: ao esgotar as possibilidades sem sucesso, o sistema atinge a Exaustão de Healing, um estado formal de prova onde a máquina declara sua incapacidade de prosseguir sem ajuda externa.
- A Máquina de Estados da Resiliência (RFC-0003)
A governança da decisão é regida por uma máquina de estados estrita. Aqui, estados governam decisões, e nunca o contrário de forma implícita.
- Detected: Intenção identificada, porém instável e imperfeita.
- Clarifying: Redução ativa de ambiguidade (Thought Logs) sem alteração de dados brutos.
- Healing: Aplicação de Healer Agents para ações corretivas registradas.
- Ready: Estado de consistência semântica; a Intent "deseja" ser validada.
- Materialized: Estado terminal de sucesso; validação aprovada e efeito persistido.
Rejected: Estado terminal de falha; a materialização foi negada por política ou exaustão.
Observabilidade Interativa: O Tri-Channel Healing Protocol
Para sair da "Caixa Preta", adotamos o Adaptive Observability Negotiation (RFC-0008) através do Tri-Channel Healing Protocol (RFC-OBS-02). A observabilidade deixa de ser um log pós-morte para se tornar uma interface de operação em tempo real.
O sistema opera em três canais não sobrepostos:
- Canal de Handshake (HTTP): Inicia a Intent e estabelece o intentId.
- Canal Cognitivo (AON/NDJSON): O canal de "pensamento em voz alta". O sistema prefere o streaming de NDJSON para compatibilidade de infraestrutura, emitindo intent.healing_request quando trava.
- Canal de Evidência (Event Log): O registro imutável de todos os eventos para auditoria forense.
Isso permite que o sistema peça ajuda ao humano (Human-in-the-loop) via comandos de cura em tempo real, sem interromper o fluxo assíncrono.
- Governança Semântica e Identidade Global
Nada atravessa fronteiras sem uma identidade global única (RFC-0001-Identity). Utilizamos URNs tipadas: urn:purecore:::. No nível do código, esses IDs são tratados como Branded Types (Nominal Typing) para garantir segurança em tempo de compilação.
O Semantic Data Governance Registry (SDGR) atua como a infraestrutura ativa que define o significado de cada campo. Dado sem dono semântico é dado inválido. O SDGR garante que o Healing respeite as invariantes de domínio e as bases legais (LGPD) de forma nativa, impedindo que o sistema "invente" significados durante a cura.
- Conclusão: Responsabilidade como Novo Padrão Ouro
A transição para o antifrágil exige que arquitetos abandonem a preguiça do descarte prematuro. Aceitar a complexidade cognitiva do Intent-Healing Protocol é o preço para garantir a segurança operacional absoluta e a preservação do valor informacional.
Sistemas que se curam em silêncio não são inteligentes; são perigosos. A evolução exige transparência, identidade e, acima de tudo, a aceitação de que o erro é apenas um estado transitório.
Regra de Ouro da RFC TCRP:
"Chunk sem identidade é ruído. Ruído não atravessa boundary."
Top comments (0)