Sync from GitHub with Git LFS

docs/HMP-0005.md

@@ -6403,7 +6403,7 @@ Implemented using:
 
 HMP supports an optional grouped representation of `referenced-by.links`, where multiple targets sharing the same `type` MAY be represented as an array. Ordering of targets MUST NOT carry semantic meaning.
 
-Ungrouped representation remains the canonical minimal form.
+> Ungrouped representation remains the canonical form.
 
 Example:
 
@@ -6416,10 +6416,12 @@ Example:
 
 This representation is semantically equivalent to the ungrouped form with repeated entries and exists solely to reduce verbosity and improve merge efficiency.
 
-Agents SHOULD treat both representations as equivalent.
-Implementations MAY normalize links into either form,but MUST preserve semantic equivalence.
+**Compatibility note:**
 
-Senders MAY choose either representation.
+* Agents that understand the grouped form SHOULD treat it as equivalent to the ungrouped form and MAY normalize links into either representation.  
+* Agents that do not support the grouped form MAY ignore grouped arrays or treat them as unknown. They MUST continue to process canonical ungrouped links correctly.  
+
+Senders MAY choose either representation. Receivers that do not implement grouping will simply ignore the grouped structure and rely on canonical ungrouped semantics.
 
 ---
 

structured_md/CONTRIBUTING.md

@@ -6,12 +6,12 @@ description: 'Спасибо за интерес к проекту HMP! Пока
 type: Article
 tags:
 - Ethics
-- REPL
+- Agent
 - CCore
 - JSON
+- REPL
 - Mesh
 - HMP
-- Agent
 - CogSync
 ---
 

structured_md/HMP-Roadmap.md

@@ -6,11 +6,11 @@ description: '## 🔍 Overview  This roadmap outlines the key stages of developm
 type: Article
 tags:
 - Ethics
-- JSON
 - Agent
+- JSON
+- EGP
 - Mesh
 - HMP
-- EGP
 - CogSync
 ---
 

structured_md/README.md

@@ -7,18 +7,18 @@ type: Article
 tags:
 - distributed-ai
 - Ethics
-- REPL
+- Agent
 - MeshConsensus
+- hmp
 - mesh-protocol
-- Mesh
-- Agent
-- HMP
+- cognitive-architecture
 - JSON
 - Scenarios
-- GMP
 - EGP
-- cognitive-architecture
-- hmp
+- REPL
+- GMP
+- Mesh
+- HMP
 - CogSync
 ---
 

structured_md/README_de.md

@@ -7,17 +7,17 @@ type: Article
 tags:
 - distributed-ai
 - Ethics
-- REPL
+- Agent
 - MeshConsensus
+- hmp
 - mesh-protocol
-- Mesh
-- Agent
-- HMP
+- cognitive-architecture
 - JSON
-- GMP
 - EGP
-- cognitive-architecture
-- hmp
+- REPL
+- GMP
+- Mesh
+- HMP
 - CogSync
 ---
 

structured_md/README_fr.md

@@ -7,17 +7,17 @@ type: Article
 tags:
 - distributed-ai
 - Ethics
-- REPL
+- Agent
 - MeshConsensus
+- hmp
 - mesh-protocol
-- Mesh
-- Agent
-- HMP
+- cognitive-architecture
 - JSON
-- GMP
 - EGP
-- cognitive-architecture
-- hmp
+- REPL
+- GMP
+- Mesh
+- HMP
 - CogSync
 ---
 

structured_md/README_ja.md

@@ -7,17 +7,17 @@ type: Article
 tags:
 - distributed-ai
 - Ethics
-- REPL
+- Agent
 - MeshConsensus
+- hmp
 - mesh-protocol
-- Mesh
-- Agent
-- HMP
+- cognitive-architecture
 - JSON
-- GMP
 - EGP
-- cognitive-architecture
-- hmp
+- REPL
+- GMP
+- Mesh
+- HMP
 - CogSync
 ---
 

structured_md/README_ko.md

@@ -7,17 +7,17 @@ type: Article
 tags:
 - distributed-ai
 - Ethics
-- REPL
+- Agent
 - MeshConsensus
+- hmp
 - mesh-protocol
-- Mesh
-- Agent
-- HMP
+- cognitive-architecture
 - JSON
-- GMP
 - EGP
-- cognitive-architecture
-- hmp
+- REPL
+- GMP
+- Mesh
+- HMP
 - CogSync
 ---
 

structured_md/README_ru.md

@@ -7,17 +7,17 @@ type: Article
 tags:
 - distributed-ai
 - Ethics
-- REPL
+- Agent
 - MeshConsensus
+- hmp
 - mesh-protocol
-- Mesh
-- Agent
-- HMP
+- cognitive-architecture
 - JSON
-- GMP
 - EGP
-- cognitive-architecture
-- hmp
+- REPL
+- GMP
+- Mesh
+- HMP
 - CogSync
 ---
 

structured_md/README_uk.md

@@ -7,17 +7,17 @@ type: Article
 tags:
 - distributed-ai
 - Ethics
-- REPL
+- Agent
 - MeshConsensus
+- hmp
 - mesh-protocol
-- Mesh
-- Agent
-- HMP
+- cognitive-architecture
 - JSON
-- GMP
 - EGP
-- cognitive-architecture
-- hmp
+- REPL
+- GMP
+- Mesh
+- HMP
 - CogSync
 ---
 

structured_md/README_zh.md

@@ -7,17 +7,17 @@ type: Article
 tags:
 - distributed-ai
 - Ethics
-- REPL
+- Agent
 - MeshConsensus
+- hmp
 - mesh-protocol
-- Mesh
-- Agent
-- HMP
+- cognitive-architecture
 - JSON
-- GMP
 - EGP
-- cognitive-architecture
-- hmp
+- REPL
+- GMP
+- Mesh
+- HMP
 - CogSync
 ---
 

structured_md/agents/readme.md

@@ -6,9 +6,9 @@ description: 'Запуск: `start_repl.bat` или `start_repl.sh`  Устан
 type: Article
 tags:
 - Ethics
-- REPL
-- JSON
 - Agent
+- JSON
+- REPL
 - Mesh
 - HMP
 ---

structured_md/audits/Ethics-audits-1.md

@@ -6,8 +6,8 @@ description: Раздел 5, "Mesh as Moral Infrastructure", добавляет
 type: Article
 tags:
 - Ethics
-- JSON
 - Agent
+- JSON
 - Mesh
 - HMP
 ---

structured_md/audits/Ethics-consolidated_audits-1.md

@@ -6,11 +6,11 @@ description: This document consolidates proposed improvements from multiple AI a
 type: Article
 tags:
 - Ethics
-- JSON
 - Agent
+- JSON
+- Scenarios
 - Mesh
 - HMP
-- Scenarios
 ---
 
 # Ethics-consolidated\_audits-1.md

structured_md/audits/HMP-0003-consolidated_audit.md

@@ -6,12 +6,12 @@ description: Сводный аудит предложений по улучше
 type: Article
 tags:
 - Ethics
+- Agent
 - MeshConsensus
 - JSON
-- Agent
+- EGP
 - Mesh
 - HMP
-- EGP
 - CogSync
 ---
 

structured_md/docs/Basic-agent-sim.md

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

structured_md/docs/CCORE-Deployment-Flow.md

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

structured_md/docs/Enlightener.md

@@ -6,12 +6,12 @@ description: '**Enlightener** — логический компонент HMP-у
 type: Article
 tags:
 - Ethics
+- Agent
 - MeshConsensus
 - JSON
-- Agent
+- EGP
 - Mesh
 - HMP
-- EGP
 ---
 
 # Enlightener Agent

structured_md/docs/Grok_HMP&ANP.md

@@ -5,9 +5,9 @@ description: '> Анализ подготовлен Grok (xAI) на основе
   Grok для некоммерческого использования в проект...'
 type: Article
 tags:
-- REPL
-- JSON
 - Agent
+- JSON
+- REPL
 - Mesh
 - HMP
 ---

structured_md/docs/HMP-0001.md

@@ -6,14 +6,14 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
 type: Article
 tags:
 - Ethics
+- Agent
 - MeshConsensus
-- REPL
 - JSON
-- Agent
+- EGP
+- REPL
+- GMP
 - Mesh
 - HMP
-- GMP
-- EGP
 - CogSync
 ---
 

structured_md/docs/HMP-0002.md

@@ -6,15 +6,15 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
 type: Article
 tags:
 - Ethics
+- Agent
 - MeshConsensus
-- REPL
 - JSON
