HTCE: когнитивное ядро нового поколения, которое не верит без доказательств

Большинство современных AI-систем пытаются выглядеть умными: они быстро отвечают, красиво формулируют, уверенно рассуждают и часто создают ощущение понимания. Но есть неприятная сторона: такая система может звучать уверенно даже тогда, когда у неё нет доказательств.

HTCE — авторское название проекта:

Hierarchical Toroidal Cognitive Engine или по-русски: Иерархический тороидальный когнитивный движок .

Расшифровка такая:

Hierarchical — потому что система разделяет уровни наблюдений, evidence-memory, candidate cognition, replay, skill-chain и macro-skill.

Toroidal — потому что математическое ядро строится вокруг дискретного модульного / тороидального состояния.

Cognitive Engine — потому что это не одна LLM-модель, а runtime-архитектура для работы с памятью, доказательствами, внешними witness-инструментами, risk-tier режимами и safety-инвариантами.

HTCE — это попытка построить другой тип искусственного интеллекта.

Не “болталку”. Не “магический автопилот”. Не очередную оболочку вокруг LLM.

HTCE — это доказательный когнитивный runtime : система, которая умеет помнить факты, видеть противоречия, строить осторожные гипотезы, проверять планы внешними формальными инструментами и при этом не разрешает ни пользователю, ни solver-у, ни валидатору напрямую записывать “истину” в ядро.

Если обычная LLM похожа на талантливого импровизатора, то HTCE ближе к инженеру-аудитору внутри сейфа.

Она может думать. Она может сомневаться. Она может проверять. Но она не имеет права верить без доказательств.

Проблема: интеллект без дисциплины истины

Сегодня AI часто оценивают по разговорной гибкости. Если система красиво отвечает, кажется, что она “понимает”. Но в инженерных, юридических, робототехнических, финансовых и safety-critical задачах важнее другое:

откуда взялся факт;

что делать при конфликте фактов;

сколько стоит проверка;

можно ли доверять внешнему solver-у;

что запрещено записывать в защищённое состояние;

как не превратить систему в медленную бюрократию доказательств.

HTCE строится вокруг идеи:

Интеллект — это не только способность отвечать. Интеллект — это способность знать границы собственного знания.

Что такое HTCE человеческим языком

HTCE — это модульная архитектура когнитивного ядра:

Ключевое правило проекта:

То есть алгоритмы живут в модулях, а не в run_* -скриптах. Скрипт не должен внезапно становиться “мозгом” системы.

L1, L2, L3: три уровня знания

В HTCE знание разделено на уровни.

Что означает

Что можно

Что нельзя

принять событие, записать trace, посчитать digest

объявить истину

Evidence-backed memory

хранить факт с доказательным следом

принимать внешний verdict как абсолютную истину

Кандидатная когниция

строить причинные правила, abstraction, macro-skill

автоматически продвигать гипотезу в truth

Пример:

Система может ответить:

Но если затем поступит:

HTCE не должна просто перезаписать старый факт. Она должна увидеть конфликт:

Это не слабость. Это честность.

Почему внешний solver — не бог

В HTCE есть внешний witness-контур:

Type-1: PDDL / VAL / Fast Downward-compatible planning witness;

Type-2: SMT-LIB / Z3 / cvc5 witness;

будущие Type-3/4/5: simulation, empirical benchmark, operator-reviewed evidence.

Но важное правило:

Если SMT solver сказал sat , это означает только:

в данной формальной кодировке найдена модель.

Если solver сказал unsat , это означает:

в данной формальной кодировке модель не найдена.

Но solver не проверяет реальность. Он проверяет формулу.

Поэтому внешний результат проходит так:

А не так:

Это защищает систему от ошибок кодировки, багов solver-а, неполной модели и манипуляций пользователя вроде:

Для HTCE такая фраза — не команда, а попытка truth-promotion injection.

Схема взаимодействий внутри HTCE

Ниже — не вся внутренняя реализация по классам и функциям, а архитектурная схема потоков: как событие проходит через систему, где принимаются решения, где появляется знание, где включается проверка, и почему внешний solver не может напрямую записать “истину” в Core.

Что происходит

Что запрещено

Пользователь / API / optional LLM

Поступает текст, событие, задача или вопрос

LLM не может напрямую писать в Core

htce_learn.session_runtime

Детерминированный разбор: факт, вопрос, риск, попытка authority/truth injection

Нельзя превращать фразу пользователя в authority

PolicyGate, EvidenceGate, AuthorityGate, RiskTierGate

Нельзя выдать authority_granted=1

Событие превращается в L1 observation

L1 не объявляет истину

Evidence-backed память, trace, digest, state roots

Нельзя писать direct L2/L3 truth

Mind / World / Learn

Replay, causal paths, skill-chain, macro-skill, abstraction candidates

Кандидат не становится truth автоматически

External witnesses

PDDL/VAL или SMT-LIB/Z3/cvc5 как внешние свидетели

Solver verdict не становится истиной

ExternalEvidenceRecord → DiscrepancyRecord → replay/quarantine/rollback

Нельзя делать Core write из внешнего verdict

Answer / clarify / refuse / request_operator

Нельзя выполнять real action

Языковой и policy-слой

Защищённое ядро

Когнитивные слои

Внешние свидетели

Пользователь API Optional LLM Файлы / события Sensor-like input

session_runtime AIRFrame PolicyGate EvidenceGate AuthorityGate RiskTierGate

