diff --git a/Docs/Vault/06_Roadmap/Roadmap_Lantern_Slice.md b/Docs/Vault/06_Roadmap/Roadmap_Lantern_Slice.md
index f75261e11..cad7bbd76 100644
--- a/Docs/Vault/06_Roadmap/Roadmap_Lantern_Slice.md
+++ b/Docs/Vault/06_Roadmap/Roadmap_Lantern_Slice.md
@@ -184,10 +184,10 @@ Runs parallel with 4–6 where possible.
 > EG/Rukhanka path (renders only in the baked ECS world, not a plain scene). **Still open:** the authoritative **in-game
 > animated run** (wire into `WaveDirector.EnemyPrefabs[]` + a Server/Client play-run — a gameplay-roster change), the
 > **custom kit** re-attach (glowing eyes/kelp as bone-parented children), and the **Bathynaut suit + 2nd creature** — so
-> the "cube→rigged→animated→fighting, twice" gate is close but not signed off. ⚠ Open discrepancy to reconcile: the
-> grounding read found `Characters.fbx` imported as **Generic** (`animationType: 3`), which conflicts with CLAUDE.md's
-> "HUMANOID" note — verify before relying on either. Safe regardless: **reuse the existing rigged Synty prefab + its
-> `CharactersAvatar`** via the tool; do NOT reimport the FBX (a rig-type flip would break the clip binding).
+> the "cube→rigged→animated→fighting, twice" gate is close but not signed off. ✅ Rig-type **verified HUMANOID**
+> (`Characters.fbx` `animationType = Human` (enum 3); `CharactersAvatar.isHuman = true`) — CLAUDE.md's "HUMANOID" note is
+> correct; the earlier "Generic" flag was an enum misread (**3 = Human, not Generic**). Still: reuse the rigged Synty
+> prefab + `CharactersAvatar` via the tool; don't reimport the FBX (a rig-type flip would break the clip binding).
 > Reusable gotchas banked: Blender-5.1 Synty-FBX import workaround, bounds-normalize scattered Synty rocks, posed-static
 > hero bake (apply-armature + visual-transform), the Unity URP render-harness (layer sign-bit, `SubmitRenderRequest`),
 > and the `EnemyRigTools.BuildDrowner` path + its EG-only-render caveat.