LENS 23 — CROSS-LENS CONNECTIONS: Energy Landscape --- LENS 01 (Constraint Hierarchy) Lens 01 maps a 10-layer constraint hierarchy from physics at the bottom to convention at the top. Lens 23 reframes that hierarchy as an activation energy chart: the constraints at the bottom (physics, hardware) are expensive to change (SLAM at 85%, WiFi at 75%), while constraints near the top (convention, code structure) are cheap to change (multi-query at 15%). The key cross-lens insight: Lens 01 identifies which constraints are dissolved vs. fixed; Lens 23 quantifies what it costs to dissolve each one. Together they produce a priority ordering — start with the constraints that are both high-leverage AND low activation energy. Multi-query satisfies both criteria. SLAM satisfies only the first. The temporal surplus concept from Lens 01 also connects directly: at 54 Hz, 37 frames per second are "free" beyond the minimum nav loop rate. Multi-query is the mechanism that spends that surplus productively. Zero activation energy is required to access it — the hardware already produces it. This makes multi-query a "free tier" of the energy landscape: it unlocks capability from slack that already exists, rather than requiring new resources to be acquired. LENS 15 (Constraint Relaxation) Lens 15 identifies three constraints relaxable TODAY for under $200: speed (0 cost), accuracy target (0 cost), WiFi (8 USD cable). Lens 23 reframes these as activation energy reductions. Dropping speed to 0.3 m/s does not just relax a constraint — it lowers the activation energy of WiFi reliability from 75% to approximately 40%, because at 0.3 m/s a 100ms spike causes only 3cm positional uncertainty instead of 10cm. Relaxing the accuracy target from 90% to 60% + retry removes the Panda dependency entirely, collapsing the hardware cost barrier from 60% to approximately 20%. The constraint relaxations in Lens 15 are therefore not independent — they are multiplied through the energy landscape. Lens 23 provides the "why now" ordering that Lens 15 does not: speed first (zero cost, immediate effect on multiple barriers), then accuracy relaxation, then tether option. Each step funds the next by lowering the apparent risk of the step after it. LENS 22 (SLAM Plateau as Skill Discontinuity) Lens 22 argues that SLAM represents a "skill-type discontinuity" — the team must shift from software engineering to systems integration, and that transition requires new muscle memory, not just more hours. Lens 23 quantifies why that discontinuity makes SLAM's activation energy so high (85%): it is not just complex code, it is a category of work that the project has not yet institutionalized. The SLAM sessions consumed disproportionate time relative to their capability gain precisely because each session encountered a different class of problem (IMU frame, Zenoh wire protocol, C++ queue size). The energy barrier is not a single wall but a series of walls, each requiring a different tool to clear. Lens 22's prescription — "treat SLAM as infrastructure, not as a feature" — maps onto Lens 23 as: the activation energy for SLAM can only be lowered by institutionalization (dedicated sessions, documented recipes, repeatable deployment), not by trying harder on any given session. Meanwhile, multi-query's 15% barrier is due to a single wall (code change) with well-understood tooling. The practical conclusion: build multi-query first, let it produce value, and use that credibility to justify the infrastructure investment that SLAM requires. SECONDARY CONNECTIONS Lens 04 (WiFi cliff edge) — Lens 23 inherits the 75% WiFi barrier directly from Lens 04's finding that the cliff edge appears at 100ms. The barrier is labeled "uncontrollable" because it is environmental: the adopter cannot guarantee their home WiFi channel quality. This is why the tether option from Lens 15 is the only engineering-solvable path to lowering it. Lens 03 (llama-server embedding blocker) — Lens 03 identifies the embedding extraction blocker as the highest-leverage addressable dependency in the architecture. Lens 23 maps that as a 55% barrier (amber) — significant but not systemic. The distinction from coral barriers: embedding extraction has a clear solution (deploy SigLIP 2 ViT-SO400M, ~800MB VRAM, ~0 USD software cost). The activation energy is not in the decision but in the operational effort of deploying a second model on Panda alongside the VLM. Lens 07 (positioning on capability/cost scatter plot) — Lens 07 shows Annie targeting the "edge + rich" quadrant that no current competitor occupies. Lens 23 explains why that quadrant is empty: it requires crossing multiple adoption barriers simultaneously. The energy landscape suggests the path into that quadrant is staged — multi-query first (low barrier, high richness), voice integration second (low barrier, high expressiveness), SLAM third (high barrier, high spatial capability). Each stage provides value that funds the credibility for the next stage. LITERAL-ENERGY CROSS-LENS CONNECTIONS (new, 2026-04-16) LENS 06 (Hardware Topology) Lens 23 prices two physical hardware facts that Lens 06 owns: (a) the Hailo-8 AI HAT+ is physically installed on Pi 5 and currently idle for navigation (~2 W typical continuous inference, 26 TOPS, YOLOv8n @ 430 FPS); (b) Beast (GB10 DGX Spark) has been always-on since session 449 (2026-04-06) at ~40–60 W idle. Lens 23 converts these into activation- energy bars: Hailo safety path = 13% barrier (power-equivalent metric), Beast ambient workloads = 2% marginal. Lens 06 should cite Lens 23's energy framing when justifying why the Hailo placement is durable and why Beast is the correct deployment target for ambient workloads. Shared claim anchor: 7× power reduction moving safety from Panda+WiFi → Hailo. LENS 19 (Hailo Activation / L1 Safety Layer) Direct dependency: Lens 19 is the implementation plan for the ~2 W Hailo path that Lens 23 prices energetically. If Lens 19 ships, Lens 23's "Hailo safety path" bar (13% activation energy) converts from opportunity to deployed. Recommended handoff: Lens 19 should cite Lens 23's 7× reduction + 13 W avoided + minutes-of-battery-reclaimed framing as the energy justification complementing Lens 19's latency justification (local <10 ms vs WiFi 25–300 ms). LENS 24 (Beast Sunk-Cost / Ambient Workload Scheduling) Direct inheritance: Lens 23 introduces the sunk-cost framing (always-on-idle = 0 W marginal); Lens 24 should extend it into a scheduling policy. Open question for Lens 24: does the sunk-cost argument survive once Beast starts doing meaningful concurrent work (thermals, fan noise, breakeven where idle ≠ free)? Lens 23 asserts 0 W marginal holds up to moderate concurrent load; Lens 24 should define the breakpoint and produce the "what goes on Beast" rubric. LENS 15 (WiFi / Constraint Relaxation) — EXTENSION Lens 15 already prices WiFi as a latency/jitter problem. Lens 23 adds a second cost axis: WiFi is also a ~3–5 W power tax on both the Pi 5 transmitter and the Panda receiver whenever it carries the safety-layer frame stream. Moving obstacle detection onto Hailo removes WiFi from the safety path twice over — latency AND power. The $8 tether option (Lens 15) is not the only WiFi-mitigation; the Hailo activation (Lens 19, priced in Lens 23) eliminates the safety-path WiFi dependency entirely without any cable. SYNTHESIS NOTE FOR ASSEMBLY Lens 23 provides the "when" and "why" ordering that the research document treats as a simple linear sequence. The energy landscape reveals that Phase 2a (multi-query) and Phase 1 (SLAM) are not steps on the same path — they are in different energy classes. The assembly should position Lens 23 findings as the sequencing rationale that connects the technical architecture (Lens 01, Lens 07) to the adoption reality (Lens 04, Lens 15, Lens 22). The key synthesis point: a technically correct architecture that requires crossing 85% activation energy barriers before delivering any value will fail adoption. Multi-query delivers value at 15% activation energy and funds the trust that makes the 85% barrier crossable.