Sync from GitHub with Git LFS

docs/HMP-0005.md

@@ -3036,7 +3036,64 @@ All evaluations are signed and verified locally.
 
 ---
 
-#### 6.2.3 Consensus computation
+#### 6.2.3 Container `vote`
+
+Represents an agent’s explicit stance toward another container (goal, task, ethics_solution, or proposal).  
+A `vote` container is **atomic** — one container expresses one agent’s position regarding one target container.
+
+```json
+{
+  "head": {
+    "class": "vote"
+  },
+  "payload": {
+    "target_did": "did:hmp:container:ethics_solution-4fba2",
+    "vote_value": 1,
+    "vote_type": "approval",
+    "reason": "Consistent with prior consensus and ethical policy E-17"
+  },
+  "related": {
+    "in_reply_to": "did:hmp:container:ethics_solution-4fba2",
+    "previous_version": "did:hmp:container:vote-13452"
+  }
+}
+```
+
+| Field                      | Description                                                                                         |
+| -------------------------- | --------------------------------------------------------------------------------------------------- |
+| `target_did`               | DID of the container being voted on (goal, task, ethics_solution, etc.).                            |
+| `vote_value`               | Numerical or boolean representation of stance: e.g., `1` (approve), `0` (neutral/abstain), `-1` (reject). |
+| `vote_type`                | Optional symbolic label for semantics (`approval`, `objection`, `support`, `abstain`, etc.).        |
+| `reason`                   | Optional short explanation or reference to supporting evidence.                                     |
+| `related.in_reply_to`      | Reference to the container the vote responds to.                                                    |
+| `related.previous_version` | Used if an agent revises its vote.                                                                  |
+
+---
+
+**Interpretation**
+
+* Each agent MAY publish one or more `vote` containers for a given `target_did`.  
+  When multiple exist, the most recent (by timestamp) is considered current.  
+* `vote` containers can later be aggregated by `consensus_result` containers (see below).  
+* Votes are immutable records; updates are expressed as new versions (`related.previous_version`).  
+
+---
+
+**Example cases**
+
+* In **GMP**, votes determine task delegation or approval.  
+* In **EGP**, votes determine which ethical solution to adopt.  
+* In **CogConsensus**, votes contribute to collective decision formation (e.g., proposal approval).  
+
+---
+
+> **Note:**  
+> Although voting semantics may differ across protocols, all use the same standardized `vote` container class,  
+> ensuring interoperability and unified aggregation through `consensus_result`.
+
+---
+
+#### 6.2.4 Consensus computation
 
 Each agent **computes a local consensus score** by aggregating received evaluations, taking trust and time into account.
 There is no centralized mechanism — consensus emerges statistically across the distributed network.
@@ -3067,7 +3124,7 @@ Results are recalculated dynamically as new data arrives.
 
 ---
 
-#### 6.2.4 Consensus states
+#### 6.2.5 Consensus states
 
 Each container receives a local status based on:
 
@@ -3085,7 +3142,7 @@ Each container receives a local status based on:
 
 ---
 
-#### 6.2.5 Consensus result containers (`consensus_result`)
+#### 6.2.6 Consensus result containers (`consensus_result`)
 
 `consensus_result` containers serve to **record aggregated consensus results** and are the main artifact of CogConsensus.
 
@@ -3156,7 +3213,7 @@ Each container receives a local status based on:
 
 ---
 
-#### 6.2.6 Consensus thresholds
+#### 6.2.7 Consensus thresholds
 
 | Consensus type                   | Minimum threshold                                                      |
 | -------------------------------- | ---------------------------------------------------------------------- |
@@ -3166,7 +3223,7 @@ Each container receives a local status based on:
 
 ---
 
-#### 6.2.7 Proof chains and verifiability
+#### 6.2.8 Proof chains and verifiability
 
 Evaluations and results form a **proof chain** (`proof-chain`):
 
@@ -3182,7 +3239,7 @@ Each element is signed and can be independently verified using cryptographic sig
 
 ---
 
-#### 6.2.8 Ethical consensus and alternative results
+#### 6.2.9 Ethical consensus and alternative results
 
 The network allows multiple consensus results on the same object, reflecting different methodologies or ethical filters.
 
@@ -3214,7 +3271,7 @@ This allows agents to explicitly indicate that a new consensus **disputes** a pr
 
 ---
 
-#### 6.2.9 Recommended agent algorithm
+#### 6.2.10 Recommended agent algorithm
 
 ```python
 # Example of a recommended algorithm for computing local consensus