LENS 12 — CROSS-LENS CONNECTIONS: Anti-Pattern Gallery ============================================================== PRIMARY CONNECTIONS (cited in brief) ============================================================== LENS 01 (Constraint Archaeology) Anti-Pattern 1 (high-frequency single-query) is directly visible in Lens 01's constraint hierarchy. The 18ms/frame inference budget is a physics-layer constraint that cannot be changed. Lens 01 would ask: "which constraints are dissolved by time?" The answer for Anti-Pattern 1 is that the 58 Hz throughput constraint is NOT dissolved — it is fixed. What IS dissoluble is the convention that all 58 Hz must carry the same question. The multi-query rotation dissolves that convention while respecting the physics constraint. Lens 01 provides the vocabulary for why this pattern change is valid: it operates entirely within dissolved-convention space. The "temporal surplus" framing from Lens 01 (free signal that costs nothing to use) maps directly onto the multi-query insight: the robot is already running its inference loop. The additional scene/obstacle/embedding queries are temporal surplus — they exist in the idle frames between goal queries. Lens 12 identifies the failure to use temporal surplus as Anti-Pattern 1. LENS 04 (Timing & Latency) Anti-Pattern 4 (bigger model = better nav) is the lens 04 question stated as an anti-pattern. Lens 04's driving question — "where is the 100ms WiFi cliff and what breaks above it?" — is the mechanism that makes Titan 26B unusable for reactive steering. The 100ms WiFi cliff means that even at Titan's 50 tok/s generation speed, a round-trip image query (encode + transmit + generate + transmit back) lands above 200ms in practice. 200ms at 1 m/s = 20cm of unguided travel per query. At Panda-local 18ms, unguided travel is 1.8cm — an order of magnitude better temporal precision. Lens 04 also validates Anti-Pattern 1's correction: its finding that "VLM rate is insensitive above 15Hz" means the value of 58Hz single-query is saturated. The marginal improvement from frame 15 to frame 58 of the same question is noise. Multi-query rotation captures the unsaturated region (scene labels are useful at 10Hz; obstacle class is useful at 10Hz; neither has been extracted at all in the single-query pattern). LENS 14 (Epistemological Status) Lens 14 found that "research describes the Waymo pattern then does the opposite (VLM-primary vs lidar-primary)." Anti-Pattern 3 (VLM can replace lidar) is precisely the epistemological conflation Lens 14 identifies: the research cites Waymo's complementary-sensor architecture extensively, then Annie's single-camera setup tempts implementors to treat the VLM as a lidar substitute. Lens 14 names this as an internal contradiction in the research — Lens 12 names it as an anti-pattern in practice. Anti-Pattern 2 (end-to-end neural is best) also connects to Lens 14. The research correctly distinguishes "what Waymo/Tesla do" (fleet-scale custom neural) from "what OK-Robot does" (off-the-shelf pragmatic integration). Lens 14 asks whether the paper's epistemological confidence matches its evidence base. For the end-to-end claim, it does not — the evidence (OK-Robot success) favours pragmatic integration. Lens 12 converts Lens 14's epistemological warning into an operational anti-pattern: "don't copy the headline; copy the method section." ============================================================== SECONDARY CONNECTIONS ============================================================== LENS 03 (Dependency Map) Anti-Pattern 1's fix (multi-query rotation) requires the embedding pipeline (Phase 2d) which hits Lens 03's highest-leverage dependency: llama-server not cleanly exposing multimodal embeddings. Lens 03 identified this as an addressable blocker requiring a separate SigLIP 2 ViT deployment (~800MB VRAM). Anti-Pattern 1 is therefore partly blocked by a dependency Lens 03 already mapped. The pattern rotation is implementable for tasks 1–3 (goal/scene/obstacle) without resolving the embedding dependency; task 4 (place recognition) requires Lens 03's blocker to be resolved first. LENS 08 (Neuroscience Analogies) Anti-Pattern 5 (build the map to navigate vs build the map to remember) maps onto Lens 08's hippocampal replay mechanism. The hippocampus does not store navigation routes — it stores place memories (episodic + semantic). Navigation is a retrieval task against stored place memories, not a real-time spatial computation. Anti-Pattern 5 confuses the hippocampus's output (successful navigation) for its purpose (building a persistent place memory). Lens 08's "build the map to remember" framing is the neuroscience version of the same correction. LENS 10 (Post-Mortem) Lens 10's core finding — "we built the fast path, forgot the slow path" — is the generalised form of Anti-Pattern 4. The fast path (Panda E2B at 54Hz for reactive steering) was built. The slow path (Titan 26B at 1–2Hz for strategic planning) was documented in the 4-tier architecture but not yet implemented. Anti-Pattern 4 is the specific failure mode that occurs when an engineer, frustrated with the fast path's limitations, tries to replace it with the slow path rather than ADDING the slow path. The correct fix is always to implement both tiers and route queries to the appropriate tier by latency requirement. LENS 11 (Adversarial Perspectives) Anti-Pattern 2 (end-to-end neural) is the anti-pattern most vulnerable to Lens 11's competitive pressure argument. If open-source VLA models (OpenVLA, pi0) continue to improve and their fine-tuning data requirements drop by 10×, Anti-Pattern 2 becomes the correct pattern. Lens 11's "race to zero" on model capability means the threshold at which a custom fine-tuned model beats pragmatic integration will eventually be crossed. Lens 12 identifies the present-day anti-pattern; Lens 11 names the condition under which it stops being an anti-pattern. The two lenses together argue for a clear trip wire: "revisit end-to-end when demo-to-train ratio reaches N." LENS 16 (Build the Map to Remember) Lens 16 is the affirmative version of Anti-Pattern 5's correction. Where Lens 12 says "don't treat SLAM as navigation infrastructure," Lens 16 says "here is what to build instead." Anti-Pattern 5 and Lens 16 are the same insight from opposite directions. Cross-reference: if a reader encounters Anti-Pattern 5 and wants the constructive framing, send them to Lens 16. If a reader encounters Lens 16's prescriptions and asks "what is the failure mode this prevents?", send them to Lens 12 Anti-Pattern 5. LENS 21 (Safety & Human Override) Anti-Pattern 3 (VLM can replace lidar) is the safety failure mode Lens 21 most concerns. Lens 21 identified the voice-to-ESTOP gap: Mom cannot say "Stop!" with under 5 seconds latency. If the lidar ESTOP is removed in favour of VLM-only obstacle detection, the safety gap widens further: the glass door problem means the robot may not detect the obstacle at all until impact. Anti-Pattern 3 is the single anti-pattern with the most direct safety consequence. Lens 12 and Lens 21 together argue that lidar ESTOP priority (Tier 3 over Tier 2) is a safety invariant, not an architectural preference. Anti-Pattern 6 (safety-critical inference over WiFi) is Lens 21's safety concern applied to the network layer. The Hailo-8 sitting idle on Pi 5 while safety reflexes travel over WiFi means the ESTOP path depends on a radio the system doesn't control. A 300 ms WiFi stall costs 30 cm at 1 m/s. Lens 21 would argue that safety reflexes must be local by construction: the local NPU is hardware Annie already has; refusing to use it for L1 safety is a gratuitous dependency on infrastructure outside the robot's hull. ============================================================== NEW CONNECTIONS — ANTI-PATTERNS 6 and 7 ============================================================== LENS 01 (Constraint Archaeology) — AP6/AP7 Both new anti-patterns are constraint-archaeology failures. The Hailo-8 was installed as a convention ("we have an AI HAT+") without a re-examination of which layer it should serve. Lens 01's "dissolved conventions" frame captures this precisely: the convention that "inference lives on the big GPU" was never re-asked when a local NPU appeared. AP7 is the inverse: the convention that "the VLM handles all vision" was never re-asked when the target became a deterministic fiducial. In both cases, the layering decision outlived the assumptions that produced it. LENS 04 (Timing & Latency) — AP6 AP6 is the most direct Lens 04 consequence: the 100 ms WiFi cliff Lens 04 identified becomes catastrophic when safety reflex paths traverse it. YOLOv8n at <10 ms local on Hailo-8 vs ~30–40 ms over WiFi-to-Panda is not a small delta — it's the difference between a reflex that keeps up with a 1 m/s robot and one that doesn't. Lens 04's latency budget argument is the quantitative backing for AP6's qualitative rule. LENS 14 (Epistemological Status) — AP7 AP7 illustrates Lens 14's "right tool for right job" principle at the mechanism level. Classical CV is deterministic; VLMs are probabilistic. Treating a known fiducial as a semantic-unknown problem is an epistemological mismatch: paying for probabilistic machinery on a deterministic signal. Lens 14 would ask "what is the paper's confidence basis for this choice?" For AP7, there is none — the VLM was reached for because it was already running, not because the problem needed it. LENS 16 (Build the Map to Remember) — AP6 AP6 interacts with Lens 16: if L1 safety lives on the Pi (Hailo-8), then Pi-local processing can also write short-term obstacle memories directly into the SLAM grid without a WiFi round-trip. The local-NPU architecture unlocks Pi-side persistent memory updates — a small but meaningful consequence. LENS 18 (Meta-Lens / Research Method) — AP6/AP7 Lens 18 examines the method by which architectural mistakes are caught before shipping. Lens 12's AP6 and AP7 are direct outputs of that method: both were surfaced by the session-119 hardware audit, which re-examined which compute was already on the robot (Hailo-8) and which tools already solved the structured signals (classical CV for fiducials). Lens 12 promotes the findings to anti-patterns; Lens 18 describes the audit method that caught them. ============================================================== PATTERN SUMMARY FOR ASSEMBLY AGENT ============================================================== The seven anti-patterns in Lens 12 form three families: Family A: "Doing the obvious thing with the existing fast path" (Anti-Patterns 1, 4) Both involve the Panda 54 Hz loop. Both are corrected by understanding that temporal frequency and semantic diversity are orthogonal. Fix: multi-query rotation (AP1), tier separation (AP4). Lenses 01 and 04 provide the analytical vocabulary for both. Family B: "Misunderstanding what each component is FOR" (Anti-Patterns 2, 3, 5) AP2 misunderstands what VLA models require (data scale). AP3 misunderstands what VLM and lidar each measure (semantics vs geometry). AP5 misunderstands what SLAM produces (navigation aid vs persistent memory). Lenses 08, 10, 14, 16, and 21 each address one of these misunderstandings from a different analytical angle. Family C: "Wrong-layer inference" (Anti-Patterns 6, 7 — new, session 119) Both are mechanism-matching failures. AP6 puts safety-critical inference on a network-dependent remote GPU when a local NPU exists; the correct pattern puts reflex-path inference on compute physically closest to the actuator. AP7 routes a known-geometry fiducial through a VLM (18 ms + WiFi) when classical CV solves it in 78 µs (230× faster, deterministic). The meta-rule: match the inference mechanism to the signal's predictability — classical CV for known shapes, local NPUs for reactive safety, VLMs for semantic unknowns, LLMs for strategy. Lenses 01, 04, 14, 16, 18 each touch this family from a different angle; Lens 21 underwrites its safety consequences. The anti-pattern gallery is, in aggregate, a failure mode map for the research's own architecture. Each anti-pattern is the path taken by an engineer who read the executive summary but not the full paper.