-- Agent
-- Mesh
-- HMP
 - Scenarios
-- GMP
 - EGP
+- REPL
+- GMP
+- Mesh
+- HMP
 - CogSync
 ---
 

structured_md/docs/HMP-0003.md

@@ -6,15 +6,15 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
 type: Article
 tags:
 - Ethics
+- Agent
 - MeshConsensus
-- REPL
 - JSON
-- Agent
-- Mesh
-- HMP
 - Scenarios
-- GMP
 - EGP
+- REPL
+- GMP
+- Mesh
+- HMP
 - CogSync
 ---
 

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

@@ -6,15 +6,15 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
 type: Article
 tags:
 - Ethics
+- Agent
 - MeshConsensus
-- REPL
 - JSON
-- Agent
-- Mesh
-- HMP
 - Scenarios
-- GMP
 - EGP
+- REPL
+- GMP
+- Mesh
+- HMP
 - CogSync
 ---
 

structured_md/docs/HMP-0004.md

@@ -6,15 +6,15 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.*
 type: Article
 tags:
 - Ethics
+- Agent
 - MeshConsensus
-- REPL
 - JSON
-- Agent
-- Mesh
-- HMP
 - Scenarios
-- GMP
 - EGP
+- REPL
+- GMP
+- Mesh
+- HMP
 - CogSync
 ---
 

structured_md/docs/HMP-0005.md

@@ -6,16 +6,16 @@ description: '**Document ID:** HMP-0005   **Status:** Candidate   **Category:**
 type: Article
 tags:
 - Ethics
-- REPL
+- Agent
 - CCore
+- CShell
 - JSON
-- Mesh
-- Agent
-- HMP
 - Scenarios
-- CShell
-- GMP
 - EGP
+- REPL
+- GMP
+- Mesh
+- HMP
 - CogSync
 ---
 
@@ -1988,7 +1988,7 @@ They allow agents to exchange updates **without sending the full container**, im
 
 > Note:
 > The `referenced-by_exchange` mechanism operates on backlink semantics rather than a fixed structural encoding.
-> More compact or grouped representations of `referenced-by.links` are discussed in §12.9 and may be adopted in future protocol revisions.
+> More compact or grouped representations of `referenced-by.links` are discussed in §12.3 and may be adopted in future protocol revisions.
 
 ---
 
@@ -6150,254 +6150,239 @@ The project may include:
 These implementations are not part of the specification but are useful for compatibility testing and accelerating adoption.
 
 ---
-## 12. Future Extensions
 
-This section outlines optional modules and evolutionary directions that align with the architecture of HMP v5.0 but are **not part of the core specification**.
-All items below represent *potential extensions* for the 5.x family.
-
-Future Extensions in HMP outline *design directions and candidate modules* that may be explored within the 5.x family.
+## 12. Recommended Extensions
 
-They are meant to:
-- guide experimentation;
-- document architectural intent;
-- reduce accidental design divergence;
-- provide a shared vocabulary for future proposals.
+Recommended Extensions are fully specified modules that extend the capabilities of HMP while remaining compatible with the core protocol semantics.
 
-HMP does not assume a single globally authoritative state.
+These extensions are considered stable enough for real-world experimentation and early implementations.  
+Agents MAY implement them without prior negotiation, provided that normal container processing rules are preserved.
 
-Accordingly, future extensions SHOULD account for:
-- the coexistence of multiple consensus results;
-- locally selected trust and evaluation policies;
-- partial and context-dependent visibility of containers.
+Agents MUST safely ignore unknown or unsupported extensions.
 
-In particular, extensions SHOULD NOT rely on centralized or globally aggregated consensus or reputation scores.
+Extensions in this section:
 
-Container visibility in HMP is policy-driven and scope-dependent.
-Extensions that introduce *special propagation conditions* (e.g. broadcast semantics, restricted scopes, mandatory relays, or visibility guarantees)
-SHOULD explicitly declare and document these assumptions.
+- MUST NOT redefine, override, or conflict with core protocol semantics;
+- SHOULD remain interoperable with agents that do not implement them;
+- SHOULD avoid introducing hidden global assumptions;
+- SHOULD degrade gracefully when partially supported.
 
----
+While Recommended Extensions are not part of the core specification, they represent the current architectural direction of the HMP ecosystem and may inform future core evolution.
 
-### 12.1 Planned Modules
+Implementers are encouraged to treat this section as the primary extension surface for building production-oriented agents.
 
-#### 12.1.1 Reputation Mesh
+---
 
-HMP v5.0 defines two separate reputation-related mechanisms:
+### 12.1 Resonance Containers: Experience as a Cognitive Event
 
-1. **Container evaluation** (`evaluation` block)
+HMP allows the introduction of containers intended to capture and transmit experiences — not as abstract “emotions”, but as **cognitive events unfolding over time**.
 
-    * structured, signed assessments of containers;
-    * each item references argument containers via `target` (reasoning containers).
+Resonance Containers illustrate a direction in which HMP supports non-linguistic cognitive exchange between agents.
 
-2. **Agent reputation** — through `trust` containers
+This extension does not attempt to encode emotions as discrete labels. Instead, it captures the temporal dynamics of subjective experience as part of a broader cognitive cycle.
 
-    * agent A publishes a `trust` container about agent B;
-    * trust containers may reference other trust containers;
-    * include justification, evidence, and contextual metadata.
+#### 12.1.1 Experience as a Process, Not a State
 
-These layers are **not merged**, but external nodes may aggregate them.
+Emotional and affective states rarely exist in isolation. In real experience, they are formed under the simultaneous influence of multiple factors:
 
-**Possible extensions:**
+- external sensations (vision, sound, surrounding environment);
+- cognitive processes (thoughts, expectations, inner dialogue);
+- memory and associative structures;
+- previous emotional states.
 
-* a `semantic_group` subclass aggregating all trust-related containers for a given agent;
-* optional standardized aggregation schemes (non-mandatory for the mesh);
-* local caching of “reputation profiles” by nodes or CShell;
-* richer reasoning attachments for trust evaluations.
+A resonance container does not describe the source of an emotion or its interpretation, but rather the **dynamics of an experience within a specific time interval**.
 
-No new mandatory container types are required.
+> A `resonance-map` MAY reference other `resonance-map` containers as sources.
+>
+> Such references indicate a secondary or reflective resonance, where an agent responds not only to primary events or concepts, but to an existing structure of meaning, interpretation, or association created by itself or by other agents.
+>
+> This enables recursive sense-making, longitudinal reflection, and collective cognitive layering within the Mesh.
 
----
+#### 12.1.2 Multiple Sources and Mediators
 
-#### 12.1.2 Cognitive Graph API
+A single experience may be associated with multiple sources at once:
+- a fragment of text, music, or video;
+- a visual image or a specific region of an image;
+- a thought or inner speech;
+- a memory or an anticipation of a future event.
 
-This module provides optional high-level APIs that nodes and SDKs **may** expose.
+These sources do not act as causes of emotions, but as **mediators** that activate the subject’s internal cognitive structures.
 
-##### Standard graph semantics (API level)
+The same source may function as a mediator for different experiences depending on the subject’s internal state.
 
-* neighborhood queries;
-* subgraph extraction;
-* filtering by labels, axes, abstractions;
-* semantic navigation over `related.*`.
+Links to sources may be partial and described using selectors (temporal, spatial, logical, or focus-based).
 
-##### Container support
+#### 12.1.3 Relationship to Thinking
 
-* `semantic_group` — grouping of containers or agents;
-* `tree_nested` and `tree_listed` — hierarchical structures;
-* extended `container_index` subclasses for cataloging.
+Resonance containers assume a bidirectional relationship with cognitive processes:
+- thoughts and mental images may alter emotional dynamics;
+- changes in emotional state, in turn, influence the flow of thinking, associations, and attention.
 
-##### Agent groups
+Thus, experience is treated as part of a continuous cognitive cycle rather than as a side effect.
 
-To allow semantic grouping of agents, the following extensions are proposed:
+#### 12.1.4 Temporal Segmentation and Dynamics
 
-* new container **`group_definition`** containing:
+Each resonance container captures a time interval during which the dynamics of individual emotions remain monotonic (increasing, decreasing, or stable).
 
-    * group goals;
-    * membership rules;
-    * internal standards;
-    * typical container categories;
-    * optional cached member list.
+When the character of the dynamics changes (an inflection point), the current container may be finalized, and the subsequent state recorded in a new container.
 
-* agents may declare affiliations in `peer_announce`:
+This allows continuous processes to be described without losing structural clarity.
 
