@@ -135,7 +135,7 @@ V4 answers:
 
 > **What boss actions actually exist, and what evidence supports the semantic moves used by the product?**
 
-Start with V4 Milestone 1 (research foundation) and Milestone 2 (Genichiro runtime pilot). See sections 18–36.
+V4 Milestone 1 is done, and Milestone 2 has proven the runtime bridge for castle Genichiro. Current work is the Genichiro semantic catalog (Milestone 4, section 29); further recording only fills gaps in that catalog. The step-by-step plan is `research/ground_truth/genichiro-plan.md`. `v4.0.0` covers castle Genichiro, all three phases. See sections 18–36.
 
 V3 is released. Sections 7–17 remain the reference for how the current product is built; their product rules (lightweight attempt recording, honest analytics, per-user isolation, one language per page) still apply.
 
@@ -845,6 +845,8 @@ for a small number of representative attacks.
 
 Do not attempt full game extraction before proving this bridge works.
 
+Once the bridge is proven, recording is targeted at gaps in the semantic catalog (section 29): moves with only static or ambiguous evidence, and moves the product will support that lack a reference clip. Do not try to record every animation in the game files.
+
 ---
 
 # 25. V4 Runtime-First Principle
@@ -983,6 +985,14 @@ Preserve this uncertainty until actual data confirms the schema.
 
 # 29. V4 Milestone 4 — Genichiro Semantic Catalog
 
+The catalog lists every action that can hit the player, cause a mistake, break the player's posture or kill. Guards, deflects, steps, dashes and hit reactions are engine actions, not moves. An animation can be only part of a move.
+
+Build the draft from the battle AI (each AI option usually requests one complete move chain, with branches and trigger conditions), TAE, runtime recordings, wiki names as candidates, and animation previews. Group variants under a move family: Genichiro's three Floating Passage variants are one family.
+
+Every entry carries an evidence status: `runtime observed`, `static evidence only` or `to confirm`. The project owner confirms every name, grouping and variant.
+
+Outputs: a reviewable move ↔ animation table, and time-labelled reference clips for the moves the product will support.
+
 For each semantic move, gather evidence such as:
 
 - ruleset
@@ -1256,16 +1266,19 @@ Do not jump directly to full automatic fight understanding.
 Use:
 
 ```text
-1. Video upload
-2. Manual annotation
-3. Semi-automatic annotation
-4. Short-clip move classification
-5. Temporal move detection
-6. Player-response detection
-7. Automatic fight report
-8. Recommendations
+1. Failure attribution prototype on local recordings
+   (hand-labelled answer set; detect damage / posture break / death
+    → look back → identify the move → merge one failure → failure report)
+2. Reliability validation on independent recordings
+3. Video upload and failure report (failure counts per move)
+4. Whole-fight move detection (short clips first, then temporal segmentation)
+5. Player-response detection
+6. True per-move analytics
+7. Recommendations
 ```
 
+At first the system proposes move candidates and a person confirms them. Recordings made with the dev-menu overlay are labelled reference data; mask the overlay when training or evaluating.
+
 Every stage should produce useful intermediate tooling.
 
 ---
@@ -1591,14 +1604,13 @@ Examples currently not justified by default:
 
 # 53. Current Priority Order
 
-V3 is released. Work through V4 in milestone order:
+V3 is released. V4 order:
 
 ```text
-1. Research foundation (V4 Milestone 1)
-2. Genichiro runtime pilot (V4 Milestone 2)
-3. Static engine mapping (V4 Milestone 3)
-4. Genichiro semantic catalog (V4 Milestone 4)
-5. Completeness review (V4 Milestone 5)
+1. Research foundation (V4 Milestone 1) — done
+2. Genichiro runtime pilot (V4 Milestone 2) — bridge proven; further recording only fills catalog gaps
+3. Genichiro semantic catalog (V4 Milestone 4) — current, using static engine mapping (V4 Milestone 3) as needed
+4. Completeness review (V4 Milestone 5)
 ```
 
 Then, to complete `v4.0.0`:
 
@@ -588,6 +588,11 @@ Runtime Identifier
 
 for several representative attacks.
 
+Once this bridge is proven, further recording is targeted. It fills gaps in the semantic catalog (Milestone 4), rather than trying to capture every animation in the game files:
+
+- moves with only static or ambiguous evidence
+- moves the product will support that have no reference clip yet
+
 ---
 
 # V4 Milestone 3 — Static Engine Mapping
@@ -632,7 +637,34 @@ manually inspect thousands of animations
 
 # V4 Milestone 4 — Genichiro Semantic Move Catalog
 
