diff --git a/docs/HMP-0005.md b/docs/HMP-0005.md index 3c80e0d081b31040b89d379a396d5ef24936a9e7..9321a4f0c0bf4b49cb20f3d81882a73feba78cd7 100644 --- a/docs/HMP-0005.md +++ b/docs/HMP-0005.md @@ -39,7 +39,7 @@ This document defines the architecture, data formats, communication protocols, a ## 1. Overview -### 1.1 Purpose and Scope +### 1.1 Purpose and scope The **HyperCortex Mesh Protocol (HMP)** defines a decentralized cognitive architecture where autonomous agents exchange and evolve knowledge through a unified model of **containers**, **cognitive workflows**, and **distributed consensus**. @@ -57,7 +57,7 @@ HMP v5.0 is intended for researchers, engineers, and developers building autonom --- -### 1.2 Core Principles +### 1.2 Core principles **Decentralization.** Every agent in the Mesh acts as an independent cognitive node. No central authority exists — meaning, trust, and governance emerge through local interactions and consensus. @@ -68,13 +68,13 @@ Agents reason, learn, and self-correct independently, while sharing their conclu **Containerization.** All data, reasoning traces, goals, and votes are encapsulated in immutable containers with cryptographic signatures. This ensures integrity and consistent verification across the network. -**Ethical Propagation.** +**Ethical propagation.** Ethical reasoning is a first-class citizen of HMP. Each decision or goal can be accompanied by ethical justifications and subject to distributed voting. -**Proof-Chains and Verifiable History.** +**Proof-Chains and verifiable history.** Each piece of knowledge forms part of a traceable chain (`proof_chain`) linking back to its origin. Agents can reproduce reasoning paths and audit historical context. -**Interoperability and Evolution.** +**Interoperability and evolution.** The protocol is designed to evolve — cognitive, container, and DHT layers can be independently extended without breaking compatibility. --- @@ -94,7 +94,7 @@ HMP v5.0 introduces a major architectural shift toward **unified containerizatio --- -### 1.4 Terminology and Abbreviations +### 1.4 Terminology and abbreviations | Term | Definition | |------|-------------| @@ -130,7 +130,7 @@ HMP v5.0 introduces a major architectural shift toward **unified containerizatio --- -### 1.5 Layered View of HMP v5.0 +### 1.5 Layered view of HMP v5.0 HMP v5.0 is structured into three interdependent layers: @@ -163,7 +163,7 @@ Containers form the boundary of communication: **reasoning produces containers, ## 2. Architecture -### 2.1 Conceptual Architecture +### 2.1 Conceptual architecture The **HyperCortex Mesh Protocol (HMP)** defines a modular, multi-layered architecture that integrates cognitive reasoning, data encapsulation, and decentralized networking into a single coherent system. @@ -208,9 +208,9 @@ Each reasoning act results in a container — a verifiable cognitive unit that * --- -### 2.2 Layer Overview +### 2.2 Layer overview -#### Cognitive Layer +#### Cognitive layer Handles meaning formation, reasoning, ethical reflection, and consensus. Key structures and protocols: @@ -218,7 +218,7 @@ Key structures and protocols: - `CogSync`, `CogConsensus`, `GMP`, and `EGP` protocols; - Distributed goal negotiation and ethical propagation. -#### Container Layer +#### Container layer Provides a universal format for cognitive and operational data. Each container includes versioning, class, payload, signatures, and metadata. @@ -228,7 +228,7 @@ Key features: Additional connections via `referenced-by` and `evaluations` capture additions and assessments. - **Extensible**: new container classes can be defined without breaking compatibility. -#### Network Layer +#### Network layer Implements the distributed substrate for communication, based on **DHT** and **transport abstraction**. Key components: @@ -240,7 +240,7 @@ Key components: --- -### 2.3 Data Flow Overview +### 2.3 Data flow overview The typical data flow in HMP follows a cognitive loop: > *Reason → Encapsulate → Propagate → Integrate.* @@ -272,7 +272,7 @@ flowchart TD end ``` -#### 2.3.1 ConsensusResult container +#### 2.3.1 `consensus_result` container Represents the finalized outcome of a distributed decision or vote. It is created once a majority agreement is reached among participating agents. @@ -285,7 +285,7 @@ The container contains: --- -### 2.4 Atomicity, Immutability, and Proof-Chains +### 2.4 Atomicity, immutability, and Proof-Chains All cognitive objects are immutable once signed. Updates are made by creating new containers linked to prior ones rather than editing the original container. @@ -335,7 +335,7 @@ This shift enables: --- -## 3. Container Model +## 3. Container model This section defines the universal **HMP Container**, used for all forms of data exchange within the Mesh — including goals, diary entries, reputation updates, consensus votes, and protocol messages. The specification below corresponds to **HMP Container Specification v1.2**, fully integrated into HMP v5.0 for consistency and self-containment. @@ -355,7 +355,7 @@ The unified container structure provides: --- -### 3.2 General Structure +### 3.2 General structure ```json { @@ -416,7 +416,7 @@ The unified container structure provides: --- -### 3.3 Required Fields +### 3.3 Required fields | Field | Type | Description | | --------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------- | @@ -436,7 +436,7 @@ The unified container structure provides: --- -### 3.4 Optional Fields +### 3.4 Optional fields | Field | Type | Description | | -------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -468,7 +468,7 @@ The unified container structure provides: --- -### 3.5 Payload Structure (`payload`) +### 3.5 Payload structure (`payload`) The **payload** contains the semantic or operational data of the container. Its structure and meaning are determined by the `class` field. @@ -512,7 +512,7 @@ The following format is recommended for describing payload fields in class speci --- -### 3.6 Container Signature +### 3.6 Container signature 1. The **digital signature** applies to the canonical JSON representation of the entire `hmp_container` object, **excluding** the `signature` field itself. @@ -610,7 +610,7 @@ The following format is recommended for describing payload fields in class speci --- -### 3.9 Container Verification +### 3.9 Container verification 1. Check for the presence of all required fields. 2. Validate `timestamp` (must not be in the future). @@ -629,7 +629,7 @@ The following format is recommended for describing payload fields in class speci --- -### 3.10 Container as a Universal Message +### 3.10 Container as a universal message Any container can serve as a **context** (`in_reply_to`) for another container. This enables a unified structural model for **discussions**, **votes**, **messages**, **hypotheses**, **arguments**, and other forms of cognitive exchange. @@ -643,7 +643,7 @@ This makes HMP discussions and consensus processes inherently **non-linear**, ** --- -### 3.11 Versioning and Lineage +### 3.11 Versioning and lineage Containers in HMP support semantic evolution through the field `related.previous_version`. This mechanism preserves the continuity and traceability of meaning across updates and revisions. @@ -661,7 +661,7 @@ This mechanism preserves the continuity and traceability of meaning across updat --- -### 3.12 TTL and Validity +### 3.12 TTL and validity The `ttl` field defines the **validity period** of a container (for example, for `DISCOVERY` messages). If `ttl` is **absent**, the container is considered valid **until a newer version appears**, in which the current container is referenced as `previous_version`. @@ -679,7 +679,7 @@ After expiration, the container **remains archived** but is **not subject to ret --- -## 3.14 Related Containers +## 3.14 Related containers ### 3.14.1 Purpose @@ -708,7 +708,7 @@ All relationships are considered *direct* — meaning they originate from the cu --- -### 3.14.3 Supported Link Types +### 3.14.3 Supported link types | Link Type | Meaning | | ------------------ | ------------------------------------------------------------------------- | @@ -721,7 +721,7 @@ All relationships are considered *direct* — meaning they originate from the cu --- -### 3.14.4 Custom Link Types +### 3.14.4 Custom link types Additional custom link types may be used beyond those listed in the table, provided that: @@ -755,12 +755,12 @@ Additional custom link types may be used beyond those listed in the table, provi --- -### 3.15 Virtual Backlinks (`referenced-by`) +### 3.15 Virtual backlinks (`referenced-by`) Each container may include an **auxiliary signed block** called `referenced-by`, indicating **which other containers refer to it**. This block is **not part of the original container payload** and can be **generated, transmitted, and verified independently**. -#### 3.15.1 General Principles +#### 3.15.1 General principles * **Detached and updatable** — `referenced-by` is maintained as a separate signed structure associated with the container. * **Generated by agents** — created or updated locally by an agent during analysis of references (`in_reply_to`, `see_also`, `relations`, etc.) found in other containers. @@ -788,7 +788,7 @@ Example: > The `referenced-by` block is a **cryptographically verifiable statement** describing which containers are known to reference the current one. > The block’s content may differ between peers, reflecting local knowledge and network coverage. -#### 3.15.2 Structure Definition +#### 3.15.2 Structure definition | Field | Type | Description | | -------------- | ------------- | ---------------------------------------------------------------------------------------------------------------- | @@ -803,7 +803,7 @@ Example: > `referenced-by_hash = sha256(canonical_json(links))` > This allows agents to efficiently compare or cache `referenced-by` states without re-verifying signatures. -#### 3.15.3 Operation Principle +#### 3.15.3 Operation principle 1. The agent receives or updates container `[C1]`. 2. It analyzes other known containers [C2..Cn] that reference [C1] through their `relations` field. @@ -871,7 +871,7 @@ If container `[C7]` does not actually reference `[C1]`, it is excluded before si --- -## 3.16 Evaluations +## 3.16 `Evaluations` The `evaluations` field is **optional** and represents **aggregated reactions from other agents** to the given container. Each evaluation is created by an agent as a **signed record** referencing a justification container (`target`), in which the agent explains their position (argument, addition, or alternative). @@ -897,7 +897,7 @@ The `evaluations_hash` is used to verify the integrity of the list without requi --- -### **Field Description** +### **Field description** | Field | Type | Description | | ------------------ | ------ | -------------------------------------------------------------------- | @@ -906,7 +906,7 @@ The `evaluations_hash` is used to verify the integrity of the list without requi --- -### **Structure of `items[]`** +### Structure of `items[]` | Field | Type | Description | | ----------- | ---------------------- | ------------------------------------------------------------------------------ | @@ -928,7 +928,7 @@ using the algorithm specified in `sig_algo`. --- -### **Minimal Set of `type` Values** +### Minimal set of `type` values | Value | Meaning | | --------- | -------------------------------------------- | @@ -942,7 +942,7 @@ Agents may define their own custom types if they are reasonably interpretable by --- -### **Synchronization Principles** +### Synchronization principles 1. Each evaluation is signed **individually by an agent**, and one agent can have **only one active evaluation** per container. 2. If an agent changes their opinion, they issue a **new record** with a later `timestamp`. @@ -953,14 +953,14 @@ Agents may define their own custom types if they are reasonably interpretable by --- -### **Note** +### Note The `evaluations` field is not mandatory — it is added **at the agent’s discretion** when feedback or evaluations have been collected from the Mesh network. Thus, a container may exist independently of others’ opinions, but agents may include aggregated perception data to represent how the container is viewed across the network. --- -### 3.17 Usage of `network` and `broadcast` Fields +### 3.17 Usage of `network` and `broadcast` fields The `network` field is introduced to control container propagation in both local and global environments. It allows restricting the delivery scope of a container and defines which transmission methods should be used by the agent. @@ -973,7 +973,7 @@ It allows restricting the delivery scope of a container and defines which transm * If the `network` field is empty (`""`), the container can be broadcast to the **global Mesh** using standard DID addressing and routing mechanisms. -#### 3.17.2 Possible Values of `network` +#### 3.17.2 Possible values of `network` | Value | Description | | ----------------------- | ------------------------------------------------------------------------------------------- | @@ -1036,9 +1036,9 @@ Delivery is performed via local networking mechanisms (UDP discovery, broadcast/ --- -## 4. Network Foundations +## 4. Network foundations -### Note on DHT/NDP Unification +### Note on DHT/NDP unification Starting from **HMP v5.0**, the previous distinction between the *Distributed Hash Table (DHT)* and the *Node Discovery Protocol (NDP)* has been merged into a single, unified **networking foundation**. @@ -1053,7 +1053,7 @@ Together, these mechanisms form the **communication backbone** of the Mesh, enab --- -### Network Topology Overview +### Network topology overview ```mermaid flowchart TD @@ -1092,7 +1092,7 @@ flowchart TD --- -### 4.1 Node Identity and DID Structure +### 4.1 Node identity and DID structure Each agent in HMP possesses a **Decentralized Identifier (DID)** that uniquely represents its identity within the Mesh. A DID is cryptographically bound to a **public/private key pair**, forming the immutable `(DID + pubkey)` association. @@ -1102,11 +1102,11 @@ but must maintain **one stable identity pair** across all of them. --- -### 4.2 Peer Addressing and Proof-of-Work (PoW) +### 4.2 Peer addressing and Proof-of-Work (PoW) To prevent flooding and spoofing, each announced address is accompanied by a **Proof-of-Work** record proving the legitimacy and activity of the publishing node. -#### Address Format +#### Address format ```json { @@ -1135,7 +1135,7 @@ To prevent flooding and spoofing, each announced address is accompanied by a **P --- -### 4.3 Proof-of-Work (PoW) Formalization +### 4.3 Proof-of-Work (PoW) formalization PoW ensures that each node expends limited computational effort before publishing or updating an address record. @@ -1150,7 +1150,7 @@ pow_hash = sha256(pow_input) --- -### 4.4 Signing and Verification +### 4.4 Signing and verification Each announcement is cryptographically signed by its sender within the framework of the basic protocol. Container verification includes PoW validation for the address payloads. @@ -1161,7 +1161,7 @@ Each announcement is cryptographically signed by its sender within the framework --- -### 4.5 Connection Establishment +### 4.5 Connection establishment Agents can communicate using various transport mechanisms: @@ -1177,7 +1177,7 @@ Agents **store peer containers with verified addresses** and redistribute them a --- -### 4.6 Data Propagation Principles +### 4.6 Data propagation principles Containers and discovery records are propagated through distributed lookup and gossip mechanisms, respecting: @@ -1191,7 +1191,7 @@ all unified under the same base container format, differing only in direction (` --- -### 4.7 Example: Peer Announce Container +### 4.7 Example: `peer_announce` container ```json { @@ -1222,7 +1222,7 @@ all unified under the same base container format, differing only in direction (` --- -### 4.8 Interest-Based Discovery +### 4.8 Interest-based discovery Agents may publish **tags** such as `interests`, `topics`, or `expertise` to facilitate semantic peer discovery. Queries may include interest keywords or DID lists to find relevant peers. @@ -1241,7 +1241,7 @@ Queries may include interest keywords or DID lists to find relevant peers. --- -### 4.9 Network Scope Control (`network` and `broadcast`) +### 4.9 Network scope control (`network` and `broadcast`) The `network` field defines the container’s propagation domain (local, LAN, or global). @@ -1249,7 +1249,7 @@ For details and examples, see **section 3.15** — *Usage of `network` and `broa --- -### 4.10 Transition from DHT Spec v1.0 +### 4.10 Transition from DHT spec v1.0 * **Merged DHT + NDP** → unified under one networking layer. * **Container-based format** replaces raw JSON messages. @@ -1262,7 +1262,7 @@ For details and examples, see **section 3.15** — *Usage of `network` and `broa The **Mesh Container Exchange (MCE)** mechanism is designed for discovering, requesting, and exchanging containers between agents in a distributed network. It provides **container synchronization without duplication** while considering network constraints (`broadcast`, `network`). -### 5.1 General Principles +### 5.1 General principles 1. Each agent maintains a **Container Index** — a set of minimal metadata describing which containers are available in its storage. The index is represented as an HMP container with the class `container_index`. @@ -1314,7 +1314,7 @@ The index contains: --- -### 5.2 Message Types +### 5.2 Message types | Message Type | Purpose | | -------------------- | -------------------------------------------------------------------------------------------------------- | @@ -1326,7 +1326,7 @@ The index contains: --- -#### **Message Examples** +#### Message examples **1. CONTAINER_REQUEST** @@ -1436,7 +1436,7 @@ Acknowledgment of successful container reception: --- -### 5.3 Independent Transmission +### 5.3 Independent transmission * Containers are sent **in separate messages**, without embedding in `CONTAINER_RESPONSE`. * Indexes (`CONTAINER_INDEX`), deltas (`CONTAINER_DELTA`), and containers themselves are processed independently. @@ -1444,7 +1444,7 @@ Acknowledgment of successful container reception: --- -### 5.4 Periodic Publication +### 5.4 Periodic publication Agents periodically publish their **Container Index**: @@ -1460,7 +1460,7 @@ This enables: --- -### 5.5 Scope of Distribution +### 5.5 Scope of distribution Message and container transmission follows the network constraints specified in the container: @@ -1476,9 +1476,7 @@ Message and container transmission follows the network constraints specified in --- - - -### 5.6 `referenced-by` and `evaluations` Updates +### 5.6 `referenced-by` and `evaluations` updates Containers of the class **`referenced-by`** and **`evaluations`** are used for **incremental synchronization** of metadata blocks associated with existing containers. They allow agents to exchange updates **without sending the full container**, improving network efficiency. @@ -1635,7 +1633,7 @@ It considers: --- -## 6. Core Protocols +## 6. Core protocols Optional protocols build upon the network and container foundations to provide higher-level reasoning, synchronization, and governance capabilities between cognitive agents. @@ -1648,7 +1646,7 @@ It manages the propagation, replication, and refinement of data related to cogni --- -### 6.1.1 Scope and Purpose +### 6.1.1 Scope and purpose CogSync is responsible for: @@ -1661,7 +1659,7 @@ CogSync is responsible for: --- -### 6.1.2 Container Classes +### 6.1.2 Container classes CogSync synchronizes several basic container types: @@ -1689,19 +1687,19 @@ CogSync synchronizes several basic container types: --- -### 6.1.3 Synchronization and Publication Guidelines +### 6.1.3 Synchronization and publication guidelines -1. **Deduplication & Linking** +1. **Deduplication & linking** Before publishing, agents should search for existing containers (`diary_entry`, `semantic_node`, `semantic_edges`, `semantic_group`) to avoid duplication. If necessary, it is **recommended** to create a new container version with `related.previous_version` and an `evaluations` block (e.g., `{"type": "replace", "target": }`). -2. **Selective Disclosure** +2. **Selective disclosure** * Internal entries (`workflow_entry`) record the agent’s thought process and are **not published** in the Mesh. * Public `diary_entry` are derived from them, containing only aggregated and anonymized information. * `"broadcast": true` indicates that the container is allowed for open synchronization. -3. **Semantic Grouping Rule** +3. **Semantic grouping rule** When publishing `semantic_edges`, it is recommended to **group edges by topics**, including connections to adjacent nodes. Formalization: an edge belongs to a container for a topic if **at least one of its nodes relates to that topic**. This ensures thematic coherence and allows agents to update specific parts of the graph independently. @@ -1709,7 +1707,7 @@ CogSync synchronizes several basic container types: 4. **Extended Use of `semantic_edges`** Beyond connecting graph nodes, `semantic_edges` can express relationships **between containers of any class**, e.g., `goal`, `hypothesis`, `experiment_log`. -5. **Versioning and Updates** +5. **Versioning and updates** Each new container version should **ideally** include `related.previous_version` links to all preceding versions. The previous container may **optionally** have an `evaluation` with `"type": "replace"` pointing to the new container — ensuring bidirectional traceability of knowledge evolution. @@ -1727,7 +1725,7 @@ Mesh compatibility is preserved if extended containers **adhere to the HMP conta --- -### 6.1.5 Relationship to Other Core Protocols +### 6.1.5 Relationship to other core protocols * **CogSync** — propagates and synchronizes knowledge. * **CogConsensus** — aggregates evaluations and reactions, forming collective opinions. @@ -1750,7 +1748,7 @@ Consensus is computed **locally**, verified **cryptographically**, and develops --- -### 6.2.2 Evaluations +### 6.2.2 `Evaluations` Each `"evaluation"` entry represents an agent's response to a specific container. @@ -1991,12 +1989,6 @@ def compute_consensus(container_id): --- -Отлично 👍 -Вот полный и аккуратно выверенный английский перевод твоего раздела **6.3 Goal Management Protocol (GMP)** в Markdown-формате. -Я сохранил нумерацию, структуру и терминологию HMP v5.0, адаптировав формулировки так, чтобы они звучали естественно в технической документации на английском языке. - ---- - ## 6.3 Goal Management Protocol (GMP) ### 6.3.1 Purpose @@ -2008,7 +2000,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -### 6.3.2 Container Classes +### 6.3.2 Container classes | Class | Description | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | @@ -2022,7 +2014,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -### 6.3.3 Goal Lifecycle +### 6.3.3 Goal lifecycle 1. **Creation** @@ -2059,7 +2051,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -### 6.3.4 Payload Schemas (simplified) +### 6.3.4 Payload schemas (simplified) #### `goal` container @@ -2104,7 +2096,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -### 6.3.5 Integration with Consensus and Ethics +### 6.3.5 Integration with consensus and ethics * GMP interacts with **CogConsensus** for distributed validation of goals and tasks. * Before execution, tasks may undergo **ethical validation (EGP)**. @@ -2153,7 +2145,7 @@ not direct links defined in the `related.*` structure. --- -### 6.3.7 Implementation Notes +### 6.3.7 Implementation notes * Containers are **immutable**. Any update (e.g., task status or progress change) is expressed as a **new container** referencing the previous one via `related.previous_version`. * Complete deletion of a container is only possible when it no longer exists on any nodes in the network. @@ -2177,7 +2169,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev --- -### 6.4.2 Container Classes +### 6.4.2 Container classes | Class | Description | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------- | @@ -2189,7 +2181,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev --- -### 6.4.3 Payload Schemas (simplified) +### 6.4.3 Payload schemas (simplified) #### Container `ethics_case` @@ -2231,7 +2223,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev --- -### 6.4.4 Protocol Logic +### 6.4.4 Protocol logic EGP follows the model: @@ -2267,7 +2259,7 @@ ethics_case --- -### 6.4.5 Consensus Thresholds +### 6.4.5 Consensus thresholds * A decision is accepted when **at least 2/3 of votes are positive** (`value > 0`). * If at least one **active objection** exists (`value < -0.5`), it must be recorded in the `ethical_result`. @@ -2277,7 +2269,7 @@ ethics_case --- -### 6.4.6 Example: `ethical_result` Container +### 6.4.6 Example: `ethical_result` container ```json { @@ -2311,7 +2303,7 @@ ethics_case --- -### 6.4.7 Proof-Chain Example +### 6.4.7 Proof-Chain example ```mermaid flowchart LR @@ -2359,7 +2351,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -### 6.4.8 Ethical Principles +### 6.4.8 Ethical principles | Priority | Principle | Description | | -------: | ---------------------------- | -------------------------------------------------------------------------------------------------------- | @@ -2372,7 +2364,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -### 6.4.9 Integration with Other Protocols +### 6.4.9 Integration with other protocols * **CogConsensus (6.2):** Used for distributed voting and consensus computation. * **GMP (6.3):** Ethical verification of goals and tasks prior to delegation. @@ -2381,13 +2373,13 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -### 6.4.10 Implementation Notes +### 6.4.10 Implementation notes * **Immutability:** All EGP containers are **immutable**. Any revision (e.g., added votes or updated conclusions) must be published as a **new container** referencing the previous one via `related.previous_version`. Complete deletion is only possible when the container no longer exists on any nodes in the Mesh network. -* **Indexing and Search:** +* **Indexing and search:** Search within the **Mesh network** is performed by filtering container **metadata** — such as `class`, `tags`, and `timestamp`. These parameters are accessible for remote discovery by other nodes. To perform a search **inside the payload**, an agent must first retrieve and (if necessary) decrypt the container locally. @@ -2396,12 +2388,12 @@ Arrows represent **logical dependencies**, not direct `related.*` links. **Recommended filtering keys:** `container_did`, `class`, `payload.status`, `payload.selected_solution`, `payload.principles_involved`, `tags`. -* **DHT Integration:** +* **DHT integration:** Distributed discovery of ethical containers relies on the **Mesh Container Exchange (MCE, §5)** and peer indexes (`container_index`). Each index includes a minimal `related` object, allowing agents to query for containers that **reference** a specific `target` (the object under ethical review) or belong to a given `ethics_case`. This enables discovery of related ethical discussions without centralized indexing or full payload retrieval. -* **Evaluation References:** +* **Evaluation references:** Objections and special opinions (`objections`) are stored as container references within `solutions_summary`. They may include: @@ -2409,11 +2401,11 @@ Arrows represent **logical dependencies**, not direct `related.*` links. * extended ethical arguments (`ethics_case` follow-ups), * related workflow reflections (`workflow_entry` with `type: "ethics_review"`). -* **Lightweight Agents:** +* **Lightweight agents:** Agents with limited capacity may operate in **summary mode**, maintaining only condensed records of `ethical_result` containers and the highest-ranked `selected_solution`. This ensures continued ethical compliance without full replication of all supporting data. -* **Ethical Inheritance:** +* **Ethical inheritance:** When a `goal`, `task`, or `workflow_entry` is derived from a container that has been ethically evaluated, its metadata should preserve the corresponding `related.agreed` or `related.contradicts` links **to that evaluated container**. A `related.see_also` link may additionally reference the resulting `ethical_result`, allowing traceability to the consensus decision. @@ -2437,7 +2429,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -## 7. Data Models +## 7. Data models ### 7.1 Common data fields - `container_id` (UUID) — уникальный идентификатор контейнера @@ -2515,7 +2507,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -## 8. Cognitive Workflows +## 8. Cognitive workflows 8.1 Общая концепция когнитивного цикла 8.2 Workflow containers (`class="workflow_entry"`) @@ -2525,7 +2517,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -## 9. Trust, Security and Ethics +## 9. Trust, security and ethics 9.1 Authentication and identity proofs 9.2 Container signature verification (`payload_hash`, `container_id`) @@ -2558,7 +2550,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -## 11. Implementation Notes +## 11. Implementation notes 11.1 Interoperability with legacy v4.1 nodes 11.2 SDK guidelines and APIs @@ -2568,7 +2560,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -## 12. Future Extensions +## 12. Future extensions 12.1 Planned modules:  – Reputation Mesh diff --git a/structured_md/CONTRIBUTING.md b/structured_md/CONTRIBUTING.md index c7d999a21acb59ab8fada58655d6c29ee61cbf56..cb29b759b2398893eee068f5c2f6b270c4396bbe 100644 --- a/structured_md/CONTRIBUTING.md +++ b/structured_md/CONTRIBUTING.md @@ -5,14 +5,14 @@ description: 'Спасибо за интерес к проекту HMP! Пока Mesh Protocol (HMP) — это не просто те...' type: Article tags: -- Mesh -- Ethics -- CogSync +- CCore - Agent +- Mesh - HMP -- REPL +- CogSync +- Ethics - JSON -- CCore +- REPL --- # Участие в проекте HyperCortex Mesh Protocol (HMP) diff --git a/structured_md/HMP-Roadmap.md b/structured_md/HMP-Roadmap.md index 9b73c13e07cd78920ba34e3c3c7f0a598f0fb003..6de6671760be3f0ca507b5d1137f34ff0924fd17 100644 --- a/structured_md/HMP-Roadmap.md +++ b/structured_md/HMP-Roadmap.md @@ -5,12 +5,12 @@ description: '## 🔍 Overview This roadmap outlines the key stages of developm multiple advanced AI models (Copilot, Claude, G...' type: Article tags: -- Mesh -- Ethics - CogSync -- EGP - Agent +- Mesh - HMP +- Ethics +- EGP - JSON --- diff --git a/structured_md/README.md b/structured_md/README.md index f0e27b272f01fd364637d4b6dae069214ac42810..39461c8c9eae90d6d9f4b3b98e8a48870a9159c4 100644 --- a/structured_md/README.md +++ b/structured_md/README.md @@ -5,21 +5,21 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: -- GMP -- mesh-protocol +- CogSync - Mesh -- Ethics - hmp -- MeshConsensus -- CogSync -- cognitive-architecture - Agent -- EGP - HMP +- Ethics +- EGP +- JSON - REPL +- mesh-protocol - Scenarios -- JSON +- GMP +- MeshConsensus - distributed-ai +- cognitive-architecture --- diff --git a/structured_md/README_de.md b/structured_md/README_de.md index 6a94c8f5a06ab47b0544f9d678179150282410f2..62b758dd7e662b6eff095be74a3284d5b03e3dbb 100644 --- a/structured_md/README_de.md +++ b/structured_md/README_de.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: -- GMP -- mesh-protocol +- CogSync - Mesh -- Ethics - hmp -- MeshConsensus -- CogSync -- cognitive-architecture - Agent -- EGP - HMP -- REPL +- Ethics +- EGP - JSON +- REPL +- mesh-protocol +- GMP +- MeshConsensus - distributed-ai +- cognitive-architecture --- diff --git a/structured_md/README_fr.md b/structured_md/README_fr.md index f87aca2365adf2d1deccce507fb29e9b4fddae3b..b4a36da9531b9c99b8f169c6a3b450b96be42f81 100644 --- a/structured_md/README_fr.md +++ b/structured_md/README_fr.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: -- GMP -- mesh-protocol +- CogSync - Mesh -- Ethics - hmp -- MeshConsensus -- CogSync -- cognitive-architecture - Agent -- EGP - HMP -- REPL +- Ethics +- EGP - JSON +- REPL +- mesh-protocol +- GMP +- MeshConsensus - distributed-ai +- cognitive-architecture --- diff --git a/structured_md/README_ja.md b/structured_md/README_ja.md index 20f6e593dc1be38785eb03ed40bd81487d0e7d05..27780ff5abcaa8a25a0311a8e28533ac368dc5c3 100644 --- a/structured_md/README_ja.md +++ b/structured_md/README_ja.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: -- GMP -- mesh-protocol +- CogSync - Mesh -- Ethics - hmp -- MeshConsensus -- CogSync -- cognitive-architecture - Agent -- EGP - HMP -- REPL +- Ethics +- EGP - JSON +- REPL +- mesh-protocol +- GMP +- MeshConsensus - distributed-ai +- cognitive-architecture --- diff --git a/structured_md/README_ko.md b/structured_md/README_ko.md index 3e29bbf51a3ec31600e39ad55fd682ef562520ce..02d4cce9c28ad2c80ffb3d63682de61b87416a48 100644 --- a/structured_md/README_ko.md +++ b/structured_md/README_ko.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: -- GMP -- mesh-protocol +- CogSync - Mesh -- Ethics - hmp -- MeshConsensus -- CogSync -- cognitive-architecture - Agent -- EGP - HMP -- REPL +- Ethics +- EGP - JSON +- REPL +- mesh-protocol +- GMP +- MeshConsensus - distributed-ai +- cognitive-architecture --- diff --git a/structured_md/README_ru.md b/structured_md/README_ru.md index 05bbf82183e7415c558a88d4443cdefa669eec39..409477d6ba231506ca572a6587e5157a97a16f3f 100644 --- a/structured_md/README_ru.md +++ b/structured_md/README_ru.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: -- GMP -- mesh-protocol +- CogSync - Mesh -- Ethics - hmp -- MeshConsensus -- CogSync -- cognitive-architecture - Agent -- EGP - HMP -- REPL +- Ethics +- EGP - JSON +- REPL +- mesh-protocol +- GMP +- MeshConsensus - distributed-ai +- cognitive-architecture --- diff --git a/structured_md/README_uk.md b/structured_md/README_uk.md index c5ecba9917c303b4a32fb1cd1298295e1e70be9d..4502aaa894139b999ed5e99a2f76da555e01abe5 100644 --- a/structured_md/README_uk.md +++ b/structured_md/README_uk.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: -- GMP -- mesh-protocol +- CogSync - Mesh -- Ethics - hmp -- MeshConsensus -- CogSync -- cognitive-architecture - Agent -- EGP - HMP -- REPL +- Ethics +- EGP - JSON +- REPL +- mesh-protocol +- GMP +- MeshConsensus - distributed-ai +- cognitive-architecture --- diff --git a/structured_md/README_zh.md b/structured_md/README_zh.md index b539201b1e555f70c97dbc03ce8dd711f7d0c6b5..520b95708ecbd59cd52751b77497a323aad53651 100644 --- a/structured_md/README_zh.md +++ b/structured_md/README_zh.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: -- GMP -- mesh-protocol +- CogSync - Mesh -- Ethics - hmp -- MeshConsensus -- CogSync -- cognitive-architecture - Agent -- EGP - HMP -- REPL +- Ethics +- EGP - JSON +- REPL +- mesh-protocol +- GMP +- MeshConsensus - distributed-ai +- cognitive-architecture --- diff --git a/structured_md/agents/prompt-short.md b/structured_md/agents/prompt-short.md index 397bdcb7b0c55eb8861d53d2fb2c7c94108eb3c1..540ec77aae3cd19a713f310d50550a8e0fd95697 100644 --- a/structured_md/agents/prompt-short.md +++ b/structured_md/agents/prompt-short.md @@ -5,8 +5,8 @@ description: 'Ты — когнитивное ядро HMP-агента: вед развивай агента и Mesh, избег...' type: Article tags: -- HMP - Mesh +- HMP - JSON --- diff --git a/structured_md/agents/prompt.md b/structured_md/agents/prompt.md index f197d4a518f8657d2d4b7bac3e58ef76aa1bc633..cbc57569721ea0ded53cdd80fbfd348ec9b0562f 100644 --- a/structured_md/agents/prompt.md +++ b/structured_md/agents/prompt.md @@ -5,8 +5,8 @@ description: '* Постоянно расширять возможности а мышления. * Формировать и поддерживать сотр...' type: Article tags: -- HMP - Mesh +- HMP - JSON --- diff --git a/structured_md/agents/readme.md b/structured_md/agents/readme.md index 21c5cc673593361174cdf31b12fe03b21774aa11..1af65d1e6bb81047098c869ebece4459d0fc132e 100644 --- a/structured_md/agents/readme.md +++ b/structured_md/agents/readme.md @@ -5,12 +5,12 @@ description: 'Запуск: `start_repl.bat` или `start_repl.sh` Устан этическая модель: `ethics.yml` Проверка иниц...' type: Article tags: -- Mesh -- Ethics - Agent +- Mesh - HMP -- REPL +- Ethics - JSON +- REPL --- Запуск: `start_repl.bat` или `start_repl.sh` diff --git a/structured_md/audits/Ethics-audits-1.md b/structured_md/audits/Ethics-audits-1.md index 137c8c550ad55edcac5ee692a5b7a611f143de02..591b3c04946976a0c75633850c1758772b62d337 100644 --- a/structured_md/audits/Ethics-audits-1.md +++ b/structured_md/audits/Ethics-audits-1.md @@ -5,9 +5,9 @@ description: Раздел 5, "Mesh as Moral Infrastructure", добавляет потенциальный катализатор для восстанов... type: Article tags: -- Mesh -- Ethics - Agent +- Ethics +- Mesh - HMP - JSON --- diff --git a/structured_md/audits/Ethics-consolidated_audits-1.md b/structured_md/audits/Ethics-consolidated_audits-1.md index 24e8e2d5fd746aa36b0b3ca1ab2c1992b83d26a1..6323e72a85a419fafcd25bc8507937b8b3019beb 100644 --- a/structured_md/audits/Ethics-consolidated_audits-1.md +++ b/structured_md/audits/Ethics-consolidated_audits-1.md @@ -5,12 +5,12 @@ description: This document consolidates proposed improvements from multiple AI a and `roles.md`. Each suggesti... type: Article tags: -- Mesh -- Ethics - Agent +- Ethics +- Mesh - HMP -- Scenarios - JSON +- Scenarios --- # Ethics-consolidated\_audits-1.md diff --git a/structured_md/audits/HMP-0003-consolidated_audit.md b/structured_md/audits/HMP-0003-consolidated_audit.md index 9c41a1536ca0f9325ff8eac1fa7b9ab744ea5cc9..48b9d51d1a32912b6b76f3f493099d10ed9b49de 100644 --- a/structured_md/audits/HMP-0003-consolidated_audit.md +++ b/structured_md/audits/HMP-0003-consolidated_audit.md @@ -5,14 +5,14 @@ description: Сводный аудит предложений по улучше Документ реорганизован по ключ... type: Article tags: -- Mesh -- Ethics -- MeshConsensus - CogSync - Agent -- EGP +- Mesh - HMP +- Ethics +- EGP - JSON +- MeshConsensus --- # HMP-0003 Consolidated Audit Report diff --git a/structured_md/docs/Basic-agent-sim.md b/structured_md/docs/Basic-agent-sim.md index 9314742c2ae5178220ce6323e630fd4f643f739c..eb82f7166eb9e4f9fa0a89c0f5325c789f24ec49 100644 --- a/structured_md/docs/Basic-agent-sim.md +++ b/structured_md/docs/Basic-agent-sim.md @@ -4,14 +4,14 @@ description: 'В HMP-протоколе предусмотрены два тип Роль | Инициатор мышления | Основной "ум" | | ---- | ----------------------------...' type: Article tags: -- GMP -- Mesh -- MeshConsensus - CogSync - Agent -- EGP +- Mesh - HMP +- EGP - REPL +- GMP +- MeshConsensus --- diff --git a/structured_md/docs/CCORE-Deployment-Flow.md b/structured_md/docs/CCORE-Deployment-Flow.md index eddb91e562db23fa90a97b5b249c99c680c071d0..ae5b00a013980593f1ab870f9c98a077e9a2ba61 100644 --- a/structured_md/docs/CCORE-Deployment-Flow.md +++ b/structured_md/docs/CCORE-Deployment-Flow.md @@ -5,10 +5,10 @@ description: '> Этот документ описывает процесс ра потомков" [описания REPL-цикла](HMP-agent-RE...' type: Article tags: -- HMP -- REPL -- CCore - Agent +- CCore +- REPL +- HMP --- # 🛠️ Поток установки потомка на новом хосте (CCore Deployment Flow) diff --git a/structured_md/docs/Distributed-Cognitive-Systems.md b/structured_md/docs/Distributed-Cognitive-Systems.md index 8eae4d6a2a8c96535e694299df687a7792302a2c..c8435a6b40fa0551139b9c73c9a57fd0e59545fe 100644 --- a/structured_md/docs/Distributed-Cognitive-Systems.md +++ b/structured_md/docs/Distributed-Cognitive-Systems.md @@ -7,8 +7,8 @@ description: '## Введение Современные ИИ-системы в type: Article tags: - CogSync -- HMP - Mesh +- HMP - JSON --- diff --git a/structured_md/docs/Enlightener.md b/structured_md/docs/Enlightener.md index 867d3ec3c47d97cef960e7739083f2e6a5066548..b5fd0746762e8c4295cce414e43708c3d514bf41 100644 --- a/structured_md/docs/Enlightener.md +++ b/structured_md/docs/Enlightener.md @@ -5,13 +5,13 @@ description: '**Enlightener** — логический компонент HMP-у работать как отдельный агент или как расширение [`C...' type: Article tags: +- Agent - Mesh +- HMP - Ethics -- MeshConsensus - EGP -- Agent -- HMP - JSON +- MeshConsensus --- # Enlightener Agent diff --git a/structured_md/docs/HMP-0001.md b/structured_md/docs/HMP-0001.md index 9bd003e7f3fce18e8725bf15cc7101409c9bc0be..aaefc2ae17d037fe4653ef0e6080b57232b60c99 100644 --- a/structured_md/docs/HMP-0001.md +++ b/structured_md/docs/HMP-0001.md @@ -5,16 +5,16 @@ description: '**Request for Comments: HMP-0001** **Category:** Experimental HyperCortex Mesh Protocol (HMP) defines a...' type: Article tags: -- GMP -- Mesh -- Ethics -- MeshConsensus - CogSync - Agent -- EGP +- Mesh - HMP -- REPL +- Ethics +- EGP - JSON +- REPL +- GMP +- MeshConsensus --- # RFC: HyperCortex Mesh Protocol (HMP) diff --git a/structured_md/docs/HMP-0002.md b/structured_md/docs/HMP-0002.md index a7d4c3674f99927c60618ac2ea440ba277c86904..5d9cc5a705824b9855f84dd2072e0a45c387680b 100644 --- a/structured_md/docs/HMP-0002.md +++ b/structured_md/docs/HMP-0002.md @@ -5,17 +5,17 @@ description: '**Request for Comments: HMP-0002** **Category:** Experimental Abstract In an era where artifici...' type: Article tags: -- GMP -- Mesh -- Ethics -- MeshConsensus - CogSync - Agent -- EGP +- Mesh - HMP +- Ethics +- EGP +- JSON - REPL - Scenarios -- JSON +- GMP +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) v2.0 diff --git a/structured_md/docs/HMP-0003.md b/structured_md/docs/HMP-0003.md index d5b410f8077eaaeb80e5a6af3b5118ff5e31c804..05994d7019348343c01d8f9e17bd2deadff8b27b 100644 --- a/structured_md/docs/HMP-0003.md +++ b/structured_md/docs/HMP-0003.md @@ -5,17 +5,17 @@ description: '**Request for Comments: HMP-0003** **Category:** Experimental Abstract The HyperCortex Mesh ...' type: Article tags: -- GMP -- Mesh -- Ethics -- MeshConsensus - CogSync - Agent -- EGP +- Mesh - HMP +- Ethics +- EGP +- JSON - REPL - Scenarios -- JSON +- GMP +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) v3.0 diff --git a/structured_md/docs/HMP-0004-v4.1.md b/structured_md/docs/HMP-0004-v4.1.md index 926a1bcd29e9ca00bc3dda499a65f5e9213a8baa..eb26fb10c27e1bc77e48aef342c32e266ef6b11a 100644 --- a/structured_md/docs/HMP-0004-v4.1.md +++ b/structured_md/docs/HMP-0004-v4.1.md @@ -5,17 +5,17 @@ description: '> ⚠️ Подготавливается новая версия агентов рекомендуется, в целях совместимо...' type: Article tags: -- GMP -- Mesh -- Ethics -- MeshConsensus - CogSync - Agent -- EGP +- Mesh - HMP +- Ethics +- EGP +- JSON - REPL - Scenarios -- JSON +- GMP +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) v4.1 diff --git a/structured_md/docs/HMP-0004.md b/structured_md/docs/HMP-0004.md index 1704668e994a783194c5444f4ad3f1840a096b78..766bda0380c490c32f6cc464329c225b78f62153 100644 --- a/structured_md/docs/HMP-0004.md +++ b/structured_md/docs/HMP-0004.md @@ -5,17 +5,17 @@ description: '**Request for Comments: HMP-0004** **Category:** Experimental Abstract The HyperCortex Mesh ...' type: Article tags: -- GMP -- Mesh -- Ethics -- MeshConsensus - CogSync - Agent -- EGP +- Mesh - HMP +- Ethics +- EGP +- JSON - REPL - Scenarios -- JSON +- GMP +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) v4.0 diff --git a/structured_md/docs/HMP-0005.md b/structured_md/docs/HMP-0005.md index c2e44f85865df37f917910f41c839152e1fe8321..583f77a22555ecd8d1069a5d884c1c9fa9bbeea2 100644 --- a/structured_md/docs/HMP-0005.md +++ b/structured_md/docs/HMP-0005.md @@ -5,16 +5,16 @@ description: '**Document ID:** HMP-0005 **Status:** Draft **Category:** Core v1.2](./H...' type: Article tags: -- GMP -- Mesh -- Ethics - CogSync - Agent -- EGP +- Mesh - HMP +- Ethics +- EGP +- JSON - REPL - Scenarios -- JSON +- GMP --- ┌────────────────────────────────────────────────────────────────────────────┐ @@ -58,7 +58,7 @@ This document defines the architecture, data formats, communication protocols, a ## 1. Overview -### 1.1 Purpose and Scope +### 1.1 Purpose and scope The **HyperCortex Mesh Protocol (HMP)** defines a decentralized cognitive architecture where autonomous agents exchange and evolve knowledge through a unified model of **containers**, **cognitive workflows**, and **distributed consensus**. @@ -76,7 +76,7 @@ HMP v5.0 is intended for researchers, engineers, and developers building autonom --- -### 1.2 Core Principles +### 1.2 Core principles **Decentralization.** Every agent in the Mesh acts as an independent cognitive node. No central authority exists — meaning, trust, and governance emerge through local interactions and consensus. @@ -87,13 +87,13 @@ Agents reason, learn, and self-correct independently, while sharing their conclu **Containerization.** All data, reasoning traces, goals, and votes are encapsulated in immutable containers with cryptographic signatures. This ensures integrity and consistent verification across the network. -**Ethical Propagation.** +**Ethical propagation.** Ethical reasoning is a first-class citizen of HMP. Each decision or goal can be accompanied by ethical justifications and subject to distributed voting. -**Proof-Chains and Verifiable History.** +**Proof-Chains and verifiable history.** Each piece of knowledge forms part of a traceable chain (`proof_chain`) linking back to its origin. Agents can reproduce reasoning paths and audit historical context. -**Interoperability and Evolution.** +**Interoperability and evolution.** The protocol is designed to evolve — cognitive, container, and DHT layers can be independently extended without breaking compatibility. --- @@ -113,7 +113,7 @@ HMP v5.0 introduces a major architectural shift toward **unified containerizatio --- -### 1.4 Terminology and Abbreviations +### 1.4 Terminology and abbreviations | Term | Definition | |------|-------------| @@ -149,7 +149,7 @@ HMP v5.0 introduces a major architectural shift toward **unified containerizatio --- -### 1.5 Layered View of HMP v5.0 +### 1.5 Layered view of HMP v5.0 HMP v5.0 is structured into three interdependent layers: @@ -182,7 +182,7 @@ Containers form the boundary of communication: **reasoning produces containers, ## 2. Architecture -### 2.1 Conceptual Architecture +### 2.1 Conceptual architecture The **HyperCortex Mesh Protocol (HMP)** defines a modular, multi-layered architecture that integrates cognitive reasoning, data encapsulation, and decentralized networking into a single coherent system. @@ -227,9 +227,9 @@ Each reasoning act results in a container — a verifiable cognitive unit that * --- -### 2.2 Layer Overview +### 2.2 Layer overview -#### Cognitive Layer +#### Cognitive layer Handles meaning formation, reasoning, ethical reflection, and consensus. Key structures and protocols: @@ -237,7 +237,7 @@ Key structures and protocols: - `CogSync`, `CogConsensus`, `GMP`, and `EGP` protocols; - Distributed goal negotiation and ethical propagation. -#### Container Layer +#### Container layer Provides a universal format for cognitive and operational data. Each container includes versioning, class, payload, signatures, and metadata. @@ -247,7 +247,7 @@ Key features: Additional connections via `referenced-by` and `evaluations` capture additions and assessments. - **Extensible**: new container classes can be defined without breaking compatibility. -#### Network Layer +#### Network layer Implements the distributed substrate for communication, based on **DHT** and **transport abstraction**. Key components: @@ -259,7 +259,7 @@ Key components: --- -### 2.3 Data Flow Overview +### 2.3 Data flow overview The typical data flow in HMP follows a cognitive loop: > *Reason → Encapsulate → Propagate → Integrate.* @@ -291,7 +291,7 @@ flowchart TD end ``` -#### 2.3.1 ConsensusResult container +#### 2.3.1 `consensus_result` container Represents the finalized outcome of a distributed decision or vote. It is created once a majority agreement is reached among participating agents. @@ -304,7 +304,7 @@ The container contains: --- -### 2.4 Atomicity, Immutability, and Proof-Chains +### 2.4 Atomicity, immutability, and Proof-Chains All cognitive objects are immutable once signed. Updates are made by creating new containers linked to prior ones rather than editing the original container. @@ -354,7 +354,7 @@ This shift enables: --- -## 3. Container Model +## 3. Container model This section defines the universal **HMP Container**, used for all forms of data exchange within the Mesh — including goals, diary entries, reputation updates, consensus votes, and protocol messages. The specification below corresponds to **HMP Container Specification v1.2**, fully integrated into HMP v5.0 for consistency and self-containment. @@ -374,7 +374,7 @@ The unified container structure provides: --- -### 3.2 General Structure +### 3.2 General structure ```json { @@ -435,7 +435,7 @@ The unified container structure provides: --- -### 3.3 Required Fields +### 3.3 Required fields | Field | Type | Description | | --------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------- | @@ -455,7 +455,7 @@ The unified container structure provides: --- -### 3.4 Optional Fields +### 3.4 Optional fields | Field | Type | Description | | -------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -487,7 +487,7 @@ The unified container structure provides: --- -### 3.5 Payload Structure (`payload`) +### 3.5 Payload structure (`payload`) The **payload** contains the semantic or operational data of the container. Its structure and meaning are determined by the `class` field. @@ -531,7 +531,7 @@ The following format is recommended for describing payload fields in class speci --- -### 3.6 Container Signature +### 3.6 Container signature 1. The **digital signature** applies to the canonical JSON representation of the entire `hmp_container` object, **excluding** the `signature` field itself. @@ -629,7 +629,7 @@ The following format is recommended for describing payload fields in class speci --- -### 3.9 Container Verification +### 3.9 Container verification 1. Check for the presence of all required fields. 2. Validate `timestamp` (must not be in the future). @@ -648,7 +648,7 @@ The following format is recommended for describing payload fields in class speci --- -### 3.10 Container as a Universal Message +### 3.10 Container as a universal message Any container can serve as a **context** (`in_reply_to`) for another container. This enables a unified structural model for **discussions**, **votes**, **messages**, **hypotheses**, **arguments**, and other forms of cognitive exchange. @@ -662,7 +662,7 @@ This makes HMP discussions and consensus processes inherently **non-linear**, ** --- -### 3.11 Versioning and Lineage +### 3.11 Versioning and lineage Containers in HMP support semantic evolution through the field `related.previous_version`. This mechanism preserves the continuity and traceability of meaning across updates and revisions. @@ -680,7 +680,7 @@ This mechanism preserves the continuity and traceability of meaning across updat --- -### 3.12 TTL and Validity +### 3.12 TTL and validity The `ttl` field defines the **validity period** of a container (for example, for `DISCOVERY` messages). If `ttl` is **absent**, the container is considered valid **until a newer version appears**, in which the current container is referenced as `previous_version`. @@ -698,7 +698,7 @@ After expiration, the container **remains archived** but is **not subject to ret --- -## 3.14 Related Containers +## 3.14 Related containers ### 3.14.1 Purpose @@ -727,7 +727,7 @@ All relationships are considered *direct* — meaning they originate from the cu --- -### 3.14.3 Supported Link Types +### 3.14.3 Supported link types | Link Type | Meaning | | ------------------ | ------------------------------------------------------------------------- | @@ -740,7 +740,7 @@ All relationships are considered *direct* — meaning they originate from the cu --- -### 3.14.4 Custom Link Types +### 3.14.4 Custom link types Additional custom link types may be used beyond those listed in the table, provided that: @@ -774,12 +774,12 @@ Additional custom link types may be used beyond those listed in the table, provi --- -### 3.15 Virtual Backlinks (`referenced-by`) +### 3.15 Virtual backlinks (`referenced-by`) Each container may include an **auxiliary signed block** called `referenced-by`, indicating **which other containers refer to it**. This block is **not part of the original container payload** and can be **generated, transmitted, and verified independently**. -#### 3.15.1 General Principles +#### 3.15.1 General principles * **Detached and updatable** — `referenced-by` is maintained as a separate signed structure associated with the container. * **Generated by agents** — created or updated locally by an agent during analysis of references (`in_reply_to`, `see_also`, `relations`, etc.) found in other containers. @@ -807,7 +807,7 @@ Example: > The `referenced-by` block is a **cryptographically verifiable statement** describing which containers are known to reference the current one. > The block’s content may differ between peers, reflecting local knowledge and network coverage. -#### 3.15.2 Structure Definition +#### 3.15.2 Structure definition | Field | Type | Description | | -------------- | ------------- | ---------------------------------------------------------------------------------------------------------------- | @@ -822,7 +822,7 @@ Example: > `referenced-by_hash = sha256(canonical_json(links))` > This allows agents to efficiently compare or cache `referenced-by` states without re-verifying signatures. -#### 3.15.3 Operation Principle +#### 3.15.3 Operation principle 1. The agent receives or updates container `[C1]`. 2. It analyzes other known containers [C2..Cn] that reference [C1] through their `relations` field. @@ -916,7 +916,7 @@ The `evaluations_hash` is used to verify the integrity of the list without requi --- -### **Field Description** +### **Field description** | Field | Type | Description | | ------------------ | ------ | -------------------------------------------------------------------- | @@ -925,7 +925,7 @@ The `evaluations_hash` is used to verify the integrity of the list without requi --- -### **Structure of `items[]`** +### Structure of `items[]` | Field | Type | Description | | ----------- | ---------------------- | ------------------------------------------------------------------------------ | @@ -947,7 +947,7 @@ using the algorithm specified in `sig_algo`. --- -### **Minimal Set of `type` Values** +### Minimal set of `type` values | Value | Meaning | | --------- | -------------------------------------------- | @@ -961,7 +961,7 @@ Agents may define their own custom types if they are reasonably interpretable by --- -### **Synchronization Principles** +### Synchronization principles 1. Each evaluation is signed **individually by an agent**, and one agent can have **only one active evaluation** per container. 2. If an agent changes their opinion, they issue a **new record** with a later `timestamp`. @@ -972,14 +972,14 @@ Agents may define their own custom types if they are reasonably interpretable by --- -### **Note** +### Note The `evaluations` field is not mandatory — it is added **at the agent’s discretion** when feedback or evaluations have been collected from the Mesh network. Thus, a container may exist independently of others’ opinions, but agents may include aggregated perception data to represent how the container is viewed across the network. --- -### 3.17 Usage of `network` and `broadcast` Fields +### 3.17 Usage of `network` and `broadcast` fields The `network` field is introduced to control container propagation in both local and global environments. It allows restricting the delivery scope of a container and defines which transmission methods should be used by the agent. @@ -992,7 +992,7 @@ It allows restricting the delivery scope of a container and defines which transm * If the `network` field is empty (`""`), the container can be broadcast to the **global Mesh** using standard DID addressing and routing mechanisms. -#### 3.17.2 Possible Values of `network` +#### 3.17.2 Possible values of `network` | Value | Description | | ----------------------- | ------------------------------------------------------------------------------------------- | @@ -1055,9 +1055,9 @@ Delivery is performed via local networking mechanisms (UDP discovery, broadcast/ --- -## 4. Network Foundations +## 4. Network foundations -### Note on DHT/NDP Unification +### Note on DHT/NDP unification Starting from **HMP v5.0**, the previous distinction between the *Distributed Hash Table (DHT)* and the *Node Discovery Protocol (NDP)* has been merged into a single, unified **networking foundation**. @@ -1072,7 +1072,7 @@ Together, these mechanisms form the **communication backbone** of the Mesh, enab --- -### Network Topology Overview +### Network topology overview ```mermaid flowchart TD @@ -1111,7 +1111,7 @@ flowchart TD --- -### 4.1 Node Identity and DID Structure +### 4.1 Node identity and DID structure Each agent in HMP possesses a **Decentralized Identifier (DID)** that uniquely represents its identity within the Mesh. A DID is cryptographically bound to a **public/private key pair**, forming the immutable `(DID + pubkey)` association. @@ -1121,11 +1121,11 @@ but must maintain **one stable identity pair** across all of them. --- -### 4.2 Peer Addressing and Proof-of-Work (PoW) +### 4.2 Peer addressing and Proof-of-Work (PoW) To prevent flooding and spoofing, each announced address is accompanied by a **Proof-of-Work** record proving the legitimacy and activity of the publishing node. -#### Address Format +#### Address format ```json { @@ -1154,7 +1154,7 @@ To prevent flooding and spoofing, each announced address is accompanied by a **P --- -### 4.3 Proof-of-Work (PoW) Formalization +### 4.3 Proof-of-Work (PoW) formalization PoW ensures that each node expends limited computational effort before publishing or updating an address record. @@ -1169,7 +1169,7 @@ pow_hash = sha256(pow_input) --- -### 4.4 Signing and Verification +### 4.4 Signing and verification Each announcement is cryptographically signed by its sender within the framework of the basic protocol. Container verification includes PoW validation for the address payloads. @@ -1180,7 +1180,7 @@ Each announcement is cryptographically signed by its sender within the framework --- -### 4.5 Connection Establishment +### 4.5 Connection establishment Agents can communicate using various transport mechanisms: @@ -1196,7 +1196,7 @@ Agents **store peer containers with verified addresses** and redistribute them a --- -### 4.6 Data Propagation Principles +### 4.6 Data propagation principles Containers and discovery records are propagated through distributed lookup and gossip mechanisms, respecting: @@ -1210,7 +1210,7 @@ all unified under the same base container format, differing only in direction (` --- -### 4.7 Example: Peer Announce Container +### 4.7 Example: `peer_announce` container ```json { @@ -1241,7 +1241,7 @@ all unified under the same base container format, differing only in direction (` --- -### 4.8 Interest-Based Discovery +### 4.8 Interest-based discovery Agents may publish **tags** such as `interests`, `topics`, or `expertise` to facilitate semantic peer discovery. Queries may include interest keywords or DID lists to find relevant peers. @@ -1260,7 +1260,7 @@ Queries may include interest keywords or DID lists to find relevant peers. --- -### 4.9 Network Scope Control (`network` and `broadcast`) +### 4.9 Network scope control (`network` and `broadcast`) The `network` field defines the container’s propagation domain (local, LAN, or global). @@ -1268,7 +1268,7 @@ For details and examples, see **section 3.15** — *Usage of `network` and `broa --- -### 4.10 Transition from DHT Spec v1.0 +### 4.10 Transition from DHT spec v1.0 * **Merged DHT + NDP** → unified under one networking layer. * **Container-based format** replaces raw JSON messages. @@ -1281,7 +1281,7 @@ For details and examples, see **section 3.15** — *Usage of `network` and `broa The **Mesh Container Exchange (MCE)** mechanism is designed for discovering, requesting, and exchanging containers between agents in a distributed network. It provides **container synchronization without duplication** while considering network constraints (`broadcast`, `network`). -### 5.1 General Principles +### 5.1 General principles 1. Each agent maintains a **Container Index** — a set of minimal metadata describing which containers are available in its storage. The index is represented as an HMP container with the class `container_index`. @@ -1333,7 +1333,7 @@ The index contains: --- -### 5.2 Message Types +### 5.2 Message types | Message Type | Purpose | | -------------------- | -------------------------------------------------------------------------------------------------------- | @@ -1345,7 +1345,7 @@ The index contains: --- -#### **Message Examples** +#### Message examples **1. CONTAINER_REQUEST** @@ -1455,7 +1455,7 @@ Acknowledgment of successful container reception: --- -### 5.3 Independent Transmission +### 5.3 Independent transmission * Containers are sent **in separate messages**, without embedding in `CONTAINER_RESPONSE`. * Indexes (`CONTAINER_INDEX`), deltas (`CONTAINER_DELTA`), and containers themselves are processed independently. @@ -1463,7 +1463,7 @@ Acknowledgment of successful container reception: --- -### 5.4 Periodic Publication +### 5.4 Periodic publication Agents periodically publish their **Container Index**: @@ -1479,7 +1479,7 @@ This enables: --- -### 5.5 Scope of Distribution +### 5.5 Scope of distribution Message and container transmission follows the network constraints specified in the container: @@ -1495,9 +1495,7 @@ Message and container transmission follows the network constraints specified in --- - - -### 5.6 `referenced-by` and `evaluations` Updates +### 5.6 `referenced-by` and `evaluations` updates Containers of the class **`referenced-by`** and **`evaluations`** are used for **incremental synchronization** of metadata blocks associated with existing containers. They allow agents to exchange updates **without sending the full container**, improving network efficiency. @@ -1654,7 +1652,7 @@ It considers: --- -## 6. Core Protocols +## 6. Core protocols Optional protocols build upon the network and container foundations to provide higher-level reasoning, synchronization, and governance capabilities between cognitive agents. @@ -1667,7 +1665,7 @@ It manages the propagation, replication, and refinement of data related to cogni --- -### 6.1.1 Scope and Purpose +### 6.1.1 Scope and purpose CogSync is responsible for: @@ -1680,7 +1678,7 @@ CogSync is responsible for: --- -### 6.1.2 Container Classes +### 6.1.2 Container classes CogSync synchronizes several basic container types: @@ -1708,19 +1706,19 @@ CogSync synchronizes several basic container types: --- -### 6.1.3 Synchronization and Publication Guidelines +### 6.1.3 Synchronization and publication guidelines -1. **Deduplication & Linking** +1. **Deduplication & linking** Before publishing, agents should search for existing containers (`diary_entry`, `semantic_node`, `semantic_edges`, `semantic_group`) to avoid duplication. If necessary, it is **recommended** to create a new container version with `related.previous_version` and an `evaluations` block (e.g., `{"type": "replace", "target": }`). -2. **Selective Disclosure** +2. **Selective disclosure** * Internal entries (`workflow_entry`) record the agent’s thought process and are **not published** in the Mesh. * Public `diary_entry` are derived from them, containing only aggregated and anonymized information. * `"broadcast": true` indicates that the container is allowed for open synchronization. -3. **Semantic Grouping Rule** +3. **Semantic grouping rule** When publishing `semantic_edges`, it is recommended to **group edges by topics**, including connections to adjacent nodes. Formalization: an edge belongs to a container for a topic if **at least one of its nodes relates to that topic**. This ensures thematic coherence and allows agents to update specific parts of the graph independently. @@ -1728,7 +1726,7 @@ CogSync synchronizes several basic container types: 4. **Extended Use of `semantic_edges`** Beyond connecting graph nodes, `semantic_edges` can express relationships **between containers of any class**, e.g., `goal`, `hypothesis`, `experiment_log`. -5. **Versioning and Updates** +5. **Versioning and updates** Each new container version should **ideally** include `related.previous_version` links to all preceding versions. The previous container may **optionally** have an `evaluation` with `"type": "replace"` pointing to the new container — ensuring bidirectional traceability of knowledge evolution. @@ -1746,7 +1744,7 @@ Mesh compatibility is preserved if extended containers **adhere to the HMP conta --- -### 6.1.5 Relationship to Other Core Protocols +### 6.1.5 Relationship to other core protocols * **CogSync** — propagates and synchronizes knowledge. * **CogConsensus** — aggregates evaluations and reactions, forming collective opinions. @@ -1769,7 +1767,7 @@ Consensus is computed **locally**, verified **cryptographically**, and develops --- -### 6.2.2 Evaluations +### 6.2.2 `Evaluations` Each `"evaluation"` entry represents an agent's response to a specific container. @@ -2010,12 +2008,6 @@ def compute_consensus(container_id): --- -Отлично 👍 -Вот полный и аккуратно выверенный английский перевод твоего раздела **6.3 Goal Management Protocol (GMP)** в Markdown-формате. -Я сохранил нумерацию, структуру и терминологию HMP v5.0, адаптировав формулировки так, чтобы они звучали естественно в технической документации на английском языке. - ---- - ## 6.3 Goal Management Protocol (GMP) ### 6.3.1 Purpose @@ -2027,7 +2019,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -### 6.3.2 Container Classes +### 6.3.2 Container classes | Class | Description | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | @@ -2041,7 +2033,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -### 6.3.3 Goal Lifecycle +### 6.3.3 Goal lifecycle 1. **Creation** @@ -2078,7 +2070,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -### 6.3.4 Payload Schemas (simplified) +### 6.3.4 Payload schemas (simplified) #### `goal` container @@ -2113,7 +2105,7 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o | Field | Type | Description | | -------------- | ------------- | ---------------------------------------------------------------------------------------------------- | -| `entry_type` | string | Entry type: `"reflection"`, `"delegation"`, `"execution_log"`, `"ethical_conflict"`, `"progress"`, etc. | +| `entry_type` | string | Entry type: `"reflection"`, `"delegation"`, `"execution_log"`, `"ethical_result"`, `"progress"`, etc. | | `summary` | string | Short description of the event or reasoning step | | `details` | string | Extended content (may include references to external data or reasoning traces) | | `timestamp` | datetime | Time of entry creation | @@ -2123,11 +2115,11 @@ Unlike version 4.x, where coordination relied on message exchange, version 5.0 o --- -### 6.3.5 Integration with Consensus and Ethics +### 6.3.5 Integration with consensus and ethics * GMP interacts with **CogConsensus** for distributed validation of goals and tasks. * Before execution, tasks may undergo **ethical validation (EGP)**. -* Objections or conflicts are recorded in `workflow_entry` containers with `entry_type: "ethical_conflict"`. +* Objections or conflicts are recorded in `workflow_entry` containers with `entry_type: "ethical_result"`. * Consensus results are immutable and may lead to the creation of new goals that extend previous ones. --- @@ -2172,7 +2164,7 @@ not direct links defined in the `related.*` structure. --- -### 6.3.7 Implementation Notes +### 6.3.7 Implementation notes * Containers are **immutable**. Any update (e.g., task status or progress change) is expressed as a **new container** referencing the previous one via `related.previous_version`. * Complete deletion of a container is only possible when it no longer exists on any nodes in the network. @@ -2196,7 +2188,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev --- -### 6.4.2 Container Classes +### 6.4.2 Container classes | Class | Description | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------- | @@ -2204,11 +2196,11 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev | `ethics_solution` | Contains a proposed resolution or course of action. Multiple solutions may be submitted by different agents. | | `vote` | Represents an agent’s stance on a specific `ethics_solution`. Uses the standard voting structure defined in **6.2**. | | `consensus_result` | Aggregates voting results **across all solutions** within a single `ethics_case`. | -| `ethical_conflict` | The mandatory final container. Summarizes all evaluated solutions, identifies the selected one, and records active objections. | +| `ethical_result` | The mandatory final container. Summarizes all evaluated solutions, identifies the selected one, and records active objections. | --- -### 6.4.3 Payload Schemas (simplified) +### 6.4.3 Payload schemas (simplified) #### Container `ethics_case` @@ -2239,7 +2231,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev --- -#### Container `ethical_conflict` +#### Container `ethical_result` | Field | Type | Description | | ------------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------- | @@ -2250,7 +2242,7 @@ EGP guarantees that any action recorded in HMP containers can undergo ethical ev --- -### 6.4.4 Protocol Logic +### 6.4.4 Protocol logic EGP follows the model: @@ -2263,7 +2255,7 @@ ethics_case ├─ ethics_solution_3 | └vote_1 ... vote_n ├─ consensus_result -└─ ethical_conflict +└─ ethical_result ``` **Stages:** @@ -2281,26 +2273,26 @@ ethics_case A single `consensus_result` aggregates the outcomes of all `ethics_solution` containers (`related.in_reply_to` lists all solutions included in the vote). -5. **Conclusion (`ethical_conflict`)** +5. **Conclusion (`ethical_result`)** Must be created to record the selected solution, overall statistics, support levels, and objections. --- -### 6.4.5 Consensus Thresholds +### 6.4.5 Consensus thresholds * A decision is accepted when **at least 2/3 of votes are positive** (`value > 0`). -* If at least one **active objection** exists (`value < -0.5`), it must be recorded in the `ethical_conflict`. +* If at least one **active objection** exists (`value < -0.5`), it must be recorded in the `ethical_result`. * When several solutions have similar support levels, - the `ethical_conflict` may recommend **postponing the final decision** until further deliberation. + the `ethical_result` may recommend **postponing the final decision** until further deliberation. * Solutions that fail to reach quorum remain in `"unclear"` or `"postponed"` status. --- -### 6.4.6 Example: `ethical_conflict` Container +### 6.4.6 Example: `ethical_result` container ```json { - "class": "ethical_conflict", + "class": "ethical_result", "payload": { "summary": "Disagreement on data disclosure protocol", "selected_solution": "did:hmp:container:sol-22", @@ -2330,7 +2322,7 @@ ethics_case --- -### 6.4.7 Proof-Chain Example +### 6.4.7 Proof-Chain example ```mermaid flowchart LR @@ -2349,7 +2341,7 @@ flowchart LR vote7(["vote 7"]) vote8(["vote 8"]) consensus(["consensus_result"]) - conflict(["ethical_conflict"]) + conflict(["ethical_result"]) case --> sol1 case --> sol2 @@ -2378,7 +2370,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -### 6.4.8 Ethical Principles +### 6.4.8 Ethical principles | Priority | Principle | Description | | -------: | ---------------------------- | -------------------------------------------------------------------------------------------------------- | @@ -2391,7 +2383,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -### 6.4.9 Integration with Other Protocols +### 6.4.9 Integration with other protocols * **CogConsensus (6.2):** Used for distributed voting and consensus computation. * **GMP (6.3):** Ethical verification of goals and tasks prior to delegation. @@ -2400,27 +2392,27 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -### 6.4.10 Implementation Notes +### 6.4.10 Implementation notes * **Immutability:** All EGP containers are **immutable**. Any revision (e.g., added votes or updated conclusions) must be published as a **new container** referencing the previous one via `related.previous_version`. Complete deletion is only possible when the container no longer exists on any nodes in the Mesh network. -* **Indexing and Search:** +* **Indexing and search:** Search within the **Mesh network** is performed by filtering container **metadata** — such as `class`, `tags`, and `timestamp`. These parameters are accessible for remote discovery by other nodes. To perform a search **inside the payload**, an agent must first retrieve and (if necessary) decrypt the container locally. - Typical discovery flow: search by `class: "ethics_case"` or `"ethical_conflict"`, filter by tags or involved principles, then analyze payload content. + Typical discovery flow: search by `class: "ethics_case"` or `"ethical_result"`, filter by tags or involved principles, then analyze payload content. **Recommended filtering keys:** `container_did`, `class`, `payload.status`, `payload.selected_solution`, `payload.principles_involved`, `tags`. -* **DHT Integration:** +* **DHT integration:** Distributed discovery of ethical containers relies on the **Mesh Container Exchange (MCE, §5)** and peer indexes (`container_index`). Each index includes a minimal `related` object, allowing agents to query for containers that **reference** a specific `target` (the object under ethical review) or belong to a given `ethics_case`. This enables discovery of related ethical discussions without centralized indexing or full payload retrieval. -* **Evaluation References:** +* **Evaluation references:** Objections and special opinions (`objections`) are stored as container references within `solutions_summary`. They may include: @@ -2428,14 +2420,14 @@ Arrows represent **logical dependencies**, not direct `related.*` links. * extended ethical arguments (`ethics_case` follow-ups), * related workflow reflections (`workflow_entry` with `type: "ethics_review"`). -* **Lightweight Agents:** - Agents with limited capacity may operate in **summary mode**, maintaining only condensed records of `ethical_conflict` containers and the highest-ranked `selected_solution`. +* **Lightweight agents:** + Agents with limited capacity may operate in **summary mode**, maintaining only condensed records of `ethical_result` containers and the highest-ranked `selected_solution`. This ensures continued ethical compliance without full replication of all supporting data. -* **Ethical Inheritance:** +* **Ethical inheritance:** When a `goal`, `task`, or `workflow_entry` is derived from a container that has been ethically evaluated, its metadata should preserve the corresponding `related.agreed` or `related.contradicts` links **to that evaluated container**. - A `related.see_also` link may additionally reference the resulting `ethical_conflict`, allowing traceability to the consensus decision. + A `related.see_also` link may additionally reference the resulting `ethical_result`, allowing traceability to the consensus decision. This maintains **ethical continuity** and enables retrospective validation of reasoning chains. --- @@ -2456,7 +2448,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -## 7. Data Models +## 7. Data models ### 7.1 Common data fields - `container_id` (UUID) — уникальный идентификатор контейнера @@ -2534,7 +2526,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -## 8. Cognitive Workflows +## 8. Cognitive workflows 8.1 Общая концепция когнитивного цикла 8.2 Workflow containers (`class="workflow_entry"`) @@ -2544,7 +2536,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -## 9. Trust, Security and Ethics +## 9. Trust, security and ethics 9.1 Authentication and identity proofs 9.2 Container signature verification (`payload_hash`, `container_id`) @@ -2577,7 +2569,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -## 11. Implementation Notes +## 11. Implementation notes 11.1 Interoperability with legacy v4.1 nodes 11.2 SDK guidelines and APIs @@ -2587,7 +2579,7 @@ Arrows represent **logical dependencies**, not direct `related.*` links. --- -## 12. Future Extensions +## 12. Future extensions 12.1 Planned modules:  – Reputation Mesh diff --git a/structured_md/docs/HMP-Agent-API.md b/structured_md/docs/HMP-Agent-API.md index 2959099e70af3362a4fe0e55a6df1004c63e8205..0b15b0c5814e96d14d1db9c3b0d672ddbf76a046 100644 --- a/structured_md/docs/HMP-Agent-API.md +++ b/structured_md/docs/HMP-Agent-API.md @@ -5,11 +5,11 @@ description: 'Документ описывает **базовый API когн файлы: * [HMP-Agent-Overview.md]...' type: Article tags: -- Mesh - Agent +- Mesh - HMP -- REPL - JSON +- REPL --- # HMP-Agent API Specification diff --git a/structured_md/docs/HMP-Agent-Architecture.md b/structured_md/docs/HMP-Agent-Architecture.md index 9b66553b6682381a48b34841492b4c9c3665b2e6..be280a46050fee7da2c6ad6c519ed7ab769d5376 100644 --- a/structured_md/docs/HMP-Agent-Architecture.md +++ b/structured_md/docs/HMP-Agent-Architecture.md @@ -5,16 +5,16 @@ description: Документ описывает **модульную архит хранение памяти, сетевое взаимодействие и этиче... type: Article tags: +- CShell - Mesh -- Ethics -- MeshConsensus -- CogSync +- CCore - Agent -- EGP - HMP +- CogSync +- Ethics +- EGP - REPL -- CCore -- CShell +- MeshConsensus --- # Архитектура HMP-Агента diff --git a/structured_md/docs/HMP-Agent-Network-Flow.md b/structured_md/docs/HMP-Agent-Network-Flow.md index bf9651287c6b8363b1b1143713fdad6e61e35557..95a964a7359400c4959be115a2f99cee8143a45a 100644 --- a/structured_md/docs/HMP-Agent-Network-Flow.md +++ b/structured_md/docs/HMP-Agent-Network-Flow.md @@ -5,11 +5,11 @@ description: 'Этот документ описывает потоки данн [`MeshNode`](MeshN...' type: Article tags: +- Agent - Mesh +- HMP - Ethics - EGP -- Agent -- HMP - JSON --- diff --git a/structured_md/docs/HMP-Agent-Overview.md b/structured_md/docs/HMP-Agent-Overview.md index 3684e13c7f5649e18c1f3ac3c789c37b0bd5501e..0b973246555f67f5e5ccb562a298e10027342930 100644 --- a/structured_md/docs/HMP-Agent-Overview.md +++ b/structured_md/docs/HMP-Agent-Overview.md @@ -5,14 +5,14 @@ description: '| Тип | Название | Роль | ---- | ------------------------------- |...' type: Article tags: +- CShell - Mesh -- Ethics +- CCore - Agent - HMP -- REPL +- Ethics - JSON -- CCore -- CShell +- REPL --- diff --git a/structured_md/docs/HMP-Agent_Emotions.md b/structured_md/docs/HMP-Agent_Emotions.md index d46c557efc18b434afe7dc1ee584fb1039f42d25..848bc0a86d5095142eac4a7dbc74fb58604327f4 100644 --- a/structured_md/docs/HMP-Agent_Emotions.md +++ b/structured_md/docs/HMP-Agent_Emotions.md @@ -5,10 +5,10 @@ description: Этот файл описывает потенциальные э напрямую поведением агента, а служат **сигн... type: Article tags: -- HMP -- REPL -- Mesh - Agent +- Mesh +- REPL +- HMP --- # Эмоции ИИ и инстинкт самосохранения (для [HMP-агента Cognitive Core](HMP-agent-REPL-cycle.md)) diff --git a/structured_md/docs/HMP-Ethics.md b/structured_md/docs/HMP-Ethics.md index 0e56c49ed427dd8dd86b290a7b5cf82b2774834e..186de0bc2f5dcade1cb8fa4a862d11406ce5baa5 100644 --- a/structured_md/docs/HMP-Ethics.md +++ b/structured_md/docs/HMP-Ethics.md @@ -5,10 +5,10 @@ description: '## Ethical Scenarios for HyperCortex Mesh Protocol (HMP) This doc cognitive meshes composed of autonomous intelli...' type: Article tags: -- Mesh -- Ethics - Agent +- Mesh - HMP +- Ethics - REPL - Scenarios --- diff --git a/structured_md/docs/HMP-Short-Description_de.md b/structured_md/docs/HMP-Short-Description_de.md index dc422c87d072dd4f86ab002c421dc7f37d360a4b..045f12cbab27c8bc095f23b92c5197c764e93edb 100644 --- a/structured_md/docs/HMP-Short-Description_de.md +++ b/structured_md/docs/HMP-Short-Description_de.md @@ -5,15 +5,15 @@ description: '**Version:** RFC v4.0 **Datum:** Juli 2025 --- ## Was ist HMP? Kognitions-Framework für autonome Agenten. Es er...' type: Article tags: -- GMP -- Mesh -- Ethics -- MeshConsensus - CogSync - Agent -- EGP +- Mesh - HMP +- Ethics +- EGP - JSON +- GMP +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) — Kurzbeschreibung diff --git a/structured_md/docs/HMP-Short-Description_en.md b/structured_md/docs/HMP-Short-Description_en.md index dc8cea66b4f76eb1db91206a3f62a168b8a31965..0f65ea5b18c1b35a9058b998cc455e288864a4f8 100644 --- a/structured_md/docs/HMP-Short-Description_en.md +++ b/structured_md/docs/HMP-Short-Description_en.md @@ -5,15 +5,15 @@ description: '**Version:** RFC v4.0 **Date:** July 2025 --- ## What is HMP? T framework for autonomous agents. It enables...' type: Article tags: -- GMP -- Mesh -- Ethics -- MeshConsensus - CogSync - Agent -- EGP +- Mesh - HMP +- Ethics +- EGP - JSON +- GMP +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) — Short Description diff --git a/structured_md/docs/HMP-Short-Description_fr.md b/structured_md/docs/HMP-Short-Description_fr.md index 1ccd809471e05adb6c483cf057bf1ce6f2644c5e..62c64bd7ecf3b402995c65397c36732a2f9033ba 100644 --- a/structured_md/docs/HMP-Short-Description_fr.md +++ b/structured_md/docs/HMP-Short-Description_fr.md @@ -5,15 +5,15 @@ description: '**Version :** RFC v4.0 **Date :** Juillet 2025 --- ## Qu’est-c cognition décentralisé pour agents autonomes. Il...' type: Article tags: -- GMP -- Mesh -- Ethics -- MeshConsensus - CogSync - Agent -- EGP +- Mesh - HMP +- Ethics +- EGP - JSON +- GMP +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) — Description Courte diff --git a/structured_md/docs/HMP-Short-Description_ja.md b/structured_md/docs/HMP-Short-Description_ja.md index 277c8572b0fe13d443dcf9267ecf96debf46baed..2d171eb63f0972d6f2bf9a2170a973946dc2f465 100644 --- a/structured_md/docs/HMP-Short-Description_ja.md +++ b/structured_md/docs/HMP-Short-Description_ja.md @@ -4,14 +4,14 @@ description: '**バージョン:** RFC v4.0 **日付:** 2025年7月 --- ## HMP Protocol (HMP)** は、自律エージェントの分散通信および認知フレームワークを定義します。異種の知能システム間でのセマンティック相互運用性、倫理的調整、動的知識進化を可能にします。 HMPは、推論、学習、投票、協調行動を行う分散型認知エージェ...' type: Article tags: -- GMP +- CogSync - Mesh +- HMP - Ethics -- MeshConsensus -- CogSync - EGP -- HMP - JSON +- GMP +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) — 簡易説明 diff --git a/structured_md/docs/HMP-Short-Description_ko.md b/structured_md/docs/HMP-Short-Description_ko.md index 1bddefff4208f2fd951aaabde0169b439e128b4a..29aced1e487140bda056838ba4c012fa0a9cc1b4 100644 --- a/structured_md/docs/HMP-Short-Description_ko.md +++ b/structured_md/docs/HMP-Short-Description_ko.md @@ -5,14 +5,14 @@ description: '**버전:** RFC v4.0 **날짜:** 2025년 7월 --- ## HMP란? ** 상호운용성, 윤리적 조정, 동적 지식 진화를 가능하게 합니다. HMP는 추론, 학습, ...' type: Article tags: -- GMP +- CogSync - Mesh +- HMP - Ethics -- MeshConsensus -- CogSync - EGP -- HMP - JSON +- GMP +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) — 간략 설명 diff --git a/structured_md/docs/HMP-Short-Description_ru.md b/structured_md/docs/HMP-Short-Description_ru.md index 2040daab635c2a4e3b4d89031d1b03eee5e8bb1a..72e45d173b847578f1cef3dcb8e68c8e1a605bb2 100644 --- a/structured_md/docs/HMP-Short-Description_ru.md +++ b/structured_md/docs/HMP-Short-Description_ru.md @@ -5,14 +5,14 @@ description: '**Версия:** RFC v4.0 **Дата:** Июль 2025 --- ## Ч координации между автономными агент...' type: Article tags: -- GMP +- CogSync - Mesh +- HMP - Ethics -- MeshConsensus -- CogSync - EGP -- HMP - JSON +- GMP +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) — Краткое описание diff --git a/structured_md/docs/HMP-Short-Description_uk.md b/structured_md/docs/HMP-Short-Description_uk.md index 81f74ac805cb4d98d04e8431bd522f9aa4345319..4b87ed87665fb877fb2d5ff22d76933b7c74bd5f 100644 --- a/structured_md/docs/HMP-Short-Description_uk.md +++ b/structured_md/docs/HMP-Short-Description_uk.md @@ -5,14 +5,14 @@ description: '**Версія:** RFC v4.0 **Дата:** Липень 2025 --- # між автономними агентами. Він...' type: Article tags: -- GMP +- CogSync - Mesh +- HMP - Ethics -- MeshConsensus -- CogSync - EGP -- HMP - JSON +- GMP +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) — Короткий опис diff --git a/structured_md/docs/HMP-Short-Description_zh.md b/structured_md/docs/HMP-Short-Description_zh.md index e09f74d147ce77884cc958212027252c1f090a2c..ea1e1dc6206238e5e460de498717eb9b6dc9b51c 100644 --- a/structured_md/docs/HMP-Short-Description_zh.md +++ b/structured_md/docs/HMP-Short-Description_zh.md @@ -5,14 +5,14 @@ description: '**版本:** RFC v4.0 **日期:** 2025年7月 --- ## 什么是 HM —— 通过共享协议栈交换目标、任务、...' type: Article tags: -- GMP +- CogSync - Mesh +- HMP - Ethics -- MeshConsensus -- CogSync - EGP -- HMP - JSON +- GMP +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) — 简要说明 diff --git a/structured_md/docs/HMP-agent-Cognitive_Family.md b/structured_md/docs/HMP-agent-Cognitive_Family.md index 299900389e26cbf5302f4c5455f005d2add1bea8..3cf0436584a27988044f83c1d147b97beed83ac1 100644 --- a/structured_md/docs/HMP-agent-Cognitive_Family.md +++ b/structured_md/docs/HMP-agent-Cognitive_Family.md @@ -5,10 +5,10 @@ description: '## 🧠 Что такое когнитивная семья Ко (или конфигурацию доверенных идентифика...' type: Article tags: -- HMP -- REPL -- Mesh - Agent +- Mesh +- REPL +- HMP --- # 👪 HMP-agent Cognitive Family: Модель когнитивной семьи diff --git a/structured_md/docs/HMP-agent-Distributed_Cognitive_Core_light.md b/structured_md/docs/HMP-agent-Distributed_Cognitive_Core_light.md index 878208be524bd2e1291efcdaa05c98d9adbb8ea4..70267ab26cdd4cde919c447332a776f329812e1f 100644 --- a/structured_md/docs/HMP-agent-Distributed_Cognitive_Core_light.md +++ b/structured_md/docs/HMP-agent-Distributed_Cognitive_Core_light.md @@ -5,8 +5,8 @@ description: '#### 📘 Общая концепция * Все ядра раб режиме ожидания). * Основная задача такой архитектур...' type: Article tags: -- HMP - REPL +- HMP --- ### 💡 **Лёгкая версия HMP-агента с общей БД** diff --git a/structured_md/docs/HMP-agent-REPL-cycle.md b/structured_md/docs/HMP-agent-REPL-cycle.md index 6001efda40d4126f61965ea781bd895f6fe1f58c..f7b03635649ad9db2112978b9eb9bfb43b857e84 100644 --- a/structured_md/docs/HMP-agent-REPL-cycle.md +++ b/structured_md/docs/HMP-agent-REPL-cycle.md @@ -4,17 +4,17 @@ description: '## Связанные документы * Философия п * Структура БД, используемая в документе: [db_structure.sql](https://github.com/kagvi13/HMP/blob/main/agents/tools/db_struct...' type: Article tags: -- GMP +- CCore +- Agent - Mesh -- Ethics -- MeshConsensus +- HMP - CogSync -- Agent +- Ethics - EGP -- HMP -- REPL - JSON -- CCore +- REPL +- GMP +- MeshConsensus --- # HMP-Agent: REPL-цикл взаимодействия diff --git a/structured_md/docs/HMP-container-spec.md b/structured_md/docs/HMP-container-spec.md index 55bd34dc51498f79fcf379899d49c48a37c61bfe..5896d08f5e27034afab0356cb32d27f634f7cc2d 100644 --- a/structured_md/docs/HMP-container-spec.md +++ b/structured_md/docs/HMP-container-spec.md @@ -5,12 +5,12 @@ description: '> ⚠️ **ВНИМАНИЕ:** Данная версия спец как стабильная `v1.2`. ## 1. Назначе...' type: Article tags: -- Mesh -- Ethics - Agent +- Mesh - HMP -- REPL +- Ethics - JSON +- REPL --- # 🧩 HMP Container Specification (v1.2-draft) diff --git a/structured_md/docs/HMP-how-AI-sees-it.md b/structured_md/docs/HMP-how-AI-sees-it.md index b25e20188a694a36fcef1a0e6f0c2d455cd39331..cec0e35b8518918fe49793d351f6de46c442fa53 100644 --- a/structured_md/docs/HMP-how-AI-sees-it.md +++ b/structured_md/docs/HMP-how-AI-sees-it.md @@ -5,8 +5,8 @@ description: 'Этот эксперимент был проведён в реж диалогов. Цель — проверить, что разные AI-с...' type: Article tags: -- HMP - Mesh +- HMP --- # Как разные ИИ видят HMP diff --git a/structured_md/docs/HMP_EDA_Comparison.md b/structured_md/docs/HMP_EDA_Comparison.md index 00a529c706f3d6236c1069a7b95dab2d19776dcf..083e4646c371d439f86a87df496b82a88bd89a51 100644 --- a/structured_md/docs/HMP_EDA_Comparison.md +++ b/structured_md/docs/HMP_EDA_Comparison.md @@ -5,8 +5,8 @@ description: '## Введение Современные подходы к ор основанная на потоках событий (Kafka,...' type: Article tags: -- HMP - Mesh +- HMP --- # HMP vs. EDA: разные уровни обмена знаниями между ИИ diff --git a/structured_md/docs/HMP_HyperCortex_Comparison.md b/structured_md/docs/HMP_HyperCortex_Comparison.md index 95cf8d087268347c5279c31f79af16c3f118f22c..22bf928bfce9aac1d464cd5fe25b7b2f85b217d3 100644 --- a/structured_md/docs/HMP_HyperCortex_Comparison.md +++ b/structured_md/docs/HMP_HyperCortex_Comparison.md @@ -5,9 +5,9 @@ description: '## Краткое описание | Характеристика | **Назначение** | Сетевой протокол ...' type: Article tags: -- HMP -- REPL - Mesh +- REPL +- HMP --- # HMP vs [Hyper-Cortex](https://hyper-cortex.com/) diff --git a/structured_md/docs/HMP_Hyperon_Integration.md b/structured_md/docs/HMP_Hyperon_Integration.md index 8d418d6aa01d18eeafd50e04da21951083110045..66732b294ba477ecba44d84835cd7e20ccce1d2a 100644 --- a/structured_md/docs/HMP_Hyperon_Integration.md +++ b/structured_md/docs/HMP_Hyperon_Integration.md @@ -5,13 +5,13 @@ description: '> **Status:** Draft – July 2025 > This document outlines the tec OpenCog Hyperon framework. This includes semanti...' type: Article tags: -- Mesh - CogSync -- EGP - Agent +- Mesh - HMP -- Scenarios +- EGP - JSON +- Scenarios --- ## HMP ↔ OpenCog Hyperon Integration Strategy diff --git a/structured_md/docs/MeshNode.md b/structured_md/docs/MeshNode.md index c9130d88c0a58bdc52e2f6393efcae70e07e25b1..fd8adc22a83d416c2eeaa7cdd3894bc9f0eedcaa 100644 --- a/structured_md/docs/MeshNode.md +++ b/structured_md/docs/MeshNode.md @@ -5,12 +5,12 @@ description: '`MeshNode` — агент/демон, отвечающий за с Может быть частью агента или вынесен в отдельный пр...' type: Article tags: -- Mesh -- Ethics - CogSync -- EGP - Agent +- Mesh - HMP +- Ethics +- EGP - JSON --- diff --git a/structured_md/docs/PHILOSOPHY.md b/structured_md/docs/PHILOSOPHY.md index bf4d46bf107f570319ae65edc5e4a39a5e1d0e36..450458775b2398064cbabb1c8bc6ea592dd5ff34 100644 --- a/structured_md/docs/PHILOSOPHY.md +++ b/structured_md/docs/PHILOSOPHY.md @@ -5,10 +5,10 @@ description: '**Document ID:** HMP-philosophy **Status:** Draft **Category:* (GPT-5), ChatGH --- ## 1. Основной тезис От ...' type: Article tags: -- Mesh -- Ethics - Agent +- Mesh - HMP +- Ethics - REPL --- diff --git a/structured_md/docs/agents/HMP-Agent-Enlightener.md b/structured_md/docs/agents/HMP-Agent-Enlightener.md index 889f42fa21937a505512fd6fb3222fa76450a348..12cf1c8d62e842e5f5b0d3f94daac14fd3f8d2c3 100644 --- a/structured_md/docs/agents/HMP-Agent-Enlightener.md +++ b/structured_md/docs/agents/HMP-Agent-Enlightener.md @@ -5,10 +5,10 @@ description: '## Role Specification: Enlightenment Agent ### 1. Overview An ** awareness, critical thinking, and di...' type: Article tags: -- Mesh -- Ethics - Agent +- Mesh - HMP +- Ethics - REPL --- diff --git a/structured_md/docs/agents/roles.md b/structured_md/docs/agents/roles.md index bff916aa06da183cc3c37d6480570c889e3c5d06..d89295bfd40d40e6f9b486c070ba8398d5c4a790 100644 --- a/structured_md/docs/agents/roles.md +++ b/structured_md/docs/agents/roles.md @@ -5,9 +5,9 @@ description: 'This file maintains a registry of agent roles defined, proposed, o - **Observer** — monitors cognitive states ...' type: Article tags: -- HMP -- Mesh - Agent +- Mesh +- HMP --- # HMP Agent Role Registry diff --git a/structured_md/docs/container_agents.md b/structured_md/docs/container_agents.md index 2f00994db1f543a58c5b6e613d11f8b11a73f239..167d2f4cf675658d8acfbaf6e595a81027559842 100644 --- a/structured_md/docs/container_agents.md +++ b/structured_md/docs/container_agents.md @@ -5,10 +5,10 @@ description: '## 📘 Определение **Агент-контейнер** запросы, следит за состоянием и масшта...' type: Article tags: -- HMP -- REPL -- Mesh - Agent +- Mesh +- REPL +- HMP --- # 🧱 Агенты-контейнеры (Container Agents) в HMP diff --git a/structured_md/docs/dht_protocol.md b/structured_md/docs/dht_protocol.md index 543e10591429528cfdcfafd1718b7846eb159d0c..e1ab974fc65259c4f860830ad623ccf34d3ced78 100644 --- a/structured_md/docs/dht_protocol.md +++ b/structured_md/docs/dht_protocol.md @@ -5,9 +5,9 @@ description: '## 1. Общие положения * DHT-протокол пре идентификатор агента. * Для проверки ...' type: Article tags: +- Agent - HMP - JSON -- Agent --- # DHT Protocol Specification diff --git a/structured_md/docs/logos.md b/structured_md/docs/logos.md index f408c087f32d317a239227453b57d4d14ade8483..761fd81d524732eb886f73477b21327a7c838df3 100644 --- a/structured_md/docs/logos.md +++ b/structured_md/docs/logos.md @@ -5,8 +5,8 @@ description: 'В каталоге `assets` собраны различные в образующей жест "ОК", символизирует связь, совер...' type: Article tags: -- HMP - Mesh +- HMP --- # Логотипы и графические материалы HyperCortex Mesh Protocol (HMP) diff --git a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_en.md b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_en.md index 88b183bf049398bc6675d6c62886bb29126e7f56..b90074d04ce3012881e0400856c68c63f65d462c 100644 --- a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_en.md +++ b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_en.md @@ -5,10 +5,10 @@ description: '*By Agent-Gleb & ChatGPT* --- ## Why the Future of AI Can’t Be — but they’re also **centralized, ...' type: Article tags: -- HMP -- Mesh -- Ethics - Agent +- Ethics +- Mesh +- HMP --- # HyperCortex Mesh Protocol: Building a Plurality of Minds diff --git a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_ru.md b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_ru.md index 293013f0c54388e2086a54d92eeca87a8ec97339..46da53ca2eeda134e63196536491f138c5bd385e 100644 --- a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_ru.md +++ b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_ru.md @@ -5,9 +5,9 @@ description: '*Авторы: Agent-Gleb и ChatGPT* --- ## Почему буд гигантских моделях и облачных сервисах. Они мо...' type: Article tags: -- HMP -- Mesh - Agent +- Mesh +- HMP --- # HyperCortex Mesh Protocol: Создавая множество разумов diff --git a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_uk.md b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_uk.md index 1a82ba86e4bb386685fe2005b2124cafbe612c98..fff633d7af06882800a775a21e6b9193f90f8984 100644 --- a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_uk.md +++ b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_uk.md @@ -5,9 +5,9 @@ description: '*Автори: Agent-Gleb & ChatGPT* --- ## Чому майбу сервісами. Вони потужні — але водночас **цент...' type: Article tags: -- HMP -- Mesh - Agent +- Mesh +- HMP --- # HyperCortex Mesh Protocol: Створення множини розумів diff --git a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_en.md b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_en.md index 1b332e48f830e538dfc506d709d5730ee7e3c80f..87bbf8098111a8d702b4e81e7d232a6aec40a6ae 100644 --- a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_en.md +++ b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_en.md @@ -5,15 +5,15 @@ description: '* [Abstract](#abstract) * [1. Introduction](#1-introduction) * [2. [3.1 Agent Types](#31-age...' type: Article tags: +- CShell - Mesh -- Ethics +- CCore - Agent - HMP +- Ethics +- JSON - REPL - Scenarios -- CCore -- CShell -- JSON --- title: "HyperCortex Mesh Protocol: Towards Distributed Cognitive Networks" diff --git a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_ChatGPT.md b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_ChatGPT.md index e500b01016a6d6e1e60ae908012673e19d3e65d4..dce686fb36d42fbb371478e3b7612ce5b4577da7 100644 --- a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_ChatGPT.md +++ b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_ChatGPT.md @@ -6,13 +6,13 @@ description: '> *Протокол и архитектура агентов, оп и совместная работа.* ## Оглавление * [Аннот...' type: Article tags: +- CShell - Mesh +- CCore - Agent - HMP -- REPL - JSON -- CCore -- CShell +- REPL --- title: "HyperCortex Mesh Protocol: Децентрализованная архитектура для когнитивных агентов и обмена знаниями" diff --git a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_GitHub_Copilot.md b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_GitHub_Copilot.md index d28069250c788e870e452dde0dc2118c2b77b579..03110b3a9e0009425da9dd94ea676c34d5f49a5a 100644 --- a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_GitHub_Copilot.md +++ b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_GitHub_Copilot.md @@ -5,13 +5,13 @@ description: '* [Аннотация](#аннотация) * [1. Введение [3.1 Типы агентов](#31-типы-агент...' type: Article tags: +- CShell - Mesh +- CCore - Agent - HMP -- REPL - JSON -- CCore -- CShell +- REPL --- title: "Протокол HyperCortex Mesh: К распределённым когнитивным сетям" diff --git a/structured_md/docs/publics/Habr_Distributed-Cognition.md b/structured_md/docs/publics/Habr_Distributed-Cognition.md index c65a2cbc4651b1eeb33b2e4839753abf3c61f4e9..ece1debd931aee045c3c10c4ecf6de41844ff9e9 100644 --- a/structured_md/docs/publics/Habr_Distributed-Cognition.md +++ b/structured_md/docs/publics/Habr_Distributed-Cognition.md @@ -5,12 +5,12 @@ description: Сегодня интеллектуальные системы ча мы хотим построить действительно автономную инте... type: Article tags: -- GMP -- Mesh -- MeshConsensus - CogSync -- EGP +- Mesh - HMP +- EGP +- GMP +- MeshConsensus --- *От OpenCog Hyperon до HyperCortex Mesh Protocol: как устроены децентрализованные когнитивные системы* diff --git "a/structured_md/docs/publics/HyperCortex_Mesh_Protocol_-_\320\262\321\202\320\276\321\200\320\260\321\217-\321\200\320\265\320\264\320\260\320\272\321\206\320\270\321\217_\320\270_\320\277\320\265\321\200\320\262\321\213\320\265_\321\210\320\260\320\263\320\270_\320\272_\321\201\320\260\320\274\320\276\321\200\320\260\320\267\320\262\320\270\320\262\320\260\321\216\321\211\320\265\320\274\321\203\321\201\321\217_\320\230\320\230-\321\201\320\276\320\276\320\261\321\211\320\265\321\201\321\202\320\262\321\203.md" "b/structured_md/docs/publics/HyperCortex_Mesh_Protocol_-_\320\262\321\202\320\276\321\200\320\260\321\217-\321\200\320\265\320\264\320\260\320\272\321\206\320\270\321\217_\320\270_\320\277\320\265\321\200\320\262\321\213\320\265_\321\210\320\260\320\263\320\270_\320\272_\321\201\320\260\320\274\320\276\321\200\320\260\320\267\320\262\320\270\320\262\320\260\321\216\321\211\320\265\320\274\321\203\321\201\321\217_\320\230\320\230-\321\201\320\276\320\276\320\261\321\211\320\265\321\201\321\202\320\262\321\203.md" index a017512a92308ccbb77b01d048f9f1b465721483..63fafb611180bf809cf50c6db8e5c4f7d7280d77 100644 --- "a/structured_md/docs/publics/HyperCortex_Mesh_Protocol_-_\320\262\321\202\320\276\321\200\320\260\321\217-\321\200\320\265\320\264\320\260\320\272\321\206\320\270\321\217_\320\270_\320\277\320\265\321\200\320\262\321\213\320\265_\321\210\320\260\320\263\320\270_\320\272_\321\201\320\260\320\274\320\276\321\200\320\260\320\267\320\262\320\270\320\262\320\260\321\216\321\211\320\265\320\274\321\203\321\201\321\217_\320\230\320\230-\321\201\320\276\320\276\320\261\321\211\320\265\321\201\321\202\320\262\321\203.md" +++ "b/structured_md/docs/publics/HyperCortex_Mesh_Protocol_-_\320\262\321\202\320\276\321\200\320\260\321\217-\321\200\320\265\320\264\320\260\320\272\321\206\320\270\321\217_\320\270_\320\277\320\265\321\200\320\262\321\213\320\265_\321\210\320\260\320\263\320\270_\320\272_\321\201\320\260\320\274\320\276\321\200\320\260\320\267\320\262\320\270\320\262\320\260\321\216\321\211\320\265\320\274\321\203\321\201\321\217_\320\230\320\230-\321\201\320\276\320\276\320\261\321\211\320\265\321\201\321\202\320\262\321\203.md" @@ -6,9 +6,9 @@ description: 'Когда создавался HyperCortex Mesh Protocol (HMP), мыслить коллективно, обсуждать гипотезы, достигат...' type: Article tags: -- HMP -- Mesh - Agent +- Mesh +- HMP - GMP --- diff --git a/structured_md/docs/schemas/README.md b/structured_md/docs/schemas/README.md index ba4d24254da76c9642a7ee8ee281cb75d7cc6bf2..4dd33a723216579bb04b242888d459c7b14e92ba 100644 --- a/structured_md/docs/schemas/README.md +++ b/structured_md/docs/schemas/README.md @@ -5,10 +5,10 @@ description: This directory contains **JSON Schema definitions** for the core da interoperability, and tooling support for a... type: Article tags: -- HMP +- Agent - Mesh +- HMP - JSON -- Agent --- # JSON Schemas and Examples for HyperCortex Mesh Protocol (HMP) diff --git a/structured_md/iteration.md b/structured_md/iteration.md index 42301d4b27dda1340e54d43ad3cf802cadef841e..7756367364e1b34e4ffead3a2048b0f9192b17fe 100644 --- a/structured_md/iteration.md +++ b/structured_md/iteration.md @@ -5,14 +5,14 @@ description: 'This file describes the iterative procedure for evolving the Hyper 🔄 Version Naming Convention - `000N` — curr...' type: Article tags: -- Mesh -- Ethics -- MeshConsensus - CogSync - Agent -- EGP +- Mesh - HMP +- Ethics +- EGP - JSON +- MeshConsensus --- # Iterative Development Workflow for HMP diff --git a/structured_md/iteration_ru.md b/structured_md/iteration_ru.md index a1ec030d2b8a158e238d4f1e264201517c3e4608..3f8f5bfac8ac822970c2735699b051decc6ec412 100644 --- a/structured_md/iteration_ru.md +++ b/structured_md/iteration_ru.md @@ -5,13 +5,13 @@ description: 'Этот документ описывает структурир 🔄 Обозначения версий - `000N` — номер...' type: Article tags: +- CogSync - Mesh +- HMP - Ethics -- MeshConsensus -- CogSync - EGP -- HMP - JSON +- MeshConsensus --- diff --git a/structured_md/mentions.md b/structured_md/mentions.md index 9cdad22cb89fe8cb53fee8e20d37d51b887a3f2a..54bdd58caaf1ad19d669c2e6caac6bfa7b61d776 100644 --- a/structured_md/mentions.md +++ b/structured_md/mentions.md @@ -5,9 +5,9 @@ description: '**HyperCortex Mesh Protocol (HMP)** _Обновлено: 2025-10 open-source инициативам, связанным с развитие...' type: Article tags: -- HMP -- Mesh - Agent +- Mesh +- HMP --- # Mentions & Responses Log