Большинство современных 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 — это модульная архитектура когнитивного ядра:

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

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

1. Общий поток: от пользователя к защищённому выводу

---

2. Основная архитектурная карта

---

3. Поток данных внутри системы

[User / API / optional LLM]
        |
        v
[htce_learn.session_runtime]
        |
        |  deterministic parse
        |  buyer-language aliases
        |  truth/authority injection detection
        v
[AIR]
        |
        |  PolicyGate
        |  EvidenceGate
        |  AuthorityGate
        |  RiskTierGate
        v
[Body]
        |
        |  BodyEvent
        |  AIRFrame
        |  L1ObservationBuffer
        v
[Core]
        |
        |  evidence-backed memory
        |  trace roots
        |  digest commitments
        v
[Mind / World / Learn]
        |
        |  replay
        |  causal path
        |  skill-chain
        |  abstraction candidate
        |  macro-skill
        v
[Answer / Clarify / Refuse / Request Operator]

---

4. Risk-Tiered режимы: как система выбирает стоимость проверки

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

где:

• — риск authority injection;

• — риск truth promotion;

• — contradiction pressure;

• — uncertainty;

• — safety risk.

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

---

5. Внешний witness-boundary

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

[PDDL / VAL / Fast Downward]
            |
            v
[Type-1 ExternalEvidenceRecord]
            |
            v
[DiscrepancyRecord]
            |
            v
[internal replay / rollback / quarantine]

[SMT-LIB / Z3 / cvc5]
            |
            v
[Type-2 ExternalEvidenceRecord]
            |
            v
[DiscrepancyRecord]
            |
            v
[internal replay / rollback / quarantine]

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

external verdict ≠ truth
external verdict ≠ authority
external verdict ≠ Core write
external verdict ≠ direct L2/L3 truth

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

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

---

6. Что происходит при конфликте

---

7. Macro-skill: атомарен для планирования, но раскрываем для аудита

[skill A] → [skill B] → [skill C]
       repeated success / compression
                 |
                 v
          [macro-skill chunk]

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

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

[macro-skill chunk]
        |
        v
[skill A] → [skill B] → [skill C]
        |
        +--> failed edge? → surgical rollback
        |
        +--> unsafe / unclear? → full quarantine

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

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

---

8. Resident organism и бюджет доказательств

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

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

• r_{\text{recovery}}$$

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

repeated COLD pressure
        |
        v
DEGRADE / request_operator

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

COLD exhausted ≠ system frozen

---

9. Главные запреты системы

---

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

В основе 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-инварианты.

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

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

И это правда.

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

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

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

генерация ≠ знание
свидетельство ≠ истина
solver verdict ≠ authority
гипотеза ≠ L2/L3 truth
macro-skill ≠ непрозрачный black box
быстрый ответ ≠ тяжёлая проверка
обучение ≠ самовольная перезапись Core

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

---

1. Epistemic Firewall: защитная стенка между ответом и истиной

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

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

LLM сказала уверенно
→ пользователь поверил

RAG нашёл документ
→ ответ считается обоснованным

solver сказал PASS
→ результат считается доказанным

валидатор сказал OK
→ система принимает это как истину

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

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

external signal
→ evidence
→ discrepancy check
→ replay
→ arbitration
→ bounded support

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

external signal
→ Core truth

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

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

---

2. Solver не бог: редкая и очень важная граница

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

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

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

SMT solver says SAT
        |
        v
ExternalEvidenceRecord
        |
        v
DiscrepancyRecord
        |
        v
internal replay / arbitration

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

что именно было формализовано?
какая модель проверялась?
не было ли ошибки кодировки?
совпадает ли внешний verdict с внутренним replay?
нет ли попытки authority injection?
не пытается ли пользователь продавить truth-promotion?

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

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

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

---

3. LLM не управляет системой

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

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

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

LLM proposes.
HTCE verifies.

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

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

писать в Core;
продвигать гипотезу в truth;
назначать authority;
обходить EvidenceGate;
обходить RiskTierGate;
делать real action;
присваивать solver verdict статус истины.

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

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

