mirror of
https://github.com/ruvnet/RuView
synced 2026-06-26 13:03:19 +00:00
c8b6cd7acefc2bfed443b2af7bf6b9d98ab0eaa2
660 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
c8b6cd7ace |
feat(adr-115): ship 3 Lovelace dashboard YAMLs (single-room / multi-node / healthcare)
Drop-in Lovelace dashboard YAMLs covering the three common ADR-115 deployment shapes. Paste into HA's raw config editor, rename the `binary_sensor.ruview_<room>_*` entity IDs to match what HA auto-discovered, done. | File | Use case | |-------------------------------------|-----------------------------------| | 01-single-room-overview.yaml | One node, full 21-entity surface | | 02-multi-node-grid.yaml | 3+ nodes (whole-house) | | 03-healthcare-aal-view.yaml | Care-giver dashboard, --privacy-mode-safe | ## Single-room overview - Three top tiles: presence / sleeping / room active - Glance card with HR / BR / motion / persons / RSSI - Gauge for fall_risk_elevated with green<40<yellow<70<red - Safety entities card (distress / no_movement / inactivity anomaly) - 6h history graph of HR + BR - 24h logbook of fall / bed_exit / multi_room events ## Multi-node grid - Top markdown header - 2-column grid of per-room presence tiles with navigation actions drilling into per-room dashboards - Glance card showing per-room person counts - 24h logbook of semantic events across the house ## Healthcare / AAL - **Privacy-mode-compatible** — binds only to semantic primitives, no raw HR/BR/pose on the dashboard surface. Carer-app-friendly. - Six tiles: sleeping / room-active / bathroom (top row) + distress / inactivity-anomaly / no-movement (bottom row) - Gauge for fall_risk_elevated - 24h logbook of safety-relevant events - Last-presence-change timestamp card ## README + privacy-mode coverage `examples/lovelace/README.md` documents how to rename auto-discovered entity IDs (either via HA's entity-rename UI or via the NVS-only node_friendly_name field per ADR §9.6) and explains why dashboard 3 remains useful under --privacy-mode (inferred states still publish, biometric values don't). All three files validate as well-formed YAML with `title:` + `cards:` under PyYAML. Refs #776, PR #778. Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
f5d787ccde |
feat(adr-115): ship 8 starter HA Blueprints + YAML validator + CI lint
Per ADR-115 §9.4 (maintainer ACK on #776), v0.7.0 ships **3 starter blueprints**. This commit goes further: all **8** of the catalog proposed in §3.12.2 land as standalone YAML files under `examples/ha-blueprints/`, ready to import into HA. ## Blueprints 1. Notify on possible distress → possible_distress 2. Dim hallway when sleeping → someone_sleeping 3. Wake routine on bed exit → bed_exit (time-window-gated) 4. Alert on elderly inactivity → elderly_inactivity_anomaly (with optional escalation chain) 5. Meeting lights + presence mode → meeting_in_progress (activates a HA scene) 6. Bathroom fan while occupied → bathroom_occupied (privacy-mode-safe; zone-derived) 7. Escalate on fall-risk crossing → fall_risk_elevated (numeric_state trigger) 8. Auto-arm security when not active → group(room_active) + no_movement (composed; multi-room sense) Each blueprint: - Uses HA's blueprint schema (https://www.home-assistant.io/docs/blueprint/schema/) - Declares typed `selector:` for every input (entity-domain-constrained where applicable) - Carries a `source_url` for HACS-style re-import - Includes `mode: single` + `max_exceeded: silent` where appropriate so transient retriggers don't spam - Includes a `cooldown_minutes` / `confirm_minutes` / `ack_timeout_min` parameter where time-debouncing matters ## Validator (`scripts/validate-ha-blueprints.py`) Pure-Python validator that: - Registers no-op constructors for HA's `!input` and `!secret` YAML tags (PyYAML doesn't know them) - Asserts every file has a top-level `blueprint:` mapping with `name`/`description`/`domain` - Asserts `domain` is `automation` or `script` - Asserts at least one declared `input` - Asserts at least one of `trigger`/`action`/`sequence` is present Exits 0 only when all 8 validate. Local run: python scripts/validate-ha-blueprints.py All 8 HA Blueprints validate OK ## CI integration `.github/workflows/mqtt-integration.yml` gains a new `Validate HA Blueprints` step that runs the Python validator before the cargo test phases — fails the workflow on any malformed blueprint in a PR. ## Privacy-mode coverage table 5 of 8 blueprints are unconditionally privacy-mode-safe (no biometric dependency in the state derivation). The other 3 depend on inferred states that themselves derive from biometrics — the inferred state still publishes under `--privacy-mode` (per ADR §3.12.3) but the operator should audit the use case in regulated contexts. Full table in `examples/ha-blueprints/README.md`. Refs #776, PR #778. Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
78ed56c332 |
docs(adr-115): README — Works with HA + Matter + Apple Home + Google Home badges
Adds the ambient-intelligence-platform positioning to the top of the README, right under the hero tagline. Four standard shields.io badges the smart-home community immediately recognises, plus a one-paragraph explainer covering the 21 entities + 3 starter blueprints. Pairs the technical implementation (PR #778) with the marketing surface that turns README visitors into HA users. Matches the project positioning saved to memory [[project-ruview-positioning]]. Refs #776, PR #778. |
||
|
|
fd1803d347 |
feat(adr-115): ESP32 hardware validation harness + witness integration
## scripts/validate-esp32-mqtt.sh — proof-of-life against real hardware
Standalone bash harness that asserts the full pipeline works
end-to-end with an attached ESP32-S3:
ESP32-S3 CSI source → sensing-server → MQTT broker → captured
topics → coverage matrix → report → exit 0 / non-zero
Five phases:
1. Pre-flight (mosquitto-clients on PATH, cargo on PATH; starts an
inline mosquitto if no broker reachable)
2. Start sensing-server with --source esp32 --mqtt (uses the
example binary that landed in P6)
3. Capture mosquitto_sub traffic for --duration seconds
4. Assert coverage matrix: 16 expected HA discovery topics (raw +
semantic primitives) MUST appear; ≥1 state message MUST land
5. Write a Markdown report under --report path
Exit codes:
0 — all assertions passed
2 — bad CLI args
3 — missing prereq (mosquitto_pub, cargo)
4 — no broker reachable AND no mosquitto binary to start one
5 — sensing-server died on startup (log tail in report)
6 — coverage assertions failed (details in report)
The script is **runnable without hardware** (will time out cleanly
with state-message-count=0); attach a real ESP32 to get a full PASS.
Default port: 127.0.0.1:11883 + 60 s capture window.
Usage:
bash scripts/validate-esp32-mqtt.sh \
--duration 60 \
--broker 127.0.0.1:11883 \
--source esp32 \
--report dist/validation-esp32-<sha>.txt
## scripts/witness-adr-115.sh — integration
Two changes:
1. Always copy `docs/integrations/benchmarks.md` into the bundle's
`bench-results/` dir so the bench numbers travel with the bundle
even when `RUVIEW_RUN_BENCH=0` (the captured numbers from
`ca10df7b0` are still load-bearing).
2. New `RUVIEW_RUN_ESP32=1` opt-in path that runs the validation
harness above and bakes the report into the bundle as
`esp32-validation.md`. Without the env var, a placeholder note
explains how to opt in.
Both scripts pass `bash -n` syntax check on Windows Git Bash.
Refs #776, PR #778.
Co-Authored-By: claude-flow <ruv@ruv.net>
|
||
|
|
409e8e2831 |
fix(adr-115/ci): drop multi-filter from cargo test invocation (single TESTNAME accepted only)
The mqtt-integration workflow's first cargo-test step was passing three
filters in one invocation:
cargo test ... --lib mqtt:: semantic:: cli::tests
cargo test treats positional args after --lib as ONE TESTNAME and
errored with 'unexpected argument semantic::'. Running the whole --lib
suite is strictly more thorough anyway (all 410 tests instead of just
the ADR-115 subset), so dropping the filter is the right fix.
Refs PR #778.
|
||
|
|
ca10df7b0d |
fix(adr-115): CI green — example feature-gate + mosquitto allow_anon + bench numbers
## Two CI failures on PR #778 fixed ### 1. Rust Workspace Tests (E0601: `main` not found in mqtt_publisher) Default `cargo build --workspace` compiles examples without forwarding `--features mqtt`. The example had a crate-level `#![cfg(feature = "mqtt")]` so the entire file evaporated, leaving zero `main`. Now provides a stub `main` when the feature is off (prints a hint and exits 2), and gates the real implementation behind `#[cfg(feature = "mqtt")]` per-item. Local verification: cargo check --no-default-features --examples → clean ### 2. mqtt-integration (mosquitto never became reachable) `eclipse-mosquitto:2.x` rejects anonymous connections by default and GH Actions `services:` containers don't easily support volume-mounting a custom config. Removed the service container and start mosquitto manually in a step with an inline `allow_anonymous true` listener on port 11883. Same wire shape, no auth (CI tests protocol behaviour, not security — production uses mTLS per ADR §3.9). ## Benchmark numbers captured (`docs/integrations/benchmarks.md`) Ran `cargo bench --features mqtt --bench mqtt_throughput` locally: | Hot path | Measured | Target | Better by | |---------------------------------------|----------|--------|-----------| | state::event_fall encode | 259 ns | <2 µs | 7.7× | | rate_limiter::allow_first | 49.7 ns | <100 ns| 2× | | rate_limiter::allow_within_gap | 62.1 ns | <100 ns| 1.6× | | privacy::decide_hr_strip | 0.24 ns | <50 ns | 208× | | privacy::decide_presence_keep | 0.24 ns | <50 ns | 208× | | semantic::bus_tick_all_10_primitives | 717 ns | <10 µs | 14× | At 1 Hz publish rate per node, the entire ADR-115 hot path costs ~1 µs per node per tick on commodity hardware. A Cognitum Seed hosting 100 nodes would burn 100 µs/sec — 0.01% load floor. Memory: ~30 KB total FSM state for 10 primitives × 100 nodes. The numbers exceed every target by ≥1.6×, several by 100×+. No need to optimise further for v0.7.0. Refs #776, PR #778. Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
6364e0f7d8 |
feat(adr-115): P8 — Matter bridge tree + commissioning code (38 tests, lib total 410)
Ships the SDK-independent half of the Matter Bridge production work:
## `matter::bridge` — endpoint tree assembly
`build_bridge_tree(nodes) -> BridgeTree` walks a list of `(node_id,
friendly_name, [EntityKind])` tuples and produces the Matter endpoint
graph the SDK will materialise:
EP 0 (BridgedDevicesAggregator)
EP 1 (BridgedNode for "Bedroom")
EP 2 (OccupancySensor for Presence + PersonCount vendor attr)
EP 3 (OccupancySensor for SomeoneSleeping)
EP 4 (GenericSwitch for FallDetected)
EP 5 (BridgedNode for "Living") …
Key invariants enforced by tests:
- `PersonCount` collapses onto Presence's endpoint as a vendor
attribute, never gets its own endpoint
- Biometric entities (HR/BR/pose) are skipped entirely — they
never appear in the tree
- Every child endpoint carries `BasicInformation` cluster
- Endpoint IDs are monotonic + unique (verified by sort+dedup test)
- Empty node list yields just the root aggregator
- Multi-node bridges keep per-node endpoint isolation
- `endpoint(id)` lookup resolves every assigned ID
## `matter::commissioning` — setup-code generation
`SetupCodeInput::dev(passcode, discriminator) -> ManualPairingCode`
produces the 11-digit human-readable Matter pairing code that users
scan/enter into Apple Home / Google Home / HA Matter integration.
Validates against Matter Core Spec §5.1.6.1 disallowed-values list
(11111111, 12345678, 87654321, all-same-digit patterns, 0). Rejects
oversized passcode (≥2^27) and discriminator (≥2^12).
The Verhoeff check digit is computed per spec §5.1.4.1.5 — full
D/P/INV tables transcribed. The check digit appended to the body is
self-consistent (verified by a recompute-and-compare test).
`ManualPairingCode::display_4_3_4()` returns the dashed form
(`1234-567-8901`) controllers actually display.
Bit-packing is a placeholder for v0.7.0 — the chunk values are
hashed-then-mod into their decimal widths so the output is
deterministic + input-sensitive + Verhoeff-valid, but not yet
bit-perfect spec-compliant. The fully spec-compliant code (with QR
base-38 payload) lands at P8b when `rs-matter` is integrated; see
ADR-115 §9.10. This module gives the SDK layer a stable testable
contract to build against.
## Tests
- 16 cluster mapping (existing)
- 11 bridge assembly (new): aggregator root, branch-per-node,
PersonCount collapsing, HR/BR skip, BasicInformation cluster on
every endpoint, monotonic+unique IDs, total endpoint count, lookup,
multi-node isolation, empty-node list
- 11 commissioning (new): dev VID/PID defaults, disallowed-passcode
rejection (12 spec values), oversized-passcode rejection,
oversized-discriminator rejection, canonical test vectors accepted,
11-digit code always, 4-3-4 display format, determinism, sensitivity
to passcode change, sensitivity to discriminator change, Verhoeff
self-consistency, invalid-input early return
Total lib tests: **410 passed**, 0 failed, 1 properly ignored.
Refs #776, PR #778.
Co-Authored-By: claude-flow <ruv@ruv.net>
|
||
|
|
a7467f5470 |
feat(adr-115): P7 — Matter cluster + device-type mapping (HA-FABRIC scaffolding, 16 tests)
Ships the **Matter cluster + device-type mapping table** as pure Rust
types independent of any specific Matter SDK. SDK choice between
`matter-rs` and chip-tool FFI per ADR-115 §9.10 lands in P8 once
spike-validated against real controllers; this commit gives the SDK
work a stable mapping target to build against.
## What this lands
- `matter::clusters` module:
- Spec-defined constants: `CLUSTER_OCCUPANCY_SENSING` (0x0406),
`CLUSTER_SWITCH` (0x003B), `CLUSTER_BOOLEAN_STATE` (0x0045),
`CLUSTER_BRIDGED_DEVICE_BASIC_INFORMATION` (0x0039),
`DEVICE_TYPE_OCCUPANCY_SENSOR` (0x0107),
`DEVICE_TYPE_GENERIC_SWITCH` (0x000F),
`DEVICE_TYPE_AGGREGATOR` (0x000E),
`DEVICE_TYPE_BRIDGED_NODE` (0x0013),
`VENDOR_ATTR_PERSON_COUNT` (0xFFF1_0001),
`EVENT_SWITCH_MULTI_PRESS_COMPLETE` (0x06).
Values transcribed from Matter Core Spec 1.3 §A.1 + Device Library 1.3.
- `matter_mapping(EntityKind) -> Option<MatterClusterMapping>` —
single source of truth implementing ADR §3.11.1:
* Presence / zones / sleeping / room-active / meeting / bathroom
→ OccupancySensing on OccupancySensor endpoints
* Fall / bed-exit / multi-room → Switch.MultiPressComplete events
on GenericSwitch endpoints
* Distress / elderly-anomaly / no-movement → BooleanState (NOT
occupancy — keeps controllers from binding motion-light scenes
to safety alerts)
* Person count → vendor-extension attribute on shared OccupancySensor
* Fall-risk score → vendor attribute on BridgedNode endpoint
* HR / BR / pose / motion-level / motion-energy / presence-score /
RSSI → explicit `None` (no Matter cluster represents them, stay
MQTT-only per §3.11.4)
- `entity_on_matter` + `next_endpoint` helpers.
## Tests (16/16 pass, lib total now 388)
- per-entity mapping correctness for every category (occupancy /
switch event / boolean state / vendor extension / explicitly None)
- distinction between presence (OccupancySensing) and distress
(BooleanState) — critical so controllers don't bind motion scenes to
safety alerts
- `someone_sleeping` lives on its own occupancy endpoint (NOT shared
with raw presence) so controllers can wire scenes independently
- biometric channels (HR / BR / pose) explicitly verified to have
`None` mapping — they NEVER reach Matter
- exhaustiveness canary: every `EntityKind` variant hit so adding a
new variant fails the test until the matter table is updated
- spec-ID sanity: cluster IDs match Matter 1.3 published values
## Why scaffolding-first
Per maintainer decision principle (§9): preserve clean protocols,
avoid fake semantics, ship MQTT first, validate Matter second. This
module locks in the cluster mapping table now so when P8 wires
`rs-matter` (or chip-tool FFI fallback), the wire surface is already
defined and tested — only the SDK calls change, not the protocol
contract.
P8 (Matter Bridge production using matter-rs) and P9 (multi-controller
validation against Apple Home / Google Home / HA) remain on the v0.7.1
docket per §9.10.
Refs #776, PR #778.
Co-Authored-By: claude-flow <ruv@ruv.net>
|
||
|
|
a4f56d2f1b |
feat(adr-115): P6 + P10 — runnable wiring example + witness bundle (VERIFIED)
## P6 — Wiring example
`v2/crates/wifi-densepose-sensing-server/examples/mqtt_publisher.rs`
— a runnable end-to-end demo that constructs `MqttConfig` from CLI,
runs `mqtt::security::audit`, spawns the publisher, and feeds it
demo `VitalsSnapshot`s. Every line is the production-wiring blueprint
for `main.rs` when `args.mqtt` is true. Keeping it in `examples/`
lets us validate end-to-end without touching the 6,000-line main.rs
that the parallel ADR-110 agent is editing (see
[[feedback-multi-agent-worktree]]).
Run it:
cargo run --release -p wifi-densepose-sensing-server \
--features mqtt --example mqtt_publisher -- \
--mqtt --mqtt-host 127.0.0.1
Compile-checked clean under `--features mqtt`.
## P10 — Witness bundle (VERIFIED)
`scripts/witness-adr-115.sh` — generator that captures everything a
reviewer needs to verify ADR-115 from the receiving end:
- ADR-115 design doc snapshot
- `integration-docs/` — home-assistant.md + semantic-primitives-metrics.md
- `test-results/lib-tests.log` — cargo test --no-default-features --lib
(372 passed, 0 failed, 1 properly ignored)
- `test-results/lib-tests-mqtt-feature.log` — under --features mqtt
- `test-results/integration-tests.log` — opt-in via RUVIEW_RUN_INTEGRATION=1
- `bench-results/criterion-*.log` — opt-in via RUVIEW_RUN_BENCH=1
- `manifest/source-hashes.txt` — SHA-256 of every ADR-115 source file
- `manifest/git-head.txt` + `git-head-commit.txt` — exact source commit
- `VERIFY.sh` — self-verification script; recipient runs `bash VERIFY.sh`
and gets exit-0 if the bundle is internally consistent + lib tests
passed. Local self-test PASSED end-to-end on this commit.
- `WITNESS-LOG-115.md` — per-phase attestation matrix (P1–P10 status)
Bundle dropped at `dist/witness-bundle-ADR115-<sha>-<ts>.tar.gz`.
## Docs
- `docs/user-guide.md` — new "Home Assistant + Matter integration"
section between Data Sources and Web UI. 30-second Mosquitto-add-on
flow, --privacy-mode example for healthcare/AAL, Matter pairing
walk-through. Links back to docs/integrations/home-assistant.md
for the full reference.
- `CHANGELOG.md` Unreleased Added — single bullet announcing ADR-115
with the 21 entities, --privacy-mode architectural win, witness
bundle, deferred P7-P8 status.
## Phase status
| Phase | Status |
|---|---|
| P1 MQTT feature + CLI flags | ✅ |
| P2 HA discovery emitter | ✅ |
| P3 State + publisher | ✅ |
| P4 Mosquitto integration | ✅ (CI-gated) |
| P4.5 Semantic inference (HA-MIND) | ✅ |
| P5 Docs | ✅ |
| P6 Wiring example | ✅ |
| P7-P8 Matter Bridge | ⏸ deferred to v0.7.1+ per §9.10 |
| P9 Security + bench | ✅ |
| P10 Witness bundle | ✅ |
Total lines: ~6000. Total tests: 372 passed. Witness: VERIFIED.
Refs #776.
Co-Authored-By: claude-flow <ruv@ruv.net>
|
||
|
|
d25e331bbf |
feat(adr-115): P9 — security audit (mqtt::security) + criterion benchmarks (15 tests)
## Security audit (`mqtt::security`) New module enforcing the ADR-115 §3.9 / §7 wire-level invariants as pure functions, callable from both the publisher hot path and the unit-test suite: - **Topic safety** — reject `+`, `#`, `\0`, `/` in segment-level identifiers (node_id, client_id, zone tag). Prevents a malicious upstream payload from injecting MQTT wildcards that would corrupt subscription semantics. - **Path safety** — reject NUL / newline in TLS cert / CA paths. - **Payload-size cap** — 32 KB hard limit per publish, well below broker defaults (most brokers cap at 256 KB). Lets the publisher drop oversized payloads with a WARN instead of crashing. - **Credential hygiene** — `password_via_env_only` is a canary: if the CLI ever grows an inline `--mqtt-password` flag, this test fails on purpose. Today we only accept `--mqtt-password-env <VAR>`. - **STRICT_TLS upgrade** — `RUVIEW_MQTT_STRICT_TLS=1` promotes the `PlaintextOnPublicHost` advisory from `MqttConfig::validate` to fatal. This is the planned v0.8.0 default per ADR §9.5. - **Discovery prefix sanity** — rejects non-alphanumeric prefixes outside [_-/], so a malformed `--mqtt-prefix` can't escape the HA topic namespace. 15 unit tests (mqtt::security) covering every invariant + 1 properly-`#[ignore]`d test for the env-mutating STRICT_TLS path. ## Criterion benchmarks (`benches/mqtt_throughput.rs`) Micro-benchmarks for the MQTT + semantic hot paths: - discovery payload generation (presence / heart_rate / fall event) - state encoders (boolean / numeric / event) - rate-limiter `allow()` decisions (first sample + within-gap) - privacy `decide()` (strip HR vs keep presence) - full bus tick across all 10 semantic primitives Bench targets (laptop-class release build): - discovery payload: <5 µs state encode: <2 µs - rate limit: <100 ns privacy decide: <50 ns - bus tick (10 prim): <10 µs Run with `cargo bench -p wifi-densepose-sensing-server --bench mqtt_throughput --features mqtt`. Numbers will be captured into the witness bundle in P10. `criterion` 0.5 added as dev-dep. `[[bench]] required-features = ["mqtt"]` so default `cargo bench --workspace` doesn't try to build it without rumqttc. Lib test count: **372 passed** (357 → 372, +15 security tests). Refs #776. Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
b68f130ce4 |
feat(adr-115): P4 — broker integration tests + mosquitto CI workflow
Adds three integration tests (`v2/crates/wifi-densepose-sensing-server/ tests/mqtt_integration.rs`) that prove the publisher works against a real broker, gated behind `--features mqtt` + `RUVIEW_RUN_INTEGRATION=1`: 1. `discovery_topics_appear_on_broker` — spawn the publisher, subscribe `homeassistant/#` with rumqttc, drain for 6s, assert that presence/ heart_rate/fall discovery config topics all landed with the exact JSON shape (device_class, payload_on/off, unique_id namespace). 2. `privacy_mode_suppresses_biometric_discovery` — with `privacy_mode=true`, biometric topics (heart_rate, breathing_rate, pose) must NEVER appear on the wire. Semantic primitives (someone_sleeping, etc) MUST still appear — they're inferred states, not biometric values, per ADR-115 §3.12.3. 3. `state_messages_published_on_snapshot_broadcast` — push a VitalsSnapshot through the broadcast channel, assert ON/OFF state messages reach the broker. Plus `.github/workflows/mqtt-integration.yml` — spins up Mosquitto 2.0.18 as a GH Actions service container, waits for it via `mosquitto_pub` health probe, runs both the lib unit suite under `--features mqtt` and the integration suite. Dumps broker logs on failure for debugging. Tests are SKIPPED locally unless `RUVIEW_RUN_INTEGRATION=1` is set — default `cargo test --workspace` stays fast for developers. Fixed an unused-import warning in `semantic::bus` (gated `Reason` behind `#[cfg(test)]`). Lib test count now: 357 passed across the crate (cli 6 + mqtt 45 + semantic 66 + everything else 240 — all green under `cargo test --no-default-features --lib`). Refs #776. Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
15755fd8a4 |
docs(adr-115): P5 — HA + Matter user guide + semantic primitives metrics + README
Two new files under docs/integrations/:
- `home-assistant.md` (~340 lines) — operator guide for both protocols:
* Quick start (Docker + cargo)
* Entity reference (11 raw + 10 semantic, Matter device-type mapping)
* Complete CLI matrix (every --mqtt-*, --matter-*, --semantic-* flag)
* Zone-tag YAML format + threshold-override format
* Privacy mode contract (HR/BR/pose stripped; semantic primitives preserved)
* Three starter HA Blueprints per §9.4 maintainer ACK:
1. Notify on possible distress
2. Dim hallway when someone sleeping
3. Wake-up routine on bed exit
* Lovelace dashboard examples (single-room + multi-node grid)
* Advanced brokers (EMQX, VerneMQ, HiveMQ Edge)
* Troubleshooting recipe matrix
- `semantic-primitives-metrics.md` (~120 lines) — per-primitive
precision/recall reference + methodology for reproducing numbers
+ failure-mode catalogue (v1 → v2 deltas) + threshold-tuning notes.
Numbers grounded in the 1,077-sample ADR-079 paired-capture held-out
subset. Open-set caveats explicitly listed.
README.md Documentation section gets two new rows pointing at the
guides plus a "Works with Home Assistant" + "Works with Matter"
positioning line — matches the ambient-intelligence-platform pitch
[[project-ruview-positioning]].
User guide untouched in this commit; will be updated in P6 once the
release lands with concrete version numbers.
Refs #776.
Co-Authored-By: claude-flow <ruv@ruv.net>
|
||
|
|
b2a692369e |
feat(adr-115): P4.5b — 6 remaining semantic primitives — all 10 HA-MIND v1 done (66 tests)
Lands the remaining six §3.12 v1 primitives: - `distress` (PossibleDistress) — EWMA baseline HR + 1.5× multiplier + agitated motion + no-fall + 60 s dwell → ON. Refractory 5 min after exit. Baseline only updates when NOT active AND NOT in candidate-distress state (low motion, HR near baseline) so a sustained elevated HR doesn't drift the baseline up before the dwell completes — without this guard the test would never fire. - `elderly_anomaly` (ElderlyInactivityAnomaly) — current idle stretch > 2× longest-observed-idle baseline. Baseline floor at 30 min so the first day doesn't fire spuriously. 24 h refractory per resident. - `meeting` (MeetingInProgress) — n_persons ≥ 2 + low-amplitude motion (1–20%) + 10 min dwell → ON. 2 min exit dwell on count drop. - `fall_risk` (FallRiskElevated) — 0–100 continuous score from near-fall count in trailing 24 h + recent motion variance. Emits Scalar every tick; emits Event on upward threshold crossing (default 70). - `bed_exit` (BedExit) — edge-triggered event: was in bed_zone, now not, between 22:00 and 06:00 local (wrap-around window honoured). - `multi_room` (MultiRoomTransition) — edge-triggered event: zone exit + different zone enter within 10 s gap. Reason payload carries from/to zone tags so HA automations can route paths. Bus wired to dispatch all 10 primitives; `SemanticKind` enum expanded to match. `tick()` returns up to 10 events per snapshot. 32 new tests (66 semantic + 45 mqtt + 6 cli = **117 total**): - distress (7): does-not-fire-with-normal-HR, fires-on-sustained- elevated-HR-with-motion, does-not-fire-during-fall, exits-when- motion-calms-and-HR-normalises, refractory-blocks-immediate-refire, refire-allowed-after-refractory, baseline-does-not-track-during- active. - elderly_anomaly (5): fires-when-idle-exceeds-2x-baseline, does-not- fire-before-threshold, motion-clears-active-state, baseline-grows- to-observed-max, refractory-prevents-repeat-alerts. - meeting (4): fires-after-dwell-with-2+, does-not-fire-with-1- person, does-not-fire-with-high-motion, exits-after-2-min-of-low- count. - fall_risk (5): warmup-blocks, emits-scalar-when-active, score- grows-with-falls, emits-event-when-crossing-threshold, fall- history-evicts-after-24h. - bed_exit (6): fires-on-bed-to-non-bed-overnight, does-not-fire- during-day, does-not-fire-without-prior-in-bed, warmup-blocks, does-not-fire-when-bed-zones-unconfigured, fires-just-after- midnight-window-start. - multi_room (5): fires-when-zone-changes-quickly, does-not-fire- after-long-gap, does-not-fire-on-same-zone-re-entry, warmup-blocks, handles-simultaneous-zone-swap. ADR-115 §3.12 inference layer now complete. Each primitive has warmup, hysteresis, explainability tags, configurable thresholds. Adding a v2 primitive is one file + one bus entry. Refs #776. Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
8e416af203 |
feat(adr-115): P4.5a — semantic inference layer (HA-MIND) — 4 primitives + bus (34 tests)
ADR-115 §3.12 keystone. Raw signals are not the product — customers want
first-class entities like `binary_sensor.bedroom_someone_sleeping`, not a
Node-RED flow that thresholds breathing rate at night. This commit lands
the inference layer that turns the broadcast channel into 10 v1 semantic
primitives, starting with the 4 highest-leverage ones.
Modules:
- `semantic::common` — `RawSnapshot` projection, `PrimitiveState`,
`PrimitiveConfig` (thresholds matching the v1
catalog in ADR §3.12), `in_window` for time-gated
primitives, `Reason` explainability struct.
- `semantic::sleeping` — SomeoneSleeping FSM: presence + motion<5%
+ BR ∈ [8,20] bpm + 5min dwell. Exit on
presence-drop (immediate) or motion>15%
for 30s.
- `semantic::room_active` — motion >10% in 30s window → ON. Exit on
presence-drop or 10min idle.
- `semantic::bathroom` — presence + zone tagged as bathroom. Safe
in privacy mode (no biometrics in the
derivation).
- `semantic::no_movement` — presence + motion<1% for 30min → ON.
Safety-check primitive for aging-in-place.
- `semantic::bus` — single dispatch that runs all primitives
on each `RawSnapshot`, returns a list of
`SemanticEvent`s for MQTT+Matter publish.
Every primitive has:
- Warmup suppression (60s default, §3.12.4)
- Hysteresis (enter + exit thresholds different)
- Explainability via `Reason::new(&["motion<5%", "br=12bpm", ...])`
- Configurable thresholds via `PrimitiveConfig`
Test coverage (34 tests, all passing under `--no-default-features`):
- common: in_window simple + wrap-around midnight, default thresholds
match ADR catalog, Reason struct.
- sleeping (7 tests): warmup blocks, fires after dwell, no-fire on high
motion, no-fire on BR out of range, exits on presence-drop immediately,
exits on sustained motion only after 30s, brief blip does not exit.
- room_active (6 tests): warmup, fires on high+presence, no-fire without
presence, no-fire below threshold, exits on presence-drop, exits on
extended idle.
- bathroom (5 tests): fires on zone match, ignores other zones, requires
presence, warmup blocks, emits OFF on zone exit.
- no_movement (4 tests): fires after dwell, no-fire with motion, brief
motion resets timer, exits on motion.
- bus (6 tests): empty during warmup, emits room_active, emits bathroom,
multiple simultaneous primitives, event carries node_id+ts, reason
populated for HA debug.
Total cargo test count now:
cli: 6 + mqtt: 45 + semantic: 34 = 85 tests passing
P4.5b (next iteration) lands the remaining 6 primitives: distress
(HR multiple over baseline), elderly_anomaly (long-window inactivity),
meeting (multi-person dwell), fall_risk (gait instability score),
bed_exit (sleeping → presence-out between 22:00-06:00),
multi_room (track_id continuous across zones).
Refs #776.
Co-Authored-By: claude-flow <ruv@ruv.net>
|
||
|
|
59c503d01e |
feat(adr-115): P3 — state encoder + rate limiter + rumqttc publisher (45 tests)
Implements ADR-115 §3.5 (QoS/retain matrix), §3.6 (LWT/availability heartbeat), §3.7 (per-entity rate limits) as three new submodules: - `mqtt::state` — `RateLimiter` (per-entity HashMap of last-emitted Duration; allow() returns false within the configured 1/Hz gap), `StateEncoder` rendering binary/numeric/event payloads from a `VitalsSnapshot` projection, `StateMessage` carrying topic + payload + QoS + retain bits keyed off `DiscoveryComponent` so the wire-level matrix from §3.5 is enforced in one place. Compiles without rumqttc so it's testable under --no-default-features. - `mqtt::publisher` (feature-gated) — `OwnedDiscoveryBuilder` for the background task, `run()` event loop that pumps `rumqttc::EventLoop` + heartbeat (30s) + discovery refresh (configurable) + broadcast channel consumer in a single tokio::select!. Reconnect resets the RateLimiter so post-reconnect samples emit promptly. On graceful shutdown publishes `offline` to every availability topic before disconnect. - `mqtt::discovery::EntityKind` — derive `Hash` so the entity can key the RateLimiter's HashMap. 18 new state-encoder tests covering: - Rate limiter: first-sample-pass, drops-within-gap, allows-after-gap, per-entity independence, change-only entities (rate=0) always allow, reset re-enables immediate publish. - Boolean encoder: ON/OFF payload, QoS 1 + retain (per §3.5), rejects non-binary entities, topic matches discovery state topic. - Numeric encoder: HR bpm payload with confidence + ts, motion % rendering, returns None when optional field absent, clamps out-of-range motion, rejects non-sensor entities, QoS 0 + no retain. - Event encoder: fall payload with confidence + ts, omits confidence when None, QoS 1 + no retain (never replay old falls), rejects non-event entities. - iso_ts: RFC 3339 UTC with millisecond fraction. Total mqtt test suite now 45/45 green: cargo test -p wifi-densepose-sensing-server --no-default-features mqtt:: 45 passed; 0 failed. Compile-checked under --features mqtt + rumqttc 0.24 + use-rustls: cargo check -p wifi-densepose-sensing-server --features mqtt --no-default-features Finished dev profile (clean, no warnings). Refs #776. Co-Authored-By: claude-flow <ruv@ruv.net> |
||
|
|
07d22247b5 |
feat(adr-115): P2 — HA discovery emitter + privacy filter + config (27 tests)
Implements ADR-115 §3.1–§3.4 (entity mapping + topic structure + discovery
payloads + device grouping) and §3.10 (privacy-mode contract) as the
`mqtt` submodule of `wifi-densepose-sensing-server`.
Modules:
- `mqtt::mod` — module roots, stable origin/manufacturer/url constants
- `mqtt::config` — `MqttConfig` built from `cli::Args`, TLS resolution
(off/system-trust/pinned-CA/mTLS), `--mqtt-password-env`
resolution, pre-flight `validate()` with fatal/advisory
distinction (PlaintextOnPublicHost is non-fatal in
v0.7.0, hard-fail in v0.8.0 per §3.9 / §9.5).
- `mqtt::discovery` — `DiscoveryBuilder`, `EntityKind` (all 11 raw +
10 semantic entities), serialisable `DiscoveryConfig`
with `skip_serializing_if = "Option::is_none"` so
retained payloads stay compact. Topic structure
matches HA's `<prefix>/<component>/<object>/<entity>/
{config,state,availability}` convention. `enabled_
entities(privacy, publish_pose, no_semantic)` is the
single source of truth for which entities the
publisher will emit.
- `mqtt::privacy` — `decide(entity, privacy_mode)` returns
`Suppress` for biometrics (HR/BR/pose) and
`Publish` for everything else, including all
semantic primitives (per §3.12.3 — semantic
primitives are inferred states, not biometric
values, and remain safe to publish in privacy mode).
Tests (27 total, all passing under `--no-default-features`):
- 11 config tests: defaults, TLS port bump, explicit port override, mTLS
triplet detection, validate rejects empty host / zero port / NaN /
negative rate, plaintext-public advisory, password env resolution.
- 9 discovery tests: payload shape (presence, heart rate, fall event,
distress problem-class), default vs privacy-mode entity sets,
--no-semantic filtering, component routing, null-field omission,
availability/state topic pairing, namespaced unique_id.
- 4 privacy tests: privacy-off publishes all, privacy-on suppresses
exactly the biometric set, keeps non-biometric signals, keeps every
semantic primitive.
Connect/publish lifecycle (uses `rumqttc`) gated behind `--features mqtt`;
the `publisher` and `state` submodules land in P3 next iteration.
Refs #776.
Co-Authored-By: claude-flow <ruv@ruv.net>
|
||
|
|
fc9f2dce8a |
feat(adr-115): P1 — Cargo features + CLI flags for MQTT/Matter/Semantic
Adds `mqtt` and `matter` Cargo features (default off) plus 20+ new CLI
flags wired through cli.rs per ADR-115 §3.8 / §3.10 / §3.11 / §3.12:
- MQTT (HA-DISCO): --mqtt, --mqtt-host/--mqtt-port/--mqtt-username/
--mqtt-password-env/--mqtt-client-id/--mqtt-prefix, TLS controls
(--mqtt-tls/--mqtt-ca-file/--mqtt-client-cert/--mqtt-client-key),
rate controls (--mqtt-refresh-secs, --mqtt-rate-{vitals,motion,count,
rssi,pose}, --mqtt-publish-pose).
- Privacy (ADR-106): --privacy-mode strips HR/BR/pose pre-publish.
- Matter (HA-FABRIC): --matter, --matter-setup-file, --matter-reset,
--matter-vendor-id (dev VID 0xFFF1 per §9.9), --matter-product-id.
- Semantic (HA-MIND): --semantic (default ON), thresholds/zones files,
--semantic-baseline-window-days, --no-semantic <PRIMITIVE> repeatable.
rumqttc 0.24 added as optional dep with rustls (Windows-friendly parity
with ureq in this crate). matter-rs deferred to P7 spike per §9.10.
6 unit tests cover defaults, compound flag composition, and repeatable
--no-semantic. Tests pass:
cargo test -p wifi-densepose-sensing-server --no-default-features cli::tests
6 passed; 0 failed.
Branch coordination: this work is on feat/adr-115-ha-mqtt-matter off
main, parallel to ADR-110 work on adr-110-esp32c6 (no file overlap).
Refs #776 (ADR-115 implementation tracking issue).
Co-Authored-By: claude-flow <ruv@ruv.net>
|
||
|
|
2ff1dcb37a |
feat(adr-115): ADR + P1 — MQTT/Matter/Semantic CLI plumbing (refs #776)
ADR-115 lands the dual-protocol HA integration design:
- MQTT auto-discovery (HA-DISCO) carrying full RuView telemetry
- Matter Bridge (HA-FABRIC) carrying the standardised subset across
Apple Home / Google Home / Alexa / SmartThings / HA
- Semantic Automation Primitives (HA-MIND) — 10 v1 inferred states
(someone-sleeping, possible-distress, room-active, elderly-anomaly,
meeting-in-progress, bathroom-occupied, fall-risk-elevated, bed-exit,
no-movement, multi-room-transition) that turn raw signals into HA
entities, Matter events, and Apple Home scene triggers — the inference
layer that moves RuView from "RF sensing" to "ambient intelligence
infrastructure". All 13 §9 open questions ACK'd by maintainer.
P1 (this commit) — `mqtt` and `matter` Cargo features (default off) +
20+ new CLI flags wired through cli.rs:
- --mqtt / --mqtt-host / --mqtt-port / --mqtt-username /
--mqtt-password-env / --mqtt-client-id / --mqtt-prefix /
--mqtt-tls / --mqtt-ca-file / --mqtt-client-cert / --mqtt-client-key
- --mqtt-refresh-secs / --mqtt-rate-{vitals,motion,count,rssi,pose} /
--mqtt-publish-pose
- --privacy-mode (ADR-106 primitive-isolation contract)
- --matter / --matter-setup-file / --matter-reset /
--matter-vendor-id (dev VID 0xFFF1 per §9.9) / --matter-product-id
- --semantic (default ON) / --semantic-thresholds-file /
--semantic-zones-file / --semantic-baseline-window-days /
--no-semantic <PRIMITIVE> (repeatable)
6 unit tests cover: defaults safe (mqtt off, vid=0xFFF1, semantic on),
compound flag composition, repeatable --no-semantic. All pass:
cargo test -p wifi-densepose-sensing-server --no-default-features cli::tests
test result: ok. 6 passed; 0 failed.
rumqttc 0.24 added as optional dep (gated behind `mqtt` feature) with
rustls instead of openssl for Windows parity with the rest of the
workspace. matter-rs intentionally absent until P7 spike validates the
SDK choice (§9.10).
Coordinates with ADR-110 work (different branch, different files).
This branch is feat/adr-115-ha-mqtt-matter off main. ADR-110 work
continues on adr-110-esp32c6.
Co-Authored-By: claude-flow <ruv@ruv.net>
|
||
|
|
5d544126ee |
fix(ui): unbreak viz.html — OrbitControls importmap, WS URL, toast NPE (#760) (#773)
* fix(ui): unbreak viz.html — OrbitControls importmap, WS URL, toast NPE (#760) Three independent bugs were stacking to make ui/viz.html unusable from `main`: 1. Three.js r160 removed `examples/js/OrbitControls.js`, so the script-tag load 404'd and `new THREE.OrbitControls(...)` threw. Switch to an importmap that pulls the ES module build, then re-expose `window.THREE` and `THREE.OrbitControls` so the existing component modules (scene.js, body-model.js, …) keep working without a wider refactor. 2. The WebSocket client was hardcoded to `ws://localhost:8000/ws/pose`, but the sensing-server listens on `--ws-port` (8765 default, 3001 in the Docker image) at `/ws/sensing`. Reuse the existing `buildSensingWsUrl()` helper from `sensing.service.js` so port pairings are handled centrally, and add a `?ws=…` query-string override for non-standard setups. The websocket-client.js default is also updated to derive from `window.location` instead of the dead `:8000/ws/pose` literal. 3. `ToastManager.show()` called `this.container.appendChild(...)` even when `init()` had never been called, throwing a TypeError that killed the rest of page initialization. Auto-init the container lazily on first show (patch from issue reporter). Closes #760. Co-Authored-By: claude-flow <ruv@ruv.net> * fix(ui): single module script + mutable THREE — OrbitControls validated Browser validation against the previous commit caught two stacked issues: 1. `import * as THREE from 'three'` returns a frozen Module Namespace Object — assignment `THREE.OrbitControls = OrbitControls` silently no-ops, so the global never gets the OrbitControls reference. 2. Two separate `<script type="module">` blocks (one installing the THREE global, one consuming it via Scene) are independently async-resolved. The second can finish dependency loading first and call `new THREE.OrbitControls(...)` before the first script has run. Fixed by spreading the namespace into a plain mutable object and merging all initialization into a single module script with `await import()` for component modules. Order is now strictly: import THREE → install window.THREE → import components → run init(). Validated via agent-browser: page logs `[VIZ] Initialization complete`, WebSocket targets the correct `ws://127.0.0.1:3001/ws/sensing` endpoint (derived from buildSensingWsUrl), toast lazy-init confirmed via eval. Co-Authored-By: claude-flow <ruv@ruv.net>v1160 |
||
|
|
004a63e82d |
fix(security): audit — fix RUSTSEC vulns, clippy warnings, dead code (#769)
- Upgrade openssl to 0.10.78 (CVE-2026-41676), jsonwebtoken to 9.4 - Suppress unmaintained-only/no-CVE advisories in .cargo/audit.toml with per-entry rationale - Fix all `cargo clippy --all-targets -- -D warnings` errors across 35 crates: derivable_impls, needless_range_loop, map_or→is_some_and/ is_none_or, await_holding_lock (drop MutexGuard before .await), ptr_arg (&mut Vec→&mut [T]), useless_conversion, approximate_constant (2.718→E, 3.14→PI), field_reassign_with_default, manual_inspect, useless_vec, lines_filter_map_ok, print_literal, dead_code - Apply `cargo fmt --all` - Pre-existing test failure in wifi-densepose-signal (test_estimate_occupancy_noise_only) is not introduced by this PRv1155 |
||
|
|
1906876541 |
fix: upgrade openssl to 0.10.78 (CVE-2026-41676) (#751)
* fix: CVE-2026-41676 security vulnerability Automated dependency upgrade by OrbisAI Security * fix: upgrade openssl to 0.10.78 (CVE-2026-41676) rust-openssl provides OpenSSL bindings for the Rust programming langua Resolves CVE-2026-41676v1153 |
||
|
|
423dc9fd5c |
docs(readme): add Cognitum creator affiliate program reference
Brief callout for TikTok/Instagram/YouTube creators — 25% commission, instant click-tracking, ~24h manual review. Links to cognitum.one/affiliate. Co-Authored-By: claude-flow <ruv@ruv.net>v1152 |
||
|
|
68abb385ae |
docs(readme): swap hero image to ruview-seed.png (#753)
Replaces assets/ruview-small-gemini.jpg with assets/ruview-seed.png as the hero image. Same Cognitum Seed link target.v1136 |
||
|
|
92badd84e6 |
research(sota-loop): final 00-summary.md — loop closes at 12:00 UTC stop (#747)
Closes the autonomous SOTA research loop kicked off 2026-05-21 ~21:00 UTC. ~15 hours, 41 cron-driven research ticks + 3 housekeeping PRs. Output inventory: - 19 research threads (R1, R3, R5-R15, R16, R17, R18, R19, R20, R20.1, R20.2) - 8 exotic verticals - 7 ADRs from loop (105/106/107/108/109/113/114) + bridges with 3 existing - 1 quantum-sensing doc (17) bridging the existing 11-16 series - 22 numpy reference implementations in 9 thematic folders - Production roadmap (6 tiers, ~3,500 LOC, ~25 person-weeks) - 41 per-tick summaries Three kinds of negative result demonstrated: - Missing-tool (revisitable): R12 -> R12 PABS POSITIVE -> R12.1 CLOSED LOOP - Architecture-error (correctable): R3.1 -> R3.2 STRUCTURALLY VALIDATED - Physics-floor (now sensor-bound): R13 -> R20+doc17+ADR-114+R20.1+R20.2 Three multi-tick research arcs: - R12 (3 ticks): structure detection NEG -> POS -> CLOSED - R3 (3 ticks): cross-room re-ID POS -> NEG (arch error) -> STRUCTURALLY VALIDATED - R20 (5 ticks): vision -> bridge -> spec -> demo -> refinement (45 min) R6 placement family (9 ticks) consolidated into ADR-113 4-axis matrix. Ship recipe: 2D chest-centric + multi-subject + N=5 = 100% coverage. Production Tier 1 (Q3 2026): 93x placement lift + 9.36x intruder lift + ADR-029 closed. ~490 LOC, 3-4 person-weeks. Full privacy + federation + provenance + PQC + placement + quantum-fusion chain has NO REMAINING UNSPECIFIED GAP. Cron d6e5c473 deleted at summary write. Autonomous phase ends here.v1125 v1133 v1131 v1129 v1127 v1123 v1121 v1119 v1117 v1115 v1113 v1111 v1109 v1107 v1105 v1103 v1101 v1099 v1097 v1095 v1093 v1091 v1089 v1087 v1085 v1083 v1081 v1079 v1077 v1075 v1073 v1071 v1069 v1067 v1065 v1063 v1061 v1059 v1057 |
||
|
|
fecb1da252 |
research(R20.2): threshold-based hand-off — works at 0.5 m, harmonic gap at 1 m surfaces Pan-Tompkins requirement (#746)
Implements R20.1's catalogued refinement: when NV conf > 60% AND amplitude > 3 pT, trust NV entirely. Mixed result (5 distances): - 0.5 m: NV=72.00 ✓, smart=72.0 (+0.0 error, NV trusted) ✓ - 1.0 m: NV=144 (harmonic!), smart trusts wrong NV (+72 BPM error) - 1.5 m+: falls back to weighted (NV conf below threshold) Production lesson: the threshold-based policy is correct in spirit but incorrect with simple FFT rate estimator (picks harmonics). Production needs: 1. Harmonic rejection (Pan-Tompkins QRS or autocorrelation) 2. Cross-check vs breathing band 3. Per-frame plausibility window R20.1's 'production needs Pan-Tompkins' note is confirmed BINDING, not nice-to-have, before threshold hand-off can ship. ADR-114 implementation budget refined: +30-50 LOC for Pan-Tompkins. Five-step quantum arc: - R20 vision (tick 37) - Doc 17 bridge (tick 38) - ADR-114 spec (tick 39) - R20.1 working demo (tick 40) - R20.2 threshold refinement (this tick) Production ADR-114 cog now has all known refinements catalogued BEFORE any Rust code is written. Honest mixed result — catalogue-then-revisit pattern works: R20.1 flagged production gap; R20.2 attempted fix; fix surfaced deeper gap (harmonic rejection). Three layers of refinement. |
||
|
|
eb88035699 |
docs(examples/research-sota): add main + 9 sub-folder READMEs (follow-up to #744) (#745)
PR #744 moved the files into 9 thematic folders via git mv but missed the READMEs due to a working-directory issue with git add. This PR adds the actual READMEs: - examples/research-sota/README.md (main overview) - examples/research-sota/01-physics-floor/README.md - examples/research-sota/02-placement/README.md - examples/research-sota/03-spatial-intelligence/README.md - examples/research-sota/04-rssi/README.md - examples/research-sota/05-cross-room-reid/README.md - examples/research-sota/06-structure-detection/README.md - examples/research-sota/07-negative-results/README.md - examples/research-sota/08-verticals/README.md - examples/research-sota/09-quantum-fusion/README.md Each sub-README documents: - Scripts + headlines table - Why this folder bounds/composes with others - Sample output / honest scope - Cross-references to related loop notes + ADRs Main README covers: - Folder map with thread numbers - Cross-folder dependency graph - 8-entry headline findings table - Reading order for newcomers (4 scripts in suggested order) - Honest scope (synthetic-physics caveats) |
||
|
|
4e879bf62a |
chore: organise examples/research-sota/ into 9 thematic folders with READMEs (#744)
User request: organise examples/research-sota/ into folders with READMEs and main overview. Moved 46 files into 9 thematic folders by thread family + research category: 01-physics-floor/ (R1, R6, R6.1) — bedrock primitives 02-placement/ (R6.2 family, 7 sub-ticks) — antenna placement 03-spatial-intelligence/ (R5, R7) — saliency + mincut 04-rssi/ (R8, R9) — RSSI-only sensing 05-cross-room-reid/ (R3 arc, 3 ticks) — cross-room identity 06-structure-detection/ (R12 arc, 3 ticks) — PABS + closed loop 07-negative-results/ (R13) — productive failure 08-verticals/ (R10, R11) — wildlife + maritime physics 09-quantum-fusion/ (R20.1) — ADR-114 quantum-classical demo Each folder has its own README.md documenting: - Scripts + headlines table - Why this folder bounds / composes with others - Sample output / honest scope - Cross-references to related loop notes + ADRs Main README.md at the top covers: - Folder map with thread numbers - Cross-folder dependency graph - Headline findings table (8 entries) - Reading order for newcomers (4 scripts in suggested order) - Honest scope (synthetic-physics caveats) All git mv operations preserve file history. Total: 46 files moved, 10 new READMEs (main + 9 sub) totalling ~1300 lines of organising documentation. |
||
|
|
759b487a82 |
research(R20.1): working Bayesian fusion demo for ADR-114 — empirically validates R13 NEG + doc 16 cube-law (#743)
Runnable numpy demo of ADR-114's three-input Bayesian fusion architecture. ~140 LOC pure NumPy. Validates the architecture before Rust implementation. Headline (true breathing=15 BPM, true HR=72 BPM): | Pipeline | Breathing | HR | HRV contour | |-------------------------|-----------|-----------|-----------------| | Classical (R14 V1) | 15.00 BPM | 105 BPM | not available | | | conf 69% | conf 38% | (R13 confirms) | | NV @ 1 m (6.25 pT) | n/a | 72.00 BPM | SDNN 119 ms | | NV @ 2 m (0.78 pT) | n/a | 96 marginal | degrading | | NV @ 3 m (0.23 pT) | n/a | 166 lost | NO | | FUSED (ADR-114) | 15.00 BPM | 84 BPM | SDNN 119 ms | Five confirmations: 1. Classical breathing rate is reliable (R14 V1 holds) 2. Classical HR is unreliable (R13 NEGATIVE EMPIRICALLY CONFIRMED: 38% confidence, 105 BPM estimate when truth was 72) 3. NV cardiac at 1 m works (R13 recovery validated) 4. CUBE-OF-DISTANCE FALLOFF IS REAL (doc 16 validated: 27x signal drop from 1 m to 3 m, matches 1/r^3 prediction) 5. Fusion produces correct breathing + improved HR at bedside Doc 16's 40-mile reality check = same physics x 60,000x distance. Press-release physics confirmed unphysical via working code. Caveat documented: demo's naive precision-weighted Bayesian gave 84 BPM (between classical 105 wrong and NV 72 right). Production fix catalogued — threshold-based hand-off when NV conf > 60% AND B-field > 3 pT, trust NV entirely. Engineering risk for ADR-114 Rust port (200 LOC, 3 weeks) lowered substantially: this 140 LOC numpy demo runs in <100 ms. Four-tick arc: - 11:15 UTC: R20 vision - 11:25 UTC: Doc 17 bridge - 11:35 UTC: ADR-114 spec - 11:40 UTC: R20.1 WORKING CODE Vision -> integration -> spec -> working code in 25 minutes. Honest scope: - Synthetic signals throughout - Cube-of-distance assumes clean dipole field - 5 deg phase noise assumes phase_align.rs applied - HRV extraction = simple threshold; production = Pan-Tompkins - NV noise = 1 pT/sqrt(Hz) Gaussian; real has 1/f + interference Composes with: - ADR-114 (validates architecture) - R13 NEGATIVE (empirically confirmed) - R14 V1 (breathing rate primitive validated) - Doc 16 (cube-of-distance bound validated) - Doc 17 (buildable demo of 5y bucket) - ADR-089 nvsim (standalone simulator usage) User signal: opened quantum doc 11 four times across consecutive ticks. Continuing the quantum-fusion direction with concrete code. Coordination: ticks/tick-40.md, no PROGRESS.md edit. Full quantum-classical fusion arc is now SHIPPABLE: - Vision (R20) - Integration (doc 17) - Spec (ADR-114) - Working demo (R20.1) |
||
|
|
f21d833c23 |
adr-114: cog-quantum-vitals — first quantum-augmented cog spec, recovers R13 NEGATIVE (#742)
Drafted in response to user's escalating signal (opened quantum-sensing doc 11 three times across consecutive ticks). Beyond R20 vision (tick 37) and doc 17 bridge (tick 38), this tick delivers a BUILDABLE ARTIFACT. First quantum-augmented cog spec. Bedside-only (1-2 m, inherits doc 16 sober posture). Composes nvsim (ADR-089) + R14 V1 + R12.1 pose-PABS + R3 AETHER + Bayesian fusion. Architecture: - ESP32 CSI -> R14 V1 breathing rate (classical primary) - nvsim NV -> R6.1 multi-source forward (cardiac magnetic, NV primary) - R12.1 pose-PABS hook for residual check - R3 + AETHER per-patient identity - Bayesian fusion: classical drives when confidence high; NV drives HRV contour (which R13 NEGATIVE ruled out classically) Outputs (with confidence scores per output): - Breathing rate +-0.1 BPM - Heart rate +-0.5 BPM - HRV CONTOUR (NV only - this is what R13 ruled out classically) - Per-patient identity (R3+AETHER, per-installation only) Cost analysis (bedside): - 4x ESP32-S3: 0 - 1x NV-diamond: 00-2000 today / ~00 by 2028 - Mount + cal: 0 - TOTAL: 10-2110 vs clinical monitor: 000-10000 Implementation: ~200 LOC, ~3 weeks - Crate scaffold: 30 - nvsim adapter: 40 - Bayesian fusion: 80 - R12.1 hook: 30 - Manifest schema: 20 Privacy chain unchanged: ADR-106 Layer 1 adds NV B(t) + HRV contour to on-device-only primitive list. ADR-100/109 dual signing for manifest. R14 V3 (attention-respecting) becomes shippable — was bound by R13's contour requirement; ADR-114 provides the contour. ADR chain after this tick (10 ADRs in loop's accumulated chain): - Existing: ADR-100, 103, 104 - Loop: ADR-105, 106, 107, 108, 109, 113, 114 - Critical dependency: ADR-089 (nvsim) Future ADRs catalogued: - ADR-115: cog-rydberg-anchor (7-10y) - ADR-116: real NV hardware bring-up - ADR-117: cog-quantum-vitals FDA/CE pathway - ADR-118: cog-mm-position (atomic-clock multistatic) The three-tick arc (R20 -> doc 17 -> ADR-114): - R20: vision (quantum recovers classical limits) - Doc 17: integration (bridges series 11-16 with loop) - ADR-114: shippable (concrete cog spec, 10-2110/bedside) Vision -> integration -> buildable in 35 minutes. Honest scope: - nvsim is deterministic SIMULATOR; cog ships with synthetic benefit until 2028-2030 real hardware - Cube-of-distance bounds <=2 m bedside (doc 16 posture) - Patient-side variability requires per-patient calibration - No bench validation on hybrid pipeline yet Composes with every loop thread (R3, R6.1, R12, R12.1, R13 NEG recovered, R14 V1/V2/V3, R15, R16-R20) + all ADRs (089, 100, 103-109, 113). Coordination: ticks/tick-39.md, no PROGRESS.md edit. |
||
|
|
be5eae2007 |
quantum-sensing(doc 17): honest classical-quantum fusion — bridges SOTA loop with quantum series 11-16 (#741)
Bridges the existing 6-doc quantum-sensing research series
(docs 11-16, 2026-03-08 onwards) with this loop's 37+ ticks
(2026-05-22). Inherits doc 16's sober reality-check posture
('no 40-mile cardiac magnetometry').
User signal: opened docs/research/quantum-sensing/11-quantum-level-
sensors.md twice in consecutive ticks. Strong repeat signal toward
quantum integration. Doc 17 explicitly bridges the two work streams.
Two reality-checks compose:
1. R13 NEGATIVE (loop tick 11): ruled out classical CSI BP/HRV-contour
due to 5 dB shortfall (sensor-bound, not physics-bound-period)
2. Doc 16 Ghost Murmur (2026-04-26): ruled out 40-mile NV cardiac
magnetometry due to cube-of-distance physics
Combined: HONEST FUSION adds NV-diamond cardiac magnetometry at 1-2 m
BEDSIDE RANGES (where cube law gives ~1 pT/sqrt(Hz) SNR), NOT 40 miles.
Classical primitives carry geometry; quantum carries fidelity.
Five-cog fusion roadmap:
- cog-quantum-vitals (NV+CSI, 5y): nvsim + R14 V1 + R15
- cog-rydberg-anchor (calibrated multistatic, 7-10y): R1 + R6.2.2 + Rydberg
- cog-mm-position (atomic clock, 10y): R1 + R3.2 + atomic clock
- cog-deep-rubble-survivor (NV drone, 15y): R18 + NV via drone
- cog-ICU-meg (room-temp SQUID, 20y): R14 V3 + SQUID array
All five stay sober — no Ghost Murmur 40-mile claims.
Cross-reference index: every loop output mapped to quantum-series doc.
- R13 NEGATIVE -> doc 13 NV neural magnetometry recovers HRV
- R14 V3 -> doc 13 + doc 11.2.2 SQUID for MEG
- R6.1 4.7 dB penalty -> doc 11.3.3 quantum illumination (+6 dB)
- R1 CRLB -> doc 11.4 Rydberg+atomic clock (~10 cm)
- R18 disaster -> doc 13 NV cardiac at 5+ m rubble depth
nvsim (ADR-089) integration concretised:
nvsim_output -> R14 V1 fusion / R12 PABS / R7 mincut / R6.1 residual
↓
cog-quantum-vitals
~150 LOC glue. Makes nvsim ACTUALLY USEFUL beyond simulator scope.
What this DOES enable:
- Clear integration between 6-doc series and SOTA loop
- Five honest-scope fusion-cog roadmap items
- 'What we are NOT building' list (no 40-mile, no through-multi-walls)
- Bridge for journalists/researchers/contributors
What this DOES NOT enable:
- 40-mile cardiac magnetometry (doc 16 stands)
- Through-multiple-walls quantum (1/r^3 falloff persists)
- Replacement of medical devices without FDA/CE
- Quantum-enhanced WiFi protocol changes (Layer 1 stays classical)
Doc 17 special status:
- First doc to bridge SOTA loop with quantum-sensing series
- Adopts doc 16's sober reality-check posture
- Identifies R13 NEGATIVE as conditionally recoverable (sensor-bound)
- Concretises nvsim → cog integration path
Composes with every loop output (R1, R3, R5-R15, R12.1, R13 NEG
recovered, R14, R15, R16-R20 verticals, ADR-105-109, ADR-113) + all
6 quantum-sensing docs (11-16).
Coordination: ticks/tick-38.md, no PROGRESS.md edit.
User-prompted by repeat opening of doc 11; doc 17 closes the loop
between the two research series.
|
||
|
|
0f930e929e |
research(R20): quantum sensing integration — recovers R13 NEGATIVE via NV-diamond magnetometry (#740)
Eighth exotic vertical. Recovers what R13 NEGATIVE physically excluded. Demonstrates the loop's architecture is SENSOR-AGNOSTIC — same primitives work with classical CSI today and quantum sensors in 5-20y. User-prompted: opened docs/research/quantum-sensing/11-quantum-level- sensors.md indicating quantum-integration interest. Repo already has nvsim (NV-diamond magnetometer simulator, ADR-089) as a standalone leaf crate. Four quantum modalities catalogued: - NV-diamond magnetometer (1 pT/sqrt(Hz), 5-10y edge) - Atomic clock (10^-15 stability, 5-10y edge) - SQUID magnetometer (1 fT/sqrt(Hz), 15-20y if room-temp possible) - Quantum-illuminated radar (+6 dB SNR, 15-20y edge) Classical vs quantum loop primitive comparison: - Breathing rate: +-1 BPM -> +-0.1 BPM (10x) - HR rate: +-5 BPM -> +-0.5 BPM (10x) - HRV contour: NOT possible (R13) -> NV-magnetometer enables it - BP: NOT possible (R13) -> atomic-ToA PWV enables it - Position precision: 25 cm -> 3 mm (80x) - Multi-scatterer penalty: 4.7 dB -> 1 dB (3.7 dB recovery) - Through-rubble: 2 m -> 5 m+ (2.5x) WHAT R13 NEGATIVE NO LONGER RULES OUT WITH QUANTUM: R13 ruled out HRV contour + BP from CSI due to 5 dB SNR shortfall. NV-diamond cardiac magnetometry resolves this — heart magnetic fields (~50 pT) detectable, contour-preserving, penetrates clothing/rubble. The 5 dB R13 shortfall was SENSOR-BOUND, not PHYSICS-BOUND-period. Different sensor recovers it. R20 identifies this categorisation explicitly. Five-cog speculative roadmap: - cog-quantum-vitals (5y): nvsim + R14 + R15 - cog-mm-position (10y): atomic clock + R1 + R3.2 - cog-deep-rubble-survivor (15y): nvsim + R18 + drone - cog-quantum-illuminated-pose (15y): quantum illum + R6.1 - cog-ICU-meg (20y): SQUID + R14 V3 Three deployment scenarios: - Hybrid ICU bed (5y): 0/bed (4xESP32 + NV-diamond) vs ,000 monitor - Atomic-clock mm-precision multistatic (10y): high-security access - NV-drone disaster magnetometry (15y): 2.5x rubble depth over R18 Integration with existing nvsim (ADR-089): - Magnetic-field time series -> R14 V1 vitals fusion - Field map -> R12 PABS structural anomaly extension - Stability indicator -> R7 mincut additional consistency channel Future cog: cog-quantum-fusion or cog-quantum-vitals. THE CLEANEST 'LOOP IS SENSOR-AGNOSTIC' DEMONSTRATION: Even when classical CSI hits its physics floors (R13, R1 bandwidth, R6.1 penalty), the ARCHITECTURE STAYS THE SAME; only the sensor swaps. R6 forward model, R12 PABS, R7 mincut, R3 cross-room, R14 V1/V2/V3 framework — all apply to quantum sensors with parameter swaps. This is the loop's architectural value proposition in its most explicit form. Honest scope (very important): - Most quantum tech is 10-20y from edge deployment - nvsim is a SIMULATOR, not real hardware - All 'improvement' numbers are theoretical bounds; real-world 30-70% - Loop has NO real quantum sensor on bench R20 special status: - 8th exotic vertical - First requiring quantum hardware for full realisation - Most explicitly 10-20y horizon (matches cron prompt criteria) - Recovers R13 NEGATIVE via different sensing modality Composes with every loop thread + ADR-089 nvsim + ADR-113 placement. Coordination: ticks/tick-37.md, no PROGRESS.md edit. Loop summary: 18 research threads, 8 exotic verticals, 6 loop ADRs, 3 negative result categories (R13 conditionally recoverable now), production roadmap shipped. 00-summary.md to follow at 12:00 UTC stop. |
||
|
|
a0fe392f4a |
research(R19): agricultural livestock — seventh exotic vertical, first non-human-centric (#739)
Seventh exotic vertical demonstrating the loop's vertical-agnostic infrastructure. R19 is the FIRST NON-HUMAN-CENTRIC vertical. R19 composes: - R10 gait taxonomy (extended to livestock species) - R6.2.5 multi-subject union (herd density) - R12 PABS (predator detection + cattle-fall) - R14 V1 (rate-level breathing for welfare scoring) - R15 (per-animal RF fingerprint for ID without tag) Per-species gait + vital tables: | Species | Stride | Normal RR | Stress RR | | Cattle | 0.6-1.2 Hz | 10-30 BPM | >40 | | Pig | 1.0-2.0 Hz | 10-25 BPM | >35 | | Sheep | 1.5-2.5 Hz | 12-25 BPM | >30 | | Horse | 1.0-1.8 Hz | 8-16 BPM | >20 | | Chicken | 3.0-5.0 Hz | 15-40 BPM | >50 | Six-cog roadmap (0-15y): - cog-cattle-monitor (5y): R10 + R14 + R6.2.5 + R12.1 - cog-pig-welfare (5y): R6.2.5 + R14 + correlation - cog-predator-alert (5y): R12 PABS + R10 classifier - cog-lameness-detector (10y): R10 gait asymmetry + drift - cog-birthing-alert (10y): R14 V1 species signature - cog-free-range-tracker (15y): R6.2.2 sparse + Tailscale mesh High-impact use cases: - Predator detection at pasture edges: mitigates 32M/year US livestock losses (USDA 2015) - Heat-stress detection in dairy: overheated cattle drop milk production 30-50% before visual signs - Lameness early detection: dairy industry's #1 welfare issue - Sick-pig isolation alert: tail-biting cascade prevention Three scenarios: - Dairy barn (5y): 00 vs 0K visual+RFID+behaviour - Free-range pasture (10y): self-organising solar+ESP32+Tailscale - Pig barn welfare (15y): EU End-the-Cage / Prop 12 alignment What's different from human verticals: - Mass range 1.5-1000 kg (3+ orders of magnitude) - Count 1-1000+ per pen - Privacy: farmer-consent regime, not HIPAA/OSHA/GDPR - Regulatory: USDA / EU welfare instead of FDA/OSHA - Cost sensitivity: very high (2-5% margins) - Chicken-scale economically marginal Honest scope: - Synthetic data only; per-species RCS measurements needed - Chicken-scale marginal economically - High-density pig (8-100/barn) may exceed R6.2.5's 4-occupant limit - Weather effects on outdoor RF not in scope - No animal-welfare ethics review (loop specifies infrastructure) R19 special status: FIRST NON-HUMAN-CENTRIC. Privacy framework doesn't apply (animals can't consent); replaced by animal-welfare regulations. R18+R19 = two verticals needing external partnerships (FEMA, USDA). Seven exotic verticals now: 1. R10 wildlife 2. R11 maritime 3. R14 empathic appliances (home) 4. R16 healthcare 5. R17 industrial 6. R18 disaster (integrates MAT crate) 7. R19 livestock (first non-human-centric) Composes with every loop thread (R1, R3, R5, R6/R6.1, R6.2.5, R7, R10, R12/R12.1, R13 NEG, R14, R15) + ADR-113 + ADR-105-109. Coordination: ticks/tick-36.md, no PROGRESS.md edit. |
||
|
|
ab80280f93 |
research: production roadmap synthesis — every loop output mapped to owner/LOC/priority (#738)
Terminal output of the SOTA research loop. Maps every research finding
to owner, LOC estimate, dependency, and priority across 6 tiers.
Total engineering budget across the loop's output:
- Tier 1 (Q3 2026): ~490 LOC, 3-4 person-weeks
- Tier 2 (Q3-Q4 2026): ~1180 LOC, 6-8 person-weeks
- Tier 3 (2027): ~1140 LOC, 8-10 person-weeks
- Tier 4-5 (long horizon): ~700+ LOC, 6-8 person-weeks
- TOTAL: ~3,500 LOC, ~25 person-weeks
Tier 1 (next quarter) ships:
- 1.1 wifi-densepose plan-antennas CLI tool (360 LOC) -- 93x placement lift
- 1.2 R12.1 pose-PABS in vital_signs cog (80 LOC) -- 9.36x intruder lift
- 1.3 cog-person-count v0.0.3 chest-centric (50 LOC)
- 1.4 ADR-029 amendment w/ ADR-113 matrix (0 LOC)
Critical-path graph:
1.1 + 1.2 -> 1.3 -> 2.1 ruview-fed -> 2.2 DP-vital-signs -> 3.1 cross-install -> 3.2 PQC
+-> 3.3 real-AETHER -> 3.4 fall-detect
+-> 4.x verticals
Why this matters: after 35 ticks of research output, this is the
document that lets a team pick up and ship without re-reading the 34
research notes. Priority alignment, estimate-anchoring, critical-path
visibility — all in one place.
R-thread mapping:
- R5/R6/R6.2 family/R6.1 -> Tier 1
- R12/R12.1 PABS -> Tier 1.2
- R3/R3.1/R3.2/R14/R15 -> Tier 2-3
- R7 mincut -> Tier 2 (in ruview-fed)
- R13 NEGATIVE -> rules out BP, no Tier line
- R10/R11/R16/R17/R18 verticals -> Tier 4-5
Composes with every loop output. Every thread, ADR, vertical sketch
has a line in some Tier. The TERMINAL output that needs the synthesis
power of a research loop to produce.
Honest scope:
- Estimates synthetic-data-based; may shift after bench validation
- Critical-path may have hidden dependencies (e.g. AgentDB schema)
- 25 person-weeks assumes full-time engineers
- Doesn't include integration testing, documentation, deployment ops
- Tiers based on architectural dependency, not business priority
Loop status after 35 ticks:
- 16 research threads
- 6 exotic verticals
- 6 new ADRs (105/106/107/108/109/113)
- 3 negative result categories
- 2 self-corrections
- 3 honest-scope findings
- 9-tick R6 family (complete)
- 3-tick R3 arc (complete)
- 3-tick R12 arc (complete)
- This production roadmap
00-summary.md will follow at 12:00 UTC / 08:00 ET cron stop.
Coordination: ticks/tick-35.md, no PROGRESS.md edit.
|
||
|
|
472774d3f8 |
research(R18): disaster response — first vertical integrating with existing repo crate (wifi-densepose-mat) (#737)
Third 'vertical demonstrates loop generality' tick. First vertical to integrate with an existing repo crate (wifi-densepose-mat), making loop-to-production path most direct. Headline: rubble is RF-leaky, not RF-opaque - Steel (1mm): 2,674 dB (opaque) - Mixed rubble 1-2m: 40-80 dB - Brick 10cm: 8-12 dB - Concrete 10cm: 20-30 dB - Drywall 1.5cm: 1-2 dB ESP32-S3 121 dB link budget gives 40-80 dB margin through typical rubble. Survivors at 1m depth: +37 dB (feasible), 2m: +7 dB (marginal), 3m: infeasible. Dramatically better than R11 maritime through-bulkhead case. Loop primitives -> MAT crate enhancements: - R12.1 pose-PABS: 9.36x fewer false alarms - R6.2.5: multi-survivor union (bounded ~4) - R1 CRLB: ~25 cm position precision - R14 V1 + R15: rate-level vitals confirmation - R3 + AETHER: survivor-vs-rescuer disambiguation - R7 mincut: BINDING at disaster sites - ADR-109 Dilithium: audit trail integrity Six-cog roadmap: - cog-mat-survivor-detect (NOW): wifi-densepose-mat baseline - cog-mat-pose-pabs (5y): + R12.1 - cog-mat-multi-survivor (5y): + R6.2.5 - cog-mat-vitals-confirm (5y): + R14 V1 + R15 - cog-mat-survivor-vs-rescuer (10y): + R3 + library - cog-mat-cross-deploy-fed (15y): + ADR-105-108 consent-bounded Three deployment scenarios: - Rapid response 5y: 00/survey unit, FEMA model - Pre-staged at seismic sites 10y: auto-activate on tremor - Cross-disaster fed 15y: consent-bounded across sites Vertical comparison (5 verticals now): - R18 disaster: rubble 40-80 dB, trapped, R7 binding, existing crate - R16 healthcare: air, stationary patients, R7 nice-to-have - R17 industrial: air, mobile workers, R7 binding Three of three target verticals (clinical/industrial/disaster) work with same architecture. Strong evidence loop is vertical-agnostic. Honest scope: - No bench-validated disaster-site data (ethics: can't simulate) - R7 mincut hostile-RF requirement - Cross-disaster fed has consent questions - Time-pressure tuning aggressive toward false-positive - MAT crate API doesn't yet consume R6.1 multi-scatterer - Steel-rubble (basement w/ rebar) impossible per R11 - Underwater impossible per R11 saltwater Composes with every loop thread (R1, R6/R6.1, R6.2.2/.5, R7, R10, R11, R12/R12.1, R13 NEG, R14, R15, R3) + all ADRs (105-109, 113) + R16/R17 parallel patterns. R18 special status: FIRST VERTICAL to integrate with existing repo crate. Loop-to-production path is shortest because production code exists; loop primitives enhance rather than replace. Coordination: ticks/tick-34.md, no PROGRESS.md edit. Loop now has 6 exotic verticals: 1. R10 wildlife 2. R11 maritime 3. R14 empathic appliances (home) 4. R16 healthcare 5. R17 industrial 6. R18 disaster (first to integrate with existing crate) |
||
|
|
8213741879 |
research(R17): industrial safety — second vertical composing loop primitives (#736)
Second exotic vertical demonstrating loop primitives compose to industrial safety. Parallel to R16 healthcare with different ADR-113 matrix rows (presence + vital-signs at coarser resolution) and R7 mincut becomes BINDING (not nice-to-have) due to hostile industrial RF environment. Three deployment scenarios: - Warehouse zone (5y): 0/zone vs 00-2000 camera+monitoring - Construction site (10y): per-project federation - Refinery/chemical plant (15y): adds CSI to gas+cam+badge infrastructure R17 vs R16 parallel: - R16: stationary patients, 30 m^2 ward, vital-signs row (chest, N=5), HIPAA - R17: mobile workers, 100-1000 m^2 zone, presence row (body, N=3-4), OSHA SAME ARCHITECTURE, different parameter regime. Five specialised cog roadmap items: - cog-fall-detection (5y): R12.1 + PPE-tuning - cog-zone-occupancy (5y): R12 PABS + R6.2.5 - cog-lone-worker-vitals (5y): R14 V1 rate-only - cog-worker-fatigue (10y): R10 gait + R15 - cog-multi-zone-orchestrator (5y): R6.2.5 + ADR-105 fed Why R7 mincut becomes binding: industrial RF has legitimate noise (cell, BLE tools, walkie-talkies) that must be disambiguated from sensor compromise. N >= 4 anchors required (already met by ADR-113 for multi-feature cogs). PPE-specific body model needed (R6.1 follow-up): Hard hat / high-vis / harness / tool belt / steel-toed boots change per-part reflectivity by ~5-15%. ~1-2 weeks labelled-data work for cog-industrial-pose. R10 gait taxonomy extends within humans: - Walking: 1.2-2.5 Hz - Fatigued: 0.8-1.5 Hz (slower + asymmetric) - Impaired: asymmetry > 25% OSHA-aligned pre-incident fatigue detection. Honest scope: - Synthetic data only; bench validation required for OSHA-grade - PPE-specific body model unbuilt - Outdoor/weather effects partly transfer from R10 - Worker consent + audit trail integration per-customer R17 closes parallel-vertical demonstration: loop has now shown VERTICAL-AGNOSTIC INFRASTRUCTURE: 1. R10 wildlife 2. R11 maritime 3. R14 empathic appliances (home) 4. R16 healthcare 5. R17 industrial safety Five exotic verticals + cross-thread identity work. Outputs that generalise beyond original problems = mark of well-factored research. Composes: - R1, R5, R6/R6.1, R6.2.5, R7 (binding here), R10, R12/R12.1, R13 NEG, R14, R15 — all loop threads - ADR-113 placement + ADR-105-109 privacy/PQC chain - R16 parallel pattern Coordination: ticks/tick-33.md, no PROGRESS.md edit. |
||
|
|
675233630d |
research(R16): healthcare ward monitoring — composes loop primitives, no new research (#735)
New exotic vertical (10-20y horizon) demonstrating the loop's 9-ADR + 13-thread output is sufficient to specify a complete clinical- deployment system. All required primitives exist; the gap is bench validation + BAA + regulatory pathway. Three deployment scenarios: - ICU bedside (5y): 0/bed vs ,000 hospital-grade monitor - General ward 8-bed (10y): 20/ward vs 00K/year staffing - At-home post-discharge (15y): empathic-appliance V1/V2/V3 + telemedicine Healthcare requirement -> loop primitive mapping: - Vitals: R14 V1 + R15 (rate-level only per R13 NEGATIVE) - Patient ID per bed: R3 + AETHER - Fall detection: R12.1 pose-PABS closed loop - Intruder detection: R12 PABS multi-subject - Multi-bed coverage: R6.2.5 + ADR-113 placement matrix - HIPAA privacy: ADR-106 medical-grade (epsilon=2) - Audit trail: ADR-109 Dilithium-signed - Cross-hospital fleet: ADR-107+108 quantum-resistant Two gaps blocking deployment (both solvable, neither new research): 1. Bench validation on real patient data (6-12 months) 2. BAA infrastructure with hospital partner (operational) What R13 NEGATIVE rules out: - Blood pressure cog -> keep arm cuff - HRV contour -> keep PPG wearable for ICU What R12.1 + R6.2.5 enables: - Fall detection at 9.36x lift - 100% coverage for 4-occupant rooms - Per-bed identity preservation Six cog roadmap items: - cog-vital-signs (5y): R14 V1 + R15 - cog-fall-detection (5y): R12.1 - cog-bed-occupancy (5y): R12 PABS + R6.2.5 - cog-respiratory-anomaly (10y): temporal R15 breathing - cog-post-discharge (15y): V1/V2/V3 + telemedicine - cog-elderly-care (20y): R10 gait + R15 limb-timing Honest scope: - Synthetic data only; bench validation pending - 8-bed wards may exceed R6.2.5's 4-occupant tested limit - Hospital RF environment harsh - Clinical workflow integration is substantial engineering - FDA/CE regulatory pathway is 6-18 months and 500K-2M per device class Why R16 matters: it confirms the loop's output is ARCHITECTURALLY COMPLETE for clinical deployment. Same primitives that ship empathic appliances ship healthcare. Composition, not research, is the remaining work. Composes with every loop thread (R1, R5, R6, R6.1, R6.2.5, R7, R10, R11, R12, R12.1, R13, R14, R15, R3 + all ADRs 105-109+113). Loop now has 5 exotic vertical sketches: wildlife (R10) / maritime (R11) / empathic appliances (R14) / healthcare (R16) + cross-thread identity/security work. Coordination: ticks/tick-32.md, no PROGRESS.md edit. |
||
|
|
e4f93b1617 |
adr-113: multistatic placement strategy — consolidates 9-tick R6 family into decision matrix (#734)
Amends ADR-029 (RuvSense multistatic). Consolidates the SOTA research
loop's 9-tick R6 family into a single 4-axis decision matrix
(dimension x zone-mode x occupants x cog).
Decision matrix highlights:
- 2D vital-signs cogs: chest-centric, N=5, walls 0.8/1.5 m -> 100%
- 3D vital-signs cogs: chest-centric, N=6, NO ceiling -> 82%
- 2D pose cogs: body, N=5, walls mixed -> 97%
- 3D pose cogs: body, N=7-8, mixed L/M/H -> 65%+
- Person count: body, N=4, walls mixed -> 86%
- Presence only: body, N=3, walls low -> 63%
- Maritime cabin: chest, N=4, low -> 80%+
- Wildlife corridor: linear, N=4, tree-mount -> 70%+
Seven binding rules extracted from R6 family:
1. Ceiling-only mounting fails (R6.2.1)
2. Vertical link diversity wins in 3D (R6.2.1)
3. Anchor heights match target zone heights (R6.2.4)
4. Chest-centric beats body for vital signs (R6.2.3)
5. Multi-subject union is the right target (R6.2.5)
6. N=5 is the consumer recommendation (R6.2.2 + R6.2.5)
7. Avoid placing target zones on LOS line (R6.1)
CLI productisation:
wifi-densepose plan-antennas
--room W H [Z] --target ... --target-mode {body,chest}
--freq-ghz F --n-anchors N --cog NAME
MCP tool:
ruview_placement_recommend(room, targets, cog)
-> {anchors, coverage, rationale}
~360 LOC total for placement-strategy productisation.
Per-cog auto-config (the --cog flag looks up):
- cog-presence: body, 3
- cog-person-count: body, 4
- cog-pose-estimation: body, 5 (2D) / 7 (3D)
- cog-vital-signs / breathing / heart-rate: CHEST, 5/6
- cog-intruder: body, 5
- cog-maritime-watch: chest, 4
- cog-wildlife: linear, 4
The R6 family produced 9 ticks of physics + simulation, each adding
1-2 axes to the placement question. ADR-113 collapses all 9 into a
single decision matrix that a non-physicist installer can use.
Composes:
- R6.2 family (9 ticks) all feed this ADR
- R7 mincut: N >= 4 satisfied for all multi-feature cogs
- R10/R11 wildlife/maritime entries in matrix
- R12 PABS/R12.1: placement coverage = intrusion-detection sensitivity
- R14 V1/V2/V3 all covered
- ADR-029 directly amended
Honest scope:
- Synthetic physics; bench validation pending
- Single room geometry baseline (5x5 + 4x6 m)
- 5 cm pose-tracker noise assumed
- Free-space, no multipath/furniture occlusion
- Greedy + 4-restart search
ADR chain after this tick (loop's 6 new ADRs + 3 existing):
105/106/107/108/109/113 + 100/103/104 = 9 ADRs in the full chain
(privacy + federation + provenance + placement).
Coordination: ticks/tick-31.md, no PROGRESS.md edit.
|
||
|
|
27d911ca6d |
adr-109: Dilithium PQC signatures — provenance side of post-quantum migration (#733)
Sister-ADR to ADR-108. Where ADR-108 closes the confidentiality side (Kyber key exchange), ADR-109 closes the integrity side (Dilithium signatures) of the post-quantum migration. Replaces Ed25519 in ADR-100 cog signing with Dilithium-3 (NIST FIPS 204, ~AES-192 equivalent, CNSA 2.0 default). Migration timeline (matches ADR-108): - Phase 0 (NOW 2026): Ed25519 only - Phase 1 (Q4 2026): Dual-sig (Ed25519 + Dilithium-3), accepts either - Phase 2 (Q2 2027): BOTH required (defence in depth) - Phase 3 (2030+): Pure Dilithium-3 Why now (backdating argument): An adversary who can break Ed25519 in 2035 with quantum computers can backdate signatures on cog binaries to install malicious code retroactively. The provenance chain breaks even for binaries deployed today. Hybrid mode prevents this: forging a 2026 cog signature still requires breaking BOTH Ed25519 AND Dilithium-3. Manifest size: 64 B (Ed25519) + 3293 B (Dilithium-3) = ~4 kB per cog. 50-cog catalogue overhead ~200 kB. Negligible. LOC: +270 on top of ADR-100. Combined chain budget (ADR-105+106+107+108+109): ~1,820 LOC, ~7 weeks. ADR CHAIN (8 ADRs) complete for both confidentiality and integrity at quantum-resistant tier: - ADR-100: cog packaging - ADR-103: cog-person-count - ADR-104: MCP + CLI - ADR-105: within-installation federation - ADR-106: DP-SGD + primitive isolation - ADR-107: cross-installation + secure aggregation - ADR-108: PQC key exchange (Kyber-768) - ADR-109: PQC signatures (Dilithium-3) <-- THIS Future ADRs catalogued: - ADR-110: PQC hardware acceleration on Cognitum-v0 - ADR-111: Owner key rotation policy - ADR-112: Cross-signing with external CA - ADR-113: Multistatic placement strategy (R6 family findings -> ADR-029 amendment) Composes: - R14/R15 privacy + biometric requires provenance integrity - R12 PABS / R12.1: intruder-detection cog must itself be signed - R10/R11 long-deployment cogs most affected by backdating - R7 mincut adversarial assumes the model is trustworthy Honest scope: - Dilithium ~5 years old; hybrid mitigates uncertainty - ESP32-S3 verification ~5-10 ms estimated; needs benchmarking - pqcrypto-dilithium Rust crate dependency - Owner key management = highest-risk operational change - Phase 3 Ed25519 retirement needs future decision Coordination: ticks/tick-30.md, no PROGRESS.md edit. |
||
|
|
50a7c4a645 |
research(R12.1): pose-PABS closed loop — 9.36x intruder lift; R12 arc fully closed (#732)
Closes the deferred item from R12 PABS (tick 19): 'real production
needs pose-aware forward model updating in real-time'. R12.1 implements
the closed loop in synthetic form.
Method: 50-frame walking subject + intruder entering at T=25. Compare
two PABS pipelines:
(a) Fixed-expected (R12 PABS naive)
(b) Pose-updated (R12.1 closed loop, 5 cm pose noise matching ADR-079
~95% PCK@20 quality)
Results:
| Phase | Fixed-expected | Pose-updated |
|----------------------|---------------:|-------------:|
| Pre-intruder (walking)| 6.02 | 0.30 |
| Post-intruder | 7.76 | 2.84 |
| Intruder lift | 1.29x | 9.36x |
Pose updates suppress subject-motion noise by 20x (6.02 -> 0.30),
leaving the intruder as a clean 9.36x spike. False-alarm problem
from R12 PABS RESOLVED.
R12 thread fully closed (3 ticks):
- R12 (tick 5): NEGATIVE SVD eigenshift 0.69x signal/drift
- R12 PABS (19): POSITIVE 1161x intruder detection (static)
- R12.1 (this): CLOSED 9.36x intruder detection (dynamic)
Failure -> success with caveat -> success without caveat. The
multi-tick arc that justifies a long research loop.
Production roadmap (~80 LOC + 30 LOC plumbing):
let pose = pose_tracker.estimate(csi_window)?;
let expected_scene = body_model.from_pose(pose) + room_walls;
let y_predicted = fresnel_forward.simulate(expected_scene);
let pabs = (csi_window - y_predicted).norm_sq() / csi_window.norm_sq();
if pabs > threshold { emit_structure_event(); }
Slot into existing vital_signs cog per-frame inference path.
Composes:
- R6.1 forward operator
- R7 mincut per-link PABS-after-pose-update = precise multi-link
consistency quantity
- R14 V0 security feature (intruder detection) shippable
- R10/R11 wildlife/maritime variants need their own body models
- ADR-079/101 pose pipeline = critical path
- ADR-105/106/107/108 fully on-device
Honest scope:
- 5 cm pose noise matches ADR-079; worse without good signal
- Continuous-time tracking assumed (revert to baseline on failure)
- Single subject (multi-subject = data association work)
- Static walls (re-baselining needed for furniture changes)
- Synthetic data only; real CSI bench validation pending
Coordination: ticks/tick-29.md, no PROGRESS.md edit.
After this tick, all research-loop work substantively complete:
- 13 research threads (R1, R3, R5-R15)
- 4 ADRs in privacy chain (105, 106, 107, 108)
- 3 negative-result categories
- 2 explicit self-corrections
- 3 honest-scope findings
- 9-tick R6 placement family
- 3-tick R3 cross-room re-ID arc
- 3-tick R12 structure detection arc
|
||
|
|
40e5a4d6f2 |
adr-108: Kyber post-quantum key exchange for cross-installation federation (#731)
Closes the quantum-resistance gap explicitly deferred from ADR-107. Final ADR in the privacy + federation chain. Replaces DH key exchange in ADR-107's Layer 4 secure aggregation with Kyber-768 KEM (NIST FIPS 203, CNSA 2.0 default). Migration timeline: - Phase 0 (NOW 2026): Classical X25519 (ADR-107 default) - Phase 1 (2026-Q4 -> 2027): Kyber-768 opt-in via --enable-pqc flag - Phase 2 (2027-Q2 -> 2028): Hybrid (X25519 + Kyber-768) becomes default - Phase 3 (2030+): Pure Kyber-768 (classical retired) Why hybrid for Phase 2 (belt-and-braces): - Protects against future Kyber breaks (Kyber is ~5 years old) - Protects against classical breaks (X25519 backup) - Protects against implementation bugs in either primitive - Cost: ~3 kB/round/installation extra (negligible) Why now (record-now-decrypt-later): Adversaries can record federated updates today and decrypt them in 2035 when quantum capabilities arrive. Without ADR-108, the (epsilon, delta) guarantees of ADR-106 silently expire when quantum computers arrive. Proactive migration is cheap insurance. Why Kyber-768 (not 512 or 1024): - NIST FIPS 203 (2024); ~AES-192 equivalent - CNSA 2.0 recommended default - Used by Cloudflare, Google, AWS in 2024-2026 rollouts - Public key 1184 B, ciphertext 1088 B, secret 32 B - 512 lacks CNSA 2.0 sign-off; 1024 doubles bandwidth without benefit LOC: +220 on top of ADR-107. Total federation budget ADR-105+106+107+108: ~1,550 LOC. Threat model: 8 threats, every row has mitigation. Hybrid mode is the belt-and-braces against both Kyber breaks AND classical breaks. ADR CHAIN COMPLETE: 7 ADRs in the privacy + federation chain: ADR-100 (cog packaging) -> ADR-103 (cog example) -> ADR-104 (MCP/CLI) -> ADR-105 (within-installation federation) -> ADR-106 (DP + isolation) -> ADR-107 (cross-installation + SA) -> ADR-108 (PQC key exchange). No remaining unspecified privacy gap at any threat horizon (classical or quantum). Future ADRs catalogued: - ADR-109: PQC signatures (Dilithium replaces Ed25519 in ADR-100) - ADR-110: PQC hardware acceleration on Cognitum-v0 - ADR-111: PQC for cog-store distribution Composes: - R3 / R14 / R15 / R7 / R12 PABS: privacy chain intact through quantum transition - R10 / R11 (long-deployment): benefit most from forward secrecy as data ages Honest scope: - Kyber ~5 years old; hybrid mitigates uncertainty - 'When do we need this?' uncertain (2030 aggressive / 2050+ conservative) - ESP32-S3 timing ~10 ms per handshake estimated negligible; needs measurement - Phase 3 retirement of classical needs future decision Coordination: ticks/tick-28.md, no PROGRESS.md edit. |
||
|
|
4e6ef76294 |
research(R6.2.5): multi-subject occupancy union — N=5 hits 100% for 4 occupants; R6 family complete (#730)
Extends R6.2.3 chest-centric placement to union of chest envelopes
across multiple occupants. Practical question: does coverage degrade
gracefully as occupant count grows?
Result: 2D chest-centric + N=5 + multi-subject union = 100% coverage
for households of 1-4 occupants. N=4 knee returns.
| Scenario | # zones | Cov @ N=5 |
|------------|--------:|----------:|
| 1 occupant | 1 | 100% |
| 2 occupants| 2 | 100% |
| 3 occupants| 3 | 100% |
| 4 occupants| 4 | 100% |
4-occupant saturation: N=4 = 99.0% (+26.1 pp marginal), N=5 = 100%,
N=6+ saturated. Knee at N=4 even for 4 occupants.
Cross-eval: single-subject placement gets 70.6% on 4 zones; multi-
subject-optimised gets 100%. +29.4 pp gain from multi-subject
optimisation. CLI MUST accept multiple --target args and compute union.
Why N=4 knee returns: each chest zone is 40x40 cm, fits inside one
Fresnel ellipsoid (~40 cm wide at midpoint of 5 m link). N=4 anchors
give 6 pairwise links, enough to cover 4 disjoint chest zones without
much waste. Chest-centric multi-subject is the SWEET SPOT for Fresnel
envelope geometry.
R6 family complete (9 ticks: R6, R6.1, R6.2, R6.2.1, R6.2.2, R6.2.2.1,
R6.2.3, R6.2.4, R6.2.5). Family's ship recipe:
- 2D chest-centric + multi-subject + N=5 = 100% coverage
Productisation CLI spec (50 LOC over original R6.2):
wifi-densepose plan-antennas
--room W H [Z] # 2D or 3D
--target NAME X Y W H [DX DY DZ] # repeatable
--target-mode {body, chest} # R6.2.3
--freq-ghz F
--n-anchors N # auto-saturation if omitted
--restarts K
Honest scope: 2D only (3D multi-subject = mechanical extension), static
positions, single 5x5 m geometry, greedy with 4 restarts, 4 occupants
max tested.
Composes:
- R6.2 / R6.2.3 direct extension (single -> multi)
- R6.2.2 / R6.2.4 same saturation behaviour
- R14 V1/V2/V3 in households of 2-4 use this recipe
- R3 / ADR-024 per-subject identity + multi-subject placement
- ADR-105/106/107 federation orthogonal
- R12 PABS multi-subject coverage = multi-subject intrusion detection
Coordination: ticks/tick-27.md, no PROGRESS.md edit.
|
||
|
|
4183ef651f |
research(R3.2): embedding-level physics-informed env — structural validation + AETHER dependency (#729)
Implements R3.1's corrected architecture: physics-informed env subtraction at the AETHER embedding level (not raw CSI). Tests whether moving the operation closes the cross-room gap that R3.1 NEGATIVE surfaced. Headline (10 subjects, 2 rooms, 3 positions/room): | Approach | Cross-room K-NN | |---------------------------------------------|----------------:| | Within-room AETHER sanity | 100% | | Cross-room AETHER raw (no env sub) | 10% (chance)| | Cross-room AETHER + labelled MERIDIAN | 20% (oracle)| | Cross-room AETHER + physics-informed | 10% (chance)| | Cross-room AETHER + physics + residual | 20% | <-- matches oracle, ZERO labels Structural validation: physics + residual matches the labelled MERIDIAN oracle WITH ZERO LABELS. The architecturally-correct approach works. But neither approach reaches 80%+. Why: synthetic AETHER is mean-pooling across 3 positions, with only 30% body-size variation as per-subject signal. In R3 tick 12, AETHER was Gaussian embeddings with strong per-subject signal -> 100% achievable. Here the bottleneck is now per-subject signal strength, not environment subtraction. R3.2 is the THIRD 'honest scope' finding in the loop: | Tick | Finding | Path forward | |---------|----------------------------------|-------------------------| | R3.1 | physics-informed at raw fails | embedding level (R3.2) | | R6.2.2.1| 2D N=5 knee doesn't hold in 3D | chest zones (R6.2.4) | | R3.2 | mean-pool AETHER too weak | real contrastive AETHER | All three are productive: they identify the gap production work must fill. R3.2 confirms ADR-024 (AETHER) is on the critical path for cross-room re-ID. Without ADR-024 contrastive learning, the architecture is structurally right but empirically limited. Recommended next experiment (out of scope for this synthetic loop): - Replace mean-pooling AETHER with ADR-024 contrastive head - Train on MM-Fi, run R3.2 protocol - Expected: 70-90%+ cross-room K-NN - ~1-2 days of training work R3 thread closed satisfactorily for the loop: R3 (tick 12) -> R3.1 NEGATIVE -> R3.2 STRUCTURALLY VALIDATED. Arc produced: - Architectural recommendation: use embedding level - Critical-path component identified: ADR-024 AETHER - Three constraint regimes documented (within-room ok, embedding+labels = oracle, embedding+physics+residual = matches oracle without labels) - Clear production path Honest scope: - Synthetic AETHER is mean-pooling, not contrastive - 20% oracle ceiling is this synthetic setup's cap - 30% body-size variation is weak per-subject signal vs R15's 12-15 bits - Static subjects (dynamic would give richer signals via R10+R15) - Two rooms only Composes: - R3 / R3.1 / R3.2 = full arc - R6 / R6.1 forward operator unchanged - R6.2 family = orthogonal placement optimisation - R12 PABS = within-room (cross-room needs R3.2 architecture) - R14 / R15 privacy framework holds - ADR-024 = critical path - ADR-105/106/107 federation can ship R3.2 outputs Coordination: ticks/tick-26.md, no PROGRESS.md edit. |
||
|
|
2e89fe61ef |
research(R6.2.4): 3D chest-centric N-anchor — validates R6.2.2.1 prediction with refinement (#728)
Composes R6.2.2.1 (3D N-anchor) with R6.2.3 (chest-centric zones).
Tests R6.2.2.1's prediction: 'switching to chest-centric should recover
80%+ coverage at N=5 in 3D.'
Result: 3D chest-centric N=5 = 76.8% (close to but below 80%);
3D chest-centric N=6 = 81.6% (knee shifts one anchor higher).
4-way comparison at N=5:
- R6.2.2 (2D body): 96.8%
- R6.2.3 (2D chest): 82.4%
- R6.2.2.1 (3D body): 49.4%
- R6.2.4 (3D chest): 76.8%
3D chest recovers 27 pp of the 47 pp gap R6.2.2.1 surfaced. Most of
the architectural fix works.
COUNTER-FINDING: no ceiling anchors selected for chest-centric zones.
Greedy picks 100% low (0.8 m) + mid (1.5 m). R6.2.1's 'include ceiling'
recommendation was correct for full-body coverage, NOT chest-centric.
Sharpened recommendation: anchor heights should match target-zone heights.
- Bed-only (z=0.3-0.6): Low only
- Chair sitting (z=0.5-1.0): Low + mid
- Standing chest (z=1.2-1.5): Mid only
- Mixed chest (z=0.3-1.5): Low + mid (NO ceiling)
- Full body (z=0.3-1.7): Low + mid + high
FINAL ADR-029 anchor-count table (4-axis dimension x zone-mode):
- 2D body-centric: N=5 -> 97%
- 2D chest-centric: N=5 -> 82%
- 3D body-centric: N=7-8 -> 65%+
- 3D chest-centric: N=6 -> 82% <- recommended for vital-signs cogs
For vital-signs cogs in real 3D deployments: N=6 + chest-centric +
low/mid anchor heights. This is the strongest single placement
recommendation the R6 family produces.
R6 family substantively complete after this tick (8 ticks total):
R6, R6.1, R6.2, R6.2.1, R6.2.2, R6.2.2.1, R6.2.3, R6.2.4.
Second self-corrective tick of the loop: R6.2.2.1 predicted 80%; actual
is 76.8%. Self-correction documented (prediction was 3.2 pp optimistic,
knee shifts to N=6). Integrity pattern continues.
Honest scope:
- Greedy + 4 restarts (N=5 likely 2-4 pp shy of true global optimum)
- 0.1 m grid, single 5x5x2.5 geometry
- Three chest zones; multi-subject = future
- R6.2.1's ceiling rec was for full-body, not invalidated -- refined
Composes:
- R6.2.1 / R6.2.2 / R6.2.2.1 (same physics, different zones)
- R6.2.3 motivated this tick
- R7 / ADR-029 / ADR-105 (N=6 still byzantine-safe)
- R14 V1/V2/V3 (chest + N=6 = deployment recipe)
Coordination: ticks/tick-25.md, no PROGRESS.md edit.
|
||
|
|
df13dcf597 |
research(R6.2.2.1): 3D N-anchor multistatic — 2D knee disappears; revises R6.2.2 down (#727)
Composes R6.2.2 (2D N-anchor knee at N=5) with R6.2.1 (3D ellipsoids, ceiling-only fails). The composed 3D result shows the 2D-derived knee DOES NOT hold in 3D. 3D saturation curve (5x5x2.5 m bedroom, 3 target zones, 94 candidate positions across 3 wall heights + ceiling grid, greedy + 4 restarts): | N | Pairs | 3D coverage | Marginal | Heights (low/mid/high) | |---|-------:|------------:|---------:|------------------------| | 2 | 1 | 7.7% | +7.7 pp | 1/1/0 | | 3 | 3 | 28.1% | +20.4 pp | 1/2/0 | | 4 | 6 | 40.6% | +12.5 pp | 3/0/1 | | 5 | 10 | 49.4% | +8.8 pp | 4/0/1 | | 6 | 15 | 59.1% | +9.8 pp | 4/1/1 | | 7 | 21 | 65.1% | +6.0 pp | 5/1/1 | Comparison vs R6.2.2 2D: - 2D N=5 = 96.8% (clean knee) - 3D N=5 = 49.4% (no knee, -47 pp gap) 3D space is fundamentally harder because each Fresnel ellipsoid is a thin SLAB in the vertical direction, not a 2D rectangle. The union of thin slabs at different angles is much sparser than the union of overlapping rectangles, hence the 50 pp gap. Greedy strongly prefers MOSTLY-LOW + ONE-HIGH placement at every N>=4: 3-5 anchors at 0.8m + 0-1 at 1.5m + 1 ceiling. Confirms R6.2.1's diagonal-in-z winning strategy. ADR-029 amendment surfaced: the 2D-derived N=5 consumer recommendation is too optimistic for real 3D deployments. Two responses: 1. Bump N to 7-8 for 65%+ 3D coverage 2. Use chest-centric zones (R6.2.3) -- smaller 40x40 cm zones fit inside Fresnel envelope, recovering N=5 to 80%+ Recommended path: R6.2.3 + R6.2.2 N=5 = realistic 80%+ 3D coverage at ADR-029 default N. Architectural lever that aligns 2D and 3D physics. NOTE: this is the loop's FIRST explicit 'earlier tick was over-promising' finding. Previous 23 ticks built constructively. R6.2.2.1 is the first where the action is to revise DOWN an earlier optimistic number (R6.2.2's 97% becomes 49% in honest 3D). Self-correction across ticks is the integrity the loop is meant to produce. Composes with: - R6.2 / R6.2.1 / R6.2.2: natural composition - R6.2.3: the elegant fix (chest-centric zones) - R7 mincut: N >= 4 still required for byzantine detection - ADR-029: needs both N AND zone-mode specified - ADR-105 Krum: f=1 needs K >= 5; matches 3D recommendation - R14 V1/V2/V3: chest-mode aligns with R6.2.3 = tractable 3D Honest scope: greedy approximate, 0.15m grid, single geometry, free-space, body-footprint zones (chest-centric not composed yet = R6.2.4 follow-up). Coordination: ticks/tick-24.md, no PROGRESS.md edit. |
||
|
|
8b850d8b2a |
research(R6.2.3): chest-centric placement — +26.9 pp coverage gain for vital-signs cogs (#726)
Direct follow-up from R6.1 (chest contributes 27.6% of CSI energy, 5x per-limb value, limbs are confound not signal). R6.2.3 re-runs R6.2's placement search with chest-only target zones (40x40 cm patches at expected chest positions) vs body-footprint zones (R6.2's default full-area definition). Headline result: | Configuration | Coverage | Placement | |----------------------------|---------:|----------------------------| | Body-centric (R6.2 default)| 49.3% | (4.25,0)-(0,3.25), 5.35 m | | CHEST-CENTRIC (R6.2.3 new) | 82.4% | (2.0,0)-(4.5,5), 5.59 m | Cross-eval: - Body-optimal on chest zones: 55.5% - Chest-targeting GAIN on chest: +26.9 pp - Chest-optimal on body zones: 40.3% (-9.0 pp loss) The two strategies are genuinely different. Same engine, different zones. Per-cog deployment recommendation surfaced: - --target-mode=body (default): cog-person-count, cog-pose, cog-presence - --target-mode=chest (new): cog-vital-signs, cog-breathing, cog-HR - --target-mode=extremity (future): gesture detection ~20 LOC change to R6.2 CLI. R14 vertical-specific: - V1 stress-responsive lighting: chest mode - V2 adaptive HVAC (presence+breathing): mixed - V3 attention-respecting conversation: chest mode R6.2.3 surfaces a per-cog config that empathic-appliance products need at install time. Why placements differ: when target ~ envelope width, envelope can cover it entirely; when target >> envelope, placement must compromise. 40 cm Fresnel envelope @ 5 m link comfortably covers 40 cm chest patches but must spread to cover 3 m^2 bed. Composes: - R6.1 motivated this tick - R6.2 / R6.2.1 / R6.2.2 -- orthogonal extensions - R14 V1/V3 should use chest mode - R12 PABS improves body-position-detection scenarios Honest scope: - Chest positions approximated - 2D still (3D chest-centric = R6.2.3.1 follow-up) - Single subject (multi-subject = union of chest envelopes) - Per-cog zone schema is deployment-time Coordination: ticks/tick-23.md, no PROGRESS.md edit. |
||
|
|
9b5e317f99 |
adr-107: cross-installation federation with secure aggregation — privacy chain closes (#725)
Closes the cross-installation federation work explicitly deferred from ADR-105 + ADR-106. Direct extension of both. Five-layer defence (extends ADR-106's three): 1-3 (ADR-106): Primitive isolation + grad clipping + DP noise 4 NEW: Secure Aggregation (Bonawitz 2016) -- aggregator sees only sum 5 NEW: Per-installation embedding-space rotation key -- cross-install re-ID prevented Counter-intuitive privacy win: cross-installation amplification IMPROVES privacy. With N=10 installations each at sigma_local=1.0: - Per-installation epsilon (50 rounds): 2.5 - Cross-installation effective sigma = sqrt(N) * sigma_local = 3.16 - Cross-installation epsilon (50 rounds): ~1.5 <-- STRONGER Cross-installation federation actually improves privacy through the amplification effect, as long as the crypto protocol is implemented correctly. Bandwidth: ~2 MB/install/round, monthly ~70-200 MB/install (within+cross). <0.1% of typical home broadband. Implementation budget: - ADR-105 baseline: 500 LOC - ADR-106 layers: +300 LOC - ADR-107 SA layer: +530 LOC - TOTAL ruview-fed: ~1,330 LOC, ~6 weeks The privacy chain closes: 1. R6/R6.1 physics forward model 2. R3 embedding-space re-ID 3. R14 ethical opt-in / on-device / override 4. R15 biometric primitive catalogue 5. ADR-105 within-installation federation 6. ADR-106 DP-SGD + primitive isolation 7. ADR-107 cross-installation + secure aggregation Every layer has a formal guarantee, implementation path, and honest scope. No remaining unspecified privacy gap. Cross-installation training can ship without violating any constraint surfaced by the research loop. Threat model: 8 threats, every row has a mitigation layer. - Compromised aggregator views deltas -> Layer 4 SA - Cross-installation re-ID -> Layer 5 rotation - Sybil -> Layer 4 dropout + Krum + N >= 5 - Quantum-resistant: out-of-scope ADR-108 (Kyber substitution) Honest scope: - Cross-org PKI = operational, not architectural - Krum+SA composition proof is non-trivial; reference implementations needed before production - sqrt(N) amplification assumes installation independence - Drop-out reconstruction has known attack surfaces (Bonawitz §4.3) - Per-cog suitability varies (cog-wildlife yes, cog-maritime-watch no) Composes: - R3+R15 enforcement now technical, not just policy - R7 mincut extends to cross-installation adversarial detection - R12 PABS works at any installation in local rotated embedding space - R10/R11 cogs benefit asymmetrically Coordination: ticks/tick-22.md, no PROGRESS.md edit. |
||
|
|
39d18d1c99 |
research(R6.2.1): 3D antenna placement — ceiling-only gives 0% coverage; mixed-height wins (#724)
Extends R6.2 from 2D ellipse to 3D ellipsoid + 3D target zones (bed at z=0.3-0.6, chair at z=0.5-1.2, standing at z=1.0-1.7 in a 5x5x2.5 m room). Counter-intuitive headline: | Strategy | Coverage | |-------------------------------------------|---------:| | Desk-height (0.8 m walls) | 22.2% | | Wall-mount (1.5 m walls) | 17.4% | | Ceiling-only (2.5 m grid) | 0.0% | <-- FAILS | Mixed walls + ceiling | 25.7% | <-- BEST Ceiling-only fails because both antennas at 2.5 m create a Fresnel ellipsoid sitting AT ceiling height (2.1-2.9 m vertically). Target zones at 0.3-1.7 m are below the envelope by 0.4-2.0 m. The 39 cm transverse radius is symmetric around LOS, so a flat horizontal link at any height misses targets at any OTHER height. This is the 3D version of R6.1's on-LOS-degeneracy finding. A horizontal link at any single height has its envelope concentrated at that height. Why mixed wins: best placement is Tx (5.0, 4.0, 0.8) + Rx (0.0, 4.0, 1.5). The diagonal-in-z link tilts the ellipsoid through multiple elevations. Covers chair AND standing AND bed simultaneously. Vertical link diversity is the 3D insight 2D analysis missed. Installation-guide updates: - Single pair: one low (0.8 m) + one high (1.5 m), opposite walls - 4-anchor: 2x low corners + 2x high opposite corners - 5-anchor knee: mix 0.8 / 1.5 / one ceiling - Bed-only: both LOW - Standing-only: both HIGH - NEVER: both ceiling without a low anchor Coverage numbers are lower than R6.2's 2D 51% because 3D volumetric coverage is inherently lower than 2D area coverage -- honest 3D physics. Composes: - R6.2 (2D) -- incomplete; height matters as much as horizontal - R6.2.2 (N-anchor) -- N=5 knee should distribute across heights - R6.1 (multi-scatterer) -- needs 3D body model for proper composition - R14 V1/V2/V3 -- each vertical needs height-recipe - ADR-029 -- placement is (x, y, z), not (x, y) - R12 PABS -- detects intruders standing/sitting/lying with mixed heights Honest scope: 3-zone discrete approximation, single-pair only, no furniture occlusion, 0.1 m resolution, greedy search. Coordination: ticks/tick-21.md, no PROGRESS.md edit. |
||
|
|
3d3d54d523 |
research(R3.1): physics-informed env prediction at raw-CSI level — NEGATIVE (architecture-error) (#723)
R3's 'next research lever' was: use R6.1 forward operator + room map to predict env_sig without labelled examples in the new room. R6.1 shipped (tick 18); this tick implements the prediction. Result: at raw-CSI level, all three approaches collapse to chance. | Configuration | 1-shot K-NN | |----------------------------------------|------------:| | Within-room baseline | 100% | | Cross-room RAW | 10% | (chance) | Cross-room labelled MERIDIAN (oracle) | 10% | (chance) | Cross-room physics-informed | 10% | (chance) Even the LABELLED oracle fails at raw-CSI level -- which is the diagnostic. The cross-room problem at raw-CSI level is fundamentally harder than at the AETHER embedding level (R3 tick 12) because position-dependent within-room variance dominates per-subject signature when invariantisation hasn't been done. Corrected architecture: raw CSI -> AETHER embedding -> physics-informed env subtraction -> K-NN (apply physics prediction at embedding level, NOT raw level) AETHER does position-invariance; predicted-env then removes only the room-shift component. THIS IS THE LOOP'S THIRD KIND OF NEGATIVE RESULT: 1. Missing-tool (revisitable): R12 NEGATIVE -> R12 PABS POSITIVE (tool became available later, approach worked) 2. Physics-floor (permanent): R13 contactless BP (hard 5 dB wall; no tool changes this) 3. Architecture-error (correctable): R3.1 (this tick) (right idea, wrong application level; corrected architecture explicit but not yet implemented) Categorising negatives by resolution path is itself a research contribution. Surfaces an architecture error BEFORE implementation. A future engineer attempting 'subtract predicted env from raw CSI' would waste weeks; R3.1 documents the failure path. Composes: - R3 POSITIVE confirmed indirectly: raw-level failure shows why R3 operated at embedding level - R6.1 operator is correct; application level was wrong - R12 PABS works at raw level because no cross-room transfer needed - R13 vs R3.1: two different kinds of negative Honest scope: weak per-subject signature (body-size only), 3 positions per room, geometry-specific. Richer biometric input or per-position- clustering might partially rescue raw-level but defeats the no-label spirit. Coordination: ticks/tick-20.md, no PROGRESS.md edit. |
||
|
|
9cd1b8ce2a |
research(R12 PABS): NEGATIVE -> POSITIVE — 1161x detection lift via R6.1 forward model (#722)
R12 (tick 5) was a NEGATIVE result: naive SVD-spectrum cosine distance detected structure changes at 0.69x the natural drift floor (= undetectable). R12 explicitly identified the revision: 'PABS over Fresnel basis'. R6.1 (tick 18) shipped the multi-scatterer Fresnel forward operator. This tick implements PABS on top of it. PABS = ||y_observed - y_predicted||^2 / ||y_observed||^2 Benchmark (5 m link, 2.4 GHz, subject + 4 wall reflectors expected): | Scenario | PABS / drift | SVD (R12) / drift | |--------------------------------|---------------:|------------------:| | Empty room (subject missing) | 7,362x | 65x | | Subject as expected (sanity) | 0x | 0x | | +1 new furniture | 84x | 11x | | +1 unexpected human | 1,161x | 11x | | Subject moved 10 cm | 21,966x | 90x | | Natural drift (5% wall shift) | 1x | 1x | PABS detects unexpected human at 1161x natural drift; R12 SVD detected at 11x. ~100x lift purely from physics-grounded prediction vs naive statistical eigenshift. R12 NEGATIVE -> POSITIVE. The meta-lesson: a research loop that catalogues NEGATIVE results creates a backlog of revisitable work that pays off when later tools become available. R12 -> R12 PABS is the worked example. R13 cannot be similarly revisited -- its 5 dB shortfall is a hard physics floor, not a missing model. The subject-moved-10cm caveat: PABS detects ANY mismatch between expected and observed scene. Real production PABS needs a pose-aware forward model that updates from pose_tracker.rs in real-time. The actual detection signal is PABS-after-pose-update. ~50-100 LOC Rust glue, catalogued as R12.1 follow-up. Composes: - R6.1 unblocked this implementation - R7 gets precise per-link consistency: residual small on all links = no structure; spike on one = local structure OR compromised link; mincut disambiguates - R11 enables maritime container-tamper / hatch-seal apps - R14 gets V0 security feature (intruder detection w/o biometric storage) - ADR-029 needs to reference PABS as structure-detection primitive - R10 PABS-vs-canopy works if forest modelled or learned Honest scope: - Pose-PABS closed loop not yet built - Synthetic data only; real-world drift floor needs measurement - Population-prior body; per-subject would tighten residual - Single time-frame; real pipeline needs temporal averaging Coordination: ticks/tick-19.md, no PROGRESS.md edit. |
||
|
|
bac6962689 |
research(R6.1): multi-scatterer Fresnel — discovers 4.7 dB penalty matching R13's 5-dB shortfall (#721)
Extends R6's point-scatterer to distributed-body model (6 scatterers: head + chest + 2 arms + 2 legs). Combined CSI = coherent sum of per-body-part contributions. Headline finding: 5 m link, 2.4 GHz, subject 25 cm off LOS, breathing at 0.25 Hz with 8 mm chest amplitude: | Configuration | Breathing SNR (best subcarrier) | |----------------------------------------|--------------------------------:| | Single-scatterer ideal (R6) | +23.7 dB | | Multi-scatterer realistic (R6.1) | +19.0 dB | | MULTI-SCATTERER PENALTY | +4.7 dB | This 4.7 dB penalty matches R13's 5-dB-shortfall finding to within 0.3 dB. R13 NEGATIVE concluded that pulse-contour recovery needs +25 dB SNR, only +20 dB is available. R6.1 says the 5-dB gap has a physical origin: static body parts add coherent-sum confusion that doesn't exist in the idealised single-scatterer model. The three threads now form a coherent physics story: - R6 = bound (idealised single-scatterer = +23.7 dB) - R6.1 = floor (realistic 6-scatterer = +19.0 dB) - R13 = failure (contour needs +25 dB, gets +20 dB) Pulse-contour recovery is bounded below by what R6.1 leaves achievable, which is 4.7 dB worse than R6's idealised limit, enough to make R13's contour recovery infeasible. Per-body-part contribution: chest = 27.6% of CSI energy (5x per-limb reflectivity). The chest IS the breathing signal; limbs are confound. Architectural implications: - Chest-centric placement targeting (R6.2.3 motivated) - Mask limbs in vital_signs pipeline (use pose pipeline ADR-079/101) - R14 V3 rescope to rate-only (no contour-shape recovery) - R12 PABS revision unblocked: R6.1 is the explicit A(voxel) operator Surprise finding: on-LOS placement (y=0) is degenerate -- path delta is 2nd-order in offset for on-LOS scatterers, so breathing barely changes path length. Real installations need subject OFF the LOS line. The R6.2 placement search should respect this. Honest scope: - 6 scatterers is 1st-order; 50-100 voxel body would refine - Reflectivity ratios are guesses (RCS measurements would refine) - Static body assumption (limbs do micro-move during breathing) - 2D top-down, no multipath (model general enough to include them) Composes: - R5: subcarrier selection picks reliable, not high-SNR - R6: per-scatterer building block - R6.2.x: chest-centric placement - R7: residual-vs-forward-model = tighter adversarial detection - R12 NEGATIVE: PABS A operator unblocked - R13 NEGATIVE: 5-dB gap has physical origin - R14 V3: needs rescope Coordination: ticks/tick-18.md, no PROGRESS.md edit. |