LENS 04 — CROSS-LENS CONVERGENCE NOTES Sensitivity Surface: "Which knob matters most?" ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ MAJOR UPDATE (2026-04-16): WIFI CLIFF SPLIT INTO TWO PATHS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ The Session 119 hardware audit (2026-04-16) changes the central sensitivity finding of this lens. The WiFi cliff edge is not one bar — it is two: - WiFi latency (semantic path) — still 95% cliff-edge coral. VLM queries ("where is the kitchen?", "what room?", "is path blocked?") traverse WiFi to Panda. No local alternative exists. - WiFi latency (safety, post-Hailo) — now 15% green, MITIGATED. Activating the idle Hailo-8 AI HAT+ on Pi 5 (26 TOPS, YOLOv8n at 430 FPS, <10 ms latency) gives obstacle detection a fully local path. WiFi stops being on the critical path for collisions. IROS paper arXiv 2601.21506 validates this dual-process split experimentally for indoor robot nav: fast local System 1 + slow remote System 2 delivers 66% latency reduction and 67.5% task success vs 5.83% for VLM-only. Annie's Pi + Panda topology maps onto this pattern without a single hardware change. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CONVERGENCE WITH LENS 01 (Temporal Surplus) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Lens 01 identified temporal surplus as the system's primary free resource: 58 Hz VLM inference leaves 42 ms of "unused time" per second relative to a 15 Hz nav loop. Previously, WiFi latency above 100ms was the single mechanism that eliminated this surplus entirely. UPDATED IMPLICATION: With Hailo-8 active, the temporal surplus chart should mark a TWO-ZONE cliff. The safety-path cliff is removed — L1 obstacle detection runs regardless of WiFi state. The semantic-path cliff remains at 100ms total loop latency for VLM queries, but now degrades gracefully: Annie can still move safely (L1 Hailo) while her higher cognition pauses waiting for Panda. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CONVERGENCE WITH LENS 06 (Composition / Layering) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ The sensitivity surface is now layered, not flat. Lens 06's composition framing maps directly onto the new reality: L1: Safety — Hailo-8 YOLOv8n, Pi 5 local, 30+ Hz, WiFi-independent L2: Nav — Gemma 4 E2B goal tracking, Panda, 15-27 Hz, WiFi-bound L3: Scene — Gemma 4 E2B multi-query, Panda, 5-9 Hz, WiFi-bound L4: Strategy — Gemma 4 26B planning, Titan, 1-2 Hz, WiFi-bound A parameter's sensitivity depends on WHICH layer it sits in. WiFi is lethal for L2-L4 but irrelevant for L1. Lens 04's bar chart is really a projection of Lens 06's layer stack onto a single axis; the split of the WiFi bar makes that projection honest. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CONVERGENCE WITH LENS 10 (Failure Pre-mortem) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Lens 10 named WiFi as the "boring" production failure mode — the one that never appears in integration tests (run on a clean channel) but causes incidents in production (shared household WiFi, microwave interference, neighboring networks). Lens 04 originally provided the mechanism: WiFi creates a discontinuous failure boundary at ~100ms. UPDATE: Lens 10's pre-mortem should now split the WiFi failure into two incident classes: - "WiFi blind spot" (pre-Hailo): WiFi glitch → VLM stale → collision. Severity: SAFETY. Blocking. - "WiFi stutter" (post-Hailo): WiFi glitch → semantic query pauses → Annie says "one moment" before answering "what room is this?". Severity: UX. Non-blocking. The failure mode class changes from "catastrophic safety" to "latency annoyance". Lens 10 should be updated to reflect that Hailo-8 activation converts a Sev-1 into a Sev-3. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CONVERGENCE WITH LENS 11 (Investment Priority) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Lens 11 ranks upgrades by value/cost ratio. Hailo-8 activation now ranks #1 by a large margin: - Hardware cost: 0 (already installed, idle) - Time cost: LOW (HailoRT/TAPPAS, well-documented) - Risk: LOW (no change to existing VLM pipeline; new layer runs alongside) - Value: HIGH (removes Sev-1 failure mode from the safety surface) - Side effects: frees WiFi tuning from "safety prerequisite" to "UX optimization"; enables future L1 ESTOP upgrades. Lens 11 should surface Hailo-8 activation ahead of wired Ethernet, 5GHz dedicated channel, or any VLM-side optimization. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CONVERGENCE WITH LENS 13 (VLM-primary vs Lidar-primary) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Lens 13's VLM-primary vs Lidar-primary debate has a third option now: Hailo-primary for safety, VLM-primary for semantics. The debate was framed as "which single source of truth drives nav?" — the new architecture makes it "which source drives WHICH decision?": - Reflexive avoidance: Hailo-8 bounding boxes (pixel-precise, local) - Door/doorway traversal: VLM (semantic, understands "go through") - Lidar: still valuable for map-building and long-range awareness - Sonar: redundant safety net below Hailo's minimum detection range Lens 13's binary framing is the wrong question. The right question (from Lens 06 Composition) is how to compose three complementary sensing modalities, not which one wins. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CONVERGENCE WITH LENS 20 (Load Balancing Across Compute) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Lens 20 tracks compute utilization across Pi/Panda/Titan. Hailo-8 activation shifts load off Panda's GPU (obstacle detection was ~1 Hz VLM prompt on Panda) onto the Pi's NPU (free silicon). Before: Pi CPU ~40%, Pi NPU 0%, Panda GPU 60%. After: Pi CPU ~40%, Pi NPU ~20%, Panda GPU ~55% (VLM keeps semantic). The WiFi pipe carries less traffic because L1 obstacle queries no longer round-trip. Panda has more headroom for multi-query semantic tasks. This is a pure Pareto improvement in the load-balance picture. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CONVERGENCE WITH LENS 25 (Blind Spot / Idle Hardware) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ This is the lens that PRODUCED the finding. Lens 25's blind-spot inventory flagged the Hailo-8 AI HAT+ as idle hardware that had been invisible to the nav architecture. Lens 04's bar chart made the cost of that blind spot quantitative: the WiFi cliff at 95% coral was partly a consequence of not using hardware we already owned. Activating Hailo-8 closes the blind spot AND shrinks the cliff. This is the canonical example of why Lens 25 exists — idle hardware is not neutral, it is a negative signal about what the system is NOT using to defend itself. Lens 25 should reference Lens 04's new "safety, post-Hailo" bar as evidence that blind-spot audits produce measurable sensitivity reductions, not just "nice to have" opportunities. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CONVERGENCE WITH LENSES 01, 17, 18, 23 (Multi-Query Pipeline) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Multiple lenses converge on multi-query as the highest-value lowest-risk upgrade. Lens 04 adds quantitative grounding: VLM rate above 15Hz is sensitivity-insensitive (20% bar, green), meaning the multi-query dispatch cycles 6 slots at 58Hz but each slot still gets ~10Hz — safely above the 15Hz floor where temporal consistency breaks down. With Hailo-8 as L1, multi-query's slot allocation can be even more semantic-heavy: the VLM no longer needs to spend a slot on "is the path blocked?" (L1 handles that at 30+ Hz). Freed slots can be spent on scene classification, landmark identification, or verbal goal tracking — pure semantic enrichment. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ MOTOR SPEED / TURN OVERSHOOT — UNCHANGED ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Motor speed for small-angle turns (90% bar, coral) remains the second cliff edge. The 5° → 37° overshoot at speed 30 is documented in MEMORY.md (session 83). Hailo-8 does not help here — this is a motor physics / coast-prediction problem, not a perception problem. Lens 21 (voice-to-ESTOP gap) and Lens 14 (VLM-primary vs lidar-primary) cross-references still apply. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SONAR ESTOP THRESHOLD — REFRAMED ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Sonar ESTOP at 250mm (85% coral) is a design constant. With Hailo-8 as the primary L1 safety layer, sonar shifts role from "primary safety net" to "redundant backstop below Hailo's minimum detection range". This may relax the sensitivity — sonar can be tuned less aggressively because it is no longer the only safety signal. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PARAMETERS CONFIRMED INSENSITIVE (green bars) — UNCHANGED ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - SLAM map resolution (30%) - Multi-query cycle count (25%) - VLM rate above 15Hz (20%) - WiFi latency (safety, post-Hailo) (15%) ← NEW green entry ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ UPDATED PRIORITY ORDER FROM SENSITIVITY ANALYSIS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1. ACTIVATE HAILO-8 FOR L1 SAFETY — NEW #1. Removes the only Sev-1 failure class from the sensitivity surface. Zero hardware cost. 2. MOTOR SPEED / COAST PREDICTION — Fix _imu_turn overshoot for small angles before relying on VLM-primary fine corrections. 3. WIFI SEMANTIC PATH — Latency watchdog + adaptive degradation on L2/L3 VLM queries. No longer safety-blocking after #1, but still a UX win. 4. EMA ALPHA — alpha=0.3 is good; add variance-tracking scene-change detection to switch alpha dynamically. 5. PROMPT FORMAT — Freeze the two-token format. Any changes require regression test of all three parser strategies. 6. EVERYTHING ELSE — Rate, resolution, cycle count: leave them alone. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CROSS-LENS FLAGS (send these updates to other lenses) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Lens 06 (Composition): Add L1 Hailo layer to the stack diagram. Lens 10 (Pre-mortem): Split WiFi failure into "blind spot" vs "stutter". Lens 11 (Investment): Rank Hailo-8 activation as #1 upgrade. Lens 13 (VLM vs Lidar): Reframe as 3-source composition, not binary. Lens 16 (Composition): Cross-reference the layered sensing stack. Lens 20 (Load balance): Update Pi NPU utilization from 0% to ~20%. Lens 25 (Blind Spot): Cite this lens as evidence that idle-hardware audits produce measurable sensitivity reductions.