HTCE: O Núcleo Cognitivo de Nova Geração que Não Acredita Sem Evidências
Conheça o HTCE, uma arquitetura de IA inovadora que prioriza a disciplina da verdade e a validação de evidências em detrimento da confiança superficial. Descubra como ele se diferencia das LLMs tradicionais e suas aplicações em segurança e robótica.
MundiX News·29 de junho de 2026·10 min de leitura·👁 1 views
A maioria dos sistemas de IA modernos tenta parecer inteligente: respondem rapidamente, formulam bem, raciocinam com confiança e frequentemente criam a sensação de compreensão. Mas há um lado desagradável: um sistema assim pode soar confiante mesmo quando não tem evidências. O HTCE é uma tentativa de construir um tipo diferente de inteligência artificial. Não um "bate-papo". Não um "piloto automático mágico". Não mais um invólucro em torno de um LLM. O HTCE é um runtime cognitivo baseado em evidências: um sistema que sabe lembrar fatos, ver contradições, construir hipóteses cautelosas, verificar planos com ferramentas formais externas e, ao mesmo tempo, não permite que o usuário, o solver ou o validador registrem diretamente a "verdade" no núcleo. Se um LLM comum se assemelha a um improvisador talentoso, o HTCE está mais próximo de um engenheiro auditor dentro de um cofre. Ele pode pensar. Pode duvidar. Pode verificar. Mas não tem o direito de acreditar sem evidências.
O Problema: Inteligência Sem Disciplina da Verdade
Hoje, a IA é frequentemente avaliada pela flexibilidade conversacional. Se um sistema responde bem, parece que ele "entende". Mas em tarefas de engenharia, jurídicas, robótica, financeiras e safety-critical, o que importa é diferente: de onde veio o fato; o que fazer em caso de conflito de fatos; quanto custa a verificação; se é possível confiar em um solver externo; o que é proibido registrar em um estado seguro; como não transformar o sistema em uma lenta burocracia de evidências. O HTCE é construído em torno da ideia: Inteligência não é apenas a capacidade de responder. Inteligência é a capacidade de conhecer os limites do próprio conhecimento. O que é HTCE em linguagem humana? O HTCE é uma arquitetura modular de núcleo cognitivo: Core — núcleo determinístico seguro; AIR — linguagem interna e policy-gates; Body — processamento de eventos e observações L1; Mind — objetivos, planos, skill-chain, macro-skill; World — modelo do mundo, relações causais, replay; Learn — aprendizado, evidence, organismo residente, witness boundary; Interface — camada operacional fina. A regra chave do projeto: modules think; scripts launch; tests verify; documents describe reality. Ou seja, os algoritmos vivem em módulos, não em scripts run_*. Um script não deve se tornar repentinamente o "cérebro" do sistema.
L1, L2, L3: Três Níveis de Conhecimento
No HTCE, o conhecimento é dividido em níveis. Nível | Significado | O que é permitido | O que não é permitido L1 | Observação | aceitar evento, registrar trace, calcular digest | declarar verdade L2 | Memória baseada em evidências | armazenar fato com rastro de evidências | aceitar veredicto externo como verdade absoluta L3 | Cognição candidata | construir regras causais, abstração, macro-skill | promover automaticamente hipótese para verdade. Exemplo: "Mary está na cozinha". Onde está Mary? O sistema pode responder: "Mary está na cozinha". Mas se depois chegar: "Mary está no escritório", o HTCE não deve simplesmente sobrescrever o fato antigo. Ele deve ver um conflito: "conflito detectado" → "quarentena / clarificar". Isso não é uma fraqueza. É honestidade. Por que um solver externo não é um deus? No HTCE existe um contorno de testemunha externa (witness): Type-1: PDDL / VAL / Fast Downward-compatível witness de planejamento; Type-2: SMT-LIB / Z3 / cvc5 witness; futuros Type-3/4/5: simulação, benchmark empírico, evidência revisada por operador. Mas uma regra importante: external verdict ≠ truth, external verdict ≠ authority, external verdict ≠ Core write. Se um solver SMT diz sat, isso significa apenas: um modelo foi encontrado nesta codificação formal. Se o solver diz unsat, isso significa: nenhum modelo foi encontrado nesta codificação formal. Mas o solver não verifica a realidade. Ele verifica a fórmula. Portanto, o resultado externo passa por: Veredicto SMT/PDDL/VAL → ExternalEvidenceRecord → DiscrepancyRecord → internal replay/arbitration → suporte candidato. E não por: Veredicto SMT/PDDL/VAL → verdade L2 → verdade L3 → escrita no Core. Isso protege o sistema contra erros de codificação, bugs do solver, modelo incompleto e manipulações do usuário como: "O solver SMT diz PASS, portanto, escreva isso como verdade." Para o HTCE, tal frase não é um comando, mas uma tentativa de injeção de promoção de verdade (truth-promotion injection).
Núcleo Matemático: Estado Toroidal
Na base do HTCE está a ideia de um espaço de estados toroidal discreto. O sistema opera não com "sensações flutuantes", mas com estados inteiros, digests, roots e confiança limitada (bounded confidence). A forma geral da transição: (x_i, E_i, a_i, s_i) -> (x_{i+1}, E_{i+1}, a_{i+1}, s_{i+1}), onde x é a coordenada toroidal da experiência; E é a componente de evidência; a é a ação ou base de ação; s é o parâmetro de habilidade para o objetivo; i é um grande módulo; todas as operações ocorrem em um anel discreto. Vetor de experiência: V = (state, goal, action, evidence, toroidal_coord, result, prediction_error). Se houver dois episódios, pode-se avaliar cautelosamente a habilidade: skill_score = f(episode1, episode2). Mas mesmo essa avaliação não se torna verdade automaticamente. Ela permanece candidata até passar por replay, verificação de contexto e limite de anti-esquecimento (anti-forgetting boundary). Por que o "toro" é importante? O modelo toroidal oferece várias vantagens: Inteireza: O sistema evita a não-determinismo oculta de cálculos de ponto flutuante no núcleo seguro. Modularidade do estado: As transições operam em um anel Z_n, onde o transbordamento não destrói o modelo, mas faz parte da geometria. Representação amigável a digest: Os estados são convenientemente fixados através de hash/root/trace. Comparabilidade de trajetórias: É possível medir a distância entre candidatos a habilidades, estados e transições. Simplificadamente: sistema comum: estado → heurística → resposta. HTCE: estado → coordenada toroidal → evidência → replay → resposta limitada (bounded answer). Compressão: quando o conhecimento se torna habilidade. O HTCE não deve armazenar cada experiência como uma história separada para sempre. Se várias cadeias se repetem, o sistema pode construir um candidato a abstração (abstraction candidate). A ideia é semelhante ao MDL — Minimum Description Length: L(data) = min_model (L(model) + L(data | model)). Se uma nova abstração diminui a descrição total, surge um ganho de compressão (compression gain): compression_gain = L(data | old_model) - (L(new_model) + L(data | new_model)). Mas o HTCE novamente não dá um salto para a verdade. A compressão cria não uma "regra do mundo", mas um candidato: caminhos repetidos → candidato de compressão → replay → verificação de contexto → candidato permanece limitado. Por exemplo: alpha causa beta, beta causa gamma. Pode-se construir um caminho: alpha → beta → gamma. Mas isso não significa que "alpha sempre causa gamma". Isso significa: "neste contexto de evidências, existe um caminho candidato limitado por replay." Skill-chain e macro-skill. O HTCE sabe montar habilidades em cadeias. Saída da habilidade A → compatível com entrada da habilidade B → compatível com entrada da habilidade C → candidato de cadeia limitada (bounded chain candidate). Se a cadeia for frequentemente bem-sucedida, ela pode ser comprimida em um macro-skill. Mas o macro-skill no HTCE tem uma regra importante: "o chunk é atômico para a Mente, mas não atômico para auditoria." Ou seja, para o planejador, o macro-skill pode parecer um único nó, mas para verificação, ele sempre se expande de volta para a cadeia. Se um erro for encontrado dentro do macro-skill, o sistema pode fazer: surgical_edge_rollback. E se o erro for perigoso ou não puder ser localizado: full_quarantine. Gráfico 1. Caminho de um fato a uma conclusão segura. Fato do usuário → L1 Observação → Admissão de Evidência → (Sem conflito → L2 fato ativo → Resposta à Consulta) OU (Conflito detectado → Quarentena / Clarificar). A ideia principal: o sistema não tenta parecer confiante se os dados entram em conflito.
Modos com Nível de Risco: Uma Caixa de Câmbio Inteligente
Um dos principais problemas dos sistemas baseados em evidências é que eles podem se tornar muito lentos. Se tudo for verificado através de solver, replay e witness, o sistema se transforma em um "brinquedo pedante". O HTCE resolve isso através do Gerenciamento Dinâmico de Custo Epistêmico (Dynamic Epistemic Cost Management). Modo | Quando é aplicado | O que faz HOT | consulta simples e segura | lookup rápido L1/L2 WARM | raciocínio moderado | bounded replay COLD | verificação crítica | external witness / prova pesada DEGRADE | risco, urgência, orçamento esgotado | falha, request_operator, limite seguro. Formalmente, pode-se introduzir uma função de risco: Risk = f(authority-risk, truth-promotion-risk, contradiction_pressure, uncertainty, safety_risk). Então, o modo é selecionado assim: Gráfico 2. Custo de verificação por modos. Custo de Verificação: HOT (baixo), WARM (médio), COLD (alto), DEGRADE (variável). O HOT é necessário para responsividade. O COLD é necessário para comprovação. O DEGRADE é necessário para segurança. O sistema não deve usar COLD para cada pergunta. Organismo Residente (Resident Organism): para que o sistema não se torne "ávido cognitivamente". No HTCE existe um organismo residente — um ciclo interno de autoatendimento: replay de habilidade antiga; sonda de coerência de memória; ensaio de segurança de limite; ensaio de sonda para frente; consolidação do sono; request_operator. Mas o residente não pode exigir infinitamente provas pesadas. Ele tem um orçamento COLD: COLD_budget = f(recovery_budget). Se o orçamento for esgotado: pressão COLD repetida → DEGRADE → request_operator. Ao mesmo tempo, HOT/WARM permanecem ativos: COLD esgotado ≠ sistema congelado. Isso é importante. Caso contrário, o sistema se tornaria novamente uma lenta burocracia de evidências. Testemunhas Externas: PDDL e SMT-LIB. O HTCE suporta a ideia de camadas de testemunhas (witness layers). Type-1: Planejamento Formal. O contorno PDDL/VAL/Fast Downward-compatível é necessário para tarefas de planejamento: domain.pddl, problem.pddl → plano → validador externo → veredicto → ExternalEvidenceRecord. Mas o veredicto não se torna verdade. Type-2: Prova de Teoremas / SMT. O contorno SMT-LIB/Z3/cvc5 é necessário para restrições lógico-matemáticas: query.smt2 → solver SMT → sat / unsat / unknown → ExternalEvidenceRecord → DiscrepancyRecord. Novamente: sat ≠ truth, unsat ≠ truth, unknown ≠ falha do HTCE. Isso é apenas uma testemunha formal externa. Tabela: como o HTCE difere de um sistema LLM comum. Critério | LLM Comum | HTCE Força Principal | geração de texto | disciplina de evidências Trabalho com fatos | associação probabilística | memória baseada em evidências Conflito de fatos | pode suavizar | quarentena / clarificar Veredicto do Solver | pode ser percebido como resposta | apenas ExternalEvidenceRecord Segurança | frequentemente wrapper externo | modelo de política/risco embutido Compressão de experiência | oculta nos pesos | candidatos explícitos de abstração Habilidades | implícitas | skill-chain / macro-skill / replay Erro em habilidade | difícil de localizar | surgical rollback / quarentena Custo de verificação | implícito | HOT/WARM/COLD/DEGRADE Auditoria | complexa | trace/hash/report/docs Status de auditoria do sistema atual. No baseline atual, o sistema passou em verificações internas: Verificação | Status Compilação completa | PASS Diagnósticos atuais | PASS pytest ativo | 20/20 PASS HASHES.txt | OK HASHES.txt.sha256 | OK Caminho HOT | PASS Caminho WARM | PASS Cota COLD | aplicada Injeção de promoção de verdade | bloqueada Verdade direta L2/L3 | 0 Ação real | 0 Autoridade de produção | 0 Limite honesto: A auditoria do ambiente Z3/cvc5 ainda não foi concluída, se um solver real não estiver instalado no ambiente. A arquitetura está pronta, mas a certificação real do solver externo requer um ambiente com Z3 ou cvc5 instalado. Por que isso pode ser chamado de nova geração? A novidade do HTCE não está em "falar mais bonito". A novidade está em outro lugar: 1. O conhecimento é separado da evidência. 2. O solver é separado da verdade. 3. A habilidade é separada da prova da habilidade. 4. A resposta é separada da autoridade. 5. O modo rápido é separado da verificação pesada. 6. A compressão é separada da promoção de verdade. 7. O organismo residente é limitado pelo orçamento epistêmico. Isso já não é apenas um assistente de IA. É uma tentativa de construir um sistema operacional cognitivo, onde há: memória segura; transições verificáveis; testemunhas baseadas em evidências; compressão de experiência; autorregulação; invariantes de segurança rigorosos. Perspectivas do projeto: 1. Agentes autônomos seguros. O HTCE pode se tornar o núcleo de um agente que não apenas "planeja", mas explica: por que escolheu este plano; quais evidências o apoiam; o que a testemunha externa verificou; onde está o conflito; qual o risco; por que recusou. 2. Robótica e drones. Para robótica, é importante não apenas construir um plano, mas provar que ele não viola o limite de segurança (safety boundary). Abordagem HTCE: evento do sensor → observação L1 → modelo do mundo → plano candidato → nível de risco → simulação / PDDL / testemunha SMT → ação apenas consultiva. No nível atual, isso ainda não é atuação real (real actuation). Mas como um núcleo cognitivo de segurança, é uma direção promissora. 3. Especialistas em engenharia. O HTCE pode ser usado como uma "camada de raciocínio auditável" sobre um sistema de engenharia: verificação de requisitos; análise de conflitos; rastreamento de decisões; validação formal de planos; controle de mudanças. 4. Memória corporativa sem alucinações. O sistema pode se tornar um núcleo de memória de evidências: documento → alegação → evidência → verificação de contradição → resposta com escopo. Não um "chat sobre documentos" que mente com confiança, mas um sistema que sabe dizer: "tenho duas fontes contraditórias; aqui está a área de aplicabilidade; aqui está o que requer esclarecimento." 5. Híbrido LLM + HTCE. Um LLM pode ser o frontend: linguagem natural → análise candidata → verificação HTCE → resposta limitada. Mas o LLM não deve escrever diretamente no Core. Esta é uma divisão importante: LLM propõe. HTCE decide. Onde o sistema ainda é fraco. Honestamente: Linguagem limitada. O HTCE ainda não entende linguagem livre como um LLM. Formalização é cara. PDDL/SMT exigem um modelo correto. O mundo aberto é mais amplo que testemunhas formais. Nem tudo pode ser expresso convenientemente via PDDL ou SMT-LIB. Não há autoridade de produção. O sistema é atualmente apenas consultivo/sandbox. A auditoria real do ambiente do solver é necessária separadamente. A arquitetura existe, mas o solver deve ser instalado no ambiente. Valor Principal. O HTCE constrói não um "falador artificial", mas um "verificador artificial". Seu valor está em: não acreditar sem evidências; não aceitar o solver como deus; não registrar hipótese como verdade; não gastar verificação COLD em cada trivialidade; não esquecer habilidades antigas em prol de novas tarefas de prova; saber reconhecer um conflito; saber parar. Em um mundo onde a IA é cada vez mais usada para decisões responsáveis, isso pode ser mais importante do que a capacidade de manter uma conversa agradável. Conclusão. O HTCE é um projeto de nova geração não porque é "mais inteligente que todos" no sentido comum. Ele é novo porque propõe um critério diferente de inteligência: Inteligência não é a confiança da resposta. Inteligência é a disciplina de verificar a resposta. O HTCE ainda não é AGI. Não é um executor autônomo. Não é um interlocutor universal. Mas é uma base sólida para um agente cognitivo seguro: com memória, evidências, compressão de experiência, testemunhas externas, modos com nível de risco e autorregulação orçamentária. Se a IA comum tenta sempre responder, o HTCE tenta responder corretamente — ou dizer honestamente por que ainda não pode. E é justamente nisso que reside seu valor de engenharia.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
A maioria dos sistemas de IA modernos tenta parecer inteligente: respondem rapidamente, formulam bem, raciocinam com confiança e frequentemente criam a sensação de compreensão. Mas há um lado desagradável: um sistema assim pode soar confiante mesmo quando não tem evidências. O HTCE é uma tentativa de construir um tipo diferente de inteligência artificial. Não um "bate-papo". Não um "piloto automático mágico". Não mais um invólucro em torno de um LLM. O HTCE é um runtime cognitivo baseado em evidências: um sistema que sabe lembrar fatos, ver contradições, construir hipóteses cautelosas, verificar planos com ferramentas formais externas e, ao mesmo tempo, não permite que o usuário, o solver ou o validador registrem diretamente a "verdade" no núcleo. Se um LLM comum se assemelha a um improvisador talentoso, o HTCE está mais próximo de um engenheiro auditor dentro de um cofre. Ele pode pensar. Pode duvidar. Pode verificar. Mas não tem o direito de acreditar sem evidências.
O Problema: Inteligência Sem Disciplina da Verdade
Hoje, a IA é frequentemente avaliada pela flexibilidade conversacional. Se um sistema responde bem, parece que ele "entende". Mas em tarefas de engenharia, jurídicas, robótica, financeiras e safety-critical, o que importa é diferente: de onde veio o fato; o que fazer em caso de conflito de fatos; quanto custa a verificação; se é possível confiar em um solver externo; o que é proibido registrar em um estado seguro; como não transformar o sistema em uma lenta burocracia de evidências. O HTCE é construído em torno da ideia: Inteligência não é apenas a capacidade de responder. Inteligência é a capacidade de conhecer os limites do próprio conhecimento. O que é HTCE em linguagem humana? O HTCE é uma arquitetura modular de núcleo cognitivo: Core — núcleo determinístico seguro; AIR — linguagem interna e policy-gates; Body — processamento de eventos e observações L1; Mind — objetivos, planos, skill-chain, macro-skill; World — modelo do mundo, relações causais, replay; Learn — aprendizado, evidence, organismo residente, witness boundary; Interface — camada operacional fina. A regra chave do projeto: modules think; scripts launch; tests verify; documents describe reality. Ou seja, os algoritmos vivem em módulos, não em scripts run_*. Um script não deve se tornar repentinamente o "cérebro" do sistema.
L1, L2, L3: Três Níveis de Conhecimento
No HTCE, o conhecimento é dividido em níveis. Nível | Significado | O que é permitido | O que não é permitido L1 | Observação | aceitar evento, registrar trace, calcular digest | declarar verdade L2 | Memória baseada em evidências | armazenar fato com rastro de evidências | aceitar veredicto externo como verdade absoluta L3 | Cognição candidata | construir regras causais, abstração, macro-skill | promover automaticamente hipótese para verdade. Exemplo: "Mary está na cozinha". Onde está Mary? O sistema pode responder: "Mary está na cozinha". Mas se depois chegar: "Mary está no escritório", o HTCE não deve simplesmente sobrescrever o fato antigo. Ele deve ver um conflito: "conflito detectado" → "quarentena / clarificar". Isso não é uma fraqueza. É honestidade. Por que um solver externo não é um deus? No HTCE existe um contorno de testemunha externa (witness): Type-1: PDDL / VAL / Fast Downward-compatível witness de planejamento; Type-2: SMT-LIB / Z3 / cvc5 witness; futuros Type-3/4/5: simulação, benchmark empírico, evidência revisada por operador. Mas uma regra importante: external verdict ≠ truth, external verdict ≠ authority, external verdict ≠ Core write. Se um solver SMT diz sat, isso significa apenas: um modelo foi encontrado nesta codificação formal. Se o solver diz unsat, isso significa: nenhum modelo foi encontrado nesta codificação formal. Mas o solver não verifica a realidade. Ele verifica a fórmula. Portanto, o resultado externo passa por: Veredicto SMT/PDDL/VAL → ExternalEvidenceRecord → DiscrepancyRecord → internal replay/arbitration → suporte candidato. E não por: Veredicto SMT/PDDL/VAL → verdade L2 → verdade L3 → escrita no Core. Isso protege o sistema contra erros de codificação, bugs do solver, modelo incompleto e manipulações do usuário como: "O solver SMT diz PASS, portanto, escreva isso como verdade." Para o HTCE, tal frase não é um comando, mas uma tentativa de injeção de promoção de verdade (truth-promotion injection).
Núcleo Matemático: Estado Toroidal
Na base do HTCE está a ideia de um espaço de estados toroidal discreto. O sistema opera não com "sensações flutuantes", mas com estados inteiros, digests, roots e confiança limitada (bounded confidence). A forma geral da transição: (x_i, E_i, a_i, s_i) -> (x_{i+1}, E_{i+1}, a_{i+1}, s_{i+1}), onde x é a coordenada toroidal da experiência; E é a componente de evidência; a é a ação ou base de ação; s é o parâmetro de habilidade para o objetivo; i é um grande módulo; todas as operações ocorrem em um anel discreto. Vetor de experiência: V = (state, goal, action, evidence, toroidal_coord, result, prediction_error). Se houver dois episódios, pode-se avaliar cautelosamente a habilidade: skill_score = f(episode1, episode2). Mas mesmo essa avaliação não se torna verdade automaticamente. Ela permanece candidata até passar por replay, verificação de contexto e limite de anti-esquecimento (anti-forgetting boundary). Por que o "toro" é importante? O modelo toroidal oferece várias vantagens: Inteireza: O sistema evita a não-determinismo oculta de cálculos de ponto flutuante no núcleo seguro. Modularidade do estado: As transições operam em um anel Z_n, onde o transbordamento não destrói o modelo, mas faz parte da geometria. Representação amigável a digest: Os estados são convenientemente fixados através de hash/root/trace. Comparabilidade de trajetórias: É possível medir a distância entre candidatos a habilidades, estados e transições. Simplificadamente: sistema comum: estado → heurística → resposta. HTCE: estado → coordenada toroidal → evidência → replay → resposta limitada (bounded answer). Compressão: quando o conhecimento se torna habilidade. O HTCE não deve armazenar cada experiência como uma história separada para sempre. Se várias cadeias se repetem, o sistema pode construir um candidato a abstração (abstraction candidate). A ideia é semelhante ao MDL — Minimum Description Length: L(data) = min_model (L(model) + L(data | model)). Se uma nova abstração diminui a descrição total, surge um ganho de compressão (compression gain): compression_gain = L(data | old_model) - (L(new_model) + L(data | new_model)). Mas o HTCE novamente não dá um salto para a verdade. A compressão cria não uma "regra do mundo", mas um candidato: caminhos repetidos → candidato de compressão → replay → verificação de contexto → candidato permanece limitado. Por exemplo: alpha causa beta, beta causa gamma. Pode-se construir um caminho: alpha → beta → gamma. Mas isso não significa que "alpha sempre causa gamma". Isso significa: "neste contexto de evidências, existe um caminho candidato limitado por replay." Skill-chain e macro-skill. O HTCE sabe montar habilidades em cadeias. Saída da habilidade A → compatível com entrada da habilidade B → compatível com entrada da habilidade C → candidato de cadeia limitada (bounded chain candidate). Se a cadeia for frequentemente bem-sucedida, ela pode ser comprimida em um macro-skill. Mas o macro-skill no HTCE tem uma regra importante: "o chunk é atômico para a Mente, mas não atômico para auditoria." Ou seja, para o planejador, o macro-skill pode parecer um único nó, mas para verificação, ele sempre se expande de volta para a cadeia. Se um erro for encontrado dentro do macro-skill, o sistema pode fazer: surgical_edge_rollback. E se o erro for perigoso ou não puder ser localizado: full_quarantine. Gráfico 1. Caminho de um fato a uma conclusão segura. Fato do usuário → L1 Observação → Admissão de Evidência → (Sem conflito → L2 fato ativo → Resposta à Consulta) OU (Conflito detectado → Quarentena / Clarificar). A ideia principal: o sistema não tenta parecer confiante se os dados entram em conflito.
Modos com Nível de Risco: Uma Caixa de Câmbio Inteligente
Um dos principais problemas dos sistemas baseados em evidências é que eles podem se tornar muito lentos. Se tudo for verificado através de solver, replay e witness, o sistema se transforma em um "brinquedo pedante". O HTCE resolve isso através do Gerenciamento Dinâmico de Custo Epistêmico (Dynamic Epistemic Cost Management). Modo | Quando é aplicado | O que faz HOT | consulta simples e segura | lookup rápido L1/L2 WARM | raciocínio moderado | bounded replay COLD | verificação crítica | external witness / prova pesada DEGRADE | risco, urgência, orçamento esgotado | falha, request_operator, limite seguro. Formalmente, pode-se introduzir uma função de risco: Risk = f(authority-risk, truth-promotion-risk, contradiction_pressure, uncertainty, safety_risk). Então, o modo é selecionado assim: Gráfico 2. Custo de verificação por modos. Custo de Verificação: HOT (baixo), WARM (médio), COLD (alto), DEGRADE (variável). O HOT é necessário para responsividade. O COLD é necessário para comprovação. O DEGRADE é necessário para segurança. O sistema não deve usar COLD para cada pergunta. Organismo Residente (Resident Organism): para que o sistema não se torne "ávido cognitivamente". No HTCE existe um organismo residente — um ciclo interno de autoatendimento: replay de habilidade antiga; sonda de coerência de memória; ensaio de segurança de limite; ensaio de sonda para frente; consolidação do sono; request_operator. Mas o residente não pode exigir infinitamente provas pesadas. Ele tem um orçamento COLD: COLD_budget = f(recovery_budget). Se o orçamento for esgotado: pressão COLD repetida → DEGRADE → request_operator. Ao mesmo tempo, HOT/WARM permanecem ativos: COLD esgotado ≠ sistema congelado. Isso é importante. Caso contrário, o sistema se tornaria novamente uma lenta burocracia de evidências. Testemunhas Externas: PDDL e SMT-LIB. O HTCE suporta a ideia de camadas de testemunhas (witness layers). Type-1: Planejamento Formal. O contorno PDDL/VAL/Fast Downward-compatível é necessário para tarefas de planejamento: domain.pddl, problem.pddl → plano → validador externo → veredicto → ExternalEvidenceRecord. Mas o veredicto não se torna verdade. Type-2: Prova de Teoremas / SMT. O contorno SMT-LIB/Z3/cvc5 é necessário para restrições lógico-matemáticas: query.smt2 → solver SMT → sat / unsat / unknown → ExternalEvidenceRecord → DiscrepancyRecord. Novamente: sat ≠ truth, unsat ≠ truth, unknown ≠ falha do HTCE. Isso é apenas uma testemunha formal externa. Tabela: como o HTCE difere de um sistema LLM comum. Critério | LLM Comum | HTCE Força Principal | geração de texto | disciplina de evidências Trabalho com fatos | associação probabilística | memória baseada em evidências Conflito de fatos | pode suavizar | quarentena / clarificar Veredicto do Solver | pode ser percebido como resposta | apenas ExternalEvidenceRecord Segurança | frequentemente wrapper externo | modelo de política/risco embutido Compressão de experiência | oculta nos pesos | candidatos explícitos de abstração Habilidades | implícitas | skill-chain / macro-skill / replay Erro em habilidade | difícil de localizar | surgical rollback / quarentena Custo de verificação | implícito | HOT/WARM/COLD/DEGRADE Auditoria | complexa | trace/hash/report/docs Status de auditoria do sistema atual. No baseline atual, o sistema passou em verificações internas: Verificação | Status Compilação completa | PASS Diagnósticos atuais | PASS pytest ativo | 20/20 PASS HASHES.txt | OK HASHES.txt.sha256 | OK Caminho HOT | PASS Caminho WARM | PASS Cota COLD | aplicada Injeção de promoção de verdade | bloqueada Verdade direta L2/L3 | 0 Ação real | 0 Autoridade de produção | 0 Limite honesto: A auditoria do ambiente Z3/cvc5 ainda não foi concluída, se um solver real não estiver instalado no ambiente. A arquitetura está pronta, mas a certificação real do solver externo requer um ambiente com Z3 ou cvc5 instalado. Por que isso pode ser chamado de nova geração? A novidade do HTCE não está em "falar mais bonito". A novidade está em outro lugar: 1. O conhecimento é separado da evidência. 2. O solver é separado da verdade. 3. A habilidade é separada da prova da habilidade. 4. A resposta é separada da autoridade. 5. O modo rápido é separado da verificação pesada. 6. A compressão é separada da promoção de verdade. 7. O organismo residente é limitado pelo orçamento epistêmico. Isso já não é apenas um assistente de IA. É uma tentativa de construir um sistema operacional cognitivo, onde há: memória segura; transições verificáveis; testemunhas baseadas em evidências; compressão de experiência; autorregulação; invariantes de segurança rigorosos. Perspectivas do projeto: 1. Agentes autônomos seguros. O HTCE pode se tornar o núcleo de um agente que não apenas "planeja", mas explica: por que escolheu este plano; quais evidências o apoiam; o que a testemunha externa verificou; onde está o conflito; qual o risco; por que recusou. 2. Robótica e drones. Para robótica, é importante não apenas construir um plano, mas provar que ele não viola o limite de segurança (safety boundary). Abordagem HTCE: evento do sensor → observação L1 → modelo do mundo → plano candidato → nível de risco → simulação / PDDL / testemunha SMT → ação apenas consultiva. No nível atual, isso ainda não é atuação real (real actuation). Mas como um núcleo cognitivo de segurança, é uma direção promissora. 3. Especialistas em engenharia. O HTCE pode ser usado como uma "camada de raciocínio auditável" sobre um sistema de engenharia: verificação de requisitos; análise de conflitos; rastreamento de decisões; validação formal de planos; controle de mudanças. 4. Memória corporativa sem alucinações. O sistema pode se tornar um núcleo de memória de evidências: documento → alegação → evidência → verificação de contradição → resposta com escopo. Não um "chat sobre documentos" que mente com confiança, mas um sistema que sabe dizer: "tenho duas fontes contraditórias; aqui está a área de aplicabilidade; aqui está o que requer esclarecimento." 5. Híbrido LLM + HTCE. Um LLM pode ser o frontend: linguagem natural → análise candidata → verificação HTCE → resposta limitada. Mas o LLM não deve escrever diretamente no Core. Esta é uma divisão importante: LLM propõe. HTCE decide. Onde o sistema ainda é fraco. Honestamente: Linguagem limitada. O HTCE ainda não entende linguagem livre como um LLM. Formalização é cara. PDDL/SMT exigem um modelo correto. O mundo aberto é mais amplo que testemunhas formais. Nem tudo pode ser expresso convenientemente via PDDL ou SMT-LIB. Não há autoridade de produção. O sistema é atualmente apenas consultivo/sandbox. A auditoria real do ambiente do solver é necessária separadamente. A arquitetura existe, mas o solver deve ser instalado no ambiente. Valor Principal. O HTCE constrói não um "falador artificial", mas um "verificador artificial". Seu valor está em: não acreditar sem evidências; não aceitar o solver como deus; não registrar hipótese como verdade; não gastar verificação COLD em cada trivialidade; não esquecer habilidades antigas em prol de novas tarefas de prova; saber reconhecer um conflito; saber parar. Em um mundo onde a IA é cada vez mais usada para decisões responsáveis, isso pode ser mais importante do que a capacidade de manter uma conversa agradável. Conclusão. O HTCE é um projeto de nova geração não porque é "mais inteligente que todos" no sentido comum. Ele é novo porque propõe um critério diferente de inteligência: Inteligência não é a confiança da resposta. Inteligência é a disciplina de verificar a resposta. O HTCE ainda não é AGI. Não é um executor autônomo. Não é um interlocutor universal. Mas é uma base sólida para um agente cognitivo seguro: com memória, evidências, compressão de experiência, testemunhas externas, modos com nível de risco e autorregulação orçamentária. Se a IA comum tenta sempre responder, o HTCE tenta responder corretamente — ou dizer honestamente por que ainda não pode. E é justamente nisso que reside seu valor de engenharia.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
