NODEDC_MISSION_CORE/docs/audits/2026-09-20-physical-midroute-017-018-results.md

Physical mid-route starts 017/018 — result review

Scope and verdict

Read-only review of the two latest physical experiments requested by the owner. No registration, threshold, UI or device-control code was changed. No scanner commands, replay session, service restart or Ops mutation was performed.

Both cold mid-route starts and subsequent geometric tracking succeeded while the scanner supplied spatial data. Run 017 moved forward; independently started run 018 travelled back towards the reference origin. There were no rejected fresh fits or inconsistent-transform decisions during either traversal.

Two qualifications matter: the reported distances differ from the operator's rough walking estimates, and both reports contain a terminal stale transition after commanded scanner stop, not an in-motion recognition failure. Absolute localisation accuracy is not established by these recordings.

Evidence and integrity

Canonical private data root: ../NODEDC_MISSION_CORE/.runtime/mission-core.

Item	017	018
Name	ja-sun-017-30m-offset	ja-sun-018-80m-offset-back
Live-test ID	2de294bb-a18e-4dfd-a9c4-51cae38fa54d	f61c7041-c1bb-4434-97e5-413bbc3e0695
Raw session	20260920T182601Z_viewer_live	20260920T183041Z_viewer_live
Selected reference length	112.248 m	120.073 m
Frozen result artifacts verified	84/84	114/114
Raw pose payload hashes verified	1126/1126	1439/1439

Both use reference session 20260911T085226Z_viewer_live, generation 8527e0de1995c93c835ee7223488ff851442792551e217d4ab43457974f798a1, route-relocalisation v6 and stationary fresh bootstrap v3. Current source hashes match the previously qualified implementation for route retrieval, bootstrap and live orchestration. Reviewed each step's source.json, numerical result and decision.json, the raw receipt indexes, STOP timing diagnostics, temporal gate and metric definitions in the actual code.

All fresh windows were disjoint in source sequence, and every admitted receipt was newer than its fresh fence and no later than calculation submission. Both starts rejected the dense origin hypothesis and searched the selected route; 018 did not inherit the final transform of 017 as an accepted localisation.

Recognition and tracking

Metric	017 forward	018 backward
Computed reference progress at start	38.37 m	84.87 m
Computed progress at last accepted fit	84.89 m	0.22 m
Recorded travelled distance	47.442 m	85.023 m
Cold confirmation from first usable prefix	51.614 s	49.065 s
Dense-start fits	108, rejected	108, rejected
Whole-route regions / precise fits	24 / 72	26 / 78
Search completed / remaining regions	yes / 0	yes / 0
Selected coarse anchor	40 m	85 m
Initial overlap / inlier RMSE	99.538% / 0.1509 m	99.259% / 0.1553 m
Runner-up distinct overlap	79.994%	81.514%
Fresh accepted fits, including first three	15/15	21/21
Fresh overlap min / median / max	98.961 / 99.325 / 99.577%	95.482 / 98.163 / 99.516%
Inlier RMSE min / median / max	0.1460 / 0.1488 / 0.1518 m	0.1486 / 0.1567 / 0.1755 m
Largest inter-update position correction	0.0401 m	0.0441 m
Largest inter-update rotation correction	0.2563°	0.5650°
Maximum accepted input age at completion	0.954 s	1.499 s
Worker wall time median / max	0.314 / 0.395 s	0.304 / 0.407 s

Progress was obtained by projecting transformed scanner positions onto the selected reference polyline. It is an estimate produced by the registration, not surveyed ground truth. Its forward/backward progression matches the stated experiments: 017 from about 38 to 85 m; 018 from about 85 m to the origin. The travelled distance is the existing live-buffer accumulated SLAM distance, not straight-line endpoint separation or an independently measured tape length.

The complete route searches took 28.333 s (017) and 25.325 s (018) across the dense and route stages. Confirmation durations include the stationary prefix and three new-data checks, but exclude device preparation before usable clouds. All numerical fits converged. Shape and information metrics remained above their admission thresholds; no failed fit was disguised as an accepted one.

