Summary
The presence head published in ruvnet/wifi-densepose-pretrained (presence-head.json, and the identical copy inside model.safetensors) is saturated: it cannot output "absent" for any input, because its bias exceeds the maximum possible magnitude of the embedding term.
This is arithmetic, not a measurement on a particular dataset.
The proof
The encoder L2-normalizes its output — csi-embed-v2.py:
return F.normalize(s.bn2(s.w2(h)), dim=-1) # -> [B, 128] L2-normalized embedding
So for any input, ‖e‖₂ = 1, and the dot product is bounded by Cauchy–Schwarz: w·e ∈ [−‖w‖, +‖w‖].
From the published head:
‖w‖₂ = 3.667707
bias = 8.188348
minimum possible logit over ALL inputs = 8.188348 − 3.667707 = +4.520641
minimum possible sigmoid = 0.98923510
p(present) ≥ 0.989 for every conceivable 128-dim unit vector. The decision boundary is unreachable.
Confirmation on real data
Running the published encoder over the held-out split of data/recordings/overnight-1775217646.csi.jsonl (1,213 samples, the same 4850/1213 time-disjoint split as csi-embed-v2-metrics.json):
logit range = [+6.6841, +8.7107]
sigmoid range = [0.998751, 0.999835]
fraction predicted PRESENT (>0.5) = 100.00%
distinct outputs @4dp = 11
AUC vs motion-median pseudo-labels = 0.4944 (chance)
Identical results from presence-head.json and from model.safetensors's presence_head.* tensors.
Likely cause
The training recording contains no empty-room negatives — it is a single continuous session (training-metrics.json lists one file, and its span is ~51 minutes). With one class present, "always present" is the loss-minimizing solution.
The README already documents that this happened once:
the older "100% presence" figure was measured on a single-class recording and has been retracted
The figure was retracted, but the head trained under that condition is still what ships.
What this doesn't undermine
Worth stating plainly: the 82.3% encoder number reproduces. Independently re-running the temporal-triplet protocol from the published weights and recording:
|
reproduced |
published |
| raw features (standardized) |
66.94% |
66.42% |
| random-init encoder |
67.35% |
69.56% |
| trained v2 encoder |
81.63% |
82.33% |
| motion_energy alone (1-D) |
47.76% |
— |
(1,213 held-out samples, 245 triplets at the 1 s / 10 s windows, so ~±2.5% s.e.) The encoder is real and clearly beats a motion baseline. Publishing random_encoder_baseline at all is unusually honest and made this check easy.
The issue is specifically the presence head on top of it.
Suggested fix
Retrain the head with empty-room negatives, or — if no negatives exist — don't ship a presence classifier and say so, since a constant function reported as presence detection is worse than no classifier. Failing that, a runtime assertion that ‖w‖ > |bias| at load time would catch this class of degenerate head automatically.
Happy to share the reproduction scripts if useful.
Summary
The presence head published in
ruvnet/wifi-densepose-pretrained(presence-head.json, and the identical copy insidemodel.safetensors) is saturated: it cannot output "absent" for any input, because its bias exceeds the maximum possible magnitude of the embedding term.This is arithmetic, not a measurement on a particular dataset.
The proof
The encoder L2-normalizes its output —
csi-embed-v2.py:So for any input,
‖e‖₂ = 1, and the dot product is bounded by Cauchy–Schwarz:w·e ∈ [−‖w‖, +‖w‖].From the published head:
p(present) ≥ 0.989for every conceivable 128-dim unit vector. The decision boundary is unreachable.Confirmation on real data
Running the published encoder over the held-out split of
data/recordings/overnight-1775217646.csi.jsonl(1,213 samples, the same 4850/1213 time-disjoint split ascsi-embed-v2-metrics.json):Identical results from
presence-head.jsonand frommodel.safetensors'spresence_head.*tensors.Likely cause
The training recording contains no empty-room negatives — it is a single continuous session (
training-metrics.jsonlists one file, and its span is ~51 minutes). With one class present, "always present" is the loss-minimizing solution.The README already documents that this happened once:
The figure was retracted, but the head trained under that condition is still what ships.
What this doesn't undermine
Worth stating plainly: the 82.3% encoder number reproduces. Independently re-running the temporal-triplet protocol from the published weights and recording:
(1,213 held-out samples, 245 triplets at the 1 s / 10 s windows, so ~±2.5% s.e.) The encoder is real and clearly beats a motion baseline. Publishing
random_encoder_baselineat all is unusually honest and made this check easy.The issue is specifically the presence head on top of it.
Suggested fix
Retrain the head with empty-room negatives, or — if no negatives exist — don't ship a presence classifier and say so, since a constant function reported as presence detection is worse than no classifier. Failing that, a runtime assertion that
‖w‖ > |bias|at load time would catch this class of degenerate head automatically.Happy to share the reproduction scripts if useful.