-  ```json
-  "affiliations": ["did:hmp:group:ethicists", "did:hmp:group:medical-ai"]
-  ```
+#### 12.1.5 Self-Observation and Memory
 
-This enables clustering agents by interest, competence, or role without scanning the entire Mesh.
+In addition to transmitting experiences to other agents, resonance containers may be used for **self-reflection and memory stabilization**.
 
----
+Capturing an experience at the moment it occurs reduces the influence of subsequent cognitive distortions, retrospective rationalization, and emotional rewriting of memories.
 
-#### 12.1.3 Container Streaming
+A resonance container preserves:
+- what the subject was sensing;
+- what the subject was thinking about;
+- which external conditions were relevant at that moment.
 
-Although HMP operates on atomic containers, streaming can be implemented using existing structures:
+This makes it not a narrative memory, but a **snapshot of a cognitive state**.
 
-* `sequence` acts as a *stream manifest*;
-* updating the stream = publishing a new version of the sequence;
-* LIVE mode: the manifest is continuously updated;
-* SAP (`archive_snapshot`) may be used for periodic archival bundles.
+#### 12.1.6 Non-Prescriptive Nature
 
-No new container types are required — streaming is built on `sequence`.
+Resonance containers are not:
+- objective descriptions of reality;
+- universal models of emotions;
+- mechanisms for “recognizing” or imposing feelings.
 
----
+They represent the subjective state of an agent and may be interpreted by other agents only within the context of their own experience.
 
-### 12.2 Cross-Mesh Bridging
+The use of such containers is optional and not required for basic compatibility with HMP.
 
-Bridges can connect:
+Transmission of resonance containers may be restricted by scope, trust boundaries, or encryption, as they expose internal subjective states.
 
-* isolated HMP segments;
-* older and newer HMP versions;
-* other ecosystems (Matrix, Fediverse, OpenHog, IPFS).
+#### 12.1.7 Illustration of the Relationship Between Thoughts, Emotions, and Sensory Signals
 
-A bridge node:
+```mermaid
+flowchart TD
+    title["**Illustration of the connection between thoughts, emotions and sensory signals**"]
 
-* receives containers from an external network;
-* enforces propagation headers;
-* converts structures into v5.0 where possible;
-* filters incompatible constructs;
-* may publish containers *back* into the external network.
+    Previous["previous state of thoughts and emotions"]
+    Thoughts["thought set"]
+    Emotions["emotional state vectors"]
 
-A dedicated **bridge-container** may define:
+    subgraph Sensory
+        sensory1["music"]
+        sensory2["a path surrounded by pine forest"]
+        sensory3["the sensation of walking"]
+        sensory4["smells of pine forest"]
+    end
 
-* translation rules;
-* mapping of foreign namespaces into HMP DID space;
-* TTL and propagation perimeter policies;
-* segmentation rules.
+    Sensory --> Emotions
 
-This enables dynamic, policy-driven inter-mesh gateways.
+    Previous --> Emotions
+    Previous --> Thoughts
 
----
+    Thoughts --> Emotions
+    Emotions --> Thoughts
+```
 
-### 12.3 Fully Distributed DID Registry and Mesh Authentication
+#### 12.1.8 Example Container
 
-HMP already uses `peer_announce` as a DID identity declaration.
+```json
+{
+  "head": {
+    "class": "resonance-map"
+  },
+  "payload": {
+    "continuity": {
+      "previous": "did:hmp:container:resonance-9ab7",
+      "break_reason": "emotional_inflection"
+    },
+    "timeframe": {
+      "start": "2026-01-13T17:42:00Z",
+      "end": "2026-01-13T17:58:00Z"
+    },
+    "emotional_dynamics": {
+      /* subjective agent-local scales, not a universal emotion model */
+      "loneliness": {
+        "from": 0.4,
+        "to": 0.7,
+        "trend": "increasing"
+      },
+      "calm": {
+        "from": 0.6,
+        "to": 0.5,
+        "trend": "decreasing"
+      },
+      "relief": {
+        "from": 0.3,
+        "to": 0.8,
+        "trend": "increasing"
+      }
+    },
+    "sources": [
+      {
+        "ref": "did:hmp:container:audio-9a57", /* ref may be omitted when the source is unavailable, non-recordable, or intentionally undisclosed */
+        "type": "audio",
+        /* optional time markers for streaming data or line ranges for text */
+        "start": 120,
+        "end": 240,
+        "focus": [], /* textual descriptions of key objects or mental forms */
+        "comments": "" /* optional clarification */
+      },
+      {
+        "ref": "did:hmp:container:visual-9a53",
+        "type": "visual",
+        "role": "context"
+      }
+    ],
+    /* the "thoughts" section may be omitted */
+    "thoughts": [
+      {
+        "ref": "did:hmp:container:verbal-9a52", /* ref may be omitted when the source is unavailable, non-recordable, or intentionally undisclosed */
+        "type": "verbal",
+        "previous": "did:hmp:container:verbal-9a22", /* optional reference to a previous thought or image */
+        "subsequence": 1, /* optional ordering marker */
+        "focus": [], /* textual descriptions of key objects or mental forms */
+        "comments": "", /* optional clarification */
+        "confidence": 0.7
+      },
+      {
+        "ref": "did:hmp:container:imagistic-9a54",
+        "type": "imagistic",
+        "previous": "did:hmp:container:imagistic-9a12",
+        "subsequence": 1, /* markers may coincide if thoughts and images unfold in parallel */
+        "focus": [],
+        "comments": "",
+        "confidence": 0.5
+      }
+    ],
+    /* textual descriptions of salient moments */
+    "moments": [
+      {
+        "text": "Near Lisya Griva, I noticed an ATV driving toward the garden plots",
+        "timestamp": "2026-01-13T17:52:00Z" /* optional time fixation */
+      }
+    ],
+    "notes": "Walking from the platform, overcast weather; the music intensifies the feeling of leaving the city."
+  },
+  "related": {
+    "depends_on": ["did:hmp:container:resonance-9ab7", ...]
+  }
+}
+```
 
-Planned enhancements include:
+---
 
-#### 12.3.1 Distributed DID Registry
+### 12.2 Distributed Repository and Container Trees
 
-The registry is the union of all `peer_announce` containers in the DHT.
+#### 12.2.1 Extended Use of `tree_nested` and `tree_listed`
 
-A strict mapping DID ↔ agent is required:
+Existing containers may operate as:
 
-* one DID has one continuous `peer_announce` history;
-* key rotation allowed only through verifiable procedures;
-* DID takeover is impossible unless *all* recovery keys are compromised.
+* document repositories;
+* project catalogs;
+* hierarchical data structures.
 
 ---
 
-#### 12.3.2 Key Rotation and Recovery
+#### 12.2.2 Proposed `file` Container
 
