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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Core  — защищённое детерминированное ядро
AIR   — внутренний язык и policy-gates
Body  — обработка событий и L1-наблюдений
Mind  — цели, планы, skill-chain, macro-skill
World — модель мира, причинные связи, replay
Learn — обучение, evidence, resident organism, witness boundary
Interface — тонкий операторский слой

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

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

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

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

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

Пример:

Mary is in kitchen
Where 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 ≠ truth
external verdict ≠ authority
external 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.

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

где:

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

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

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

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

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

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

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

где:

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

• — цель;

• — действие;

• — evidence;

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

• — результат;

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

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

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

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

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

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

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

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

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

Упрощённо:

обычная система:
  состояние → эвристика → ответ

HTCE:
  состояние → тороидальная координата → evidence → replay → bounded answer

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

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

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

где:

• — данные;

• — модель;

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

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

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

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

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

Например:

alpha causes beta
beta 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. Путь от факта к защищённому выводу

Факт пользователя
      |
      v
L1 Observation
      |
      v
Evidence admission
      |
      +-------------------+
      |                   |
      v                   v
No conflict          Conflict detected
      |                   |
      v                   v
L2 active fact       Quarantine / clarify
      |
      v
Query answer

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

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

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

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

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

где:

• — authority-risk;

• — truth-promotion-risk;

• — contradiction pressure;

• — uncertainty;

• — safety risk.

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

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

Verification cost

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

• 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.pddl
problem.pddl
plan
→ external validator
→ verdict
→ ExternalEvidenceRecord

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

Type-2: SMT/Theorem Proving

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

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

Снова:

sat ≠ truth
unsat ≠ truth
unknown ≠ failure of HTCE

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

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

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

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

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

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.

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

Честно:

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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