LENS 10 — FAILURE PRE-MORTEM: CROSS-LENS CONNECTIONS ============================================================================== PRIMARY CONNECTIONS ============================================================================== LENS 04 (Connectivity & Latency Constraints) Lens 04 identified the WiFi cliff edge at 100ms — the point at which VLM RTT degrades from usable to safety-critical. It correctly quantified the risk. Lens 10 shows what happens when the quantified risk is never mitigated. The pre-monsoon humidity increase that drives 8% frame timeout in May 2026 is exactly the "congested home WiFi" scenario Lens 04 modeled. The connection is causal: Lens 04 diagnosed the hazard; Lens 10 records the injury. Actionable implication: Lens 04's WiFi cliff edge finding should have generated a direct implementation requirement — "implement circuit breaker before Phase 2a ships." It didn't. The gap between a risk documented in a research lens and a mitigation implemented in code is where the pre-mortem failure lives. LENS 13 (Caregiving Context / Mom's Usage Patterns) Lens 10's August 2026 event — Mom stops using Annie — is the concrete realization of Lens 13's core concern: that the system's technical success metrics may be decoupled from its real-world adoption by a 60+ year old non-technical user in a domestic caregiving context. 94% navigation success rate (all hours) masked ~75% success rate (7–9pm). Lens 13 would have caught this: it understands that Mom's usage is time-clustered (tea time, TV time, pre-bed), not uniformly distributed. A per-user per-hour breakdown is a caregiving context requirement, not an optional metric refinement. The trust recovery problem is also Lens 13 territory: habits form in ~2 weeks of consistent failure. Once Mom stops asking Annie, re-engagement requires active effort, not just technical fixes. LENS 21 (Voice Control & Safety Gap) Lens 21 flagged the voice-to-ESTOP latency gap: Mom cannot say "Stop!" and have Annie respond within 5 seconds in the current architecture. The glass door incident is the realized version of this risk. ESTOP fired at 80mm — within the physical safety margin, but too late to prevent the door frame collision. The gap between sensor blind spot (both VLM and lidar wrong) and physical safety margin (ESTOP at 80mm) was narrower than the system design assumed. The connection: Lens 21 identified the slow path in the voice safety loop. Lens 10 shows that the slow path in the sensor fusion loop has the same problem. Both are symptoms of the same design deficit: the fast path was specified; the slow path (degraded mode, failure recovery, safety margins) was left unspecified. ============================================================================== SECONDARY CONNECTIONS ============================================================================== LENS 01 (Constraint Hierarchy) The glass door failure reveals a hidden constraint that wasn't in the explicit hierarchy: "sensors must have non-overlapping blind spots." The 4-tier fusion architecture (VLM + lidar + IMU) assumes sensor independence. Glass violates this — it makes VLM and lidar correlated failures rather than independent ones. Lens 01's constraint hierarchy should include a row for "sensor diversity guarantee" above the "VLM proposes, lidar disposes" rule. LENS 02 (Abstraction Leaks) The Pico RP2040 REPL crash is, per Lens 02, the canonical invisible abstraction leak: a hardware failure mode that propagates upward through the stack and surfaces as SLAM map corruption at a different layer entirely. The pre-mortem shows that abstraction leaks compound: REPL crash → IMU dropout → EKF divergence → SLAM corruption → Phase 2c data loss → 3-week schedule slip. Each layer passed the failure to the next without catching it. A leak detector (IMU watchdog) at the lowest layer would have broken the chain. LENS 03 (Dependency Graph) Lens 03 identified the llama-server embedding blocker as the highest-leverage addressable dependency. Lens 10 shows a related structural failure: the Phase 2 roadmap was presented as a DAG but was actually a linear chain (2c → 2d → 2e, all gated on Phase 1 SLAM). Lens 03's dependency analysis should have flagged this — a chain is a DAG with maximum fragility. The mitigation: either parallelize (find work that doesn't require SLAM) or explicitly name the chain as a single-point-of-failure and protect it. LENS 07 (Market Positioning) Lens 07 plotted the 12-system scatter: Annie targeting the empty "edge+rich" quadrant. The October 2026 pivot to cloud VLM routing through Titan abandons the "edge" axis — the exact differentiator that positioned Annie away from commodity solutions. The pre-mortem failure (WiFi unreliability) directly caused the positioning failure (edge thesis abandoned). This is the meta-failure: a technical constraint not mitigated at the infrastructure level forced an architectural retreat that undermined the product's strategic positioning. LENS 08 (Neuroscience Analogies) Lens 08 introduced the hippocampal replay mechanism — the "slow path" that consolidates fast perception into durable memory. The pre-mortem shows that the system built the equivalent of the visual cortex (fast 58Hz VLM perception) without building the hippocampus (slow path consolidation, recovery, graceful degradation). The neuroscience analogy is precise: a brain with a functional visual cortex but no hippocampus cannot learn from failure. It keeps making the same mistake. Annie hit the glass door once. Without a slow-path memory mechanism, it would hit it again. LENS 11 (Red Team Brief) Lens 11's "boring failure" adversarial perspective — the $200 robot vacuum with a $5 depth sensor — becomes more credible after the pre-mortem. The glass door incident and WiFi freezes are exactly the attacks a red team would use: "show me what happens when WiFi degrades" and "show me what happens at a glass surface." The red team brief from Lens 11 should have generated test scenarios, not just adversarial framing. LENS 14 (Academic vs. Reality Gap) Lens 14 identified that the research describes the Waymo pattern (lidar- primary, camera-semantic) but implements the opposite (VLM-primary). The pre-mortem's glass door failure is a direct consequence of the VLM-primary bet: Waymo's lidar-primary approach would not have been fooled by a transparent surface. This is not an argument against VLM-primary for Annie — the constraints are different. But it confirms Lens 14's warning: when you deviate from the academic literature's primary sensor, you inherit failure modes that the literature didn't design around. LENS 15 (Hardware Constraint Relaxation) Lens 15 argued that "the last 40% accuracy costs 10x hardware" and identified 3 constraints relaxable for under $200. The VRAM ceiling failure (Phase 2d abandoned because SigLIP 2 + VLM exceeded Panda's 4GB) is exactly the scenario Lens 15's hardware analysis should have caught. Adding a second GPU or upgrading Panda's VRAM before shipping Phase 2d would have cost less than the schedule delay from abandoning the phase. LENS 22 (SLAM Plateau) Lens 22 identified the SLAM plateau as a skill-type discontinuity — infrastructure work, not ML tuning. The pre-mortem's September 2026 Phase 2c stall confirms this: SLAM instability (Zenoh fix undeployed, MessageFilter queue, IMU watchdog absent) is infrastructure debt that blocks all downstream ML work. Lens 22's "build the map not to navigate — build it to remember" insight implies that map reliability must be treated as a hard infrastructure requirement before any semantic layer is built on top. The pre-mortem shows what happens when this ordering is violated. LENS 26 (Convergence — Bypass the Text Layer) Lens 26 argued that bypassing the text-language decoding layer (using embeddings instead of "LEFT MEDIUM" tokens) is the highest-value architectural change. Phase 2d (embedding extraction) was the implementation of this insight. It was the first phase abandoned. The pre-mortem records the irony: the highest-value capability was the first to be cut when VRAM constraints forced a decision. The lesson: highest-value capabilities should also be the most protected from resource cuts — but they were the least protected because they were the furthest from shipping. ============================================================================== ADDED CONNECTIONS — ECOSYSTEM BOM DISCIPLINE & HAILO MITIGATION ============================================================================== LENS 03 (Dependency Graph) — false-dependency audit The Orin NX paperweight (2027 scenario) exposes a failure mode that Lens 03 should surface as a companion artifact: the "false-dependency audit." For every ecosystem commitment the team is considering, verify the full chain works end-to-end before investing in learning curve or capital. An ecosystem buy-in without a complete BOM (carrier board, stereo camera, software stack all in hand at purchase time) is a hardware-layer version of a perceived dependency that the code doesn't actually need. LENS 25 (Ethics of Resource Allocation) — burnt capital is moral In a single-developer project funded by personal savings, misallocated engineering time is moral burn: hours that could have gone to Mom's usability (the 7–9pm degradation window) or to the IMU watchdog (the known unfixed risk) and instead flow to an ecosystem that doesn't fit. The Orin NX paperweight is the hardware-layer expression of the same pattern — $600 of capital frozen in a drawer. Lens 25 should treat ecosystem-adoption decisions as ethical as well as technical: every hour invested in a stack that doesn't fit is an hour stolen from the user who is waiting for the product to become reliable. ============================================================================== SYNTHESIS: THE SLOW PATH FAILURE MODE ============================================================================== Every lens connection above traces back to the same root cause that Lens 10 makes explicit: the research optimized a single path through the system — the fast path, when everything works — and left every other path unspecified. The slow path is not a single feature. It is the entire design space of: - What happens when WiFi latency exceeds the command timeout - What happens when both sensors agree on the wrong answer - What happens when the IMU crashes and no watchdog catches it - What happens when SLAM corruption forces a map rebuild - What happens when VRAM constraints force a capability cut - What happens when the prerequisite chain breaks at its weakest link - What happens when the user stops asking A pre-mortem's deepest value is not identifying individual failure modes. It is revealing the structural deficit that allows multiple independent failure modes to compound into a single outcome: the system was abandoned. The structural deficit here is the absence of a slow-path specification. Fixing the glass door doesn't fix the WiFi freeze. Fixing the WiFi freeze doesn't fix the IMU watchdog. But all three fail for the same reason: the design never asked "what does this do when it fails?" for any component. The mitigation is not more research. It is a mandatory slow-path review: for every component in the fast path, define its behavior under the top 3 failure modes before shipping the fast path. This review has a name in resilience engineering: Failure Mode and Effects Analysis (FMEA). The 4-tier fusion architecture was designed. Its FMEA was never written. The Hailo-8 activation and the Orin NX paperweight are the same lesson at the ecosystem layer. The slow-path failure inside the system ("what happens when WiFi drops?") has a twin failure outside it ("what happens when we reach for a rescue that doesn't fit?"). The mitigation is the same shape: inventory what you already have (Hailo-8 idle on the Pi 5), verify fit before commitment, and treat ecosystem buys as BOM decisions (Orin NX without a carrier is a paperweight).