Eigenvalue occupancy is compiled out of the shipped server; all counting is one scalar threshold

Eigenvalue occupancy is compiled out of the shipped server; all counting is one scalar threshold

Repo: ruvnet/RuView · Severity: High (design) · Measured: 2026-09-15
No fix proposed — this needs a decision, and the Windows build is in flight.

What ships

wifi-densepose-signal/Cargo.toml:

[features]
default = ["eigenvalue"]           # requires BLAS via ndarray-linalg

wifi-densepose-sensing-server/Cargo.toml:60:

# `--no-default-features` at the workspace root can produce a Windows-friendly
# build without vcpkg/openblas (issue #366, #415).
wifi-densepose-signal = { …, default-features = false }

Nothing in the workspace re-enables it. So the compiled estimate_occupancy is the stub:

#[cfg(not(feature = "eigenvalue"))]
pub fn estimate_occupancy(&self, _recent_frames: &[Vec<f64>]) -> Result<usize, FieldModelError> {
    Err(FieldModelError::NotCalibrated)   // ignores its input, always errors
}

Consequence

Every calibrated occupancy result comes from the perturbation-energy fallback. Confirmed:
inference_method was field_model_perturbation_energy_v1 in 100% of frames across every
capture. The entire live person-detection is:

if perturbation.total_energy > empty_threshold { 1 } else { 0 }

One scalar against one frozen threshold. baseline_eigenvalue_count is computed, stored in
the receipt, published to the app — and never used for any decision.

This is visibly unstable: the same empty room read absent 604/604, then present 613/613
twenty minutes later, unchanged model and node.

Local experiment (bench only, not proposed)

openblas-static fails to build on macOS/ARM (its cblat3.f Fortran test target).
openblas-system with Homebrew OpenBLAS 0.3.33 builds in ~1 min, the real
estimate_occupancy compiles and runs, and the sensing-server suite is unchanged.

So the blocker is the static BLAS build, not the feature. A system-BLAS backend or a
platform-conditional feature would sidestep it.

Decision needed

Windows support is the stated reason the feature is off, and a Tauri Windows desktop just
merged (ruview-mobile#28) with windows-server/ruview-server-manifest.json. So this now
needs a deliberate choice rather than a flag flip:

1. platform-conditional feature (eigenvalue on macOS/Linux, fallback on Windows), or
2. a BLAS-free eigenvalue path, or
3. accept threshold-only counting — and stop publishing baseline_eigenvalue_count,
   which currently implies a capability the build does not have.

Start with wifi-densepose-signal/Cargo.toml and wifi-densepose-sensing-server/Cargo.toml:60, then trace the cfg-gated estimate_occupancy implementation and the perturbation-energy fallback. Run the sensing-server suite and inspect how baseline_eigenvalue_count and inference_method are published. Done requires a recorded choice among platform-conditional eigenvalue support, a BLAS-free path, or threshold-only counting with consistent published results.