diff --git a/restoration/source410/RENDER-ROADMAP.NOTES.md b/restoration/source410/RENDER-ROADMAP.NOTES.md
index bf9da5bc..31c433ac 100644
--- a/restoration/source410/RENDER-ROADMAP.NOTES.md
+++ b/restoration/source410/RENDER-ROADMAP.NOTES.md
@@ -621,3 +621,62 @@ answer MechClassID (3001) by reading the .SKL notation pages (VIDEO/*.SKL are
 in the mount) into a dpl_DCS hierarchy and hanging the per-node .BGF geometry
 off it -- ReadSKLFile + RecurseSKLFile per the sibling header, content from
 the BT411 donor.
+
+================================================================================
+SPEC FOR THE NEXT BRICK: the mech skeleton (.SKL -> dpl_DCS tree)
+================================================================================
+Everything needed to write it is now known.  Written down so the next session
+is mechanical rather than exploratory.
+
+THE FILE FORMAT (VIDEO/MAD.SKL, a plain NotationFile):
+
+    [DamageZones]          dz_dtorso=0 ... dz_utorso=21   (22 of them)
+    [ROOT]                 JointCount=25  DZoneCount=22
+                           tranx/trany/tranz  pitch/yaw/roll
+                           joint=jointlocal   joint=jointshadow
+    [jointlocal]           parent=ROOT  Type=balltranslate
+                           tranx.. pitch..   joint=jointhip joint=jointlthigh ...
+    [jointhip]             parent=jointlocal  Type=hingex
+                           Object=mad_hip.bgf         <- the geometry
+                           dzone=dz_hip               <- damage-zone tags
+                           tranx.. pitch..  joint=jointtorso  site=siteedz_hip
+
+So each page is one node: a local transform, an OPTIONAL .bgf object, zero or
+more damage-zone tags, and its child joint page names.  Type= is the joint
+kind (ball / balltranslate / hingex / hingey) and matters for animation, not
+for the initial build.
+
+THE dPL CALLS (CODE/RP/MUNGA_L4/libDPL/dpl/DPL.H):
+
+    dpl_NewDCS()                        create a transform node
+    dpl_SetDCSMatrix(d, float32 *m)     its 4x4 matrix
+    dpl_AddDCSToDCS(parent, child)      parent it
+    dpl_AddDCSToScene(d)                root it
+    dpl_SetDCSZone(d, zone)             assign the zone (MakeNewZone gives one)
+    dpl_LoadObject(name, dpl_load_normal)
+    dpl_NewInstance() / dpl_SetInstanceObject(i,o) / dpl_AddInstanceToDCS(d,i)
+    dpl_FlushDCS(d)                     push it to the card
+
+THE ALGORITHM (matches RPL4VID.HPP's ReadSKLFile + RecurseSKLFile):
+  ReadSKLFile: open the .SKL as a NotationFile, make the zone, recurse "ROOT".
+  RecurseSKLFile(page, parentDCS):
+    1. read tranx/y/z + pitch/yaw/roll -> a matrix -> dpl_NewDCS + SetDCSMatrix
+    2. parent it (AddDCSToDCS, or AddDCSToScene at the root)
+    3. if Object= -> dpl_LoadObject, dpl_NewInstance, SetInstanceObject,
+       AddInstanceToDCS   (Entity_Being_Created is already set by the caller so
+       the C callback can tag geometry with damage zones -- see L4VIDEO.CPP:4176)
+    4. record dcs_array[segment index] so DPLJointToDCSTranslator (L4VIDEO.CPP:
+       6326) can map joint -> DCS afterwards
+    5. for each joint= child, recurse
+
+THE ONE UNKNOWN: the exact dpl_MATRIX layout/convention.  No surviving source
+calls dpl_SetDCSMatrix -- the RP game file that did is missing, like BT's.
+Derive it from dpl3-revive/spec/VELOCIRENDER_PROTOCOL.md, which decodes DCS
+bodies as "type 5 (dcs), 4x4 dpl_MATRIX each", and from DPLTYPES.H.
+
+SUCCESS CRITERION, and it is exact.  The dpl3-revive reference capture of a
+real pod decodes as "Transforms: flush bodies type 5 (dcs) x26" and
+"Placements: type 4 (instance) x22".  MAD.SKL declares JointCount=25 (+1 root
+= 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.