Back to Ruview

Architecture Decision Records

docs/adr/README.md

0.7.08.1 KB
Original Source

Architecture Decision Records

This folder contains 44 Architecture Decision Records (ADRs) that document every significant technical choice in the RuView / WiFi-DensePose project.

Why ADRs?

Building a system that turns WiFi signals into human pose estimation involves hundreds of non-obvious decisions: which signal processing algorithms to use, how to bridge ESP32 firmware to a Rust pipeline, whether to run inference on-device or on a server, how to handle multi-person separation with limited subcarriers.

ADRs capture the context, options considered, decision made, and consequences for each of these choices. They serve three purposes:

  1. Institutional memory — Six months from now, anyone (human or AI) can read why we chose IIR bandpass filters over FIR for vital sign extraction, not just see the code.

  2. AI-assisted development — When an AI agent works on this codebase, ADRs give it the constraints and rationale it needs to make changes that align with the existing architecture. Without them, AI-generated code tends to drift — reinventing patterns that already exist, contradicting earlier decisions, or optimizing for the wrong tradeoffs.

  3. Review checkpoints — Each ADR is a reviewable artifact. When a proposed change touches the architecture, the ADR forces the author to articulate tradeoffs before writing code, not after.

ADRs and Domain-Driven Design

The project uses Domain-Driven Design (DDD) to organize code into bounded contexts — each with its own language, types, and responsibilities. ADRs and DDD work together:

  • ADRs define boundaries: ADR-029 (RuvSense) established multistatic sensing as a separate bounded context from single-node CSI. ADR-042 (CHCI) defined a new aggregate root for coherent channel imaging.
  • DDD models define the language: The RuvSense domain model defines terms like "coherence gate", "dwell time", and "TDM slot" that ADRs reference precisely.
  • Together they prevent drift: An AI agent reading ADR-039 knows that edge processing tiers are configured via NVS keys, not compile-time flags — because the ADR says so. The DDD model tells it which aggregate owns that configuration.

How ADRs are structured

Each ADR follows a consistent format:

  • Context — What problem or gap prompted this decision
  • Decision — What we chose to do and how
  • Consequences — What improved, what got harder, and what risks remain
  • References — Related ADRs, papers, and code paths

Statuses: Proposed (under discussion), Accepted (approved and/or implemented), Superseded (replaced by a later ADR).


ADR Index

Hardware and firmware

ADRTitleStatus
ADR-012ESP32 CSI Sensor Mesh for Distributed SensingAccepted (partial)
ADR-018ESP32 Development Implementation PathProposed
ADR-028ESP32 Capability Audit and Witness RecordAccepted
ADR-029RuvSense Multistatic Sensing Mode (TDM, channel hopping)Proposed
ADR-032Multistatic Mesh Security HardeningAccepted
ADR-039ESP32-S3 Edge Intelligence Pipeline (on-device vitals)Accepted (hardware-validated)
ADR-040WASM Programmable Sensing (Tier 3)Accepted
ADR-041WASM Module Collection (65 edge modules)Accepted (hardware-validated)
ADR-044Provisioning Tool EnhancementsProposed

Signal processing and sensing

ADRTitleStatus
ADR-013Feature-Level Sensing on Commodity GearAccepted
ADR-014SOTA Signal Processing AlgorithmsAccepted
ADR-021Vital Sign Detection (breathing, heart rate)Partial
ADR-030Persistent Field Model and Drift DetectionProposed
ADR-033CRV Signal Line Sensing IntegrationProposed
ADR-037Multi-Person Pose Detection from Single ESP32Proposed
ADR-042Coherent Human Channel Imaging (beyond CSI)Proposed

Machine learning and training

ADRTitleStatus
ADR-005SONA Self-Learning for Pose EstimationPartial
ADR-006GNN-Enhanced CSI Pattern RecognitionPartial
ADR-015Public Dataset Strategy (MM-Fi, Wi-Pose)Accepted
ADR-016RuVector Training Pipeline IntegrationAccepted
ADR-017RuVector Signal + MAT IntegrationProposed
ADR-020Migrate AI Inference to Rust (ONNX Runtime)Accepted
ADR-023Trained DensePose Model with RuVector PipelineProposed
ADR-024Project AETHER: Contrastive CSI EmbeddingsRequired
ADR-027Project MERIDIAN: Cross-Environment GeneralizationProposed

Platform and UI

ADRTitleStatus
ADR-019Sensing-Only UI with Gaussian SplatsAccepted
ADR-022Windows WiFi Enhanced Fidelity (multi-BSSID)Partial
ADR-025macOS CoreWLAN WiFi SensingProposed
ADR-031RuView Sensing-First RF ModeProposed
ADR-034Expo React Native Mobile AppAccepted
ADR-035Live Sensing UI Accuracy and Data TransparencyAccepted
ADR-036Training Pipeline UI IntegrationProposed
ADR-043Sensing Server UI API Completion (14 endpoints)Accepted

Architecture and infrastructure

ADRTitleStatus
ADR-001WiFi-Mat Disaster Detection ArchitectureAccepted
ADR-002RuVector RVF Integration StrategySuperseded
ADR-003RVF Cognitive Containers for CSIProposed
ADR-004HNSW Vector Search for FingerprintingPartial
ADR-007Post-Quantum Cryptography for SensingProposed
ADR-008Distributed Consensus for Multi-APProposed
ADR-009RVF WASM Runtime for Edge DeploymentProposed
ADR-010Witness Chains for Audit Trail IntegrityProposed
ADR-011Proof-of-Reality and Mock EliminationProposed
ADR-026Survivor Track Lifecycle (MAT crate)Accepted
ADR-038Sublinear GOAP for Roadmap OptimizationProposed

  • DDD Domain Models — Bounded context definitions, aggregate roots, and ubiquitous language
  • User Guide — Setup, API reference, and hardware instructions
  • Build Guide — Building from source