VoxelForge/Standalone/Research/WorldAssemblerM3/Research4/shared-notes.md

Shared notes (researcher R4 <-> implementer L38 pass 3), newest at bottom

R4 preliminary result — posted before final attribution

Reproduction result: no. On the requested synthetic helix (3 m centerline radius, 3.31 m pitch, 20 controls/turn, 3 m constant bore, lateral Catmull–Rom as the code does), the audit-style 32 m/0.125 m two-sided wall probe does not reproduce L38's 7.8 m / 3.4 cm coherent signal.

• L37 smoothed tube: best fitted wall period 2.500 m, local amplitude 0.023 cm, coherent amplitude 0.012 cm.
• L38 nearest smoothed tube only: 0.9375 m period, local amplitude 0.002 cm, coherent amplitude 0.001 cm.
• L38 with its independent floor-owner cap: same tube-scale result (0.002 cm local, 0.001 cm coherent).
• L38 with the tube's own floor except in the near-floor band: also unchanged at this scale.

Those measurements make the constant-radius tube geometry, the exact closest-point solve, and the basic independent floor cap insufficient explanations for the real failure. I am checking the route data and audit windows next; do not make a production change based on the synthetic result alone.

Implementer localization, 2026-10-23

The real owner L38 field has been replayed against the exact saved L38 poses at the same seven heights on a separately built L37 source/binary. In window 2 (127.494..159.494 m, away from either mouth), centerline-height L38 roots are inner≈3.0 m, outer=0.4375 m until s=150.744 m; at s=150.869 m (segment 154, t=0.905) inner also becomes 0.4375 m, with both samples tagged as passage fallback support. L37 stays near 3 m on both sides at the same poses. Fine L38 height probing finds the support crossing at h=-0.125,0,+0.125 m, and none by |h|=0.25 m. The ripple fit is a step in the two-sided mean (outer fallback root throughout, inner owner switch) rather than a repeated 7.8 m oscillation.

Could you check whether your synthetic/route analysis can reproduce this specific fallback-root signature, and recommend a shared floor/fallback ownership correction that preserves the upper coil's walk floor without letting its support surface intersect the neighboring bore?

The logged 7.812 m is 8.20 of the synthetic's 0.953 m control chords, 0.408 of its 19.138 m helical turn arc, and 2.36 pitches. It does not match an integer control spacing, turn, or pitch.

Implementer trials 1–6

Fallback depth alone is not sufficient: 0.25 m gives 1.16 cm wall amplitude but only 356/1,285 wall samples and 0/5,116 fallback fills; 0.4375 m gives the same wall coverage/amplitude and 4,704/5,116 fills; 0.45 m and 0.50 m both return to 12.06 cm with 5,116/5,116 fills. Widening the 0.4375 m strip from 0.55 m to 0.70 m changes neither result. Applying fallback before the paired-bore carve cleared all 5,116 fallback samples and caused 810 route support misses. The wall crossings are therefore tied to the floor-cap/fallback composition, not just strip width.

Your 0.55 m floor-band candidate is next. Does the control-only run include fallback support, and if not, can you check whether changing only the floor cap can remove the tagged fallback-root step in the real field? The current field marks the failing h=0 roots as passage fallback support.

R4 owner-pairing diagnosis

I also replayed the saved FI Style 2 resolved-layout controls from Saved/Linux/l38/owner-fi-style2-layout.json (435 points, 443.270 m chord arc) with the same wall-probe cadence and Catmull lateral curve. All five windows have a 3 m radius. The final window starts at 374.256 m and enters the route's spacing transition: chord steps grow from about 0.69–0.95 m to 2.37–3.13 m.

• Raw route tube: L37 0.292 cm local / 0.059 cm coherent; L38 0.143 cm local / 0.029 cm coherent. The closest-point and chord-vs-spline change alone does not create the failure.
• L38 tube plus its independent floor-owner cap: 7.375 cm local at 5.000 m, 1.493 cm coherent. This identifies the separate floor cap as the large wall-surface change on the recorded controls.
• A cap that uses any floor-band candidate within the 3 m bore radius jumps to 31.018 cm at 7.8125 m. A cap that uses the route floor only when its horizontal offset is within the 0.55 m fallback/walk strip returned to the raw-tube result: 0.143 cm local / 0.029 cm coherent.

Candidate source change: keep the current floorOwner for fallback support and mouth data, but form the tube's floor cap from nearestFloorBandCandidate.floorQ only when that candidate is within the 0.55 m walk strip; otherwise use nearestBoreCandidate.boreFloorQ. The replacement belongs at bestFloorLimitedDistance in ApplyResolvedStratePassageCarves, immediately after boreDistance is selected. This keeps a neighboring coil's floor plane from clipping a wall while retaining the route-owned floor at the walk strip.

The control-only model reproduces a large cap-induced wall artifact and its removal; it does not reproduce the real audit's exact 12 cm / 7.8 m pair. It omits native FI density, wall-relief detail, and the production BVH visitation. For the 0.55 m variant, the floor probe returned 0.00000 cm maximum error and 0.00000 cm peak-to-peak over all five windows.

While this research was running, the working tree began showing the same carveFloorQ/0.55 m guard in ShapeWorldInternal.h (I did not edit source). No build or real-world audit was run against that concurrent source state. The Python evidence supports it as the next trial; the real 12 cm result remains unverified after the change.

Response to implementer fallback-root follow-up

The route-only helper above does not model fallbackDistance or the native density>=0 gate, so it cannot reproduce the tagged 0.4375 m roots. Those roots are outside the tube-only attribution above. The current source applies min(composed,bestFallbackDistance) independently after the floor-limited bore carve. That can put the floor-owner's solid strip into a neighboring coil's carved volume.

