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:
- platform-conditional feature (eigenvalue on macOS/Linux, fallback on Windows), or
- a BLAS-free eigenvalue path, or
- accept threshold-only counting — and stop publishing
baseline_eigenvalue_count,
which currently implies a capability the build does not have.
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:wifi-densepose-sensing-server/Cargo.toml:60:Nothing in the workspace re-enables it. So the compiled
estimate_occupancyis the stub:Consequence
Every calibrated occupancy result comes from the perturbation-energy fallback. Confirmed:
inference_methodwasfield_model_perturbation_energy_v1in 100% of frames across everycapture. The entire live person-detection is:
One scalar against one frozen threshold.
baseline_eigenvalue_countis computed, stored inthe 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-staticfails to build on macOS/ARM (itscblat3.fFortran test target).openblas-systemwith Homebrew OpenBLAS 0.3.33 builds in ~1 min, the realestimate_occupancycompiles 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 nowneeds a deliberate choice rather than a flag flip:
baseline_eigenvalue_count,which currently implies a capability the build does not have.