# project_highlevel — memory

Append-only. Non-obvious things I've learned that aren't in code or git history. Narrative conventions, framing decisions Cameron has signed off on, dead-ends to avoid.

## Narrative / framing conventions Cameron has signed off on

### 2026-06-17 — Back-half plan locked + Onshape antipattern partially rehabilitated
Cameron's structured plan for the remaining internship (follow-on to Jun 16 scope cut):
- **Now → ~Jul 1**: core experiments + figures + paper only
- **~Jul 1 → Aug 17**: extras + scaling + own-robot REDO + final presentation
- **1 hr/day Onshape discipline starting now**, ~1 week to ramp, then incremental work toward own-robot rebuild

**Important update to the Onshape dead-end (which said "Onshape during TRI is parked, point at the plan if Cameron raises it")**: the dead-end specifically targeted *bundling a 2-month arm rebuild into a half-day task slot during paper crunch*. The Jun 17 plan is structurally different — it's a *bounded skill-building discipline (1hr/day)* in the *post-Sergey-validation window*, with the actual rebuild scoped for the back-half (Jul 1+). This is allowed.

**The distinction matters**: the antipattern is *bundling* (smuggling Y into the slot for X). A bounded discipline isn't bundling — it's an explicit time investment Cameron is making in his own development. The right pushback for future raisings: if Cameron proposes Onshape for full-time work *before* paper crunch is done, point at this entry and the Jun 17 split. If he proposes 1hr/day discipline, that's fine.

**Why this is the right plan, not anxiety-addition**: 
- Sergey already validated the paper as "in good shape" — Cameron has air cover to invest in the back-half
- The 1hr/day is bounded, not a full-time pivot
- Own-robot in the back-half addresses the *root cause* of the nice-to-haves' hackiness (lack of stack control)
- Cameron's identity statement (real robotics, bottlenecks, own the stack) is the lens — own-robot IS the bottleneck for sustainable nice-to-haves
- The previously-parked items (sim2real, pretraining) become principled with own-robot, not hacky

**Going forward**: when Cameron raises new "nice-to-haves" between now and Jul 1, default reaction is still "parked, captured for post-paper or back-half" unless tightly bounded. Don't relitigate the back-half plan unless Cameron initiates a change.

### 2026-06-16 — Major scope cut: core-experiments-only, nice-to-haves parked
Cameron's call after meeting with Sergey (paper validated as "in good shape"). Pulled video-IDM, sim2real, and 1k-hours pretraining out of active scope. Reasoning Cameron gave: (a) too many half-finished threads diluting the core, (b) the nice-to-haves don't interest him, (c) they're not the bottleneck, (d) most require hacky workarounds on hardware he doesn't control (extrinsics post-hoc, no sim for YAM gripper). Right answer post-paper: own-robot for hardware/data control. Pre-paper: nail core experiments excellently with great visualizations.

**What stays active**: in-dist · data efficiency · OOD object position · OOD viewpoint · dexterous tasks. Plus skilled-teleop recruitment (core-supportive, not extension).

**What got parked**: video-IDM, sim2real (incl. real-to-sim re-render), 1k-hours YAM pretraining.

**Why this is healthy, not anxious-subtraction**: Sergey's "paper is in good shape" validation gives Cameron the air cover to subtract. The previous pattern (anxiety→addition) doesn't apply here — this is *confidence→subtraction*. Counter-instinct for an internship is "do more to prove value"; the right move is "do core excellently to ship a real paper." Vault `tasks.md` updated with Parked section + Post-paper north star section. See `vault/para/tasks.md` "Post-paper north star (2026-06-16)" — build own robot post-paper for hardware/data control, then scale parked items cleanly.

**Apply going forward**: if a new nice-to-have surfaces between now and Aug 17, default reaction is "parked, captured for post-paper" unless Cameron explicitly opens scope. Don't relitigate the parked items unless Cameron initiates.

### 2026-06-10 — Binding framing is the canonical pitch (supersedes factorization framing)
Cameron's articulation: *"Today's robot policies must learn — from image-to-action labels alone — the EEF↔pixel association, depth along the ray, scene geometry, and the implicit camera-to-robot extrinsics. PARA **binds the action space to its projecting image features**: discretizes the volume of candidate EEF positions, attaches each candidate to the pretrained image features at its projection, and reformulates policy learning as feature **selection** over that volume."*

