LENS 15: CONSTRAINT RELAXATION — CROSS-LENS CONNECTIONS

=== TO LENS 06 (RELIABILITY / FAULT BOUNDARIES) ===

Lens 15 Row 5 moves the L1 safety layer off WiFi onto Hailo-8 local detection (26 TOPS, idle today on the Pi 5, YOLOv8n at 430 FPS, <10 ms, zero WiFi dependency). This changes Lens 06's failure-mode map: WiFi drop no longer disables reactive obstacle avoidance — only semantic goal-finding degrades. The single-point-of-failure analysis for Panda should note that Hailo-8 provides an independent local fallback for reactive safety. Open question Lens 06 should own: if Hailo-8 becomes L1, does sonar/lidar ESTOP demote to L0 tertiary, or do all three run in parallel voting? Lens 15 only flags the architectural slot; Lens 06 decides the voting rule.

=== TO LENS 13 (MARKET / POSITIONING AND MODEL SELECTION) ===

Lens 15's "60% accuracy + retry" scenario maps to a product positioning question: is Annie a premium product that justifies $400 in distributed GPU hardware to reach 90% accuracy, or a $150 Pi-only product competing on simplicity? The constraint relaxation analysis suggests these are two distinct products, not points on a continuous upgrade path.

Lens 15 Row 6 makes an explicit model-selection argument: Gemma 4 E2B is being asked to do four jobs where only one (semantic reasoning) actually requires a VLM. NanoOWL (102 FPS) and GroundingDINO 1.5 Edge (75 FPS, 36.2 AP zero-shot) are the VRAM-light detectors that should enter Lens 13's model-menu. Lens 13 should cross-reference this lens for the "zero-capex" framing — these detectors fit into existing Panda headroom, not next-purchase items.

The hardware trend argument also informs market timing: Annie can ship now at 60% on cheap hardware, or in 18 months at 90% on the same hardware. Dormant-hardware activation changes that math too — "now at 90% on hardware already in the house" becomes a third option.

=== TO LENS 16 (CAPEX vs OPEX / BUDGET DISCIPLINE) ===

Lens 15 introduces the zero-capex relaxation principle: before any purchase, audit owned-but-dormant assets. Lens 16's procurement flow should gain a mandatory gate step — "Is this compute already owned but idle?" — before evaluating new spend. The three-tier dormant audit (Hailo-8 on Pi 5, Beast DGX Spark, Orin NX 16GB) should appear in Lens 16 as the canonical example. Every "we need to buy X" proposal should first pass through: does Hailo-8, Beast, or Orin NX already cover this? Session-449 workload-idle status on Beast is the tell — a 128 GB GB10 box with no job has been absorbing opportunity cost for weeks.

=== TO LENS 24 (HARDWARE INVENTORY / ASSET ACCOUNTING) ===

Lens 15 exposes a gap in the inventory discipline — the original research framed constraints as WiFi + Panda + Titan, overlooking Hailo-8 (on the robot), Beast (always-on, idle), and Orin NX (owned, reserved). Lens 24 should explicitly track "owned but not currently serving a workload" as a first-class category, with a utilization column and a last-job timestamp. Three rows to add immediately: Hailo-8 AI HAT+ (26 TOPS, utilization 0%, last-job-for-nav never), Beast DGX Spark (128 GB, utilization 0%, last-job 2026-04-06 session 449), Orin NX 16GB (100 TOPS Ampere, utilization 0%, last-job never — reserved). Preventing this oversight from recurring is the point.

=== TO LENS 25 (ARCHITECTURAL EVOLUTION / FUTURE-PROOFING) ===

Lens 15 argues that dormant-hardware activation collapses the 18–24 month VRAM-headroom timeline to weeks. Lens 25 should split the roadmap into two parallel tracks: a near-term ACTIVATION TRACK (Hailo-8 → L1 safety; Beast → specialist models; Orin NX → future chassis) with earlier payoff and lower risk, and a long-term TREND TRACK (Snapdragon X Elite, Orin successors, VRAM-per-dollar curve). The activation track does not replace the trend track — it just collects the free wins before waiting on silicon vendors.

=== TO LENS 04 (SENSITIVITY SURFACE — retained from prior pass) ===

Lens 04 identified WiFi latency as having a discontinuous cliff edge at ~100 ms. Lens 15 Row 1 names the $8 fix (USB-C tether). Lens 15 Row 5 adds a second fix: even with WiFi intact, move the safety layer to Hailo-8 so the cliff no longer lies on the critical path. Two independent relaxations of the same cliff — one cable, one dormant chip — both zero-capex or near-zero.

=== SYNTHESIS: THE CONSTRAINT HIERARCHY (REVISED) ===

Reading Lenses 04, 06, 13, 16, 24, and 25 together with Lens 15 produces a revised hierarchy:

TIER 0 (NEW — relax immediately, $0, already owned): Dormant-hardware activation. Hailo-8 → L1 safety; Beast → overflow workloads; Orin NX → future chassis slot.

TIER 1 (relax immediately, free): Speed cap at 0.3 m/s. Eliminates 60% of documented failure modes with a config change.

TIER 2 (relax soon, $8): USB tether for Panda-to-Pi link. Eliminates WiFi cliff edge for the connections that still need the network.

TIER 3 (relax at product boundary): Accuracy target from 90% to 60% + retry. Eliminates Panda GPU dependency entirely.

TIER 4 (relax via right-sized models, $0 software): Open-vocab detectors — NanoOWL / GroundingDINO 1.5 Edge / YOLO-World-S — absorb goal-finding and scene classification. Gemma 4 E2B stays resident for true semantic reasoning only.

TIER 5 (relax with hardware cycle, 18–24 months): VRAM per model. Snapdragon X Elite successor integrates VLM and detector on one edge board.

TIER 6 (relax architecturally, ~$0 software): Text output layer. SigLIP embedding bypass + learned motor policy. Currently blocked by llama-server API surface, not by compute.