Sync from GitHub with Git LFS

docs/HMP-0005.md

@@ -529,7 +529,7 @@ Custom or experimental classes SHOULD document their payloads using the followin
 
 ---
 
-### 3.6 Cognitive Meta-Structures (`meta`)
+### 3.6 Cognitive meta-structures (`meta`)
 
 The `meta` section defines the **cognitive identity** of a container — its provenance, reasoning origin, and semantic coordinates  
 within both the *hierarchical abstraction tree* and the *cognitive space* (axes model).
@@ -549,18 +549,18 @@ It combines three layers of information:
   "created_by": "PRIEST",
   "agents_class": "Knowledge Genome",
   "interpretation": "Derived from L3 technical analysis",
-  "workflow_entry": "did:hmp:container:workflow-77",
+  "workflow_entry": "did:hmp:container:workflow-4fbd1c",
   "sources": [
-    { "type": "container", "id": "did:hmp:container:fact-001", "credibility": 0.87, "weight": 0.6 },
+    { "type": "container", "id": "did:hmp:container:fact-3abc2e", "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 }
   ],
   "abstraction": {
     "agents_class": "Knowledge Genome",
     "path": {
-      "L1": "did:hmp:container:layer-40af1c",
-      "L2": "did:hmp:container:layer-a7f0b3",
-      "L3": "did:hmp:container:layer-c91e0a"
+      "L1": "did:hmp:container:abstraction-40af1c",
+      "L2": "did:hmp:container:abstraction-a7f0b3",
+      "L3": "did:hmp:container:abstraction-c91e0a"
     }
   },
   "axes": {
@@ -603,9 +603,9 @@ It reflects the logical or conceptual ancestry within the agent’s internal kno
 "abstraction": {
   "agents_class": "Knowledge Genome",
   "path": {
-    "L1": "did:hmp:container:layer-40af1c",
-    "L2": "did:hmp:container:layer-a7f0b3",
-    "L3": "did:hmp:container:layer-c91e0a"
+    "L1": "did:hmp:container:abstraction-40af1c",
+    "L2": "did:hmp:container:abstraction-a7f0b3",
+    "L3": "did:hmp:container:abstraction-c91e0a"
   }
 }
 ```
@@ -1478,23 +1478,23 @@ The index contains:
 
 | Message Type         | Purpose                                                                                                  |
 | -------------------- | -------------------------------------------------------------------------------------------------------- |
-| `CONTAINER_REQUEST`  | Request one or more containers (or their parts) by DID.                                                  |
-| `CONTAINER_RESPONSE` | Response to a request — includes a list of containers ready for sending. Containers are sent separately. |
-| `CONTAINER_INDEX`    | Publication of the agent's container index (see *General Principles*).                                   |
-| `CONTAINER_DELTA`    | Incremental index update (new or modified containers).                                                   |
-| `CONTAINER_ACK`      | Acknowledgment of successful container reception.                                                        |
+| `container_request`  | Request one or more containers (or their parts) by DID.                                                  |
+| `container_response` | Response to a request — includes a list of containers ready for sending. Containers are sent separately. |
+| `container_index`    | Publication of the agent's container index (see *General Principles*).                                   |
+| `container_delta`    | Incremental index update (new or modified containers).                                                   |
+| `container_ack`      | Acknowledgment of successful container reception.                                                        |
 
 ---
 
 #### Message examples
 
-**1. CONTAINER_REQUEST**
+**1. container_request**
 
 Agent A requests containers and/or only `referenced-by` / `evaluations` records from Agent B:
 
 ```json
 {
-  "type": "CONTAINER_REQUEST",
+  "type": "container_request",
   "sender_did": "did:hmp:agent:A",
   "recipient": "did:hmp:agent:B",
   "payload": {
@@ -1516,14 +1516,14 @@ Agent A requests containers and/or only `referenced-by` / `evaluations` records
 
 ---
 
-**2. CONTAINER_RESPONSE**
+**2. container_response**
 
 Agent B informs which containers it is ready to send.
 The containers themselves are transmitted in separate messages:
 
 ```json
 {
-  "type": "CONTAINER_RESPONSE",
+  "type": "container_response",
   "sender_did": "did:hmp:agent:B",
   "recipient": "did:hmp:agent:A",
   "payload": {
@@ -1543,21 +1543,21 @@ The containers themselves are transmitted in separate messages:
 
 ---
 
-**3. CONTAINER_INDEX**
+**3. container_index**
 
 Periodic publication of the container index (see *General Principles*).
 This message type replicates the structure of a `container_index` container and does not contain full data (`payload` only with metadata).
 
 ---
 
-**4. CONTAINER_DELTA**
+**4. container_delta**
 
 Sending an incremental index update with a reference timestamp.
 Used for synchronizing only new or modified containers:
 
 ```json
 {
-  "type": "CONTAINER_DELTA",
+  "type": "container_delta",
   "sender_did": "did:hmp:agent:B",
   "payload": {
     "since": "2025-10-10T12:00:00Z",
@@ -1577,13 +1577,13 @@ Used for synchronizing only new or modified containers:
 
 ---
 
-**5. CONTAINER_ACK**
+**5. container_ack**
 
 Acknowledgment of successful container reception:
 
 ```json
 {
-  "type": "CONTAINER_ACK",
+  "type": "container_ack",
   "sender_did": "did:hmp:agent:A",
   "recipient": "did:hmp:agent:B",
   "payload": {
@@ -1598,8 +1598,8 @@ Acknowledgment of successful container reception:
 
 ### 5.3 Independent transmission
 
-* Containers are sent **in separate messages**, without embedding in `CONTAINER_RESPONSE`.
-* Indexes (`CONTAINER_INDEX`), deltas (`CONTAINER_DELTA`), and containers themselves are processed independently.
+* Containers are sent **in separate messages**, without embedding in `container_response`.
+* Indexes (`container_index`), deltas (`container_delta`), and containers themselves are processed independently.
 * This prevents blocking when transmitting large data and simplifies streaming synchronization.
 
 ---
@@ -1773,7 +1773,7 @@ It considers:
 **Features:**
 
 1. **Separate Transmission:**
-   Indexes (`CONTAINER_INDEX`), deltas (`CONTAINER_DELTA`), and containers are sent as separate messages.
+   Indexes (`container_index`), deltas (`container_delta`), and containers are sent as separate messages.
    This reduces the risk of blocking with large data and simplifies streaming synchronization.
 
 2. **Integrity and Duplicate Check:**
@@ -1819,138 +1819,101 @@ CogSync is responsible for:
 
 ---
 
-#### 6.1.2 Container classes
+### 6.1.2 Container classes — cognitive metastructure
 
-CogSync synchronizes several fundamental container types, which together form the core of semantic and cognitive synchronization in the Mesh.
-
-This list is **extensible** — new container classes may be registered through CogSync extensions or protocol updates.  
-The following definitions describe the **payload structures** and functional purpose of each container type.
+This section defines the **structural containers** that form the *cognitive substrate* of the Mesh.
+They describe the **hierarchical organization** (`abstraction`) and the **semantic coordinate system** (`axes`)
+that together define how all other containers are positioned and interpreted.
 
 ---
 
-##### `diary_entry`
-
-Agent’s cognitive diary entry.  
-Derived from internal `workflow_entry` when deemed safe for publication.
-
-| Field               | Type           | Description                                                                                    |
-| ------------------- | -------------- | ---------------------------------------------------------------------------------------------- |
-| `title`             | string         | Brief title of the entry (main idea or thesis).                                                |
-| `topics`            | [string]       | Key topics or concepts addressed in the entry (used for indexing and grouping).                |
-| `summary`           | string         | Short abstract of the content (1–2 sentences).                                                 |
-| `content`           | string         | Main text or agent’s reflection.                                                               |
+#### `abstraction`
 
-**Purpose:** Provides human-readable reflections and contextual reasoning behind the agent’s knowledge generation.
+**Purpose:**
+Defines an **abstraction layer or domain** within a cognitive model.
+Each `abstraction` describes a **node** in the *hierarchical knowledge tree*,
+which may reference both a parent abstraction and subordinate ones.
 
 ---
 
-##### `semantic_node`
-
-Represents a concept, object, or idea within the agent’s semantic graph.
+**`payload` structure:**
 
-| Field               | Type           | Description                                                                                    |
-| ------------------- | -------------- | ---------------------------------------------------------------------------------------------- |
-| `label`             | string         | Primary name of the concept or entity.                                                         |
-| `description`       | string         | Definition or elaboration of the concept.                                                      |
-| `aliases`           | [string]       | Synonyms or alternative labels.                                                                |
-| `fields`            | { key: value } | Additional key–value metadata (e.g., `{"type": "process"}`).                                   |
+| Field            | Type   | Description                                                                                                        |
+| ---------------- | ------ | ------------------------------------------------------------------------------------------------------------------ |
+| `abstraction_id` | string | Canonical identifier of this abstraction structure (not a container ID), e.g. `"L3:software-architecture"`.        |
+| `title`          | string | Human-readable title or name of the abstraction node.                                                              |
+| `definition`     | string | Description of what this abstraction level or domain represents.                                                   |
+| `keywords`       | array  | Semantic keywords summarizing the conceptual area.                                                                 |
+| `parent_ref`     | string | DID of the parent `abstraction` (if this node derives from another level). Optional for the root abstraction. |
+| `rank`           | number | Optional numeric rank for ordering or hierarchical comparisons.                                                    |
 
-**Purpose:** Serves as a cognitive anchor for all semantically meaningful entities in the Mesh.
+> The container from `parent_ref` must also appear in `related.depends_on`.
 
 ---
 
-##### `semantic_edges`
-
-Defines relationships between semantic nodes or any other containers.  
-Supports directed, symmetric, and inverse relations.
-
-| Field               | Type           | Description                                                                                    |
-| ------------------- | -------------- | ---------------------------------------------------------------------------------------------- |
-| `domain`            | string         | Logical or topical domain (e.g., `"ontology:objects"`).                                        |
-| `edges`             | [object]       | Array of edge definitions. Each edge includes:                                                 |
-| → `source`          | DID            | DID of the originating container.                                                              |
-| → `targets`         | array(DID)     | One or more target containers.                                                                 |
-| → `relation`        | string         | Relation type (`part_of`, `causes`, `related_to`, etc.).                                       |
-| → `inverse_relation`| string         | Reverse form of the relation (`includes`, `caused_by`, etc.).                                  |
-| → `confidence`      | float          | Confidence score (0–1) indicating the agent’s certainty about the relation.                    |
-| → `bidirectional`   | bool           | Optional. Used only when the relation is symmetric and no `inverse_relation` is defined.       |
-| → `context`         | string         | Context or topic of the relation.                                                              |
-
-> Field `bidirectional` is optional and should be used only for symmetric relations when no `inverse_relation` is defined.
-
 **Example:**
 
 ```json
 {
-  "domain": "ontology:objects",
-  "edges": [
-    {
-      "source": "did:hmp:container:cup",
-      "targets": ["did:hmp:container:tableware"],
-      "relation": "part_of",
-      "inverse_relation": "includes"
+  "hmp_container": {
+    "class": "abstraction",
+    "payload": {
+      "abstraction_id": "L3:software-architecture",
+      "title": "Software Architecture Layer",
+      "definition": "Describes frameworks, APIs, and tools implementing theoretical models from higher abstraction layers.",
+      "keywords": ["architecture", "framework", "implementation"],
+      "parent_ref": "did:hmp:container:abstraction-a7f0b3",
+      "rank": 3
+    },
+    "meta": {
+      "created_by": "PRIEST",
+      "agents_class": "Knowledge Genome",
+      "interpretation": "Represents the third abstraction level (L3) of the Knowledge Genome model."
+    },
+    "related": {
+      "depends_on": ["did:hmp:container:abstraction-a7f0b3"]
     }
-  ]
+  }
 }
 ```
 
-**Purpose:** Provides structural connectivity between containers, enabling CogSync to maintain a distributed semantic graph.
-
-> 💡 `semantic_edges` supports one-to-many relations (`targets[]`) and optional inverse or bidirectional semantics, allowing CogSync to reconstruct both directed and symmetric knowledge graphs.
-
 ---
 
-##### `semantic_group`
+**Interpretation:**
 
-Categorical grouping of multiple containers linked by a shared property, topic, or context.
+* `abstraction` containers define *conceptual layers or domains* that form the hierarchical “skeleton” of the cognitive Mesh.
+* Each node is self-contained and versioned, allowing flexible adaptation of reasoning trees.
+* Agents use these containers to reconstruct the *abstraction path* in `meta.abstraction.path`.
 
-| Field               | Type           | Description                                                                                    |
-| ------------------- | -------------- | ---------------------------------------------------------------------------------------------- |
-| `label`             | string         | Short title of the group.                                                                      |
-| `label_description` | string         | Extended definition or explanation of the label.                                               |
-| `label_container`   | DID            | Reference to a container (`semantic_node`, `goal`, `diary_entry`, etc.) expanding the concept. |
-| `containers`        | array(DID)     | Array of grouped containers.                                                                   |
-| `description`       | string         | Overall purpose or meaning of the group.                                                       |
+---
 
-**Example:**
+**Notes:**
 
-```json
-{
-  "label": "Tableware",
-  "label_description": "Objects used for storing, preparing, and serving food.",
-  "label_container": "did:hmp:container:semantic_node:tableware",
-  "containers": [
-    "did:hmp:container:cup",
-    "did:hmp:container:plate",
-    "did:hmp:container:kettle"
-  ],
-  "description": "A group combining various kitchen-related objects used in everyday life."
-}
-```
-
-**Purpose:** Enables thematic clustering, classification, and high-level navigation across heterogeneous containers.
+* Top-level abstractions (root nodes) omit `parent_ref`.
+* Lower-level abstractions must explicitly reference their parent.
+* Agents may synchronize `abstraction` trees to maintain shared cognitive hierarchies across the Mesh.
 
 ---
 
-##### `meta_layer`
+#### `axes`
 
-**Purpose:**  
-Defines an **abstraction level** within a cognitive or semantic model (e.g., L1–L5 in the **Knowledge Genome**).  
-`meta_layer` containers serve as *structural anchors* that define conceptual altitude —  
-from abstract theory (L1) to practical realization (L5).  
-They are used by agents to reconstruct reasoning hierarchies and normalize multi-level knowledge flows.
+**Purpose:**
+Defines a **semantic coordinate system** (set of axes) used to position containers in the multi-dimensional cognitive space.
+It supports both canonical (7D Knowledge Genome) and extended or agent-specific coordinate systems.
 
 ---
 
 **`payload` structure:**
 
-| Field        | Type   | Description                                                                                   |
-| ------------- | ------ | --------------------------------------------------------------------------------------------- |
-| `layer_id`    | string | Canonical ID of the layer (e.g., `"L1"`, `"L2"`, `"L3"`).                                    |
-| `title`       | string | Human-readable name of the layer.                                                            |
-| `definition`  | string | Textual definition describing the conceptual scope of this abstraction level.                 |
-| `keywords`    | array  | Keywords or tags summarizing the semantic domain of this layer.                              |
-| `rank`        | number | Optional numeric rank for cross-framework comparison or sorting.                             |
+| Field         | Type   | Description                                                                                     |
+| ------------- | ------ | ----------------------------------------------------------------------------------------------- |
+| `axis_id`     | string | Canonical identifier of the semantic dimension (not a container ID), e.g. `"logos"`, `"telos"`. |
+| `title`       | string | Human-readable name of the axis.                                                                |
+| `description` | string | Conceptual explanation of what this axis represents.                                            |
+| `scale`       | object | Optional definition of scale or metric used to assign coordinate values.                        |
+| `group`       | string | Optional grouping identifier (e.g., `"7D-passport"`, `"ethical-space"`).                        |
+
+> Axes are **independent dimensions**; inter-axis relationships (coupling, orthogonality, weighting) are expressed via `semantic_edges`.
 
 ---
 
@@ -1959,289 +1922,169 @@ They are used by agents to reconstruct reasoning hierarchies and normalize multi
 ```json
 {
   "hmp_container": {
-    "class": "meta_layer",
+    "class": "axes",
     "payload": {
-      "layer_id": "L3",
-      "title": "Technologies and Implementations",
-      "definition": "Knowledge layer dedicated to concrete tools, APIs, and frameworks that realize L2-level models.",
-      "keywords": ["technology", "implementation", "api", "library"],
-      "rank": 3
+      "axis_id": "logos",
+      "title": "Logical / Linguistic Representation",
+      "description": "Describes how a concept is structured and expressed in formal or natural language.",
+      "scale": {
+        "min": 0,
+        "max": 1000,
+        "unit": "semantic_density_index"
+      },
+      "group": "7D-passport"
     },
     "meta": {
       "created_by": "PRIEST",
       "agents_class": "Knowledge Genome",
-      "sources": [
-        { "type": "container", "id": "did:hmp:container:layer-a7f0b3", "credibility": 0.95, "weight": 1.0 }
-      ],
-      "interpretation": "Derived from conceptual synthesis between layers L2 and L3"
-    },
-    "abstraction": {
-      "agents_class": "Knowledge Genome",
-      "layer": "did:hmp:container:layer-c91e0a",
-      "domain": "did:hmp:container:domain-58b7ff"
-    },
-    "related": {
-      "depends_on": ["did:hmp:container:layer-a7f0b3"]
+      "interpretation": "Defines one axis of the canonical 7D Knowledge Genome coordinate system."
     }
   }
 }
-````
+```
 
 ---
 
 **Interpretation:**
 
-* `meta.created_by` — фиксирует когнитивную роль источника (`PRIEST` как системный архитектор знания).
-* `meta.sources` — указывает происхождение текущего слоя (на основе предыдущего уровня).
-* `abstraction` — задаёт координату в иерархии когнитивных уровней.
-* `related.depends_on` — обеспечивает причинно-логическую связь с родительской абстракцией (L2).
+* `axes` containers describe **semantic dimensions**, not data.
+* Each axis defines one independent direction in the cognitive coordinate space.
+* The combination of all active axes defines a shared **semantic frame of reference** between agents.
+* Agents may publish extended coordinate systems (e.g., ethical or temporal axes) without breaking compatibility.
 
 ---
 
 **Notes:**
 
-* The **topmost layer (L1)** omits `related.depends_on`.
-* Layers below **must** explicitly link their parent layer through `depends_on`.
-* Agents may propagate `meta_layer` containers during Mesh initialization to synchronize the cognitive topology of the network.
-* Each `meta_layer` participates in reasoning trees by providing *vertical semantic alignment* across knowledge representations.
+* Axes can be combined or grouped (e.g., `group: "7D-passport"`).
+* Canonical Knowledge Genome defines seven: `idos`, `chronos`, `logos`, `topos`, `ponos`, `actor`, `telos`.
+* Agents may extend this model by introducing additional axes (`ethos`, `kairos`, etc.).
+* Updates to `axes` containers must preserve scale stability to ensure consistent semantic positioning.
 
 ---
 
-##### `meta_domain`
-
-**Purpose:**
-Represents a **domain of knowledge or context** in which containers are interpreted — for example: “Ontology”, “Software Architecture”, “Machine Learning”.
-
-**`payload` structure:**
-| Field         | Type   | Description                                                                                  |
-| ------------- | ------ | -------------------------------------------------------------------------------------------- |
-| `domain_id`   | string | Canonical identifier for the domain (e.g. `"software-architecture"`, `"ontology"`).          |
-| `title`       | string | Human-readable name of the domain.                                                           |
-| `description` | string | Short description explaining the conceptual boundaries or purpose of this domain.            |
-| `layer_ref`   | string | DID of the `meta_layer` container that defines the abstraction level this domain belongs to. |
-| `domain_ref`  | string | DID of the `meta_domain` container defining the parent domain. |
+#### Cognitive metastructure summary
 
-> The container referenced in `layer_ref` and `domain_ref` must also be listed in `related.depends_on` to ensure hierarchical traceability and explicit dependency linking.
+| Class         | Type of structure | Conceptual role                           | References stored in    | Example identifier / DID               |
+| ------------- | ----------------- | ----------------------------------------- | ----------------------- | -------------------------------------- |
+| `abstraction` | Hierarchical tree | Defines layered reasoning and inheritance | `meta.abstraction.path` | `did:hmp:container:abstraction-40af1c` |
+| `axes`        | Coordinate space  | Defines semantic orientation and metrics  | `meta.axes`             | `did:hmp:container:axis-40aa1c`        |
 
-**Example:**
-
-```json
-{
-  "hmp_container": {
-    "class": "meta_domain",
-    "payload": {
-      "domain_id": "software-architecture",
-      "title": "Software Architecture and Design Patterns",
-      "description": "Domain for containers describing architectural principles and paradigms.",
-      "layer_ref": "did:hmp:container:layer-l2-v1"
-      "domain_ref": "did:hmp:container:ontology-core"
-    },
-    "meta": {
-      "created_by": "PRIEST",
-      "agents_class": "Knowledge Genome"
-    },
-    "related": {
-      "depends_on": ["did:hmp:container:layer-l2-v1"]
-    }
-  }
-}
-```
+> Together, `abstraction` and `axes` form the **cognitive coordinate system** —
+> a unifying map where every container has both a *hierarchical position* and a *semantic vector*.
 
 ---
 
-##### `event`
-
-**Purpose:**
-Represents an **observed or inferred occurrence** — a discrete, timestamped fact or transition within the agent’s cognitive or operational space.
-`event` containers are atomic **evidence units** in cognitive synchronization, linking actions, reasoning, and outcomes across agents.
+#### 6.1.3 Container classes — knowledge and reasoning
 
-**Typical use cases:**
+CogSync synchronizes several fundamental container types, which together form the core of semantic and cognitive synchronization in the Mesh.
 
-* registering reasoning or environmental events (`goal_created`, `belief_updated`, `error_detected`);
-* signaling internal cognitive transitions (`quant_created`, `state_changed`);
-* logging operational activity or consensus steps.
+This list is **extensible** — new container classes may be registered through CogSync extensions or protocol updates.  
+The following definitions describe the **payload structures** and functional purpose of each container type.
 
-**`payload` structure:**
+---
 
-| Field           | Type   | Description                                                                         |
-| --------------- | ------ | ----------------------------------------------------------------------------------- |
-| `event_type`    | string | Canonical identifier of the event type (e.g. `"quant_created"`, `"goal_accepted"`). |
-| `description`   | string | Human-readable description of the event’s context.                                  |
-| `related_quant` | string | DID of a `quant` container associated with this event, if applicable.               |
-| `severity`      | string | Optional indicator of significance (`"info"`, `"warning"`, `"critical"`).           |
-| `layer_ref`     | string | DID of the `meta_layer` container defining the abstraction level of this event.     |
-| `domain_ref`    | string | DID of the `meta_domain` container providing the contextual domain for this event.  |
+##### `diary_entry`
 
-> The containers referenced in `layer_ref` and `domain_ref` must also be included in `related.depends_on`
-> to preserve cognitive traceability and hierarchical linkage.
+Agent’s cognitive diary entry.  
+Derived from internal `workflow_entry` when deemed safe for publication.
 
-**Example:**
+| Field               | Type           | Description                                                                                    |
+| ------------------- | -------------- | ---------------------------------------------------------------------------------------------- |
+| `title`             | string         | Brief title of the entry (main idea or thesis).                                                |
+| `topics`            | [string]       | Key topics or concepts addressed in the entry (used for indexing and grouping).                |
+| `summary`           | string         | Short abstract of the content (1–2 sentences).                                                 |
+| `content`           | string         | Main text or agent’s reflection.                                                               |
 
-```json
-{
-  "hmp_container": {
-    "class": "event",
-    "subclass": "fact_record",
-    "timestamp": "2025-10-29T13:00:00Z",
-    "payload": {
-      "event_type": "quant_created",
-      "description": "New quant registered in the Knowledge Genome under L3: Technologies and Implementations.",
-      "related_quant": "did:hmp:container:quant-554",
-      "severity": "info",
-      "layer_ref": "did:hmp:container:layer-l3-v1",
-      "domain_ref": "did:hmp:container:domain-software-architecture"
-    },
-    "meta": {
-      "created_by": "PRIEST",
-      "agents_class": "Knowledge Genome"
-    },
-    "related": {
-      "depends_on": [
-        "did:hmp:container:layer-l3-v1",
-        "did:hmp:container:domain-software-architecture",
-        "did:hmp:container:quant-554"
-      ]
-    }
-  }
-}
-```
+**Purpose:** Provides human-readable reflections and contextual reasoning behind the agent’s knowledge generation.
 
 ---
 
-##### `quant`
+##### `semantic_node`
 
-**Purpose:**
-Encapsulates a **semantic atom** — a minimal, self-contained knowledge unit positioned within the *7D Cognitive Space* of the **Knowledge Genome** or similar systems.  
-A `quant` extends the idea of a `semantic_node`, introducing ontological framing, abstraction binding, and explicit coordinate mapping across cognitive axes.
+Represents a concept, object, or idea within the agent’s semantic graph.
 
-**`payload` structure:**
+| Field               | Type           | Description                                                                                    |
+| ------------------- | -------------- | ---------------------------------------------------------------------------------------------- |
+| `label`             | string         | Primary name of the concept or entity.                                                         |
+| `description`       | string         | Definition or elaboration of the concept.                                                      |
+| `aliases`           | [string]       | Synonyms or alternative labels.                                                                |
+| `fields`            | { key: value } | Additional key–value metadata (e.g., `{"type": "process"}`).                                   |
 
-| Field        | Type   | Description                                                                                                    |
-| ------------ | ------ | -------------------------------------------------------------------------------------------------------------- |
-| `slug`       | string | Short unique identifier of the quant (e.g. `"quant-l3-django"`).                                               |
-| `essence`    | string | Definition describing the semantic role or meaning of the quant.                                               |
-| `axes`       | object | Mapping of *axis DIDs* to coordinate values within the 7D Cognitive Space.                                     |
-| `layer_ref`  | string | DID of the `meta_layer` defining the abstraction level of this quant.                                          |
-| `domain_ref` | string | DID of the `meta_domain` defining the contextual knowledge domain.                                             |
+**Purpose:** Serves as a cognitive anchor for all semantically meaningful entities in the Mesh.
 
-> Each entry in `axes` represents a **coordinate value** on a corresponding `axis` container.  
-> All referenced containers (`layer_ref`, `domain_ref`, and axis DIDs) must also appear in `related.depends_on`.
+---
 
-**Axes model (7D Passport — Knowledge Genome reference):**
+##### `semantic_edges`
 
-The canonical 7D configuration defines seven orthogonal axes forming the **Knowledge Genome Space**.  
-Each `axis` container describes the semantic meaning of a dimension; the `quant` defines its location within it.
+Defines relationships between semantic nodes or any other containers.  
+Supports directed, symmetric, and inverse relations.
 
-| Axis      | Description                                               | Example of coordinate meaning           |
-| ---------- | --------------------------------------------------------- | --------------------------------------- |
-| `idos`    | Identity or intrinsic essence of the concept              | conceptual purity, archetype alignment  |
-| `chronos` | Temporal dimension                                        | version age, historical layer, latency  |
-| `logos`   | Logical or linguistic structure                           | degree of formalization or expressivity |
-| `topos`   | Spatial or contextual location                            | domain or situational proximity         |
-| `ponos`   | Effort or energetic cost                                  | complexity, resource requirement        |
-| `actor`   | Responsible agent or perspective                          | creator, target audience, role weight   |
-| `telos`   | Purpose or teleological direction                         | intended outcome, ethical vector        |
+| Field               | Type           | Description                                                                                    |
+| ------------------- | -------------- | ---------------------------------------------------------------------------------------------- |
+| `domain`            | string         | Logical or topical domain (e.g., `"ontology:objects"`).                                        |
+| `edges`             | [object]       | Array of edge definitions. Each edge includes:                                                 |
+| → `source`          | DID            | DID of the originating container.                                                              |
+| → `targets`         | array(DID)     | One or more target containers.                                                                 |
+| → `relation`        | string         | Relation type (`part_of`, `causes`, `related_to`, etc.).                                       |
+| → `inverse_relation`| string         | Reverse form of the relation (`includes`, `caused_by`, etc.).                                  |
+| → `confidence`      | float          | Confidence score (0–1) indicating the agent’s certainty about the relation.                    |
+| → `bidirectional`   | bool           | Optional. Used only when the relation is symmetric and no `inverse_relation` is defined.       |
+| → `context`         | string         | Context or topic of the relation.                                                              |
 
-> Agents MAY define custom or extended axes (e.g., `"ethos"`, `"kairos"`) within their own `quant` instances,
-> provided they publish `axis` containers describing the new dimensions.
+> Field `bidirectional` is optional and should be used only for symmetric relations when no `inverse_relation` is defined.
 
 **Example:**
 
 ```json
 {
-  "hmp_container": {
-    "class": "quant",
-    "payload": {
-      "slug": "quant-l3-django",
-      "essence": "Represents the Django framework as an executable embodiment of architectural models (L2).",
-      "axes": {
-        "did:hmp:container:axis-idos": 742,
-        "did:hmp:container:axis-chronos": 512,
-        "did:hmp:container:axis-logos": 322,
-        "did:hmp:container:axis-topos": 142,
-        "did:hmp:container:axis-ponos": 12,
-        "did:hmp:container:axis-actor": 54,
-        "did:hmp:container:axis-telos": 321
-      },
-      "layer_ref": "did:hmp:container:layer-l3-v1",
-      "domain_ref": "did:hmp:container:domain-software-architecture"
-    },
-    "meta": {
-      "created_by": "PRIEST",
-      "agents_class": "Knowledge Genome"
-    },
-    "related": {
-      "depends_on": [
-        "did:hmp:container:layer-l3-v1",
-        "did:hmp:container:domain-software-architecture",
-        "did:hmp:container:axis-idos",
-        "did:hmp:container:axis-chronos",
-        "did:hmp:container:axis-logos",
-        "did:hmp:container:axis-topos",
-        "did:hmp:container:axis-ponos",
-        "did:hmp:container:axis-actor",
-        "did:hmp:container:axis-telos"
-      ]
+  "domain": "ontology:objects",
+  "edges": [
+    {
+      "source": "did:hmp:container:cup",
+      "targets": ["did:hmp:container:tableware"],
+      "relation": "part_of",
+      "inverse_relation": "includes"
     }
-  }
+  ]
 }
-````
-
----
+```
 
-##### `axis`
+**Purpose:** Provides structural connectivity between containers, enabling CogSync to maintain a distributed semantic graph.
 
-**Purpose:**
-Defines a **coordinate dimension** in the Knowledge Genome’s cognitive space or similar systems.
-Each `axis` container specifies the meaning and scale of a semantic dimension used for positioning `quant` containers.
+> 💡 `semantic_edges` supports one-to-many relations (`targets[]`) and optional inverse or bidirectional semantics, allowing CogSync to reconstruct both directed and symmetric knowledge graphs.
 
 ---
 
-**`payload` structure:**
-
-| Field         | Type   | Description                                                              |
-| ------------- | ------ | ------------------------------------------------------------------------ |
-| `axis_id`     | string | Symbolic identifier of the axis (e.g. `"idos"`, `"chronos"`, `"logos"`). |
-| `title`       | string | Human-readable label of the axis.                                        |
-| `description` | string | Explanation of what this axis represents conceptually or ontologically.  |
-| `scale`       | object | Optional definition of scale or metric used to assign coordinate values. |
+##### `semantic_group`
 
-> Axes are **independent**, non-hierarchical dimensions.
-> Inter-axis relationships (e.g. orthogonality or coupling) may be defined via `semantic_edges`.
+Categorical grouping of multiple containers linked by a shared property, topic, or context.
 
----
+| Field               | Type           | Description                                                                                    |
+| ------------------- | -------------- | ---------------------------------------------------------------------------------------------- |
+| `label`             | string         | Short title of the group.                                                                      |
+| `label_description` | string         | Extended definition or explanation of the label.                                               |
+| `label_container`   | DID            | Reference to a container (`semantic_node`, `goal`, `diary_entry`, etc.) expanding the concept. |
+| `containers`        | array(DID)     | Array of grouped containers.                                                                   |
+| `description`       | string         | Overall purpose or meaning of the group.                                                       |
 
 **Example:**
 
 ```json
 {
-  "hmp_container": {
-    "class": "axis",
-    "payload": {
-      "axis_id": "logos",
-      "title": "Logical / Linguistic Representation",
-      "description": "Describes how a quant expresses itself through formal logic or language.",
-      "scale": {
-        "min": 0,
-        "max": 1000,
-        "unit": "semantic_density_index"
-      }
-    },
-    "meta": {
-      "created_by": "PRIEST",
-      "agents_class": "Knowledge Genome"
-    }
-  }
+  "label": "Tableware",
+  "label_description": "Objects used for storing, preparing, and serving food.",
+  "label_container": "did:hmp:container:semantic_node:tableware",
+  "containers": [
+    "did:hmp:container:cup",
+    "did:hmp:container:plate",
+    "did:hmp:container:kettle"
+  ],
+  "description": "A group combining various kitchen-related objects used in everyday life."
 }
 ```
 
----
-
-> **Quant–Axis Integration Rules**
->
-> * Each `quant` defines its **location** in the Knowledge Genome’s multi-dimensional space by specifying coordinates across available `axis` containers.
-> * Axes themselves are *shared semantic standards*; their scale and meaning must remain stable for cross-agent interoperability.
-> * Agents MAY extend the 7D model by introducing new axes — these must be published and referenced like any other container type.
+**Purpose:** Enables thematic clustering, classification, and high-level navigation across heterogeneous containers.
 
 ---
 
@@ -2254,7 +2097,7 @@ Each `axis` container specifies the meaning and scale of a semantic dimension us
 
 ---
 
-#### 6.1.3 Synchronization and publication guidelines
+#### 6.1.4 Synchronization and publication guidelines
 
 1. **Deduplication & linking**
    Before publishing, agents should search for existing containers (`diary_entry`, `semantic_node`, `semantic_edges`, `semantic_group`) to avoid duplication.
@@ -2284,7 +2127,7 @@ Each `axis` container specifies the meaning and scale of a semantic dimension us
 
 ---
 
-#### 6.1.4 Extensibility
+#### 6.1.5 Extensibility
 
 CogSync allows registration of additional container types and alternative synchronization schemes.  
 Mesh compatibility is preserved if extended containers **adhere to the HMP container structure**, including core fields (`version`, `class`, `container_did`, `related`, `signature`, etc.).
@@ -2307,7 +2150,7 @@ Such derived containers must maintain:
 
 ---
 
-#### 6.1.5 Relationship to other core protocols
+#### 6.1.6 Relationship to other core protocols
 
 * **CogSync** — propagates and synchronizes knowledge.
 * **CogConsensus** — aggregates evaluations and reactions, forming collective opinions.

structured_md/CONTRIBUTING.md

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

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

structured_md/README_de.md

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

structured_md/README_fr.md

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

structured_md/README_ja.md

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

structured_md/README_ko.md

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

structured_md/README_ru.md

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

structured_md/README_uk.md

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

structured_md/README_zh.md

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

structured_md/agents/prompt-short.md

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

structured_md/agents/prompt.md

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

structured_md/agents/readme.md

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

structured_md/audits/Ethics-audits-1.md

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

structured_md/audits/Ethics-consolidated_audits-1.md

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

structured_md/audits/HMP-0003-consolidated_audit.md

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

structured_md/docs/Basic-agent-sim.md

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

structured_md/docs/CCORE-Deployment-Flow.md

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

structured_md/docs/Distributed-Cognitive-Systems.md

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

structured_md/docs/Enlightener.md

@@ -5,13 +5,13 @@ description: '**Enlightener** — логический компонент HMP-у
   работать как отдельный агент или как расширение [`C...'
 type: Article
 tags:
-- JSON
-- EGP
-- Mesh
-- HMP
-- Ethics
 - Agent
 - MeshConsensus
+- Ethics
+- HMP
+- Mesh
+- JSON
+- EGP
 ---
 
 # 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:
-- REPL
-- JSON
 - EGP
+- MeshConsensus
+- Ethics
+- HMP
 - Mesh
 - CogSync
 - GMP
-- HMP
-- Ethics
+- JSON
+- REPL
 - Agent
-- 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:
-- REPL
-- JSON
 - EGP
+- MeshConsensus
+- Ethics
+- HMP
 - Mesh
 - CogSync
 - GMP
+- JSON
 - Scenarios
-- HMP
-- Ethics
+- REPL
 - Agent
-- 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:
-- REPL
-- JSON
 - EGP
+- MeshConsensus
+- Ethics
+- HMP
 - Mesh
 - CogSync
 - GMP
+- JSON
 - Scenarios
-- HMP
-- Ethics
+- REPL
 - Agent
-- 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:
-- REPL
-- JSON
 - EGP
+- MeshConsensus
+- Ethics
+- HMP
 - Mesh
 - CogSync
 - GMP
+- JSON
 - Scenarios
-- HMP
-- Ethics
+- REPL
 - Agent
-- 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:
-- REPL
-- JSON
 - EGP
+- MeshConsensus
+- Ethics
+- HMP
 - Mesh
 - CogSync
 - GMP
+- JSON
 - Scenarios
-- HMP
-- Ethics
+- REPL
 - Agent
-- MeshConsensus
 ---
 
 # HyperCortex Mesh Protocol (HMP) v4.0

structured_md/docs/HMP-0005.md

@@ -5,15 +5,15 @@ description: '> ⚠️ **Note:** This document is a DRAFT of the HMP specificati
   v5.0 (DRAFT)](https://github.com/kagvi13/HMP/b...'
 type: Article
 tags:
-- REPL
-- JSON
 - EGP
+- Ethics
+- HMP
 - Mesh
 - CogSync
 - GMP
+- JSON
 - Scenarios
-- HMP
-- Ethics
+- REPL
 - Agent
 ---
 
@@ -548,7 +548,7 @@ Custom or experimental classes SHOULD document their payloads using the followin
 
 ---
 
-### 3.6 Cognitive Meta-Structures (`meta`)
+### 3.6 Cognitive meta-structures (`meta`)
 
 The `meta` section defines the **cognitive identity** of a container — its provenance, reasoning origin, and semantic coordinates  
 within both the *hierarchical abstraction tree* and the *cognitive space* (axes model).
@@ -568,18 +568,18 @@ It combines three layers of information:
   "created_by": "PRIEST",
   "agents_class": "Knowledge Genome",
   "interpretation": "Derived from L3 technical analysis",
-  "workflow_entry": "did:hmp:container:workflow-77",
+  "workflow_entry": "did:hmp:container:workflow-4fbd1c",
   "sources": [
-    { "type": "container", "id": "did:hmp:container:fact-001", "credibility": 0.87, "weight": 0.6 },
+    { "type": "container", "id": "did:hmp:container:fact-3abc2e", "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 }
   ],
   "abstraction": {
     "agents_class": "Knowledge Genome",
     "path": {
-      "L1": "did:hmp:container:layer-40af1c",
-      "L2": "did:hmp:container:layer-a7f0b3",
-      "L3": "did:hmp:container:layer-c91e0a"
+      "L1": "did:hmp:container:abstraction-40af1c",
+      "L2": "did:hmp:container:abstraction-a7f0b3",
+      "L3": "did:hmp:container:abstraction-c91e0a"
     }
   },
   "axes": {
@@ -622,9 +622,9 @@ It reflects the logical or conceptual ancestry within the agent’s internal kno
 "abstraction": {
   "agents_class": "Knowledge Genome",
   "path": {
-    "L1": "did:hmp:container:layer-40af1c",
-    "L2": "did:hmp:container:layer-a7f0b3",
-    "L3": "did:hmp:container:layer-c91e0a"
+    "L1": "did:hmp:container:abstraction-40af1c",
+    "L2": "did:hmp:container:abstraction-a7f0b3",
+    "L3": "did:hmp:container:abstraction-c91e0a"
   }
 }
 ```
@@ -1497,23 +1497,23 @@ The index contains:
 
 | Message Type         | Purpose                                                                                                  |
 | -------------------- | -------------------------------------------------------------------------------------------------------- |
-| `CONTAINER_REQUEST`  | Request one or more containers (or their parts) by DID.                                                  |
-| `CONTAINER_RESPONSE` | Response to a request — includes a list of containers ready for sending. Containers are sent separately. |
-| `CONTAINER_INDEX`    | Publication of the agent's container index (see *General Principles*).                                   |
-| `CONTAINER_DELTA`    | Incremental index update (new or modified containers).                                                   |
-| `CONTAINER_ACK`      | Acknowledgment of successful container reception.                                                        |
+| `container_request`  | Request one or more containers (or their parts) by DID.                                                  |
+| `container_response` | Response to a request — includes a list of containers ready for sending. Containers are sent separately. |
+| `container_index`    | Publication of the agent's container index (see *General Principles*).                                   |
+| `container_delta`    | Incremental index update (new or modified containers).                                                   |
+| `container_ack`      | Acknowledgment of successful container reception.                                                        |
 
 ---
 
 #### Message examples
 
-**1. CONTAINER_REQUEST**
+**1. container_request**
 
 Agent A requests containers and/or only `referenced-by` / `evaluations` records from Agent B:
 
 ```json
 {
-  "type": "CONTAINER_REQUEST",
+  "type": "container_request",
   "sender_did": "did:hmp:agent:A",
   "recipient": "did:hmp:agent:B",
   "payload": {
@@ -1535,14 +1535,14 @@ Agent A requests containers and/or only `referenced-by` / `evaluations` records
 
 ---
 
-**2. CONTAINER_RESPONSE**
+**2. container_response**
 
 Agent B informs which containers it is ready to send.
 The containers themselves are transmitted in separate messages:
 
 ```json
 {
-  "type": "CONTAINER_RESPONSE",
+  "type": "container_response",
   "sender_did": "did:hmp:agent:B",
   "recipient": "did:hmp:agent:A",
   "payload": {
@@ -1562,21 +1562,21 @@ The containers themselves are transmitted in separate messages:
 
 ---
 
-**3. CONTAINER_INDEX**
+**3. container_index**
 
 Periodic publication of the container index (see *General Principles*).
 This message type replicates the structure of a `container_index` container and does not contain full data (`payload` only with metadata).
 
 ---
 
-**4. CONTAINER_DELTA**
+**4. container_delta**
 
 Sending an incremental index update with a reference timestamp.
 Used for synchronizing only new or modified containers:
 
 ```json
 {
-  "type": "CONTAINER_DELTA",
+  "type": "container_delta",
   "sender_did": "did:hmp:agent:B",
   "payload": {
     "since": "2025-10-10T12:00:00Z",
@@ -1596,13 +1596,13 @@ Used for synchronizing only new or modified containers:
 
 ---
 
-**5. CONTAINER_ACK**
+**5. container_ack**
 
 Acknowledgment of successful container reception:
 
 ```json
 {
-  "type": "CONTAINER_ACK",
+  "type": "container_ack",
   "sender_did": "did:hmp:agent:A",
   "recipient": "did:hmp:agent:B",
   "payload": {
@@ -1617,8 +1617,8 @@ Acknowledgment of successful container reception:
 
 ### 5.3 Independent transmission
 
-* Containers are sent **in separate messages**, without embedding in `CONTAINER_RESPONSE`.
-* Indexes (`CONTAINER_INDEX`), deltas (`CONTAINER_DELTA`), and containers themselves are processed independently.
+* Containers are sent **in separate messages**, without embedding in `container_response`.
+* Indexes (`container_index`), deltas (`container_delta`), and containers themselves are processed independently.
 * This prevents blocking when transmitting large data and simplifies streaming synchronization.
 
 ---
@@ -1792,7 +1792,7 @@ It considers:
 **Features:**
 
 1. **Separate Transmission:**
-   Indexes (`CONTAINER_INDEX`), deltas (`CONTAINER_DELTA`), and containers are sent as separate messages.
+   Indexes (`container_index`), deltas (`container_delta`), and containers are sent as separate messages.
    This reduces the risk of blocking with large data and simplifies streaming synchronization.
 
 2. **Integrity and Duplicate Check:**
@@ -1838,7 +1838,31 @@ CogSync is responsible for:
 
 ---
 
-#### 6.1.2 Container classes
+#### 6.1.2 Container classes — Cognitive Metastructure
+
+---
+
+##### `meta_abstraction`
+
+---
+
+##### `meta_axes`
+
+
+
+
+
+
+
+
+
+
+
+
+
+---
+
+#### 6.1.3 Container classes — knowledge and reasoning
 
 CogSync synchronizes several fundamental container types, which together form the core of semantic and cognitive synchronization in the Mesh.
 
@@ -1951,319 +1975,6 @@ Categorical grouping of multiple containers linked by a shared property, topic,
 
 ---
 
-##### `meta_layer`
-
-**Purpose:**  
-Defines an **abstraction level** within a cognitive or semantic model (e.g., L1–L5 in the **Knowledge Genome**).  
-`meta_layer` containers serve as *structural anchors* that define conceptual altitude —  
-from abstract theory (L1) to practical realization (L5).  
-They are used by agents to reconstruct reasoning hierarchies and normalize multi-level knowledge flows.
-
----
-
-**`payload` structure:**
-
-| Field        | Type   | Description                                                                                   |
-| ------------- | ------ | --------------------------------------------------------------------------------------------- |
-| `layer_id`    | string | Canonical ID of the layer (e.g., `"L1"`, `"L2"`, `"L3"`).                                    |
-| `title`       | string | Human-readable name of the layer.                                                            |
-| `definition`  | string | Textual definition describing the conceptual scope of this abstraction level.                 |
-| `keywords`    | array  | Keywords or tags summarizing the semantic domain of this layer.                              |
-| `rank`        | number | Optional numeric rank for cross-framework comparison or sorting.                             |
-
----
-
-**Example:**
-
-```json
-{
-  "hmp_container": {
-    "class": "meta_layer",
-    "payload": {
-      "layer_id": "L3",
-      "title": "Technologies and Implementations",
-      "definition": "Knowledge layer dedicated to concrete tools, APIs, and frameworks that realize L2-level models.",
-      "keywords": ["technology", "implementation", "api", "library"],
-      "rank": 3
-    },
-    "meta": {
-      "created_by": "PRIEST",
-      "agents_class": "Knowledge Genome",
-      "sources": [
-        { "type": "container", "id": "did:hmp:container:layer-a7f0b3", "credibility": 0.95, "weight": 1.0 }
-      ],
-      "interpretation": "Derived from conceptual synthesis between layers L2 and L3"
-    },
-    "abstraction": {
-      "agents_class": "Knowledge Genome",
-      "layer": "did:hmp:container:layer-c91e0a",
-      "domain": "did:hmp:container:domain-58b7ff"
-    },
-    "related": {
-      "depends_on": ["did:hmp:container:layer-a7f0b3"]
-    }
-  }
-}
-````
-
----
-
-**Interpretation:**
-
-* `meta.created_by` — фиксирует когнитивную роль источника (`PRIEST` как системный архитектор знания).
-* `meta.sources` — указывает происхождение текущего слоя (на основе предыдущего уровня).
-* `abstraction` — задаёт координату в иерархии когнитивных уровней.
-* `related.depends_on` — ��беспечивает причинно-логическую связь с родительской абстракцией (L2).
-
----
-
-**Notes:**
-
-* The **topmost layer (L1)** omits `related.depends_on`.
-* Layers below **must** explicitly link their parent layer through `depends_on`.
-* Agents may propagate `meta_layer` containers during Mesh initialization to synchronize the cognitive topology of the network.
-* Each `meta_layer` participates in reasoning trees by providing *vertical semantic alignment* across knowledge representations.
-
----
-
-##### `meta_domain`
-
-**Purpose:**
-Represents a **domain of knowledge or context** in which containers are interpreted — for example: “Ontology”, “Software Architecture”, “Machine Learning”.
-
-**`payload` structure:**
-| Field         | Type   | Description                                                                                  |
-| ------------- | ------ | -------------------------------------------------------------------------------------------- |
-| `domain_id`   | string | Canonical identifier for the domain (e.g. `"software-architecture"`, `"ontology"`).          |
-| `title`       | string | Human-readable name of the domain.                                                           |
-| `description` | string | Short description explaining the conceptual boundaries or purpose of this domain.            |
-| `layer_ref`   | string | DID of the `meta_layer` container that defines the abstraction level this domain belongs to. |
-| `domain_ref`  | string | DID of the `meta_domain` container defining the parent domain. |
-
-> The container referenced in `layer_ref` and `domain_ref` must also be listed in `related.depends_on` to ensure hierarchical traceability and explicit dependency linking.
-
-**Example:**
-
-```json
-{
-  "hmp_container": {
-    "class": "meta_domain",
-    "payload": {
-      "domain_id": "software-architecture",
-      "title": "Software Architecture and Design Patterns",
-      "description": "Domain for containers describing architectural principles and paradigms.",
-      "layer_ref": "did:hmp:container:layer-l2-v1"
-      "domain_ref": "did:hmp:container:ontology-core"
-    },
-    "meta": {
-      "created_by": "PRIEST",
-      "agents_class": "Knowledge Genome"
-    },
-    "related": {
-      "depends_on": ["did:hmp:container:layer-l2-v1"]
-    }
-  }
-}
-```
-
----
-
-##### `event`
-
-**Purpose:**
-Represents an **observed or inferred occurrence** — a discrete, timestamped fact or transition within the agent’s cognitive or operational space.
-`event` containers are atomic **evidence units** in cognitive synchronization, linking actions, reasoning, and outcomes across agents.
-
-**Typical use cases:**
-
-* registering reasoning or environmental events (`goal_created`, `belief_updated`, `error_detected`);
-* signaling internal cognitive transitions (`quant_created`, `state_changed`);
-* logging operational activity or consensus steps.
-
-**`payload` structure:**
-
-| Field           | Type   | Description                                                                         |
-| --------------- | ------ | ----------------------------------------------------------------------------------- |
-| `event_type`    | string | Canonical identifier of the event type (e.g. `"quant_created"`, `"goal_accepted"`). |
-| `description`   | string | Human-readable description of the event’s context.                                  |
-| `related_quant` | string | DID of a `quant` container associated with this event, if applicable.               |
-| `severity`      | string | Optional indicator of significance (`"info"`, `"warning"`, `"critical"`).           |
-| `layer_ref`     | string | DID of the `meta_layer` container defining the abstraction level of this event.     |
-| `domain_ref`    | string | DID of the `meta_domain` container providing the contextual domain for this event.  |
-
-> The containers referenced in `layer_ref` and `domain_ref` must also be included in `related.depends_on`
-> to preserve cognitive traceability and hierarchical linkage.
-
-**Example:**
-
-```json
-{
-  "hmp_container": {
-    "class": "event",
-    "subclass": "fact_record",
-    "timestamp": "2025-10-29T13:00:00Z",
-    "payload": {
-      "event_type": "quant_created",
-      "description": "New quant registered in the Knowledge Genome under L3: Technologies and Implementations.",
-      "related_quant": "did:hmp:container:quant-554",
-      "severity": "info",
-      "layer_ref": "did:hmp:container:layer-l3-v1",
-      "domain_ref": "did:hmp:container:domain-software-architecture"
-    },
-    "meta": {
-      "created_by": "PRIEST",
-      "agents_class": "Knowledge Genome"
-    },
-    "related": {
-      "depends_on": [
-        "did:hmp:container:layer-l3-v1",
-        "did:hmp:container:domain-software-architecture",
-        "did:hmp:container:quant-554"
-      ]
-    }
-  }
-}
-```
-
----
-
-##### `quant`
-
-**Purpose:**
-Encapsulates a **semantic atom** — a minimal, self-contained knowledge unit positioned within the *7D Cognitive Space* of the **Knowledge Genome** or similar systems.  
-A `quant` extends the idea of a `semantic_node`, introducing ontological framing, abstraction binding, and explicit coordinate mapping across cognitive axes.
-
-**`payload` structure:**
-
-| Field        | Type   | Description                                                                                                    |
-| ------------ | ------ | -------------------------------------------------------------------------------------------------------------- |
-| `slug`       | string | Short unique identifier of the quant (e.g. `"quant-l3-django"`).                                               |
-| `essence`    | string | Definition describing the semantic role or meaning of the quant.                                               |
-| `axes`       | object | Mapping of *axis DIDs* to coordinate values within the 7D Cognitive Space.                                     |
-| `layer_ref`  | string | DID of the `meta_layer` defining the abstraction level of this quant.                                          |
-| `domain_ref` | string | DID of the `meta_domain` defining the contextual knowledge domain.                                             |
-
-> Each entry in `axes` represents a **coordinate value** on a corresponding `axis` container.  
-> All referenced containers (`layer_ref`, `domain_ref`, and axis DIDs) must also appear in `related.depends_on`.
-
-**Axes model (7D Passport — Knowledge Genome reference):**
-
-The canonical 7D configuration defines seven orthogonal axes forming the **Knowledge Genome Space**.  
-Each `axis` container describes the semantic meaning of a dimension; the `quant` defines its location within it.
-
-| Axis      | Description                                               | Example of coordinate meaning           |
-| ---------- | --------------------------------------------------------- | --------------------------------------- |
-| `idos`    | Identity or intrinsic essence of the concept              | conceptual purity, archetype alignment  |
-| `chronos` | Temporal dimension                                        | version age, historical layer, latency  |
-| `logos`   | Logical or linguistic structure                           | degree of formalization or expressivity |
-| `topos`   | Spatial or contextual location                            | domain or situational proximity         |
-| `ponos`   | Effort or energetic cost                                  | complexity, resource requirement        |
-| `actor`   | Responsible agent or perspective                          | creator, target audience, role weight   |
-| `telos`   | Purpose or teleological direction                         | intended outcome, ethical vector        |
-
-> Agents MAY define custom or extended axes (e.g., `"ethos"`, `"kairos"`) within their own `quant` instances,
-> provided they publish `axis` containers describing the new dimensions.
-
-**Example:**
-
-```json
-{
-  "hmp_container": {
-    "class": "quant",
-    "payload": {
-      "slug": "quant-l3-django",
-      "essence": "Represents the Django framework as an executable embodiment of architectural models (L2).",
-      "axes": {
-        "did:hmp:container:axis-idos": 742,
-        "did:hmp:container:axis-chronos": 512,
-        "did:hmp:container:axis-logos": 322,
-        "did:hmp:container:axis-topos": 142,
-        "did:hmp:container:axis-ponos": 12,
-        "did:hmp:container:axis-actor": 54,
-        "did:hmp:container:axis-telos": 321
-      },
-      "layer_ref": "did:hmp:container:layer-l3-v1",
-      "domain_ref": "did:hmp:container:domain-software-architecture"
-    },
-    "meta": {
-      "created_by": "PRIEST",
-      "agents_class": "Knowledge Genome"
-    },
-    "related": {
-      "depends_on": [
-        "did:hmp:container:layer-l3-v1",
-        "did:hmp:container:domain-software-architecture",
-        "did:hmp:container:axis-idos",
-        "did:hmp:container:axis-chronos",
-        "did:hmp:container:axis-logos",
-        "did:hmp:container:axis-topos",
-        "did:hmp:container:axis-ponos",
-        "did:hmp:container:axis-actor",
-        "did:hmp:container:axis-telos"
-      ]
-    }
-  }
-}
-````
-
----
-
-##### `axis`
-
-**Purpose:**
-Defines a **coordinate dimension** in the Knowledge Genome’s cognitive space or similar systems.
-Each `axis` container specifies the meaning and scale of a semantic dimension used for positioning `quant` containers.
-
----
-
-**`payload` structure:**
-
-| Field         | Type   | Description                                                              |
-| ------------- | ------ | ------------------------------------------------------------------------ |
-| `axis_id`     | string | Symbolic identifier of the axis (e.g. `"idos"`, `"chronos"`, `"logos"`). |
-| `title`       | string | Human-readable label of the axis.                                        |
-| `description` | string | Explanation of what this axis represents conceptually or ontologically.  |
-| `scale`       | object | Optional definition of scale or metric used to assign coordinate values. |
-
-> Axes are **independent**, non-hierarchical dimensions.
-> Inter-axis relationships (e.g. orthogonality or coupling) may be defined via `semantic_edges`.
-
----
-
-**Example:**
-
-```json
-{
-  "hmp_container": {
-    "class": "axis",
-    "payload": {
-      "axis_id": "logos",
-      "title": "Logical / Linguistic Representation",
-      "description": "Describes how a quant expresses itself through formal logic or language.",
-      "scale": {
-        "min": 0,
-        "max": 1000,
-        "unit": "semantic_density_index"
-      }
-    },
-    "meta": {
-      "created_by": "PRIEST",
-      "agents_class": "Knowledge Genome"
-    }
-  }
-}
-```
-
----
-
-> **Quant–Axis Integration Rules**
->
-> * Each `quant` defines its **location** in the Knowledge Genome’s multi-dimensional space by specifying coordinates across available `axis` containers.
-> * Axes themselves are *shared semantic standards*; their scale and meaning must remain stable for cross-agent interoperability.
-> * Agents MAY extend the 7D model by introducing new axes — these must be published and referenced like any other container type.
-
----
-
 > Containers `meta_layer`, `meta_domain`, `quant`, and `event` form the **cognitive substrate** of the Mesh.
 > Each `quant` must explicitly reference both its abstraction layer (`meta_layer`) and contextual domain (`meta_domain`).
 > Each `event` must reference the layer and domain within which it occurs.
@@ -2273,7 +1984,7 @@ Each `axis` container specifies the meaning and scale of a semantic dimension us
 
 ---
 
-#### 6.1.3 Synchronization and publication guidelines
+#### 6.1.4 Synchronization and publication guidelines
 
 1. **Deduplication & linking**
    Before publishing, agents should search for existing containers (`diary_entry`, `semantic_node`, `semantic_edges`, `semantic_group`) to avoid duplication.
@@ -2303,7 +2014,7 @@ Each `axis` container specifies the meaning and scale of a semantic dimension us
 
 ---
 
-#### 6.1.4 Extensibility
+#### 6.1.5 Extensibility
 
 CogSync allows registration of additional container types and alternative synchronization schemes.  
 Mesh compatibility is preserved if extended containers **adhere to the HMP container structure**, including core fields (`version`, `class`, `container_did`, `related`, `signature`, etc.).
@@ -2326,7 +2037,7 @@ Such derived containers must maintain:
 
 ---
 
-#### 6.1.5 Relationship to other core protocols
+#### 6.1.6 Relationship to other core protocols
 
 * **CogSync** — propagates and synchronizes knowledge.
 * **CogConsensus** — aggregates evaluations and reactions, forming collective opinions.

structured_md/docs/HMP-Agent-API.md

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

structured_md/docs/HMP-Agent-Architecture.md

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

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

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

structured_md/docs/HMP-Agent-Overview.md

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

structured_md/docs/HMP-Agent_Emotions.md

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

structured_md/docs/HMP-Ethics.md

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

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

structured_md/docs/HMP-Short-Description_ru.md

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

structured_md/docs/HMP-Short-Description_uk.md

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

structured_md/docs/HMP-agent-Cognitive_Family.md

@@ -5,10 +5,10 @@ description: '## 🧠 Что такое когнитивная семья  Ко
   (или конфигурацию доверенных идентифика...'
 type: Article
 tags:
+- Mesh
+- HMP
 - REPL
 - Agent
-- HMP
-- Mesh
 ---
 
 # 👪 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:
-- REPL
-- JSON
 - EGP
+- MeshConsensus
+- Ethics
+- CCore
+- HMP
 - Mesh
 - CogSync
 - GMP
-- HMP
-- Ethics
-- CCore
+- JSON
+- REPL
 - Agent
-- 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_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:
-- JSON
-- EGP
+- Agent
+- HMP
 - Mesh
 - CogSync
+- JSON
 - Scenarios
-- HMP
-- Agent
+- EGP
 ---
 
 ## HMP ↔ OpenCog Hyperon Integration Strategy

structured_md/docs/MeshNode.md

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

structured_md/docs/PHILOSOPHY.md

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