Using the last raw pose and last accepted transform of 017, then the first raw pose and third fresh (confirmed) transform of 018, their shared physical-place coordinates differ by approximately 0.0173 m. This is an encouraging cross-session repeatability observation, conditional on the owner's statement that the scanner restarted at the same physical location. It is not an absolute 1.7 cm accuracy certificate: both estimates use the same reference, and exact physical endpoint placement was not independently measured.

At the current scanner location, the maximum difference between the initial transform and later accepted transforms was 0.119 m in 017 and 0.124 m in 018. These are registration corrections relative to the initial hypothesis, not position errors against ground truth. Total orientation-transform changes were 0.357° and 1.135° respectively; the largest single update is listed separately.

End-of-run stale: lifecycle finding

UTC chronology from raw receipt indexes and scanner-diagnostics.jsonl:

Event	017	018
STOP handling began	18:28:20.335	18:33:28.029
Last spatial cloud received	18:28:20.710	18:33:30.337
Last accepted fit completed	18:28:21.033	18:33:27.795
Temporal gate became stale	18:28:28.698	18:33:35.441
Capture/planning input finished	18:29:12.068	18:34:22.051

STOP was confirmed by the device. Heartbeats and device-status receipts continued after spatial output ceased. The capture remained active for roughly another 51 s while shutdown completed. The numerical gate correctly refused to retain live localisation after its eight-second sample-age fence; the live orchestrator consequently began recovery (recovery_attempt=1) despite the scanner already being deliberately stopped. No new recovery fit followed.

This is a real lifecycle/reporting defect: commanded stopping should not be reported as unexpected loss requiring relocalisation. The correct follow-up is to distinguish capture finalisation from active spatial acquisition, while still clearing live authority. It is not a reason to weaken the freshness fence or mark stale transforms as live. The present review does not implement that follow-up.

Code anchors: causal_tracking.py:32 expires accepted evidence; stationary_live.py:349 ticks the gate and starts recovery before the source has ended. The source's active state remains true during the prolonged stop finalisation, so simply reordering the end-of-input check is insufficient.

Input delivery finding

Raw spatial receipts averaged approximately 10 Hz in both experiments, with maximum receipt gaps of about 1.11 s and 1.01 s. Recorded planning continuity segments contained no gap beyond the two-second boundary and no detected pose discontinuity. Burst delivery means that speed calculated from consecutive host receipt intervals is not a valid physical velocity estimate.

The private derived-data queue did discard some packets on overflow:

• 017: 9/1125 lidar frames (0.80%), no pose frames.
• 018: 34/1439 lidar frames (2.36%), 1/1439 pose frames (0.07%).

These are deltas of cumulative ingress counters, not raw-recorder losses. Corresponding packets remain in the raw recordings. The discarded derived packets did not produce a failed geometric/temporal check in these runs, but delivery cannot honestly be described as lossless. Queue/scheduling headroom remains a follow-up concern before greater speed, load or route length.

Accuracy interpretation and conclusion

In registration.py:140, overlap is the fraction of sampled query points whose nearest reference point lies within 0.5 m. RMSE is computed only over that inlier set, after the existing 0.25 m voxel preparation. Thus 99% is not a 99% probability of correct localisation, and 0.15 m RMSE is neither a measured scanner position error nor its guaranteed bound. Small corrections between updates indicate consistency, not independently measured absolute accuracy.

Passed for this recorded location: cold starts away from the route origin, distinct-region selection, three fresh confirmation checks, forward tracking, independent cold restart near 85 m, and backward tracking to the origin. These are physical v6 results, not only archive simulations.

Not established: centimetre-level absolute accuracy, reliability across many independent starts, arbitrary off-route starts, kilometre-scale maps, different locations/conditions, or safe autonomous driving margins. A physical accuracy claim requires independently measured checkpoints and comparison of reported scanner positions with those checkpoints.

Recommended decision: retain the geometric cascade and thresholds. Address commanded-stop semantics and inspect derived-queue headroom separately; use measured checkpoints for the next accuracy assessment. Do not interpret a larger walking distance alone as a measurement of absolute accuracy.