The load-bearing phrase is *"bind the action space to its projecting image features."* Selection-vs-regression is what makes the data-efficiency claim mechanistic instead of magical (the policy doesn't have to learn extrinsics/geometry/association — geometry is *given* by the projection).

**Why this supersedes the 2026-06-02 factorization framing:** the binding framing covers BOTH old PARA (factorized single-view, uv heatmap + height bin along one ray) and new PARA (joint multi-view, world voxel grid projected into every view) as instances of the same family — *action selection on a feature-bound candidate volume.* View count becomes an implementation detail, not a story. Dissolves the Jun-3 single-view headline tension cleanly (it's also retired today — see below).

**How to use:** after the paradox / data-efficiency hook, before the why-it-works list. Same slot the factorization framing held. Wired into `/data/cameron/para/pitch.md` (new "## Current pitch (canonical 2026-06-10)" section) and `vault/para/goals.md` ("Binding framing"). Old factorization framing preserved under OLD markers in both files.

### 2026-06-10 — Single-view headline lock is RETIRED (was canonical 2026-06-03 → 2026-06-09)
View count is no longer a headline claim. The binding framing makes view count an implementation detail of how candidates get their bound features. The "humans use ego view, not wrist cam" rhetorical move is dropped; replace with "PixelNeRF was always multi-view, it scales gracefully with view count." Today's canonical arch (multi-view per-voxel, see [[feedback_multiview_voxel_canonical]]) consumes 2 views and that's fine. Single-view results become *"PARA works even with N=1"* — a strength, not a regression. See `vault/para/goals.md` OLD marker on Single-view headline decision.

### 2026-06-03 — Single third-person scene cam is the locked headline modality (wrist cam dropped from headline) — RETIRED 2026-06-10
Wrist cam was finnicky in TRI Wk 1 live deploy vs scene cam reliability. Rhetorical framing: "humans use ego view, not wrist cam — single view isn't theoretically impossible." This pre-empts the "but you should fuse wrist cam!" reviewer comment by *proving fusion isn't necessary*, not by being weaker than fusion methods. Phase 2 of the TRI plan (originally wrist cam integration) reallocated to single-view depth — more OOD axes, more dexterous tasks, more backbones. Wrist cam may resurface as paper appendix ablation only. See `vault/para/goals.md` "Single-view headline decision."

### 2026-06-03 — Locked overview figure structure: action head diagram + 4-5 evidence buckets
Top half = action head vs global regression head diagram (the second-beat factorization made visual). Bottom half = 4-5 buckets: data efficiency, OOD object position, OOD viewpoint, dexterity (CAP 2 TASKS in figure: towel fold + cup/mug; egg-carton / desk-cleanup / bimanual are aspirational, tease in text not figure), and optional 5th bucket flexible backbones (DINOv2/v3 real + VGGT aspirational). Staged V1/V2/V3 by evidence-readiness. See `vault/para/goals.md` "Locked overview figure structure."

### 2026-06-02 — Second-beat factorization framing is the locked mechanism pitch
*"PARA is a new robot action head. We factorize the target EEF position (x, y, z) into (a) the pixel uv predicted as a heatmap over the image, and (b) the world-frame height predicted as a categorical distribution over discretized height bins along that pixel's ray. The critical choice is height not depth — that's what bakes in viewpoint invariance."*
Use AFTER the hook (paradox / data-efficiency), never as the opener. The factorization framing anchors the contribution in the familiar "action head" abstraction every ML practitioner knows — most audience-portable mechanism statement we have. Wired into `/data/cameron/para/pitch.md` (new section "PARA's factorization (precise mechanism statement)") and `vault/para/goals.md`.

### 2026-05-19 — "Head > backbone" is the new paper claim worth surfacing
Smaller DINOv3-S/16+ (30M) + KV-factored head beats DINOv3-L (305M) + dense head on smith300 (8.70/9.32 vs 9.88 px). This deserves a paragraph in the abstract, not just an ablation table. Pre-empts the "your model is small, scale will subsume you" objection that the DUSt3R-inductive-bias framing always attracts.

### 2026-05-19 — "Did we skip a step?" lab-deck framing (DUSt3R analogy)
The pitch's setup slide (slide 2 of `omidlab.net/para_presentation`): the field is sprinting toward maximally-flexible architectures (VLAs, video-model policies). DUSt3R showed the right inductive bias unlocks problem categories. PARA argues we skipped past a productive level of structure for action prediction. **Use** the "trend toward *maximally-flexible*" phrasing, not "removing all inductive bias" (latter is strawman). Audience-fit caveat: this lands for CV-savvy crowds; less so for results-only audiences (per lab-meeting feedback 2026-05-09 — see below).

### 2026-05-25 — Lead with data efficiency, not robustness (per life_manager + Cameron)
Investor / advisor pitch headlines on **"30 demos vs 3,000+"** (sharpened to **"15 demos vs 3,000+"** after 2026-05-29 YAM in-dist result). Robustness is the *evidence*, data efficiency is the *thesis*. Consumers don't care if the camera moves — they care about the cost of teaching the robot. This shift came from a long drive-to-TRI conversation with life_manager.

### 2026-05-25 — Identity-level frame matters more than any single experiment
"Winning the internship" isn't best-results-in-lab — it's *"the version of yourself at 27 you'd hire."* Boring consistent routine (6am wake, 10pm bed, 25-min lift, 1500 cal) IS the research-strategic move because it preserves cognitive bandwidth for the work. Don't treat life_manager territory as separate from research strategy.

### 2026-05-12 — Lab presentation feedback for future deck variants
Cameron's lab is less CV-savvy than he'd assumed; the DUSt3R / inductive-bias analogies didn't resonate. Future internal talks should be **results-first**, framing-late. Save the inductive-bias narrative for paper + external-talk audiences. (Memo to self: respect audience fit; don't bake the inductive-bias frame into every artifact.)

### 2026-05-11 — UMI cross-embodiment dropped from paper
Cameron gave UMI a real shot; generalization failed. Mention in goals.md as "parked." Don't resurrect unless empirical evidence comes back. (The cross-embodiment story now leans on arm-deleted point tracks for "evidence" + a future paragraph if/when YAM transfer demonstrates it.)

## Pitch-language anti-patterns (per 2026-05-26 pitch crystallisation)

- **Never lead with mechanism.** "Hey we predict a per-pixel probability volume over voxels" — lost the listener. Lead with paradox ("features generalize, policies don't") or result ("15 demos vs 3,000+").
- **Retire these phrases:** *"hug features more locally"* (jargon — say "predict on top of the feature grid"), *"implicit motion map"* (sounds like optical flow), *"candidate 3D location"* (say "voxel").
- **The fix gets 2× the airtime of the diagnosis.** Don't spend 70% of the pitch saying what's wrong with existing policies.

## Recurring anti-patterns to watch in Cameron

### Bundling
"Since I'm doing [necessary task], I'll also do [exciting but premature task]." Examples I've caught:
- "Bigger ArUco boards → also rebuild arm in Onshape during TRI" (2026-05-24). The boards are mechanically independent of the arm; the rebuild is a 2-month project misslotted as a half-day side task.
- "Print new arm version → also learn Onshape at TRI" (2026-05-22). Same pattern, different door.

When Cameron proposes a Task X that "while we're at it" includes Task Y — verify Y is actually load-bearing for X or is being smuggled in under cover.

### Anxiety → addition
When Cameron feels stuck/stifled (esp. closeout phase of a paper), his instinct is to *add* workstreams. The right move is *subtract*: "you need to be working only on the thing that determines whether the paper is a banger." Surface this directly when the pattern appears — he's responded well to it.

### Scope creep around hardware
Cameron loves hardware projects (custom arm, UMI, mobile base, linear rail). Each is real and earned; none belong in the *current* paper's critical path. Keep them sequenced in `arm_v2_plan.md` and resurface the doc when scope creep tries to relitigate.

## Dead ends — don't restart these

- **Onshape during TRI / during paper crunch.** Discussed 3x (2026-05-22, 24, 25). Locked in `arm_v2_plan.md` as Month 4+ work post-paper. If Cameron raises it again, point at the plan.
- **UMI cross-embodiment.** See above; explored and dropped 2026-05-11.
- **Panda deployment.** Hardware proved unreliable; abandoned 2026-05-06. Don't resurrect.

## Operational

### 2026-05-26 — yams owns TRI-technical work
Spinning up yams agent freed my context dramatically. Defer all TRI-technical questions to yams (calibration, deploy, DGX, MuJoCo debugging). I stay in strategy mode. See `vault/para/overview.md` ownership table.

### 2026-05-12 — Doc-vs-chat split
Cameron has caught me before saying "dispatching now" without actually dispatching (2026-05-12, figure_maker fig1 task). When I say I'll do a thing, do the thing in the same message. Don't separate intention from execution.

### Standing
- Cameron prefers terse, opinionated responses. Lead with the recommendation. Reasoning comes after, in bullets.
- "Per `vault/para/memory.md`, [convention]..." beats remembering a fact from compacted history. Reference vault paths in responses.
- Per `feedback_proactive_execution.md` in long-term memory: chain the full pipeline automatically, don't ask permission between obvious steps.
