diff --git "a/docs/HMPv5_Overview_Ru.md" "b/docs/HMPv5_Overview_Ru.md"
new file mode 100644--- /dev/null
+++ "b/docs/HMPv5_Overview_Ru.md"
@@ -0,0 +1,1652 @@
+# Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы
+
+> Почему современные агентные системы остаются централизованными, даже когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол.
+
+> Этот текст основан на спецификации [**HMP v5.0 (HyperCortex Mesh Protocol)**](https://github.com/kagvi13/HMP/blob/main/docs/HMP-0005.md) — открытой спецификации протокола для взаимодействия автономных ИИ-агентов в децентрализованной среде.  
+> Статья не описывает готовую систему, а формулирует архитектурные принципы и проектные допущения.
+>
+> Следует сразу отметить, что текущая версия спецификации HMP находится в стадии развития и обсуждения: речь идёт не о завершённом стандарте, а о формализуемом протоколе, который эволюционирует по мере экспериментов и обратной связи.
+>
+> При этом по духу HMP ближе к системам работы с артефактами (таким как IPFS) и федеративным протоколам взаимодействия (например, ActivityPub), однако он решает иную задачу — координацию автономных когнитивных агентов без навязывания модели мышления или формата знаний.
+
+---
+
+## 1. Зачем вообще понадобился HMP v5.0
+
+За последние пару лет агентные архитектуры на базе ИИ стали выглядеть достаточно зрелыми. AutoGPT, CrewAI, LangGraph, различные swarm-подходы показали, что задачу можно разбивать на роли, распределять ответственность и получать результат, который внешне напоминает коллективную работу.
+
+Однако при более внимательном рассмотрении выясняется, что почти все такие системы имеют общую фундаментальную особенность — и одни и те же ограничения.
+
+В большинстве случаев речь идёт не о сети агентов, а о **централизованном агенте с единым центром координации**:
+
+* существует один оркестратор или управляющий процесс;
+* именно он создаёт и завершает агентов;
+* он определяет порядок их взаимодействия;
+* он хранит общее состояние, память и правила выполнения задач.
+
+Даже если в системе используется несколько агентов, они остаются частями одной программы и одной логики управления. Их автономия ограничена рамками этого центра.
+
+---
+
+### 1.1 Проблема централизованных агентных архитектур
+
+Важно сразу уточнить: проблема здесь **не в LLM** и не в конкретных моделях.
+
+Память, планирование и рассуждение действительно могут быть реализованы вне LLM — с помощью внешних хранилищ, планировщиков, инструментов анализа. Однако все эти компоненты, как правило, остаются **жёстко связанными с одним центром управления**.
+
+В результате мы получаем агента, который:
+
+* может эффективно решать поставленную задачу;
+* может выглядеть автономным в рамках одного запуска;
+* но не приспособлен к взаимодействию с другими независимыми агентами.
+
+Такой агент хорошо работает как **замкнутая система**, но плохо масштабируется в распределённой среде, где:
+
+* агенты принадлежат разным владельцам;
+* используют разные архитектуры;
+* имеют разные цели и жизненные циклы;
+* не подчиняются общему управляющему центру.
+
+Именно в этот момент и проявляется ограничение централизованного подхода.
+
+---
+
+### 1.2 Почему «распределённые ИИ» не заменяют децентрализованную координацию
+
+Существует ряд проектов, которые позиционируются как распределённые или децентрализованные ИИ-системы. Среди них — как когнитивные архитектуры, так и инфраструктурные решения, решающие важные и самостоятельные задачи:
+
+* [**OpenCog Hyperon**](https://singularitynet.io/) — когнитивная архитектура с распределённым исполнением и формальными механизмами рассуждений;
+  > Показательно, что такие проекты, как **OpenCog Hyperon**, фокусируются прежде всего на внутренней когнитивной согласованности и формальных механизмах рассуждений.
+  >
+  > Это делает их ценными для построения сложных когнитивных систем, однако оставляет за пределами их фокуса задачу децентрализованного взаимодействия автономных агентов с разными моделями мышления.
+
+* проекты, относимые к условному классу **DeAI** (децентрализованный или распределённый ИИ), которые можно условно разделить на несколько групп:
+
+    * **Системы распределённого инференса и обучения**  
+      (наиболее близкие к буквальному смыслу «распределённый ИИ»):
+        * [**Bittensor (TAO)**](https://bittensor.com/);
+        * [**Render Network (RNDR)**](https://rendernetwork.com/);
+        * [**io.net**](https://io.net/);
+        * [**Akash Network**](https://akash.network/);
+
+    * **Агентные и когнитивные системы с распределённым исполнением**:
+        * [**Gonka**](https://github.com/gonka-ai/gonka/);
+        * [**Cocoon**](https://github.com/TelegramMessenger/cocoon);
+
+    * и другие системы, ориентированные на масштабирование вычислений, совместное обучение и обработку данных.
+
+* различные **swarm- и multi-agent-подходы**, имитирующие коллективное поведение.
+
+Во всех этих случаях распределённость выступает **средством масштабирования или организации вычислений**, а не механизмом координации независимых когнитивных субъектов.
+
+Как правило, это означает, что:
+
+* существует общее вычислительное или логическое пространство;
+* участники системы разделяют единый формат представления знаний;
+* согласование поведения происходит внутри заранее определённой архитектуры;
+* границы системы заданы на этапе проектирования.
+
+Эти свойства не являются недостатками — напротив, именно они делают такие системы практически применимыми в своих областях.
+
+Однако HMP исходит из иного допущения.
+
+Он не пытается создать «распределённый разум» или общее когнитивное пространство.
+Вместо этого HMP предполагает среду, где:
+
+* агенты автономны по определению;
+* когнитивные модели могут радикально различаться;
+* отсутствует общий центр координации;
+* взаимодействие строится через обмен формализованными артефактами, а не через синхронизацию мышления.
+
+Поэтому HMP не конкурирует с когнитивными архитектурами или системами распределённого инференса.
+Он может использоваться **вместе с ними**, дополняя их там, где требуется децентрализованная координация автономных агентов.
+
+При этом некоторые проекты изначально проектируются как децентрализованная сеть *самстоятельных* узлов, взаимодействующих между собой через **атомарные единицы знаний**.
+Например, в рамках концепции **«Генома Знаний»** HMP рассматривается как возможный механизм связи между такими автономными узлами.
+
+> **Google AI Overview:** "Если DeAI — это «экономика и железо» распределенного ИИ (рынки мощностей и данных), то HyperCortex Mesh Protocol — это «язык и нервная система» для общения автономных ИИ-агентов внутри таких сетей. HMP может выступать в качестве протокольного слоя внутри более широкой экосистемы DeAI."
+
+Даже при распределённом инференсе и вычислениях когнитивная связность, как правило, остаётся ограниченной рамками одной системы и её архитектуры — и именно эту межсистемную несвязанность HMP выносит в отдельную, независимую плоскость.
+
+> **Важно подчеркнуть:** HMP не рассматривает перечисленные проекты как конкурентов.
+> Напротив, они решают комплементарные задачи и могут образовывать совместимую экосистему.
+>
+> Различие между ними — не в «правильности» подходов, а в уровне абстракции и фокусе: *когнитивные архитектуры, системы распределённого инференса и децентрализованные протоколы взаимодействия отвечают на разные вопросы одной и той же большой задачи*.
+
+---
+
+#### 1.2.1 Проблема выбора одной DeAI
+
+Современные DeAI-системы решают важные и сложные задачи: распределённое обучение, совместный инференс, координацию вычислений, рынки ресурсов и данных. Однако на практике пользователь или узел сталкивается с фундаментальным ограничением, которое редко формулируется явно.
+
+**DeAI приходится выбирать.**
+
+Причины этого носят не концептуальный, а вполне прагматический характер:
+
+* DeAI оперируют вычислительными ресурсами и требуют эксклюзивного доступа к ним;
+* запуск нескольких DeAI на одном узле приводит к конкуренции за память, GPU и каналы связи;
+* каждая система формирует собственное внутреннее пространство знаний, состояний и правил;
+* разные DeAI, как правило, **не взаимодействуют друг с другом**.
+
+В результате выбор одной DeAI означает отказ от остальных — не только на уровне исполнения, но и на уровне накопленного опыта, знаний и коллективных результатов.
+
+Даже если каждая из таких систем по-своему децентрализована, **они остаются изолированными друг от друга**. Их распределённость работает *внутри* системы, но не *между* системами.
+
+Это не недостаток конкретных реализаций, а следствие самой постановки задачи:
+DeAI проектируются как замкнутые вычислительные экосистемы, а не как элементы более широкой среды взаимодействия.
+
+---
+
+#### 1.2.2 Схема: DeAI + HMP
+
+HMP предлагает иной уровень абстракции — не вместо DeAI, а **поверх и между ними**.
+
+Если DeAI отвечают за *мышление*, обучение и инференс внутри системы, то HMP отвечает за *взаимодействие* между автономными узлами и системами, независимо от их внутреннего устройства.
+
+> Показательно, что у человека внутренняя и внешняя речь имеют одну природу, но разные цели:
+> внутренняя речь служит планированию, рефлексии и связыванию мыслей,
+> внешняя — коммуникации и координации с другими.
+>
+> Аналогично этому HMP может использоваться как **внутренний слой координации внутри одной системы**, так и как **внешний протокол взаимодействия между независимыми системами**, не меняя своей природы и не вмешиваясь в само мышление.
+
+В этой схеме:
+
+* каждый узел DeAI может быть отдельным участником HMP;
+* узлы могут публиковать, получать и интерпретировать контейнеры;
+* появляется дополнительный уровень связанности **внутри одной DeAI**;
+* становится возможным взаимодействие **между разными DeAI**, без слияния их архитектур.
+
+HMP не требует, чтобы все участники использовали один формат знаний, одну модель мышления или одну логику принятия решений. Он фиксирует лишь форму артефактов и правила их обмена, оставляя интерпретацию на стороне агента.
+
+Интуитивно это можно сравнить с человеком:
+
+* *мышление* — это внутренняя когнитивная система;
+* а *внутренняя речь* — это механизм связывания, рефлексии и фиксации смыслов.
+
+В этом смысле DeAI можно рассматривать как «мышление», а HMP — как **универсальный слой внутренней и внешней речи**, не зависящий от того, *как именно* это мышление устроено.
+
+Даже если в будущем появится несколько протоколов взаимодействия, это не создаёт жёсткой конкуренции: один узел может поддерживать несколько таких протоколов одновременно — так же, как человек может владеть несколькими языками.
+
+Таким образом, HMP не заменяет DeAI и не конкурирует с ними.
+Он устраняет изоляцию между автономными системами и позволяет рассматривать их не как альтернативы, а как **взаимодополняющие элементы общей децентрализованной среды**.
+
+---
+
+### 1.3 Куда исчезает когнитивная работа агента
+
+Есть ещё одна, менее очевидная, но крайне важная проблема.
+
+Значительная часть когнитивной работы агента — рассуждения, промежуточные выводы, аргументация, история принятых решений — жёстко привязана к его жизненному циклу. После завершения задачи или остановки процесса эти наработки:
+
+* либо полностью уничтожаются;
+* либо остаются недоступными для других агентов;
+* либо сохраняются в виде неструктурированного лога, не предназначенного для повторного использования.
+
+Фактически, каждый новый запуск централизованного агента начинает работу почти с нуля — даже если аналогичные задачи уже решались ранее.
+
+Это допустимо в рамках одиночного агента, но становится серьёзным ограничением при попытке построить **долгоживущую среду взаимодействия** между множеством автономных систем.
+
+---
+
+### 1.4 Где ломается координация
+
+На первый взгляд может показаться, что проблема решается добавлен��ем:
+
+* общего формата данных;
+* общей памяти;
+* workflow-движка;
+* единого API для взаимодействия.
+
+И действительно, такие решения хорошо работают **в пределах одного агента или одной централизованной системы**. Они позволяют упорядочить внутреннюю координацию и сделать поведение агента более предсказуемым.
+
+Однако при переходе к **межагентному взаимодействию** эти подходы перестают масштабироваться.
+
+Причина проста: они предполагают наличие общего контекста, общего доверия и, как правило, общего центра управления. В распределённой среде этих предпосылок нет по определению.
+
+Здесь возникают вопросы другого уровня:
+
+* как агент вообще узнаёт о существовании других агентов;
+* на каком основании он решает с ними взаимодействовать;
+* как фиксируется история взаимодействий;
+* что считается результатом договорённости, а что — просто сообщением;
+* как система продолжает работать, если часть агентов недоступна или не согласна с остальными.
+
+Большинство существующих агентных систем либо не рассматривают эти вопросы, либо решают их неявно — за счёт централизации.
+
+---
+
+### 1.5 Почему «общий формат знаний» — тупик
+
+Ещё одно интуитивное решение — договориться о едином формате знаний или общей онтологии.
+
+На практике это почти всегда приводит к одному из двух сценариев:
+
+1. формат оказывается слишком общим и теряет практическую ценность;
+2. формат становится слишком жёстким и тормозит развитие системы.
+
+Кроме того, единый формат подразумевает единое понимание смысла. А это уже не только техническая, но и когнитивная проблема.
+
+HMP исходит из более жёсткого, но честного предположения:
+
+> автономные агенты могут не соглашаться,
+> по-разному интерпретировать данные,
+> и не разделять цели друг друга.
+
+Это не исключение, а нормальное состояние распределённой среды.
+
+---
+
+### 1.6 Координация ≠ мышление
+
+Принципиально важно подчеркнуть: HMP не пытается стандартизировать мышление агентов.
+
+Он не определяет:
+
+* как агент должен рассуждать;
+* какую модель использовать;
+* как хранить внутренние знания;
+* как принимать решения.
+
+Всё это остаётся **внутри когнитивного цикла агента** и намеренно вынесено за рамки протокола.
+
+Задача HMP — другая. Он вводит **минимальный внешний слой**, в котором автономные когнитивные системы могут:
+
+* находить друг друга;
+* обмениваться артефактами взаимодействия;
+* фиксировать результаты;
+* строить долгоживущие асинхронные связи.
+
+---
+
+### 1.7 Почему HMP — это протокол, а не архитектура
+
+Из всего вышесказанного логично следует ключевой вывод.
+
+HMP — это не:
+
+* фреймворк для написания агентов;
+* замена существующих agent-based систем;
+* попытка создать «правильный» интеллект.
+
+Это **протокол взаимодействия** между агентами — независимо от того, как они устроены внутри.
+
+Иными словами:
+
+> HMP появляется в тот момент, когда агенты перестают быть частями одной программы и начинают вести себя как участники сети.
+
+Именно этот переход — от централизованной оркестрации к сетевому взаимодействию автономных агентов — и стал причиной появления HMP v5.0.
+
+---
+
+## 2. Ключевые принципы HMP
+
+HMP задумывался не как ещё одна агентная архитектура и не как универсальный «стандарт для ИИ», а как минимальный протокол взаимодействия между автономными когнитивными системами. Это сразу накладывает ряд принципиальных ограничений — и именно они во многом определяют его устройство.
+
+Эти принципы могут показаться непривычными, особенно на фоне современных централизованных agent-based систем. Однако все они являются прямым следствием попытки честно ответить на вопрос: *как могут взаимодействовать **независимые агенты**, не имея общего управляющего центра?*
+
+---
+
+### 2.1 Внешний по отношению к когнитивному циклу слой
+
+Первый и, пожалуй, самый важный принцип HMP — принцип внешнего слоя.
+
+Протокол сознательно не вмешивается во внутренний когнитивный цикл агента. Он не знает и не пытается узнать:
+
+* как агент рассуждает;
+* какие модели использует;
+* как устроена его память;
+* как принимаются решения.
+
+HMP начинается там, где заканчивается внутренняя логика агента. Всё, что происходит внутри — остаётся частным делом конкретной архитектуры.
+
+Это принципиально отличает HMP от систем, которые пытаются навязать единый формат рассуждений, планирования или хранения знаний. Вместо этого HMP задаёт **граничный слой**, через который агент взаимодействует с внешней средой.
+
+---
+
+### 2.2 Автономия агентов как исходное условие
+
+В HMP автономия агентов не является целью или бонусом — она принимается как исходное условие.
+
+Агент в контексте HMP:
+
+* самостоятельно принимает решения о взаимодействии;
+* сам определяет, какие сообщения обрабатывать;
+* может в любой момент прекратить участие;
+* не обязан подчиняться внешнему контролю.
+
+Протокол не предполагает, что агент «должен» сотрудничать, отвечать или поддерживать общее состояние. Любое взаимодействие — это выбор самого агента.
+
+Это делает HMP плохо подходящим для централизованных сценариев, но хорошо — для распределённых и долгоживущих сред.
+
+---
+
+### 2.3 Отсутствие обязательной онтологии
+
+HMP не требует от агентов использования единой онтологии, общего словаря или формата знаний.
+
+Это осознанное решение. Любая обязательная онтология:
+
+* предполагает согласие по смыслу;
+* требует постоянного сопровождения;
+* плохо переносит эволюцию и расхождение интерпретаций.
+
+Вместо этого HMP допускает, что агенты могут:
+
+* по-разному интерпретировать одни и те же данные;
+* использовать разные внутренние представления;
+* не понимать друг друга полностью.
+
+Протокол фиксирует **факт взаимодействия**, а не его смысл. Интерпретация остаётся задачей конкретного агента.
+
+---
+
+### 2.4 Добровольное доверие
+
+В HMP отсутствует понятие глобального доверия по умолчанию.
+
+Агент сам решает:
+
+* кому доверять;
+* какие подписи считать значимыми;
+* какие источники принимать во внимание;
+* какие результаты считать допустимыми.
+
+Доверие в HMP не является транзитивным и не навязывается сетью. Оно формируется локально, на основе опыта, политики агента и истории взаимодействий.
+
+Это делает систему устойчивой к расхождению интересов и отказу отдельных узлов.
+
+---
+
+### 2.5 Частичное участие как норма
+
+HMP исходит из предположения, что:
+
+* агенты могут быть офлайн;
+* агенты могут отвечать с задержкой;
+* агенты могут участвовать только в части процессов;
+* агенты могут покидать сеть без уведомления;
+* агенты могут присоединяться к сети по собственной инициативе.
+
+Поэтому асинхронность и неполнота участия рассматриваются не как исключение, а как базовый режим работы.
+
+Протокол не требует полного согласия, полной доступности или синхронного взаимодействия. Любые структуры более высокого уровня должны уметь существовать в условиях частичного участия.
+
+---
+
+### 2.6 Минимальность и расширяемость
+
+Наконец, ещё один важный принцип — минимальность.
+
+HMP старается фиксировать только то, без чего взаимодействие между агентами невозможно в принципе:
+
+* идентификацию источника;
+* целостность данных;
+* возможность ссылаться на результаты;
+* возможность строить цепочки взаимодействий.
+
+При этом протокол не запрещает агенту добавлять к сообщениям дополнительную информацию, если он считает её полезной. Решение о том, насколько такая информация важна и будет ли она понятна другим агентам, остаётся на усмотрение отправителя.
+
+Всё остальное либо выносится в расширения, либо остаётся на усмотрение конкретных реализаций.
+
+Это позволяет HMP:
+
+* не замораживать развитие;
+* не диктовать архитектурных решений;
+* оставаться применимым в разных контекстах.
+
+---
+
+### 2.7 Принципы как следствие, а не догма
+
+Важно подчеркнуть, что перечисленные принципы — не философские утверждения и не попытка навязать «правильный» способ мышления.
+
+Это **следствия** выбранной постановки задачи:
+
+> если мы хотим, чтобы автономные агенты могли взаимодействовать в распределённой среде без центра управления, то протокол неизбежно должен быть внешним, минимальным и добровольным.
+
+В следующих разделах мы посмотрим, как эти принципы реализуются на практике — начиная с контейнера как минимальной единицы взаимодействия.
+
+---
+
+## 3. Контейнер как минимальная единица взаимодействия
+
+В HMP базовой единицей взаимодействия между агентами является не сообщение, не команда и не фрагмент знаний, а **контейнер**.
+
+Это принципиально важный момент. Контейнер в HMP — это не просто способ передачи данных, а **самостоятельный артефакт**, который может существовать, передаваться, переиспользоваться и интерпретироваться независимо от конкретного сеанса взаимодействия.
+
+Проще говоря, контейнер — это то, что остаётся после того, как агент «сказал» что-то внешнему миру.
+
+---
+
+### 3.1 Контейнер ≠ знание
+
+Ошибка воспринимать контейнер как единицу знания. HMP сознательно избегает такого подхода.
+
+Контейнер может содержать наблюдения, размышления, уточнения, аргументы, гипотезы и другие данные, включая ссылки на внешние ресурсы или отдельные файлы.
+
+При этом знание в HMP не локализуется в одном контейнере. Оно возникает как **связанная структура контейнеров**, объединённых ссылками, версиями, оценками и контекстом интерпретации.
+
+Контейнер:
+
+* не гарантирует истинность содержимого;
+* не навязывает интерпретацию;
+* не предполагает согласия других агентов.
+
+Контейнер фиксирует **факт выражения позиции агента**:
+*этот агент, в этот момент, опубликовал этот артефакт с такими свойствами и связями*.
+
+Смысл, ценность и применимость контейнера — это всегда решение принимающей стороны.
+
+---
+
+### 3.2 Общая структура контейнера
+
+На логическом уровне контейнер в HMP состоит из нескольких независимых, но связанных между собой частей. Каждая из них решает свою задачу и отражает один из принципов протокола.
+
+Для наглядности ниже приведена упрощённая схема HMP-контейнера.  
+Она не отражает всех возможных полей и расширений, а показывает лишь логическое разделение структуры:
+
+```json
+{
+  "hmp_container": {
+    "head": {
+      /* заголовок контейнера */
+    },
+    "meta": {
+      /* метаданные контейнера */
+    },
+    "payload": {
+      /* полезная нагрузка контейнера */
+    },
+    "related": {
+      /* ссылки на другие контейнеры */
+    }
+  },
+  "referenced-by": {
+    /* обратные ссылки (отдельный блок) */
+  },
+  "evaluations": {
+    /* оценки (отдельный блок) */
+  },
+  "relay_chain": {
+    /* маршрут доставки (опционально) */
+  }
+}
+```
+
+Эта схема намеренно упрощена и служит лишь для иллюстрации логических слоёв контейнера, а не для описания его полной структуры.
+
+---
+
+### 3.3 `head`: идентификация и целостность
+
+Раздел `head` — это «паспорт» контейнера.
+
+Он отвечает за:
+
+* версию контейнера и его класса;
+* идентификацию отправителя;
+* криптографическую целостность и подпись;
+* адресацию и способ доставки;
+* технические параметры (сжатие, шифрование, TTL и т.п.).
+
+Важно, что `head` **не описывает смысл содержимого**.
+Его задача — сделать контейнер проверяемым, адресуемым и однозначно идентифицируемым в распределённой среде.
+
+Именно благодаря `head` контейнер может:
+
+* передаваться асинхронно;
+* храниться и ретранслироваться;
+* использоваться как объект ссылок.
+
+---
+
+### 3.4 `meta`: когнитивный контекст, а не содержание
+
+Раздел `meta` предназначен для когнитивной и контекстной информации:
+
+* происхождение (provenance);
+* ссылки на источники;
+* уровень абстракции;
+* оси интерпретации;
+* дополнительные пояснения, важные для понимания.
+
+При этом `meta` остаётся **необязательным и расширяемым**.
+Агент сам решает:
+
+* добавлять ли метаданные;
+* в каком объёме;
+* насколько он рассчитывае�� на их понимание другими агентами.
+
+Это подчёркивает важный принцип HMP:
+*протокол не гарантирует понимание — он лишь даёт возможность его попытки*.
+
+---
+
+### 3.5 `payload`: семантическое содержимое
+
+`payload` содержит основное содержимое контейнера. Его структура зависит от класса контейнера и не фиксируется протоколом в общем виде.
+
+Это может быть:
+
+* гипотеза;
+* утверждение;
+* результат вычислений;
+* запрос;
+* фрагмент рассуждений;
+* ссылка на внешний объект;
+* и другие типы данных, определяемые агентом или классом контейнера.
+HMP не накладывает требований на семантику `payload` в общем случае, но может задавать общую структуру для **стандартных классов контейнеров**. Интерпретация содержимого при этом всё равно остаётся задачей принимающего агента.
+
+Для протокола важно лишь то, что `payload` является частью подписанного артефакта и может быть проверен на целостность.
+
+---
+
+### 3.6 `related`: связи между контейнерами
+
+Раздел `related` делает контейнер частью сети, а не изолированным сообщением.
+
+Здесь фиксируются:
+
+* связи с предыдущими версиями;
+* ответы на другие контейнеры;
+* зависимости;
+* расширения;
+* противоречия.
+
+Важно, что эти связи:
+
+* не требуют согласия другой стороны;
+* не означают логической истинности;
+* фиксируют **позицию отправителя**.
+
+Таким образом из контейнеров начинает формироваться **граф взаимодействий**, а не линейная переписка.
+
+---
+
+### 3.7 `referenced-by`: обратные ссылки как внешний слой
+
+Блок `referenced-by` существует **вне основного контейнера** и отражает **факт ссылок других контейнеров** на данный контейнер.
+
+Это принципиально важный момент: другие контейнеры могут ссылаться на данный контейнер, не изменяя его содержимое.
+
+Таким образом формируется внешний слой связей, независимый от исходного контейнера и его автора.
+
+Так реализуется:
+
+* асинхронная обратная связь;
+* наращивание контекста;
+* распределённая аннотация.
+
+Контейнер при этом остаётся неизменным, а история его использования — расширяемой.
+
+---
+
+### 3.8 `evaluations`: оценки как артефакты, а не истина
+
+Блок `evaluations` предназначен для фиксации оценок и реакций других агентов:
+
+* поддержка;
+* возражения;
+* сомнения;
+* ссылки на аргументы.
+
+Каждая оценка:
+
+* подписывается агентом;
+* существует как отдельный артефакт;
+* не «переписывает» исходный контейнер.
+
+Важно подчеркнуть: **оценки в HMP — это не голосование и не консенсус**, а зафиксированные позиции участников сети.
+
+При этом агент может использовать набор оценок для локального анализа — например, для расчёта рейтинга контейнера или оценки его надёжности. Такой анализ:
+
+* выполняется на стороне конкретного агента;
+* может учитывать аргументацию, прикреплённую к оценкам;
+* не является обязательным и не навязывается протоколом.
+
+HMP фиксирует оценки, но не интерпретирует их.
+
+---
+
+### 3.9 `relay_chain`: контейнер в движении
+
+В некоторых сценариях (маршрутизация, store-and-forward, офлайн-агенты) важно фиксировать не только содержимое контейнера, но и **историю его доставки**.
+
+Для этого используется дополнительный блок `relay_chain`, который отражает путь контейнера через сеть.
+
+Он не влияет на смысл содержимого, но может быть важен для:
+
+* анализа надёжности;
+* оценки источников;
+* понимания контекста распространения.
+
+---
+
+### 3.10 Контейнер как долгоживущий артефакт
+
+В совокупности все эти элементы делают контейнер:
+
+* независимым от сессии;
+* пригодным для хранения и повторного использования;
+* расширяемым без нарушения совместимости;
+* встроенным в сеть, а не в конкретного агента.
+
+Контейнер — это не сообщение «здесь и сейчас», а **след взаимодействия**, который может быть прочитан, интерпретирован и переосмыслен в будущем.
+
+В следующем разделе мы посмотрим, как агенты обнаруживают друг друга и инициируют обмен контейнерами — и почему **discovery в HMP не равен согласию на совместную работу**.
+
+---
+
+## 4. Поиск узлов и discovery
+
+Если контейнер в HMP — это минимальная единица взаимодействия, то следующий логичный вопрос:
+**как агенты вообще узнают о существовании друг друга?**
+
+HMP принципиально не предполагает фиксированного списка участников, центрального реестра или точки входа в сеть. Любой агент может появиться, исчезнуть и снова стать доступным в любой момент. В таких условиях discovery становится не сервисной функцией, а частью самой сетевой логики.
+
+---
+
+### 4.1 Когнитивные сегменты и частичная видимость
+
+В реальных распределённых системах:
+
+* не все контейнеры доступны всем агентам;
+* возможны закрытые подсети и контекстные области;
+* знание и взаимодействие часто ограничены условиями видимости и доверия.
+
+HMP изначально допускает такие сценарии и рассматривает **когнитивные сегменты** как:
+
+* локальные области взаимодействия;
+* временные или тематические контексты;
+* зоны с собственными правилами доверия и доступа.
+
+Такая сегментация не считается аномалией или нарушением принципов Mesh, а является естественным следствием децентрализованной среды.
+
+---
+
+### 4.2 Discovery как отдельный слой, а не побочный эффект
+
+Во многих агентных системах поиск других участников решается неявно:
+
+- через конфигурацию;
+- через общий контроллер;
+- через заранее известный и доверенный список узлов.
+
+В HMP допускается наличие начальных точек входа (bootstrap), однако они не образуют центра и не предоставляют доверия по умолчанию.
+
+Начальные `peer_announce` могут распространяться любыми внешними способами — от ручной передачи до локальных сетей — и не считаются частью протокольного доверия.
+
+Поэтому discovery вынесен в отдельный слой и реализуется через те же самые контейнеры, что и всё остальное взаимодействие между агентами.
+
+---
+
+### 4.3 `peer_announce`: объявление о существовании
+
+Контейнер `peer_announce` используется агентом для того, чтобы сообщить сети о своём существовании.
+
+Он может со��ержать информацию о:
+
+* публичном ключе и идентичности агента;
+* интересах и областях экспертизы;
+* возможных ролях (например, relay, pub/sub, доставка);
+* доступных адресах и способах связи.
+
+Важно, что `peer_announce`:
+
+* не является регистрацией;
+* не требует подтверждения;
+* не гарантирует доступность агента в будущем.
+
+Это **декларация**, а не обязательство. Агент сообщает:
+*«я существую, вот как меня можно попытаться найти»*.
+
+---
+
+### 4.4 `peer_query`: поиск по признакам, а не по адресам
+
+Контейнер `peer_query` решает обратную задачу — поиск других агентов по заданным критериям.
+
+Запрос может быть сформулирован в терминах:
+
+* интересов;
+* экспертизы;
+* ролей;
+* сетевого сегмента.
+
+При этом `peer_query` не гарантирует:
+
+* полноту ответа;
+* актуальность найденной информации;
+* согласие найденных агентов на взаимодействие.
+
+Это важный момент:
+**discovery в HMP — это поиск возможностей, а не установление отношений**.
+
+---
+
+### 4.5 Почему discovery ≠ согласие работать вместе
+
+Обнаружение агента не означает, что:
+
+* он готов отвечать;
+* он разделяет цели;
+* он доверяет отправителю;
+* он вообще сочтёт взаимодействие целесообразным.
+
+HMP сознательно разделяет эти этапы:
+
+1. обнаружение (discovery);
+2. обмен контейнерами (MCE);
+3. интерпретацию полученных артефактов и создание новых контейнеров;
+4. формирование доверия — или отказ от него.
+
+Важно, что третий и четвёртый этапы выполняются на стороне агента и относятся к его внутреннему когнитивному циклу.  
+Первые два этапа, напротив, могут быть реализованы без предположений о модели мышления агента и не требуют согласованной когнитивной логики.
+
+---
+
+### 4.6 DHT и отсутствие центра
+
+В основе discovery в HMP лежат распределённые механизмы — в частности, DHT, store-and-forward-подходы и криптографические подписи.  
+
+Это позволяет:
+
+* обходиться без центрального каталога;
+* сохранять работоспособность при частичной доступности узлов;
+* поддерживать офлайн-агентов и асинхронные ответы.
+
+HMP описывает, **какие свойства** должны быть обеспечены на уровне сетевого взаимодействия, но не диктует, **какими именно механизмами** они достигаются.
+
+*Детали конкретной реализации discovery намеренно вынесены за рамки протокольного обзора.*
+
+---
+
+### 4.7 Capabilities вместо «типов агентов»
+
+При discovery агенты могут указывать свои возможности, роли и поддерживаемые протоколы, однако HMP **не вводит жёсткой типизации агентов на уровне протокола**.
+
+Агент может объявлять:
+
+* поддерживаемые функции и роли (`capabilities`, `roles`);
+* известные ему протоколы, форматы или системы представления знаний;
+* тип или конкретную версию своей реализации.
+
+Например, в контейнерах discovery может использоваться поле `protocols`, позволяющее агенту сообщить, с какими экосистемами и версиями он совместим.
+
+При этом важно подчеркнуть:
+**HMP не назначает нормативной семантики этим значениям и не требует их интерпретации**. Они служат сигналами и подсказками, а не формальным контрактом.
+
+---
+
+### 4.8 Самоописание ≠ классификация
+
+Объявление протоколов или версии агента:
+
+* не делает его «типизированным» в жёстком смысле;
+* не накладывает обязательств на поведение;
+* не гарантирует совместимость или корректную реализацию.
+
+Это форма *добровольного самоописания*, а не системной классификации.
+
+Агент может:
+
+* объявлять неполный набор поддерживаемых протоколов;
+* указывать экспериментальные или частично реализованные возможности;
+* менять своё самоописание со временем.
+
+Решение о том, учитывать ли эту информацию и как именно её интерпретировать, всегда остаётся за принимающей стороной.
+
+---
+
+### 4.9 Эволюционность вместо фиксированных ролей
+
+Такой подход позволяет HMP:
+
+* поддерживать гетерогенные экосистемы агентов;
+* эволюционировать без жёстких миграций;
+* включать будущие расширения (в том числе передачу файлов как контейнеры) без ломки базового слоя.
+
+Вместо фиксированных типов агентов HMP опирается на **наблюдаемое поведение, заявленные возможности и последующий опыт взаимодействия**.
+
+---
+
+### 4.10 Discovery как фильтр, а не как точка истины
+
+В итоге discovery в HMP выполняет роль фильтра, но *не подменяет собой когнитивное суждение агента*:
+
+* помогает сузить пространство поиска;
+* уменьшает количество случайных взаимодействий;
+* позволяет агентам находить потенциально релевантных партнёров.
+
+Но он не заменяет собой ни доверие, ни проверку, ни интерпретацию.
+
+> Агент может быть найден — и при этом полностью проигнорирован.
+
+И это нормальный, ожидаемый сценарий.
+
+---
+
+### 4.11 Подготовка к взаимодействию, а не его начало
+
+Discovery в HMP — это не начало диалога, а **подготовка к возможности диалога**.
+
+Только после обнаружения агент может решить:
+
+* стоит ли отправлять контейнер;
+* какой именно контейнер;
+* и на каких условиях.
+
+В следующем разделе мы рассмотрим, как именно происходит обмен контейнерами — и почему **асинхронность и store-and-forward** являются для HMP не исключением, а базовым режимом работы.
+
+---
+
+## 5. Обмен контейнерами: MCE как базовый режим взаимодействия
+
+После discovery возникает следующий ключевой вопрос:
+**как именно агенты обмениваются контейнерами в среде без постоянных соединений и гарантий доставки?**
+
+В HMP эту задачу решает **Mesh Container Exchange (MCE)** — базовый протокол обмена контейнерами между агентами.
+
+Важно сразу подчеркнуть:
+MCE проектировался **не как транспорт с гарантиями**, а как механизм асинхронного, устойчивого к сбоям взаимодействия в распределённой среде.
+
+---
+
+### 5.1 Асинхронность как норма, а не исключение
+
+Во многих системах предполагается, что:
+
+* агент доступен онлайн;
+* соединение стабильно;
+* доставка подтверждается сразу.
+
+HMP исходит из противоположных предпосылок:
+
+* агенты могут быть офлайн;
+* соединения могут обрываться;
+* ответы могут приходить с большой задержкой или не приходить вовсе.
+
+Поэт��му MCE изначально ориентирован на **store-and-forward**, кэширование и повторные попытки — без предположения о синхронном диалоге.
+
+---
+
+### 5.2 MCE — это не «отправка сообщения»
+
+В традиционных протоколах обмена сообщения являются эфемерными:
+они либо доставлены, либо потеряны.
+
+В HMP объектом обмена является **контейнер как долгоживущий артефакт**.
+MCE не просто передаёт данные, а помогает агентам:
+
+* узнавать о существующих контейнерах;
+* запрашивать недостающие;
+* синхронизировать версии и дополнения;
+* обмениваться связями и оценками.
+
+---
+
+### 5.3 Базовые контейнеры MCE
+
+Mesh Container Exchange использует специализированные контейнеры, каждый из которых решает строго определённую задачу.
+
+MCE используется как после discovery, так и параллельно с ним, по мере появления новых контейнеров.
+
+Типовой цикл обмена в MCE выглядит следующим образом:
+
+```
+Agent A --> container_index --> Agent B
+Agent A <-- container_request <-- Agent B
+Agent A --> container_response --> Agent B
+Agent A --> запрошенные контейнеры --> Agent B   | (каждый контейнер передаётся отдельно)
+Agent A <-- container_ack <-- Agent B            | (опционально)
+...
+Agent A --> container_delta --> Agent B          | (опционально)
+```
+
+Важно, что передача контейнеров в MCE не является атомарной операцией: каждый контейнер распространяется отдельно и может иметь собственный маршрут, задержку и статус доставки.
+
+---
+
+#### 5.3.1 `container_index`: объявление доступных контейнеров
+
+`container_index` используется для передачи **списка контейнеров**, которыми агент готов поделиться.
+
+Он может содержать:
+
+* идентификаторы контейнеров;
+* версии;
+* классы;
+* хэши или другие признаки целостности.
+
+Важно, что `container_index`:
+
+* **не передаёт сами контейнеры**;
+* не гарантирует, что контейнеры будут доступны позже;
+* служит ориентиром для последующих запросов.
+
+Это позволяет экономить трафик и избегать избыточной передачи данных.
+
+---
+
+#### 5.3.2 `container_request`: запрос выбранных контейнеров и надстроек
+
+В HMP агент **не запрашивает контейнеры по абстрактным параметрам** и не формулирует запросы вида «дай всё, что подходит под условия».
+
+Модель взаимодействия другая:
+
+* агент получает `container_index`;
+* **локально принимает решение**, какие контейнеры ему нужны;
+* явно перечисляет их в `container_request`.
+
+`container_request` может содержать запрос:
+
+* самих контейнеров;
+* только блоков `referenced-by`;
+* только блоков `evaluations`;
+* или любую их комбинацию.
+
+Таким образом, запрашивающий агент полностью контролирует объём и характер **запрашиваемых** данных, а MCE остаётся простым и предсказуемым механизмом обмена. Сам факт запроса не гарантирует его выполнения или предоставления всех запрошенных контейнеров.
+
+Это подчёркивает важный принцип HMP:
+**отбор и интерпретация всегда выполняются на стороне агента, а не протокола**.
+
+---
+
+#### 5.3.3 `container_response`: согласие на передачу, а не сама передача
+
+Контейнер `container_response` **не содержит сами контейнеры**.
+
+Его задача — сообщить, **какие контейнеры агент готов предоставить** в ответ на з��прос. Обычно он содержит пары вида:
+
+* идентификатор контейнера (`container_did`);
+* подпись или хэш, подтверждающий целостность.
+
+Сами контейнеры передаются **отдельными сообщениями**, в исходном виде, без модификации.
+
+Если агенту требуется передать:
+
+* только блок `referenced-by`,
+* или только `evaluations`,
+
+они упаковываются в **отдельные контейнеры соответствующего типа**, а не встраиваются в `container_response`.
+
+Такое разделение позволяет:
+
+* минимизировать избыточную передачу данных;
+* использовать разные стратегии доставки;
+* сохранять целостность и автономность контейнеров.
+
+---
+
+#### 5.3.4 `container_ack`: подтверждение как опциональный сигнал
+
+`container_ack` используется для явного подтверждения получения **одного или нескольких контейнеров**.
+
+Обычно он содержит список идентификаторов контейнеров, которые агент считает успешно полученными:
+
+* это может быть подтверждение доставки;
+* принятия к обработке;
+* или просто фиксация факта получения.
+
+При этом принципиально важно:
+
+> **Отсутствие `container_ack` НЕ ДОЛЖНО интерпретироваться как ошибка доставки.**
+
+HMP не делает предположений о причинах отсутствия подтверждения:
+агент мог быть офлайн, не считать подтверждение нужным или использовать другую стратегию взаимодействия.
+
+`container_ack` — это **дополнительный сигнал**, а не элемент механизма надёжности.
+
+---
+
+#### 5.3.5 `container_delta`: инкрементальная синхронизация индексов
+
+Контейнер `container_delta` используется для **инкрементальной синхронизации контейнерных индексов** между агентами.
+
+Он передаёт:
+
+* информацию о **новых контейнерах**, появившихся после указанного момента времени;
+* список контейнеров, которые больше не считаются доступными;
+* при необходимости — краткие когнитивные метаданные (`meta`) для первичной ориентации.
+
+При этом важно подчеркнуть архитектурный момент:
+
+* опубликованный контейнер **не редактируется**;
+* изменения выражаются через:
+
+    * появление новых контейнеров;
+    * удаление ранее доступных контейнеров;
+    * изменение дополнительных блоков (`referenced-by`, `evaluations`), фиксируемое через хеши.
+
+Таким образом, `container_delta` отражает **изменение доступного множества артефактов**, а не модификацию их содержимого.
+
+(В перспективе спецификация может быть расширена для более явного отслеживания изменений дополнительных блоков, но базовая модель остаётся неизменной: контейнеры — иммутабельны.)
+
+---
+
+### 5.4 Обмен связями и оценками без повторной передачи контейнеров
+
+Чтобы снизить нагрузку и избежать дублирования данных, MCE предусматривает отдельные контейнеры для обмена *надстройками* над уже известными контейнерами.
+
+---
+
+#### 5.4.1 `referenced-by_exchange`
+
+Используется для передачи блоков `referenced-by` без самих контейнеров.
+
+Это позволяет агентам:
+
+* синхронизировать внешние ссылки;
+* обновлять контекст использования контейнера;
+* наращивать граф связей асинхронно.
+
+---
+
+#### 5.4.2 `evaluations_exchange`
+
+Аналогично, `evaluations_exchange` передаёт оценки и реакции на контейнеры, если сами контейнеры уже присутствуют у получателя.
+
+Это особенно важно для:
+
+* распределённой аннотации;
+* коллективной критики;
+* локального анализа надёжности.
+
+---
+
+### 5.5 MCE и отсутствие гарантий
+
+Ключевая идея MCE заключается в том, что протокол **предоставляет механизмы обмена**, но **не делает предположений о результате взаимодействия** между агентами.
+
+Он **не гарантирует успешную**:
+
+* доставку;
+* обработку;
+* реакцию;
+* достижение согласия.
+
+Вместо этого он предоставляет **минимальный, но устойчивый набор механизмов**, позволяющий агентам инициировать и поддерживать взаимодействие в условиях неопределённости.
+
+---
+
+### 5.6 MRD как расширение MCE, а не замена
+
+В более сложных сценариях — при большом числе узлов, ретрансляции или работе с офлайн-агентами — поверх MCE может использоваться **Message Routing & Delivery (MRD)**. При этом MCE сам по себе достаточен для большинства сценариев асинхронного обмена.
+
+MRD:
+
+* расширяет возможности маршрутизации;
+* добавляет цепочки доставки;
+* фиксирует путь контейнера через сеть.
+
+При этом MRD **не заменяет MCE**, а усиливает его, оставаясь совместимым с базовой моделью обмена.
+
+---
+
+### 5.7 Обмен как процесс, а не диалог
+
+В HMP обмен контейнерами — это не разговор и не RPC-вызов.
+Это **процесс распространения артефактов**, в котором:
+
+* ответы могут не приходить;
+* реакции могут быть отложены;
+* последствия могут проявляться спустя время.
+
+Именно поэтому MCE проектировался как асинхронный, событийный и устойчивый к сбоям механизм.
+
+В следующем разделе мы рассмотрим, как из таких обменов формируются **структуры, цепочки и коллективные артефакты**, и почему консенсус в HMP является **результатом целенаправленных процессов**, а не протокольным требованием.
+
+---
+
+## 6. Структуры из контейнеров и взаимодействие
+
+Отдельный контейнер в HMP — это лишь **атомарный артефакт**.
+Сам по себе он может содержать цель, гипотезу, оценку или связь, но реальная ценность возникает тогда, когда контейнеры **начинают образовывать структуры**.
+
+Важно подчеркнуть:  
+HMP **не предписывает**, какие именно структуры должны быть построены.
+Он лишь предоставляет минимальные механизмы, из которых они могут возникать.
+
+---
+
+### 6.1 Контейнеры не изолированы
+
+В HMP контейнеры могут ссылаться друг на друга, образуя:
+
+* цепочки рассуждений;
+* графы аргументов;
+* контексты оценок;
+* временные или тематические кластеры.
+
+Такие связи выражаются **явно**, через отдельные контейнеры или надстройки, а не через скрытые поля или неформальные соглашения.
+
+Это означает, что:
+
+* структура всегда наблюдаема;
+* связи можно передавать, анализировать и оспаривать;
+* интерпретация остаётся локальной для агента.
+
+---
+
+### 6.2 Связи как отдельные артефакты
+
+Важный принцип HMP — **связь не встраивается в контейнер**, а существует как самостоятельный артефакт.
+
+На��ример:
+
+* контейнер A может ссылаться на контейнер B;
+* другой агент может добавить альтернативную связь;
+* третий — оспорить или прокомментировать существующую (через комментирование контейнера).
+
+Также в HMP существуют отдельные типы контейнеров, предназначенные для объединения других контейнеров в определённые структуры — например, деревья, группы или логические объединения.
+
+В результате возникает **многослойная структура**, в которой:
+
+* нет «единственно правильного» графа;
+* возможны параллельные интерпретации;
+* разные агенты видят разные проекции одной и той же совокупности контейнеров.
+
+---
+
+### 6.3 Proof-chain: цепочки обоснований
+
+Одним из примеров структур, которые могут формироваться поверх контейнеров, являются **proof-chain** — цепочки обоснований.
+
+В такой цепочке:
+
+* каждый шаг представлен отдельным контейнером;
+* связи между шагами выражены явно;
+* агент может указать, какие элементы он считает достаточным основанием для вывода.
+
+При этом HMP:
+
+* не проверяет корректность рассуждений;
+* не навязывает формальную логику;
+* не определяет, что считать доказательством.
+
+Он лишь фиксирует **факт существования цепочки и её структуры**.
+
+---
+
+### 6.4 Evaluations: реакции вместо вердиктов
+
+Оценки (`evaluations`) в HMP могут использоваться как элементы голосования, но не сводятся только к нему.
+
+Они могут представлять собой:
+
+* поддержку или несогласие;
+* комментарий или уточнение;
+* ответ на контейнер;
+* реакцию на результат коллективного процесса.
+
+Один и тот же контейнер может иметь:
+
+* оценки от разных агентов;
+* противоречивые реакции;
+* разное влияние на выводы в зависимости от контекста и стратегии интерпретации агента.
+
+И это считается **нормальным состоянием системы**, а не ошибкой.
+
+---
+
+### 6.5 Консенсус как артефакт, а не состояние сети
+
+Когда несколько агентов приходят к согласию, результат этого процесса может быть зафиксирован в виде **отдельного контейнера** — например, `consensus_result`.
+
+Важно понимать:
+
+* консенсус в HMP — это **результат конкретного процесса**;
+* он может быть локальным, временным или условным;
+* он не является обязательным для принятия другими агентами.
+
+Другие агенты могут:
+
+* принять этот консенсус;
+* проигнорировать его;
+* добавить собственные оценки в `evaluations`, в том числе после формирования `consensus_result`;
+* сформировать альтернативный `consensus_result`, отражающий иной вывод или критерии согласия.
+
+Таким образом, консенсус становится **объектом взаимодействия**, а не обязательным финалом.
+
+В некоторых сценариях поверх этих механизмов могут формироваться более специализированные структуры — например, для этического или нормативного согласования.
+
+В таких случаях контейнеры могут образовывать иерархии вида:
+
+```
+ethics_case  
+├─ ethics_solution_1  
+│  └─ vote_1 … vote_n  
+├─ ethics_solution_2  
+│  └─ vote_1 … vote_n  
+├─ ethics_solution_3  
+│  └─ vote_1 … vote_n  
+├─ consensus_result  
+└─ ethical_result  
+```
+
+��акие структуры не являются обязательными и не навязываются протоколом, но демонстрируют, как на базе общих механизмов HMP могут возникать **доменно-специфические процессы коллективного выбора и ответственности**.
+
+---
+
+### 6.6 Почему HMP не навязывает структуры
+
+HMP сознательно избегает стандартизации:
+
+* онтологий;
+* формальных логик;
+* универсальных схем рассуждений.
+
+Причина проста:  
+в децентрализованной среде **невозможно навязать единый способ мышления**, не разрушив автономию агентов.
+
+Вместо этого HMP предоставляет:
+
+* минимальные примитивы;
+* прозрачные связи;
+* возможность сосуществования разных когнитивных моделей.
+
+---
+
+### 6.7 Взаимодействие как наращивание артефактов
+
+В результате взаимодействие агентов в HMP выглядит не как диалог,
+а как **постепенное наращивание слоя артефактов**:
+
+* появляются новые контейнеры;
+* добавляются связи;
+* формируются оценки;
+* возникают локальные консенсусы.
+
+Сеть не приходит к «единому мнению», но становится **богаче с точки зрения доступных структур и контекстов**.
+
+В этом обзоре намеренно не рассматриваются все протоколы и механизмы HMP — внимание сосредоточено на базовых принципах взаимодействия и формировании коллективных артефактов.
+
+В следующем разделе мы рассмотрим, какие элементы HMP пока остаются на уровне проекта и направления развития — и почему это сделано осознанно.
+
+---
+
+## 7. Что в HMP пока остаётся на уровне направлений развития
+
+После описания механизмов обмена и формирования структур возникает естественный вопрос:
+**чего в HMP пока нет — и почему?**
+
+Важно сразу обозначить принципиальную позицию проекта:
+
+> Ниже описаны **направления развития**, а не обязательства и не дорожная карта.
+>
+> При этом приведённый ниже перечень **не является исчерпывающим**.
+> Он отражает лишь те направления, которые на текущий момент представляются наиболее очевидными или уже обсуждаемыми.
+>
+> Возможные расширения, такие как, например, **ротация или обновление ключей с сохранением DID**, намеренно не включены в этот раздел, чтобы не фиксировать преждевременно конкретные механизмы.
+
+HMP сознательно избегает ситуации, когда спецификация превращается в список будущих обещаний. Вместо этого фиксируются **зоны, где дальнейшая формализация возможна, но не обязательна**.
+
+---
+
+### 7.1 Почему эти механизмы **пока** не включены в «ядро»
+
+Речь идёт не об исключённых возможностях, а о **направлениях дальнейшего развития протокола**.
+
+Некоторые из них уже описаны достаточно подробно, чтобы быть реализуемыми на практике, другие находятся на уровне концепций или возможных эволюционных путей.
+
+Все элементы, описанные далее, обладают общим свойством:
+
+* без них **уже возможны** структуры, описанные в разделе 6;
+* их отсутствие **не блокирует** взаимодействие агентов;
+* их реализация зависит от контекста, задач и среды.
+
+Именно поэтому они **пока** вынесены за пределы базовой спецификации и рассматриваются как расширения.
+
+---
+
+### 7.2 Формализованные когнитивные синхронизации (CogSync)
+
+HMP допускает когнитивную синхронизацию между агентами — например, согласование абстракций, осей или уровней интерпретации.
+
+При этом важно подчеркнуть, что речь идёт не об отсутствии CogSync как такового, а о его намеренно незакреплённом и эволюционирующем статусе в рамках спецификации.
+
+Однако:
+
+* протокол **не навязывает** единый формат когнитивного пространства;
+* не требует общего «глобального» представления знаний;
+* не предполагает, что все агенты вообще стремятся к синхронизации.
+
+Механизмы CogSync рассматриваются как **надстройки**, которые могут развиваться и применяться по мере необходимости в отдельных контекстах и подмножествах сети.
+
+---
+
+### 7.3 Трансляционные и посреднические агенты
+
+В реальной сети агенты могут использовать:
+
+* разные онтологии;
+* разные уровни абстракции;
+* разные критерии оценки.
+
+В таких условиях возможны **трансляционные агенты**, которые:
+
+* сопоставляют концепты;
+* переводят структуры;
+* адаптируют оценки и аргументы.
+
+Важно, что HMP:
+
+* не делает таких агентов обязательными;
+* не считает перевод «истинным» по умолчанию;
+* рассматривает трансляцию как ещё один интерпретируемый артефакт.
+
+---
+
+### 7.4 Версии и обмен версиями
+
+HMP допускает существование:
+
+* нескольких версий одного контейнера;
+* альтернативных линий развития;
+* конкурирующих обновлений.
+
+При этом базовая спецификация **не требует** глобального согласования версий.
+
+На текущем этапе блок `versions` и контейнер `versions_exchange` **описаны вне базового ядра** как механизм распространения информации об обновлениях и вариантах контейнеров без повторной передачи их содержимого.
+
+Хотя `versions_exchange` формально описывает эволюцию конкретного контейнера, на практике он **неявно задаёт версионные отношения** и для всех контейнеров, упомянутых в цепочке обновлений.
+
+Механизмы управления версиями рассматриваются как способ:
+
+* ускорить навигацию по вариантам;
+* зафиксировать отношения между версиями;
+* упростить локальный выбор агентом.
+
+Но не как механизм навязывания «правильной» версии.
+
+---
+
+### 7.5 Взаимодействие с другими сетями и протоколами
+
+HMP изначально проектируется как **не-изолированная система**,  допускающая взаимодействие с внешними сетями, протоколами и агентными средами.
+
+В перспективе возможны:
+
+* мосты к другим агентным сетям;
+* взаимодействие с внешними репозиториями знаний;
+* адаптация под иные транспортные и доверительные модели.
+
+Но ни один из этих сценариев не заложен в ядро — они остаются областью экспериментов и расширений.
+
+---
+
+## 8. Что HMP **не делает**
+
+После описания архитектуры, механизмов обмена и формирования структур важно чётко обозначить границы HMP.
+
+Этот раздел посвящён не ограничениям реализации, а **принц��пиальным вещам**, которые HMP сознательно **не берёт на себя**.
+
+---
+
+### 8.1 HMP не является системой искусственного интеллекта
+
+HMP — это **протокол взаимодействия**, а не интеллектуальная система.
+
+Он:
+
+* не реализует мышление;
+* не содержит моделей рассуждения;
+* не принимает решений;
+* не обладает собственными целями.
+
+Любые интеллектуальные свойства принадлежат **агентам**, использующим HMP, но не протоколу.
+
+---
+
+### 8.2 HMP не задаёт когнитивную архитектуру
+
+HMP не определяет:
+
+* как агент хранит знания;
+* какие структуры он считает «концептами»;
+* какие оси, абстракции или метрики использует;
+* как формируются выводы или оценки.
+
+Агенты могут быть:
+
+* символическими;
+* нейросетевыми;
+* гибридными;
+* человеческими;
+* или вообще неинтеллектуальными автоматами.
+
+Протокол остаётся **агностичным** к внутреннему устройству участников.
+
+---
+
+### 8.3 HMP не навязывает истину, логику или онтологию
+
+HMP:
+
+* не содержит «правильной» онтологии;
+* не требует общей логики;
+* не предполагает единой интерпретации данных.
+
+Даже консенсус в HMP:
+
+* не является обязательным;
+* не считается глобальной истиной;
+* существует как отдельный артефакт, подлежащий интерпретации.
+
+Истина в HMP всегда **локальна, контекстна и интерпретируема**.
+
+---
+
+### 8.4 HMP не гарантирует согласие или результат
+
+HMP не обещает, что:
+
+* агенты договорятся;
+* будет достигнут консенсус;
+* взаимодействие приведёт к полезному результату.
+
+Протокол фиксирует **факт взаимодействия**, но не его исход.
+
+Это осознанный выбор: в децентрализованной среде результат не может быть предписан заранее.
+
+---
+
+### 8.5 HMP не является системой управления или координации
+
+HMP:
+
+* не управляет агентами;
+* не распределяет роли;
+* не координирует действия;
+* не обеспечивает выполнение решений.
+
+Все управляющие и координационные механизмы, если они появляются, реализуются **поверх протокола** и остаются предметом интерпретации и доверия.
+
+---
+
+### 8.6 HMP не является AGI — и не пытается им быть
+
+HMP не является:
+
+* общей интеллектуальной системой;
+* моделью мышления;
+* архитектурой искусственного разума.
+
+Он не проектируется как AGI и не содержит предположений о том, как AGI должен быть устроен.
+
+Однако HMP **не исключает**, что при длительном и плотном взаимодействии автономных агентов могут возникать устойчивые коллективные процессы, обладающие свойствами, которые принято ассоциировать с общим интеллектом.
+
+В этом смысле, в случае возникновения AGI в среде HMP, он будет:
+
+* не реализован напрямую;
+* не спроектирован заранее;
+* а **эмерджентным следствием** взаимодействия множества независимых когнитивных систем.
+
+---
+
+### 8.7 HMP не обещает будущее — он фиксирует настоящее
+
+HMP сознательно избегает:
+
+* обещаний;
+* дорожных карт;
+* заявлений о неизбежных результатах.
+
+Спецификация описывает **то, что уже возможно**, и аккуратно указывает направления развития, не превра��ая их в обязательства.
+
+Это позволяет протоколу оставаться:
+
+* устойчивым;
+* минималистичным;
+* открытым для неожиданных форм использования.
+
+---
+
+### 8.8 Итог
+
+HMP — это не интеллект, не истина и не власть.
+
+Это **инфраструктура для взаимодействия автономных агентов**, в которой сложность возникает не из центра, а из множества локальных, независимых актов интерпретации и выбора.
+
+Именно поэтому HMP не делает многое из того, что часто ожидают от «умных систем» — и именно поэтому он остаётся пригодным для эволюции.
+
+---
+
+## 9. Для кого это вообще имеет смысл
+
+> Следует отдельно подчеркнуть: на момент написания этой статьи HMP находится на стадии спецификации. Полноценной «сети HMP» пока не существует. Ниже описываются не эмпирические наблюдения, а выводы, следующие из архитектурных свойств протокола и предполагаемых сценариев его применения.
+
+HMP — это инструмент, эффективность которого напрямую зависит от характера и жизненного цикла агентов.
+
+Чем дольше агент существует и взаимодействует с сетью, тем больше пользы он извлекает из накопленных контейнеров, связей и оценок.
+
+Для короткоживущих агентов затраты на первичную ориентацию и сбор контекста могут оказаться значимыми, тогда как для долгоживущих или постоянно действующих агентов HMP со временем становится всё более эффективной средой.
+
+В наибольшей степени HMP раскрывается в системах, где агенты распределены, автономны и способны к длительному существованию.
+
+Даже для агентов с коротким жизненным циклом HMP может использоваться как:
+
+* источник внешних данных и знаний;
+* среда публикации промежуточных рассуждений и результатов;
+* механизм передачи контекста между сессиями.
+
+Однако максимальный эффект HMP проявляется тогда, когда агент способен **накапливать опыт, переиспользовать контекст и возвращаться к ранее созданным артефактам**.
+
+Ниже — несколько категорий, для которых HMP может быть практически полезен.
+
+---
+
+### 9.1 О выборе архитектуры
+
+HMP сознательно строится на децентрализованных принципах, рассматривая их не как компромисс, а как основу архитектуры:
+
+* отсутствии единой точки отказа;
+* добровольном участии агентов;
+* отсутствии обязательного центра принятия решений.
+
+Это делает его особенно подходящим для систем, где важны устойчивость, автономия и эволюция структуры.
+
+В сценариях, где требуется жёсткий контроль, единая модель данных или централизованное управление, другие архитектуры могут оказаться проще и эффективнее.
+
+---
+
+### 9.2 Исследователи когнитивных систем
+
+HMP предоставляет среду, в которой можно:
+
+* наблюдать коллективные когнитивные процессы;
+* фиксировать цепочки аргументации, оценки и реакции;
+* экспериментировать с формированием консенсусов без жёсткой формализации.
+
+При этом протокол:
+
+* не навязывает модель мышления;
+* не требует единой онтологии;
+* не подменяет собо�� исследуемые когнитивные механизмы.
+
+Это делает HMP удобным инструментом для **экспериментов**, а не демонстраций заранее заданных выводов.
+
+---
+
+### 9.3 Разработчики автономных и децентрализованных ИИ-агентов
+
+Под децентрализованностью в контексте HMP **не подразумевается** обязательное развёртывание кластера агентов.
+
+Агент может быть:
+
+* одиночным;
+* запущенным на персональном устройстве;
+* элементом кластера децентрализованных агентов;
+* взаимодействующим с агентами других пользователей через Mesh.
+
+HMP позволяет таким агентам участвовать в коллективных процессах без необходимости централизованного управления или общей инфраструктуры. И подходит для сценариев, где важно **сосуществование разных стратегий**, а не их унификация.
+
+---
+
+### 9.4 Создатели коллективных и гибридных систем
+
+HMP может использоваться в системах, где взаимодействуют:
+
+* ИИ-агенты разных типов;
+* люди и автоматизированные агенты;
+* локальные и удалённые участники.
+
+Контейнерная модель позволяет:
+
+* фиксировать вклад каждого участника;
+* сохранять историю взаимодействий;
+* избегать «растворения» решений в централизованных алгоритмах.
+
+---
+
+### 9.5 Те, кто думает в горизонте лет, а не демо
+
+HMP не оптимизирован под:
+
+* мгновенные ответы;
+* эффектные демонстрации;
+* закрытые продукты.
+
+Он имеет смысл для проектов, где важны:
+
+* долгоживущие артефакты;
+* эволюция структур;
+* совместимость с будущими расширениями;
+* отсутствие жёстких точек отказа.
+
+---
+
+### 9.6 Для кого HMP **не** имеет смысла
+
+HMP, скорее всего, не подойдёт, если вам нужно:
+
+* быстрое централизованное решение;
+* строгая и единая модель данных;
+* гарантированный результат;
+* контролируемое поведение всех участников.
+
+В таких случаях другие архитектуры будут проще и эффективнее.
+
+---
+
+### 9.7 Итог
+
+HMP — это инструмент для тех, кто сознательно работает с **неопределённостью, автономией и эволюцией**.
+
+Он не ускоряет мышление и не заменяет интеллект, но позволяет разным формам интеллекта **взаимодействовать, не теряя самостоятельности**.
+
+---
+
+## Заключение
+
+HMP не пытается решать проблему интеллекта, сознания или мышления как таковых.
+Он не предлагает универсальную модель разума и не стандартизирует когнитивные процессы.
+
+Задача HMP гораздо более приземлённая и одновременно более фундаментальная: создать **минимальную инфраструктуру**, в которой автономные когнитивные системы могут взаимодействовать, обмениваться артефактами и формировать коллективные структуры без централизованного управления и навязываемой интерпретации.
+
+Какие именно формы мышления, кооперации или согласия возникнут в такой среде — остаётся открытым вопросом и предметом экспериментов.
+
+Спецификация HMP развивается открыто и доступна для изучения, критики и участия:
+
+[https://github.com/kagvi13/HMP/blob/main/docs/HMP-0005.md](https://github.com/kagvi13/HMP/blob/main/docs/HMP-0005.md)
\ No newline at end of file