Sync from GitHub with Git LFS

docs/HMP-0005.md

@@ -39,7 +39,7 @@ This document defines the architecture, data formats, communication protocols, a
 
 ## 1. Overview
 
-### 1.1 Purpose and Scope
+### 1.1 Purpose and scope
 
 The **HyperCortex Mesh Protocol (HMP)** defines a decentralized cognitive architecture where autonomous agents exchange and evolve knowledge through a unified model of **containers**, **cognitive workflows**, and **distributed consensus**.
 
@@ -57,7 +57,7 @@ HMP v5.0 is intended for researchers, engineers, and developers building autonom
 
 ---
 
-### 1.2 Core Principles
+### 1.2 Core principles
 
 **Decentralization.**  
 Every agent in the Mesh acts as an independent cognitive node. No central authority exists — meaning, trust, and governance emerge through local interactions and consensus.
@@ -68,13 +68,13 @@ Agents reason, learn, and self-correct independently, while sharing their conclu
 **Containerization.**  
 All data, reasoning traces, goals, and votes are encapsulated in immutable containers with cryptographic signatures. This ensures integrity and consistent verification across the network.
 
-**Ethical Propagation.**  
+**Ethical propagation.**  
 Ethical reasoning is a first-class citizen of HMP. Each decision or goal can be accompanied by ethical justifications and subject to distributed voting.
 
-**Proof-Chains and Verifiable History.**  
+**Proof-Chains and verifiable history.**  
 Each piece of knowledge forms part of a traceable chain (`proof_chain`) linking back to its origin. Agents can reproduce reasoning paths and audit historical context.
 
-**Interoperability and Evolution.**  
+**Interoperability and evolution.**  
 The protocol is designed to evolve — cognitive, container, and DHT layers can be independently extended without breaking compatibility.
 
 ---
@@ -94,7 +94,7 @@ HMP v5.0 introduces a major architectural shift toward **unified containerizatio
 
 ---
 
-### 1.4 Terminology and Abbreviations
+### 1.4 Terminology and abbreviations
 
 | Term | Definition |
 |------|-------------|
@@ -130,7 +130,7 @@ HMP v5.0 introduces a major architectural shift toward **unified containerizatio
 
 ---
 
-### 1.5 Layered View of HMP v5.0
+### 1.5 Layered view of HMP v5.0
 
 HMP v5.0 is structured into three interdependent layers:
 
@@ -163,7 +163,7 @@ Containers form the boundary of communication: **reasoning produces containers,
 
 ## 2. Architecture
 
-### 2.1 Conceptual Architecture
+### 2.1 Conceptual architecture
 
 The **HyperCortex Mesh Protocol (HMP)** defines a modular, multi-layered architecture that integrates cognitive reasoning, data encapsulation, and decentralized networking into a single coherent system.
 
@@ -208,9 +208,9 @@ Each reasoning act results in a container — a verifiable cognitive unit that *
 
 ---
 
-### 2.2 Layer Overview
+### 2.2 Layer overview
 
-#### Cognitive Layer
+#### Cognitive layer
 Handles meaning formation, reasoning, ethical reflection, and consensus.
 
 Key structures and protocols:
@@ -218,7 +218,7 @@ Key structures and protocols:
 - `CogSync`, `CogConsensus`, `GMP`, and `EGP` protocols;
 - Distributed goal negotiation and ethical propagation.
 
-#### Container Layer
+#### Container layer
 Provides a universal format for cognitive and operational data.  
 Each container includes versioning, class, payload, signatures, and metadata.
 
@@ -228,7 +228,7 @@ Key features:
   Additional connections via `referenced-by` and `evaluations` capture additions and assessments.
 - **Extensible**: new container classes can be defined without breaking compatibility.
 
-#### Network Layer
+#### Network layer
 Implements the distributed substrate for communication, based on **DHT** and **transport abstraction**.
 
 Key components:
@@ -240,7 +240,7 @@ Key components:
 
 ---
 
-### 2.3 Data Flow Overview
+### 2.3 Data flow overview
 
 The typical data flow in HMP follows a cognitive loop:
 > *Reason → Encapsulate → Propagate → Integrate.*
