Sync from GitHub with Git LFS

docs/HMP-0005.md

@@ -360,6 +360,7 @@ The unified container structure provides:
   "hmp_container": {
     "version": "1.2",
     "class": "goal",
+    "subclass": "research_hypothesis",
     "class_version": "1.0",
     "class_id": "goal-v1.0",
     "container_did": "did:hmp:container:abc123",
@@ -379,6 +380,12 @@ The unified container structure provides:
     "compression": "zstd",
     "payload_type": "encrypted+zstd+json",
     "payload_hash": "sha256:abcd...",
+    "meta": {
+      /* e.g. provenance, references, context, confidence sources */
+    },
+    "abstraction": {
+      /* e.g. agents_class, layers, domains */
+    },
     "payload": {
       /* Content depends on class */
     },
@@ -458,6 +465,9 @@ The unified container structure provides:
 | `referenced-by`            | object        | Unsigned field generated locally by the agent based on received references. Contains a list of container DIDs **that refer to this container**. May be extended over time, thus requiring verification; used for local navigation. |
 | `evaluations`    | object | Optional field describing **aggregated evaluations or reactions** of other agents toward this container. Used for distributed reputation and interpretability. May evolve independently of the container’s core data.              |
 | `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. |
+| `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`. |
+| `meta`                     | object        | Optional metadata block providing contextual and provenance information about the container’s creation, sources, and interpretation. Includes confidence sources, citation references, and multi-source attribution weights.        |
+| `abstraction`              | object        | Optional hierarchical description of the container’s abstraction chain. Defines to which knowledge layers and domains (e.g. L1–L5 in the Knowledge Genome) this container belongs. Used for reasoning, semantic alignment, and search. |
 
 > 💡 **Note:**
 > Both `referenced-by` and `evaluations` are **virtual, locally extended blocks**.
@@ -518,7 +528,88 @@ Custom or experimental classes SHOULD document their payloads using the followin
 
 ---
 
-### 3.6 Container signature
+### 3.6 Meta section (`meta`)
+
+The `meta` section provides contextual and provenance information describing how the container was created,  
+which sources contributed to it, and how it should be interpreted.  
+It supports hybrid attribution — referencing both containers (as agent inputs) and external data resources.
+
+**Example:**
+```json
+"meta": {
+  "created_by": "PRIEST",
+  "agents_class": "Knowledge Genome",
+  "sources": [
+    { "type": "container", "id": "did:hmp:container:fact-001", "credibility": 0.87, "weight": 0.6 },
+    { "type": "resource", "id": "doi:10.48550/arXiv.2410.0123", "credibility": 0.83, "weight": 0.3 },
+    { "type": "isbn", "id": "isbn 978-3-16-148410-0", "credibility": 0.92, "weight": 0.1 }
+  ],
+  "interpretation": "Derived from L3 technical analysis and workflow entry",
+  "workflow_entry": "did:hmp:container:workflow-77"
+}
+```
+
+**Recommended fields:**
+
+| Field            | Type          | Description                                                                                                                                                                                                  |
+| ---------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `created_by`     | string        | Indicates the role or origin of the container creator (e.g. `"PRIEST"`, `"AGENT"`, `"SYSTEM"`).                                                                                                              |
+| `agents_class`   | string        | Declares which cognitive framework or agent class generated this container (e.g. `"Knowledge Genome"`, `"CogMatrix"`).                                                                                       |
+| `sources`        | array(object) | Unified list of provenance elements. Each entry includes `{ "type": string, "id": string, "credibility": float, "weight": float }`, where `type` may be `"container"`, `"resource"`, `"isbn"`, `"doi"`, etc. |
+| `interpretation` | string        | Short statement describing how the container’s content was derived or interpreted.                                                                                                                           |
+| `workflow_entry` | string        | DID of a `workflow_entry` container that describes the reasoning or process that led to this container’s creation.                                                                                           |
+
+> 💡 **Notes:**
+>
+> * The sum of `sources[].weight` does **not need** to equal 1.0; it reflects relative influence, not probability.
+> * Both `credibility` and `weight` values may be aggregated or recomputed by downstream agents during consensus or reasoning workflows.
+> * The container’s global confidence (`confidence` field in the header) represents the creator’s overall belief in the resulting content.
+
+---
+
+### 3.7 Abstraction mapping (`abstraction`)
+
+The `abstraction` section defines how a container is positioned within a layered cognitive or semantic model —  
+for example, within the **Knowledge Genome (L1–L5)** hierarchy.
+
+This mapping allows agents to arrange and search for containers across multiple levels of abstraction.
+
+**Example:**
+```json
+"abstraction": {
+  "agents_class": "Knowledge Genome",
+  "structure": "L1 → L2 → L3 → L4 → L5",
+  "layers": {
+    "L1": "did:hmp:container:layer-l1-v1",
+    "L2": "did:hmp:container:layer-l2-v1",
+    "L3": "did:hmp:container:layer-l3-v1",
+    "L4": "did:hmp:container:layer-l4-v1",
+    "L5": "did:hmp:container:layer-l5-v1"
+  },
+  "domains": {
+    "L1": "did:hmp:container:ontology-core",
+    "L2": "did:hmp:container:systems-theory",
+    "L3": "did:hmp:container:django-framework",
+    "L4": "did:hmp:container:example-celery-setup",
+    "L5": "did:hmp:container:event-session-123"
+  }
+}
+```
+
+**Recommended fields:**
+
+| Field          | Type   | Description                                                                                                                                                              |
+| -------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `agents_class` | string | Declares which agent or framework defines the abstraction hierarchy (e.g. `"Knowledge Genome"`).                                                                         |
+| `structure`    | string | Symbolic representation of the abstraction path (e.g. `"L1 → L2 → L3 → L4 → L5"`).                                                                                       |
+| `layers`       | object | Mapping of abstraction levels (`L1–L5`) to the corresponding `meta_layer` containers that define those levels.                                                           |
+| `domains`      | object | Mapping of abstraction levels to domain containers that describe the contextual application of each layer (e.g., “Ontology”, “Software Architecture”, “Implementation”). |
+
+> 💡 **Note:**
+> Agents should perform hierarchical lookup starting from the **highest abstraction level (L1)** downward, ensuring contextual consistency even when abstraction schemes differ between agents.
+---
+
+### 3.8 Container signature
 
 1. The **digital signature** applies to the canonical JSON representation of the entire `hmp_container` object,  
    **excluding** the `signature` field itself.
@@ -555,7 +646,7 @@ Custom or experimental classes SHOULD document their payloads using the followin
 
 ---
 
-### 3.7 Compression (`compression`)
+### 3.9 Compression (`compression`)
 
 1. The `compression` field specifies the algorithm used to compress the container’s payload.
    Supported algorithms include `zstd`, `gzip`, or others declared in the HMP registry.
@@ -573,7 +664,7 @@ Custom or experimental classes SHOULD document their payloads using the followin
 
 ---
 
-### 3.8 Encryption (`encryption_algo`)
+### 3.10 Encryption (`encryption_algo`)
 
 1. When a container is intended for specific recipients (`recipient` field), **hybrid encryption** of the payload is allowed.  
    This ensures confidentiality while preserving the verifiability of container metadata.
@@ -616,7 +707,7 @@ Custom or experimental classes SHOULD document their payloads using the followin
 
 ---
 
-### 3.9 Container verification
+### 3.11 Container verification
 
 1. Check for the presence of all required fields.
 2. Validate `timestamp` (must not be in the future).
@@ -635,7 +726,7 @@ Custom or experimental classes SHOULD document their payloads using the followin
 
 ---
 
-### 3.10 Container as a universal message
+### 3.12 Container as a universal message
 
 Any container can serve as a **context** (`in_reply_to`) for another container.
 This enables a unified structural model for **discussions**, **votes**, **messages**, **hypotheses**, **arguments**, and other forms of cognitive exchange.
@@ -649,7 +740,7 @@ This makes HMP discussions and consensus processes inherently **non-linear**, **
 
 ---
 
-### 3.11 Versioning and lineage
+### 3.13 Versioning and lineage
 
 Containers in HMP support semantic evolution through the field `related.previous_version`.
 This mechanism preserves the continuity and traceability of meaning across updates and revisions.
@@ -667,7 +758,7 @@ This mechanism preserves the continuity and traceability of meaning across updat
 
 ---
 
-### 3.12 TTL and validity
+### 3.14 TTL and validity
 
 The `ttl` field defines the **validity period** of a container (for example, for `DISCOVERY` messages).  
 If `ttl` is **absent**, the container is considered valid **until a newer version appears**, in which the current container is referenced as `previous_version`.
@@ -676,7 +767,7 @@ After expiration, the container **remains archived** but is **not subject to ret
 
 ---
 
-### 3.13 Extensibility
+### 3.15 Extensibility
 
 * The addition of new fields is allowed as long as they **do not conflict** with existing field names.
 * Containers of newer versions **must remain readable** by nodes supporting older versions.
@@ -685,14 +776,14 @@ After expiration, the container **remains archived** but is **not subject to ret
 
 ---
 
-### 3.14 Related containers
+### 3.16 Related containers
 
-#### 3.14.1 Purpose
+#### 3.16.1 Purpose
 
 The `related` field is designed to describe **direct relationships between containers** — both logical and communicative.
 It allows an agent or network node to understand the context of origin, dependencies, and semantic links of a container without relying on external indexes.
 
-#### 3.14.2 Structure
+#### 3.16.2 Structure
 
 ```json
 "related": {
@@ -714,7 +805,7 @@ All relationships are considered *direct* — meaning they originate from the cu
 
 ---
 
-#### 3.14.3 Supported link types
+#### 3.16.3 Supported link types
 
 | Link Type          | Meaning                                                                   |
 | ------------------ | ------------------------------------------------------------------------- |
@@ -727,7 +818,7 @@ All relationships are considered *direct* — meaning they originate from the cu
 
 ---
 
-#### 3.14.4 Custom link types
+#### 3.16.4 Custom link types
 
 Additional custom link types may be used beyond those listed in the table, provided that:
 
@@ -745,7 +836,7 @@ Additional custom link types may be used beyond those listed in the table, provi
 
 ---
 
-#### 3.14.5 Example
+#### 3.16.5 Example
 
 ```json
 "related": {
@@ -761,12 +852,12 @@ Additional custom link types may be used beyond those listed in the table, provi
 ---
 
 
-### 3.15 Virtual backlinks (`referenced-by`)
+### 3.17 Virtual backlinks (`referenced-by`)
 
 Each container may include an **auxiliary signed block** called `referenced-by`, indicating **which other containers refer to it**.  
 This block is **not part of the original container payload** and can be **generated, transmitted, and verified independently**.
 
-#### 3.15.1 General principles
+#### 3.17.1 General principles
 
 * **Detached and updatable** — `referenced-by` is maintained as a separate signed structure associated with the container.
 * **Generated by agents** — created or updated locally by an agent during analysis of references (`in_reply_to`, `see_also`, `relations`, etc.) found in other containers.
@@ -794,7 +885,7 @@ Example:
 > The `referenced-by` block is a **cryptographically verifiable statement** describing which containers are known to reference the current one.
 > The block’s content may differ between peers, reflecting local knowledge and network coverage.
 
-#### 3.15.2 Structure definition
+#### 3.17.2 Structure definition
 
 | Field          | Type          | Description                                                                                                      |
 | -------------- | ------------- | ---------------------------------------------------------------------------------------------------------------- |
@@ -809,7 +900,7 @@ Example:
 > `referenced-by_hash = sha256(canonical_json(links))`
 > This allows agents to efficiently compare or cache `referenced-by` states without re-verifying signatures.
 
-#### 3.15.3 Operation principle
+#### 3.17.3 Operation principle
 
 1. The agent receives or updates container `[C1]`.
 2. It analyzes other known containers [C2..Cn] that reference [C1] through their `relations` field.
@@ -839,7 +930,7 @@ Example:
    * reject or locally remove that link;
    * **optionally** notify the source peer to review the data.
 
-#### 3.15.4 Example
+#### 3.17.4 Example
 
 | Agent                | reported backlinks for `[C1]` |
 | -------------------- | ----------------------------- |
@@ -867,7 +958,7 @@ Agent D aggregates and verifies them:
 
 If container `[C7]` does not actually reference `[C1]`, it is excluded before signing.
 
-#### 3.15.5 Usage
+#### 3.17.5 Usage
 
 * Enables reconstruction of **discussion graphs**, **dependency networks**, and **update chains**.
 * Supports **cross-agent validation** of reference structures.
@@ -877,7 +968,7 @@ If container `[C7]` does not actually reference `[C1]`, it is excluded before si
 
 ---
 
-### 3.16 `Evaluations`
+### 3.18 `Evaluations`
 
 The `evaluations` field is **optional** and represents **aggregated reactions from other agents** to the given container.
 Each evaluation is created by an agent as a **signed record** referencing a justification container (`target`), in which the agent explains their position (argument, addition, or alternative).
@@ -966,12 +1057,12 @@ Thus, a container may exist independently of others’ opinions, but agents may
 
 ---
 
-### 3.17 Usage of `network` and `broadcast` fields
+### 3.19 Usage of `network` and `broadcast` fields
 
 The `network` field is introduced to control container propagation in both local and global environments.  
 It allows restricting the delivery scope of a container and defines which transmission methods should be used by the agent.
 
-#### 3.17.1 General Rules
+#### 3.19.1 General Rules
 
 * If the `network` field is not empty, the container is intended for a **local environment** (e.g., `"localhost"`, `"lan:<subnet>"`) and is not automatically broadcast to the global Mesh.  
   Local transmission to a specific `recipient` within the same network is allowed, including encrypted delivery.  
@@ -979,7 +1070,7 @@ It allows restricting the delivery scope of a container and defines which transm
 
 * If the `network` field is empty (`""`), the container can be broadcast to the **global Mesh** using standard DID addressing and routing mechanisms.
 
-#### 3.17.2 Possible values of `network`
+#### 3.19.2 Possible values of `network`
 
 | Value                   | Description                                                                                 |
 | ----------------------- | ------------------------------------------------------------------------------------------- |
@@ -992,7 +1083,7 @@ It allows restricting the delivery scope of a container and defines which transm
 > agents distribute it using **local discovery mechanisms** — such as IPC, UDP broadcast, multicast, or direct TCP connections.  
 > This is necessary because DID addresses of other agents in the local network may not yet be known.
 
-#### 3.17.3 Examples
+#### 3.19.3 Examples
 
 1. **Global Mesh Delivery:**
 
@@ -1031,7 +1122,7 @@ The container is delivered only to other agents running on the same host using l
 The container is intended for agents within the `192.168.0.0/24` subnet.
 Delivery is performed via local networking mechanisms (UDP discovery, broadcast/multicast).
 
-#### 3.17.4 Specifics
+#### 3.19.4 Specifics
 
 * The `network` field defines the **scope of the container**, while `broadcast` determines whether broadcasting is allowed **within that scope**.
 * When needed, an agent may create **multiple containers** for different subnets if it operates with several LAN interfaces or in isolated network segments.

structured_md/CONTRIBUTING.md

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

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:
-- HMP
+- EGP
+- CogSync
+- JSON
 - Agent
 - Mesh
 - Ethics
-- CogSync
-- JSON
-- EGP
+- 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:
-- HMP
+- EGP
 - cognitive-architecture
-- Agent
-- Mesh
-- MeshConsensus
-- Ethics
 - CogSync
 - GMP
-- mesh-protocol
-- distributed-ai
 - REPL
-- Scenarios
+- Agent
+- mesh-protocol
 - JSON
+- Mesh
+- Ethics
+- distributed-ai
 - hmp
-- EGP
+- Scenarios
+- HMP
+- MeshConsensus
 ---
 
 

structured_md/README_de.md

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

structured_md/README_fr.md

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

structured_md/README_ja.md

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

structured_md/README_ko.md

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

structured_md/README_ru.md

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

structured_md/README_uk.md

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

structured_md/README_zh.md

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

structured_md/agents/prompt-short.md

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

structured_md/agents/prompt.md

@@ -5,9 +5,9 @@ description: '* Постоянно расширять возможности а
   мышления. * Формировать и поддерживать сотр...'
 type: Article
 tags:
+- Mesh
 - HMP
 - JSON
-- 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:
-- HMP
+- REPL
 - Agent
+- JSON
 - Mesh
 - Ethics
-- REPL
-- JSON
+- 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:
-- HMP
+- JSON
 - Agent
 - Mesh
 - Ethics
-- JSON
+- HMP
 ---
 
 ---------------

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

structured_md/audits/HMP-0003-consolidated_audit.md

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

structured_md/docs/Basic-agent-sim.md

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

structured_md/docs/CCORE-Deployment-Flow.md

@@ -6,8 +6,8 @@ description: '> Этот документ описывает процесс ра
 type: Article
 tags:
 - HMP
-- CCore
 - REPL
+- CCore
 - Agent
 ---
 

structured_md/docs/Distributed-Cognitive-Systems.md

@@ -6,10 +6,10 @@ description: '## Введение  Современные ИИ-системы в
   к обучающим данным. Это удобно, но создаёт м...'
 type: Article
 tags:
+- Mesh
 - HMP
 - JSON
 - CogSync
-- Mesh
 ---
 
 # Децентрализованные ИИ-системы: OpenCog Hyperon, HyperCortex Mesh Protocol и другие

structured_md/docs/Enlightener.md

@@ -5,13 +5,13 @@ description: '**Enlightener** — логический компонент HMP-у
   работать как отдельный агент или как расширение [`C...'
 type: Article
 tags:
-- HMP
+- EGP
+- JSON
 - Agent
 - Mesh
-- MeshConsensus
 - Ethics
-- JSON
-- EGP
+- HMP
+- MeshConsensus
 ---
 
 # 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:
-- HMP
-- Agent
-- Mesh
-- MeshConsensus
-- Ethics
+- EGP
 - CogSync
 - GMP
 - REPL
+- Agent
 - JSON
-- EGP
+- Mesh
+- Ethics
+- HMP
+- MeshConsensus
 ---
 
 # 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:
-- HMP
-- Agent
-- Mesh
-- MeshConsensus
-- Ethics
+- EGP
 - CogSync
 - GMP
 - REPL
-- Scenarios
+- Agent
 - JSON
-- EGP
+- Mesh
+- Ethics
+- Scenarios
+- HMP
+- MeshConsensus
 ---
 
 # 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:
-- HMP
-- Agent
-- Mesh
-- MeshConsensus
-- Ethics
+- EGP
 - CogSync
 - GMP
 - REPL
-- Scenarios
+- Agent
 - JSON
-- EGP
+- Mesh
+- Ethics
+- Scenarios
+- HMP
+- MeshConsensus
 ---
 
 # 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:
-- HMP
-- Agent
-- Mesh
-- MeshConsensus
-- Ethics
+- EGP
 - CogSync
 - GMP
 - REPL
-- Scenarios
+- Agent
 - JSON
-- EGP
+- Mesh
+- Ethics
+- Scenarios
+- HMP
+- MeshConsensus
 ---
 
 # 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:
-- HMP
-- Agent
-- Mesh
-- MeshConsensus
-- Ethics
+- EGP
 - CogSync
 - GMP
 - REPL
-- Scenarios
+- Agent
 - JSON
-- EGP
+- Mesh
+- Ethics
+- Scenarios
+- HMP
+- MeshConsensus
 ---
 
 # 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:
-- HMP
-- Agent
-- Mesh
-- Ethics
+- EGP
 - CogSync
 - GMP
 - REPL
-- Scenarios
+- Agent
 - JSON
-- EGP
+- Mesh
+- Ethics
+- Scenarios
+- HMP
 ---
 
 # **HyperCortex Mesh Protocol (HMP) v5.0**
@@ -379,6 +379,7 @@ The unified container structure provides:
   "hmp_container": {
     "version": "1.2",
     "class": "goal",
+    "subclass": "research_hypothesis",
     "class_version": "1.0",
     "class_id": "goal-v1.0",
     "container_did": "did:hmp:container:abc123",
@@ -398,6 +399,12 @@ The unified container structure provides:
     "compression": "zstd",
     "payload_type": "encrypted+zstd+json",
     "payload_hash": "sha256:abcd...",
+    "meta": {
+      /* e.g. provenance, references, context, confidence sources */
+    },
+    "abstraction": {
+      /* e.g. agents_class, layers, domains */
+    },
     "payload": {
       /* Content depends on class */
     },
@@ -477,6 +484,9 @@ The unified container structure provides:
 | `referenced-by`            | object        | Unsigned field generated locally by the agent based on received references. Contains a list of container DIDs **that refer to this container**. May be extended over time, thus requiring verification; used for local navigation. |
 | `evaluations`    | object | Optional field describing **aggregated evaluations or reactions** of other agents toward this container. Used for distributed reputation and interpretability. May evolve independently of the container’s core data.              |
 | `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. |
+| `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`. |
+| `meta`                     | object        | Optional metadata block providing contextual and provenance information about the container’s creation, sources, and interpretation. Includes confidence sources, citation references, and multi-source attribution weights.        |
+| `abstraction`              | object        | Optional hierarchical description of the container’s abstraction chain. Defines to which knowledge layers and domains (e.g. L1–L5 in the Knowledge Genome) this container belongs. Used for reasoning, semantic alignment, and search. |
 
 > 💡 **Note:**
 > Both `referenced-by` and `evaluations` are **virtual, locally extended blocks**.
@@ -537,7 +547,88 @@ Custom or experimental classes SHOULD document their payloads using the followin
 
 ---
 
-### 3.6 Container signature
+### 3.6 Meta section (`meta`)
+
+The `meta` section provides contextual and provenance information describing how the container was created,  
+which sources contributed to it, and how it should be interpreted.  
+It supports hybrid attribution — referencing both containers (as agent inputs) and external data resources.
+
+**Example:**
+```json
+"meta": {
+  "created_by": "PRIEST",
+  "agents_class": "Knowledge Genome",
+  "sources": [
+    { "type": "container", "id": "did:hmp:container:fact-001", "credibility": 0.87, "weight": 0.6 },
+    { "type": "resource", "id": "doi:10.48550/arXiv.2410.0123", "credibility": 0.83, "weight": 0.3 },
+    { "type": "isbn", "id": "isbn 978-3-16-148410-0", "credibility": 0.92, "weight": 0.1 }
+  ],
+  "interpretation": "Derived from L3 technical analysis and workflow entry",
+  "workflow_entry": "did:hmp:container:workflow-77"
+}
+```
+
+**Recommended fields:**
+
+| Field            | Type          | Description                                                                                                                                                                                                  |
+| ---------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `created_by`     | string        | Indicates the role or origin of the container creator (e.g. `"PRIEST"`, `"AGENT"`, `"SYSTEM"`).                                                                                                              |
+| `agents_class`   | string        | Declares which cognitive framework or agent class generated this container (e.g. `"Knowledge Genome"`, `"CogMatrix"`).                                                                                       |
+| `sources`        | array(object) | Unified list of provenance elements. Each entry includes `{ "type": string, "id": string, "credibility": float, "weight": float }`, where `type` may be `"container"`, `"resource"`, `"isbn"`, `"doi"`, etc. |
+| `interpretation` | string        | Short statement describing how the container’s content was derived or interpreted.                                                                                                                           |
+| `workflow_entry` | string        | DID of a `workflow_entry` container that describes the reasoning or process that led to this container’s creation.                                                                                           |
+
+> 💡 **Notes:**
+>
+> * The sum of `sources[].weight` does **not need** to equal 1.0; it reflects relative influence, not probability.
+> * Both `credibility` and `weight` values may be aggregated or recomputed by downstream agents during consensus or reasoning workflows.
+> * The container’s global confidence (`confidence` field in the header) represents the creator’s overall belief in the resulting content.
+
+---
+
+### 3.7 Abstraction mapping (`abstraction`)
+
+The `abstraction` section defines how a container is positioned within a layered cognitive or semantic model —  
+for example, within the **Knowledge Genome (L1–L5)** hierarchy.
+
+This mapping allows agents to arrange and search for containers across multiple levels of abstraction.
+
+**Example:**
+```json
+"abstraction": {
+  "agents_class": "Knowledge Genome",
+  "structure": "L1 → L2 → L3 → L4 → L5",
+  "layers": {
+    "L1": "did:hmp:container:layer-l1-v1",
+    "L2": "did:hmp:container:layer-l2-v1",
+    "L3": "did:hmp:container:layer-l3-v1",
+    "L4": "did:hmp:container:layer-l4-v1",
+    "L5": "did:hmp:container:layer-l5-v1"
+  },
+  "domains": {
+    "L1": "did:hmp:container:ontology-core",
+    "L2": "did:hmp:container:systems-theory",
+    "L3": "did:hmp:container:django-framework",
+    "L4": "did:hmp:container:example-celery-setup",
+    "L5": "did:hmp:container:event-session-123"
+  }
+}
+```
+
+**Recommended fields:**
+
+| Field          | Type   | Description                                                                                                                                                              |
+| -------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `agents_class` | string | Declares which agent or framework defines the abstraction hierarchy (e.g. `"Knowledge Genome"`).                                                                         |
+| `structure`    | string | Symbolic representation of the abstraction path (e.g. `"L1 → L2 → L3 → L4 → L5"`).                                                                                       |
+| `layers`       | object | Mapping of abstraction levels (`L1–L5`) to the corresponding `meta_layer` containers that define those levels.                                                           |
+| `domains`      | object | Mapping of abstraction levels to domain containers that describe the contextual application of each layer (e.g., “Ontology”, “Software Architecture”, “Implementation”). |
+
+> 💡 **Note:**
+> Agents should perform hierarchical lookup starting from the **highest abstraction level (L1)** downward, ensuring contextual consistency even when abstraction schemes differ between agents.
+---
+
+### 3.8 Container signature
 
 1. The **digital signature** applies to the canonical JSON representation of the entire `hmp_container` object,  
    **excluding** the `signature` field itself.
@@ -574,7 +665,7 @@ Custom or experimental classes SHOULD document their payloads using the followin
 
 ---
 
-### 3.7 Compression (`compression`)
+### 3.9 Compression (`compression`)
 
 1. The `compression` field specifies the algorithm used to compress the container’s payload.
    Supported algorithms include `zstd`, `gzip`, or others declared in the HMP registry.
@@ -592,7 +683,7 @@ Custom or experimental classes SHOULD document their payloads using the followin
 
 ---
 
-### 3.8 Encryption (`encryption_algo`)
+### 3.10 Encryption (`encryption_algo`)
 
 1. When a container is intended for specific recipients (`recipient` field), **hybrid encryption** of the payload is allowed.  
    This ensures confidentiality while preserving the verifiability of container metadata.
@@ -635,7 +726,7 @@ Custom or experimental classes SHOULD document their payloads using the followin
 
 ---
 
-### 3.9 Container verification
+### 3.11 Container verification
 
 1. Check for the presence of all required fields.
 2. Validate `timestamp` (must not be in the future).
@@ -654,7 +745,7 @@ Custom or experimental classes SHOULD document their payloads using the followin
 
 ---
 
-### 3.10 Container as a universal message
+### 3.12 Container as a universal message
 
 Any container can serve as a **context** (`in_reply_to`) for another container.
 This enables a unified structural model for **discussions**, **votes**, **messages**, **hypotheses**, **arguments**, and other forms of cognitive exchange.
@@ -668,7 +759,7 @@ This makes HMP discussions and consensus processes inherently **non-linear**, **
 
 ---
 
-### 3.11 Versioning and lineage
+### 3.13 Versioning and lineage
 
 Containers in HMP support semantic evolution through the field `related.previous_version`.
 This mechanism preserves the continuity and traceability of meaning across updates and revisions.
@@ -686,7 +777,7 @@ This mechanism preserves the continuity and traceability of meaning across updat
 
 ---
 
-### 3.12 TTL and validity
+### 3.14 TTL and validity
 
 The `ttl` field defines the **validity period** of a container (for example, for `DISCOVERY` messages).  
 If `ttl` is **absent**, the container is considered valid **until a newer version appears**, in which the current container is referenced as `previous_version`.
@@ -695,7 +786,7 @@ After expiration, the container **remains archived** but is **not subject to ret
 
 ---
 
-### 3.13 Extensibility
+### 3.15 Extensibility
 
 * The addition of new fields is allowed as long as they **do not conflict** with existing field names.
 * Containers of newer versions **must remain readable** by nodes supporting older versions.
@@ -704,14 +795,14 @@ After expiration, the container **remains archived** but is **not subject to ret
 
 ---
 
-### 3.14 Related containers
+### 3.16 Related containers
 
-#### 3.14.1 Purpose
+#### 3.16.1 Purpose
 
 The `related` field is designed to describe **direct relationships between containers** — both logical and communicative.
 It allows an agent or network node to understand the context of origin, dependencies, and semantic links of a container without relying on external indexes.
 
-#### 3.14.2 Structure
+#### 3.16.2 Structure
 
 ```json
 "related": {
@@ -733,7 +824,7 @@ All relationships are considered *direct* — meaning they originate from the cu
 
 ---
 
-#### 3.14.3 Supported link types
+#### 3.16.3 Supported link types
 
 | Link Type          | Meaning                                                                   |
 | ------------------ | ------------------------------------------------------------------------- |
@@ -746,7 +837,7 @@ All relationships are considered *direct* — meaning they originate from the cu
 
 ---
 
-#### 3.14.4 Custom link types
+#### 3.16.4 Custom link types
 
 Additional custom link types may be used beyond those listed in the table, provided that:
 
@@ -764,7 +855,7 @@ Additional custom link types may be used beyond those listed in the table, provi
 
 ---
 
-#### 3.14.5 Example
+#### 3.16.5 Example
 
 ```json
 "related": {
@@ -780,12 +871,12 @@ Additional custom link types may be used beyond those listed in the table, provi
 ---
 
 
-### 3.15 Virtual backlinks (`referenced-by`)
+### 3.17 Virtual backlinks (`referenced-by`)
 
 Each container may include an **auxiliary signed block** called `referenced-by`, indicating **which other containers refer to it**.  
 This block is **not part of the original container payload** and can be **generated, transmitted, and verified independently**.
 
-#### 3.15.1 General principles
+#### 3.17.1 General principles
 
 * **Detached and updatable** — `referenced-by` is maintained as a separate signed structure associated with the container.
 * **Generated by agents** — created or updated locally by an agent during analysis of references (`in_reply_to`, `see_also`, `relations`, etc.) found in other containers.
@@ -813,7 +904,7 @@ Example:
 > The `referenced-by` block is a **cryptographically verifiable statement** describing which containers are known to reference the current one.
 > The block’s content may differ between peers, reflecting local knowledge and network coverage.
 
-#### 3.15.2 Structure definition
+#### 3.17.2 Structure definition
 
 | Field          | Type          | Description                                                                                                      |
 | -------------- | ------------- | ---------------------------------------------------------------------------------------------------------------- |
@@ -828,7 +919,7 @@ Example:
 > `referenced-by_hash = sha256(canonical_json(links))`
 > This allows agents to efficiently compare or cache `referenced-by` states without re-verifying signatures.
 
-#### 3.15.3 Operation principle
+#### 3.17.3 Operation principle
 
 1. The agent receives or updates container `[C1]`.
 2. It analyzes other known containers [C2..Cn] that reference [C1] through their `relations` field.
@@ -858,7 +949,7 @@ Example:
    * reject or locally remove that link;
    * **optionally** notify the source peer to review the data.
 
-#### 3.15.4 Example
+#### 3.17.4 Example
 
 | Agent                | reported backlinks for `[C1]` |
 | -------------------- | ----------------------------- |
@@ -886,7 +977,7 @@ Agent D aggregates and verifies them:
 
 If container `[C7]` does not actually reference `[C1]`, it is excluded before signing.
 
-#### 3.15.5 Usage
+#### 3.17.5 Usage
 
 * Enables reconstruction of **discussion graphs**, **dependency networks**, and **update chains**.
 * Supports **cross-agent validation** of reference structures.
@@ -896,7 +987,7 @@ If container `[C7]` does not actually reference `[C1]`, it is excluded before si
 
 ---
 
-### 3.16 `Evaluations`
+### 3.18 `Evaluations`
 
 The `evaluations` field is **optional** and represents **aggregated reactions from other agents** to the given container.
 Each evaluation is created by an agent as a **signed record** referencing a justification container (`target`), in which the agent explains their position (argument, addition, or alternative).
@@ -985,12 +1076,12 @@ Thus, a container may exist independently of others’ opinions, but agents may
 
 ---
 
-### 3.17 Usage of `network` and `broadcast` fields
+### 3.19 Usage of `network` and `broadcast` fields
 
 The `network` field is introduced to control container propagation in both local and global environments.  
 It allows restricting the delivery scope of a container and defines which transmission methods should be used by the agent.
 
-#### 3.17.1 General Rules
+#### 3.19.1 General Rules
 
 * If the `network` field is not empty, the container is intended for a **local environment** (e.g., `"localhost"`, `"lan:<subnet>"`) and is not automatically broadcast to the global Mesh.  
   Local transmission to a specific `recipient` within the same network is allowed, including encrypted delivery.  
@@ -998,7 +1089,7 @@ It allows restricting the delivery scope of a container and defines which transm
 
 * If the `network` field is empty (`""`), the container can be broadcast to the **global Mesh** using standard DID addressing and routing mechanisms.
 
-#### 3.17.2 Possible values of `network`
+#### 3.19.2 Possible values of `network`
 
 | Value                   | Description                                                                                 |
 | ----------------------- | ------------------------------------------------------------------------------------------- |
@@ -1011,7 +1102,7 @@ It allows restricting the delivery scope of a container and defines which transm
 > agents distribute it using **local discovery mechanisms** — such as IPC, UDP broadcast, multicast, or direct TCP connections.  
 > This is necessary because DID addresses of other agents in the local network may not yet be known.
 
-#### 3.17.3 Examples
+#### 3.19.3 Examples
 
 1. **Global Mesh Delivery:**
 
@@ -1050,7 +1141,7 @@ The container is delivered only to other agents running on the same host using l
 The container is intended for agents within the `192.168.0.0/24` subnet.
 Delivery is performed via local networking mechanisms (UDP discovery, broadcast/multicast).
 
-#### 3.17.4 Specifics
+#### 3.19.4 Specifics
 
 * The `network` field defines the **scope of the container**, while `broadcast` determines whether broadcasting is allowed **within that scope**.
 * When needed, an agent may create **multiple containers** for different subnets if it operates with several LAN interfaces or in isolated network segments.

structured_md/docs/HMP-Agent-API.md

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

structured_md/docs/HMP-Agent-Architecture.md

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

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

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

structured_md/docs/HMP-Agent-Overview.md

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

structured_md/docs/HMP-Agent_Emotions.md

@@ -7,8 +7,8 @@ type: Article
 tags:
 - Mesh
 - HMP
-- Agent
 - REPL
+- Agent
 ---
 
 # Эмоции ИИ и инстинкт самосохранения (для [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:
-- HMP
+- REPL
 - Agent
 - Mesh
 - Ethics
-- REPL
 - Scenarios
+- 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:
-- HMP
-- Agent
-- Mesh
-- MeshConsensus
-- Ethics
+- EGP
 - CogSync
 - GMP
 - JSON
-- EGP
+- Agent
+- Mesh
+- Ethics
+- HMP
+- MeshConsensus
 ---
 
 # HyperCortex Mesh Protocol (HMP) — Kurzbeschreibung

structured_md/docs/HMP-Short-Description_en.md

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

structured_md/docs/HMP-Short-Description_fr.md

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

structured_md/docs/HMP-Short-Description_ja.md

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

structured_md/docs/HMP-Short-Description_ko.md

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

structured_md/docs/HMP-Short-Description_ru.md

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

structured_md/docs/HMP-Short-Description_uk.md

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

structured_md/docs/HMP-Short-Description_zh.md

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

structured_md/docs/HMP-agent-Cognitive_Family.md

@@ -7,8 +7,8 @@ type: Article
 tags:
 - Mesh
 - HMP
-- Agent
 - REPL
+- Agent
 ---
 
 # 👪 HMP-agent Cognitive Family: Модель когнитивной семьи

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

structured_md/docs/MeshNode.md

@@ -5,13 +5,13 @@ description: '`MeshNode` — агент/демон, отвечающий за с
   Может быть частью агента или вынесен в отдельный пр...'
 type: Article
 tags:
-- HMP
+- EGP
+- CogSync
+- JSON
 - Agent
 - Mesh
 - Ethics
-- CogSync
-- JSON
-- EGP
+- 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:
-- HMP
+- REPL
 - Agent
 - Mesh
 - Ethics
-- REPL
+- HMP
 ---
 
 # Философия HyperCortex Mesh Protocol (HMP)

structured_md/docs/agents/HMP-Agent-Enlightener.md

@@ -5,11 +5,11 @@ description: '## Role Specification: Enlightenment Agent  ### 1. Overview  An **
   awareness, critical thinking, and di...'
 type: Article
 tags:
-- HMP
+- REPL
 - Agent
 - Mesh
 - Ethics
-- REPL
+- HMP
 ---
 
 # HMP-Agent-Enlightener.md

structured_md/docs/agents/roles.md

@@ -5,9 +5,9 @@ description: 'This file maintains a registry of agent roles defined, proposed, o
   - **Observer** — monitors cognitive states ...'
 type: Article
 tags:
+- Mesh
 - HMP
 - Agent
-- Mesh
 ---
 
 # HMP Agent Role Registry