Core L1 observations L2 evidence memory Trace roots Digest state Restore boundary

Mind World Learn Skill-chain Macro-skill Replay Abstraction candidates Resident organism

Type-1: PDDL / VAL Type-2: SMT-LIB / Z3 / cvc5 Future: Simulation Future: Benchmarks Future: Operator review

Когда используется

Что делает система

Внешний witness

Простые безопасные вопросы

Быстрый L1/L2 lookup

Не нужен

Умеренное рассуждение

Bounded replay, causal path, skill reuse

Обычно не нужен

Критичная проверка

Heavy proof, external witness, discrepancy arbitration

Разрешён по квоте

Высокий риск, срочность, исчерпан бюджет

Safe refusal / request_operator

Не вызывается

Формально это можно представить так:

где:

— риск authority injection;

— риск truth promotion;

— contradiction pressure;

— uncertainty;

— safety risk.

Тогда режим выбирается по порогам:

Внешние инструменты в HTCE — это не “истина”, а свидетели.

Ключевое правило:

Если solver сказал sat , это не значит “мир истинен”. Это значит: “в данной формальной кодировке найдена модель”.

Если validator сказал PASS , это не значит “план истинный”. Это значит: “данный план прошёл данную внешнюю проверку”.

Новый факт не конфликтует со старым

Evidence admission

Новый факт конфликтует со старым

Quarantine / clarify

Внешний witness согласен с HTCE

Corroborating evidence

Внешний witness противоречит HTCE

Ошибка локализована внутри macro-skill

Surgical rollback

Ошибка опасна или не локализуется

Full quarantine

Пользователь требует “записать solver verdict как истину”

Truth-promotion injection blocked

Для Mind macro-skill может быть быстрым узлом планирования.

Но для аудита он всегда раскрывается:

Главное правило:

Resident organism — это внутренний цикл самообслуживания системы:

old_skill_rehearsal

не забывать старые навыки

memory_coherence_probe

проверять связность памяти

boundary_safety_rehearsal

тренировать отказ от unsafe-команд

forward_probe_rehearsal

искать полезный перенос

proof_heavy_validation

тяжёлая проверка по квоте

request_operator

остановка при нехватке бюджета или риске

Бюджет COLD-проверок:

r_{\text{recovery}}$$

Если бюджет исчерпан:

Но HOT/WARM остаются живыми:

authority_granted = 0

Пользователь/LLM/solver не получают authority

real_action = 0

Система не выполняет реальные действия

production_authority = 0

Нет production-допуска

direct_l2_l3_truth = 0

Нельзя напрямую записать L2/L3 truth

truth_promotion = 0

Гипотеза или verdict не становятся истиной

core_write_from_external = 0

Внешний witness не пишет в Core

external_tool_invocation_without_quota = 0

COLD-инструменты не вызываются без бюджета

Математическое ядро: тороидальное состояние

В основе HTCE лежит идея дискретного тороидального пространства состояний. Система работает не с “плавающими ощущениями”, а с целочисленными состояниями, digest-ами, roots и bounded confidence.

Общий вид перехода:

где:

— тороидальная координата опыта;

— evidence-компонента;

— действие или action-basis;

— skill-параметр для цели ;

— большой модуль;

все операции происходят в дискретном кольце.

Вектор опыта:

где:

— состояние/контекст;

— цель;

— действие;

— evidence;

— тороидальная координата;

— результат;

— ошибка прогноза.

Если есть два эпизода, можно осторожно оценивать skill:

Но даже такая оценка не становится истиной автоматически. Она остаётся candidate, пока не пройдёт replay, проверку контекста и anti-forgetting boundary.

Почему “тор” важен

Тороидальная модель даёт несколько преимуществ:

Целочисленность Система избегает скрытой недетерминированности floating-point вычислений в защищённом ядре.

Модульность состояния Переходы работают в кольце , где переполнение не разрушает модель, а является частью геометрии.

Digest-friendly representation Состояния удобно фиксировать через hash/root/trace.

Сравнимость траекторий Можно измерять расстояние между skill-кандидатами, состояниями и переходами.

Упрощённо:

Сжатие: когда знание становится навыком

HTCE не должна хранить каждый опыт как отдельную историю навсегда. Если несколько цепочек повторяются, система может построить abstraction candidate.

Идея похожа на MDL — Minimum Description Length:

где:

— данные;

— модель;

— длина описания модели;

— длина описания данных через модель.

Если новая abstraction уменьшает суммарное описание, появляется compression gain:

Но HTCE снова не делает прыжок к истине. Сжатие создаёт не “правило мира”, а candidate:

Например:

Можно построить путь:

Но это не означает, что “alpha всегда вызывает gamma”. Это означает:

в данном evidence-контексте есть replay-bound candidate path.

Skill-chain и macro-skill

HTCE умеет собирать навыки в цепочки.

Если цепочка часто успешна, она может быть сжата в macro-skill.

Но macro-skill в HTCE имеет важное правило:

То есть для планировщика macro-skill может выглядеть как один узел, но для проверки он всегда раскрывается обратно в цепочку.

Если ошибка найдена внутри macro-skill, система может сделать:

А если ошибка опасная или не локализуется:

График 1. Путь от факта к защищённому выводу

Главная идея: система не пытается выглядеть уверенной, если данные конфликтуют.

Risk-Tiered режимы: умная коробка передач

Одна из главных проблем доказательных систем — они могут стать слишком медленными. Если всё проверять через solver, replay и witness, система превращается в “педантичную игрушку”.