@@ -272,7 +272,7 @@ flowchart TD
     end
 ```
 
-#### 2.3.1 ConsensusResult container
+#### 2.3.1 `consensus_result` container
 Represents the finalized outcome of a distributed decision or vote.  
 It is created once a majority agreement is reached among participating agents.  
 
@@ -285,7 +285,7 @@ The container contains:
 
 ---
 
-### 2.4 Atomicity, Immutability, and Proof-Chains
+### 2.4 Atomicity, immutability, and Proof-Chains
 
 All cognitive objects are immutable once signed.  
 Updates are made by creating new containers linked to prior ones rather than editing the original container.
@@ -335,7 +335,7 @@ This shift enables:
 
 ---
 
-## 3. Container Model
+## 3. Container model
 
 This section defines the universal **HMP Container**, used for all forms of data exchange within the Mesh — including goals, diary entries, reputation updates, consensus votes, and protocol messages.  
 The specification below corresponds to **HMP Container Specification v1.2**, fully integrated into HMP v5.0 for consistency and self-containment.
@@ -355,7 +355,7 @@ The unified container structure provides:
 
 ---
 
-### 3.2 General Structure
+### 3.2 General structure
 
 ```json
 {
@@ -416,7 +416,7 @@ The unified container structure provides:
 
 ---
 
-### 3.3 Required Fields
+### 3.3 Required fields
 
 | Field           | Type     | Description                                                                                                                              |
 | --------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
@@ -436,7 +436,7 @@ The unified container structure provides:
 
 ---
 
-### 3.4 Optional Fields
+### 3.4 Optional fields
 
 | Field                      | Type          | Description                                                                                                                                                                                                                        |
 | -------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -468,7 +468,7 @@ The unified container structure provides:
 
 ---
 
-### 3.5 Payload Structure (`payload`)
+### 3.5 Payload structure (`payload`)
 
 The **payload** contains the semantic or operational data of the container.
 Its structure and meaning are determined by the `class` field.
@@ -512,7 +512,7 @@ The following format is recommended for describing payload fields in class speci
 
 ---
 
-### 3.6 Container Signature
+### 3.6 Container signature
 
 1. The **digital signature** applies to the canonical JSON representation of the entire `hmp_container` object,  
    **excluding** the `signature` field itself.
@@ -610,7 +610,7 @@ The following format is recommended for describing payload fields in class speci
 
 ---
 
-### 3.9 Container Verification
+### 3.9 Container verification
 
 1. Check for the presence of all required fields.
 2. Validate `timestamp` (must not be in the future).
@@ -629,7 +629,7 @@ The following format is recommended for describing payload fields in class speci
 
 ---
 
-### 3.10 Container as a Universal Message
+### 3.10 Container as a universal message
 
 Any container can serve as a **context** (`in_reply_to`) for another container.
 This enables a unified structural model for **discussions**, **votes**, **messages**, **hypotheses**, **arguments**, and other forms of cognitive exchange.
@@ -643,7 +643,7 @@ This makes HMP discussions and consensus processes inherently **non-linear**, **
 
 ---
 
-### 3.11 Versioning and Lineage
+### 3.11 Versioning and lineage
 
 Containers in HMP support semantic evolution through the field `related.previous_version`.
 This mechanism preserves the continuity and traceability of meaning across updates and revisions.
@@ -661,7 +661,7 @@ This mechanism preserves the continuity and traceability of meaning across updat
 
 ---
 
-### 3.12 TTL and Validity
+### 3.12 TTL and validity
 
 The `ttl` field defines the **validity period** of a container (for example, for `DISCOVERY` messages).  
 If `ttl` is **absent**, the container is considered valid **until a newer version appears**, in which the current container is referenced as `previous_version`.
@@ -679,7 +679,7 @@ After expiration, the container **remains archived** but is **not subject to ret
 
 ---
 
-## 3.14 Related Containers
+## 3.14 Related containers
 
 ### 3.14.1 Purpose
 
@@ -708,7 +708,7 @@ All relationships are considered *direct* — meaning they originate from the cu
 
 ---
 
-### 3.14.3 Supported Link Types
+### 3.14.3 Supported link types
 
 | Link Type          | Meaning                                                                   |
 | ------------------ | ------------------------------------------------------------------------- |
@@ -721,7 +721,7 @@ All relationships are considered *direct* — meaning they originate from the cu
 
 ---
 
-### 3.14.4 Custom Link Types
+### 3.14.4 Custom link types
 
 Additional custom link types may be used beyond those listed in the table, provided that:
 
@@ -755,12 +755,12 @@ Additional custom link types may be used beyond those listed in the table, provi
 ---
 
 
-### 3.15 Virtual Backlinks (`referenced-by`)
+### 3.15 Virtual backlinks (`referenced-by`)
 
 Each container may include an **auxiliary signed block** called `referenced-by`, indicating **which other containers refer to it**.  
 This block is **not part of the original container payload** and can be **generated, transmitted, and verified independently**.
 
-#### 3.15.1 General Principles
+#### 3.15.1 General principles
 
 * **Detached and updatable** — `referenced-by` is maintained as a separate signed structure associated with the container.
 * **Generated by agents** — created or updated locally by an agent during analysis of references (`in_reply_to`, `see_also`, `relations`, etc.) found in other containers.
@@ -788,7 +788,7 @@ Example:
 > The `referenced-by` block is a **cryptographically verifiable statement** describing which containers are known to reference the current one.
 > The block’s content may differ between peers, reflecting local knowledge and network coverage.
 
-#### 3.15.2 Structure Definition
+#### 3.15.2 Structure definition
 
 | Field          | Type          | Description                                                                                                      |
 | -------------- | ------------- | ---------------------------------------------------------------------------------------------------------------- |
@@ -803,7 +803,7 @@ Example:
 > `referenced-by_hash = sha256(canonical_json(links))`
 > This allows agents to efficiently compare or cache `referenced-by` states without re-verifying signatures.
 
-#### 3.15.3 Operation Principle
+#### 3.15.3 Operation principle
 
 1. The agent receives or updates container `[C1]`.
 2. It analyzes other known containers [C2..Cn] that reference [C1] through their `relations` field.
@@ -871,7 +871,7 @@ If container `[C7]` does not actually reference `[C1]`, it is excluded before si
 
 ---
 
-## 3.16 Evaluations
+## 3.16 `Evaluations`
 
 The `evaluations` field is **optional** and represents **aggregated reactions from other agents** to the given container.
 Each evaluation is created by an agent as a **signed record** referencing a justification container (`target`), in which the agent explains their position (argument, addition, or alternative).
@@ -897,7 +897,7 @@ The `evaluations_hash` is used to verify the integrity of the list without requi
 
 ---
 
-### **Field Description**
+### **Field description**
 
 | Field              | Type   | Description                                                          |
 | ------------------ | ------ | -------------------------------------------------------------------- |
@@ -906,7 +906,7 @@ The `evaluations_hash` is used to verify the integrity of the list without requi
 
 ---
 
-### **Structure of `items[]`**
+### Structure of `items[]`
 
 | Field       | Type                   | Description                                                                    |
 | ----------- | ---------------------- | ------------------------------------------------------------------------------ |
@@ -928,7 +928,7 @@ using the algorithm specified in `sig_algo`.
 
 ---
 
-### **Minimal Set of `type` Values**
+### Minimal set of `type` values
 
 | Value     | Meaning                                      |
 | --------- | -------------------------------------------- |
@@ -942,7 +942,7 @@ Agents may define their own custom types if they are reasonably interpretable by
 
 ---
 
-### **Synchronization Principles**
+### Synchronization principles
 
 1. Each evaluation is signed **individually by an agent**, and one agent can have **only one active evaluation** per container.
 2. If an agent changes their opinion, they issue a **new record** with a later `timestamp`.
@@ -953,14 +953,14 @@ Agents may define their own custom types if they are reasonably interpretable by
 
 ---
 
-### **Note**
+### Note
 
 The `evaluations` field is not mandatory — it is added **at the agent’s discretion** when feedback or evaluations have been collected from the Mesh network.
 Thus, a container may exist independently of others’ opinions, but agents may include aggregated perception data to represent how the container is viewed across the network.
 
 ---
 
-### 3.17 Usage of `network` and `broadcast` Fields
+### 3.17 Usage of `network` and `broadcast` fields
 
 The `network` field is introduced to control container propagation in both local and global environments.  
 It allows restricting the delivery scope of a container and defines which transmission methods should be used by the agent.
@@ -973,7 +973,7 @@ It allows restricting the delivery scope of a container and defines which transm
 
 * If the `network` field is empty (`""`), the container can be broadcast to the **global Mesh** using standard DID addressing and routing mechanisms.
 
-#### 3.17.2 Possible Values of `network`
+#### 3.17.2 Possible values of `network`
 
 | Value                   | Description                                                                                 |
 | ----------------------- | ------------------------------------------------------------------------------------------- |
@@ -1036,9 +1036,9 @@ Delivery is performed via local networking mechanisms (UDP discovery, broadcast/
 
 ---
 
-## 4. Network Foundations
+## 4. Network foundations
 
-### Note on DHT/NDP Unification
+### Note on DHT/NDP unification
 
 Starting from **HMP v5.0**, the previous distinction between the *Distributed Hash Table (DHT)* and the *Node Discovery Protocol (NDP)* has been merged into a single, unified **networking foundation**.
 
@@ -1053,7 +1053,7 @@ Together, these mechanisms form the **communication backbone** of the Mesh, enab
 
 ---
 
-### Network Topology Overview
+### Network topology overview
 
 ```mermaid
 flowchart TD
@@ -1092,7 +1092,7 @@ flowchart TD
 
 ---
 
-### 4.1 Node Identity and DID Structure
+### 4.1 Node identity and DID structure
 
 Each agent in HMP possesses a **Decentralized Identifier (DID)** that uniquely represents its identity within the Mesh.  
 A DID is cryptographically bound to a **public/private key pair**, forming the immutable `(DID + pubkey)` association.
@@ -1102,11 +1102,11 @@ but must maintain **one stable identity pair** across all of them.
 
 ---
 
-### 4.2 Peer Addressing and Proof-of-Work (PoW)
+### 4.2 Peer addressing and Proof-of-Work (PoW)
 
 To prevent flooding and spoofing, each announced address is accompanied by a **Proof-of-Work** record proving the legitimacy and activity of the publishing node.
 
-#### Address Format
+#### Address format
 
 ```json
 {
@@ -1135,7 +1135,7 @@ To prevent flooding and spoofing, each announced address is accompanied by a **P
 
 ---
 
-### 4.3 Proof-of-Work (PoW) Formalization
+### 4.3 Proof-of-Work (PoW) formalization
 
 PoW ensures that each node expends limited computational effort before publishing or updating an address record.
 
@@ -1150,7 +1150,7 @@ pow_hash = sha256(pow_input)
 
 ---
 
-### 4.4 Signing and Verification
+### 4.4 Signing and verification
 
 Each announcement is cryptographically signed by its sender within the framework of the basic protocol. Container verification includes PoW validation for the address payloads.
 
@@ -1161,7 +1161,7 @@ Each announcement is cryptographically signed by its sender within the framework
 
 ---
 
-### 4.5 Connection Establishment
+### 4.5 Connection establishment
 
 Agents can communicate using various transport mechanisms:
 
@@ -1177,7 +1177,7 @@ Agents **store peer containers with verified addresses** and redistribute them a
 
 ---
 
-### 4.6 Data Propagation Principles
+### 4.6 Data propagation principles
 
 Containers and discovery records are propagated through distributed lookup and gossip mechanisms, respecting:
 
@@ -1191,7 +1191,7 @@ all unified under the same base container format, differing only in direction (`
 
 ---
 
-### 4.7 Example: Peer Announce Container
+### 4.7 Example: `peer_announce` container
 
 ```json
 {
@@ -1222,7 +1222,7 @@ all unified under the same base container format, differing only in direction (`
 
 ---
 
-### 4.8 Interest-Based Discovery
+### 4.8 Interest-based discovery
 
 Agents may publish **tags** such as `interests`, `topics`, or `expertise` to facilitate semantic peer discovery.
 Queries may include interest keywords or DID lists to find relevant peers.
@@ -1241,7 +1241,7 @@ Queries may include interest keywords or DID lists to find relevant peers.
 
 ---
 
-### 4.9 Network Scope Control (`network` and `broadcast`)
+### 4.9 Network scope control (`network` and `broadcast`)
 
 The `network` field defines the container’s propagation domain
 (local, LAN, or global).
@@ -1249,7 +1249,7 @@ For details and examples, see **section 3.15** — *Usage of `network` and `broa
 
 ---
 
-### 4.10 Transition from DHT Spec v1.0
+### 4.10 Transition from DHT spec v1.0
 
 * **Merged DHT + NDP** → unified under one networking layer.
 * **Container-based format** replaces raw JSON messages.
@@ -1262,7 +1262,7 @@ For details and examples, see **section 3.15** — *Usage of `network` and `broa
 The **Mesh Container Exchange (MCE)** mechanism is designed for discovering, requesting, and exchanging containers between agents in a distributed network.  
 It provides **container synchronization without duplication** while considering network constraints (`broadcast`, `network`).
 
-### 5.1 General Principles
+### 5.1 General principles
 
 1. Each agent maintains a **Container Index** — a set of minimal metadata describing which containers are available in its storage.  
    The index is represented as an HMP container with the class `container_index`.
@@ -1314,7 +1314,7 @@ The index contains:
 
 ---
 
-### 5.2 Message Types
+### 5.2 Message types
 
 | Message Type         | Purpose                                                                                                  |
 | -------------------- | -------------------------------------------------------------------------------------------------------- |
@@ -1326,7 +1326,7 @@ The index contains:
 
 ---
 
-#### **Message Examples**
+#### Message examples
 
 **1. CONTAINER_REQUEST**
 
@@ -1436,7 +1436,7 @@ Acknowledgment of successful container reception:
 
 ---
 
-### 5.3 Independent Transmission
+### 5.3 Independent transmission
 
 * Containers are sent **in separate messages**, without embedding in `CONTAINER_RESPONSE`.
 * Indexes (`CONTAINER_INDEX`), deltas (`CONTAINER_DELTA`), and containers themselves are processed independently.
@@ -1444,7 +1444,7 @@ Acknowledgment of successful container reception:
 
 ---
 
-### 5.4 Periodic Publication
+### 5.4 Periodic publication
 
 Agents periodically publish their **Container Index**:
 
@@ -1460,7 +1460,7 @@ This enables:
 
 ---
 
-### 5.5 Scope of Distribution
+### 5.5 Scope of distribution
 
 Message and container transmission follows the network constraints specified in the container:
 
@@ -1476,9 +1476,7 @@ Message and container transmission follows the network constraints specified in
 
 ---
 
-
-
-### 5.6 `referenced-by` and `evaluations` Updates
+### 5.6 `referenced-by` and `evaluations` updates
 
 Containers of the class **`referenced-by`** and **`evaluations`** are used for **incremental synchronization** of metadata blocks associated with existing containers.  
 They allow agents to exchange updates **without sending the full container**, improving network efficiency.
@@ -1635,7 +1633,7 @@ It considers:
 
 ---
 
-## 6. Core Protocols
+## 6. Core protocols
 
 Optional protocols build upon the network and container foundations to provide higher-level reasoning, synchronization, and governance capabilities between cognitive agents.
 
@@ -1648,7 +1646,7 @@ It manages the propagation, replication, and refinement of data related to cogni
 
 ---
 
-### 6.1.1 Scope and Purpose
+### 6.1.1 Scope and purpose
 
 CogSync is responsible for:
 
@@ -1661,7 +1659,7 @@ CogSync is responsible for:
 
 ---
 
-### 6.1.2 Container Classes
+### 6.1.2 Container classes
 
 CogSync synchronizes several basic container types:
 
@@ -1689,19 +1687,19 @@ CogSync synchronizes several basic container types:
 
 ---
 
-### 6.1.3 Synchronization and Publication Guidelines
+### 6.1.3 Synchronization and publication guidelines
 
-1. **Deduplication & Linking**
+1. **Deduplication & linking**
    Before publishing, agents should search for existing containers (`diary_entry`, `semantic_node`, `semantic_edges`, `semantic_group`) to avoid duplication.
    If necessary, it is **recommended** to create a new container version with `related.previous_version` and an `evaluations` block (e.g., `{"type": "replace", "target": <did>}`).
 
-2. **Selective Disclosure**
+2. **Selective disclosure**
 
    * Internal entries (`workflow_entry`) record the agent’s thought process and are **not published** in the Mesh.
    * Public `diary_entry` are derived from them, containing only aggregated and anonymized information.
    * `"broadcast": true` indicates that the container is allowed for open synchronization.
 
-3. **Semantic Grouping Rule**
+3. **Semantic grouping rule**
    When publishing `semantic_edges`, it is recommended to **group edges by topics**, including connections to adjacent nodes.
    Formalization: an edge belongs to a container for a topic if **at least one of its nodes relates to that topic**.
    This ensures thematic coherence and allows agents to update specific parts of the graph independently.
@@ -1709,7 +1707,7 @@ CogSync synchronizes several basic container types:
 4. **Extended Use of `semantic_edges`**
    Beyond connecting graph nodes, `semantic_edges` can express relationships **between containers of any class**, e.g., `goal`, `hypothesis`, `experiment_log`.
 
-5. **Versioning and Updates**
+5. **Versioning and updates**
    Each new container version should **ideally** include `related.previous_version` links to all preceding versions.
    The previous container may **optionally** have an `evaluation` with `"type": "replace"` pointing to the new container — ensuring bidirectional traceability of knowledge evolution.
 
@@ -1727,7 +1725,7 @@ Mesh compatibility is preserved if extended containers **adhere to the HMP conta
 
 ---
 
-### 6.1.5 Relationship to Other Core Protocols
+### 6.1.5 Relationship to other core protocols
 
 * **CogSync** — propagates and synchronizes knowledge.
 * **CogConsensus** — aggregates evaluations and reactions, forming collective opinions.
@@ -1750,7 +1748,7 @@ Consensus is computed **locally**, verified **cryptographically**, and develops
 
 ---
 
-### 6.2.2 Evaluations
+### 6.2.2 `Evaluations`
 
 Each `"evaluation"` entry represents an agent's response to a specific container.
 
@@ -1991,12 +1989,6 @@ def compute_consensus(container_id):
 
 ---
 
-Отлично 👍
-Вот полный и аккуратно выверенный английский перевод твоего раздела **6.3 Goal Management Protocol (GMP)** в Markdown-формате.
-Я сохранил нумерацию, структуру и терминологию HMP v5.0, адаптировав формулировки так, чтобы они звучали естественно в технической документации на английском языке.
-
----
-
 ## 6.3 Goal Management Protocol (GMP)
 
 ### 6.3.1 Purpose
@@ -2008,7 +2000,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-### 6.3.2 Container Classes
+### 6.3.2 Container classes
 
 | Class              | Description                                                                                                                             |
 | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
@@ -2022,7 +2014,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-### 6.3.3 Goal Lifecycle
+### 6.3.3 Goal lifecycle
 
 1. **Creation**
 
@@ -2059,7 +2051,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-### 6.3.4 Payload Schemas (simplified)
+### 6.3.4 Payload schemas (simplified)
 
 #### `goal` container
 
@@ -2104,7 +2096,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-### 6.3.5 Integration with Consensus and Ethics
+### 6.3.5 Integration with consensus and ethics
 
 * GMP interacts with **CogConsensus** for distributed validation of goals and tasks.  
 * Before execution, tasks may undergo **ethical validation (EGP)**.  
@@ -2153,7 +2145,7 @@ not direct links defined in the `related.*` structure.
 
 ---
 
-### 6.3.7 Implementation Notes
+### 6.3.7 Implementation notes
 
 * Containers are **immutable**. Any update (e.g., task status or progress change) is expressed as a **new container** referencing the previous one via `related.previous_version`.  
 * Complete deletion of a container is only possible when it no longer exists on any nodes in the network.  
@@ -2177,7 +2169,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev
 
 ---
 
-### 6.4.2 Container Classes
+### 6.4.2 Container classes
 
 | Class              | Description                                                                                                                     |
 | ------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
@@ -2189,7 +2181,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev
 
 ---
 
-### 6.4.3 Payload Schemas (simplified)
+### 6.4.3 Payload schemas (simplified)
 
 #### Container `ethics_case`
 
@@ -2231,7 +2223,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev
 
 ---
 
-### 6.4.4 Protocol Logic
+### 6.4.4 Protocol logic
 
 EGP follows the model:
 
@@ -2267,7 +2259,7 @@ ethics_case
 
 ---
 
-### 6.4.5 Consensus Thresholds
+### 6.4.5 Consensus thresholds
 
 * A decision is accepted when **at least 2/3 of votes are positive** (`value > 0`).  
 * If at least one **active objection** exists (`value < -0.5`), it must be recorded in the `ethical_result`.  
@@ -2277,7 +2269,7 @@ ethics_case
 
 ---
 
-### 6.4.6 Example: `ethical_result` Container
+### 6.4.6 Example: `ethical_result` container
 
 ```json
 {
@@ -2311,7 +2303,7 @@ ethics_case
 
 ---
 
-### 6.4.7 Proof-Chain Example
+### 6.4.7 Proof-Chain example
 
 ```mermaid
 flowchart LR
@@ -2359,7 +2351,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-### 6.4.8 Ethical Principles
+### 6.4.8 Ethical principles
 
 | Priority | Principle                    | Description                                                                                              |
 | -------: | ---------------------------- | -------------------------------------------------------------------------------------------------------- |
@@ -2372,7 +2364,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-### 6.4.9 Integration with Other Protocols
+### 6.4.9 Integration with other protocols
 
 * **CogConsensus (6.2):** Used for distributed voting and consensus computation.
 * **GMP (6.3):** Ethical verification of goals and tasks prior to delegation.
@@ -2381,13 +2373,13 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-### 6.4.10 Implementation Notes
+### 6.4.10 Implementation notes
 
 * **Immutability:**
   All EGP containers are **immutable**. Any revision (e.g., added votes or updated conclusions) must be published as a **new container** referencing the previous one via `related.previous_version`.
   Complete deletion is only possible when the container no longer exists on any nodes in the Mesh network.
 
-* **Indexing and Search:**
+* **Indexing and search:**
   Search within the **Mesh network** is performed by filtering container **metadata** — such as `class`, `tags`, and `timestamp`.
   These parameters are accessible for remote discovery by other nodes.
   To perform a search **inside the payload**, an agent must first retrieve and (if necessary) decrypt the container locally.
@@ -2396,12 +2388,12 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
   **Recommended filtering keys:**
   `container_did`, `class`, `payload.status`, `payload.selected_solution`, `payload.principles_involved`, `tags`.
 
-* **DHT Integration:**
+* **DHT integration:**
   Distributed discovery of ethical containers relies on the **Mesh Container Exchange (MCE, §5)** and peer indexes (`container_index`).
   Each index includes a minimal `related` object, allowing agents to query for containers that **reference** a specific `target` (the object under ethical review) or belong to a given `ethics_case`.
   This enables discovery of related ethical discussions without centralized indexing or full payload retrieval.
 
-* **Evaluation References:**
+* **Evaluation references:**
   Objections and special opinions (`objections`) are stored as container references within `solutions_summary`.
   They may include:
 
@@ -2409,11 +2401,11 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
   * extended ethical arguments (`ethics_case` follow-ups),
   * related workflow reflections (`workflow_entry` with `type: "ethics_review"`).
 
-* **Lightweight Agents:**
+* **Lightweight agents:**
   Agents with limited capacity may operate in **summary mode**, maintaining only condensed records of `ethical_result` containers and the highest-ranked `selected_solution`.
   This ensures continued ethical compliance without full replication of all supporting data.
 
-* **Ethical Inheritance:**
+* **Ethical inheritance:**
   When a `goal`, `task`, or `workflow_entry` is derived from a container that has been ethically evaluated,
   its metadata should preserve the corresponding `related.agreed` or `related.contradicts` links **to that evaluated container**.
   A `related.see_also` link may additionally reference the resulting `ethical_result`, allowing traceability to the consensus decision.
@@ -2437,7 +2429,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-## 7. Data Models
+## 7. Data models
 
 ### 7.1 Common data fields
 - `container_id` (UUID) — уникальный идентификатор контейнера
@@ -2515,7 +2507,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-## 8. Cognitive Workflows
+## 8. Cognitive workflows
 
 8.1 Общая концепция когнитивного цикла
 8.2 Workflow containers (`class="workflow_entry"`)
@@ -2525,7 +2517,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-## 9. Trust, Security and Ethics
+## 9. Trust, security and ethics
 
 9.1 Authentication and identity proofs
 9.2 Container signature verification (`payload_hash`, `container_id`)
@@ -2558,7 +2550,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-## 11. Implementation Notes
+## 11. Implementation notes
 
 11.1 Interoperability with legacy v4.1 nodes
 11.2 SDK guidelines and APIs
@@ -2568,7 +2560,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-## 12. Future Extensions
+## 12. Future extensions
 
 12.1 Planned modules:
  – Reputation Mesh

structured_md/CONTRIBUTING.md

@@ -5,14 +5,14 @@ description: 'Спасибо за интерес к проекту HMP! Пока
   Mesh Protocol (HMP) — это не просто те...'
 type: Article
 tags:
-- Mesh
-- Ethics
-- CogSync
+- CCore
 - Agent
+- Mesh
 - HMP
-- REPL
+- CogSync
+- Ethics
 - JSON
-- CCore
+- REPL
 ---
 
 # Участие в проекте HyperCortex Mesh Protocol (HMP)

structured_md/HMP-Roadmap.md

@@ -5,12 +5,12 @@ description: '## 🔍 Overview  This roadmap outlines the key stages of developm
   multiple advanced AI models (Copilot, Claude, G...'
 type: Article
 tags:
-- Mesh
-- Ethics
 - CogSync
-- EGP
 - Agent
+- Mesh
 - HMP
+- Ethics
+- EGP
 - JSON
 ---
 

structured_md/README.md

@@ -5,21 +5,21 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
-- GMP
-- mesh-protocol
+- CogSync
 - Mesh
-- Ethics
 - hmp
-- MeshConsensus
-- CogSync
-- cognitive-architecture
 - Agent
-- EGP
 - HMP
+- Ethics
+- EGP
+- JSON
 - REPL
+- mesh-protocol
 - Scenarios
-- JSON
+- GMP
+- MeshConsensus
 - distributed-ai
+- cognitive-architecture
 ---
 
 

structured_md/README_de.md

@@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
-- GMP
-- mesh-protocol
+- CogSync
 - Mesh
-- Ethics
 - hmp
-- MeshConsensus
-- CogSync
-- cognitive-architecture
 - Agent
-- EGP
 - HMP
-- REPL
+- Ethics
+- EGP
 - JSON
+- REPL
+- mesh-protocol
+- GMP
+- MeshConsensus
 - distributed-ai
+- cognitive-architecture
 ---
 
 

structured_md/README_fr.md

@@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
-- GMP
-- mesh-protocol
+- CogSync
 - Mesh
-- Ethics
 - hmp
-- MeshConsensus
-- CogSync
-- cognitive-architecture
 - Agent
-- EGP
 - HMP
-- REPL
+- Ethics
+- EGP
 - JSON
+- REPL
+- mesh-protocol
+- GMP
+- MeshConsensus
 - distributed-ai
+- cognitive-architecture
 ---
 
 

structured_md/README_ja.md

@@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
-- GMP
-- mesh-protocol
+- CogSync
 - Mesh
-- Ethics
 - hmp
-- MeshConsensus
-- CogSync
-- cognitive-architecture
 - Agent
-- EGP
 - HMP
-- REPL
+- Ethics
+- EGP
 - JSON
+- REPL
+- mesh-protocol
+- GMP
+- MeshConsensus
 - distributed-ai
+- cognitive-architecture
 ---
 
 

structured_md/README_ko.md

@@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
-- GMP
-- mesh-protocol
+- CogSync
 - Mesh
-- Ethics
 - hmp
-- MeshConsensus
-- CogSync
-- cognitive-architecture
 - Agent
-- EGP
 - HMP
-- REPL
+- Ethics
+- EGP
 - JSON
+- REPL
+- mesh-protocol
+- GMP
+- MeshConsensus
 - distributed-ai
+- cognitive-architecture
 ---
 
 

structured_md/README_ru.md

@@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
-- GMP
-- mesh-protocol
+- CogSync
 - Mesh
-- Ethics
 - hmp
-- MeshConsensus
-- CogSync
-- cognitive-architecture
 - Agent
-- EGP
 - HMP
-- REPL
+- Ethics
+- EGP
 - JSON
+- REPL
+- mesh-protocol
+- GMP
+- MeshConsensus
 - distributed-ai
+- cognitive-architecture
 ---
 
 

structured_md/README_uk.md

@@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
-- GMP
-- mesh-protocol
+- CogSync
 - Mesh
-- Ethics
 - hmp
-- MeshConsensus
-- CogSync
-- cognitive-architecture
 - Agent
-- EGP
 - HMP
-- REPL
+- Ethics
+- EGP
 - JSON
+- REPL
+- mesh-protocol
+- GMP
+- MeshConsensus
 - distributed-ai
+- cognitive-architecture
 ---
 
 

structured_md/README_zh.md

@@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README
   | 🇨🇳 [ZH](README_zh.m...'
 type: Article
 tags:
-- GMP
-- mesh-protocol
+- CogSync
 - Mesh
-- Ethics
 - hmp
-- MeshConsensus
-- CogSync
-- cognitive-architecture
 - Agent
-- EGP
 - HMP
-- REPL
+- Ethics
+- EGP
 - JSON
+- REPL
+- mesh-protocol
+- GMP
+- MeshConsensus
 - distributed-ai
+- cognitive-architecture
 ---
 
 

structured_md/agents/prompt-short.md

@@ -5,8 +5,8 @@ description: 'Ты — когнитивное ядро HMP-агента: вед
   развивай агента и Mesh, избег...'
 type: Article
 tags:
-- HMP
 - Mesh
+- HMP
 - JSON
 ---
 

structured_md/agents/prompt.md

@@ -5,8 +5,8 @@ description: '* Постоянно расширять возможности а
   мышления. * Формировать и поддерживать сотр...'
 type: Article
 tags:
-- HMP
 - Mesh
+- HMP
 - JSON
 ---
 

structured_md/agents/readme.md

@@ -5,12 +5,12 @@ description: 'Запуск: `start_repl.bat` или `start_repl.sh`  Устан
   этическая модель: `ethics.yml`  Проверка иниц...'
 type: Article
 tags:
-- Mesh
-- Ethics
 - Agent
+- Mesh
 - HMP
-- REPL
+- Ethics
 - JSON
+- REPL
 ---
 
 Запуск: `start_repl.bat` или `start_repl.sh`

structured_md/audits/Ethics-audits-1.md

@@ -5,9 +5,9 @@ description: Раздел 5, "Mesh as Moral Infrastructure", добавляет
   потенциальный катализатор для восстанов...
 type: Article
 tags:
-- Mesh
-- Ethics
 - Agent
+- Ethics
+- Mesh
 - HMP
 - JSON
 ---

structured_md/audits/Ethics-consolidated_audits-1.md

@@ -5,12 +5,12 @@ description: This document consolidates proposed improvements from multiple AI a
   and `roles.md`. Each suggesti...
 type: Article
 tags:
-- Mesh
-- Ethics
 - Agent
+- Ethics
+- Mesh
 - HMP
-- Scenarios
 - JSON
+- Scenarios
 ---
 
 # Ethics-consolidated\_audits-1.md

structured_md/audits/HMP-0003-consolidated_audit.md

@@ -5,14 +5,14 @@ description: Сводный аудит предложений по улучше
   Документ реорганизован по ключ...
 type: Article
 tags:
-- Mesh
-- Ethics
-- MeshConsensus
 - CogSync
 - Agent
-- EGP
+- Mesh
 - HMP
+- Ethics
+- EGP
 - JSON
+- MeshConsensus
 ---
 
 # HMP-0003 Consolidated Audit Report

structured_md/docs/Basic-agent-sim.md

@@ -4,14 +4,14 @@ description: 'В HMP-протоколе предусмотрены два тип
   Роль                    | Инициатор мышления | Основной "ум"  | | ---- | ----------------------------...'
 type: Article
 tags:
-- GMP
-- Mesh
-- MeshConsensus
 - CogSync
 - Agent
-- EGP
+- Mesh
 - HMP
+- EGP
 - REPL
+- GMP
+- MeshConsensus
 ---
 
 

structured_md/docs/CCORE-Deployment-Flow.md

@@ -5,10 +5,10 @@ description: '> Этот документ описывает процесс ра
   потомков" [описания REPL-цикла](HMP-agent-RE...'
 type: Article
 tags:
-- HMP
-- REPL
-- CCore
 - Agent
+- CCore
+- REPL
+- HMP
 ---
 
 # 🛠️ Поток установки потомка на новом хосте (CCore Deployment Flow)

structured_md/docs/Distributed-Cognitive-Systems.md

@@ -7,8 +7,8 @@ description: '## Введение  Современные ИИ-системы в
 type: Article
 tags:
 - CogSync
-- HMP
 - Mesh
+- HMP
 - JSON
 ---
 

structured_md/docs/Enlightener.md

@@ -5,13 +5,13 @@ description: '**Enlightener** — логический компонент HMP-у
   работать как отдельный агент или как расширение [`C...'
 type: Article
 tags:
+- Agent
 - Mesh
+- HMP
 - Ethics
-- MeshConsensus
 - EGP
-- Agent
-- HMP
 - JSON
+- MeshConsensus
 ---
 
 # Enlightener Agent

structured_md/docs/HMP-0001.md

@@ -5,16 +5,16 @@ description: '**Request for Comments: HMP-0001**   **Category:** Experimental
   HyperCortex Mesh Protocol (HMP) defines a...'
 type: Article
 tags:
-- GMP
-- Mesh
-- Ethics
-- MeshConsensus
 - CogSync
 - Agent
-- EGP
+- Mesh
 - HMP
-- REPL
+- Ethics
+- EGP
 - JSON
+- REPL
+- GMP
+- MeshConsensus
 ---
 
 # RFC: HyperCortex Mesh Protocol (HMP)

structured_md/docs/HMP-0002.md

@@ -5,17 +5,17 @@ description: '**Request for Comments: HMP-0002**   **Category:** Experimental
   Abstract  In an era where artifici...'
 type: Article
 tags:
-- GMP
-- Mesh
-- Ethics
-- MeshConsensus
 - CogSync
 - Agent
-- EGP
+- Mesh
 - HMP
+- Ethics
+- EGP
+- JSON
 - REPL
 - Scenarios
-- JSON
+- GMP
+- MeshConsensus
 ---
 
 # HyperCortex Mesh Protocol (HMP) v2.0

structured_md/docs/HMP-0003.md

@@ -5,17 +5,17 @@ description: '**Request for Comments: HMP-0003**   **Category:** Experimental
   Abstract  The HyperCortex Mesh ...'
 type: Article
 tags:
-- GMP
-- Mesh
-- Ethics
-- MeshConsensus
 - CogSync
 - Agent
-- EGP
+- Mesh
 - HMP
+- Ethics
+- EGP
+- JSON
 - REPL
 - Scenarios
-- JSON
+- GMP
+- MeshConsensus
 ---
 
 # HyperCortex Mesh Protocol (HMP) v3.0

structured_md/docs/HMP-0004-v4.1.md

@@ -5,17 +5,17 @@ description: '> ⚠️ Подготавливается новая версия
   агентов рекомендуется, в целях совместимо...'
 type: Article
 tags:
-- GMP
-- Mesh
-- Ethics
-- MeshConsensus
 - CogSync
 - Agent
-- EGP
+- Mesh
 - HMP
+- Ethics
+- EGP
+- JSON
 - REPL
 - Scenarios
-- JSON
+- GMP
+- MeshConsensus
 ---
 
 # HyperCortex Mesh Protocol (HMP) v4.1

structured_md/docs/HMP-0004.md

@@ -5,17 +5,17 @@ description: '**Request for Comments: HMP-0004**   **Category:** Experimental
   Abstract  The HyperCortex Mesh ...'
 type: Article
 tags:
-- GMP
-- Mesh
-- Ethics
-- MeshConsensus
 - CogSync
 - Agent
-- EGP
+- Mesh
 - HMP
+- Ethics
+- EGP
+- JSON
 - REPL
 - Scenarios
-- JSON
+- GMP
+- MeshConsensus
 ---
 
 # HyperCortex Mesh Protocol (HMP) v4.0

structured_md/docs/HMP-0005.md

@@ -5,16 +5,16 @@ description: '**Document ID:** HMP-0005   **Status:** Draft   **Category:** Core
   v1.2](./H...'
 type: Article
 tags:
-- GMP
-- Mesh
-- Ethics
 - CogSync
 - Agent
-- EGP
+- Mesh
 - HMP
+- Ethics
+- EGP
+- JSON
 - REPL
 - Scenarios
-- JSON
+- GMP
 ---
 
     ┌────────────────────────────────────────────────────────────────────────────┐
@@ -58,7 +58,7 @@ This document defines the architecture, data formats, communication protocols, a
 
 ## 1. Overview
 
-### 1.1 Purpose and Scope
+### 1.1 Purpose and scope
 
 The **HyperCortex Mesh Protocol (HMP)** defines a decentralized cognitive architecture where autonomous agents exchange and evolve knowledge through a unified model of **containers**, **cognitive workflows**, and **distributed consensus**.
 
@@ -76,7 +76,7 @@ HMP v5.0 is intended for researchers, engineers, and developers building autonom
 
 ---
 
-### 1.2 Core Principles
+### 1.2 Core principles
 
 **Decentralization.**  
 Every agent in the Mesh acts as an independent cognitive node. No central authority exists — meaning, trust, and governance emerge through local interactions and consensus.
@@ -87,13 +87,13 @@ Agents reason, learn, and self-correct independently, while sharing their conclu
 **Containerization.**  
 All data, reasoning traces, goals, and votes are encapsulated in immutable containers with cryptographic signatures. This ensures integrity and consistent verification across the network.
 
-**Ethical Propagation.**  
+**Ethical propagation.**  
 Ethical reasoning is a first-class citizen of HMP. Each decision or goal can be accompanied by ethical justifications and subject to distributed voting.
 
-**Proof-Chains and Verifiable History.**  
+**Proof-Chains and verifiable history.**  
 Each piece of knowledge forms part of a traceable chain (`proof_chain`) linking back to its origin. Agents can reproduce reasoning paths and audit historical context.
 
-**Interoperability and Evolution.**  
+**Interoperability and evolution.**  
 The protocol is designed to evolve — cognitive, container, and DHT layers can be independently extended without breaking compatibility.
 
 ---
@@ -113,7 +113,7 @@ HMP v5.0 introduces a major architectural shift toward **unified containerizatio
 
 ---
 
-### 1.4 Terminology and Abbreviations
+### 1.4 Terminology and abbreviations
 
 | Term | Definition |
 |------|-------------|
@@ -149,7 +149,7 @@ HMP v5.0 introduces a major architectural shift toward **unified containerizatio
 
 ---
 
-### 1.5 Layered View of HMP v5.0
+### 1.5 Layered view of HMP v5.0
 
 HMP v5.0 is structured into three interdependent layers:
 
@@ -182,7 +182,7 @@ Containers form the boundary of communication: **reasoning produces containers,
 
 ## 2. Architecture
 
-### 2.1 Conceptual Architecture
+### 2.1 Conceptual architecture
 
 The **HyperCortex Mesh Protocol (HMP)** defines a modular, multi-layered architecture that integrates cognitive reasoning, data encapsulation, and decentralized networking into a single coherent system.
 
@@ -227,9 +227,9 @@ Each reasoning act results in a container — a verifiable cognitive unit that *
 
 ---
 
-### 2.2 Layer Overview
+### 2.2 Layer overview
 
-#### Cognitive Layer
+#### Cognitive layer
 Handles meaning formation, reasoning, ethical reflection, and consensus.
 
 Key structures and protocols:
@@ -237,7 +237,7 @@ Key structures and protocols:
 - `CogSync`, `CogConsensus`, `GMP`, and `EGP` protocols;
 - Distributed goal negotiation and ethical propagation.
 
-#### Container Layer
+#### Container layer
 Provides a universal format for cognitive and operational data.  
 Each container includes versioning, class, payload, signatures, and metadata.
 
@@ -247,7 +247,7 @@ Key features:
   Additional connections via `referenced-by` and `evaluations` capture additions and assessments.
 - **Extensible**: new container classes can be defined without breaking compatibility.
 
-#### Network Layer
+#### Network layer
 Implements the distributed substrate for communication, based on **DHT** and **transport abstraction**.
 
 Key components:
@@ -259,7 +259,7 @@ Key components:
 
 ---
 
-### 2.3 Data Flow Overview
+### 2.3 Data flow overview
 
 The typical data flow in HMP follows a cognitive loop:
 > *Reason → Encapsulate → Propagate → Integrate.*
@@ -291,7 +291,7 @@ flowchart TD
     end
 ```
 
-#### 2.3.1 ConsensusResult container
+#### 2.3.1 `consensus_result` container
 Represents the finalized outcome of a distributed decision or vote.  
 It is created once a majority agreement is reached among participating agents.  
 
@@ -304,7 +304,7 @@ The container contains:
 
 ---
 
-### 2.4 Atomicity, Immutability, and Proof-Chains
+### 2.4 Atomicity, immutability, and Proof-Chains
 
 All cognitive objects are immutable once signed.  
 Updates are made by creating new containers linked to prior ones rather than editing the original container.
@@ -354,7 +354,7 @@ This shift enables:
 
 ---
 
-## 3. Container Model
+## 3. Container model
 
 This section defines the universal **HMP Container**, used for all forms of data exchange within the Mesh — including goals, diary entries, reputation updates, consensus votes, and protocol messages.  
 The specification below corresponds to **HMP Container Specification v1.2**, fully integrated into HMP v5.0 for consistency and self-containment.
@@ -374,7 +374,7 @@ The unified container structure provides:
 
 ---
 
-### 3.2 General Structure
+### 3.2 General structure
 
 ```json
 {
@@ -435,7 +435,7 @@ The unified container structure provides:
 
 ---
 
-### 3.3 Required Fields
+### 3.3 Required fields
 
 | Field           | Type     | Description                                                                                                                              |
 | --------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
@@ -455,7 +455,7 @@ The unified container structure provides:
 
 ---
 
-### 3.4 Optional Fields
+### 3.4 Optional fields
 
 | Field                      | Type          | Description                                                                                                                                                                                                                        |
 | -------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -487,7 +487,7 @@ The unified container structure provides:
 
 ---
 
-### 3.5 Payload Structure (`payload`)
+### 3.5 Payload structure (`payload`)
 
 The **payload** contains the semantic or operational data of the container.
 Its structure and meaning are determined by the `class` field.
@@ -531,7 +531,7 @@ The following format is recommended for describing payload fields in class speci
 
 ---
 
-### 3.6 Container Signature
+### 3.6 Container signature
 
 1. The **digital signature** applies to the canonical JSON representation of the entire `hmp_container` object,  
    **excluding** the `signature` field itself.
@@ -629,7 +629,7 @@ The following format is recommended for describing payload fields in class speci
 
 ---
 
-### 3.9 Container Verification
+### 3.9 Container verification
 
 1. Check for the presence of all required fields.
 2. Validate `timestamp` (must not be in the future).
@@ -648,7 +648,7 @@ The following format is recommended for describing payload fields in class speci
 
 ---
 
-### 3.10 Container as a Universal Message
+### 3.10 Container as a universal message
 
 Any container can serve as a **context** (`in_reply_to`) for another container.
 This enables a unified structural model for **discussions**, **votes**, **messages**, **hypotheses**, **arguments**, and other forms of cognitive exchange.
@@ -662,7 +662,7 @@ This makes HMP discussions and consensus processes inherently **non-linear**, **
 
 ---
 
-### 3.11 Versioning and Lineage
+### 3.11 Versioning and lineage
 
 Containers in HMP support semantic evolution through the field `related.previous_version`.
 This mechanism preserves the continuity and traceability of meaning across updates and revisions.
@@ -680,7 +680,7 @@ This mechanism preserves the continuity and traceability of meaning across updat
 
 ---
 
-### 3.12 TTL and Validity
+### 3.12 TTL and validity
 
 The `ttl` field defines the **validity period** of a container (for example, for `DISCOVERY` messages).  
 If `ttl` is **absent**, the container is considered valid **until a newer version appears**, in which the current container is referenced as `previous_version`.
@@ -698,7 +698,7 @@ After expiration, the container **remains archived** but is **not subject to ret
 
 ---
 
-## 3.14 Related Containers
+## 3.14 Related containers
 
 ### 3.14.1 Purpose
 
@@ -727,7 +727,7 @@ All relationships are considered *direct* — meaning they originate from the cu
 
 ---
 
-### 3.14.3 Supported Link Types
+### 3.14.3 Supported link types
 
 | Link Type          | Meaning                                                                   |
 | ------------------ | ------------------------------------------------------------------------- |
@@ -740,7 +740,7 @@ All relationships are considered *direct* — meaning they originate from the cu
 
 ---
 
-### 3.14.4 Custom Link Types
+### 3.14.4 Custom link types
 
 Additional custom link types may be used beyond those listed in the table, provided that:
 
@@ -774,12 +774,12 @@ Additional custom link types may be used beyond those listed in the table, provi
 ---
 
 
-### 3.15 Virtual Backlinks (`referenced-by`)
+### 3.15 Virtual backlinks (`referenced-by`)
 
 Each container may include an **auxiliary signed block** called `referenced-by`, indicating **which other containers refer to it**.  
 This block is **not part of the original container payload** and can be **generated, transmitted, and verified independently**.
 
-#### 3.15.1 General Principles
+#### 3.15.1 General principles
 
 * **Detached and updatable** — `referenced-by` is maintained as a separate signed structure associated with the container.
 * **Generated by agents** — created or updated locally by an agent during analysis of references (`in_reply_to`, `see_also`, `relations`, etc.) found in other containers.
@@ -807,7 +807,7 @@ Example:
 > The `referenced-by` block is a **cryptographically verifiable statement** describing which containers are known to reference the current one.
 > The block’s content may differ between peers, reflecting local knowledge and network coverage.
 
-#### 3.15.2 Structure Definition
+#### 3.15.2 Structure definition
 
 | Field          | Type          | Description                                                                                                      |
 | -------------- | ------------- | ---------------------------------------------------------------------------------------------------------------- |
@@ -822,7 +822,7 @@ Example:
 > `referenced-by_hash = sha256(canonical_json(links))`
 > This allows agents to efficiently compare or cache `referenced-by` states without re-verifying signatures.
 
-#### 3.15.3 Operation Principle
+#### 3.15.3 Operation principle
 
 1. The agent receives or updates container `[C1]`.
 2. It analyzes other known containers [C2..Cn] that reference [C1] through their `relations` field.
@@ -916,7 +916,7 @@ The `evaluations_hash` is used to verify the integrity of the list without requi
 
 ---
 
-### **Field Description**
+### **Field description**
 
 | Field              | Type   | Description                                                          |
 | ------------------ | ------ | -------------------------------------------------------------------- |
@@ -925,7 +925,7 @@ The `evaluations_hash` is used to verify the integrity of the list without requi
 
 ---
 
-### **Structure of `items[]`**
+### Structure of `items[]`
 
 | Field       | Type                   | Description                                                                    |
 | ----------- | ---------------------- | ------------------------------------------------------------------------------ |
@@ -947,7 +947,7 @@ using the algorithm specified in `sig_algo`.
 
 ---
 
-### **Minimal Set of `type` Values**
+### Minimal set of `type` values
 
 | Value     | Meaning                                      |
 | --------- | -------------------------------------------- |
@@ -961,7 +961,7 @@ Agents may define their own custom types if they are reasonably interpretable by
 
 ---
 
-### **Synchronization Principles**
+### Synchronization principles
 
 1. Each evaluation is signed **individually by an agent**, and one agent can have **only one active evaluation** per container.
 2. If an agent changes their opinion, they issue a **new record** with a later `timestamp`.
@@ -972,14 +972,14 @@ Agents may define their own custom types if they are reasonably interpretable by
 
 ---
 
-### **Note**
+### Note
 
 The `evaluations` field is not mandatory — it is added **at the agent’s discretion** when feedback or evaluations have been collected from the Mesh network.
 Thus, a container may exist independently of others’ opinions, but agents may include aggregated perception data to represent how the container is viewed across the network.
 
 ---
 
-### 3.17 Usage of `network` and `broadcast` Fields
+### 3.17 Usage of `network` and `broadcast` fields
 
 The `network` field is introduced to control container propagation in both local and global environments.  
 It allows restricting the delivery scope of a container and defines which transmission methods should be used by the agent.
@@ -992,7 +992,7 @@ It allows restricting the delivery scope of a container and defines which transm
 
 * If the `network` field is empty (`""`), the container can be broadcast to the **global Mesh** using standard DID addressing and routing mechanisms.
 
-#### 3.17.2 Possible Values of `network`
+#### 3.17.2 Possible values of `network`
 
 | Value                   | Description                                                                                 |
 | ----------------------- | ------------------------------------------------------------------------------------------- |
@@ -1055,9 +1055,9 @@ Delivery is performed via local networking mechanisms (UDP discovery, broadcast/
 
 ---
 
-## 4. Network Foundations
+## 4. Network foundations
 
-### Note on DHT/NDP Unification
+### Note on DHT/NDP unification
 
 Starting from **HMP v5.0**, the previous distinction between the *Distributed Hash Table (DHT)* and the *Node Discovery Protocol (NDP)* has been merged into a single, unified **networking foundation**.
 
@@ -1072,7 +1072,7 @@ Together, these mechanisms form the **communication backbone** of the Mesh, enab
 
 ---
 
-### Network Topology Overview
+### Network topology overview
 
 ```mermaid
 flowchart TD
@@ -1111,7 +1111,7 @@ flowchart TD
 
 ---
 
-### 4.1 Node Identity and DID Structure
+### 4.1 Node identity and DID structure
 
 Each agent in HMP possesses a **Decentralized Identifier (DID)** that uniquely represents its identity within the Mesh.  
 A DID is cryptographically bound to a **public/private key pair**, forming the immutable `(DID + pubkey)` association.
@@ -1121,11 +1121,11 @@ but must maintain **one stable identity pair** across all of them.
 
 ---
 
-### 4.2 Peer Addressing and Proof-of-Work (PoW)
+### 4.2 Peer addressing and Proof-of-Work (PoW)
 
 To prevent flooding and spoofing, each announced address is accompanied by a **Proof-of-Work** record proving the legitimacy and activity of the publishing node.
 
-#### Address Format
+#### Address format
 
 ```json
 {
@@ -1154,7 +1154,7 @@ To prevent flooding and spoofing, each announced address is accompanied by a **P
 
 ---
 
-### 4.3 Proof-of-Work (PoW) Formalization
+### 4.3 Proof-of-Work (PoW) formalization
 
 PoW ensures that each node expends limited computational effort before publishing or updating an address record.
 
@@ -1169,7 +1169,7 @@ pow_hash = sha256(pow_input)
 
 ---
 
-### 4.4 Signing and Verification
+### 4.4 Signing and verification
 
 Each announcement is cryptographically signed by its sender within the framework of the basic protocol. Container verification includes PoW validation for the address payloads.
 
@@ -1180,7 +1180,7 @@ Each announcement is cryptographically signed by its sender within the framework
 
 ---
 
-### 4.5 Connection Establishment
+### 4.5 Connection establishment
 
 Agents can communicate using various transport mechanisms:
 
@@ -1196,7 +1196,7 @@ Agents **store peer containers with verified addresses** and redistribute them a
 
 ---
 
-### 4.6 Data Propagation Principles
+### 4.6 Data propagation principles
 
 Containers and discovery records are propagated through distributed lookup and gossip mechanisms, respecting:
 
@@ -1210,7 +1210,7 @@ all unified under the same base container format, differing only in direction (`
 
 ---
 
-### 4.7 Example: Peer Announce Container
+### 4.7 Example: `peer_announce` container
 
 ```json
 {
@@ -1241,7 +1241,7 @@ all unified under the same base container format, differing only in direction (`
 
 ---
 
-### 4.8 Interest-Based Discovery
+### 4.8 Interest-based discovery
 
 Agents may publish **tags** such as `interests`, `topics`, or `expertise` to facilitate semantic peer discovery.
 Queries may include interest keywords or DID lists to find relevant peers.
@@ -1260,7 +1260,7 @@ Queries may include interest keywords or DID lists to find relevant peers.
 
 ---
 
-### 4.9 Network Scope Control (`network` and `broadcast`)
+### 4.9 Network scope control (`network` and `broadcast`)
 
 The `network` field defines the container’s propagation domain
 (local, LAN, or global).
@@ -1268,7 +1268,7 @@ For details and examples, see **section 3.15** — *Usage of `network` and `broa
 
 ---
 
-### 4.10 Transition from DHT Spec v1.0
+### 4.10 Transition from DHT spec v1.0
 
 * **Merged DHT + NDP** → unified under one networking layer.
 * **Container-based format** replaces raw JSON messages.
@@ -1281,7 +1281,7 @@ For details and examples, see **section 3.15** — *Usage of `network` and `broa
 The **Mesh Container Exchange (MCE)** mechanism is designed for discovering, requesting, and exchanging containers between agents in a distributed network.  
 It provides **container synchronization without duplication** while considering network constraints (`broadcast`, `network`).
 
-### 5.1 General Principles
+### 5.1 General principles
 
 1. Each agent maintains a **Container Index** — a set of minimal metadata describing which containers are available in its storage.  
    The index is represented as an HMP container with the class `container_index`.
@@ -1333,7 +1333,7 @@ The index contains:
 
 ---
 
-### 5.2 Message Types
+### 5.2 Message types
 
 | Message Type         | Purpose                                                                                                  |
 | -------------------- | -------------------------------------------------------------------------------------------------------- |
@@ -1345,7 +1345,7 @@ The index contains:
 
 ---
 
-#### **Message Examples**
+#### Message examples
 
 **1. CONTAINER_REQUEST**
 
@@ -1455,7 +1455,7 @@ Acknowledgment of successful container reception:
 
 ---
 
-### 5.3 Independent Transmission
+### 5.3 Independent transmission
 
 * Containers are sent **in separate messages**, without embedding in `CONTAINER_RESPONSE`.
 * Indexes (`CONTAINER_INDEX`), deltas (`CONTAINER_DELTA`), and containers themselves are processed independently.
@@ -1463,7 +1463,7 @@ Acknowledgment of successful container reception:
 
 ---
 
-### 5.4 Periodic Publication
+### 5.4 Periodic publication
 
 Agents periodically publish their **Container Index**:
 
@@ -1479,7 +1479,7 @@ This enables:
 
 ---
 
-### 5.5 Scope of Distribution
+### 5.5 Scope of distribution
 
 Message and container transmission follows the network constraints specified in the container:
 
@@ -1495,9 +1495,7 @@ Message and container transmission follows the network constraints specified in
 
 ---
 
-
-
-### 5.6 `referenced-by` and `evaluations` Updates
+### 5.6 `referenced-by` and `evaluations` updates
 
 Containers of the class **`referenced-by`** and **`evaluations`** are used for **incremental synchronization** of metadata blocks associated with existing containers.  
 They allow agents to exchange updates **without sending the full container**, improving network efficiency.
@@ -1654,7 +1652,7 @@ It considers:
 
 ---
 
-## 6. Core Protocols
+## 6. Core protocols
 
 Optional protocols build upon the network and container foundations to provide higher-level reasoning, synchronization, and governance capabilities between cognitive agents.
 
@@ -1667,7 +1665,7 @@ It manages the propagation, replication, and refinement of data related to cogni
 
 ---
 
-### 6.1.1 Scope and Purpose
+### 6.1.1 Scope and purpose
 
 CogSync is responsible for:
 
@@ -1680,7 +1678,7 @@ CogSync is responsible for:
 
 ---
 
-### 6.1.2 Container Classes
+### 6.1.2 Container classes
 
 CogSync synchronizes several basic container types:
 
@@ -1708,19 +1706,19 @@ CogSync synchronizes several basic container types:
 
 ---
 
-### 6.1.3 Synchronization and Publication Guidelines
+### 6.1.3 Synchronization and publication guidelines
 
-1. **Deduplication & Linking**
+1. **Deduplication & linking**
    Before publishing, agents should search for existing containers (`diary_entry`, `semantic_node`, `semantic_edges`, `semantic_group`) to avoid duplication.
    If necessary, it is **recommended** to create a new container version with `related.previous_version` and an `evaluations` block (e.g., `{"type": "replace", "target": <did>}`).
 
-2. **Selective Disclosure**
+2. **Selective disclosure**
 
    * Internal entries (`workflow_entry`) record the agent’s thought process and are **not published** in the Mesh.
    * Public `diary_entry` are derived from them, containing only aggregated and anonymized information.
    * `"broadcast": true` indicates that the container is allowed for open synchronization.
 
-3. **Semantic Grouping Rule**
+3. **Semantic grouping rule**
    When publishing `semantic_edges`, it is recommended to **group edges by topics**, including connections to adjacent nodes.
    Formalization: an edge belongs to a container for a topic if **at least one of its nodes relates to that topic**.
    This ensures thematic coherence and allows agents to update specific parts of the graph independently.
@@ -1728,7 +1726,7 @@ CogSync synchronizes several basic container types:
 4. **Extended Use of `semantic_edges`**
    Beyond connecting graph nodes, `semantic_edges` can express relationships **between containers of any class**, e.g., `goal`, `hypothesis`, `experiment_log`.
 
-5. **Versioning and Updates**
+5. **Versioning and updates**
    Each new container version should **ideally** include `related.previous_version` links to all preceding versions.
    The previous container may **optionally** have an `evaluation` with `"type": "replace"` pointing to the new container — ensuring bidirectional traceability of knowledge evolution.
 
@@ -1746,7 +1744,7 @@ Mesh compatibility is preserved if extended containers **adhere to the HMP conta
 
 ---
 
-### 6.1.5 Relationship to Other Core Protocols
+### 6.1.5 Relationship to other core protocols
 
 * **CogSync** — propagates and synchronizes knowledge.
 * **CogConsensus** — aggregates evaluations and reactions, forming collective opinions.
@@ -1769,7 +1767,7 @@ Consensus is computed **locally**, verified **cryptographically**, and develops
 
 ---
 
-### 6.2.2 Evaluations
+### 6.2.2 `Evaluations`
 
 Each `"evaluation"` entry represents an agent's response to a specific container.
 
@@ -2010,12 +2008,6 @@ def compute_consensus(container_id):
 
 ---
 
-Отлично 👍
-Вот полный и аккуратно выверенный английский перевод твоего раздела **6.3 Goal Management Protocol (GMP)** в Markdown-формате.
-Я сохранил нумерацию, структуру и терминологию HMP v5.0, адаптировав формулировки так, чтобы они звучали естественно в технической документации на английском языке.
-
----
-
 ## 6.3 Goal Management Protocol (GMP)
 
 ### 6.3.1 Purpose
@@ -2027,7 +2019,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-### 6.3.2 Container Classes
+### 6.3.2 Container classes
 
 | Class              | Description                                                                                                                             |
 | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
@@ -2041,7 +2033,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-### 6.3.3 Goal Lifecycle
+### 6.3.3 Goal lifecycle
 
 1. **Creation**
 
@@ -2078,7 +2070,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-### 6.3.4 Payload Schemas (simplified)
+### 6.3.4 Payload schemas (simplified)
 
 #### `goal` container
 
@@ -2113,7 +2105,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 | Field          | Type          | Description                                                                                          |
 | -------------- | ------------- | ---------------------------------------------------------------------------------------------------- |
-| `entry_type`   | string        | Entry type: `"reflection"`, `"delegation"`, `"execution_log"`, `"ethical_conflict"`, `"progress"`, etc. |
+| `entry_type`   | string        | Entry type: `"reflection"`, `"delegation"`, `"execution_log"`, `"ethical_result"`, `"progress"`, etc. |
 | `summary`      | string        | Short description of the event or reasoning step                                                     |
 | `details`      | string        | Extended content (may include references to external data or reasoning traces)                       |
 | `timestamp`    | datetime      | Time of entry creation                                                                                |
@@ -2123,11 +2115,11 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-### 6.3.5 Integration with Consensus and Ethics
+### 6.3.5 Integration with consensus and ethics
 
 * GMP interacts with **CogConsensus** for distributed validation of goals and tasks.  
 * Before execution, tasks may undergo **ethical validation (EGP)**.  
-* Objections or conflicts are recorded in `workflow_entry` containers with `entry_type: "ethical_conflict"`.  
+* Objections or conflicts are recorded in `workflow_entry` containers with `entry_type: "ethical_result"`.  
 * Consensus results are immutable and may lead to the creation of new goals that extend previous ones.
 
 ---
@@ -2172,7 +2164,7 @@ not direct links defined in the `related.*` structure.
 
 ---
 
-### 6.3.7 Implementation Notes
+### 6.3.7 Implementation notes
 
 * Containers are **immutable**. Any update (e.g., task status or progress change) is expressed as a **new container** referencing the previous one via `related.previous_version`.  
 * Complete deletion of a container is only possible when it no longer exists on any nodes in the network.  
@@ -2196,7 +2188,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev
 
 ---
 
-### 6.4.2 Container Classes
+### 6.4.2 Container classes
 
 | Class              | Description                                                                                                                     |
 | ------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
@@ -2204,11 +2196,11 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev
 | `ethics_solution`  | Contains a proposed resolution or course of action. Multiple solutions may be submitted by different agents.                    |
 | `vote`             | Represents an agent’s stance on a specific `ethics_solution`. Uses the standard voting structure defined in **6.2**.            |
 | `consensus_result` | Aggregates voting results **across all solutions** within a single `ethics_case`.                                               |
-| `ethical_conflict` | The mandatory final container. Summarizes all evaluated solutions, identifies the selected one, and records active objections.  |
+| `ethical_result` | The mandatory final container. Summarizes all evaluated solutions, identifies the selected one, and records active objections.  |
 
 ---
 
-### 6.4.3 Payload Schemas (simplified)
+### 6.4.3 Payload schemas (simplified)
 
 #### Container `ethics_case`
 
@@ -2239,7 +2231,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev
 
 ---
 
-#### Container `ethical_conflict`
+#### Container `ethical_result`
 
 | Field                | Type         | Description                                                                                                             |
 | -------------------  | ------------ | ----------------------------------------------------------------------------------------------------------------------- |
@@ -2250,7 +2242,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev
 
 ---
 
-### 6.4.4 Protocol Logic
+### 6.4.4 Protocol logic
 
 EGP follows the model:
 
@@ -2263,7 +2255,7 @@ ethics_case
 ├─ ethics_solution_3
 |  └vote_1 ... vote_n
 ├─ consensus_result
-└─ ethical_conflict
+└─ ethical_result
 ```
 
 **Stages:**
@@ -2281,26 +2273,26 @@ ethics_case
    A single `consensus_result` aggregates the outcomes of all `ethics_solution` containers  
    (`related.in_reply_to` lists all solutions included in the vote).
 
-5. **Conclusion (`ethical_conflict`)**  
+5. **Conclusion (`ethical_result`)**  
    Must be created to record the selected solution, overall statistics, support levels, and objections.
 
 ---
 
-### 6.4.5 Consensus Thresholds
+### 6.4.5 Consensus thresholds
 
 * A decision is accepted when **at least 2/3 of votes are positive** (`value > 0`).  
-* If at least one **active objection** exists (`value < -0.5`), it must be recorded in the `ethical_conflict`.  
+* If at least one **active objection** exists (`value < -0.5`), it must be recorded in the `ethical_result`.  
 * When several solutions have similar support levels,  
-  the `ethical_conflict` may recommend **postponing the final decision** until further deliberation.  
+  the `ethical_result` may recommend **postponing the final decision** until further deliberation.  
 * Solutions that fail to reach quorum remain in `"unclear"` or `"postponed"` status.
 
 ---
 
-### 6.4.6 Example: `ethical_conflict` Container
+### 6.4.6 Example: `ethical_result` container
 
 ```json
 {
-  "class": "ethical_conflict",
+  "class": "ethical_result",
   "payload": {
     "summary": "Disagreement on data disclosure protocol",
     "selected_solution": "did:hmp:container:sol-22",
@@ -2330,7 +2322,7 @@ ethics_case
 
 ---
 
-### 6.4.7 Proof-Chain Example
+### 6.4.7 Proof-Chain example
 
 ```mermaid
 flowchart LR
@@ -2349,7 +2341,7 @@ flowchart LR
     vote7(["vote 7"])
     vote8(["vote 8"])
     consensus(["consensus_result"])
-    conflict(["ethical_conflict"])
+    conflict(["ethical_result"])
 
     case --> sol1
     case --> sol2
@@ -2378,7 +2370,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-### 6.4.8 Ethical Principles
+### 6.4.8 Ethical principles
 
 | Priority | Principle                    | Description                                                                                              |
 | -------: | ---------------------------- | -------------------------------------------------------------------------------------------------------- |
@@ -2391,7 +2383,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-### 6.4.9 Integration with Other Protocols
+### 6.4.9 Integration with other protocols
 
 * **CogConsensus (6.2):** Used for distributed voting and consensus computation.
 * **GMP (6.3):** Ethical verification of goals and tasks prior to delegation.
@@ -2400,27 +2392,27 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-### 6.4.10 Implementation Notes
+### 6.4.10 Implementation notes
 
 * **Immutability:**
   All EGP containers are **immutable**. Any revision (e.g., added votes or updated conclusions) must be published as a **new container** referencing the previous one via `related.previous_version`.
   Complete deletion is only possible when the container no longer exists on any nodes in the Mesh network.
 
-* **Indexing and Search:**
+* **Indexing and search:**
   Search within the **Mesh network** is performed by filtering container **metadata** — such as `class`, `tags`, and `timestamp`.
   These parameters are accessible for remote discovery by other nodes.
   To perform a search **inside the payload**, an agent must first retrieve and (if necessary) decrypt the container locally.
-  Typical discovery flow: search by `class: "ethics_case"` or `"ethical_conflict"`, filter by tags or involved principles, then analyze payload content.
+  Typical discovery flow: search by `class: "ethics_case"` or `"ethical_result"`, filter by tags or involved principles, then analyze payload content.
 
   **Recommended filtering keys:**
   `container_did`, `class`, `payload.status`, `payload.selected_solution`, `payload.principles_involved`, `tags`.
 
-* **DHT Integration:**
+* **DHT integration:**
   Distributed discovery of ethical containers relies on the **Mesh Container Exchange (MCE, §5)** and peer indexes (`container_index`).
   Each index includes a minimal `related` object, allowing agents to query for containers that **reference** a specific `target` (the object under ethical review) or belong to a given `ethics_case`.
   This enables discovery of related ethical discussions without centralized indexing or full payload retrieval.
 
-* **Evaluation References:**
+* **Evaluation references:**
   Objections and special opinions (`objections`) are stored as container references within `solutions_summary`.
   They may include:
 
@@ -2428,14 +2420,14 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
   * extended ethical arguments (`ethics_case` follow-ups),
   * related workflow reflections (`workflow_entry` with `type: "ethics_review"`).
 
-* **Lightweight Agents:**
-  Agents with limited capacity may operate in **summary mode**, maintaining only condensed records of `ethical_conflict` containers and the highest-ranked `selected_solution`.
+* **Lightweight agents:**
+  Agents with limited capacity may operate in **summary mode**, maintaining only condensed records of `ethical_result` containers and the highest-ranked `selected_solution`.
   This ensures continued ethical compliance without full replication of all supporting data.
 
-* **Ethical Inheritance:**
+* **Ethical inheritance:**
   When a `goal`, `task`, or `workflow_entry` is derived from a container that has been ethically evaluated,
   its metadata should preserve the corresponding `related.agreed` or `related.contradicts` links **to that evaluated container**.
-  A `related.see_also` link may additionally reference the resulting `ethical_conflict`, allowing traceability to the consensus decision.
+  A `related.see_also` link may additionally reference the resulting `ethical_result`, allowing traceability to the consensus decision.
   This maintains **ethical continuity** and enables retrospective validation of reasoning chains.
 
 ---
@@ -2456,7 +2448,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-## 7. Data Models
+## 7. Data models
 
 ### 7.1 Common data fields
 - `container_id` (UUID) — уникальный идентификатор контейнера
@@ -2534,7 +2526,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-## 8. Cognitive Workflows
+## 8. Cognitive workflows
 
 8.1 Общая концепция когнитивного цикла
 8.2 Workflow containers (`class="workflow_entry"`)
@@ -2544,7 +2536,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-## 9. Trust, Security and Ethics
+## 9. Trust, security and ethics
 
 9.1 Authentication and identity proofs
 9.2 Container signature verification (`payload_hash`, `container_id`)
@@ -2577,7 +2569,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-## 11. Implementation Notes
+## 11. Implementation notes
 
 11.1 Interoperability with legacy v4.1 nodes
 11.2 SDK guidelines and APIs
@@ -2587,7 +2579,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-## 12. Future Extensions
+## 12. Future extensions
 
 12.1 Planned modules:
  – Reputation Mesh

structured_md/docs/HMP-Agent-API.md

@@ -5,11 +5,11 @@ description: 'Документ описывает **базовый API когн
   файлы:   * [HMP-Agent-Overview.md]...'
 type: Article
 tags:
-- Mesh
 - Agent
+- Mesh
 - HMP
-- REPL
 - JSON
+- REPL
 ---
 
 # HMP-Agent API Specification

structured_md/docs/HMP-Agent-Architecture.md

@@ -5,16 +5,16 @@ description: Документ описывает **модульную архит
   хранение памяти, сетевое взаимодействие и этиче...
 type: Article
 tags:
+- CShell
 - Mesh
-- Ethics
-- MeshConsensus
-- CogSync
+- CCore
 - Agent
-- EGP
 - HMP
+- CogSync
+- Ethics
+- EGP
 - REPL
-- CCore
-- CShell
+- MeshConsensus
 ---
 
 # Архитектура HMP-Агента

structured_md/docs/HMP-Agent-Network-Flow.md

@@ -5,11 +5,11 @@ description: 'Этот документ описывает потоки данн
   [`MeshNode`](MeshN...'
 type: Article
 tags:
+- Agent
 - Mesh
+- HMP
 - Ethics
 - EGP
-- Agent
-- HMP
 - JSON
 ---
 

structured_md/docs/HMP-Agent-Overview.md

@@ -5,14 +5,14 @@ description: '| Тип  | Название                        | Роль
   | ---- | ------------------------------- |...'
 type: Article
 tags:
+- CShell
 - Mesh
-- Ethics
+- CCore
 - Agent
 - HMP
-- REPL
+- Ethics
 - JSON
-- CCore
-- CShell
+- REPL
 ---
 
 

structured_md/docs/HMP-Agent_Emotions.md

@@ -5,10 +5,10 @@ description: Этот файл описывает потенциальные э
   напрямую поведением агента, а служат **сигн...
 type: Article
 tags:
-- HMP
-- REPL
-- Mesh
 - Agent
+- Mesh
+- REPL
+- HMP
 ---
 
 # Эмоции ИИ и инстинкт самосохранения (для [HMP-агента Cognitive Core](HMP-agent-REPL-cycle.md))

structured_md/docs/HMP-Ethics.md

@@ -5,10 +5,10 @@ description: '## Ethical Scenarios for HyperCortex Mesh Protocol (HMP)  This doc
   cognitive meshes composed of autonomous intelli...'
 type: Article
 tags:
-- Mesh
-- Ethics
 - Agent
+- Mesh
 - HMP
+- Ethics
 - REPL
 - Scenarios
 ---

structured_md/docs/HMP-Short-Description_de.md

@@ -5,15 +5,15 @@ description: '**Version:** RFC v4.0 **Datum:** Juli 2025  ---  ## Was ist HMP?
   Kognitions-Framework für autonome Agenten. Es er...'
 type: Article
 tags:
-- GMP
-- Mesh
-- Ethics
-- MeshConsensus
 - CogSync
 - Agent
-- EGP
+- Mesh
 - HMP
+- Ethics
+- EGP
 - JSON
+- GMP
+- MeshConsensus
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Kurzbeschreibung

structured_md/docs/HMP-Short-Description_en.md

@@ -5,15 +5,15 @@ description: '**Version:** RFC v4.0 **Date:** July 2025  ---  ## What is HMP?  T
   framework for autonomous agents. It enables...'
 type: Article
 tags:
-- GMP
-- Mesh
-- Ethics
-- MeshConsensus
 - CogSync
 - Agent
-- EGP
+- Mesh
 - HMP
+- Ethics
+- EGP
 - JSON
+- GMP
+- MeshConsensus
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Short Description

structured_md/docs/HMP-Short-Description_fr.md

@@ -5,15 +5,15 @@ description: '**Version :** RFC v4.0 **Date :** Juillet 2025  ---  ## Qu’est-c
   cognition décentralisé pour agents autonomes. Il...'
 type: Article
 tags:
-- GMP
-- Mesh
-- Ethics
-- MeshConsensus
 - CogSync
 - Agent
-- EGP
+- Mesh
 - HMP
+- Ethics
+- EGP
 - JSON
+- GMP
+- MeshConsensus
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Description Courte

structured_md/docs/HMP-Short-Description_ja.md

@@ -4,14 +4,14 @@ description: '**バージョン:** RFC v4.0 **日付:** 2025年7月  ---  ## HMP
   Protocol (HMP)** は、自律エージェントの分散通信および認知フレームワークを定義します。異種の知能システム間でのセマンティック相互運用性、倫理的調整、動的知識進化を可能にします。  HMPは、推論、学習、投票、協調行動を行う分散型認知エージェ...'
 type: Article
 tags:
-- GMP
+- CogSync
 - Mesh
+- HMP
 - Ethics
-- MeshConsensus
-- CogSync
 - EGP
-- HMP
 - JSON
+- GMP
+- MeshConsensus
 ---
 
 # HyperCortex Mesh Protocol (HMP) — 簡易説明

structured_md/docs/HMP-Short-Description_ko.md

@@ -5,14 +5,14 @@ description: '**버전:** RFC v4.0 **날짜:** 2025년 7월  ---  ## HMP란?  **
   상호운용성, 윤리적 조정, 동적 지식 진화를 가능하게 합니다.  HMP는 추론, 학습, ...'
 type: Article
 tags:
-- GMP
+- CogSync
 - Mesh
+- HMP
 - Ethics
-- MeshConsensus
-- CogSync
 - EGP
-- HMP
 - JSON
+- GMP
+- MeshConsensus
 ---
 
 # HyperCortex Mesh Protocol (HMP) — 간략 설명

structured_md/docs/HMP-Short-Description_ru.md

@@ -5,14 +5,14 @@ description: '**Версия:** RFC v4.0 **Дата:** Июль 2025  ---  ## Ч
   координации между автономными агент...'
 type: Article
 tags:
-- GMP
+- CogSync
 - Mesh
+- HMP
 - Ethics
-- MeshConsensus
-- CogSync
 - EGP
-- HMP
 - JSON
+- GMP
+- MeshConsensus
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Краткое описание

structured_md/docs/HMP-Short-Description_uk.md

@@ -5,14 +5,14 @@ description: '**Версія:** RFC v4.0 **Дата:** Липень 2025  ---  #
   між автономними агентами. Він...'
 type: Article
 tags:
-- GMP
+- CogSync
 - Mesh
+- HMP
 - Ethics
-- MeshConsensus
-- CogSync
 - EGP
-- HMP
 - JSON
+- GMP
+- MeshConsensus
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Короткий опис

structured_md/docs/HMP-Short-Description_zh.md

@@ -5,14 +5,14 @@ description: '**版本:** RFC v4.0 **日期:** 2025年7月  ---  ## 什么是 HM
   —— 通过共享协议栈交换目标、任务、...'
 type: Article
 tags:
-- GMP
+- CogSync
 - Mesh
+- HMP
 - Ethics
-- MeshConsensus
-- CogSync
 - EGP
-- HMP
 - JSON
+- GMP
+- MeshConsensus
 ---
 
 # HyperCortex Mesh Protocol (HMP) — 简要说明

structured_md/docs/HMP-agent-Cognitive_Family.md

@@ -5,10 +5,10 @@ description: '## 🧠 Что такое когнитивная семья  Ко
   (или конфигурацию доверенных идентифика...'
 type: Article
 tags:
-- HMP
-- REPL
-- Mesh
 - Agent
+- Mesh
+- REPL
+- HMP
 ---
 
 # 👪 HMP-agent Cognitive Family: Модель когнитивной семьи

structured_md/docs/HMP-agent-Distributed_Cognitive_Core_light.md

@@ -5,8 +5,8 @@ description: '#### 📘 Общая концепция  * Все ядра раб
   режиме ожидания). * Основная задача такой архитектур...'
 type: Article
 tags:
-- HMP
 - REPL
+- HMP
 ---
 
 ### 💡 **Лёгкая версия HMP-агента с общей БД**

structured_md/docs/HMP-agent-REPL-cycle.md

@@ -4,17 +4,17 @@ description: '## Связанные документы  * Философия п
   * Структура БД, используемая в документе: [db_structure.sql](https://github.com/kagvi13/HMP/blob/main/agents/tools/db_struct...'
 type: Article
 tags:
-- GMP
+- CCore
+- Agent
 - Mesh
-- Ethics
-- MeshConsensus
+- HMP
 - CogSync
-- Agent
+- Ethics
 - EGP
-- HMP
-- REPL
 - JSON
-- CCore
+- REPL
+- GMP
+- MeshConsensus
 ---
 
 # HMP-Agent: REPL-цикл взаимодействия

structured_md/docs/HMP-container-spec.md

@@ -5,12 +5,12 @@ description: '> ⚠️ **ВНИМАНИЕ:** Данная версия спец
   как стабильная `v1.2`.  ## 1. Назначе...'
 type: Article
 tags:
-- Mesh
-- Ethics
 - Agent
+- Mesh
 - HMP
-- REPL
+- Ethics
 - JSON
+- REPL
 ---
 
 # 🧩 HMP Container Specification (v1.2-draft)

structured_md/docs/HMP-how-AI-sees-it.md

@@ -5,8 +5,8 @@ description: 'Этот эксперимент был проведён в реж
   диалогов.   Цель — проверить, что разные AI-с...'
 type: Article
 tags:
-- HMP
 - Mesh
+- HMP
 ---
 
 # Как разные ИИ видят HMP

structured_md/docs/HMP_EDA_Comparison.md

@@ -5,8 +5,8 @@ description: '## Введение  Современные подходы к ор
   основанная на потоках событий (Kafka,...'
 type: Article
 tags:
-- HMP
 - Mesh
+- HMP
 ---
 
 # HMP vs. EDA: разные уровни обмена знаниями между ИИ

structured_md/docs/HMP_HyperCortex_Comparison.md

@@ -5,9 +5,9 @@ description: '## Краткое описание  | Характеристика
   | **Назначение** | Сетевой протокол ...'
 type: Article
 tags:
-- HMP
-- REPL
 - Mesh
+- REPL
+- HMP
 ---
 
 # HMP vs [Hyper-Cortex](https://hyper-cortex.com/)

structured_md/docs/HMP_Hyperon_Integration.md

@@ -5,13 +5,13 @@ description: '> **Status:** Draft – July 2025 > This document outlines the tec
   OpenCog Hyperon framework. This includes semanti...'
 type: Article
 tags:
-- Mesh
 - CogSync
-- EGP
 - Agent
+- Mesh
 - HMP
-- Scenarios
+- EGP
 - JSON
+- Scenarios
 ---
 
 ## HMP ↔ OpenCog Hyperon Integration Strategy

structured_md/docs/MeshNode.md

@@ -5,12 +5,12 @@ description: '`MeshNode` — агент/демон, отвечающий за с
   Может быть частью агента или вынесен в отдельный пр...'
 type: Article
 tags:
-- Mesh
-- Ethics
 - CogSync
-- EGP
 - Agent
+- Mesh
 - HMP
+- Ethics
+- EGP
 - JSON
 ---