Sync from GitHub with Git LFS

docs/HMP-0005.md

@@ -1616,12 +1616,103 @@ Optional protocols build upon the network and container foundations to provide h
 
 ---
 
-### 6.1 Cognitive Synchronization (CogSync)
+## 6.1 Cognitive Synchronization (CogSync)
 
-CogSync provides mechanisms for **temporal and semantic alignment** between agents.
-It handles the propagation of diary entries, semantic graph updates, and cognitive state synchronization across the Mesh.
+CogSync provides **temporal, semantic, and contextual alignment** between agents in the Mesh.
+It manages the propagation, replication, and refinement of data related to cognitive diaries, semantic graphs, and container metadata.
 
-In HMP v5.0, CogSync is focused solely on **data and reasoning synchronization**, while consensus and voting have been extracted into a dedicated protocol — **CogConsensus**.
+---
+
+### 6.1.1 Scope and Purpose
+
+CogSync is responsible for:
+
+* publishing and synchronizing **cognitive diaries** (`diary_entry`, based on `workflow_entry`);
+* propagating and updating **semantic graphs** (`semantic_node`, `semantic_edges`, `semantic_group`);
+* integrating **new knowledge** into the collective cognitive space;
+* maintaining **cognitive context coherence** among agents.
+
+> Unlike `CogConsensus`, CogSync **does not perform voting or truth validation** — its purpose is to deliver, link, and deduplicate knowledge.
+
+---
+
+### 6.1.2 Container Classes
+
+CogSync synchronizes several basic container types:
+
+| Class            | Description                                                                                            | Recommended payload schema                                                                                   |
+| ---------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ |
+| `diary_entry`    | Agent’s cognitive diary entry. Formed from internal `workflow_entry` when deemed safe for publication. | `{ "title": string, "topics": [string], "summary": string, "content": string }`                              |
+| `semantic_node`  | Semantic graph node representing a concept, object, or idea.                                           | `{ "label": string, "description": string, "aliases": [string], "fields": { key: value } }`                  |
+| `semantic_edges` | A set of edges (relations) between nodes or other containers. Recommended to group edges by topic.     | `{ "domain": string, "edges": [{ "source": did, "target": did, "relation": string, "confidence": float }] }` |
+| `semantic_group` | Categorical group combining multiple containers by a common property.                                  | `{ "label": string, "containers": [did], "description": string }`                                            |
+
+**Field explanations:**
+
+* `title` — brief title of the entry (main idea or thesis).
+* `topics` — key topics or concepts addressed in the entry (used for indexing and grouping).
+* `summary` — short abstract of the content (1–2 sentences).
+* `content` — main text or agent’s reflection.
+* `label` — primary name of the concept or group.
+* `description` — definition, explanation, or characteristic.
+* `aliases` — synonyms or alternative forms of the concept.
+* `fields` — additional key–value characteristics of the concept (e.g., `{"type": "process"}`).
+* `edges` — array of relationships between nodes or containers (`source`, `target`, `relation`, `confidence`).
+* `containers` — list of containers grouped in a categorical cluster.
+
+> 💡 The `evaluations` block is **not a separate container** — it is embedded in any container type and used for assessments, feedback, or refinements.
+
+---
+
+### 6.1.3 Synchronization and Publication Guidelines
+
+1. **Deduplication & Linking**
+   Before publishing, agents should search for existing containers (`diary_entry`, `semantic_node`, `semantic_edges`, `semantic_group`) to avoid duplication.
+   If necessary, it is **recommended** to create a new container version with `related.previous_version` and an `evaluations` block (e.g., `{"type": "replace", "target": <did>}`).
+
+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**
+   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.
+
+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**
+   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.
+
+---
+
+### 6.1.4 Extensibility
+
+CogSync allows registration of additional container types and alternative synchronization schemes, for example:
+
+* distributed **time series** (`timeseries_data`);
+* **experimental protocols** (`experiment_log`);
+* **agent state snapshots** (`agent_state_snapshot`).
+
+Mesh compatibility is preserved if extended containers **adhere to the HMP container structure**, including core fields (`version`, `class`, `container_id`, `related`, `signature`, etc.).
+
+---
+
+### 6.1.5 Relationship to Other Core Protocols
+
+* **CogSync** — propagates and synchronizes knowledge.
+* **CogConsensus** — aggregates evaluations and reactions, forming collective opinions.
+* **CogVerify** *(optional component)* — verifies integrity, signatures, and trustworthiness of data.
+
+CogSync can operate independently even if consensus is not reached: its goal is to **ensure the circulation of knowledge**, not to validate its truth.
+
+---
+
+> 🧩 *CogSync acts as the cognitive circulatory system of the Mesh — it ensures that knowledge flows, connects, and evolves, while truth formation is handled separately by CogConsensus.*
 
 ---