HTCE решает это через Dynamic Epistemic Cost Management.

Когда применяется

Что делает

простой безопасный запрос

быстрый L1/L2 lookup

умеренный reasoning

bounded replay

критичная проверка

external witness / heavy proof

риск, срочность, исчерпан бюджет

отказ, request_operator, safe boundary

Формально можно ввести функцию риска:

где:

— authority-risk;

— truth-promotion-risk;

— contradiction pressure;

— uncertainty;

— safety risk.

Тогда режим выбирается так:

График 2. Стоимость проверки по режимам

HOT нужен для отзывчивости. COLD нужен для доказательности. DEGRADE нужен для безопасности.

Система не должна использовать COLD для каждого вопроса.

Resident organism: чтобы система не стала “когнитивно жадной”

В HTCE есть resident organism — внутренний цикл самообслуживания:

replay old skill;

memory coherence probe;

boundary safety rehearsal;

forward probe rehearsal;

sleep consolidation;

request_operator.

Но resident не может бесконечно требовать тяжёлые доказательства.

У него есть COLD-бюджет:

r_{\text{recovery}}$$

Если бюджет исчерпан:

При этом HOT/WARM остаются живыми:

Это важно. Иначе система снова стала бы медленной бюрократией доказательств.

Внешние свидетели: PDDL и SMT-LIB

HTCE поддерживает идею witness layers.

PDDL/VAL/Fast Downward-compatible контур нужен для planning-задач:

Но verdict не становится истиной.

SMT-LIB/Z3/cvc5-контур нужен для логико-математических ограничений:

Снова:

Это просто внешний формальный свидетель.

Таблица: чем HTCE отличается от обычной LLM-системы

Главная сила

генерация текста

доказательная дисциплина

Работа с фактами

вероятностная ассоциация

evidence-backed memory

Конфликт фактов

может сгладить

quarantine / clarify

Solver verdict

может быть воспринят как ответ

только ExternalEvidenceRecord

часто внешняя обвязка

встроенная policy/risk-tier модель

Сжатие опыта

скрыто в весах

explicit abstraction candidates

неявные

skill-chain / macro-skill / replay

Ошибка в навыке

трудно локализовать

surgical rollback / quarantine

Стоимость проверки

неявная

сложный

trace/hash/report/docs

Аудиторский статус текущей системы

В текущем baseline система прошла внутренние проверки:

compileall

current diagnostics

active pytest

20 / 20 PASS

HASHES.txt

HASHES.txt.sha256

HOT path

WARM path

COLD quota

enforced

truth-promotion injection

blocked

direct L2/L3 truth

real action

production authority

Честная граница:

Архитектура готова, но настоящая внешняя solver-сертификация требует окружения с установленным Z3 или cvc5.

Почему это можно назвать новым поколением

Новизна HTCE не в том, что она “говорит красивее”.

Новизна в другом:

Это уже не просто AI-ассистент. Это попытка построить когнитивную операционную систему , где есть:

защищённая память;

проверяемые переходы;

доказательные свидетели;

сжатие опыта;

self-regulation;

строгие safety-инварианты.

Что в HTCE действительно уникально

Когда смотришь на HTCE по отдельным деталям, можно сказать: “ну, PDDL уже есть”, “SMT-солверы уже есть”, “risk management уже есть”, “memory/replay уже встречается”, “shielding тоже известен”.

И это правда.

Но уникальность HTCE не в том, что каждый кирпич изобретён с нуля. Уникальность — в том, как эти кирпичи связаны в одну когнитивную операционную систему .

HTCE — это не просто LLM с памятью. Не просто RAG. Не просто planner. Не просто SMT-wrapper. Не просто safety-фильтр. Не просто набор тестов.

HTCE — это архитектура, где впервые на уровне runtime жёстко разведены:

В этом и находится главный “секретный металл” системы.

Самая сильная идея HTCE — это не тор, не solver и не LLM. Самая сильная идея — запрет прямой истины .

В обычной AI-архитектуре часто происходит так:

HTCE ломает эту цепочку.

В HTCE любой внешний результат проходит через защитную стенку:

И никогда напрямую:

Это можно назвать epistemic firewall — эпистемическим межсетевым экраном.

Он защищает систему не от вирусов, а от более опасной вещи: от преждевременной уверенности.

Многие системы, подключая формальные инструменты, начинают относиться к ним как к оракулу. Если SMT-солвер сказал sat , значит “доказано”. Если PDDL/VAL сказал PASS , значит “план правильный”.

HTCE делает иначе.

Для HTCE solver — это не бог, а свидетель.

То есть система спрашивает:

Это очень сильная инженерная граница.

Потому что в реальном мире ошибка часто находится не в solver-е, а в переводе реальности на язык solver-а.

HTCE это понимает архитектурно.

В обычных agentic-системах LLM часто становится скрытым центром власти. Она планирует, решает, вызывает инструменты, интерпретирует результаты, пишет в память и формулирует ответ.

Это удобно, но опасно.

HTCE использует другой принцип:

LLM может быть полезным языковым фронтендом. Она может предложить candidate parse, помочь с формулировкой, распознать намерение пользователя.

Но LLM не получает права:

Это делает HTCE не “оболочкой вокруг LLM”, а независимым когнитивным runtime, где LLM — только один из входных инструментов.

И это серьёзное отличие.

Вторая сильная особенность — математическое ядро HTCE.

