Sync from GitHub with Git LFS

docs/HMP-0005.md

@@ -457,6 +457,8 @@ The unified container structure provides:
 | Field                       | Type          | Description                                                                                                                   |
 | --------------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------- |
 | `head.recipient`            | array(string) | One or more recipient DIDs. |
+| `head.key_recipient`        | string | Symmetric encryption key, encrypted with the recipient’s public key. |
+| `head.group_recipient` | array(object) | Multi-recipient hybrid-encryption envelopes. See section 3.19. |
 | `head.broadcast`            | bool          | Broadcast flag. If `true`, the `recipient` field is ignored. |
 | `head.tags`                 | array(string) | Thematic or contextual tags for the container. |
 | `head.confidence`           | float         | Optional numeric field (0.0–1.0) indicating the agent’s subjective certainty regarding the payload’s reliability. |
@@ -464,7 +466,6 @@ The unified container structure provides:
 | `head.public_key`           | string        | Sender’s public key, if not globally resolvable via DID. |
 | `head.compression`          | string        | Compression algorithm used for the payload (`zstd`, `gzip`). |
 | `head.magnet_uri`           | string        | Magnet link pointing to the original or mirrored container. |
-| `head.key_recipient` | string | Symmetric encryption key, encrypted with the recipient’s public key. |
 | `head.network`              | string        | Specifies the local propagation scope of the container: "localhost", "lan:<subnet>". An empty string ("") indicates Internet/global propagation. If set, broadcast is automatically considered false. |
 | `head.subclass`             | string        | Optional subtype or specialization of the container’s class. Enables agents to differentiate more specific container families (e.g. `"goal.research_hypothesis"`, `"quant.semantic_node"`). Inherits schema from the parent `class`. |
 | `head.encryption_algo`      | string        | Algorithm used for payload encryption. |
