Published presence head cannot output 'absent' for any input (bias 8.19 > ||w|| 3.67 on L2-normalized embeddings)

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.