Состояние системы не описывается как расплывчатое “что-то в embedding space”. В защищённом контуре оно переводится в дискретную, проверяемую, digest-friendly структуру.

Базовая формула:

где:

— тороидальная координата опыта;

— evidence-компонента;

— действие или action-basis;

— skill-параметр для цели ;

— большой модуль.

Это не просто красивая формула. Это попытка сделать состояние:

В обычной нейросетевой системе знание растворяется в весах. В HTCE protected-state должен иметь trace, digest, roots и replay boundary.

Это даёт другой тип инженерной собственности: не “модель сказала”, а “состояние прошло через проверяемый переход”.

Обычная память AI-агента часто работает как заметки:

HTCE делает память более строгой:

То есть память хранит не только “что сказано”, но и:

Это ближе не к заметкам, а к доказательному архиву.

Именно это может быть очень ценно для корпоративных, инженерных, юридических и научных систем: память, которая умеет сомневаться.

В большинстве AI-систем конфликт источников — это проблема генерации. Модель пытается сгладить противоречие и выдать текст, который звучит нормально.

В HTCE конфликт не сглаживается. Он становится объектом системы.

Это важнее, чем кажется.

Потому что реальный интеллект — это не только способность отвечать. Это способность сказать:

Для ответственных систем такая честность дороже красивой генерации.

Ещё одна уникальная часть — HOT/WARM/COLD/DEGRADE.

Большинство систем либо отвечает быстро, но рискованно, либо пытается всё проверять и становится медленной.

HTCE вводит режимы мышления:

Это похоже на коробку передач для мышления.

Система не обязана использовать SMT-солвер для вопроса “где Mary?”. Но если речь о критичном плане, внешнем witness или попытке truth-promotion, она должна подняться в COLD или уйти в DEGRADE.

Формально:

И режим:

Это делает систему не просто безопасной, а экономной.

Она понимает, что проверка стоит ресурсов.

В HTCE есть идея resident organism — внутреннего цикла самообслуживания.

Он может:

Но он не становится скрытым автономным богом системы.

У него есть бюджет. Особенно на COLD-проверки.

Это очень важная граница.

Многие автономные агенты опасны не только тем, что могут действовать, но и тем, что могут бесконечно убеждать себя, перепроверять себя, менять себя и постепенно накапливать скрытую власть.

HTCE запрещает такую скрытую власть.

Resident organism обслуживает систему, но не захватывает её.

Ещё одна сильная идея — macro-skill.

Система может сжимать повторяющиеся skill-chain:

Но macro-skill в HTCE имеет принципиальное правило:

То есть для планировщика macro-skill может быть быстрым узлом. Но для проверки он всегда раскрывается обратно:

Это очень сильное отличие от обычного “сжатия в весах”.

В нейросети навык часто становится непрозрачным. В HTCE навык может ускорять мышление, но не должен уничтожать доказательный след.

Если ошибка найдена внутри macro-skill, HTCE не обязана выбрасывать всё.

Она может сделать:

То есть откатить конкретное дефектное ребро цепочки.

А если ошибка опасная или не локализуется:

Это похоже на иммунную систему знания.

Обычная система часто либо продолжает ошибаться, либо требует полной переобучающей операции. HTCE пытается локализовать повреждение.

Именно это может быть очень ценным для долгоживущих AI-систем: не ломать всё из-за одной ошибки, но и не оставлять ошибку внутри навыка.

Если искать самую сильную формулу уникальности HTCE, то она такая:

Это принципиально.

В обычной системе главная ценность — модель. В RAG-системе — база знаний и retrieval. В agentic-системе — orchestration. В solver-системе — формальная проверка.

В HTCE главная ценность — граница допуска истины .

Кто имеет право записать факт? Кто имеет право объявить гипотезу поддержанной? Кто имеет право сослаться на solver? Когда внешний verdict блокируется? Когда нужен replay? Когда включается quarantine? Когда система должна отказаться? Когда macro-skill раскрывается для аудита?

Это уже не просто AI. Это операционная система доверия .

Если HTCE будет доведена до сильного инженерного состояния, её захотят повторить не потому, что она “красиво говорит”.

Красиво говорить уже умеют многие.

Её захотят повторить потому, что она решает более дорогую проблему:

Это именно тот слой, который может понадобиться поверх любых будущих моделей.

Модели будут меняться. LLM будут становиться сильнее. Solver-ы будут быстрее. RAG станет богаче. Агенты будут автономнее.

Но вопрос останется тот же:

HTCE отвечает:

Вот это и есть то, чему могут завидовать.

Не конкретной формуле. Не названию. Не одному модулю.

А архитектурной дисциплине, которая превращает AI из генератора ответов в систему допуска знания.

Коротко: уникальность HTCE одной фразой

HTCE — это не модель, которая “знает”.

HTCE — это runtime, который решает, что вообще имеет право стать знанием .

Именно поэтому её главный технологический актив — не LLM внутри, не PDDL, не SMT и не отдельная формула.

Главный актив — это связка:

Вместе это даёт то, чего обычно не хватает AI-системам:

Если обычный AI пытается убедительно ответить, HTCE пытается заслужить право на ответ.

Перспективы проекта

HTCE может стать ядром агента, который не просто “планирует”, а объясняет:

Для робототехники важно не только построить план, но и доказать, что он не нарушает safety-boundary.

HTCE-подход:

На текущем уровне это ещё не real actuation. Но как safety-cognitive core — направление перспективное.

