NODEDC_MISSION_CORE/docs/audits/2026-09-19-physical-repeat-006-results.md

Physical repeat: 35.30 m and slow planning cloud

Date: 2026-09-19. Read-only diagnosis requested after the operator reported a successful approximately 35 m walk, stable video, and an unusually slow new cloud. No product code, device configuration, runtime, or Ops card was changed. The registration-stabilization changes remain loaded in the canonical 8000 service.

Identity and integrity

The new project is also named ja-sun-006; it must not be confused with the earlier failed run under that same name.

• Run: 27a20878-9697-4735-a86e-763de28e4b67.
• Query: 20260919T185447Z_viewer_live, generation 1.
• Reference: 20260911T085226Z_viewer_live; route 0–577, map 0–785, route-context-map/v1, 70,870 points.
• All 83 run artifacts matched their stored hashes. Raw MQTT and metadata hashes also matched the capture summary. Raw SHA-256: 0723c51b7555740e802db669597e42e3f21f4438ef909e1d6ee4e89284119a88.
• Browser diagnostics identify the deployed build app-D2qqIbEW.js.

Registration result

The complete 108-hypothesis stationary search finished at 18:55:38.734 UTC. After three independent fresh checks, tracking began at 18:55:51.852 UTC, approximately 38.47 s after the first pose. The first six calculation windows were stationary or nearly stationary; the operator moved after tracking began.

All 15 fresh-validation results were accepted. There was no registration rejection or receipt-gap transition during the walk. The final distance was 35.300 m (scanner's own reported distance 35.215 m). During moving windows, overlap was 96.14–98.14%; final stationary checks were 99.37% and 99.16%. Final inlier RMSE was 0.14384 m. This is surface agreement, not independent position accuracy.

Accepted transform yaw ranged approximately −3.028° to −2.831°, a span of 0.197°. These are map-frame alignment angles, not an absolute heading error. The large apparent rotation/fallback observed in the earlier run is not present in these saved transforms. Fresh fit worker wall times were 0.246–0.517 s; the latest input age at result admission was 0.311–1.845 s. Fits remain scheduled approximately every five seconds, not at native pose rate.

End-of-run chronology

Event	UTC
Last substantial pose increment (>3 cm between adjacent receipts)	18:56:43.810
Last accepted fit, distance 35.300 m	18:56:53.617
Correlated physical STOP response	18:56:54.625
Last raw point cloud	18:56:54.747
Registration freshness expired	18:57:00.643
Camera archive sealed	18:57:15.245
Input/session closed	18:57:44.599

The final lost/stale is after confirmed STOP and cessation of raw cloud input, not a loss while walking. The final report ends input-ended. Cleanup took longer than physical STOP; those are separate events and must not be conflated. Current acquisition is completed, receiver stopped, device STOP protocol-confirmed, source/control idle, physical command inactive. No STOP command was sent by this diagnostic work.

Why the cloud remains slow

The implementation still has separate ordinary-live and planning display paths. The previous change improved snapshot/poll cadence and alignment ownership, but did not turn the planning preview into a native-rate streaming view.

Layer	Evidence
Raw K1 receipts	1,013 poses and 1,013 point-cloud frames; both approximately 9.984 Hz
Raw cloud spacing	median 87.58 ms; p95 194.01 ms; maximum 1.001 s
Existing planning buffer applied offline to this raw recording	169 cloud frames, 1.663 Hz; median spacing 0.560 s, p95 0.935 s, maximum 1.207 s
Fresh map-fit/evidence layer	roughly one update per five seconds
Browser planning requests	next request starts 500 ms after the previous fetch/send finishes; this is not guaranteed 2 FPS

The offline buffer count is deterministic sampling analysis, not a measurement of the physical browser's rendering rate. The actual planning ingress consumed 1,000/1,013 cloud events (13 overflow), all 1,013 poses (zero overflow), and 941/942 camera frames (one overflow). These derived-queue counts do not indicate loss of the raw recording.

Source trace:

• missions/live_buffer.py:43–64: accepts cloud no more often than every 500 ms; 0.25 m voxel, up to 4,000 points/frame, 40 accumulated frames, 40,000 points in a snapshot. At the end, these 40 selected frames cover 23.61 s of history. This is historical accumulation, not a 23.61 s delay before adding a frame.
• missions/stationary_live.py:233–244: snapshots that same buffer on a separate 500 ms gate. Changing the poll interval does not remove the upstream sampling.
• missions/live_scene.py:25–43: clears/replaces the entire query/path and validation entities for each response. Green points belong to the previous accepted fit window; they intentionally do not follow every new cloud.
• PlanningLiveScene.tsx:25–42: sequential HTTP download, RRD handoff, then a 500 ms wait. No recorded per-frame fetch/decode/present acknowledgement exists for this physical pass, so exact browser delay and its dominant cost are unknown.
• Ordinary viewer/rerun_bridge.py:218–249,358–381 publishes each admitted point-cloud envelope to its live Rerun stream. That is not the planning accumulated-snapshot transport.

The ordinary receiver recorded zero decode errors and receipt-to-publish p95 85.212 ms. That metric belongs to the ordinary bridge, not planning's browser. The raw stream contains approximately one-second receipt stalls, so it should not be described as perfectly uniform. Nonetheless it supplies much more frequent data than the planning preview admits.

Conclusion: the complaint has a concrete implementation basis. There is no evidence that K1 SLAM itself needs multiple seconds per new cloud in this pass. The planning display remains deliberately downsampled and snapshot-driven. Exact user-visible latency is not reconstructible from the retained evidence.

Camera

Complete archive: 942 segments, 75,970,859 bytes. Init, index, all segment hashes, and stream digest verified. Browser diagnostics for the recording interval show successful playback without a decode-error/restart event. Single-threaded offline FFmpeg decoding completed with exit 0 and no corrupt-frame/macroblock diagnostic. It emitted 51 non-monotonic DTS lines plus two repeat notices at the null-output muxer. Therefore decoded pictures are not showing the earlier 005 corruption pattern, but timestamp cleanliness is not fully accepted. Exit 0 alone is not treated as proof of a flawless video path.

Decision and next step

Accept this as a successful short physical registration repeat, not as autonomous navigation acceptance. The slow view should not be dismissed as irrelevant: operators need a current view, and a future controller needs explicitly bounded pose freshness rather than the age of a five-second fit or a painted cloud.

Recommended implementation next: feed a bounded fresh cloud/pose display from the existing ingress independently of the numerical accumulation buffer; reuse the admitted live transport where compatible; apply the last accepted alignment to fresh data, keeping fit evidence separate. Preserve identity, segment, freshness, loss and no-authority fences. Do not simply increase ICP frequency or expand its buffer. Instrument receive → sample → export → browser-present and frame sequence so a physical display delay can actually be measured. Qualify this on the current saved recording before requesting another field walk. No such change was made in this diagnostic turn.

Runtime remained snapshot-runtime-564d78ca9bd1eb86e13bdce9b4b5be27, PID 99603, healthy on 8000. Temporary offline analyses and FFmpeg completed; no service, camera, replay publisher, or device-control job was started. Ops was read only.