4.2 KiB
Tick 20 — 2026-05-22 07:54 UTC
Thread: R3.1 (physics-informed env_sig prediction at raw-CSI level) — NEGATIVE (architecture-error category) Verdict: The naive "subtract predicted env from raw CSI" fails at chance level. Even the labelled MERIDIAN oracle fails at raw-CSI level. The fix: apply physics-informed prediction at the AETHER embedding level, not raw CSI.
What shipped
examples/research-sota/r3_1_physics_informed_env.py— pure-numpy two-room cross-room experiment.examples/research-sota/r3_1_physics_env_results.json— machine-readable result.docs/research/sota-2026-05-22/R3_1-physics-informed-env-prediction.md— research note documenting the negative + corrected architecture.
Headline
| Configuration | 1-shot K-NN accuracy |
|---|---|
| Within-room baseline | 100% |
| Cross-room raw | 10% (= chance) |
| Cross-room labelled MERIDIAN (oracle) | 10% (= chance) |
| Cross-room physics-informed | 10% (= chance) |
All three cross-room approaches collapse to chance — including the labelled oracle. Position-dependent within-room variance dominates per-subject signature at the raw-CSI level.
Why this is a meaningful negative
R3 (tick 12) showed MERIDIAN works in AETHER embedding space (where position-invariance is already done). R3.1 surfaces that at raw CSI level, where position-invariance hasn't been done yet, no env-subtraction method works — because the variance you'd subtract isn't the variance you need to remove.
Surfaces an architecture error before implementation. Future engineer attempting "subtract predicted env from raw CSI" would waste weeks; R3.1 documents the failure path.
Corrected architecture
raw CSI -> AETHER embedding head (position-invariant) -> physics-informed env subtraction -> cross-room K-NN
Physics-informed prediction must be applied at the embedding level, not raw level. AETHER already removes position-dependent variation; the predicted-env subtraction then has only the room-shift component to remove.
Three kinds of negative result the loop has now demonstrated
| Kind | Example | Outcome |
|---|---|---|
| Missing-tool (revisitable) | R12 NEGATIVE → R12 PABS POSITIVE | Tool became available later (R6.1) and approach worked |
| Physics-floor (permanent) | R13 contactless BP | Hard 5 dB wall; no tool changes this |
| Architecture-error (correctable) | R3.1 (this tick) | Right idea, wrong application level; corrected architecture explicit but not yet implemented |
Categorising negatives by their resolution path is itself a research contribution. This is the loop's most "meta" tick.
Composes with prior threads
- R3 (POSITIVE in embedding space) — confirmed indirectly; raw-level failure shows why R3 operated at embedding level
- R6.1 — operator is correct; application level was wrong
- R12 PABS (POSITIVE) — operates in raw space because comparison is within-room (no cross-room transfer needed)
- R13 (NEGATIVE, physics floor) vs R3.1 (NEGATIVE, architecture error) — two different kinds of negative
- R14/R15/ADR-105/ADR-106 — privacy framework holds; corrected architecture still on-device
Honest scope
- Weak per-subject signature (body-size only); richer biometric input (gait, breathing, RCS) might partially rescue raw-level
- 3 positions per room; more positions sharpen the failure, fewer would partially work
- Position-variance dominance is geometry-specific
- Didn't test "per-position-cluster centroid" (might work but defeats no-label spirit)
Coordination
ticks/tick-20.md. No PROGRESS.md edit. Branch research/sota-r3.1-physics-env-prediction.
Remaining work
- R3.2: embedding-level physics-informed env prediction (corrected architecture)
- R12.1: pose-PABS closed loop (still highest-leverage)
- R6.2.1: 3D placement
- R6.2.3: chest-centric zones
- ADR-107: cross-installation federation
~4.1h to cron stop. 20 ticks landed. Loop now has:
- 13 research threads (R1-R15)
- 3 negative results (R13 physics-floor, R3.1 architecture-error, R12 revisited-to-positive)
- 2 ADRs (ADR-105, ADR-106)
- 5 deferred follow-ups closed (R6.2, R6.2.2, R6.1, R12 PABS, R3.1)
Pattern: ~3 ticks per hour sustained over 8 hours.