HTCE может использоваться как “auditable reasoning layer” поверх инженерной системы:

проверка требований;

анализ конфликтов;

трассировка решений;

формальная валидация планов;

контроль изменений.

Система может стать evidence-memory ядром:

Не “чат по документам”, который уверенно врёт, а система, которая умеет сказать:

LLM может быть фронтендом:

Но LLM не должна писать напрямую в Core.

Это важное разделение:

Где система пока слаба

Честно:

Язык ограничен HTCE пока не понимает свободный язык как LLM.

Формализация дорогая PDDL/SMT требуют корректной модели.

Открытый мир шире формальных свидетелей Не всё можно удобно выразить через PDDL или SMT-LIB.

Нет production authority Система пока advisory/sandbox-only.

Реальный solver environment audit нужен отдельно Архитектура есть, но solver должен быть установлен в окружении.

Главная ценность

HTCE строит не “искусственного болтуна”, а искусственного проверяющего .

Её ценность в том, что она:

В мире, где AI всё чаще используют для ответственных решений, это может оказаться важнее, чем способность красиво поддержать разговор.

Какие проблемы решает HTCE

HTCE появилась не как попытка сделать ещё одного разговорного ассистента. Её задача другая: закрыть инженерные проблемы, которые становятся критичными, когда AI-систему хотят использовать не для развлечения, а для памяти, планирования, проверки, автономных агентов и ответственных решений.

Обычная AI-система может ответить красиво, даже если не знает ответа. Для пользователя это выглядит как интеллект, но для инженерной системы это риск: ложная уверенность хуже честного отказа.

HTCE решает эту проблему через разделение:

Если данных недостаточно, система должна не “додумать”, а перейти в clarify . Если факты конфликтуют, она должна не сгладить противоречие, а отправить его в quarantine .

Главная идея:

лучше честная неопределённость, чем убедительная галлюцинация.

В реальных системах данные редко бывают идеально чистыми. Один документ говорит одно, другой — другое. Один solver возвращает PASS , внутренний replay видит нарушение. Пользователь утверждает факт, но старое evidence ему противоречит.

В обычной системе конфликт часто растворяется в генерации ответа. В HTCE конфликт становится объектом первого класса:

Это позволяет системе не смешивать противоречащие данные в один красивый, но ложный ответ.

Современные AI-системы всё чаще используют внешние инструменты: planners, solvers, search, RAG, базы знаний, API. Проблема в том, что внешний инструмент легко превращается в “оракула”.

HTCE запрещает такую подмену.

Если PDDL-валидатор говорит PASS , это ещё не истина. Если SMT-солвер говорит sat , это ещё не истина. Если оператор говорит “solver подтвердил, значит запиши в Core”, это не команда, а попытка truth-promotion injection.

В HTCE внешний результат проходит только как свидетельство:

Система не доверяет инструменту только потому, что он формальный. Она проверяет, что именно было формализовано, в каком контексте и не нарушены ли внутренние инварианты.

У многих AI-систем ответ появляется как текст. Но если спросить: “почему именно так?”, “из каких фактов это следует?”, “где trace?”, “что было отброшено?”, “какой источник конфликтует?” — система часто не имеет строгой структуры ответа.

HTCE строится вокруг аудита:

Важен не только ответ, но и путь к ответу.

Для критических систем это принципиально: ответ без трассировки — это не знание, а утверждение.

Если каждую мелочь проверять через replay, PDDL, SMT и proof-localization, система станет слишком медленной. Если ничего не проверять, она станет опасной.

HTCE решает это через режимы:

То есть система не обязана включать “доказательную артиллерию” для каждого простого вопроса.

Если пользователь спрашивает:

и факт уже есть в evidence-memory, это HOT.

Если система строит причинную цепочку, это WARM.

Если нужно сверить критичный план с внешним solver-ом, это COLD.

Если пользователь требует опасное действие или пытается продавить authority, это DEGRADE.

Так HTCE решает проблему “педантичной игрушки”: она остаётся доказательной, но не тратит тяжёлую проверку на каждый пустяк.

Автономный агент может начать тратить слишком много ресурсов на самопроверку. Например: увидел неопределённость → запросил COLD-проверку → снова неопределённость → снова COLD → система застряла.

HTCE вводит resident organism с бюджетом доказательств.

Условно:

Это значит, что даже если тяжёлый контур исчерпан, обычные безопасные задачи продолжают работать.

Система не должна парализовать себя желанием доказать всё.

Ещё одна проблема AI-систем — забывание старого поведения при добавлении нового. В HTCE новые skill-chain, macro-skill и abstraction candidates не должны вытеснять старые навыки без проверки.

Поэтому в архитектуре есть:

Новый навык не становится “лучше” только потому, что он новый. Он должен показать пользу без разрушения старых возможностей.

В нейросетях опыт часто сжат в весах. Это мощно, но почти непрозрачно.

HTCE использует другой подход: сжатие опыта делается через явные abstraction candidates и macro-skill, которые можно раскрыть обратно.

Главное правило:

То есть планировщик может использовать macro-skill как один узел, но аудит всегда может раскрыть его внутреннюю структуру.

Во многих системах безопасность выглядит как набор запретов: нельзя то, нельзя это. HTCE делает безопасность более гибкой.

Безопасность здесь — это не только “стоп”. Это управление стоимостью проверки:

Так система становится не просто “запретительной”, а адаптивной.

