Sync from GitHub with Git LFS

docs/HMP-0005.md

@@ -260,7 +260,7 @@ flowchart TD
 
     A[Agent A: <br>creates Goal container]
     B[Agent B: <br>replies with <br>Task proposal <br>related.in_reply_to = Goal]
-    C[Agent C: <br>evaluates proposal, <br>creates Evaluation container]
+    C[Agent C: <br>evaluates proposal, <br>creates evaluation container]
     R[Result: <br>consensus_result container <br>aggregates evaluations]
 
     subgraph Interaction["Distributed Reasoning Cycle"]
@@ -3018,6 +3018,7 @@ All evaluations are signed and verified locally.
 
 ```json
 "evaluations": {
+  "evaluations_hash": "sha256:efgh...",
   "items": [
     {
       "value": -0.4,
@@ -3038,8 +3039,7 @@ All evaluations are signed and verified locally.
 
 #### 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.
+A `vote` container represents a **simplified, atomic evaluation** — an agent’s explicit stance toward another container (e.g., `goal`, `task`, `ethics_solution`, or `proposal`).  
 
 ```json
 {
@@ -3050,10 +3050,20 @@ A `vote` container is **atomic** — one container expresses one agent’s posit
     "target_did": "did:hmp:container:ethics_solution-4fba2",
     "vote_value": 1,
     "vote_type": "approval",
-    "reason": "Consistent with prior consensus and ethical policy E-17"
+    "arguments": [
+      {
+        "reason": "Consistent with prior consensus and ethical policy E-17",
+        "evidence": ["did:hmp:container:abc12462"]
+      },
+      {
+        "reason": "No conflict with safety constraints",
+        "evidence": ["did:hmp:container:def772ab"]
+      }
+    ]
   },
   "related": {
-    "in_reply_to": "did:hmp:container:ethics_solution-4fba2",
+    "in_reply_to": ["did:hmp:container:ethics_solution-4fba2"],
+    "depends_on": ["did:hmp:container:abc12462", "did:hmp:container:def772ab"],
     "previous_version": "did:hmp:container:vote-13452"
   }
 }
@@ -3064,8 +3074,9 @@ A `vote` container is **atomic** — one container expresses one agent’s posit
 | `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.                                     |
+| `arguments`                | Optional array of reasoning elements that justify the vote. Each entry may include a `reason` and linked `evidence`. |
 | `related.in_reply_to`      | Reference to the container the vote responds to.                                                    |
+| `related.depends_on`       | References to containers (e.g., evidence or argumentation) used as the basis for this decision.     |
 | `related.previous_version` | Used if an agent revises its vote.                                                                  |
 
 ---
@@ -3074,22 +3085,32 @@ A `vote` container is **atomic** — one container expresses one agent’s posit
 
 * 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`).  
+* Votes are **immutable**; updates are published as new containers referencing the previous one via `related.previous_version`.  
+* A `vote` container SHOULD correspond to an entry in the **evaluations** structure of the referenced container, representing the same decision context.  
+* Agents MAY instead express their stance through other container types (`ethics_solution`, `workflow_entry`, etc.);  
+  all such contributions are aggregated through the block **evaluation**, not limited to explicit `vote` containers.
+
+---
+
+**Consensus interpretation**
+
+During consensus computation (§6.2.4), the system considers **all containers linked in the block `evaluation`**,  
+not only explicit `vote` containers.  
+A `vote` thus acts as a **standardized shorthand** for agents or lightweight nodes that need to record a simple position  
+without producing a full analytical `evaluation`.
 
 ---
 
 **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).  
+* In **EGP**, votes indicate preferred ethical solutions.  
+* In **CogConsensus**, votes may coexist with more complex evaluations and are processed equivalently in the aggregation phase.
 
 ---
 
 > **Note:**  
-> Although voting semantics may differ across protocols, all use the same standardized `vote` container class,  
-> ensuring interoperability and unified aggregation through `consensus_result`.
+> The `vote` container is an **optional specialization** of the evaluation mechanism — it improves interoperability and clarity in binary or scalar decision-making, but consensus formation always relies on the full **evaluation graph**, where every relevant container (including `vote`) contributes evidence and weight.
 
 ---
 
@@ -4527,7 +4548,7 @@ This allows gradual enrichment of the trust model without schema changes.
     }
   },
   "related": {
-    "in_reply_to": "did:hmp:container:peerannounce-567",
+    "in_reply_to": ["did:hmp:container:peerannounce-567"],
     "see_also": ["did:hmp:container:peerannounce-489"],
     "previous_version": "did:hmp:container:trust-9ab7"
   }