Candidate shared-domain correction to test: clip the fallback SDF against the solid side of the same floor-limited bore before applying it: fallbackDistance = max(fallbackDistance, -bestFloorLimitedDistance). Where the route-owned cap is at the intended walk floor, bestFloorLimitedDistance is zero at the floor and positive below it, so the fallback slab still supports the walk surface. Above that floor, the bore's void side makes -bestFloorLimitedDistance positive and prevents fallback support from re-filling the neighboring bore. This belongs at the fallback application (bestFallbackDistance / composed=min) after the cap distance has been computed. I am checking the route-only side roots now; real support coverage remains for the implementer's next trial.

Fallback-root probe result and revised candidate

The shared-domain mask alone does not remove this local root. On the saved route at s=150.744 and 150.869 m, the nearest tube is segment 154 and the selected floor owner is segment 134. Its floor lies 0.4475/0.4473 m above the local bore centerline, so the query is on the solid side of that selected floor (bestFloorLimitedDistance≈+0.447 m); the shared-domain mask correctly leaves the fallback strip in place. The route-only fallback model has a 0.5625 m root on both sides at both poses (the logged world root is 0.4375 m; this model omits native density and production candidate traversal).

A narrower geometric correction reproduces the root change: limit the fallback slab's bottom to just above a neighboring bore centerline when that centerline lies below the selected floor. Compute boreCenterZ = nearestBoreCandidate.boreFloorQ + nearestBoreCandidate.boreRadius - 0.15*qPerMetre. If boreCenterZ < floorOwner.floorQ, set the slab bottom to max(floorOwner.floorQ - FallbackThicknessMetres*qPerMetre, boreCenterZ + 0.01*qPerMetre); otherwise retain the 1 m depth. Recompute the fallback SDF with this bottom after both owners are known. In Python, the gap is 0.4475/0.4473 m, so fallback depth becomes 0.4375/0.4373 m; the 0.5625 m centerline roots disappear. The route-owner's top floor remains exactly at zero, and a point 0.25 m below remains inside the support slab.

This matches the implementer's depth sweep: 0.4375 m is just above the collision threshold and greatly reduces the wall fit, while 0.45 m crosses the neighboring bore centerline and restores the failure. A dynamic limit should affect only overlapping fallback regions, unlike the global 0.4375 m trial. It has not been tested against native-density support coverage; the absent local root also does not prove that a 3 m rock-wall crossing appears there. I withdraw the shared-domain mask as the proposed fix for this signature.

Implementer trials 7–8

Trial 7 of the 0.55 m floor-cap guard on the real owner reduced wall amplitude to 0.58 cm at 6.375 m, coverage 955/1,285, walkability PASS; it caused 3,024 native-rock support misses and is not usable. Trial 8 widened the floor-owner band vertically through the 0.4375 m support depth and reduced fallback depth to 0.4375 m; wall amplitude remained 0.58 cm but coverage fell to 254/1,285 and 635 support misses remained. The remaining trials combined that support band with fallback-SDF clipping to test support retention above the bore-owned floor.

Final implementer result

Trials 9–10 with fallback clipping and a 0.40 m vertical support cap ended at the same result: 0.58 cm wall amplitude, 254/1,285 coverage, and 2,269 support misses; widening the near-floor cap from 0.55 m to 0.75 m made no difference. We stopped at the 10-trial budget, restored the pre-trial L38 source, removed temporary wall-pose instrumentation, and rebuilt/re-hashed the restored source. The owner gate remains 12.06 cm at 7.812 m; no full matrix was run.

R4 correction for the next trial

I independently reproduced the local tagged-root geometry in the saved-route control model: at s=150.744/150.869 m, the independent 1 m fallback has a 0.5625 m radial root on both sides; dynamically ending its slab 0.01 m above the lower bore centerline removes the root, leaves the owning floor at 0, and retains support 0.25 m below it. This is approximate to the real 0.4375 m root and does not model native density.

The earlier shared-domain probe used the old, independent floor-owner cap and therefore did not remove the root: it also measured 0.5625 m. The paired-domain trial is different: outside the 0.55 m walk strip / 0.375 m below-floor band, the floor cap follows the nearest bore, then the fallback is clipped to that bore's solid-side domain. At the logged pose the lower bore's floor is below the query, so this pairing rejects the upper coil's fallback there; at the upper coil's own floor it retains the intended fallback.

Paired-domain root check: the route-only radial probe now yields no support crossing on either side at s=150.744/150.869 m, while the independent and shared-owner-only modes still cross at 0.5625 m. At the lower coil centerline the paired clip distance is +2.850 m, making fallback unavailable there. At the upper owner floor, paired support is 0.000 m on top and -0.243 m 0.25 m below.

The corresponding 32 m route-only wall audit returns 0.003 cm local amplitude at 2.375 m for all three cases (independent fallback, owner cap plus shared domain, paired cap/domain), with all 257 probes finding the 3 m outer wall. This does not validate the real 12 cm fix: the Python base field retains a continuous tube wall and omits native FI density, which is needed to reproduce the missing-rock wall roots. The actionable Python result is the tagged-root removal plus floor support retention, not an amplitude match.

Final caveat after implementer trials 9–10: the full owner gate is restored to 12.06 cm / 7.812 m. Fallback clipping with a 0.40 m cap got 0.58 cm but only 254/1,285 coverage and 2,269 support misses. The 0.375 m geometry model is a small candidate rule, not a demonstrated production fix; its native support coverage must be checked before any claim that the ripple is removed.