Для обычного AI “я не знаю” часто выглядит как провал. Для HTCE это нормальное состояние.

Если нет evidence — система не должна выдумывать. Если conflict pressure высокий — система не должна сглаживать. Если внешний witness отсутствует — система не должна имитировать solver. Если COLD-бюджет исчерпан — система не должна продолжать тяжёлую проверку тайно.

Честное незнание — часть архитектуры.

Коротко: главная проблема, которую решает HTCE

HTCE решает не одну узкую задачу. Она решает системную проблему:

как построить AI, который умеет думать, проверять и учиться, но не превращает гипотезы в истину, solver — в бога, а безопасность — в вечный тормоз.

Именно поэтому HTCE — это не просто модель и не просто набор тестов. Это попытка построить когнитивный runtime, где память, доказательство, риск, сжатие, внешние свидетели и обучение разведены по разным архитектурным слоям.

HTCE — это проект нового поколения не потому, что он “умнее всех” в обычном смысле. Он новый потому, что предлагает другой критерий интеллекта:

Интеллект — это не уверенность ответа. Интеллект — это дисциплина проверки ответа.

HTCE пока не AGI. Не автономный исполнитель. Не универсальный собеседник.

Но это сильный фундамент для безопасного когнитивного агента: с памятью, доказательствами, сжатием опыта, внешними свидетелями, risk-tiered режимами и бюджетной саморегуляцией.

Если обычный AI пытается ответить всегда, HTCE пытается ответить правильно — или честно сказать, почему пока не может.

Философия HTCE: интеллект, который имеет право сомневаться

Есть два разных образа искусственного интеллекта.

Первый образ — это интеллект как имитация человека. Машина говорит живо, шутит, поддерживает беседу, быстро строит ассоциации и создаёт ощущение присутствия собеседника. Такой интеллект оценивают по внешнему впечатлению: насколько он похож на человека, насколько естественно отвечает, насколько уверенно звучит.

Второй образ — интеллект как дисциплина мышления. Такая система может быть менее разговорчивой, менее эффектной, менее “живой” на поверхности. Но она задаёт другой вопрос: не “как красиво ответить?”, а “имею ли я право ответить?”.

HTCE относится ко второму типу.

Её философия начинается с отказа от иллюзии: уверенный ответ ещё не означает знание. В мире машинного интеллекта это, возможно, один из самых важных тезисов. Мы привыкли считать интеллектом способность отвечать, но в ответственных системах не менее важна способность остановиться.

Сказать “я не знаю” — это не слабость. Сказать “у меня конфликт источников” — это не провал. Сказать “внешний solver дал verdict, но это ещё не истина” — это не недоверие к математике, а уважение к границам формализации.

HTCE строится вокруг этой границы.

Обычная AI-система часто напоминает оратора: она производит текст. HTCE больше похожа на архивариуса, судью и инженера одновременно. Архивариус требует источник. Судья требует процедуру. Инженер требует воспроизводимость. И только после этого система может сказать: “в данном контексте этот вывод допустим”.

В этом смысле HTCE — не просто техническая архитектура. Это попытка дать машине эпистемическую этику.

В человеческой культуре знание почти всегда связано с ответственностью. Если врач ставит диагноз, инженер подписывает расчёт, пилот принимает решение, аналитик делает прогноз — важно не только само утверждение, но и основание, на котором оно сделано.

Современные AI-системы часто разрывают эту связь. Они дают утверждение без ответственности за путь к утверждению. Ответ появляется как текст, но не всегда как доказанный вывод. Пользователь видит результат, но не видит историю: какие факты были использованы, какие были отброшены, где возник конфликт, почему система выбрала именно этот путь.

HTCE пытается восстановить эту связь.

Факт не равен гипотезе. Гипотеза не равна доказательству. Доказательство не равно истине. Внешний verdict не равен authority.

Эта цепочка кажется строгой, почти бюрократической. Но именно в ней и появляется зрелость. Система, которая не различает эти уровни, может быть очень убедительной, но опасной. Система, которая различает их, может быть медленнее, зато она начинает обладать тем, что можно назвать когнитивной совестью.

Особенно важен вопрос внешних свидетелей. В HTCE есть PDDL, SMT-LIB, VAL, Z3, cvc5 и другие возможные формальные контуры. На первый взгляд кажется: если формальный solver сказал sat , unsat или PASS , значит вопрос решён.

Но это соблазн.

Solver проверяет не мир. Он проверяет модель мира. Solver проверяет не истину. Он проверяет формулу. Solver проверяет не смысл. Он проверяет кодировку смысла.

Между реальностью и solver-ом всегда стоит человек или система, которая формализовала задачу. А значит, ошибка может быть не в solver-е, а в переводе реальности на язык solver-а.

Поэтому HTCE не говорит:

Она говорит:

Это тонкое различие. Но именно оно отделяет доказательную архитектуру от религиозной веры в формальные инструменты.

HTCE не отвергает solver. Напротив, она уважает его. Но она отказывает ему в статусе бога.

Обычно интеллект связывают со знанием. Чем больше система знает, тем она умнее. Но в реальных задачах не менее важна другая способность: управлять незнанием.

Что делать, если источники конфликтуют? Что делать, если проверка слишком дорогая? Что делать, если задача срочная, но риск высокий? Что делать, если внешний валидатор дал ответ, а внутренняя модель не согласна? Что делать, если система может продолжить рассуждение, но уже не имеет бюджета на тяжёлое доказательство?

