RuView Files

What's in this release

This release adds the beginnings of a trust layer to RuView's WiFi sensing — the plumbing so the system can eventually say either "here's my answer, and here's proof it's trustworthy right now" or, honestly, "I don't know" — instead of quietly guessing when conditions have changed. Think of it like a nutrition label for a sensor reading: not just the number, but where it came from, whether the sensor was properly calibrated, and whether anything's changed since.

It also folds in WiFi Veil, a separate defensive project that showed up as its own new public repository (ruvnet/wifi-veil) in the last release.

New capabilities

• Better benchmark and evaluation data pipelines — RuView can now ingest a well-known public WiFi-sensing benchmark (Widar3.0), data from newer high-resolution WiFi hardware, and a rig for checking vital-sign (breathing/heart-rate) accuracy against ground truth.
• Five safety fixes from an outside review of the codebase, the two most important being:
• A fix for a network security gap: the sensor's data port could previously be reached by unintended senders. It's now checked on every incoming connection.
• A new automated check that catches a specific kind of broken AI model before it ships — one that outputs a number which technically always says "someone is present," no matter what it actually sees. (A model like this was published earlier; this release prevents a repeat, though it does not remove what's already out there — see "Known limitations" below.)
• The first building blocks of a "trust chain" — nine new components for calibrating a sensor, cryptographically signing that calibration so it can't be silently altered, and checking whether current conditions still match what the sensor was calibrated for.

Honest status of the "trust chain" — please read this

This is a preview, not a finished, self-enforcing feature. The new components (calibrate → sign → check → allow/deny an action) are each well-built and each pass their own tests — but they are not yet wired together, and nothing in the live sensing server uses this chain yet to actually stop a bad reading from being trusted. It's like building a smoke detector, a sprinkler system, and a fire alarm — each tested separately on a workbench and working — but the wires between them haven't been run yet.

Two of the five safety fixes above are the exception: the network port guard and the CSI-data-policy checker (below) are fully wired in and active today.

A full write-up of this finding is documented in the codebase at docs/user-guide.md → "Perception Certificate Spine (Developer Preview)", and in this independent review.

Verification (independently re-run, not taken on faith)

• Full automated test suite: 4,337 tests passed, 0 failed.
• Deterministic signal-processing proof (a fixed reference signal must always reproduce an exact, bit-for-bit fingerprint): passed.
• Full workspace re-compiled cleanly after merging this alongside the WiFi Veil release.

Known limitations

• The already-published AI model mentioned above has not been taken down — that decision needs a maintainer, and this release only stops the next broken model from shipping.
• A repository check for accidentally-committed raw sensor recordings (which can contain identifiable personal data) is active in CI and is currently failing — 6 pre-existing recordings (~64 MB) from before this release are still tracked in git history. Their removal is intentionally left as a follow-up decision for whoever owns that data, not something silently swept aside.
• No ESP32 hardware or Python code was touched by this release.

Docker image

docker pull ghcr.io/ruvnet/RuView:bf17fc0407e28eb136a6da3b02f0a457a724efdb