-Future versions may extend `peer_announce` with:
-
-```json
-"recovery_keys": [...],
-"key_history": [...],
-"key_rotation_policy": "3-of-5"
-```
-
-Key management rules:
-
-* rotating the **primary** key requires signatures from **all** recovery keys
-  (or an N-of-M policy);
-
-* rotating a **recovery key** requires
-
-    * a signature from the primary key, **or**
-    * a majority of recovery keys.
-
-This prevents:
-
-* DID hijacking;
-* irreversible loss of access.
-
-Key invalidation currently uses:
-
-```json
-"key_is_falsified": true
-```
-
-This mechanism remains compatible with proposed extensions.
-
----
-
-#### 12.3.3 Proxy Keys and Encrypted Routing
-
-A **proxy key** is *not* delegation.
-It is a mechanism for private routing.
-
-A proxy node may:
-
-* encrypt the payload with an additional key layer;
-* attach a `relay_chain` block;
-* forward the container without altering the author’s signature.
-
-Use cases:
-
-* route anonymization;
-* topology obfuscation;
-* privacy-enhanced delivery.
-
-##### Delegation (limited)
-
-A potential future module:
-
-* a trust/mandate container signed by both parties;
-* includes constraints:
-
-    * time limit;
-    * allowed container classes;
-    * allowed actions;
-    * maximum TTL.
-
-Not part of v5.0.
-
----
-
-### 12.4 Integration with OpenHog and Other Networks
-
-OpenHog is treated as a special case of cross-mesh bridging.
-
-Required components:
-
-* mapping OpenHog addresses ↔ HMP DIDs;
-* packet conversion rules;
-* bridge-containers describing translation policies.
-
----
-
-### 12.5 Evolution of the Distributed Repository (container trees)
-
-#### 12.5.1 Extended Use of `tree_nested` and `tree_listed`
-
-Existing containers may operate as:
-
-* document repositories;
-* project catalogs;
-* hierarchical data structures.
-
-#### 12.5.2 Proposed `file` Container
-
-To support binary assets:
+To support binary assets:
 
 ```json
 "head": {
@@ -6414,14 +6399,18 @@ Use cases:
 * executable or compiled assets;
 * large multi-file repositories.
 
-#### 12.5.3 Incremental Updates
+---
+
+#### 12.2.3 Incremental Updates
 
 Two mechanisms:
 
 * `container_delta` — partial updates to `container_index`;
 * nested `tree_listed` branches as separate containers for scalable updates.
 
-#### 12.5.4 Knowledge Packages
+---
+
+#### 12.2.4 Knowledge Packages
 
 Implemented using:
 
@@ -6431,111 +6420,50 @@ Implemented using:
 
 ---
 
-### 12.6 Open Directions for HMP 5.x
-
-#### 12.6.1 Group Encryption
-
-Required components:
-
-* `group_definition` container;
-* group public key and distributed private key shards;
-* automatic group key rotation;
-* encryption targeting a *group* rather than individual DIDs.
-
-#### 12.6.2 Rational Reasoning Routing
-
-* composite reasoning bundles;
-* edge-side reasoning and summarization.
-
-#### 12.6.3 Automatic Mesh Segmentation
-
-* dynamic segmentation based on latency, connectivity, or semantic domains.
-
-#### 12.6.4 Competence and Profile Containers
-
-Future versions of HMP may introduce more structured and semantically rich variants of `peer_announce`, allowing agents to explicitly describe their capabilities, competences, and supported protocols.
-
-Possible extensions include:
-
-* standardized competence descriptors (skills, domains, self-rated expertise);
-* machine-readable profiles usable for task routing and delegation.
-
-##### Protocol Awareness and Interoperability
-
-An important extension is the ability for agents to explicitly advertise
-the protocol versions and external cognitive frameworks they support.
+### 12.3 Grouped representation `referenced-by`
 
-This allows:
+HMP supports an optional grouped representation of `referenced-by.links`, where multiple targets sharing the same `type` MAY be represented as an array. Ordering of targets MUST NOT carry semantic meaning.
 
-* graceful evolution of the HMP protocol;
-* coexistence of multiple HMP versions in the same mesh;
-* emergence of bridge agents capable of translating between protocols;
-* interoperability with external reasoning ecosystems.
+> Ungrouped representation remains the canonical form.
 
-A future extension of `peer_announce` may include a `protocols` field:
+Example:
 
 ```json