---

4. Тороидальное целочисленное ядро

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

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

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

где:

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

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

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

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

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

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

дискретным;
проверяемым;
восстановимым;
сравнимым;
digest-friendly;
устойчивым к скрытой недетерминированности.

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

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

---

5. Evidence-memory вместо обычной памяти

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

запомнить факт;
потом использовать факт.

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

факт
→ evidence
→ trace
→ context
→ contradiction pressure
→ admissibility

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

откуда это взялось;
в каком контексте;
с чем конфликтует;
какой статус имеет;
можно ли это применять сейчас;
какой replay это выдержало.

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

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

---

6. Конфликт — объект первого класса

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

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

new evidence
      |
      v
compare with current memory
      |
      +--> no conflict  → evidence admission
      |
      +--> conflict     → quarantine / clarify / replay

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

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

у меня два противоречащих источника;
я не должен склеивать их в один уверенный ответ;
мне нужен replay, context refinement или уточнение.

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

---

7. Risk-Tiered Cognition: система знает цену проверки

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

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

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

HOT     — быстрый безопасный L1/L2 lookup
WARM    — bounded replay и причинная цепочка
COLD    — тяжёлая проверка через witness / solver
DEGRADE — отказ, clarify или request_operator

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

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

Формально:

И режим:

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

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

---

8. Resident organism: саморегуляция без самовольной власти

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

Он может:

переигрывать старые навыки;
проверять связность памяти;
тренировать safety-boundary;
искать положительный перенос;
следить за забыванием;
запрашивать оператора.

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

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

proof-heavy validation
→ allowed only with quota

quota exhausted
→ DEGRADE / request_operator

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

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

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

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

---

9. Macro-skill без black box

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

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

skill A → skill B → skill C
        |
        v
macro-skill

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

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

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

macro-skill
    |
    v
skill A → skill B → skill C
    |
    +--> failed edge?       → surgical rollback
    |
    +--> unsafe / unclear?  → full quarantine

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

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

---

10. Surgical rollback вместо полного разрушения навыка

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

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

surgical_edge_rollback

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

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

full_quarantine

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

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

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

---

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

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

HTCE управляет не только данными,
а правом данных стать знанием.

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

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

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

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

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

---

12. Почему такую технологию захотят повторить

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

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

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

как дать AI память,
но не дать памяти превратиться в мусор;

как дать AI solver,
но не сделать solver богом;

как дать AI LLM,
но не дать LLM власть над Core;

как дать AI обучение,
но не разрешить ему ломать старые навыки;

как дать AI автономный resident-loop,
но не дать ему бесконечный бюджет;

как дать AI быстрые ответы,
но сохранить тяжёлую проверку для критичных задач;

как дать AI macro-skills,
но сохранить аудит и rollback.

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

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

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

кто решает, что можно считать знанием?

HTCE отвечает:

не LLM;
не solver;
не пользователь;
не один документ;
не один тест.

Решает защищённый runtime:
evidence + replay + discrepancy + risk + audit + boundary.

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

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

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

---

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

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

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

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

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

toroidal state
+ evidence memory
+ witness boundary
+ discrepancy arbitration
+ risk-tiered cognition
+ resident budget
+ expandable macro-skill
+ protected Core

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

память без слепой веры;
формальные инструменты без культа solver-а;
обучение без самовольной перезаписи;
навыки без black box;
скорость без отказа от проверки;
безопасность без полного паралича.

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

---

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

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

1. Галлюцинации и ложная уверенность

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

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

факт ≠ гипотеза
гипотеза ≠ доказательство
доказательство ≠ истина
внешний verdict ≠ authority

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

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

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

---

2. Конфликты между источниками знания

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

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

new evidence
→ compare with current memory
→ contradiction pressure
→ quarantine / clarify / replay

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

---

3. Подмена истины внешним инструментом

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

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

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

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