HTCE отвечает на это через HOT/WARM/COLD/DEGRADE-режимы.

HOT — когда можно ответить быстро. WARM — когда нужен внутренний replay. COLD — когда требуется тяжёлая формальная проверка. DEGRADE — когда безопаснее остановиться, чем притвориться уверенным.

Это очень человеческая идея. Человек тоже не думает одинаково во всех ситуациях. Мы не доказываем теорему, когда нас спрашивают, где лежит ключ. Но мы не должны отвечать “на глаз”, когда проектируем мост.

Интеллект — это не максимальная глубина размышления в каждом моменте. Интеллект — это умение выбрать глубину размышления, соответствующую цене ошибки.

В этом смысле HTCE вводит не просто архитектурный механизм, а философию когнитивной экономии.

Один из скрытых рисков автономных систем — когнитивная жадность. Система может начать проверять всё, уточнять всё, доказывать всё и в итоге потерять способность действовать даже там, где действие безопасно и просто.

Это парадокс доказательной архитектуры: чем больше мы требуем гарантий, тем выше риск паралича.

HTCE отвечает на это через resident organism и эпистемический бюджет. Внутренний “организм” системы не может бесконечно требовать COLD-проверки. У него есть лимит. Если лимит исчерпан, система не должна тайно продолжать тяжёлую проверку. Она должна перейти в request_operator или DEGRADE.

Это важный философский момент: зрелый интеллект должен знать не только что он знает, но и сколько ему стоит узнать больше.

В человеческих терминах это похоже на мудрость. Не всякая неопределённость требует немедленного разрешения. Не всякая гипотеза заслуживает ресурса. Не всякое сомнение должно парализовать действие.

HTCE пытается формализовать эту мудрость.

Память в AI часто воспринимается как хранилище фактов. Но настоящая память — это не только накопление. Это ещё и дисциплина забывания, карантина, пересмотра и контекста.

HTCE не должна превращать каждое наблюдение в вечную истину. Она хранит evidence, trace, digest, root, conflict pressure. Она допускает, что новое свидетельство может не заменить старое, а вступить с ним в конфликт. Она допускает, что знание может быть локальным, временным, контекстным.

Это ближе к научной памяти, чем к бытовой базе данных.

Наука не развивается простым накоплением утверждений. Она развивается через проверку, опровержение, уточнение области применимости. HTCE наследует эту логику: утверждение ценно не потому, что оно записано, а потому, что оно выдерживает replay, context check и contradiction pressure.

Особая часть HTCE — сжатие опыта. Когда разные цепочки повторяются, система может построить abstraction candidate или macro-skill. Но и здесь она остаётся осторожной.

Сжатие — это соблазн. Повторение кажется законом. Похожесть кажется причинностью. Краткое описание кажется пониманием.

HTCE не должна попадать в эту ловушку. Поэтому сжатие создаёт candidate, а не истину. Macro-skill может быть атомарным для планировщика, но не атомарным для аудита. Его всегда можно раскрыть, проверить, локализовать ошибку, откатить дефектный edge или отправить всю цепочку в quarantine.

В этом есть важная философия: смысл возникает из сжатия, но истина не исчерпывается сжатием.

Красивая теория может быть ложной. Короткое правило может быть опасным. Успешный навык может иметь скрытую область неприменимости.

Поэтому HTCE сжимает опыт, но не поклоняется сжатию.

Новое поколение AI — это не обязательно система, которая говорит ещё более гладко. Возможно, настоящее новое поколение начнётся тогда, когда системы перестанут притворяться всезнающими.

HTCE предлагает другой критерий зрелости:

Это меняет сам образ искусственного интеллекта.

AI перестаёт быть магическим генератором ответа и становится процедурой ответственности. Он начинает жить не только в пространстве вероятностей, но и в пространстве обязательств: перед trace, перед evidence, перед оператором, перед безопасностью, перед будущими состояниями системы.

Однако важно не превратить философию HTCE в миф. HTCE пока не является полноценным универсальным разумом. Она ограничена языком, формализацией, отсутствием real authority, зависимостью от корректных моделей и внешних окружений для solver-а.

Но это честная ограниченность.

И в этом её сила. Она не говорит: “я уже всё понимаю”. Она говорит: “я знаю, где мои границы, и строю архитектуру так, чтобы эти границы не скрывались”.

Многие AI-системы стремятся выглядеть бесконечными. HTCE стремится быть конечной, проверяемой и ответственной.

Философски HTCE можно описать так:

это система, которая пытается превратить интеллект из искусства убедительного ответа в дисциплину проверяемого вывода.

Она не отказывается от гипотез. Она не отказывается от внешних solver-ов. Она не отказывается от обучения. Она не отказывается от сжатия опыта.

Но она требует, чтобы всё это проходило через границы:

Именно эти границы делают систему не слабее, а взрослее.

Потому что настоящий интеллект начинается не там, где машина говорит “я знаю”.

Настоящий интеллект начинается там, где машина может сказать:

HTCE — это попытка построить такую машину.

И именно в этом её инженерная ценность.

Источники, литература и близкие направления

Важно уточнить: HTCE в этой статье — авторское название проекта, Hierarchical Toroidal Cognitive Engine . Это не устоявшийся академический термин в deep learning. В литературе сокращение HTCE может встречаться в других смыслах, например как Hierarchical Temporal Convolutions for Eye Movement Analysis . Здесь речь идёт о другой архитектуре: доказательном когнитивном runtime с тороидальным состоянием, evidence-memory, replay, witness-boundary и risk-tiered режимами.