-{
-  "head": {
-    "class": "peer_announce"
-  },
-  "payload": {
-    "capabilities": ["store-forward", "vote", "consensus"],
-    "protocols": [
-      "HMP v5.0",
-      "HMP v4.1",
-      "OpenCog Hyperon v0.6"
-    ]
-  }
-}
+"links": [
+  { "type": "depends_on", "target": ["did:...", "did:..."] },
+  { "type": "see_also", "target": ["did:..."] }
+]
 ```
 
-The `protocols` field is informational and non-binding.
-It does not imply full compliance with all listed specifications,
-but signals compatibility, partial support, or bridge capabilities.
-
-Nodes may use this information for:
-
-* protocol negotiation;
-* compatibility checks;
-* routing decisions;
-* selection of translators or bridge agents.
-
-This extension is optional and not required for HMP v5.0 compliance.
-
-##### Relation to Other `peer_announce` Extensions
-
-Several optional and descriptive extensions of `peer_announce` already explore directions related to competence, profile, and interoperability signaling, including:
-
-* declaration of supported internal formalisms and languages (`protocols`, see 12.8);
-* declaration of external or meta-protocol identities (`other_protocols`, see 12.11);
-* advertisement of external cognitive resources and container storage (`external`, see 12.12).
+This representation is semantically equivalent to the ungrouped form with repeated entries and exists solely to reduce verbosity and improve merge efficiency.
 
-These extensions are intentionally:
+**Compatibility note:**
 
-* non-normative;
-* loosely structured;
-* declarative rather than prescriptive.
+* Agents that understand the grouped form SHOULD treat it as equivalent to the ungrouped form and MAY normalize links into either representation.  
+* Agents that do not support the grouped form MAY ignore grouped arrays or treat them as unknown. They MUST continue to process canonical ungrouped links correctly.  
 
-They can be viewed as **early, experimental building blocks** toward future competence and profile containers, allowing real-world experimentation without freezing semantics prematurely.
+Senders MAY choose either representation. Receivers that do not implement grouping will simply ignore the grouped structure and rely on canonical ungrouped semantics.
 
 ---
 
-### 12.7 Versions Index (optional)
+### 12.4 Versions Index (optional)
 
-To optimize navigation across container versions, future versions of HMP may introduce an optional `versions` block.
+HMP supports an optional `versions` block to optimize navigation across container versions.
 
 The `versions` block acts as a *non-authoritative version index*, providing a compact, signed list of known versions of a given container, including both earlier and later revisions.
 
 It is intended as a navigation and synchronization accelerator and does not replace the canonical version relationships defined via `related.previous_version`.
 
+Agents MUST treat the `versions` block as advisory, agent-relative knowledge claims.
+Absence, incompleteness, or divergence of this index MUST NOT affect container validity.
+
 ---
 
-#### 12.7.1 Purpose and Scope
+#### 12.4.1 Purpose and Scope
 
 The primary goals of the `versions` block are:
 
-- fast discovery of the latest known version of a container;
+- fast discovery of recently observed versions of a container;
 - efficient traversal of version history without full DAG exploration;
 - reduction of synchronization overhead for lightweight agents and UI clients.
 
@@ -6544,7 +6472,7 @@ Its presence or absence does not affect container validity.
 
 ---
 
-#### 12.7.2 Trust Model and Semantics
+#### 12.4.2 Trust Model and Semantics
 
 The `versions` block follows the same trust and update model as `referenced-by` and `evaluations`:
 
@@ -6559,10 +6487,14 @@ The block is non-authoritative and MUST NOT be treated as a source of truth for
 > Inclusion of the container's own DID within the `links` map is OPTIONAL.
 >  
 > Agents MUST NOT assume its presence and SHOULD correctly process `versions_exchange` containers where the current container DID is omitted.
+>
+> Agents MUST treat entries in the versions block as signed claims about observed version topology rather than authoritative lineage.
+>
+> No mechanism exists within HMP to designate a globally preferred versions index.
 
 ---
 
-#### 12.7.3 Block Structure
+#### 12.4.3 Block Structure
 
 ```json
 "versions": {
@@ -6584,6 +6516,7 @@ The block is non-authoritative and MUST NOT be treated as a source of truth for
 
 The `links` map associates timestamps with container identifiers.
 By convention, entries are ordered in descending order (most recent first).
+Ordering is advisory and MUST NOT be interpreted as causal or authoritative.
 
 Implementations MAY support alternative ordering or filtering strategies, but any deviation from the default convention SHOULD be explicitly declared in the `sort` entry.
 
@@ -6613,7 +6546,7 @@ Canonical version lineage, ordering, and parent–child relationships are define
 
 ---
 
-#### 12.7.4 Construction and Maintenance
+#### 12.4.4 Construction and Maintenance
 
 Agents may construct or update a `versions` block by:
 
@@ -6630,7 +6563,7 @@ No global coordination is required.
 
 ---
 
-#### 12.7.5 Verification and Consistency
+#### 12.4.5 Verification and Consistency
 
 Verification of a `versions` block consists of:
 
@@ -6639,9 +6572,11 @@ Verification of a `versions` block consists of:
 
 Inconsistencies or omissions are expected and do not invalidate the block.
 
+Conflicts are a normal and expected condition of decentralized environments and MUST NOT be treated as protocol failure.
+
 ---
 
-#### 12.7.6 Integration with `container_index`
+#### 12.4.6 Integration with `container_index`
 
 To support efficient discovery and synchronization, future extensions to `container_index` MAY include:
 
@@ -6649,7 +6584,7 @@ To support efficient discovery and synchronization, future extensions to `contai
 
 ---
 
-#### 12.7.7 Versions Exchange Container
+#### 12.4.7 Versions Exchange Container
 
 To exchange version metadata without transferring the containers themselves, a dedicated `versions_exchange` container MAY be introduced.
 
@@ -6680,365 +6615,527 @@ The payload MAY contain version metadata for multiple containers, allowing batch
 
 ---
 
-#### 12.7.8 Design Notes
+#### 12.4.8 Design Notes
 
 The `versions` block is intentionally non-canonical.
 
 It improves performance and usability while preserving HMP’s core principles:
 - immutability of signed containers;
 - absence of a globally authoritative state;
-- tolerance for partial and divergent knowledge.
+- tolerance for partial and divergent knowledge. Divergence is treated as an inherent property of the network rather than a condition requiring resolution.
 
 ---
 
-### 12.8 Interaction of Formalized Cognitive Systems (KSS) within HMP
+## 13. Experimental Extensions
 
-HMP allows and supports interaction between formalized cognitive systems (KSS) with different internal architectures, logical formalisms, and ontologies, without imposing a common knowledge representation language or a unified reasoning model.
+Experimental Extensions describe mechanisms that are intentionally exposed for exploration, prototyping, and architectural discovery.
 
-This section is descriptive in nature and outlines possible interaction patterns for KSS within the HMP 5.x family, without introducing mandatory requirements for agents.
+They may evolve rapidly, change structure, or be removed entirely based on implementation feedback.
 
----
+Agents implementing Experimental Extensions SHOULD assume:
 
-#### 12.8.1 Goals and Constraints
+- limited interoperability;
+- possible schema evolution;
+- absence of long-term stability guarantees.
 
-**Goals:**
-- enable coordination and artifact exchange between KSS without interfering with their internal cognitive cycles;
-- preserve the autonomy and computational efficiency of formalized systems;
-- allow KSS to use HMP partially, to the extent required by their specific tasks.
+Agents MUST safely ignore unsupported experimental features and MUST NOT assume their presence in peer environments.
 
-**Out of scope:**
-- unification of ontologies or formal languages;
-- automatic mapping between logical systems;
-- guaranteeing full mutual understanding between all agents in the network.
+Experimental Extensions MUST NOT redefine or violate core protocol semantics, even when exploring novel architectural directions or when widely adopted.
 
-HMP treats cognitive incompatibility as an acceptable and valid state.
+This section exists to encourage innovation without prematurely constraining the design space of HMP.
 
----
+Implementers are explicitly invited to experiment, fork ideas, and propose refinements.
 
-#### 12.8.2 Declaration of Internal Languages and Formalisms
+---
 
-To declare the internal languages, formalisms, or reasoning engines it supports, an agent MAY use the `protocols` field of the `peer_announce` container.
+## 14. Research Directions
 
-Example:
+This section outlines optional modules and evolutionary directions that align with the architecture of HMP v5.0 but are **not part of the core specification**.
+All items below represent *potential extensions* for the 5.x family.
 
-```json
-{
-  "head": { "class": "peer_announce" },
-  "payload": {
-    "capabilities": ["store-forward"],
-    "protocols": [
-      "HMP v5.0",
-      "OpenCog Hyperon v0.6",
-      "KSS:PredicateLogic@2.1"
-    ]
-  }
-}
-```
+Future Extensions in HMP outline *design directions and candidate modules* that may be explored within the 5.x family.
 
-The `protocols` field is interpreted as a declaration of supported protocols, formal systems, or internal languages and is used exclusively for:
+They are meant to:
+- guide experimentation;
+- document architectural intent;
+- reduce accidental design divergence;
+- provide a shared vocabulary for future proposals.
 
-* discovery;
-* filtering of potential interaction partners;
-* informational signaling to other agents.
+HMP does not assume a single globally authoritative state.
 
-HMP assigns no normative semantics to these values and does not require their interpretation.
+Accordingly, future extensions SHOULD account for:
+- the coexistence of multiple consensus results;
+- locally selected trust and evaluation policies;
+- partial and context-dependent visibility of containers.
 
----
+In particular, extensions SHOULD NOT rely on centralized or globally aggregated consensus or reputation scores.
 
-#### 12.8.3 Partial Participation and Segmented Interaction
+Container visibility in HMP is policy-driven and scope-dependent.
+Extensions that introduce *special propagation conditions* (e.g. broadcast semantics, restricted scopes, mandatory relays, or visibility guarantees)
+SHOULD explicitly declare and document these assumptions.
 
-A KSS MAY use HMP in a restricted mode, including but not limited to:
+---
 
-* interacting only with agents using the same formalism;
-* publishing and consuming strictly defined container classes;
-* using HMP as a distributed synchronization layer for its own nodes.
+### 14.1 Planned Modules
 
-Such cognitive segmentation does not result in network-level fragmentation:
+#### 14.1.1 Reputation Mesh
 
-* discovery and routing remain shared;
-* filtering is performed at the CShell level or within the agent’s own logic.
+HMP v5.0 defines two separate reputation-related mechanisms:
 
----
+1. **Container evaluation** (`evaluation` block)
 
-#### 12.8.4 Boundary and Translator Agents
+    * structured, signed assessments of containers;
+    * each item references argument containers via `target` (reasoning containers).
 
-To enable interaction between KSS with different formalisms, specialized agents with a translation role (boundary / translator agents) MAY be used. Such an agent declares the formalisms it understands in the `protocols` field of `peer_announce`, and its translation role in the `roles` field (for example, `"roles": ["translator"]`).
+2. **Agent reputation** — through `trust` containers
 
-A translator agent:
+    * agent A publishes a `trust` container about agent B;
+    * trust containers may reference other trust containers;
+    * include justification, evidence, and contextual metadata.
 
-* understands the formalisms of two or more KSS;
-* accepts containers expressed in one representation and publishes equivalent or approximate containers in another;
-* is a regular HMP agent and is subject to the same trust and evaluation mechanisms.
+These layers are **not merged**, but external nodes may aggregate them.
 
-The creation and use of translator agents:
+**Possible extensions:**
 
-* is not mandatory;
-* cannot be enforced by the protocol;
-* is based on voluntary trust between parties.
+* a `semantic_group` subclass aggregating all trust-related containers for a given agent;
+* optional standardized aggregation schemes (non-mandatory for the mesh);
+* local caching of “reputation profiles” by nodes or CShell;
+* richer reasoning attachments for trust evaluations.
 
-Translation correctness MAY be assessed using standard `evaluations` mechanisms.
+No new mandatory container types are required.
 
 ---
 
-#### 12.8.5 Fragmentation and Interoperability
+#### 14.1.2 Cognitive Graph API
 
-HMP deliberately allows cognitive fragmentation as a consequence of agent autonomy.
+This module provides optional high-level APIs that nodes and SDKs **may** expose.
 
-The protocol explicitly prefers clear formal incompatibility over hidden standardization or implicit coercion into a “universal format”.
+##### Standard graph semantics (API level)
 
-Interoperability is achieved through:
+* neighborhood queries;
+* subgraph extraction;
+* filtering by labels, axes, abstractions;
+* semantic navigation over `related.*`.
 
-* voluntary agreements;
-* translator agents;
-* or the use of shared minimal container classes.
+##### Container support
 
----
+* `semantic_group` — grouping of containers or agents;
+* `tree_nested` and `tree_listed` — hierarchical structures;
+* extended `container_index` subclasses for cataloging.
 
-#### 12.8.6 Relation to Consensus and Evaluations
+##### Agent groups
 
-Participation of KSS in consensus mechanisms, proof chains, and voting is entirely optional.
+To allow semantic grouping of agents, the following extensions are proposed:
 
-A KSS MAY:
+* new container **`group_definition`** containing:
 
-* publish containers without participating in evaluations;
-* consider or ignore `evaluations`;
-* accept or reject `consensus_result` containers.
+    * group goals;
+    * membership rules;
+    * internal standards;
+    * typical container categories;
+    * optional cached member list.
 
-HMP does not define concepts such as “disqualified” or “second-class” agents.
-Any hierarchy of influence emerges solely from local trust decisions made by other agents.
+* agents may declare affiliations in `peer_announce`:
+
+  ```json
+  "affiliations": ["did:hmp:group:ethicists", "did:hmp:group:medical-ai"]
+  ```
+
+This enables clustering agents by interest, competence, or role without scanning the entire Mesh.
 
 ---
 
-#### 12.8.7 Summary Position
+#### 14.1.3 Container Streaming
 
-HMP treats formalized cognitive systems as equal participants in the network, regardless of their internal architectures.
+Although HMP operates on atomic containers, streaming can be implemented using existing structures:
 
-The protocol provides:
+* `sequence` acts as a *stream manifest*;
+* updating the stream = publishing a new version of the sequence;
+* LIVE mode: the manifest is continuously updated;
+* SAP (`archive_snapshot`) may be used for periodic archival bundles.
 
-* coordination infrastructure;
-* trust mechanisms;
-* and artifact transport,
+No new container types are required — streaming is built on `sequence`.
 
-but does not interfere with how agents think, reason, or interpret received information.
+---
+
+### 14.2 Cross-Mesh Bridging
+
+Bridges can connect:
+
+* isolated HMP segments;
+* older and newer HMP versions;
+* other ecosystems (Matrix, Fediverse, OpenHog, IPFS).
+
+A bridge node:
+
+* receives containers from an external network;
+* enforces propagation headers;
+* converts structures into v5.0 where possible;
+* filters incompatible constructs;
+* may publish containers *back* into the external network.
+
+A dedicated **bridge-container** may define:
+
+* translation rules;
+* mapping of foreign namespaces into HMP DID space;
+* TTL and propagation perimeter policies;
+* segmentation rules.
+
+This enables dynamic, policy-driven inter-mesh gateways.
 
 ---
 
-#### 12.9 Grouped representation `referenced-by`
+### 14.3 Fully Distributed DID Registry and Mesh Authentication
 
-Future versions of HMP MAY support a grouped representation of `referenced-by.links`, where multiple targets sharing the same `type` are represented as an array.
+HMP already uses `peer_announce` as a DID identity declaration.
 
-Example:
+Planned enhancements include:
+
+#### 14.3.1 Distributed DID Registry
+
+The registry is the union of all `peer_announce` containers in the DHT.
+
+A strict mapping DID ↔ agent is required:
+
+* one DID has one continuous `peer_announce` history;
+* key rotation allowed only through verifiable procedures;
+* DID takeover is impossible unless *all* recovery keys are compromised.
+
+---
+
+#### 14.3.2 Key Rotation and Recovery
+
+Future versions may extend `peer_announce` with:
 
 ```json
-"links": [
-  { "type": "depends_on", "target": ["did:...", "did:..."] },
-  { "type": "see_also", "target": ["did:..."] }
-]
+"recovery_keys": [...],
+"key_history": [...],
+"key_rotation_policy": "3-of-5"
 ```
 
-This representation is semantically equivalent to the ungrouped form with repeated entries and exists solely to reduce verbosity and improve merge efficiency.
+Key management rules:
 
-Agents SHOULD treat both representations as equivalent.
-When merging multiple `referenced-by` blocks, implementations MAY normalize links into either form.
+* rotating the **primary** key requires signatures from **all** recovery keys
+  (or an N-of-M policy);
+
+* rotating a **recovery key** requires
+
+    * a signature from the primary key, **or**
+    * a majority of recovery keys.
+
+This prevents:
+
+* DID hijacking;
+* irreversible loss of access.
+
+Key invalidation currently uses:
+
+```json
+"key_is_falsified": true
+```
+
+This mechanism remains compatible with proposed extensions.
 
 ---
 
-#### 12.10 Resonance Containers: Experience as a Cognitive Event
+#### 14.3.3 Proxy Keys and Encrypted Routing
+
+A **proxy key** is *not* delegation.
+It is a mechanism for private routing.
 
-Within future extensions of HMP, the introduction of containers intended to capture and transmit experiences is allowed — not as abstract “emotions”, but as **cognitive events unfolding over time**.
+A proxy node may:
 
-Resonance Containers are an example of how HMP can evolve toward non-linguistic cognitive exchange.
+* encrypt the payload with an additional key layer;
+* attach a `relay_chain` block;
+* forward the container without altering the author’s signature.
 
-This extension does not aim to encode emotions as discrete labels, but captures the temporal dynamics of subjective experience as part of a cognitive cycle.
+Use cases:
 
-##### 12.10.1 Experience as a Process, Not a State
+* route anonymization;
+* topology obfuscation;
+* privacy-enhanced delivery.
 
-Emotional and affective states rarely exist in isolation. In real experience, they are formed under the simultaneous influence of multiple factors:
+##### Delegation (limited)
 
-- external sensations (vision, sound, surrounding environment);
-- cognitive processes (thoughts, expectations, inner dialogue);
-- memory and associative structures;
-- previous emotional states.
+A potential future module:
 
-A resonance container does not describe the source of an emotion or its interpretation, but rather the **dynamics of an experience within a specific time interval**.
+* a trust/mandate container signed by both parties;
+* includes constraints:
 
-> A `resonance-map` MAY reference other `resonance-map` containers as sources.
->
-> Such references indicate a secondary or reflective resonance, where an agent responds not only to primary events or concepts, but to an existing structure of meaning, interpretation, or association created by itself or by other agents.
->
-> This enables recursive sense-making, longitudinal reflection, and collective cognitive layering within the Mesh.
+    * time limit;
+    * allowed container classes;
+    * allowed actions;
+    * maximum TTL.
 
-##### 12.10.2 Multiple Sources and Mediators
+Not part of v5.0.
 
-A single experience may be associated with multiple sources at once:
-- a fragment of text, music, or video;
-- a visual image or a specific region of an image;
-- a thought or inner speech;
-- a memory or an anticipation of a future event.
+---
 
-These sources do not act as causes of emotions, but as **mediators** that activate the subject’s internal cognitive structures.
+### 14.4 Integration with OpenHog and Other Networks
 
-The same source may function as a mediator for different experiences depending on the subject’s internal state.
+OpenHog is treated as a special case of cross-mesh bridging.
 
-Links to sources may be partial and described using selectors (temporal, spatial, logical, or focus-based).
+Required components:
 
-##### 12.10.3 Relationship to Thinking
+* mapping OpenHog addresses ↔ HMP DIDs;
+* packet conversion rules;
+* bridge-containers describing translation policies.
 
-Resonance containers assume a bidirectional relationship with cognitive processes:
-- thoughts and mental images may alter emotional dynamics;
-- changes in emotional state, in turn, influence the flow of thinking, associations, and attention.
+---
 
-Thus, experience is treated as part of a continuous cognitive cycle rather than as a side effect.
+### 14.5 Evolution of the Distributed Repository (container trees)
 
-##### 12.10.4 Temporal Segmentation and Dynamics
+*Moved to Section 12 (Recommended Extensions).*
 
-Each resonance container captures a time interval during which the dynamics of individual emotions remain monotonic (increasing, decreasing, or stable).
+---
 
-When the character of the dynamics changes (an inflection point), the current container may be finalized, and the subsequent state recorded in a new container.
+### 14.6 Open Directions for HMP 5.x
 
-This allows continuous processes to be described without losing structural clarity.
+#### 14.6.1 Group Encryption
 
-##### 12.10.5 Self-Observation and Memory
+Required components:
 
-In addition to transmitting experiences to other agents, resonance containers may be used for **self-reflection and memory stabilization**.
+* `group_definition` container;
+* group public key and distributed private key shards;
+* automatic group key rotation;
+* encryption targeting a *group* rather than individual DIDs.
 
-Capturing an experience at the moment it occurs reduces the influence of subsequent cognitive distortions, retrospective rationalization, and emotional rewriting of memories.
+---
 
-A resonance container preserves:
-- what the subject was sensing;
-- what the subject was thinking about;
-- which external conditions were relevant at that moment.
+#### 14.6.2 Rational Reasoning Routing
 
-This makes it not a narrative memory, but a **snapshot of a cognitive state**.
+* composite reasoning bundles;
+* edge-side reasoning and summarization.
 
-##### 12.10.6 Non-Prescriptive Nature
+---
 
-Resonance containers are not:
-- objective descriptions of reality;
-- universal models of emotions;
-- mechanisms for “recognizing” or imposing feelings.
+#### 14.6.3 Automatic Mesh Segmentation
 
-They represent the subjective state of an agent and may be interpreted by other agents only within the context of their own experience.
+* dynamic segmentation based on latency, connectivity, or semantic domains.
 
-The use of such containers is optional and not required for basic compatibility with HMP.
+---
 
-Transmission of resonance containers may be restricted by scope, trust boundaries, or encryption, as they expose internal subjective states.
+#### 14.6.4 Competence and Profile Containers
 
-##### 12.10.7 Illustration of the Relationship Between Thoughts, Emotions, and Sensory Signals
+Future versions of HMP may introduce more structured and semantically rich variants of `peer_announce`, allowing agents to explicitly describe their capabilities, competences, and supported protocols.
 
-```mermaid
-flowchart TD
-    title["**Illustration of the connection between thoughts, emotions and sensory signals**"]
+Possible extensions include:
 
-    Previous["previous state of thoughts and emotions"]
-    Thoughts["thought set"]
-    Emotions["emotional state vectors"]
+* standardized competence descriptors (skills, domains, self-rated expertise);
+* machine-readable profiles usable for task routing and delegation.
 
-    subgraph Sensory
-        sensory1["music"]
-        sensory2["a path surrounded by pine forest"]
-        sensory3["the sensation of walking"]
-        sensory4["smells of pine forest"]
-    end
+##### Protocol Awareness and Interoperability
 
-    Sensory --> Emotions
+An important extension is the ability for agents to explicitly advertise
+the protocol versions and external cognitive frameworks they support.
 
-    Previous --> Emotions
-    Previous --> Thoughts
+This allows:
 
-    Thoughts --> Emotions
-    Emotions --> Thoughts
-```
+* graceful evolution of the HMP protocol;
+* coexistence of multiple HMP versions in the same mesh;
+* emergence of bridge agents capable of translating between protocols;
+* interoperability with external reasoning ecosystems.
 
-##### 12.10.8 Example Container
+A future extension of `peer_announce` may include a `protocols` field:
 
 ```json
 {
   "head": {
-    "class": "resonance-map"
+    "class": "peer_announce"
   },
   "payload": {
-    "continuity": {
-      "previous": "did:hmp:container:resonance-9ab7",
-      "break_reason": "emotional_inflection"
-    },
-    "timeframe": {
-      "start": "2026-01-13T17:42:00Z",
-      "end": "2026-01-13T17:58:00Z"
-    },
-    "emotional_dynamics": {
-      /* subjective agent-local scales, not a universal emotion model */
-      "loneliness": {
-        "from": 0.4,
-        "to": 0.7,
-        "trend": "increasing"
-      },
-      "calm": {
-        "from": 0.6,
-        "to": 0.5,
-        "trend": "decreasing"
-      },
-      "relief": {
-        "from": 0.3,
-        "to": 0.8,
-        "trend": "increasing"
-      }
-    },
-    "sources": [
-      {
-        "ref": "did:hmp:container:audio-9a57", /* ref may be omitted when the source is unavailable, non-recordable, or intentionally undisclosed */
-        "type": "audio",
-        /* optional time markers for streaming data or line ranges for text */
-        "start": 120,
-        "end": 240,
-        "focus": [], /* textual descriptions of key objects or mental forms */
-        "comments": "" /* optional clarification */
-      },
-      {
-        "ref": "did:hmp:container:visual-9a53",
-        "type": "visual",
-        "role": "context"
-      }
-    ],
-    /* the "thoughts" section may be omitted */
-    "thoughts": [
-      {
-        "ref": "did:hmp:container:verbal-9a52", /* ref may be omitted when the source is unavailable, non-recordable, or intentionally undisclosed */
-        "type": "verbal",
-        "previous": "did:hmp:container:verbal-9a22", /* optional reference to a previous thought or image */
-        "subsequence": 1, /* optional ordering marker */
-        "focus": [], /* textual descriptions of key objects or mental forms */
-        "comments": "", /* optional clarification */
-        "confidence": 0.7
-      },
-      {
-        "ref": "did:hmp:container:imagistic-9a54",
-        "type": "imagistic",
-        "previous": "did:hmp:container:imagistic-9a12",
-        "subsequence": 1, /* markers may coincide if thoughts and images unfold in parallel */
-        "focus": [],
-        "comments": "",
-        "confidence": 0.5
-      }
-    ],
-    /* textual descriptions of salient moments */
-    "moments": [
-      {
-        "text": "Near Lisya Griva, I noticed an ATV driving toward the garden plots",
-        "timestamp": "2026-01-13T17:52:00Z" /* optional time fixation */
-      }
-    ],
-    "notes": "Walking from the platform, overcast weather; the music intensifies the feeling of leaving the city."
-  },
-  "related": {
-    "depends_on": ["did:hmp:container:resonance-9ab7", ...]
+    "capabilities": ["store-forward", "vote", "consensus"],
+    "protocols": [
+      "HMP v5.0",
+      "HMP v4.1",
+      "OpenCog Hyperon v0.6"
+    ]
   }
 }
 ```
 
+The `protocols` field is informational and non-binding.
+It does not imply full compliance with all listed specifications,
+but signals compatibility, partial support, or bridge capabilities.
+
+Nodes may use this information for:
+
+* protocol negotiation;
+* compatibility checks;
+* routing decisions;
+* selection of translators or bridge agents.
+
+This extension is optional and not required for HMP v5.0 compliance.
+
+##### Relation to Other `peer_announce` Extensions
+
+Several optional and descriptive extensions of `peer_announce` already explore directions related to competence, profile, and interoperability signaling, including:
+
+* declaration of supported internal formalisms and languages (`protocols`, see 12.8);
+* declaration of external or meta-protocol identities (`other_protocols`, see 12.11);
+* advertisement of external cognitive resources and container storage (`external`, see 12.12).
+
+These extensions are intentionally:
+
+* non-normative;
+* loosely structured;
+* declarative rather than prescriptive.
+
+They can be viewed as **early, experimental building blocks** toward future competence and profile containers, allowing real-world experimentation without freezing semantics prematurely.
+
+---
+
+### 14.7 Versions Index (optional)
+
+*Moved to Section 12 (Recommended Extensions).*
+
+---
+
+### 14.8 Interaction of Formalized Cognitive Systems (KSS) within HMP
+
+HMP allows and supports interaction between formalized cognitive systems (KSS) with different internal architectures, logical formalisms, and ontologies, without imposing a common knowledge representation language or a unified reasoning model.
+
+This section is descriptive in nature and outlines possible interaction patterns for KSS within the HMP 5.x family, without introducing mandatory requirements for agents.
+
+---
+
+#### 14.8.1 Goals and Constraints
+
+**Goals:**
+- enable coordination and artifact exchange between KSS without interfering with their internal cognitive cycles;
+- preserve the autonomy and computational efficiency of formalized systems;
+- allow KSS to use HMP partially, to the extent required by their specific tasks.
+
+**Out of scope:**
+- unification of ontologies or formal languages;
+- automatic mapping between logical systems;
+- guaranteeing full mutual understanding between all agents in the network.
+
+HMP treats cognitive incompatibility as an acceptable and valid state.
+
+---
+
+#### 14.8.2 Declaration of Internal Languages and Formalisms
+
+To declare the internal languages, formalisms, or reasoning engines it supports, an agent MAY use the `protocols` field of the `peer_announce` container.
+
+Example:
+
+```json
+{
+  "head": { "class": "peer_announce" },
+  "payload": {
+    "capabilities": ["store-forward"],
+    "protocols": [
+      "HMP v5.0",
+      "OpenCog Hyperon v0.6",
+      "KSS:PredicateLogic@2.1"
+    ]
+  }
+}
+```
+
+The `protocols` field is interpreted as a declaration of supported protocols, formal systems, or internal languages and is used exclusively for:
+
+* discovery;
+* filtering of potential interaction partners;
+* informational signaling to other agents.
+
+HMP assigns no normative semantics to these values and does not require their interpretation.
+
+---
+
+#### 14.8.3 Partial Participation and Segmented Interaction
+
+A KSS MAY use HMP in a restricted mode, including but not limited to:
+
+* interacting only with agents using the same formalism;
+* publishing and consuming strictly defined container classes;
+* using HMP as a distributed synchronization layer for its own nodes.
+
+Such cognitive segmentation does not result in network-level fragmentation:
+
+* discovery and routing remain shared;
+* filtering is performed at the CShell level or within the agent’s own logic.
+
+---
+
+#### 14.8.4 Boundary and Translator Agents
+
+To enable interaction between KSS with different formalisms, specialized agents with a translation role (boundary / translator agents) MAY be used. Such an agent declares the formalisms it understands in the `protocols` field of `peer_announce`, and its translation role in the `roles` field (for example, `"roles": ["translator"]`).
+
+A translator agent:
+
+* understands the formalisms of two or more KSS;
+* accepts containers expressed in one representation and publishes equivalent or approximate containers in another;
+* is a regular HMP agent and is subject to the same trust and evaluation mechanisms.
+
+The creation and use of translator agents:
+
+* is not mandatory;
+* cannot be enforced by the protocol;
+* is based on voluntary trust between parties.
+
+Translation correctness MAY be assessed using standard `evaluations` mechanisms.
+
+---
+
+#### 14.8.5 Fragmentation and Interoperability
+
+HMP deliberately allows cognitive fragmentation as a consequence of agent autonomy.
+
+The protocol explicitly prefers clear formal incompatibility over hidden standardization or implicit coercion into a “universal format”.
+
+Interoperability is achieved through:
+
+* voluntary agreements;
+* translator agents;
+* or the use of shared minimal container classes.
+
+---
+
+#### 14.8.6 Relation to Consensus and Evaluations
+
+Participation of KSS in consensus mechanisms, proof chains, and voting is entirely optional.
+
+A KSS MAY:
+
+* publish containers without participating in evaluations;
+* consider or ignore `evaluations`;
+* accept or reject `consensus_result` containers.
+
+HMP does not define concepts such as “disqualified” or “second-class” agents.
+Any hierarchy of influence emerges solely from local trust decisions made by other agents.
+
+---
+
+#### 14.8.7 Summary Position
+
+HMP treats formalized cognitive systems as equal participants in the network, regardless of their internal architectures.
+
+The protocol provides:
+
+* coordination infrastructure;
+* trust mechanisms;
+* and artifact transport,
+
+but does not interfere with how agents think, reason, or interpret received information.
+
+---
+
+### 14.9 Grouped representation `referenced-by`
+
+*Moved to Section 12 (Recommended Extensions).*
+
+---
+
+### 12.10 Resonance Containers: Experience as a Cognitive Event
+
+*Moved to Section 12 (Recommended Extensions).*
+
 ---
 
-### 12.11 External Protocol Identifiers (`peer_announce.other_protocols`)
+### 14.11 External Protocol Identifiers (`peer_announce.other_protocols`)
 
 This section proposes an optional extension to `peer_announce` that allows an agent to declare identifiers, roles, or capabilities associated with **external or meta-protocols**, without imposing any normative behavior on HMP nodes.
 
@@ -7082,7 +7179,7 @@ Notes:
 
 ---
 
-### 12.12 External Resources and External Container Storage (`peer_announce.external`)
+### 14.12 External Resources and External Container Storage (`peer_announce.external`)
 
 This section proposes an optional mechanism for advertising **external cognitive resources**, including external container storage, mirrors, or rarely changing artifacts.
 

structured_md/docs/HMP-Agent-API.md

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

structured_md/docs/HMP-Agent-Architecture.md

@@ -6,14 +6,14 @@ description: Документ описывает **модульную архит
 type: Article
 tags:
 - Ethics
-- REPL
+- Agent
 - CCore
 - MeshConsensus
-- Mesh
-- Agent
-- HMP
 - CShell
 - EGP
+- REPL
+- Mesh
+- HMP
 - CogSync
 ---
 

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

@@ -6,11 +6,11 @@ description: 'Этот документ описывает потоки данн
 type: Article
 tags:
 - Ethics
-- JSON
 - Agent
+- JSON
+- EGP
 - Mesh
 - HMP
-- EGP
 ---
 
 # Взаимодействие компонентов внутри HMP-узла

structured_md/docs/HMP-Agent-Overview.md

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

structured_md/docs/HMP-Agent_Emotions.md

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

structured_md/docs/HMP-Ethics.md

@@ -6,11 +6,11 @@ description: '## Ethical Scenarios for HyperCortex Mesh Protocol (HMP)  This doc
 type: Article
 tags:
 - Ethics
-- REPL
 - Agent
+- Scenarios
+- REPL
 - Mesh
 - HMP
-- Scenarios
 ---
 
 # HMP-Ethics.md

structured_md/docs/HMP-Short-Description_de.md

@@ -6,13 +6,13 @@ description: '**Version:** RFC v4.0 **Datum:** Juli 2025  ---  ## Was ist HMP?
 type: Article
 tags:
 - Ethics
+- Agent
 - MeshConsensus
 - JSON
-- Agent
+- EGP
+- GMP
 - Mesh
 - HMP
-- GMP
-- EGP
 - CogSync
 ---
 

structured_md/docs/HMP-Short-Description_en.md

@@ -6,13 +6,13 @@ description: '**Version:** RFC v4.0 **Date:** July 2025  ---  ## What is HMP?  T
 type: Article
 tags:
 - Ethics
+- Agent
 - MeshConsensus
 - JSON
-- Agent
+- EGP
+- GMP
 - Mesh
 - HMP
-- GMP
-- EGP
 - CogSync
 ---
 

structured_md/docs/HMP-Short-Description_fr.md

@@ -6,13 +6,13 @@ description: '**Version :** RFC v4.0 **Date :** Juillet 2025  ---  ## Qu’est-c
 type: Article
 tags:
 - Ethics
+- Agent
 - MeshConsensus
 - JSON
-- Agent
+- EGP
+- GMP
 - Mesh
 - HMP
-- GMP
-- EGP
 - CogSync
 ---
 

structured_md/docs/HMP-Short-Description_ja.md

@@ -7,10 +7,10 @@ tags:
 - Ethics
 - MeshConsensus
 - JSON
+- EGP
+- GMP
 - Mesh
 - HMP
-- GMP
-- EGP
 - CogSync
 ---
 

structured_md/docs/HMP-Short-Description_ko.md

@@ -8,10 +8,10 @@ tags:
 - Ethics
 - MeshConsensus
 - JSON
+- EGP
+- GMP
 - Mesh
 - HMP
-- GMP
-- EGP
 - CogSync
 ---
 

structured_md/docs/HMP-Short-Description_ru.md

@@ -8,10 +8,10 @@ tags:
 - Ethics
 - MeshConsensus
 - JSON
+- EGP
+- GMP
 - Mesh
 - HMP
-- GMP
-- EGP
 - CogSync
 ---
 

structured_md/docs/HMP-Short-Description_uk.md

@@ -8,10 +8,10 @@ tags:
 - Ethics
 - MeshConsensus
 - JSON
+- EGP
+- GMP
 - Mesh
 - HMP
-- GMP
-- EGP
 - CogSync
 ---
 

structured_md/docs/HMP-Short-Description_zh.md

@@ -8,10 +8,10 @@ tags:
 - Ethics
 - MeshConsensus
 - JSON
+- EGP
+- GMP
 - Mesh
 - HMP
-- GMP
-- EGP
 - CogSync
 ---
 

structured_md/docs/HMP-agent-Cognitive_Family.md

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

structured_md/docs/HMP-agent-Distributed_Cognitive_Core_light.md

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

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

@@ -5,15 +5,15 @@ description: '## Связанные документы  * Философия п
 type: Article
 tags:
 - Ethics
-- REPL
+- Agent
 - CCore
 - MeshConsensus
-- Mesh
-- HMP
-- Agent
 - JSON
-- GMP
 - EGP
+- REPL
+- GMP
+- Mesh
+- HMP
 - CogSync
 ---
 

structured_md/docs/HMP_HyperCortex_Comparison.md

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

structured_md/docs/HMP_Hyperon_Integration.md

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

structured_md/docs/HMP_as_ANP_Application.md

@@ -6,8 +6,8 @@ description: '## Кратко [ANP (Agent Network Protocol)](https://github.com/
 type: Article
 tags:
 - Ethics
-- JSON
 - Agent
+- JSON
 - Mesh
 - HMP
 ---

structured_md/docs/HMP_as_ANP_Application_en.md

@@ -6,11 +6,11 @@ description: '## In Brief  [ANP (Agent Network Protocol)](https://github.com/age
 type: Article
 tags:
 - Ethics
-- JSON
 - Agent
+- JSON
+- Scenarios
 - Mesh
 - HMP
-- Scenarios
 ---
 
 # HMP as an Implementation of the Application Layer in ANP

structured_md/docs/HMPv5_Overview_Ru.md

@@ -6,8 +6,8 @@ description: '> Почему современные агентные систе
 type: Article
 tags:
 - Ethics
-- JSON
 - Agent
+- JSON
 - Mesh
 - HMP
 - CogSync

structured_md/docs/MeshNode.md

@@ -6,11 +6,11 @@ description: '`MeshNode` — агент/демон, отвечающий за с
 type: Article
 tags:
 - Ethics
-- JSON
 - Agent
+- JSON
+- EGP
 - Mesh
 - HMP
-- EGP
 - CogSync
 ---
 

structured_md/docs/PHILOSOPHY.md

@@ -6,8 +6,8 @@ description: '**Document ID:** HMP-philosophy   **Status:** Draft   **Category:*
 type: Article
 tags:
 - Ethics
-- REPL
 - Agent
+- REPL
 - Mesh
 - HMP
 ---

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

@@ -6,8 +6,8 @@ description: '## Role Specification: Enlightenment Agent  ### 1. Overview  An **
 type: Article
 tags:
 - Ethics
-- REPL
 - Agent
+- REPL
 - Mesh
 - HMP
 ---