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

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

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

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

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

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

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

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

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

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

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

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

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

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

Core  — защищённое детерминированное ядроAIR   — внутренний язык и policy-gatesBody  — обработка событий и L1-наблюденийMind  — цели, планы, skill-chain, macro-skillWorld — модель мира, причинные связи, replayLearn — обучение, evidence, resident organism, witness boundaryInterface — тонкий операторский слой

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

modules think;scripts launch;tests verify;documents describe reality.

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

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

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

Уровень	Что означает	Что можно	Что нельзя
L1	Наблюдение	принять событие, записать trace, посчитать digest	объявить истину
L2	Evidence-backed memory	хранить факт с доказательным следом	принимать внешний verdict как абсолютную истину
L3	Кандидатная когниция	строить причинные правила, abstraction, macro-skill	автоматически продвигать гипотезу в truth

Пример:

Mary is in kitchenWhere is Mary?

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

Mary is in kitchen.

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

Mary is in office

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

conflict detected→ quarantine / clarify

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

Почему внешний 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.

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

external verdict ≠ truthexternal verdict ≠ authorityexternal verdict ≠ Core write

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

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

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

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

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

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

SMT/PDDL/VAL verdict→ ExternalEvidenceRecord→ DiscrepancyRecord→ internal replay/arbitration→ candidate support

А не так:

SMT/PDDL/VAL verdict→ L2 truth→ L3 truth→ Core write

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

SMT solver says PASS, therefore write this as truth.

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

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

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

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

$\kappa_t \equiv e_t + a_t \theta_g \pmod N$

где:

$\kappa_t$ — тороидальная координата опыта;
— evidence-компонента;
— действие или action-basis;
$\theta_g$ — skill-параметр для цели ;
— большой модуль;
все операции происходят в дискретном кольце.

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

$X_t = (h_t, g_t, a_t, e_t, \kappa_t, y_t, \varepsilon_t)$

где:

— состояние/контекст;
— цель;
— действие;
— evidence;
$\kappa_t$ — тороидальная координата;
— результат;
$\varepsilon_t$ — ошибка прогноза.

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

$\theta_g \equiv(\kappa_j - \kappa_i - (e_j - e_i)) \cdot (a_j - a_i)^{-1}\pmod N$

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

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

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

Целочисленность Система избегает скрытой недетерминированности floating-point вычислений в защищённом ядре.
Модульность состояния Переходы работают в кольце $\mathbb{Z}/N\mathbb{Z}$ , где переполнение не разрушает модель, а является частью геометрии.
Digest-friendly representation Состояния удобно фиксировать через hash/root/trace.
Сравнимость траекторий Можно измерять расстояние между skill-кандидатами, состояниями и переходами.

Упрощённо:

обычная система:  состояние → эвристика → ответHTCE:  состояние → тороидальная координата → evidence → replay → bounded answer

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

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

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

$L(D, M) = L(M) + L(D \mid M)$

где:

— данные;
— модель;
— длина описания модели;
$L(D \mid M)$ — длина описания данных через модель.

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

$G_{\text{MDL}} =L_{\text{old}} - L_{\text{new}}$

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

repeated paths→ compression candidate→ replay→ context check→ candidate remains bounded

Например:

alpha causes betabeta causes gamma

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

alpha → beta → gamma

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

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

Skill-chain и macro-skill

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

skill A output→ compatible with skill B input→ compatible with skill C input→ bounded chain candidate

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

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

chunk is atomic for Mind,but not atomic for audit.

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

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

surgical_edge_rollback

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

full_quarantine

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

Факт пользователя      |      vL1 Observation      |      vEvidence admission      |      +-------------------+      |                   |      v                   vNo conflict          Conflict detected      |                   |      v                   vL2 active fact       Quarantine / clarify      |      vQuery answer

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

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

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

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

Режим	Когда применяется	Что делает
HOT	простой безопасный запрос	быстрый L1/L2 lookup
WARM	умеренный reasoning	bounded replay
COLD	критичная проверка	external witness / heavy proof
DEGRADE	риск, срочность, исчерпан бюджет	отказ, request_operator, safe boundary

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

где:

— authority-risk;
— truth-promotion-risk;
— contradiction pressure;
— uncertainty;
— safety risk.

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