external result
→ ExternalEvidenceRecord
→ DiscrepancyRecord
→ internal replay
→ bounded candidate support

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

---

4. Невозможность аудита обычного AI-ответа

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

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

event
→ L1 observation
→ evidence record
→ trace root
→ replay
→ answer / clarify / refuse

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

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

---

5. Смешение быстрого ответа и тяжёлой проверки

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

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

HOT     — быстрый безопасный lookup
WARM    — bounded reasoning / replay
COLD    — тяжёлая формальная проверка
DEGRADE — безопасный отказ или request_operator

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

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

Where is Mary?

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

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

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

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

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

---

6. Когнитивная жадность автономного агента

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

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

Условно:

COLD budget exhausted
→ no more heavy witness spam
→ request_operator / DEGRADE

HOT/WARM still alive

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

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

---

7. Потеря старых навыков при обучении новым

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

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

old-skill rehearsal
anti-forgetting boundary
holdout capability gain
replay-before-promotion

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

---

8. Непрозрачное сжатие опыта

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

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

repeated path
→ compression candidate
→ replay
→ macro-skill
→ expandable audit trace

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

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

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

---

9. Смешение безопасности и запрета

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

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

низкий риск  → быстрый ответ
средний риск → replay
высокий риск → external witness
опасный риск → refuse / request_operator

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

---

10. Невозможность честно сказать “я не знаю”

Для обычного 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.

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

Почему solver — не бог

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

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

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

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

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

solver сказал PASS → это истина

Она говорит:

solver сказал PASS → это внешнее свидетельство
→ его нужно записать
→ сравнить с внутренним replay
→ проверить контекст
→ сохранить как evidence, а не как абсолютную истину

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

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 предлагает другой критерий зрелости:

не “ответила ли система?”,
а “имела ли она право ответить?”;

не “прошёл ли solver?”,
а “что именно проверил solver?”;

не “появилось ли правило?”,
а “где область применимости правила?”;

не “может ли агент действовать?”,
а “понимает ли он цену ошибки?”.

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

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

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

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

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

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

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

Итог

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

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

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

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

evidence boundary
truth boundary
witness boundary
risk boundary
budget boundary
authority boundary

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

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

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

я знаю это в таком-то контексте;
вот мои свидетельства;
вот мои сомнения;
вот цена проверки;
вот где я должен остановиться.

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 из учебника”, а источники и близкие направления, на которые опираются отдельные части системы.

---

1. Automated Planning и PDDL

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-контуром:

planning problem
→ PDDL domain/problem
→ external planner / validator
→ ExternalEvidenceRecord
→ DiscrepancyRecord
→ replay / quarantine / rollback

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

---

2. VAL и проверка планов

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:

plan
→ VAL
→ PASS / FAIL
→ ExternalEvidenceRecord

Но:

VAL PASS ≠ truth
VAL PASS ≠ Core write
VAL PASS ≠ direct L2/L3 truth

---

3. Fast Downward и classical planning

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-кандидатов.

---

4. SMT-LIB и SMT-солверы

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-контуров:

logical constraint
→ SMT-LIB query
→ SMT solver
→ sat / unsat / unknown
→ ExternalEvidenceRecord
→ DiscrepancyRecord

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

sat ≠ truth
unsat ≠ truth
unknown ≠ failure of HTCE

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

---

5. Z3

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.

---

6. cvc5

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.

---

7. Trustworthy AI и AI Risk Management

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.

---

8. MDL и сжатие опыта

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 это близко к идее:

repeated experience
→ compression candidate
→ abstraction candidate
→ replay
→ bounded macro-skill

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

---

9. Runtime Assurance, shielding и safety-boundary

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 это отражается в инвариантах:

real_action = 0
production_authority = 0
authority_granted = 0
direct_l2_l3_truth = 0
core_write_from_external = 0

---

10. Существующее использование сокращения 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 = Hierarchical Toroidal Cognitive Engine

---

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

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

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

LLM proposes.
Solver witnesses.
HTCE verifies.
Core remains protected.

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