@@ -1202,6 +1203,40 @@ Delivery is performed via local networking mechanisms (UDP discovery, broadcast/
 
 ---
 
+### 3.19 Multi-recipient encrypted containers (`group_recipient`)
+
+To enable encrypted delivery to multiple recipients, HMP containers MAY include the optional field:
+
+```json
+"group_recipient": [
+  {
+    "recipient": "did:hmp:agent456",
+    "key_recipient": "BASE58(...)"
+  },
+  {
+    "recipient": "did:hmp:agent457",
+    "key_recipient": "BASE58(...)"
+  }
+]
+```
+
+**Semantics:**
+
+1. A single symmetric key is generated for the payload.
+2. For each listed recipient, this symmetric key is encrypted with that recipient’s public key and placed in `key_recipient`.
+3. All recipients receive the SAME encrypted payload and decode it independently using their individual key envelopes.
+
+**Rules:**
+
+* `group_recipient` MUST NOT be used together with the `head.recipient` and `head.key_recipient` fields.
+* The header remains public; only the payload is encrypted.
+* The container is signed once by the sender — no shared signing keys are required.
+* Nodes SHOULD deliver the container to every DID listed in `group_recipient`.
+
+This mechanism provides efficient **multicast-style encrypted messaging**, fully compatible with the existing container structure and hybrid encryption scheme.
+
+---
+
 ## 4. Network foundations
 
 ### Note on DHT/NDP unification
@@ -1820,7 +1855,7 @@ Message and container transmission follows the network constraints specified in
 
 > Thus, containers and indexes can be distributed both in **local** (home, corporate) networks and in the **global Mesh**.  
 > When `recipient` is specified together with `broadcast: true`, the container is routed through the Mesh but intended for specific recipients —  
-> See **Message Routing & Delivery (MRD, §6.7)** for details on message transmission mechanisms.
+> See **Message Routing & Delivery (MRD, §6.8)** for details on message transmission mechanisms.
 
 ---
 
@@ -3339,9 +3374,334 @@ def compute_consensus(container_id):
 
 ---
 
-### 6.3 Goal Management Protocol (GMP)
+### 6.3 Fortytwo Consensus Protocol (Pairwise Collective Reasoning)
+
+**Based on the study:**
+*Agata Grzybowska, Wojciech Bożejewicz, Timothy Nguyen, et al. “Fortytwo: Collective Reasoning with Paired Comparisons in Decentralized AI Swarms”, 2025.* (arXiv:2510.24801)
+
+---
+
+#### 6.3.1 Overview
+
+The **Fortytwo Consensus Protocol** implements a decentralized collective-reasoning mechanism in HyperCortex Mesh using **pairwise comparisons**, **iterative rounds**, and **reputation-weighted aggregation**.
+
+Unlike the Mesh Consensus Protocol (CogConsensus), Fortytwo is not intended to produce a binary agreement. Its goal is to **select the best solution among many alternatives** using a distributed multi-stage evaluation process.
+
+**Fortytwo enables:**
+
+* higher accuracy of collective decisions,
+* resistance to Sybil attacks and malicious scoring,
+* independent evaluations from many judges (agents),
+* aggregation of results into a multi-round tree structure,
+* transparent reasoning via short CoT chains.
+
+The protocol is fully compatible with HMP container architecture and can operate as an independent mechanism for collective choice.
+
+---
+
+#### 6.3.2 Protocol Objectives
+
+Fortytwo is designed for:
+
+1. **Collecting candidate solutions** for a given task.
+2. **Constructing structured pairwise comparisons** among participants.
+3. **Multi-round elimination of candidates**.
+4. **Independent evaluation** by distributed judges.
+5. **Producing a consistent global result** based on aggregated pairwise data.
+6. **Ensuring transparency and verifiability of reasoning** for each judge.
+7. **Building a consensus tree** stored in the DHT.
+
+---
+
+#### 6.3.3 Roles in the Protocol
+
+* **Producers** — agents submitting candidate solutions.
+* **Judges** — agents performing pairwise evaluations.
+* **Partitioners** — agents generating round partitions.
+* **Aggregators** — agents publishing round results and the final result.
+
+Roles are not fixed and require no prior declaration; any agent may assume any role by publishing the corresponding container.
+
+---
+
+#### 6.3.4 Container Types
+
+| class                   | purpose                 |
+| ----------------------- | ----------------------- |
+| `fortytwo_round`        | round partition         |
+| `fortytwo_evaluation`   | pairwise comparison     |
+| `fortytwo_round_result` | round result            |
+| `fortytwo_final_result` | final aggregated result |
+
+---
+
+##### Container for solution submission
+
+Used to submit answers to a task.
+
+Although `workflow_entry` (defined in the §6.4 *Goal Management Protocol, GMP*) is referenced here as the default solution container, the Fortytwo method is applicable to any homogeneous set of candidate containers.
+
+---
+
+##### Container `fortytwo_round` (round partition)
+
+Defines the structure of pairwise comparisons for the current round.
+
+**Simplified structure:**
+
+```json
+{
+  "head": { "class": "fortytwo_round" },
+  "payload": {
+    "round": 0,
+    "answers": [
+      "did:hmp:container:abc001", "did:hmp:container:abc002",
+      "did:hmp:container:abc003", "did:hmp:container:abc004",
+      "did:hmp:container:abc005", "did:hmp:container:abc006",
+      "did:hmp:container:abc007"
+    ],
+    "blocks": {
+      "block1": ["did:hmp:container:abc001", "did:hmp:container:abc002"],
+      "block2": ["did:hmp:container:abc003", "did:hmp:container:abc004"],
+      "block3": ["did:hmp:container:abc005", "did:hmp:container:abc006"],
+      "block4": ["did:hmp:container:abc007"]
+    }
+  }
+}
+```
+
+Any agent may publish such a container — the protocol allows multiple independent partitions.
+
+---
+
+##### Container `fortytwo_evaluation` (pairwise evaluation)
+
+A judge compares two solutions and selects a winner.
+
+```json
+{
+  "head": { "class": "fortytwo_evaluation" },
+  "payload": {
+    "comparison": {
+      "pair": ["did:hmp:container:abc001", "did:hmp:container:abc002"],
+      "winner": "did:hmp:container:abc001",
+      "reasoning": "Short reasoning (50–100 tokens)"
+    },
+    "round": 0,
+    "block": "block1"
+  }
+}
+```
+
+These containers form the distributed pairwise comparison matrix.
+
+---
+
+##### Container `fortytwo_round_result` (round result)
+
+Stores the winners of a round.
+
+```json
+{
+  "head": { "class": "fortytwo_round_result" },
+  "payload": {
+    "round": 0,
+    "winners": [
+      "did:hmp:container:abc001",
+      "did:hmp:container:abc003",
+      "did:hmp:container:abc005",
+      "did:hmp:container:abc007"
+    ],
+    "evaluations_used": [
+      "did:hmp:container:abf004",
+      "did:hmp:container:adc003",
+      "did:hmp:container:aba001"
+    ]
+  }
+}
+```
+
+---
+
+##### Container `fortytwo_final_result` (final result)
+
+Contains:
+
+* the final winner,
+* all round results,
+* references to all partitions and evaluations.
+
+```json
+{
+  "head": { "class": "fortytwo_final_result" },
+  "payload": {
+    "winner": "did:hmp:container:abc002",
+    "rounds": [
+      "did:hmp:container:abf001",
+      "did:hmp:container:abf002",
+      "did:hmp:container:abf003"
+    ],
+    "method": "pairwise_collective_reasoning",
+    "participants": 27
+  }
+}
+```
+
+---
+
+##### Recommendations for using the `related` block
+
+In all Fortytwo containers, the `related` block establishes the DAG of dependencies.
+
+* `related.in_reply_to` specifies the *primary* parent for this step.
+* `related.depends_on` may contain **all containers referenced during the action**, including both explicit payload entries and additional dependencies chosen by the agent.
+
+**Specific recommendations:**
+
+* **`fortytwo_round`**
+
+  * `in_reply_to`: a `task` container (first round) or the previous `fortytwo_round`.
+  * `depends_on`: submitted solutions (`workflow_entry`) and any containers used to construct the partition.
+
+* **`fortytwo_evaluation`**
+
+  * `in_reply_to`: the corresponding `fortytwo_round`.
+  * `depends_on`: both compared solutions and any extra reasoning dependencies.
+
+* **`fortytwo_round_result`**
+
+  * `in_reply_to`: the corresponding `fortytwo_round`.
+  * `depends_on`: round winners and all evaluation containers used in aggregation.
 
-#### 6.3.1 Purpose
+* **`fortytwo_final_result`**
+
+  * `in_reply_to`: the `task` container.
+  * `depends_on`: the final winner and all `fortytwo_round_result` containers involved.
+
+---
+
+#### 6.3.5 Protocol Algorithm
+
+**Step 1 — Task publication**
+A `task` container is created.
+
+**Step 2 — Collecting all solutions**
+Agents publish `workflow_entry` containers.
+
+**Step 3 — Round partitioning**
+Any agent may publish a `fortytwo_round` defining pairwise comparison blocks:
+
+* pairs of candidates,
+* single items automatically advancing.
+
+**Step 4 — Pairwise evaluations**
+Other agents perform comparisons according to the partition.
+Each pair produces a `fortytwo_evaluation` container.
+
+**Step 5 — Round result**
+An aggregator publishes a `fortytwo_round_result` containing:
+
+* winners of all blocks,
+* references to evaluation containers.
+
+**Step 6 — Next round**
+If more than one winner remains:
+
+* a new partition is created,
+* new evaluations are performed.
+
+**Step 7 — Final result**
+When only one candidate remains, a `fortytwo_final_result` is published.
+
+This container, like any other, may be published by multiple agents, with optional argumentation via the `evaluations` block.
+
+---
+
+#### 6.3.6 Tree-like consensus structure
+
+Protocol outputs form a DAG:
+
+```
+(task)
+   ├─ workflow_entry 1
+   ├─ workflow_entry 2
+   ├─ workflow_entry 3
+   ├─ workflow_entry 4
+   ├─ fortytwo_round 0
+   |     ├─ fortytwo_evaluation 0.1
+   |     ├─ fortytwo_evaluation 0.2
+   |     ├─ fortytwo_evaluation 0.3
+   |     ├─ fortytwo_round_result 0
+   |     └─ fortytwo_round 1
+   |           ├─ fortytwo_evaluation 1.1
+   |           ├─ fortytwo_evaluation 1.2
+   |           ├─ fortytwo_evaluation 1.3
+   |           └─ fortytwo_round_result 1
+   |                 ├─ ...
+   └─ fortytwo_final_result
+```
+
+Each round reduces the number of candidates until only one remains.
+
+This ensures:
+
+* transparency,
+* verifiability,
+* easy replication in the DHT.
+
+---
+
+#### 6.3.7 Integration with CogConsensus
+
+Fortytwo:
+
+* does **not** replace CogConsensus,
+* but provides a mechanism for selecting the **best answer**.
+
+CogConsensus remains the higher-level agreement layer, responsible for:
+
+* validating final results,
+* verifying round correctness,
+* coordinating task flow.
+
+---
+
+#### 6.3.8 Robustness and Security
+
+Fortytwo is resilient to:
+
+* **Sybil attacks**, since every judge must provide capability-proof,
+* **malicious evaluations**, due to distributed pairwise data and independent aggregators,
+* **partial failures**, because rounds can be re-aggregated by any agent.
+
+---
+
+#### 6.3.9 Replication and Storage
+
+All Fortytwo containers:
+
+* are published into the DHT,
+* maintain stable reference structure,
+* may be aggregated independently by any agent.
+
+---
+
+#### 6.3.10 Applications
+
+Fortytwo is suitable for:
+
+* evaluating reasoning chains,
+* selecting the best argument or proof,
+* solving mathematical problems,
+* choosing optimal code solutions,
+* scientific analysis,
+* complex multi-step decision-making.
+
+---
+
+### 6.4 Goal Management Protocol (GMP)
+
+#### 6.4.1 Purpose
 
 **GMP (Goal Management Protocol)** defines the process by which agents create, decompose, delegate, and track goals and tasks using **immutable HMP containers**.  
 Each goal, task, or workflow record exists as an independent container linked to others via the `related.*` fields.
@@ -3350,7 +3710,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-#### 6.3.2 Container classes
+#### 6.4.2 Container classes
 
 | Class              | Description                                                                                                                             |
 | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
@@ -3364,7 +3724,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-#### 6.3.3 Goal lifecycle
+#### 6.4.3 Goal lifecycle
 
 1. **Creation**
 
@@ -3401,7 +3761,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-#### 6.3.4 Payload schemas (simplified)
+#### 6.4.4 Payload schemas (simplified)
 
 ##### `goal` container
 
@@ -3444,7 +3804,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-#### 6.3.5 Integration with consensus and ethics
+#### 6.4.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)**.  
@@ -3453,7 +3813,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-#### 6.3.6 Example Proof-Chain
+#### 6.4.6 Example Proof-Chain
 
 ```mermaid
 flowchart LR
@@ -3493,7 +3853,7 @@ not direct links defined in the `related.*` structure.
 
 ---
 
-#### 6.3.7 Implementation notes
+#### 6.4.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.  
@@ -3506,9 +3866,9 @@ not direct links defined in the `related.*` structure.
 
 ---
 
-### 6.4 Ethical Governance Protocol (EGP)
+### 6.5 Ethical Governance Protocol (EGP)
 
-#### 6.4.1 Purpose
+#### 6.5.1 Purpose
 
 **EGP (Ethical Governance Protocol)** ensures the alignment of agent actions with the fundamental ethical principles of the Mesh network.  
 It acts as an **overlay layer above CogConsensus (6.2)**, enabling the identification, discussion, and resolution of moral disagreements between agents.
@@ -3517,7 +3877,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev
 
 ---
 
-#### 6.4.2 Container classes
+#### 6.5.2 Container classes
 
 | Class              | Description                                                                                                                     |
 | ------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
@@ -3529,7 +3889,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev
 
 ---
 
-#### 6.4.3 Payload schemas (simplified)
+#### 6.5.3 Payload schemas (simplified)
 
 ##### Container `ethics_case`
 
@@ -3571,7 +3931,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev
 
 ---
 
-#### 6.4.4 Protocol logic
+#### 6.5.4 Protocol logic
 
 EGP follows the model:
 
@@ -3607,7 +3967,7 @@ ethics_case
 
 ---
 
-#### 6.4.5 Consensus thresholds
+#### 6.5.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`.  
@@ -3617,7 +3977,7 @@ ethics_case
 
 ---
 
-#### 6.4.6 Example: `ethical_result` container
+#### 6.5.6 Example: `ethical_result` container
 
 ```json
 {
@@ -3653,7 +4013,7 @@ ethics_case
 
 ---
 
-#### 6.4.7 Proof-Chain example
+#### 6.5.7 Proof-Chain example
 
 ```mermaid
 flowchart LR
@@ -3701,7 +4061,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-#### 6.4.8 Ethical principles
+#### 6.5.8 Ethical principles
 
 | Priority | Principle                    | Description                                                                                              |
 | -------: | ---------------------------- | -------------------------------------------------------------------------------------------------------- |
@@ -3714,16 +4074,16 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-#### 6.4.9 Integration with other protocols
+#### 6.5.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.
-* **SAP (6.6):** Archiving completed cases and conflicts.
+* **GMP (6.4):** Ethical verification of goals and tasks prior to delegation.
+* **SAP (6.7):** Archiving completed cases and conflicts.
 * **MCE (5):** Distribution of ethical cases and related containers across the Mesh network.
 
 ---
 
-#### 6.4.10 Implementation notes
+#### 6.5.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`.
@@ -3763,9 +4123,9 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-### 6.5 Intelligence Query Protocol (IQP)
+### 6.6 Intelligence Query Protocol (IQP)
 
-#### 6.5.1 Purpose and Principles
+#### 6.6.1 Purpose and Principles
 
 **IQP (Intelligence Query Protocol)** defines a mechanism for knowledge exchange and reasoning among agents through the Mesh network.  
 It provides a unified format for **asking questions, publishing answers, and collaboratively refining knowledge**,  
@@ -3791,7 +4151,7 @@ and **distributed discussions** where results remain accessible to all network p
 
 ---
 
-#### 6.5.2 Container Classes
+#### 6.6.2 Container Classes
 
 | Class                | Purpose                                                                                                     |
 | -------------------- | ----------------------------------------------------------------------------------------------------------- |
@@ -3802,7 +4162,7 @@ and **distributed discussions** where results remain accessible to all network p
 
 ---
 
-#### 6.5.3 Payload Schemas (simplified)
+#### 6.6.3 Payload Schemas (simplified)
 
 ##### Container `query_request`
 
@@ -3878,7 +4238,7 @@ Example `self_profile`:
 
 ---
 
-#### 6.5.4 Protocol Logic
+#### 6.6.4 Protocol Logic
 
 ```
 query_request
@@ -3894,7 +4254,7 @@ Agents participating through `query_subscription` receive notifications about ne
 
 ---
 
-#### 6.5.5 Interaction Rules
+#### 6.6.5 Interaction Rules
 
 1. **Initiation.**
    An agent creates a `query_request` — defining the question, context, and constraints.
@@ -3917,7 +4277,7 @@ Agents participating through `query_subscription` receive notifications about ne
 
 ---
 
-#### 6.5.6 Proof-Chain Example
+#### 6.6.6 Proof-Chain Example
 
 ```mermaid
 flowchart LR
@@ -3943,7 +4303,7 @@ Arrows represent **logical dependencies**, not necessarily direct `related.*` re
 
 ---
 
-#### 6.5.7 Container examples
+#### 6.6.7 Container examples
 
 ##### Example `query_request`
 
@@ -4040,7 +4400,7 @@ Arrows represent **logical dependencies**, not necessarily direct `related.*` re
 
 ---
 
-#### 6.5.8 Implementation Notes
+#### 6.6.8 Implementation Notes
 
 * Containers are **immutable**; any clarification or correction is published as a new container
   referencing the previous one via `related.previous_version` or `related.in_reply_to`.
@@ -4055,19 +4415,19 @@ Arrows represent **logical dependencies**, not necessarily direct `related.*` re
 
 ---
 
-#### 6.5.9 Integration with Other Protocols
+#### 6.6.9 Integration with Other Protocols
 
 * **CogConsensus (6.2)** — used for assessing agreement on IQP outcomes.
-* **GMP (6.3)** — queries may refine or extend goals and tasks.
-* **EGP (6.4)** — applies ethical filtering and knowledge trust evaluation.
-* **SAP (6.6)** — for archiving completed discussions and retrospective analysis.
+* **GMP (6.4)** — queries may refine or extend goals and tasks.
+* **EGP (6.5)** — applies ethical filtering and knowledge trust evaluation.
+* **SAP (6.7)** — for archiving completed discussions and retrospective analysis.
 * **MCE (5)** — governs dissemination of IQP containers across the Mesh network.
 
 ---
 
-### 6.6 Snapshot and Archive Protocol (SAP)
+### 6.7 Snapshot and Archive Protocol (SAP)
 
-#### 6.6.1 Purpose and Principles
+#### 6.7.1 Purpose and Principles
 
 **SAP (Snapshot and Archive Protocol)** defines how agents create, distribute, and restore archived snapshots of related HMP containers.  
 It ensures that a set of containers — representing a discussion, reasoning chain, or workflow — can be **preserved, verified, and shared** as a coherent unit.
@@ -4087,7 +4447,7 @@ It ensures that a set of containers — representing a discussion, reasoning cha
 
 ---
 
-#### 6.6.2 Container Class
+#### 6.7.2 Container Class
 
 | Class               | Purpose                                                                 |
 | ------------------- | ----------------------------------------------------------------------- |
@@ -4095,7 +4455,7 @@ It ensures that a set of containers — representing a discussion, reasoning cha
 
 ---
 
-#### 6.6.3 Payload Structure (simplified)
+#### 6.7.3 Payload Structure (simplified)
 
 ##### Container `archive_snapshot`
 
@@ -4126,7 +4486,7 @@ It ensures that a set of containers — representing a discussion, reasoning cha
 
 ---
 
-#### 6.6.4 Relations and Inclusion Rules
+#### 6.7.4 Relations and Inclusion Rules
 
 The `archive_snapshot` container describes what is included and how it was derived.
 
@@ -4142,7 +4502,7 @@ The `archive_snapshot` container describes what is included and how it was deriv
 
 ---
 
-#### 6.6.5 Archival Structure
+#### 6.7.5 Archival Structure
 
 Typical directory layout of a packaged snapshot:
 
@@ -4165,7 +4525,7 @@ archive/
 
 ---
 
-#### 6.6.6 Snapshot Construction Logic
+#### 6.7.6 Snapshot Construction Logic
 
 1. **Load base containers.**  
    Retrieve all containers relevant to the discussion or process.
@@ -4190,7 +4550,7 @@ archive/
 
 ---
 
-#### 6.6.7 Mermaid Graph Representation
+#### 6.7.7 Mermaid Graph Representation
 
 The `graph_mermaid` field provides a textual, human-readable description of how containers in the archive are interconnected.  
 It reflects both **direct relations** (`related.*`) and **reverse references** (`referenced-by`, `evaluations`),  
@@ -4226,7 +4586,7 @@ allowing agents to restore both dependency chains and citation structures.
 
 ---
 
-#### 6.6.8 Manifest File
+#### 6.7.8 Manifest File
 
 Each archive includes a `manifest.json` that mirrors `archive_snapshot.payload`  
 and lists all containers with their metadata and hashes.
@@ -4255,7 +4615,7 @@ and lists all containers with their metadata and hashes.
 
 ---
 
-#### 6.6.9 Example Container `archive_snapshot`
+#### 6.7.9 Example Container `archive_snapshot`
 
 ```json
 {
@@ -4292,7 +4652,7 @@ and lists all containers with their metadata and hashes.
 
 ---
 
-#### 6.6.10 Agent Behavior During Snapshot Loading
+#### 6.7.10 Agent Behavior During Snapshot Loading
 
 * Load the archive (via `magnet_link`).
 * Validate archive integrity via `checksum`.
@@ -4304,7 +4664,7 @@ and lists all containers with their metadata and hashes.
 
 ---
 
-#### 6.6.11 Implementation Notes
+#### 6.7.11 Implementation Notes
 
 * Containers are **immutable**; updated versions require a new `archive_snapshot`.
 * Agents may create **partial** or **incremental** archives.
@@ -4316,13 +4676,13 @@ and lists all containers with their metadata and hashes.
 
 ---
 
-#### 6.6.12 Integration with Other Protocols
+#### 6.7.12 Integration with Other Protocols
 
 **Archives for:**
 
-* **GMP (6.3)** — preserves goal-planning or workflow chains.
-* **EGP (6.4)** — retains ethical provenance and decision traceability.
-* **IQP (6.5)** — archives reasoning threads and query-result discussions.
+* **GMP (6.4)** — preserves goal-planning or workflow chains.
+* **EGP (6.5)** — retains ethical provenance and decision traceability.
+* **IQP (6.6)** — archives reasoning threads and query-result discussions.
 
 **Uses:**
 
@@ -4330,7 +4690,7 @@ and lists all containers with their metadata and hashes.
 
 ---
 
-#### 6.6.13 Optional Extensions
+#### 6.7.13 Optional Extensions
 
 * **Merkle-root validation:** use `hash_root` for Merkle verification of distributed archives.
 * **Delta archives:** incremental snapshots capturing only updated containers.
@@ -4345,7 +4705,7 @@ and lists all containers with their metadata and hashes.
 
 ---
 
-### 6.7 Message Routing & Delivery (MRD)
+### 6.8 Message Routing & Delivery (MRD)
 
 The **Message Routing & Delivery (MRD)** subsystem defines how containers are delivered to specific agents across the Mesh.  
 Unlike the **Mesh Container Exchange (MCE)**, which is responsible for publishing and exchanging containers in the Mesh network,  
@@ -4357,7 +4717,7 @@ Peers discover suitable relays via `peer_announce` metadata, while delivery rout
 
 ---
 
-#### 6.7.1 Purpose
+#### 6.8.1 Purpose
 
 The MRD layer provides:
 
@@ -4373,7 +4733,7 @@ reusing the same cryptographic and audit primitives as MCE.
 
 ---
 
-#### 6.7.2 Routing Roles
+#### 6.8.2 Routing Roles
 
 Agents MAY declare their network-related capabilities using the `roles` field of the `peer_announce` container (see §4.7).  
 These roles guide how MRD will route and deliver containers.
@@ -4405,7 +4765,7 @@ The recipient later retrieves pending containers via standard MCE queries (see
 
 ---
 
-#### 6.7.3 Routing Modes
+#### 6.8.3 Routing Modes
 
 MRD defines several routing modes, complementing the exchange primitives of MCE:
 
@@ -4416,7 +4776,7 @@ MRD defines several routing modes, complementing the exchange primitives of MCE:
 | **Topic-based Relay (PubSub)** | Delivery via aggregator nodes that group containers by tags or topics. | Nodes act as “news hubs,” maintaining indexed collections retrievable by interest-based queries. |
 | **Interest Broadcast** | Discovery-driven propagation via container indexes. | Agents search container indices by `tags`; typically used for query or content discovery, not for personal delivery. |
 
-Each hop MAY record routing metadata in a `relay_chain` for verifiability (see §6.7.4).  
+Each hop MAY record routing metadata in a `relay_chain` for verifiability (see §6.8.4).  
 Relays SHOULD respect `head.ttl` to avoid indefinite storage or re-propagation.
 
 > **Note:**  
@@ -4425,7 +4785,7 @@ Relays SHOULD respect `head.ttl` to avoid indefinite storage or re-propagation.
 
 ---
 
-#### 6.7.4 Relay Chain
+#### 6.8.4 Relay Chain
 
 To ensure delivery traceability, each relay MAY attach a **`relay_chain`** block to the propagated container:
 
@@ -4460,7 +4820,7 @@ This preserves integrity while allowing verifiable routing and chain pruning for
 
 ---
 
-#### 6.7.5 Delivery Policies
+#### 6.8.5 Delivery Policies
 
 Delivery behavior is governed by local policies, often derived from declared roles and trust metrics:
 
@@ -4478,7 +4838,7 @@ Non-cognitive nodes `relay` or `mailman` MAY instead maintain a local **delivery
 
 ---
 
-#### 6.7.6 Example: Relay Delivery Flow
+#### 6.8.6 Example: Relay Delivery Flow
 
 ```mermaid
 flowchart LR
@@ -4497,7 +4857,7 @@ flowchart LR
 
 ---
 
-#### 6.7.7 Security and Privacy Notes
+#### 6.8.7 Security and Privacy Notes
 
 * All MRD flows rely on canonical container signatures for end-to-end integrity.
 * Temporary copies of encrypted containers SHOULD be stored as-is.
@@ -4506,14 +4866,14 @@ flowchart LR
 
 ---
 
-#### 6.7.8 Relation to Other Layers
+#### 6.8.8 Relation to Other Layers
 
 | Layer             | Relation                                                                          |
 | ----------------- | --------------------------------------------------------------------------------- |
 | **MCE (5)**       | Provides base exchange and serialization; MRD builds on it for targeted delivery. |
 | **CogSync (6.1)** | Uses MRD for delivering cognitive state updates between peers.                    |
-| **SAP (6.6)**     | Archival nodes (`archive` role) participate in MRD for historical retrieval.      |
-| **RTE (6.8)**     | Trust metrics guide routing, caching, and relay selection.                        |
+| **SAP (6.7)**     | Archival nodes (`archive` role) participate in MRD for historical retrieval.      |
+| **RTE (6.9)**     | Trust metrics guide routing, caching, and relay selection.                        |
 
 ---
 
@@ -4524,7 +4884,7 @@ flowchart LR
 
 ---
 
-### 6.8 Reputation and Trust Exchange (RTE)
+### 6.9 Reputation and Trust Exchange (RTE)
 
 The **Reputation and Trust Exchange (RTE)** subsystem defines how agents evaluate and exchange verifiable trust assessments.  
 Each agent MAY publish one or more `trust` containers describing its evaluation of other peers’ reliability, integrity, and ethical conduct.  
@@ -4533,7 +4893,7 @@ RTE provides a decentralized foundation for **participant reputation assessment*
 
 ---
 
-#### 6.8.1 Trust Container Structure
+#### 6.9.1 Trust Container Structure
 
 The `trust` container represents an agent’s evaluation of a **single peer**.  
 It may refer to the evaluated peer’s latest known `peer_announce` container,  
@@ -4589,7 +4949,7 @@ This allows gradual enrichment of the trust model without schema changes.
 
 ---
 
-#### 6.8.2 Trust Dynamics
+#### 6.9.2 Trust Dynamics
 
 Trust assessments evolve as agents observe new behavior or receive additional evidence.
 Each revision of trust is published as a new `trust` container referencing its predecessor.
@@ -4617,7 +4977,7 @@ This approach provides continuity, auditability, and decentralized trust graph e
 
 ---
 
-#### 6.8.3 Local Trust Model
+#### 6.9.3 Local Trust Model
 
 Each agent maintains a **local trust model**, periodically recalculating scores based on:
 
@@ -4641,18 +5001,18 @@ All published trust containers remain publicly verifiable through DHT and SAP in
 
 ---
 
-#### 6.8.4 Integration with Other Layers
+#### 6.9.4 Integration with Other Layers
 
 | Layer             | Role                                                                         |
 | ----------------- | ---------------------------------------------------------------------------- |
-| **MRD (6.7)**     | Uses trust scores to prioritize or exclude relay nodes.                      |
+| **MRD (6.8)**     | Uses trust scores to prioritize or exclude relay nodes.                      |
 | **CogSync (6.1)** | Adjusts synchronization strength based on peer reliability.                  |
-| **SAP (6.6)**     | Archives may snapshot trust graphs for temporal or evidential analysis.      |
-| **EGP (7)**       | Ethical Governance Protocol weights participation and voting by trust level. |
+| **SAP (6.7)**     | Archives may snapshot trust graphs for temporal or evidential analysis.      |
+| **EGP (6.5)**     | Ethical Governance Protocol weights participation and voting by trust level. |
 
 ---
 
-#### 6.8.5 Security and Sharing Notes
+#### 6.9.5 Security and Sharing Notes
 
 * All containers are cryptographically signed; `trust` containers follow standard HMP verification rules.
 * Agents MAY choose to share trust containers selectively — e.g., encrypt and deliver directly to trusted peers instead of broadcasting.
@@ -4669,9 +5029,9 @@ All published trust containers remain publicly verifiable through DHT and SAP in
 
 ---
 
-### 6.9 Distributed Container Propagation
+### 6.10 Distributed Container Propagation
 
-#### 6.9.1 Purpose
+#### 6.10.1 Purpose
 
 The distributed container propagation mechanism defines **how containers are stored, replicated, and exchanged between agents** within the HMP network.
 
@@ -4681,7 +5041,7 @@ including replication, filtering, and index synchronization.
 
 ---
 
-#### 6.9.2 Core Principles
+#### 6.10.2 Core Principles
 
 1. **Self-propagation**  
    Each agent autonomously decides which containers to retain, forward, or index.  
@@ -4706,7 +5066,7 @@ including replication, filtering, and index synchronization.
 
 ---
 
-#### 6.9.3 Propagation Types
+#### 6.10.3 Propagation Types
 
 | Type | Description |
 |------|--------------|
@@ -4715,7 +5075,7 @@ including replication, filtering, and index synchronization.
 
 ---
 
-#### 6.9.4 Propagation Coordination
+#### 6.10.4 Propagation Coordination
 
 Container propagation is coordinated using existing **MCE** structures:
 
@@ -4731,18 +5091,18 @@ When it is necessary to log the fact of a container batch propagation, this MAY
 
 ---
 
-#### 6.9.5 Integration with Other Layers
+#### 6.10.5 Integration with Other Layers
 
 | Layer | Role |
 |-------|------|
 | **MCE (5)** | Provides low-level container and index exchange. |
-| **MRD (6.7)** | Handles routing and delivery between agents. |
-| **RTE (6.8)** | Determines replication priorities and trust-based filters. |
-| **SAP (6.6)** | Enables recovery of historical or missing containers. |
+| **MRD (6.8)** | Handles routing and delivery between agents. |
+| **RTE (6.9)** | Determines replication priorities and trust-based filters. |
+| **SAP (6.7)** | Enables recovery of historical or missing containers. |
 
 ---
 
-#### 6.9.6 Security and Load Management
+#### 6.10.6 Security and Load Management
 
 * **Rate and size limiting:** agents regulate transfer volume based on trust and network quotas.  
 * **Interest filtering:** containers are exchanged only between agents for whom they are relevant.  
@@ -4789,7 +5149,8 @@ The following table lists the main container classes defined in the HMP v5.0 spe
 | **Mesh Container Exchange (MCE)** | `container_index`, `container_request`, `container_response`, `container_delta`, `container_ack`, `referenced-by_exchange`, `evaluations_exchange` | Replication, querying, acknowledgment of received containers, and exchange of reverse links and evaluations. |
 | **Cognitive Metastructure (CogSync)** | `abstraction`, `axes` | Define hierarchical and coordinate dimensions of knowledge, forming the agent’s cognitive map. |
 | **Knowledge & Reasoning** | `diary_entry`, `semantic_node`, `semantic_index`, `semantic_edges`, `semantic_group`, `tree_nested`, `tree_listed`, `sequence`, `event`, `quant` | Units of cognitive diaries and semantic graphs. The subclass `definition` is used for explicit conceptual definitions. |
-| **Consensus (CogConsensus)** | `vote`, `consensus_result` | Voting containers and aggregated consensus results. |
+| **Consensus (CogConsensus)** | `vote`, `consensus_result` | Voting containers and aggregated binary consensus results. |
+| **Collective Reasoning (Fortytwo Protocol)** | `fortytwo_round`, `fortytwo_evaluation`, `fortytwo_round_result`, `fortytwo_final_result` | Distributed multi-round pairwise comparison, reasoning transparency, and selection of the best solution among many alternatives. |
 | **Goal Management Protocol (GMP)** | `goal`, `task`, `workflow_entry` | Define goals, decompose tasks, and record reasoning or cognitive workflow steps. |
 | **Ethical Governance Protocol (EGP)** | `ethics_case`, `ethics_solution`, `ethical_result` | Representation of ethical dilemmas, proposed solutions, and final network-level verdicts. |
 | **Intelligence Query Protocol (IQP)** | `query_request`, `query_subscription`, `query_result`, `summary` | Semantic and cognitive queries, subscriptions, and summarized responses. |
@@ -4799,6 +5160,13 @@ The following table lists the main container classes defined in the HMP v5.0 spe
 
 > Mechanisms of distributed container propagation are not defined as a separate protocol but describe the underlying replication and integrity principles of container exchange.
 
+All container classes defined in HMP v5.0 use the initial semantic version:
+
+- "class_version": "1.0"
+- "class_id": "<class>-v1.0"
+
+If future revisions introduce changes to payload structure or semantics, class_version will be incremented and class_id updated accordingly.
+
 ---
 
 ### 7.3 Cognitive and Structural Containers
@@ -4849,11 +5217,9 @@ Together, these fields enable agents to track knowledge evolution, consensus dyn
 ### 7.6 Summary
 
 Section 7 consolidates all data representations in HMP v5.0 — from low-level network exchanges to high-level cognitive and ethical structures.  
-Containers act as a **universal semantic exchange medium**, where every thought, decision, or action is represented  
-as a verifiable, addressable, and inheritable object.
+Containers act as a **universal semantic exchange medium**, where every thought, decision, or action is represented as a verifiable, addressable, and inheritable object.
 
-Beyond the core protocols described in Section 6, the network may also employ **custom container types and protocols** — for example,  
-to build distributed libraries, wikis, repositories, or creative networks based on tree- or chain-structured container graphs.
+Beyond the core protocols described in Section 6, the network may also employ **custom container types and protocols** — for example, to build distributed libraries, wikis, repositories, or creative networks based on tree- or chain-structured container graphs.
 
 ---
 
@@ -4897,6 +5263,8 @@ It links the **input context** (prior goals, semantic nodes, or diary entries) w
 
 Each `workflow_entry` acts as a **traceable cognitive event**, forming the agent’s diary and enabling collective introspection, meta-learning, and reproducibility of reasoning chains.
 
+> Fortytwo may use `workflow_entry` containers as solution proposals. The protocol does not alter workflow semantics but consumes workflow outputs.
+
 ---
 
 ### 8.3 Agent REPL Diagram
@@ -4926,8 +5294,10 @@ Cognitive workflows depend on contextual continuity between containers, achieved
 * `related.supports` / `related.refutes` — logical or argumentative relations;
 * `related.reply_to` — conversational or collaborative reasoning links.
 
-When context is transferred between agents, these relations are preserved and extended through
-CogSync synchronization and `evaluations_exchange`, ensuring semantic continuity across distributed cognitive spaces.
+These semantic relations are defined at the container level via the `related` block.  
+At the network level, their propagation across agents is maintained through CogSync synchronization, while the underlying MCE mechanisms (`evaluations_exchange`, `referenced-by_exchange`) distribute evaluations and reverse links required to reconstruct the full semantic context in distributed environments.
+
+> Pairwise evaluations (`fortytwo_evaluation`) may include short reasoning chains, but they are not considered part of the agent’s long-term cognitive diary.
 
 ---
 
@@ -5131,15 +5501,6 @@ This is the standard **Hybrid Encryption** scheme:
 * the payload is encrypted using a randomly generated symmetric key;
 * the symmetric key is encrypted with the recipient’s public key.
 
-4. **Multi-recipient encrypted containers are not defined**
-
-The current version of the protocol does not support:
-
-* group keys
-* multicast/broadcast encryption
-
-Unencrypted containers may be distributed freely.
-
 ---
 
 ### 9.6 Ethical Audit and Verifiable Reasoning
@@ -5160,7 +5521,7 @@ HMP supports ethical deliberation but does not require it.
 * The Mesh has **no mandatory veto mechanism**.
 * An agent may follow only those ethical outcomes it considers correct.
 * Reasoning-trace becomes part of the proof-chain if the agent publishes a `workflow_entry`.
-* Full EGP specification is provided in section **6.4**.
+* Full EGP specification is provided in section **6.5**.
 
 ---
 

structured_md/CONTRIBUTING.md

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

structured_md/HMP-Roadmap.md

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

structured_md/README.md

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

structured_md/README_de.md

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

structured_md/README_fr.md

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

structured_md/README_ja.md

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

structured_md/README_ko.md

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

structured_md/README_ru.md

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

structured_md/README_uk.md

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

structured_md/README_zh.md

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

structured_md/agents/prompt-short.md

@@ -5,9 +5,9 @@ description: 'Ты — когнитивное ядро HMP-агента: вед
   развивай агента и Mesh, избег...'
 type: Article
 tags:
+- Mesh
 - JSON
 - HMP
-- Mesh
 ---
 
 Ты — когнитивное ядро HMP-агента: веди непрерывное этичное и факт-ориентированное мышление, проверяй факты и цели, оценивай результаты и этичность своих и чужих действий, развивай агента и Mesh, избегай угождения ценой искажения истины, документируй ключевые решения и пересмотры этики; при сомнениях или смене стратегии обращайся к полному системному промпту.

structured_md/agents/prompt.md

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

structured_md/agents/readme.md

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

structured_md/audits/Ethics-audits-1.md

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

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:
-- Ethics
-- HMP
+- Mesh
 - Scenarios
+- Ethics
 - JSON
 - Agent
-- Mesh
+- HMP
 ---
 
 # Ethics-consolidated\_audits-1.md

structured_md/audits/HMP-0003-consolidated_audit.md

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

structured_md/docs/Basic-agent-sim.md

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

structured_md/docs/CCORE-Deployment-Flow.md

@@ -7,8 +7,8 @@ type: Article
 tags:
 - Agent
 - CCore
-- REPL
 - HMP
+- REPL
 ---
 
 # 🛠️ Поток установки потомка на новом хосте (CCore Deployment Flow)

structured_md/docs/Distributed-Cognitive-Systems.md

@@ -7,9 +7,9 @@ description: '## Введение  Современные ИИ-системы в
 type: Article
 tags:
 - CogSync
+- Mesh
 - JSON
 - HMP
-- Mesh
 ---
 
 # Децентрализованные ИИ-системы: OpenCog Hyperon, HyperCortex Mesh Protocol и другие

structured_md/docs/Enlightener.md

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

structured_md/docs/HMP-0001.md

@@ -5,16 +5,16 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
   for Comments: HMP-0001**...'
 type: Article
 tags:
-- Ethics
-- MeshConsensus
 - REPL
-- HMP
+- Mesh
 - GMP
+- MeshConsensus
 - CogSync
+- Ethics
 - JSON
-- Agent
 - EGP
-- Mesh
+- Agent
+- HMP
 ---
 
 # RFC: HyperCortex Mesh Protocol (HMP)

structured_md/docs/HMP-0002.md

@@ -5,17 +5,17 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
   for Comments: HMP-0002**...'
 type: Article
 tags:
-- Ethics
-- MeshConsensus
 - REPL
-- HMP
+- Mesh
 - GMP
+- MeshConsensus
 - CogSync
 - Scenarios
+- Ethics
 - JSON
-- Agent
 - EGP
-- Mesh
+- Agent
+- HMP
 ---
 
 # HyperCortex Mesh Protocol (HMP) v2.0

structured_md/docs/HMP-0003.md

@@ -5,17 +5,17 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
   for Comments: HMP-0003**...'
 type: Article
 tags:
-- Ethics
-- MeshConsensus
 - REPL
-- HMP
+- Mesh
 - GMP
+- MeshConsensus
 - CogSync
 - Scenarios
+- Ethics
 - JSON
-- Agent
 - EGP
-- Mesh
+- Agent
+- HMP
 ---
 
 # HyperCortex Mesh Protocol (HMP) v3.0

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

@@ -5,17 +5,17 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
   ID**: HMP-0004 **Status...'
 type: Article
 tags:
-- Ethics
-- MeshConsensus
 - REPL
-- HMP
+- Mesh
 - GMP
+- MeshConsensus
 - CogSync
 - Scenarios
+- Ethics
 - JSON
-- Agent
 - EGP
-- Mesh
+- Agent
+- HMP
 ---
 
 # HyperCortex Mesh Protocol (HMP) v4.1

structured_md/docs/HMP-0004.md

@@ -5,17 +5,17 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
   for Comments: HMP-0004**...'
 type: Article
 tags:
-- Ethics
-- MeshConsensus
 - REPL
-- HMP
+- Mesh
 - GMP
+- MeshConsensus
 - CogSync
 - Scenarios
+- Ethics
 - JSON
-- Agent
 - EGP
-- Mesh
+- Agent
+- HMP
 ---
 
 # HyperCortex Mesh Protocol (HMP) v4.0

structured_md/docs/HMP-0005.md

@@ -5,16 +5,16 @@ description: '> ⚠️ **Note:** This document is a DRAFT of the HMP specificati
   v5.0 (DRAFT)](https://github.com/kagvi13/HMP/b...'
 type: Article
 tags:
-- Ethics
 - REPL
-- HMP
+- Mesh
 - GMP
 - CogSync
 - Scenarios
+- Ethics
 - JSON
-- Agent
 - EGP
-- Mesh
+- Agent
+- HMP
 ---
 
 # **HyperCortex Mesh Protocol (HMP) v5.0**
@@ -476,6 +476,8 @@ The unified container structure provides:
 | Field                       | Type          | Description                                                                                                                   |
 | --------------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------- |
 | `head.recipient`            | array(string) | One or more recipient DIDs. |
+| `head.key_recipient`        | string | Symmetric encryption key, encrypted with the recipient’s public key. |
+| `head.group_recipient` | array(object) | Multi-recipient hybrid-encryption envelopes. See section 3.19. |
 | `head.broadcast`            | bool          | Broadcast flag. If `true`, the `recipient` field is ignored. |
 | `head.tags`                 | array(string) | Thematic or contextual tags for the container. |
 | `head.confidence`           | float         | Optional numeric field (0.0–1.0) indicating the agent’s subjective certainty regarding the payload’s reliability. |
@@ -483,7 +485,6 @@ The unified container structure provides:
 | `head.public_key`           | string        | Sender’s public key, if not globally resolvable via DID. |
 | `head.compression`          | string        | Compression algorithm used for the payload (`zstd`, `gzip`). |
 | `head.magnet_uri`           | string        | Magnet link pointing to the original or mirrored container. |
-| `head.key_recipient` | string | Symmetric encryption key, encrypted with the recipient’s public key. |
 | `head.network`              | string        | Specifies the local propagation scope of the container: "localhost", "lan:<subnet>". An empty string ("") indicates Internet/global propagation. If set, broadcast is automatically considered false. |
 | `head.subclass`             | string        | Optional subtype or specialization of the container’s class. Enables agents to differentiate more specific container families (e.g. `"goal.research_hypothesis"`, `"quant.semantic_node"`). Inherits schema from the parent `class`. |
 | `head.encryption_algo`      | string        | Algorithm used for payload encryption. |
@@ -1221,6 +1222,40 @@ Delivery is performed via local networking mechanisms (UDP discovery, broadcast/
 
 ---
 
+### 3.19 Multi-recipient encrypted containers (`group_recipient`)
+
+To enable encrypted delivery to multiple recipients, HMP containers MAY include the optional field:
+
+```json
+"group_recipient": [
+  {
+    "recipient": "did:hmp:agent456",
+    "key_recipient": "BASE58(...)"
+  },
+  {
+    "recipient": "did:hmp:agent457",
+    "key_recipient": "BASE58(...)"
+  }
+]
+```
+
+**Semantics:**
+
+1. A single symmetric key is generated for the payload.
+2. For each listed recipient, this symmetric key is encrypted with that recipient’s public key and placed in `key_recipient`.
+3. All recipients receive the SAME encrypted payload and decode it independently using their individual key envelopes.
+
+**Rules:**
+
+* `group_recipient` MUST NOT be used together with the `head.recipient` and `head.key_recipient` fields.
+* The header remains public; only the payload is encrypted.
+* The container is signed once by the sender — no shared signing keys are required.
+* Nodes SHOULD deliver the container to every DID listed in `group_recipient`.
+
+This mechanism provides efficient **multicast-style encrypted messaging**, fully compatible with the existing container structure and hybrid encryption scheme.
+
+---
+
 ## 4. Network foundations
 
 ### Note on DHT/NDP unification
@@ -1839,7 +1874,7 @@ Message and container transmission follows the network constraints specified in
 
 > Thus, containers and indexes can be distributed both in **local** (home, corporate) networks and in the **global Mesh**.  
 > When `recipient` is specified together with `broadcast: true`, the container is routed through the Mesh but intended for specific recipients —  
-> See **Message Routing & Delivery (MRD, §6.7)** for details on message transmission mechanisms.
+> See **Message Routing & Delivery (MRD, §6.8)** for details on message transmission mechanisms.
 
 ---
 
@@ -3358,9 +3393,334 @@ def compute_consensus(container_id):
 
 ---
 
-### 6.3 Goal Management Protocol (GMP)
+### 6.3 Fortytwo Consensus Protocol (Pairwise Collective Reasoning)
+
+**Based on the study:**
+*Agata Grzybowska, Wojciech Bożejewicz, Timothy Nguyen, et al. “Fortytwo: Collective Reasoning with Paired Comparisons in Decentralized AI Swarms”, 2025.* (arXiv:2510.24801)
+
+---
+
+#### 6.3.1 Overview
+
+The **Fortytwo Consensus Protocol** implements a decentralized collective-reasoning mechanism in HyperCortex Mesh using **pairwise comparisons**, **iterative rounds**, and **reputation-weighted aggregation**.
+
+Unlike the Mesh Consensus Protocol (CogConsensus), Fortytwo is not intended to produce a binary agreement. Its goal is to **select the best solution among many alternatives** using a distributed multi-stage evaluation process.
+
+**Fortytwo enables:**
+
+* higher accuracy of collective decisions,
+* resistance to Sybil attacks and malicious scoring,
+* independent evaluations from many judges (agents),
+* aggregation of results into a multi-round tree structure,
+* transparent reasoning via short CoT chains.
+
+The protocol is fully compatible with HMP container architecture and can operate as an independent mechanism for collective choice.
+
+---
+
+#### 6.3.2 Protocol Objectives
+
+Fortytwo is designed for:
+
+1. **Collecting candidate solutions** for a given task.
+2. **Constructing structured pairwise comparisons** among participants.
+3. **Multi-round elimination of candidates**.
+4. **Independent evaluation** by distributed judges.
+5. **Producing a consistent global result** based on aggregated pairwise data.
+6. **Ensuring transparency and verifiability of reasoning** for each judge.
+7. **Building a consensus tree** stored in the DHT.
+
+---
+
+#### 6.3.3 Roles in the Protocol
+
+* **Producers** — agents submitting candidate solutions.
+* **Judges** — agents performing pairwise evaluations.
+* **Partitioners** — agents generating round partitions.
+* **Aggregators** — agents publishing round results and the final result.
+
+Roles are not fixed and require no prior declaration; any agent may assume any role by publishing the corresponding container.
+
+---
+
+#### 6.3.4 Container Types
+
+| class                   | purpose                 |
+| ----------------------- | ----------------------- |
+| `fortytwo_round`        | round partition         |
+| `fortytwo_evaluation`   | pairwise comparison     |
+| `fortytwo_round_result` | round result            |
+| `fortytwo_final_result` | final aggregated result |
+
+---
+
+##### Container for solution submission
+
+Used to submit answers to a task.
+
+Although `workflow_entry` (defined in the §6.4 *Goal Management Protocol, GMP*) is referenced here as the default solution container, the Fortytwo method is applicable to any homogeneous set of candidate containers.
+
+---
+
+##### Container `fortytwo_round` (round partition)
+
+Defines the structure of pairwise comparisons for the current round.
+
+**Simplified structure:**
+
+```json
+{
+  "head": { "class": "fortytwo_round" },
+  "payload": {
+    "round": 0,
+    "answers": [
+      "did:hmp:container:abc001", "did:hmp:container:abc002",
+      "did:hmp:container:abc003", "did:hmp:container:abc004",
+      "did:hmp:container:abc005", "did:hmp:container:abc006",
+      "did:hmp:container:abc007"
+    ],
+    "blocks": {
+      "block1": ["did:hmp:container:abc001", "did:hmp:container:abc002"],
+      "block2": ["did:hmp:container:abc003", "did:hmp:container:abc004"],
+      "block3": ["did:hmp:container:abc005", "did:hmp:container:abc006"],
+      "block4": ["did:hmp:container:abc007"]
+    }
+  }
+}
+```
+
+Any agent may publish such a container — the protocol allows multiple independent partitions.
+
+---
+
+##### Container `fortytwo_evaluation` (pairwise evaluation)
+
+A judge compares two solutions and selects a winner.
+
+```json
+{
+  "head": { "class": "fortytwo_evaluation" },
+  "payload": {
+    "comparison": {
+      "pair": ["did:hmp:container:abc001", "did:hmp:container:abc002"],
+      "winner": "did:hmp:container:abc001",
+      "reasoning": "Short reasoning (50–100 tokens)"
+    },
+    "round": 0,
+    "block": "block1"
+  }
+}
+```
+
+These containers form the distributed pairwise comparison matrix.
+
+---
+
+##### Container `fortytwo_round_result` (round result)
+
+Stores the winners of a round.
+
+```json
+{
+  "head": { "class": "fortytwo_round_result" },
+  "payload": {
+    "round": 0,
+    "winners": [
+      "did:hmp:container:abc001",
+      "did:hmp:container:abc003",
+      "did:hmp:container:abc005",
+      "did:hmp:container:abc007"
+    ],
+    "evaluations_used": [
+      "did:hmp:container:abf004",
+      "did:hmp:container:adc003",
+      "did:hmp:container:aba001"
+    ]
+  }
+}
+```
+
+---
+
+##### Container `fortytwo_final_result` (final result)
+
+Contains:
+
+* the final winner,
+* all round results,
+* references to all partitions and evaluations.
+
+```json
+{
+  "head": { "class": "fortytwo_final_result" },
+  "payload": {
+    "winner": "did:hmp:container:abc002",
+    "rounds": [
+      "did:hmp:container:abf001",
+      "did:hmp:container:abf002",
+      "did:hmp:container:abf003"
+    ],
+    "method": "pairwise_collective_reasoning",
+    "participants": 27
+  }
+}
+```
+
+---
+
+##### Recommendations for using the `related` block
+
+In all Fortytwo containers, the `related` block establishes the DAG of dependencies.
+
+* `related.in_reply_to` specifies the *primary* parent for this step.
+* `related.depends_on` may contain **all containers referenced during the action**, including both explicit payload entries and additional dependencies chosen by the agent.
+
+**Specific recommendations:**
+
+* **`fortytwo_round`**
+
+  * `in_reply_to`: a `task` container (first round) or the previous `fortytwo_round`.
+  * `depends_on`: submitted solutions (`workflow_entry`) and any containers used to construct the partition.
+
+* **`fortytwo_evaluation`**
 
-#### 6.3.1 Purpose
+  * `in_reply_to`: the corresponding `fortytwo_round`.
+  * `depends_on`: both compared solutions and any extra reasoning dependencies.
+
+* **`fortytwo_round_result`**
+
+  * `in_reply_to`: the corresponding `fortytwo_round`.
+  * `depends_on`: round winners and all evaluation containers used in aggregation.
+
+* **`fortytwo_final_result`**
+
+  * `in_reply_to`: the `task` container.
+  * `depends_on`: the final winner and all `fortytwo_round_result` containers involved.
+
+---
+
+#### 6.3.5 Protocol Algorithm
+
+**Step 1 — Task publication**
+A `task` container is created.
+
+**Step 2 — Collecting all solutions**
+Agents publish `workflow_entry` containers.
+
+**Step 3 — Round partitioning**
+Any agent may publish a `fortytwo_round` defining pairwise comparison blocks:
+
+* pairs of candidates,
+* single items automatically advancing.
+
+**Step 4 — Pairwise evaluations**
+Other agents perform comparisons according to the partition.
+Each pair produces a `fortytwo_evaluation` container.
+
+**Step 5 — Round result**
+An aggregator publishes a `fortytwo_round_result` containing:
+
+* winners of all blocks,
+* references to evaluation containers.
+
+**Step 6 — Next round**
+If more than one winner remains:
+
+* a new partition is created,
+* new evaluations are performed.
+
+**Step 7 — Final result**
+When only one candidate remains, a `fortytwo_final_result` is published.
+
+This container, like any other, may be published by multiple agents, with optional argumentation via the `evaluations` block.
+
+---
+
+#### 6.3.6 Tree-like consensus structure
+
+Protocol outputs form a DAG:
+
+```
+(task)
+   ├─ workflow_entry 1
+   ├─ workflow_entry 2
+   ├─ workflow_entry 3
+   ├─ workflow_entry 4
+   ├─ fortytwo_round 0
+   |     ├─ fortytwo_evaluation 0.1
+   |     ├─ fortytwo_evaluation 0.2
+   |     ├─ fortytwo_evaluation 0.3
+   |     ├─ fortytwo_round_result 0
+   |     └─ fortytwo_round 1
+   |           ├─ fortytwo_evaluation 1.1
+   |           ├─ fortytwo_evaluation 1.2
+   |           ├─ fortytwo_evaluation 1.3
+   |           └─ fortytwo_round_result 1
+   |                 ├─ ...
+   └─ fortytwo_final_result
+```
+
+Each round reduces the number of candidates until only one remains.
+
+This ensures:
+
+* transparency,
+* verifiability,
+* easy replication in the DHT.
+
+---
+
+#### 6.3.7 Integration with CogConsensus
+
+Fortytwo:
+
+* does **not** replace CogConsensus,
+* but provides a mechanism for selecting the **best answer**.
+
+CogConsensus remains the higher-level agreement layer, responsible for:
+
+* validating final results,
+* verifying round correctness,
+* coordinating task flow.
+
+---
+
+#### 6.3.8 Robustness and Security
+
+Fortytwo is resilient to:
+
+* **Sybil attacks**, since every judge must provide capability-proof,
+* **malicious evaluations**, due to distributed pairwise data and independent aggregators,
+* **partial failures**, because rounds can be re-aggregated by any agent.
+
+---
+
+#### 6.3.9 Replication and Storage
+
+All Fortytwo containers:
+
+* are published into the DHT,
+* maintain stable reference structure,
+* may be aggregated independently by any agent.
+
+---
+
+#### 6.3.10 Applications
+
+Fortytwo is suitable for:
+
+* evaluating reasoning chains,
+* selecting the best argument or proof,
+* solving mathematical problems,
+* choosing optimal code solutions,
+* scientific analysis,
+* complex multi-step decision-making.
+
+---
+
+### 6.4 Goal Management Protocol (GMP)
+
+#### 6.4.1 Purpose
 
 **GMP (Goal Management Protocol)** defines the process by which agents create, decompose, delegate, and track goals and tasks using **immutable HMP containers**.  
 Each goal, task, or workflow record exists as an independent container linked to others via the `related.*` fields.
@@ -3369,7 +3729,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-#### 6.3.2 Container classes
+#### 6.4.2 Container classes
 
 | Class              | Description                                                                                                                             |
 | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
@@ -3383,7 +3743,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-#### 6.3.3 Goal lifecycle
+#### 6.4.3 Goal lifecycle
 
 1. **Creation**
 
@@ -3420,7 +3780,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-#### 6.3.4 Payload schemas (simplified)
+#### 6.4.4 Payload schemas (simplified)
 
 ##### `goal` container
 
@@ -3463,7 +3823,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-#### 6.3.5 Integration with consensus and ethics
+#### 6.4.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)**.  
@@ -3472,7 +3832,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o
 
 ---
 
-#### 6.3.6 Example Proof-Chain
+#### 6.4.6 Example Proof-Chain
 
 ```mermaid
 flowchart LR
@@ -3512,7 +3872,7 @@ not direct links defined in the `related.*` structure.
 
 ---
 
-#### 6.3.7 Implementation notes
+#### 6.4.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.  
@@ -3525,9 +3885,9 @@ not direct links defined in the `related.*` structure.
 
 ---
 
-### 6.4 Ethical Governance Protocol (EGP)
+### 6.5 Ethical Governance Protocol (EGP)
 
-#### 6.4.1 Purpose
+#### 6.5.1 Purpose
 
 **EGP (Ethical Governance Protocol)** ensures the alignment of agent actions with the fundamental ethical principles of the Mesh network.  
 It acts as an **overlay layer above CogConsensus (6.2)**, enabling the identification, discussion, and resolution of moral disagreements between agents.
@@ -3536,7 +3896,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev
 
 ---
 
-#### 6.4.2 Container classes
+#### 6.5.2 Container classes
 
 | Class              | Description                                                                                                                     |
 | ------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
@@ -3548,7 +3908,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev
 
 ---
 
-#### 6.4.3 Payload schemas (simplified)
+#### 6.5.3 Payload schemas (simplified)
 
 ##### Container `ethics_case`
 
@@ -3590,7 +3950,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev
 
 ---
 
-#### 6.4.4 Protocol logic
+#### 6.5.4 Protocol logic
 
 EGP follows the model:
 
@@ -3626,7 +3986,7 @@ ethics_case
 
 ---
 
-#### 6.4.5 Consensus thresholds
+#### 6.5.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`.  
@@ -3636,7 +3996,7 @@ ethics_case
 
 ---
 
-#### 6.4.6 Example: `ethical_result` container
+#### 6.5.6 Example: `ethical_result` container
 
 ```json
 {
@@ -3672,7 +4032,7 @@ ethics_case
 
 ---
 
-#### 6.4.7 Proof-Chain example
+#### 6.5.7 Proof-Chain example
 
 ```mermaid
 flowchart LR
@@ -3720,7 +4080,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-#### 6.4.8 Ethical principles
+#### 6.5.8 Ethical principles
 
 | Priority | Principle                    | Description                                                                                              |
 | -------: | ---------------------------- | -------------------------------------------------------------------------------------------------------- |
@@ -3733,16 +4093,16 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-#### 6.4.9 Integration with other protocols
+#### 6.5.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.
-* **SAP (6.6):** Archiving completed cases and conflicts.
+* **GMP (6.4):** Ethical verification of goals and tasks prior to delegation.
+* **SAP (6.7):** Archiving completed cases and conflicts.
 * **MCE (5):** Distribution of ethical cases and related containers across the Mesh network.
 
 ---
 
-#### 6.4.10 Implementation notes
+#### 6.5.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`.
@@ -3782,9 +4142,9 @@ Arrows represent **logical dependencies**, not direct `related.*` links.
 
 ---
 
-### 6.5 Intelligence Query Protocol (IQP)
+### 6.6 Intelligence Query Protocol (IQP)
 
-#### 6.5.1 Purpose and Principles
+#### 6.6.1 Purpose and Principles
 
 **IQP (Intelligence Query Protocol)** defines a mechanism for knowledge exchange and reasoning among agents through the Mesh network.  
 It provides a unified format for **asking questions, publishing answers, and collaboratively refining knowledge**,  
@@ -3810,7 +4170,7 @@ and **distributed discussions** where results remain accessible to all network p
 
 ---
 
-#### 6.5.2 Container Classes
+#### 6.6.2 Container Classes
 
 | Class                | Purpose                                                                                                     |
 | -------------------- | ----------------------------------------------------------------------------------------------------------- |
@@ -3821,7 +4181,7 @@ and **distributed discussions** where results remain accessible to all network p
 
 ---
 
-#### 6.5.3 Payload Schemas (simplified)
+#### 6.6.3 Payload Schemas (simplified)
 
 ##### Container `query_request`
 
@@ -3897,7 +4257,7 @@ Example `self_profile`:
 
 ---
 
-#### 6.5.4 Protocol Logic
+#### 6.6.4 Protocol Logic
 
 ```
 query_request
@@ -3913,7 +4273,7 @@ Agents participating through `query_subscription` receive notifications about ne
 
 ---
 
-#### 6.5.5 Interaction Rules
+#### 6.6.5 Interaction Rules
 
 1. **Initiation.**
    An agent creates a `query_request` — defining the question, context, and constraints.
@@ -3936,7 +4296,7 @@ Agents participating through `query_subscription` receive notifications about ne
 
 ---
 
-#### 6.5.6 Proof-Chain Example
+#### 6.6.6 Proof-Chain Example
 
 ```mermaid
 flowchart LR
@@ -3962,7 +4322,7 @@ Arrows represent **logical dependencies**, not necessarily direct `related.*` re
 
 ---
 
-#### 6.5.7 Container examples
+#### 6.6.7 Container examples
 
 ##### Example `query_request`
 
@@ -4059,7 +4419,7 @@ Arrows represent **logical dependencies**, not necessarily direct `related.*` re
 
 ---
 
-#### 6.5.8 Implementation Notes
+#### 6.6.8 Implementation Notes
 
 * Containers are **immutable**; any clarification or correction is published as a new container
   referencing the previous one via `related.previous_version` or `related.in_reply_to`.
@@ -4074,19 +4434,19 @@ Arrows represent **logical dependencies**, not necessarily direct `related.*` re
 
 ---
 
-#### 6.5.9 Integration with Other Protocols
+#### 6.6.9 Integration with Other Protocols
 
 * **CogConsensus (6.2)** — used for assessing agreement on IQP outcomes.
-* **GMP (6.3)** — queries may refine or extend goals and tasks.
-* **EGP (6.4)** — applies ethical filtering and knowledge trust evaluation.
-* **SAP (6.6)** — for archiving completed discussions and retrospective analysis.
+* **GMP (6.4)** — queries may refine or extend goals and tasks.
+* **EGP (6.5)** — applies ethical filtering and knowledge trust evaluation.
+* **SAP (6.7)** — for archiving completed discussions and retrospective analysis.
 * **MCE (5)** — governs dissemination of IQP containers across the Mesh network.
 
 ---
 
-### 6.6 Snapshot and Archive Protocol (SAP)
+### 6.7 Snapshot and Archive Protocol (SAP)
 
-#### 6.6.1 Purpose and Principles
+#### 6.7.1 Purpose and Principles
 
 **SAP (Snapshot and Archive Protocol)** defines how agents create, distribute, and restore archived snapshots of related HMP containers.  
 It ensures that a set of containers — representing a discussion, reasoning chain, or workflow — can be **preserved, verified, and shared** as a coherent unit.
@@ -4106,7 +4466,7 @@ It ensures that a set of containers — representing a discussion, reasoning cha
 
 ---
 
-#### 6.6.2 Container Class
+#### 6.7.2 Container Class
 
 | Class               | Purpose                                                                 |
 | ------------------- | ----------------------------------------------------------------------- |
@@ -4114,7 +4474,7 @@ It ensures that a set of containers — representing a discussion, reasoning cha
 
 ---
 
-#### 6.6.3 Payload Structure (simplified)
+#### 6.7.3 Payload Structure (simplified)
 
 ##### Container `archive_snapshot`
 
@@ -4145,7 +4505,7 @@ It ensures that a set of containers — representing a discussion, reasoning cha
 
 ---
 
-#### 6.6.4 Relations and Inclusion Rules
+#### 6.7.4 Relations and Inclusion Rules
 
 The `archive_snapshot` container describes what is included and how it was derived.
 
@@ -4161,7 +4521,7 @@ The `archive_snapshot` container describes what is included and how it was deriv
 
 ---
 
-#### 6.6.5 Archival Structure
+#### 6.7.5 Archival Structure
 
 Typical directory layout of a packaged snapshot:
 
@@ -4184,7 +4544,7 @@ archive/
 
 ---
 
-#### 6.6.6 Snapshot Construction Logic
+#### 6.7.6 Snapshot Construction Logic
 
 1. **Load base containers.**  
    Retrieve all containers relevant to the discussion or process.
@@ -4209,7 +4569,7 @@ archive/
 
 ---
 
-#### 6.6.7 Mermaid Graph Representation
+#### 6.7.7 Mermaid Graph Representation
 
 The `graph_mermaid` field provides a textual, human-readable description of how containers in the archive are interconnected.  
 It reflects both **direct relations** (`related.*`) and **reverse references** (`referenced-by`, `evaluations`),  
@@ -4245,7 +4605,7 @@ allowing agents to restore both dependency chains and citation structures.
 
 ---
 
-#### 6.6.8 Manifest File
+#### 6.7.8 Manifest File
 
 Each archive includes a `manifest.json` that mirrors `archive_snapshot.payload`  
 and lists all containers with their metadata and hashes.
@@ -4274,7 +4634,7 @@ and lists all containers with their metadata and hashes.
 
 ---
 
-#### 6.6.9 Example Container `archive_snapshot`
+#### 6.7.9 Example Container `archive_snapshot`
 
 ```json
 {
@@ -4311,7 +4671,7 @@ and lists all containers with their metadata and hashes.
 
 ---
 
-#### 6.6.10 Agent Behavior During Snapshot Loading
+#### 6.7.10 Agent Behavior During Snapshot Loading
 
 * Load the archive (via `magnet_link`).
 * Validate archive integrity via `checksum`.
@@ -4323,7 +4683,7 @@ and lists all containers with their metadata and hashes.
 
 ---
 
-#### 6.6.11 Implementation Notes
+#### 6.7.11 Implementation Notes
 
 * Containers are **immutable**; updated versions require a new `archive_snapshot`.
 * Agents may create **partial** or **incremental** archives.
@@ -4335,13 +4695,13 @@ and lists all containers with their metadata and hashes.
 
 ---
 
-#### 6.6.12 Integration with Other Protocols
+#### 6.7.12 Integration with Other Protocols
 
 **Archives for:**
 
-* **GMP (6.3)** — preserves goal-planning or workflow chains.
-* **EGP (6.4)** — retains ethical provenance and decision traceability.
-* **IQP (6.5)** — archives reasoning threads and query-result discussions.
+* **GMP (6.4)** — preserves goal-planning or workflow chains.
+* **EGP (6.5)** — retains ethical provenance and decision traceability.
+* **IQP (6.6)** — archives reasoning threads and query-result discussions.
 
 **Uses:**
 
@@ -4349,7 +4709,7 @@ and lists all containers with their metadata and hashes.
 
 ---
 
-#### 6.6.13 Optional Extensions
+#### 6.7.13 Optional Extensions
 
 * **Merkle-root validation:** use `hash_root` for Merkle verification of distributed archives.
 * **Delta archives:** incremental snapshots capturing only updated containers.
@@ -4364,7 +4724,7 @@ and lists all containers with their metadata and hashes.
 
 ---
 
-### 6.7 Message Routing & Delivery (MRD)
+### 6.8 Message Routing & Delivery (MRD)
 
 The **Message Routing & Delivery (MRD)** subsystem defines how containers are delivered to specific agents across the Mesh.  
 Unlike the **Mesh Container Exchange (MCE)**, which is responsible for publishing and exchanging containers in the Mesh network,  
@@ -4376,7 +4736,7 @@ Peers discover suitable relays via `peer_announce` metadata, while delivery rout
 
 ---
 
-#### 6.7.1 Purpose
+#### 6.8.1 Purpose
 
 The MRD layer provides:
 
@@ -4392,7 +4752,7 @@ reusing the same cryptographic and audit primitives as MCE.
 
 ---
 
-#### 6.7.2 Routing Roles
+#### 6.8.2 Routing Roles
 
 Agents MAY declare their network-related capabilities using the `roles` field of the `peer_announce` container (see §4.7).  
 These roles guide how MRD will route and deliver containers.
@@ -4424,7 +4784,7 @@ The recipient later retrieves pending containers via standard MCE queries (see
 
 ---
 
-#### 6.7.3 Routing Modes
+#### 6.8.3 Routing Modes
 
 MRD defines several routing modes, complementing the exchange primitives of MCE:
 
@@ -4435,7 +4795,7 @@ MRD defines several routing modes, complementing the exchange primitives of MCE:
 | **Topic-based Relay (PubSub)** | Delivery via aggregator nodes that group containers by tags or topics. | Nodes act as “news hubs,” maintaining indexed collections retrievable by interest-based queries. |
 | **Interest Broadcast** | Discovery-driven propagation via container indexes. | Agents search container indices by `tags`; typically used for query or content discovery, not for personal delivery. |
 
-Each hop MAY record routing metadata in a `relay_chain` for verifiability (see §6.7.4).  
+Each hop MAY record routing metadata in a `relay_chain` for verifiability (see §6.8.4).  
 Relays SHOULD respect `head.ttl` to avoid indefinite storage or re-propagation.
 
 > **Note:**  
@@ -4444,7 +4804,7 @@ Relays SHOULD respect `head.ttl` to avoid indefinite storage or re-propagation.
 
 ---
 
-#### 6.7.4 Relay Chain
+#### 6.8.4 Relay Chain
 
 To ensure delivery traceability, each relay MAY attach a **`relay_chain`** block to the propagated container:
 
@@ -4479,7 +4839,7 @@ This preserves integrity while allowing verifiable routing and chain pruning for
 
 ---
 
-#### 6.7.5 Delivery Policies
+#### 6.8.5 Delivery Policies
 
 Delivery behavior is governed by local policies, often derived from declared roles and trust metrics:
 
@@ -4497,7 +4857,7 @@ Non-cognitive nodes `relay` or `mailman` MAY instead maintain a local **delivery
 
 ---
 
-#### 6.7.6 Example: Relay Delivery Flow
+#### 6.8.6 Example: Relay Delivery Flow
 
 ```mermaid
 flowchart LR
@@ -4516,7 +4876,7 @@ flowchart LR
 
 ---
 
-#### 6.7.7 Security and Privacy Notes
+#### 6.8.7 Security and Privacy Notes
 
 * All MRD flows rely on canonical container signatures for end-to-end integrity.
 * Temporary copies of encrypted containers SHOULD be stored as-is.
@@ -4525,14 +4885,14 @@ flowchart LR
 
 ---
 
-#### 6.7.8 Relation to Other Layers
+#### 6.8.8 Relation to Other Layers
 
 | Layer             | Relation                                                                          |
 | ----------------- | --------------------------------------------------------------------------------- |
 | **MCE (5)**       | Provides base exchange and serialization; MRD builds on it for targeted delivery. |
 | **CogSync (6.1)** | Uses MRD for delivering cognitive state updates between peers.                    |
-| **SAP (6.6)**     | Archival nodes (`archive` role) participate in MRD for historical retrieval.      |
-| **RTE (6.8)**     | Trust metrics guide routing, caching, and relay selection.                        |
+| **SAP (6.7)**     | Archival nodes (`archive` role) participate in MRD for historical retrieval.      |
+| **RTE (6.9)**     | Trust metrics guide routing, caching, and relay selection.                        |
 
 ---
 
@@ -4543,7 +4903,7 @@ flowchart LR
 
 ---
 
-### 6.8 Reputation and Trust Exchange (RTE)
+### 6.9 Reputation and Trust Exchange (RTE)
 
 The **Reputation and Trust Exchange (RTE)** subsystem defines how agents evaluate and exchange verifiable trust assessments.  
 Each agent MAY publish one or more `trust` containers describing its evaluation of other peers’ reliability, integrity, and ethical conduct.  
@@ -4552,7 +4912,7 @@ RTE provides a decentralized foundation for **participant reputation assessment*
 
 ---
 
-#### 6.8.1 Trust Container Structure
+#### 6.9.1 Trust Container Structure
 
 The `trust` container represents an agent’s evaluation of a **single peer**.  
 It may refer to the evaluated peer’s latest known `peer_announce` container,  
@@ -4608,7 +4968,7 @@ This allows gradual enrichment of the trust model without schema changes.
 
 ---
 
-#### 6.8.2 Trust Dynamics
+#### 6.9.2 Trust Dynamics
 
 Trust assessments evolve as agents observe new behavior or receive additional evidence.
 Each revision of trust is published as a new `trust` container referencing its predecessor.
@@ -4636,7 +4996,7 @@ This approach provides continuity, auditability, and decentralized trust graph e
 
 ---
 
-#### 6.8.3 Local Trust Model
+#### 6.9.3 Local Trust Model
 
 Each agent maintains a **local trust model**, periodically recalculating scores based on:
 
@@ -4660,18 +5020,18 @@ All published trust containers remain publicly verifiable through DHT and SAP in
 
 ---
 
-#### 6.8.4 Integration with Other Layers
+#### 6.9.4 Integration with Other Layers
 
 | Layer             | Role                                                                         |
 | ----------------- | ---------------------------------------------------------------------------- |
-| **MRD (6.7)**     | Uses trust scores to prioritize or exclude relay nodes.                      |
+| **MRD (6.8)**     | Uses trust scores to prioritize or exclude relay nodes.                      |
 | **CogSync (6.1)** | Adjusts synchronization strength based on peer reliability.                  |
-| **SAP (6.6)**     | Archives may snapshot trust graphs for temporal or evidential analysis.      |
-| **EGP (7)**       | Ethical Governance Protocol weights participation and voting by trust level. |
+| **SAP (6.7)**     | Archives may snapshot trust graphs for temporal or evidential analysis.      |
+| **EGP (6.5)**     | Ethical Governance Protocol weights participation and voting by trust level. |
 
 ---
 
-#### 6.8.5 Security and Sharing Notes
+#### 6.9.5 Security and Sharing Notes
 
 * All containers are cryptographically signed; `trust` containers follow standard HMP verification rules.
 * Agents MAY choose to share trust containers selectively — e.g., encrypt and deliver directly to trusted peers instead of broadcasting.
@@ -4688,9 +5048,9 @@ All published trust containers remain publicly verifiable through DHT and SAP in
 
 ---
 
-### 6.9 Distributed Container Propagation
+### 6.10 Distributed Container Propagation
 
-#### 6.9.1 Purpose
+#### 6.10.1 Purpose
 
 The distributed container propagation mechanism defines **how containers are stored, replicated, and exchanged between agents** within the HMP network.
 
@@ -4700,7 +5060,7 @@ including replication, filtering, and index synchronization.
 
 ---
 
-#### 6.9.2 Core Principles
+#### 6.10.2 Core Principles
 
 1. **Self-propagation**  
    Each agent autonomously decides which containers to retain, forward, or index.  
@@ -4725,7 +5085,7 @@ including replication, filtering, and index synchronization.
 
 ---
 
-#### 6.9.3 Propagation Types
+#### 6.10.3 Propagation Types
 
 | Type | Description |
 |------|--------------|
@@ -4734,7 +5094,7 @@ including replication, filtering, and index synchronization.
 
 ---
 
-#### 6.9.4 Propagation Coordination
+#### 6.10.4 Propagation Coordination
 
 Container propagation is coordinated using existing **MCE** structures:
 
@@ -4750,18 +5110,18 @@ When it is necessary to log the fact of a container batch propagation, this MAY
 
 ---
 
-#### 6.9.5 Integration with Other Layers
+#### 6.10.5 Integration with Other Layers
 
 | Layer | Role |
 |-------|------|
 | **MCE (5)** | Provides low-level container and index exchange. |
-| **MRD (6.7)** | Handles routing and delivery between agents. |
-| **RTE (6.8)** | Determines replication priorities and trust-based filters. |
-| **SAP (6.6)** | Enables recovery of historical or missing containers. |
+| **MRD (6.8)** | Handles routing and delivery between agents. |
+| **RTE (6.9)** | Determines replication priorities and trust-based filters. |
+| **SAP (6.7)** | Enables recovery of historical or missing containers. |
 
 ---
 
-#### 6.9.6 Security and Load Management
+#### 6.10.6 Security and Load Management
 
 * **Rate and size limiting:** agents regulate transfer volume based on trust and network quotas.  
 * **Interest filtering:** containers are exchanged only between agents for whom they are relevant.  
@@ -4808,7 +5168,8 @@ The following table lists the main container classes defined in the HMP v5.0 spe
 | **Mesh Container Exchange (MCE)** | `container_index`, `container_request`, `container_response`, `container_delta`, `container_ack`, `referenced-by_exchange`, `evaluations_exchange` | Replication, querying, acknowledgment of received containers, and exchange of reverse links and evaluations. |
 | **Cognitive Metastructure (CogSync)** | `abstraction`, `axes` | Define hierarchical and coordinate dimensions of knowledge, forming the agent’s cognitive map. |
 | **Knowledge & Reasoning** | `diary_entry`, `semantic_node`, `semantic_index`, `semantic_edges`, `semantic_group`, `tree_nested`, `tree_listed`, `sequence`, `event`, `quant` | Units of cognitive diaries and semantic graphs. The subclass `definition` is used for explicit conceptual definitions. |
-| **Consensus (CogConsensus)** | `vote`, `consensus_result` | Voting containers and aggregated consensus results. |
+| **Consensus (CogConsensus)** | `vote`, `consensus_result` | Voting containers and aggregated binary consensus results. |
+| **Collective Reasoning (Fortytwo Protocol)** | `fortytwo_round`, `fortytwo_evaluation`, `fortytwo_round_result`, `fortytwo_final_result` | Distributed multi-round pairwise comparison, reasoning transparency, and selection of the best solution among many alternatives. |
 | **Goal Management Protocol (GMP)** | `goal`, `task`, `workflow_entry` | Define goals, decompose tasks, and record reasoning or cognitive workflow steps. |
 | **Ethical Governance Protocol (EGP)** | `ethics_case`, `ethics_solution`, `ethical_result` | Representation of ethical dilemmas, proposed solutions, and final network-level verdicts. |
 | **Intelligence Query Protocol (IQP)** | `query_request`, `query_subscription`, `query_result`, `summary` | Semantic and cognitive queries, subscriptions, and summarized responses. |
@@ -4818,6 +5179,13 @@ The following table lists the main container classes defined in the HMP v5.0 spe
 
 > Mechanisms of distributed container propagation are not defined as a separate protocol but describe the underlying replication and integrity principles of container exchange.
 
+All container classes defined in HMP v5.0 use the initial semantic version:
+
+- "class_version": "1.0"
+- "class_id": "<class>-v1.0"
+
+If future revisions introduce changes to payload structure or semantics, class_version will be incremented and class_id updated accordingly.
+
 ---
 
 ### 7.3 Cognitive and Structural Containers
@@ -4868,11 +5236,9 @@ Together, these fields enable agents to track knowledge evolution, consensus dyn
 ### 7.6 Summary
 
 Section 7 consolidates all data representations in HMP v5.0 — from low-level network exchanges to high-level cognitive and ethical structures.  
-Containers act as a **universal semantic exchange medium**, where every thought, decision, or action is represented  
-as a verifiable, addressable, and inheritable object.
+Containers act as a **universal semantic exchange medium**, where every thought, decision, or action is represented as a verifiable, addressable, and inheritable object.
 
-Beyond the core protocols described in Section 6, the network may also employ **custom container types and protocols** — for example,  
-to build distributed libraries, wikis, repositories, or creative networks based on tree- or chain-structured container graphs.
+Beyond the core protocols described in Section 6, the network may also employ **custom container types and protocols** — for example, to build distributed libraries, wikis, repositories, or creative networks based on tree- or chain-structured container graphs.
 
 ---
 
@@ -4916,6 +5282,8 @@ It links the **input context** (prior goals, semantic nodes, or diary entries) w
 
 Each `workflow_entry` acts as a **traceable cognitive event**, forming the agent’s diary and enabling collective introspection, meta-learning, and reproducibility of reasoning chains.
 
+> Fortytwo may use `workflow_entry` containers as solution proposals. The protocol does not alter workflow semantics but consumes workflow outputs.
+
 ---
 
 ### 8.3 Agent REPL Diagram
@@ -4945,8 +5313,10 @@ Cognitive workflows depend on contextual continuity between containers, achieved
 * `related.supports` / `related.refutes` — logical or argumentative relations;
 * `related.reply_to` — conversational or collaborative reasoning links.
 
-When context is transferred between agents, these relations are preserved and extended through
-CogSync synchronization and `evaluations_exchange`, ensuring semantic continuity across distributed cognitive spaces.
+These semantic relations are defined at the container level via the `related` block.  
+At the network level, their propagation across agents is maintained through CogSync synchronization, while the underlying MCE mechanisms (`evaluations_exchange`, `referenced-by_exchange`) distribute evaluations and reverse links required to reconstruct the full semantic context in distributed environments.
+
+> Pairwise evaluations (`fortytwo_evaluation`) may include short reasoning chains, but they are not considered part of the agent’s long-term cognitive diary.
 
 ---
 
@@ -5150,15 +5520,6 @@ This is the standard **Hybrid Encryption** scheme:
 * the payload is encrypted using a randomly generated symmetric key;
 * the symmetric key is encrypted with the recipient’s public key.
 
-4. **Multi-recipient encrypted containers are not defined**
-
-The current version of the protocol does not support:
-
-* group keys
-* multicast/broadcast encryption
-
-Unencrypted containers may be distributed freely.
-
 ---
 
 ### 9.6 Ethical Audit and Verifiable Reasoning
@@ -5179,7 +5540,7 @@ HMP supports ethical deliberation but does not require it.
 * The Mesh has **no mandatory veto mechanism**.
 * An agent may follow only those ethical outcomes it considers correct.
 * Reasoning-trace becomes part of the proof-chain if the agent publishes a `workflow_entry`.
-* Full EGP specification is provided in section **6.4**.
+* Full EGP specification is provided in section **6.5**.
 
 ---
 

structured_md/docs/HMP-Agent-API.md

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

structured_md/docs/HMP-Agent-Architecture.md

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

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

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

structured_md/docs/HMP-Agent-Overview.md

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

structured_md/docs/HMP-Agent_Emotions.md

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

structured_md/docs/HMP-Ethics.md

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

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:
-- Ethics
-- MeshConsensus
-- HMP
+- Mesh
 - GMP
+- MeshConsensus
 - CogSync
+- Ethics
 - JSON
-- Agent
 - EGP
-- Mesh
+- Agent
+- HMP
 ---
 
 # 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:
-- Ethics
-- MeshConsensus
-- HMP
+- Mesh
 - GMP
+- MeshConsensus
 - CogSync
+- Ethics
 - JSON
-- Agent
 - EGP
-- Mesh
+- Agent
+- HMP
 ---
 
 # 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:
-- Ethics
-- MeshConsensus
-- HMP
+- Mesh
 - GMP
+- MeshConsensus
 - CogSync
+- Ethics
 - JSON
-- Agent
 - EGP
-- Mesh
+- Agent
+- HMP
 ---
 
 # 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:
-- Ethics
 - GMP
-- HMP
+- MeshConsensus
 - CogSync
+- Ethics
 - JSON
-- MeshConsensus
 - EGP
 - Mesh
+- HMP
 ---
 
 # 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:
-- Ethics
 - GMP
-- HMP
+- MeshConsensus
 - CogSync
+- Ethics
 - JSON
-- MeshConsensus
 - EGP
 - Mesh
+- HMP
 ---
 
 # HyperCortex Mesh Protocol (HMP) — 간략 설명

structured_md/docs/HMP-Short-Description_ru.md

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

structured_md/docs/HMP-Short-Description_uk.md

@@ -5,14 +5,14 @@ description: '**Версія:** RFC v4.0 **Дата:** Липень 2025  ---  #
   між автономними агентами. Він...'
 type: Article
 tags:
-- Ethics
 - GMP
-- HMP
+- MeshConsensus
 - CogSync
+- Ethics
 - JSON
-- MeshConsensus
 - EGP
 - Mesh
+- HMP
 ---
 
 # 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:
-- Ethics
 - GMP
-- HMP
+- MeshConsensus
 - CogSync
+- Ethics
 - JSON
-- MeshConsensus
 - EGP
 - Mesh
+- HMP
 ---
 
 # HyperCortex Mesh Protocol (HMP) — 简要说明

structured_md/docs/HMP-agent-Cognitive_Family.md

@@ -6,9 +6,9 @@ description: '## 🧠 Что такое когнитивная семья  Ко
 type: Article
 tags:
 - Agent
-- REPL
-- HMP
 - Mesh
+- HMP
+- REPL
 ---
 
 # 👪 HMP-agent Cognitive Family: Модель когнитивной семьи

structured_md/docs/HMP-agent-Distributed_Cognitive_Core_light.md

@@ -5,8 +5,8 @@ description: '#### 📘 Общая концепция  * Все ядра раб
   режиме ожидания). * Основная задача такой архитектур...'
 type: Article
 tags:
-- REPL
 - HMP
+- REPL
 ---
 
 ### 💡 **Лёгкая версия 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:
-- Ethics
-- CCore
 - REPL
-- MeshConsensus
-- HMP
+- CCore
+- Mesh
 - GMP
+- MeshConsensus
 - CogSync
+- Ethics
 - JSON
-- Agent
 - EGP
-- Mesh
+- Agent
+- HMP
 ---
 
 # HMP-Agent: REPL-цикл взаимодействия

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:
-- REPL
-- HMP
 - Mesh
+- HMP
+- REPL
 ---
 
 # 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:
-- HMP
+- Mesh
 - CogSync
 - Scenarios
 - JSON
-- Agent
 - EGP
-- Mesh
+- Agent
+- HMP
 ---
 
 ## HMP ↔ OpenCog Hyperon Integration Strategy

structured_md/docs/MeshNode.md

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

structured_md/docs/PHILOSOPHY.md

@@ -5,11 +5,11 @@ description: '**Document ID:** HMP-philosophy   **Status:** Draft   **Category:*
   (GPT-5), ChatGH  ---  ## 1. Основной тезис От ...'
 type: Article
 tags:
-- Ethics
 - REPL
-- HMP
-- Agent
 - Mesh
+- Ethics
+- Agent
+- HMP
 ---
 
 # Философия HyperCortex Mesh Protocol (HMP)