diff --git a/restoration/source410/RENDER-ROADMAP.NOTES.md b/restoration/source410/RENDER-ROADMAP.NOTES.md
index 31c433ac..5161b61b 100644
--- a/restoration/source410/RENDER-ROADMAP.NOTES.md
+++ b/restoration/source410/RENDER-ROADMAP.NOTES.md
@@ -680,3 +680,49 @@ real pod decodes as "Transforms: flush bodies type 5 (dcs) x26" and
 = 26) and DZoneCount=22.  So a correct walk of this one file should put 26 DCS
 flushes and 22 instance flushes on the wire -- countable in the fifodump
 without looking at a single pixel.
+
+--------------------------------------------------------------------------------
+API INVENTORY for the skeleton walk -- all confirmed, nothing left to discover
+--------------------------------------------------------------------------------
+NotationFile (CODE/RP/MUNGA/NOTATION.HPP) reads every field the .SKL needs:
+    GetEntry(page, entry, Scalar*)        tranx/trany/tranz, pitch/yaw/roll
+    GetEntry(page, entry, const char**)   Object=  (the .bgf)
+    MakeEntryList(page, "joint")          the child pages
+    MakeEntryList(page, "dzone")          the damage-zone tags
+    NameList iteration is entry = list->GetFirstEntry(); entry;
+    entry = entry->GetNextEntry()   -- exactly how DPLReadINIPage walks
+    objectpath= at L4VIDEO.CPP:1858, so copy that idiom.
+
+dPL side, all in libDPL/dpl/DPL.H:
+    dpl_NewDCS / dpl_SetDCSMatrix / dpl_AddDCSToDCS / dpl_AddDCSToScene
+    dpl_SetDCSZone / dpl_FlushDCS
+    dpl_LoadObject(name, dpl_load_normal) / dpl_NewInstance /
+    dpl_SetInstanceObject / dpl_AddInstanceToDCS / dpl_FlushInstance /
+    dpl_FlushObject
+
+THE MATRIX, as far as the evidence goes.  A DCS flush body decodes as
+[remote:4][type_check:4][node:4][matrix:64] -- 16 float32, a 4x4 (confirmed
+by dpl3-revive/patha/analyze_scene.py, which reads rest[4:68] as 16 floats).
+Decoding a real BT capture (patha/bt1.raw.bin) prints a near-identity DCS with
+a single 10.0 term in the LAST ROW, which points at row-major with the
+translation in row 3 -- but the printed rows look shifted by one word against
+a true identity, so that decoder's offset is suspect by exactly 4 bytes.
+DO NOT trust this without re-deriving it; the cheap way is to build the tree
+with IDENTITY matrices first (below), then set one known node's translation
+and watch which slot moves in the fifodump.
+
+RECOMMENDED ORDER OF WORK -- two stages, each independently verifiable:
+  STAGE 1: walk the .SKL and build the tree with IDENTITY matrices.  Every
+  node collapses onto the origin so it looks wrong, but the STRUCTURE is
+  provable without pixels: the wire must carry 26 DCS flushes and 22 instance
+  flushes (MAD.SKL: JointCount=25 +root, DZoneCount=22 -- and the dpl3-revive
+  reference capture of a real pod shows exactly 26 and 22).  Getting those
+  counts proves the recursion, the object loads and the parenting.
+  STAGE 2: put the real transforms in and fix the convention by observation.
+
+ONE API STILL TO CHECK BEFORE STAGE 1: how the .SKL filename reaches us.  The
+engine builds a chain via L4VideoObjectWrapper::BuildVideoObjectChainFromResource
+and rejects our mech with "wrong video resource type for object mad.skl"
+(L4VIDEO.CPP:4265) because it only accepts L4VideoObject::Object / Rubble.  So
+the skeleton arrives as a different L4VideoObject::ResourceType -- find that
+enumerator and branch on it in our override rather than re-deriving the name.