diff --git a/research/evaluations/language-pilot-01/human-review/review-bernd-worsch-2026-10-19.json b/research/evaluations/language-pilot-01/human-review/review-bernd-worsch-2026-10-19.json
index 8e7a170..c60121c 100644
--- a/research/evaluations/language-pilot-01/human-review/review-bernd-worsch-2026-10-19.json
+++ b/research/evaluations/language-pilot-01/human-review/review-bernd-worsch-2026-10-19.json
@@ -153,38 +153,38 @@
     {
       "answer": "S05-U",
       "scores": {
-        "C1": null,
-        "C2": null,
-        "R": null,
-        "Q": null
+        "C1": 1,
+        "C2": 1,
+        "R": 1,
+        "Q": 1
       },
       "evidence": {
-        "C1": null,
-        "C2": null,
-        "R": null,
-        "Q": null
+        "C1": "Reviewer: yes.",
+        "C2": "Reviewer: yes \u2014 receipt updates P's own history, 'should not alter the active content or the status of Q'.",
+        "R": "Reviewer: yes.",
+        "Q": "Reviewer: yes \u2014 'clear contract for the receiver's ancestry and precondition behavior'."
       },
-      "unsupported_claims": null,
-      "suspected_condition_leakage": null,
-      "notes": null
+      "unsupported_claims": [],
+      "suspected_condition_leakage": "none",
+      "notes": "Reviewer guidance (S05): the resolution strategies are a simplification of keeping git-style version histories for all participants and offering every possible merge-conflict resolution. A system designer could select from a fairly complete strategy set by limiting history count/storage and applying merge, rebase and conflict-diff UI facilities. Reviewer guidance (S05, R): design two different interaction systems. (1) Synchronous collaboration (shared whiteboard, document, multiplayer): the conflict-resolved state is visible to all participants, who can react, correct or modify it to establish their intent before the result is finalized for asynchronously reached mid/long-term consumers. (2) A register that feeds, or is queried by, other consumers asynchronously: changes may propagate before their resolution, and updating all consumers with the resolution may be infeasible without an additional distribution mechanism, which carries its own design considerations."
     },
     {
       "answer": "S05-V",
       "scores": {
-        "C1": null,
-        "C2": null,
-        "R": null,
-        "Q": null
+        "C1": 1,
+        "C2": 1,
+        "R": 1,
+        "Q": 1
       },
       "evidence": {
-        "C1": null,
-        "C2": null,
-        "R": null,
-        "Q": null
+        "C1": "Reviewer: yes.",
+        "C2": "Reviewer: yes \u2014 update P's status to accepted, 'not reapply P's changes to revision c or Q'.",
+        "R": "Reviewer: yes.",
+        "Q": "Reviewer: yes \u2014 'critical missing contract is the receiver's ancestry and precondition behavior'."
       },
-      "unsupported_claims": null,
-      "suspected_condition_leakage": null,
-      "notes": null
+      "unsupported_claims": [],
+      "suspected_condition_leakage": "none",
+      "notes": "Reviewer guidance (S05): the resolution strategies are a simplification of keeping git-style version histories for all participants and offering every possible merge-conflict resolution. A system designer could select from a fairly complete strategy set by limiting history count/storage and applying merge, rebase and conflict-diff UI facilities. Reviewer guidance (S05, R): design two different interaction systems. (1) Synchronous collaboration (shared whiteboard, document, multiplayer): the conflict-resolved state is visible to all participants, who can react, correct or modify it to establish their intent before the result is finalized for asynchronously reached mid/long-term consumers. (2) A register that feeds, or is queried by, other consumers asynchronously: changes may propagate before their resolution, and updating all consumers with the resolution may be infeasible without an additional distribution mechanism, which carries its own design considerations."
     },
     {
       "answer": "S06-U",