LENS 24 — GAP FINDER: Cross-Lens Connections "What's not being said — and why?" --- MANDATORY CROSS-REFERENCES (Lens 03, Lens 10, Lens 13) LENS 03 — Dependency Mapper: "What does this require that it doesn't name?" Lens 03 identified the llama-server embedding blocker as the highest-leverage addressable dependency in the entire research. Phase 2d requires embedding extraction from the VLM, but llama-server doesn't expose intermediate embeddings for multimodal inputs cleanly. The workaround is a separate SigLIP 2 model on Panda — an unlisted prerequisite. Lens 24 Gap 1 (camera-lidar extrinsic calibration) is the same pattern one tier lower. Phase 2c requires a calibrated camera-lidar transform, but the research never lists calibration as a prerequisite. Both gaps are hidden prerequisites — dependencies that block a specific phase without being named in that phase's prerequisite list. Together, Lens 03 and Lens 24 identify a systematic documentation blind spot: the research lists hardware prerequisites (SigLIP on Panda) and software prerequisites (Phase 1 SLAM deployed) but omits physical setup prerequisites (calibration completed). Physical prerequisites don't appear in software dependency graphs, which is why they go unlisted. LENS 10 — Post-Mortem Reconstructor: "What will the retrospective say went wrong?" Lens 10 surfaced the retrospective finding: "we built the fast path, forgot the slow path." The specific example cited was the SLAM plateau — building fast scan-matching without the slow-path loop closure and recovery protocols that make SLAM reliable over days and weeks of operation. Lens 24 extends this pattern across the entire research. Every item in the 18-gap inventory is a slow-path item: hallucination recovery, map corruption, WiFi degradation, battery management, emergency behavior, long-term drift correction. The fast path is the nominal case. The slow path is every named gap. The most predictive cross-reference: Lens 10 identified that the retrospective always surfaces the slow-path gaps as the "obvious" things that should have been designed from day one. Lens 24's Gap 2 (VLM hallucination recovery) is the strongest candidate for this category — confidence accumulation without a cross-validation gate will produce a memorable failure (robot accelerates into a wall) that will appear in the retrospective as "we should have checked the VLM against the lidar before increasing speed." LENS 13 — Assumption Archaeologist: "What does this treat as given that isn't?" Lens 13 surfaces buried assumptions — things the research treats as background facts that are actually design decisions with alternatives. The most important buried assumption that Lens 24 exposes: the research assumes the fusion rule "VLM proposes, lidar disposes" is universally correct. This assumption is stated as a design principle (Part 3) and then applied throughout the architecture. Lens 24 Gap 17 (glass surfaces) directly falsifies this assumption: there exists a physical scenario where lidar is wrong and VLM is right, and the fusion rule silences the correct sensor. The assumption that "no high-speed agents in a home" (from the Waymo section, dismissing MotionLM) is another buried assumption that Lens 13 would surface and Lens 24 extends. The assumption leads directly to Gap 5 (dynamic obstacle tracking) being entirely absent from the architecture. --- ADDITIONAL CROSS-LENS CONNECTIONS LENS 04 — Latency/Bandwidth Analyst Lens 04 identified the WiFi cliff edge at 100ms. Lens 24 Gap 3 (WiFi fallback) is the recovery-path complement: Lens 04 mapped the failure mode, Lens 24 identifies the missing recovery protocol. A complete system needs both: the latency characterization (Lens 04) AND the degradation hierarchy (Lens 24 Gap 3). Without the degradation hierarchy, the latency data is a warning without a response. LENS 07 — Competitive Landscape Lens 07 identified Annie targeting the empty "edge+rich" quadrant — local compute with rich semantic understanding. Lens 24 reinforces this framing: the gaps inventory is the price of admission for the "rich" half of that quadrant. Any competitor attempting to occupy the same quadrant faces the same 18 gaps. The gaps are not Annie-specific — they are the unsolved problems of the entire "edge+rich" design space. This means that solving any gap (particularly Gap 17, the glass surface problem, and Gap 2, hallucination recovery) creates durable differentiation. LENS 11 — Adversarial Reviewer Lens 11 identified the "open-source race to zero" as a strategic threat — competitors will replicate the fast path. Lens 24 shows that the slow path is where the moat is. A system that handles hallucination recovery, glass surfaces, and furniture rearrangement is genuinely harder to replicate than one that does multi-query VLM dispatch. The 18-gap inventory is not a list of problems — it is a list of defensible advantages for the team that solves them first. LENS 15 — Resource/Constraint Analyst Lens 15 identified: "Last 40 percent accuracy costs 10x hardware." Lens 24 Gap 9 (cost-benefit analysis) is the implementation of this insight at the phase level. The research proposes 5 phases (2a through 2e) with decreasing probability of success (90% down to 50%). Lens 15's observation suggests the last 2 phases (2d and 2e, embedding extraction and AnyLoc loop closure) may cost disproportionate implementation effort for marginal navigation improvement. Gap 9 identifies the missing analysis that would answer this question — the research never specifies what threshold of navigation success rate improvement justifies proceeding to the next phase. LENS 16 — Memory/Storage Analyst Lens 16: "Build the map not to navigate — build it to remember." Lens 24 Gap 8 (privacy of spatial memory) is the dark side of this insight. If the map is built to remember — semantically rich, embedding-indexed, timestamped — then it is also a detailed record of domestic life. Lens 16 identified the map as a positive capability (persistent semantic memory of the home). Lens 24 identifies it as a privacy liability. Both analyses apply simultaneously to the same artifact. LENS 21 — Safety/Failure Mode Analyst Lens 21 identified the voice-to-ESTOP gap: "Mom can't say 'Stop!' with under 5 seconds latency." Lens 24 Gap 16 (emergency behavior) is the systemic version of this observation. The ESTOP covers proximate physical hazards (obstacle at 250mm). Emergency behavior covers distal hazards (smoke in the kitchen, medical alert in the bedroom). Lens 21 + Lens 24 together identify a safety ladder with a gap in the middle: immediate physical ESTOP (covered) → voice interrupt (latency problem, Lens 21) → whole-home emergency response (not specified, Lens 24) → nothing above strategic tier. LENS 26 — Synthesis/Integration Lens 26 identified 3 branches converging toward bypassing the text-language layer as the highest-value change. Lens 24 Gap 10 (acoustic localization) is the positive case for this bypass: voice-directed navigation bypasses the entire VLM goal-finding pipeline for the specific case where the user speaks the goal's location. "I'm in the kitchen" → acoustic bearing + natural language → direct waypoint. No visual goal-finding, no place recognition, no semantic map query required. This is the practical implementation of Lens 26's "bypass text-language layer" insight in the navigation domain. --- SYNTHESIS: WHAT THE GAPS COLLECTIVELY REVEAL The 18-gap inventory is not a list of bugs in the research. It is a map of the implicit assumptions that define the research's scope. Every gap corresponds to an assumption: - Calibration is assumed done (Gap 1) - VLM is assumed reliable enough (Gap 2) - WiFi is assumed stable (Gap 3) - Map is assumed uncorrupted (Gap 4) - Obstacles are assumed static (Gap 5) - Lights are assumed on (Gap 6) - Battery is assumed sufficient (Gap 7) - Surfaces are assumed opaque (Gap 17) Each assumption is reasonable for a research demonstration. Each assumption is fragile in daily home operation. The cross-lens pattern is consistent across Lens 03, 10, 13, 21, and 24: the research is precise about what it covers and silent about what it excludes. The silences are not random — they cluster around recovery, edge cases, and human factors. These are the three categories that separate a research prototype from a deployed home robot. --- UPDATE — 2026-04-16: CROSS-LENS CONNECTIONS FROM THE SESSION 119 HARDWARE AUDIT The session 119 hardware audit (2026-04-16) surfaced three new cross-lens connections that sharpen existing ties and introduce one new standing tie (Lens 25). LENS 04 — Latency/Bandwidth Analyst (UPDATED) Lens 04's WiFi cliff-edge finding (100 ms) originally terminated in Lens 24 Gap 3 as an unsolved recovery-path problem. The session 119 audit closes this termination. The Hailo-8 AI HAT+ on the Pi 5 (26 TOPS, <10 ms local inference, zero WiFi dependency) means the safety loop no longer traverses the WiFi link at all. Gap 3 reclassifies to "mitigation path identified," and a new Gap 3a (Hailo-8 integration action item) now carries the residual work. Lens 04 should be updated to note: the latency cliff no longer gates the safety layer once Hailo-8 is activated — it only gates the semantic layer, which is acceptable degradation (the robot remains safe but loses goal-tracking until WiFi recovers). LENS 15 — Resource/Constraint Analyst (UPDATED) Lens 15's "last 40% accuracy costs 10x hardware" maps onto the newly-visible inventory layer. Beast (idle 128 GB DGX Spark) and the Orin NX 16GB (100 TOPS, unmounted) are the "10x hardware already owned" that the original analysis never registered. The IROS dual-process paper (arXiv 2601.21506, 66% latency reduction) demonstrates that the "last 40% accuracy" can sometimes be had at 0x *new* hardware cost when existing assets are re-deployed. Lens 15 should incorporate an owned-hardware line item into its constraint models — counting idle accelerators as zero-cost capacity rather than treating them as unavailable. LENS 21 — Safety/Failure Mode Analyst (UPDATED) Lens 21 previously identified the voice-to-ESTOP gap and the safety-ladder gap (immediate ESTOP → voice interrupt → whole-home emergency → nothing above strategic). The Hailo-8 activation inserts a new rung below the existing immediate ESTOP: a 430 FPS local vision ESTOP that triggers on YOLOv8n person/obstacle detection before lidar range-ring activation. This is a safety-positive change that should be reflected in Lens 21's ladder diagram. Lens 21 should also flag the internal contradiction surfaced by the inventory gaps: a system that lists "WiFi fallback unsolved" as a safety gap while a 26 TOPS accelerator sits idle on the same board is internally inconsistent — the safety layer was under-specified because the capacity audit was skipped. LENS 25 — Process Gaps / Meta-Methodology (NEW PRIMARY TIE) This is the most important new cross-reference. The meta-gap documented in the updated Lens 24 narrative — no owned-hardware audit was performed before designing workloads — is exactly the methodology failure Lens 25 is designed to surface. Recommend Lens 25 add an "Owned-Hardware Inventory Audit" as a standing pre-design ritual: Before any new compute tier is proposed, enumerate every powered-on accelerator in the household and explicitly state: (a) which tier hosts the new workload, or (b) which owned accelerator is retired by the new proposal, or (c) why no owned accelerator can host the workload. The three inventory items (INV-1 Hailo-8, INV-2 Beast, INV-3 Orin NX) become the seed entries of the standing inventory. Every future lens that proposes a new workload should consult this inventory first. HARDWARE FACTS REGISTERED IN THIS UPDATE - Hailo-8 AI HAT+ on Pi 5: 26 TOPS, ~430 FPS YOLOv8n, <10 ms inference, zero WiFi dependency - Beast (2nd DGX Spark): 128 GB unified memory, always-on, workload-idle since 2026-04-06 - Orin NX 16GB: 100 TOPS Ampere, owned, no carrier board yet - IROS dual-process paper (arXiv 2601.21506): fast reactive + slow semantic = 66% latency reduction, 67.5% vs 5.83% navigation success rate --- END OF CROSS-LENS ANALYSIS — LENS 24