-Create a reviewed mapping between engine actions and semantic moves.
+Create a reviewed catalog of the boss's semantic moves and the engine actions behind them.
+
+A semantic move is an action that can hit the player, cause a mistake, break the player's posture or kill. Guards, deflects, steps, dashes and hit reactions are engine actions but not moves. An animation can also be only part of a move.
+
+Start the draft as soon as runtime identifiers exist, from the evidence already gathered:
+
+- the battle AI: each AI option usually requests one complete move chain, with its branches and trigger conditions
+- TAE: attack, projectile and effect events
+- runtime recordings
+- wiki names, as candidates
+- animation previews
+
+Group variants under a move family. For example, Genichiro's three Floating Passage variants form one family.
+
+Every entry carries an evidence status:
+
+```text
+runtime observed
+static evidence only
+to confirm
+```
+
+The project owner confirms every name, grouping and variant.
+
+Outputs:
+
+- a reviewable move ↔ animation table
+- time-labelled reference clips for the moves the product will support
 
 Each mapping should retain evidence.
 
@@ -681,6 +713,8 @@ unused_or_unreachable
 unknown
 ```
 
+Guards, deflects, steps and dashes are `non_combat`. An animation that is only part of a move maps to that move.
+
 Every runtime-observed combat action should map to:
 
 ```text
@@ -878,62 +912,76 @@ Practice Suggestions
 
 ---
 
-## V5 Milestone 1 — Video Upload and Storage
+## V5 Milestone 1 — Failure Attribution Prototype
 
-Add:
+The first V5 goal is narrow: in the player's own recordings, find each failure and the boss move that caused it.
 
-- gameplay video upload
-- user ownership
-- metadata
-- processing status
-- storage lifecycle
+```text
+detect damage taken / posture broken / death
+        ↓
+look back at the preceding boss actions
+        ↓
+identify the boss move (V4 catalog)
+        ↓
+merge events that belong to one failure
+        ↓
+failure record: time, clip, move
+```
 
-Video blobs do not need to live inside PostgreSQL.
+Work on local recordings first:
 
-PostgreSQL should store metadata and references.
+- label a small set of recordings by hand as the answer set: move start/end, phase, ruleset, failure events; keep uncertain labels
+- at first the system proposes move candidates and a person confirms them; automate as accuracy allows
+- player HP, posture and death can be read from the game HUD
+
+The annotation tooling should be useful even if automatic recognition never becomes perfect.
+
+Recordings made for V4 carry the dev-menu animation labels, so they double as labelled reference data. Mask the overlay region when training or evaluating, so a model cannot read the label.
+
+Output: one recording → one failure report a person can check.
 
 ---
 
-## V5 Milestone 2 — Annotation Pipeline
+## V5 Milestone 2 — Reliability Validation
+
+Check the prototype on independent fight recordings:
 
-Before automatic ML detection:
+- missed failures
+- misidentified moves
+- one failure counted twice
 
-- build manual annotation tooling
-- use V4 ground-truth IDs
-- label move start/end timestamps
-- label phase
-- label ruleset
-- preserve uncertain labels
+Keep results the system cannot confirm as uncertain.
 
-The annotation tool should be useful even if ML never works perfectly.
+Measure precision and recall, for failure detection and for move identification.
 
 ---
 
-## V5 Milestone 3 — Semi-Automatic Move Recognition
+## V5 Milestone 3 — Video Upload and Failure Report
 
-Start with assistance rather than full automation.
+Once attribution is reliable, let users upload recordings.
 
-Example:
+Add:
 
-```text
-System:
-"This looks like Floating Passage."
+- gameplay video upload
+- user ownership
+- metadata
+- processing status
+- storage lifecycle
 
-[Confirm]
-[Choose Different Move]
-```
+Show the failure times, their clips, the moves, and the number of failures per move.
 
-Measure:
+These are failure counts, not success rates: how often each move occurred is not known yet.
 
-- annotation speed improvement
-- precision
-- recall
-- confidence calibration
+Video blobs do not need to live inside PostgreSQL.
+
+PostgreSQL should store metadata and references.
 
 ---
 
 ## V5 Milestone 4 — Automatic Move Detection
 
+Detect every boss move in a fight, not only the ones before a failure. Move occurrences are the denominator that true per-move rates need.
+
 Progress from:
 
 ```text
@@ -949,7 +997,7 @@ full fight
 → move classification
 ```
 
-Do not require whole-fight understanding as the first ML milestone.
+Expand coverage from what the system could not attribute in users' recordings: add samples, then the other Genichiro encounters (prologue, the Sword Saint fight's Way of Tomoe phase, Inner Genichiro).
 
 ---