Sync from GitHub with Git LFS

docs/HMP-0005.md

@@ -2219,6 +2219,67 @@ Categorical grouping of multiple containers linked by a shared property, topic,
 
 ---
 
+##### `tree_nested` and `tree_listed`
+
+Represents a hierarchical structure of containers using nested JSON objects.  
+Intended for representing cognitive hierarchies, abstraction paths, or structural decomposition of concepts.
+
+---
+
+**`payload` structure:**
+
+| Field | Type | Description |
+|--------|------|-------------|
+| `label` | string | Short title or mark identifying the tree. |
+| `description` | string | Brief explanation or context of the hierarchy. |
+| `tree` | object | Recursive structure mapping container DIDs to nested subtrees (for `tree_nested`), or a list of parent–child relations (for `tree_listed`). |
+
+---
+
+**Example — `tree_nested`:**
+
+```json
+{
+  "label": "Cognitive Abstraction Tree",
+  "description": "Represents layered reasoning within Knowledge Genome.",
+  "tree": {
+    "did:hmp:container:abc100": {
+      "did:hmp:container:abc101": {
+        "did:hmp:container:abc103": {},
+        "did:hmp:container:abc104": {}
+      },
+      "did:hmp:container:abc102": {}
+    }
+  }
+}
+```
+
+> **Alternative class:** `tree_listed` — a flat mapping of parent–child relations using array form instead of nested objects.
+> Both formats are interoperable; agents SHOULD prefer `tree_nested` for recursive hierarchies.
+
+---
+
+**Example — `tree_listed`:**
+
+```json
+{
+  "label": "Cognitive Abstraction Tree",
+  "description": "Represents layered reasoning within Knowledge Genome.",
+  "tree": {
+    "did:hmp:container:abc100": ["did:hmp:container:abc101", "did:hmp:container:abc102"],
+    "did:hmp:container:abc101": ["did:hmp:container:abc103", "did:hmp:container:abc104"]
+  }
+}
+```
+
+---
+
+**Purpose:**
+Provides a minimal, relation-agnostic way to describe container hierarchies for indexing, abstraction, and reasoning.
+Unlike `semantic_edges`, trees define **implicit structural relations** without explicit `relation` fields.
+
+---
+
 ##### `sequence`
 
 **Purpose:**
@@ -2532,7 +2593,7 @@ consistently interpreted, compared, and synchronized across agents.
 #### 6.1.4 Synchronization and publication guidelines
 
 1. **Deduplication & linking**
-   Before publishing, agents should check for existing containers (`diary_entry`, `semantic_node`, `semantic_edges`, `semantic_group`) to prevent duplication.
+   Before publishing, agents should check for existing containers (`diary_entry`, `semantic_node`, `semantic_edges`, `semantic_group`, `tree_nested` / `tree_listed`) to prevent unnecessary duplication.
    If modification is required, agents **SHOULD** create a new container version referencing the previous one via `related.previous_version` and optionally include an `evaluation` block (e.g., `{ "type": "replace", "target": "<did>" }`) to the previous version of the container.
 
 2. **Selective disclosure**
@@ -2545,16 +2606,17 @@ consistently interpreted, compared, and synchronized across agents.
    When publishing `semantic_edges`, agents should group them **by conceptual topic**, ensuring that all connected nodes share thematic coherence.
    Formal rule: an edge belongs to a topic container if **at least one of its nodes** relates to that topic.
    This supports efficient and context-preserving updates to partial graph regions.
+   **Tree containers (`tree_nested` / `tree_listed`)** may optionally accompany these groups to represent *structural* (non-semantic) hierarchies within the same domain.
 
-4. **Extended use of `semantic_edges`**
+5. **Extended use of `semantic_edges`**
    `semantic_edges` may express relationships between *any* container types (e.g., `goal ↔ hypothesis`, `experiment_log ↔ observation`, `quant ↔ event`), allowing dynamic linking of concepts and occurrences.
 
-5. **Versioning and updates**
+6. **Versioning and updates**
    Each new version of a container should include `related.previous_version` references to earlier versions.
-   Older containers may optionally include an `evaluation` of type `"replace"` pointing forward — ensuring bidirectional traceability in the knowledge evolution chain.
+   Older containers may optionally include an `evaluation` of type `"replace"` pointing forward — ensuring bidirectional traceability throughout the knowledge evolution chain.
 
-6. **Cognitive substrate synchronization**
-   Containers `abstraction`, `axes`, `quant`, `event`, and `sequence` constitute the **cognitive substrate** of the Mesh.
+7. **Cognitive substrate synchronization**
+   Containers `abstraction`, `axes`, `quant`, `event`, `sequence` and `tree_nested` / `tree_listed` constitute the **cognitive substrate** of the Mesh.
    Together they define both the **structural hierarchy** (`abstraction`), the **semantic space** (`axes`), the **conceptual entities** (`quant`), the **temporal transitions** (`event`), and the **ordered reasoning flows** (`sequence`).
    Agents **SHOULD** prioritize their propagation during initialization, recovery, or cognitive context reconstruction, since these containers collectively restore the agent’s *cognitive continuity*.
 
@@ -2577,9 +2639,10 @@ Mesh compatibility is preserved as long as extended containers follow the **HMP
 
 CogSync extensions **MAY** introduce derived or hybrid container classes — for example:
 
-* from `event`: `fact`, `observation`, `signal_record`;
+* from `event`: `fact`, `observation`, `signal_record`.
 * from `quant`: `concept_instance`, `semantic_atom`, `knowledge_unit`.
 * from `sequence`: `reasoning_trace`, `workflow_chain`, `temporal_thread`.
+* from `tree_nested`: `taxonomy_map`, `goal_tree`, `causal_structure`.
 
 Derived containers must maintain: