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.