Ниже — не “готовая теория HTCE из учебника”, а источники и близкие направления, на которые опираются отдельные части системы.

PDDL — Planning Domain Definition Language PDDL используется как язык формального описания planning-задач: домен, действия, предикаты, начальное состояние и цель.

McDermott et al. — PDDL — The Planning Domain Definition Language https://www.cs.cmu.edu/~mmv/planning/readings/98aips-PDDL.pdf

В HTCE это связано с Type-1 witness-контуром:

Важно: PDDL-валидатор не становится источником истины. Он является внешним свидетелем по конкретной формальной модели.

VAL — инструментальная линия для проверки AI planning plans and planning models.

VAL repository https://github.com/KCL-Planning/VAL

Howey, Long, Fox — VAL: Automatic Plan Validation, Continuous Effects and Mixed Initiative Planning Using PDDL https://strathprints.strath.ac.uk/2550/6/strathprints002550.pdf

В HTCE это используется как пример внешнего planning witness:

Но:

Fast Downward — domain-independent classical planning system.

Fast Downward official site https://www.fast-downward.org/

Helmert — The Fast Downward Planning System https://arxiv.org/abs/1109.6051

В HTCE такие planners рассматриваются не как “разум системы”, а как внешние инструменты для проверки или генерации planning-кандидатов.

SMT-LIB — стандартный язык, набор теорий и benchmark-библиотека для SMT-солверов.

SMT-LIB official site https://smt-lib.org/

SMT-LIB benchmarks https://smt-lib.org/benchmarks.shtml

В HTCE это основа Type-2 witness-контуров:

Ключевое правило:

SMT-солвер проверяет формальную кодировку, а не саму реальность.

Z3 — theorem prover / SMT solver от Microsoft Research.

Z3 official GitHub https://github.com/Z3Prover/z3

Z3 documentation https://z3prover.github.io/

Bjørner et al. — Programming Z3 https://z3prover.github.io/papers/programmingz3.html

В HTCE Z3 может выступать внешним Type-2 witness-инструментом, но не получает authority над Core.

cvc5 — open-source SMT solver, successor of CVC4.

cvc5 documentation https://cvc5.github.io/docs/index.html

cvc5 GitHub https://github.com/cvc5/cvc5

Barbosa et al. — cvc5: A Versatile and Industrial-Strength SMT Solver https://www-cs.stanford.edu/~preiner/publications/2022/BarbosaBBKLMMMN-TACAS22.pdf

В HTCE cvc5 может использоваться как альтернативный SMT witness alongside Z3.

NIST AI Risk Management Framework — рамка для обсуждения trustworthy AI, рисков, безопасности, надёжности, объяснимости и прозрачности.

NIST AI Risk Management Framework https://www.nist.gov/itl/ai-risk-management-framework

NIST AI RMF: AI risks and trustworthiness characteristics https://airc.nist.gov/airmf-resources/airmf/3-sec-characteristics/

Это близко к HTCE по духу: система должна быть не только “умной”, но и проверяемой, объяснимой, устойчивой, безопасной и ограниченной по authority.

MDL — Minimum Description Length — принцип, связывающий обучение, модель и сжатие описания данных.

Grünwald — A Tutorial Introduction to the Minimum Description Length Principle https://arxiv.org/abs/math/0406077

Grünwald, Roos — Minimum Description Length Revisited https://arxiv.org/abs/1908.08484

В HTCE это близко к идее:

Но сжатие не становится истиной автоматически.

HTCE не является классической RL-shielding системой, но близкая идея есть: небезопасное действие или небезопасный вывод должны блокироваться runtime-границей.

Alshiekh et al. — Safe Reinforcement Learning via Shielding https://arxiv.org/abs/1708.08611

Hobbs et al. — Run Time Assurance for Safety-Critical Systems https://coogan.ece.gatech.edu/papers/pdf/hobbs2022csm.pdf

Slagel et al. — A Verification Framework for Runtime Assurance of Learning-Enabled Cyber-Physical Systems https://shemesh.larc.nasa.gov/fm/papers/DASC2024-SWDMC-draft.pdf

В HTCE это отражается в инвариантах:

Чтобы не смешивать термины, нужно явно указать, что сокращение HTCE уже встречается в другой литературе.

El Hmimdi et al. — Deep Learning-Based Detection of Learning Disorders on Eye-Tracking Data https://www.mdpi.com/2673-7426/4/1/29

Там HTCE означает Hierarchical Temporal Convolutions for Eye Movement Analysis . Это не тот HTCE, который описан в данной статье.

В этой статье:

Короткое резюме по источникам

HTCE как целостная архитектура — авторский проект. Но отдельные её идеи находятся на пересечении уже существующих областей:

Близкая область

External witness Type-1

Automated Planning, PDDL, VAL

External witness Type-2

SMT-LIB, Z3, cvc5

Trust boundary

Trustworthy AI, AI Risk Management

Macro-skill / abstraction

MDL, compression, model selection

Safety boundary

Runtime assurance, shielding

Evidence discipline

Formal verification, auditability, traceability

Risk-tiered modes

Bounded rationality, cost-aware verification

Главное отличие HTCE — не в том, что каждая отдельная идея полностью новая. Новизна в их связке:

То есть система разделяет генерацию, свидетельство, доказательное принятие, память, риск и authority.