MEMORY.md

@@ -560,3 +560,16 @@ x=-10336 z=366 Road_Hollywood     x= 1664 z=  5 Terrain_DEM
 - **The road is a flat slab at 366 cm** across the whole demo block, while the sidewalk slices follow the DEM and descend 380 -> 104 cm. The gap is therefore in the street generator: the road is not sampling the elevation per row the way the sidewalks do, or it was written with a single Z.
 - That also explains why every sidewalk fix failed - the street the player actually stands on is the flat road, and the sloped sidewalk is metres below it.
 - **Next:** inspect how `rows` is built in `Art/blender/street/street_mesh.py` - the road's `road_z` reads `dem_z(x, y)` from the same rows as the sidewalk, so a flat result means `dem_z` is returning the same value for every row (origin offset or a lookup that fails and falls back), and the fix is in that sampler.
+
+## 2026-11-09 — Source truth vs what the engine reports
+
+Sampled the regenerated street blend at the player's X (x = -133.36 m):
+
+```
+Road_Hollywood   verts at y = -9.0..-9.1, z = 0.87..0.94 m
+Sidewalk_North   verts at y = +11.9..+12.0, z = 1.51..1.59 m
+```
+
+So the road is the south band at ~0.9 m and the north sidewalk is at ~1.55 m, exactly a kerb above it. **The source geometry is correct and consistent.**
+
+In the engine at the player's position (UE Y -1150 cm, i.e. the north sidewalk band) the trace reports `Road_Hollywood` at **366 cm** - the road is neither in that Y band nor at that height in the source. So the mismatch is introduced on the way in: either the FBX export's Y mirror documented in `export_site_fbx.py`, or the importer's transform. Until that is settled, no screenshot reflects the source, and a visual signoff would be approving a defect.