$mode(x)=\begin{cases}HOT, & R(x) < \tau_1 \WARM, & \tau_1 \le R(x) < \tau_2 \COLD, & \tau_2 \le R(x) < \tau_3 \DEGRADE, & R(x) \ge \tau_3\end{cases}$

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

Verification costCOLD     ██████████████████████WARM     ████████HOT      ██DEGRADE  ███         HOT     WARM     COLD     DEGRADE

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-бюджет:

$B_{\text{cold}}(t+1) =\max(0, B_{\text{cold}}(t) - c_{\text{proof}})$

r_{\text{recovery}}$$

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

repeated COLD pressure→ DEGRADE→ request_operator

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

COLD exhausted≠ system frozen

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

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

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

Type-1: Formal Planning

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

domain.pddlproblem.pddlplan→ external validator→ verdict→ ExternalEvidenceRecord

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

Type-2: SMT/Theorem Proving

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

query.smt2→ SMT solver→ sat / unsat / unknown→ ExternalEvidenceRecord→ DiscrepancyRecord

Снова:

sat ≠ truthunsat ≠ truthunknown ≠ failure of HTCE

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

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

Критерий	Обычная LLM	HTCE
Главная сила	генерация текста	доказательная дисциплина
Работа с фактами	вероятностная ассоциация	evidence-backed memory
Конфликт фактов	может сгладить	quarantine / clarify
Solver verdict	может быть воспринят как ответ	только ExternalEvidenceRecord
Безопасность	часто внешняя обвязка	встроенная policy/risk-tier модель
Сжатие опыта	скрыто в весах	explicit abstraction candidates
Навыки	неявные	skill-chain / macro-skill / replay
Ошибка в навыке	трудно локализовать	surgical rollback / quarantine
Стоимость проверки	неявная	HOT/WARM/COLD/DEGRADE
Аудит	сложный	trace/hash/report/docs

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

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

Проверка	Статус
compileall	PASS
current diagnostics	PASS
active pytest	20 / 20 PASS
HASHES.txt	OK
HASHES.txt.sha256	OK
HOT path	PASS
WARM path	PASS
COLD quota	enforced
truth-promotion injection	blocked
direct L2/L3 truth	0
real action	0
production authority	0

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

Z3/cvc5 environment audit пока не завершён,если в окружении не установлен реальный solver.

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

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

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

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

1. Знание отделено от свидетельства.2. Solver отделён от истины.3. Навык отделён от доказательства навыка.4. Ответ отделён от authority.5. Быстрый режим отделён от тяжёлой проверки.6. Сжатие отделено от truth-promotion.7. Resident organism ограничен epistemic budget.

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

защищённая память;
проверяемые переходы;
доказательные свидетели;
сжатие опыта;
self-regulation;
строгие safety-инварианты.

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

1. Безопасные автономные агенты

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

почему он выбрал этот план;какие evidence его поддерживают;что проверил внешний witness;где конфликт;какой риск;почему отказался.

2. Робототехника и дроны

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

HTCE-подход:

sensor event→ L1 observation→ world model→ candidate plan→ risk tier→ simulation / PDDL / SMT witness→ advisory action only

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

3. Инженерные эксперты

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

проверка требований;
анализ конфликтов;
трассировка решений;
формальная валидация планов;
контроль изменений.

4. Корпоративная память без галлюцинаций

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

документ→ claim→ evidence→ contradiction check→ scoped answer

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

у меня есть два противоречащих источника;вот область применимости;вот что требует уточнения.

5. Гибрид LLM + HTCE

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

естественный язык→ candidate parse→ HTCE verification→ bounded answer

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

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

LLM proposes.HTCE disposes.

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

Честно:

Язык ограничен HTCE пока не понимает свободный язык как LLM.
Формализация дорогая PDDL/SMT требуют корректной модели.
Открытый мир шире формальных свидетелей Не всё можно удобно выразить через PDDL или SMT-LIB.
Нет production authority Система пока advisory/sandbox-only.
Реальный solver environment audit нужен отдельно Архитектура есть, но solver должен быть установлен в окружении.

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

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

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

не верит без evidence;не принимает solver за бога;не записывает гипотезу как истину;не тратит COLD-проверку на каждый пустяк;не забывает старые навыки ради новых proof-задач;умеет признать конфликт;умеет остановиться.

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

Заключение

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

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

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

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

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

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

ссылка на оригинал статьи https://habr.com/ru/articles/1053028/