ruvnet--RuView/api-docs/adr/ADR-310-80211bf-native-architecture.md

ADR-310: 802.11bf-native architecture — standardized WLAN sensing as native measurement types

• Status: Proposed (ADR-300 phase 2)
• Date: 2026-08-11
• Deciders: ruv
• Tags: 80211bf, wlan-sensing, standards, measurement-types, hal, phase-2

Context

This ADR is a child of ADR-300 and owns primitive #10, 802.11bf-native architecture. In the ADR-300 phasing it is a phase-2 integration primitive: it sits on the phase-1 spine (authenticated identity ADR-305, spatial ontology ADR-306, evidence engine ADR-304) and feeds ADR-320 (the RuView sensor HAL), which is the clause of the acceptance test that "identifies the hardware." It is authored as Proposed.

IEEE 802.11bf-2025 ("WLAN Sensing") was published 2025-09-26 — verified against the IEEE SA record in wifi-densepose-hardware (ieee80211bf/mod.rs header, "evidence grade MEASURED", ADR-152 §1.1). Standardization is complete for sub-7 GHz and >45 GHz (DMG) bands: formal sensing measurement setup, measurement instances, feedback/reporting, and sensing-by-proxy (SBP). This changes RuView's strategic frame: rather than treating every WiFi measurement as an opportunistic extraction from incidental traffic, RuView can be the open reference sensing stack around the standard — the day commodity silicon exposes it.

Substantial scaffolding already exists and must be reused/extended, not rebuilt. v2/crates/wifi-densepose-hardware/src/ieee80211bf/ already models the standardized procedure surface as forward-compatible types (ADR-152/153):

• types — SpecProfile version gates, SensingRole/TransceiverRole, MeasurementSetupParams, SensingCapabilities negotiation, and required ConsentMode governance metadata on every setup.
• messages — SensingMeasurementSetupRequest/Response, SensingMeasurementInstance, SensingMeasurementReport, CsiReportPayload, SbpRequest/Response, SensingSessionTermination.
• session — a deterministic FSM (Idle → SetupNegotiating → Active → Terminating → Idle) with rejection paths, single-role enforcement, and SBP proxy mode; table (responder-side setup registry); transport (the SensingTransport seam, a SimTransport test double, and an OpportunisticCsiBridge that maps today's opportunistic CSI onto the standardized report path).

The module's own honesty note is authoritative and carried forward here: it is not a certified 802.11bf implementation, and no commodity silicon — ESP32 included — implements the standard yet; the OTA frame binding lands when a chipset exposes it. Wideband ingest plumbing is already in place too: ADR-292 (FeitCSI/AX210) carries native subcarrier dimensionality end-to-end and records the native→pipeline mapping, and noted that "truncated CIR is a natural extension of the same plumbing."

What is missing is architectural, not protocol scaffolding: normalized CSI is still treated as the WiFi input. The standardized sensing measurements (TB/non-TB soundings, truncated CIR / PDP reports) are modeled as protocol messages but are not yet first-class native measurement types that flow through calibration (ADR-301), fusion (ADR-311), and the ontology (ADR-306) on equal footing with normalized CSI.

Options considered

1. Keep 802.11bf as a protocol model only; always down-convert its reports to normalized CSI at ingest. Rejected: truncated CIR/PDP carry range-resolved multipath structure that flattening to a CSI matrix discards; it also wastes the standard's native report semantics.
2. Fork a parallel "bf pipeline" alongside the CSI pipeline. Rejected: duplicates calibration, fusion, ontology, and evidence plumbing, and re-opens the O(surfaces²) translation problem ADR-306 exists to close.
3. Promote standardized sensing measurements to native measurement types inside the existing pipeline, with normalized CSI as one measurement type among several. Chosen.

Decision

Adopt an 802.11bf-native architecture: standardized WLAN sensing measurements become additional native measurement types, alongside — not replacing — normalized CSI.

1. Native measurement types

• Define the standardized reports the ieee80211bf module already models (TB and non-TB soundings; truncated CIR; PDP) as first-class MeasurementType variants that the pipeline carries end-to-end, each tagged with its SpecProfile and band. Normalized CSI remains one such type; the OpportunisticCsiBridge remains the path for silicon that only offers incidental CSI.
• Truncated CIR/PDP reuse the ADR-292 subcarrier-agnostic / native- dimensionality plumbing (truncated CIR is the stated natural extension); the native→pipeline mapping is recorded in frame metadata so downstream stages know the true range/spectral resolution of a bf report vs. an interpolated CSI frame.

2. Ontology and governance binding

• Each standardized measurement becomes an ADR-306 Observation node from an ADR-305-authenticated Sensor, carrying SemanticProvenance and exactly one EvidenceLevel (L0–L5, ADR-282). The ieee80211bf ConsentMode metadata — required on every setup — composes with the ADR-277 policy engine, so a standardized session is admitted under the same governance as any other sensing task (ADR-280).
• SBP (sensing-by-proxy) sessions attribute the report to the proxying and the sensing entities distinctly, so provenance is not laundered through the proxy.

3. HAL feed (ADR-320)

• The capability set a device advertises — which MeasurementTypes, bands, bandwidths, roles, and SpecProfile it supports — is exactly the descriptor ADR-320 (HAL) needs to "identify the hardware." ADR-310 defines that capability descriptor as the projection of SensingCapabilities; ADR-320 consumes it. A device that implements no bf profile advertises only the opportunistic-CSI capability.

Consequences

• RuView is positioned as the open reference stack around the standard: when a chipset exposes 802.11bf, its native reports flow through calibration, fusion, ontology, and evidence with no bespoke pipeline — the plumbing is already tested against SimTransport and synthetic fixtures.
• Normalized CSI is demoted from "the WiFi input" to "one measurement type," which is the correct framing for a multi-measurement future and prevents the bf path from being a second-class citizen.
• No hardware claim is made or implied. No commodity silicon implements 802.11bf yet; this ADR wires the types and flow, tested in simulation. Any OTA/native-report accuracy claim requires real silicon evidence (a captured log) per CLAUDE.md, and any wideband number must be tagged with the capture hardware (ADR-292). No benchmark number is invented here.
• This ADR does not re-open ADR-152/153's decision to avoid OTA frame binding until silicon exists; it consumes that surface and adds the pipeline integration.

Validation

• cargo test -p wifi-densepose-hardware — existing ieee80211bf FSM, table, and transport tests continue to pass; new tests assert that a SensingMeasurementReport (TB and non-TB) and a truncated-CIR/PDP report round-trip through the pipeline as native MeasurementTypes.
• cargo test -p wifi-densepose-mat — truncated CIR ingest reuses the ADR-292 subcarrier-agnostic path and records the native→pipeline mapping; dimension/ version validation on standardized reports mirrors the FeitCSI parser gates.
• Ontology/governance tests: each standardized measurement becomes an ADR-306 Observation from an ADR-305-authenticated Sensor with one EvidenceLevel; ConsentMode composes with ADR-277 admission; SBP attributes proxy vs. sensor provenance distinctly.
• HAL contract test: the ADR-320 capability descriptor is derivable from SensingCapabilities; a bf-less device advertises only opportunistic CSI.
• All measurement-type flows are simulation-tested (SimTransport, synthetic fixtures); OTA binding and any hardware accuracy claim remain out of scope until real silicon exposes the standard.