Three-Tier Node — Decision Tree

This document maps each load-bearing decision in the three-tier proposal to (a) what it depends on, (b) what evidence would justify yes/no, and (c) which ADR slot would house the decision once made. It is intentionally short — the prose lives in the SOTA survey and the seed exploration.

1. Load-bearing vs independent decisions

Six decisions are load-bearing — they unblock or block other decisions:

Five decisions are independent of the three-tier shape and can be made in parallel:

2. Decision tree (Mermaid)

flowchart TD
    L1{"L1: BOM ceiling per node?"}
    L1 -->|"<= $15"| KEEP_TODAY["Keep ADR-028 single-S3 node.
Three-tier proposal is out of budget."]
    L1 -->|"$15-$30"| L3
    L1 -->|"> $30"| L3

    L3{"L3: Heavy compute per node
or per cluster?"}
    L3 -->|"per cluster (1 Pi / 3-6 nodes)"| HYBRID["Hybrid path:
single-S3 sensor + cluster Pi.
Cheapest viable upgrade."]
    L3 -->|"per node"| L2

    L2{"L2: Single-MCU or dual-MCU
per node?"}
    L2 -->|"single MCU"| L4_SINGLE["ADR-081 already covers this.
Investigate WHY a dual-MCU is needed."]
    L2 -->|"dual MCU (sensor + comms)"| L4

    L4{"L4: Is no_std CSI capture
production-quality?"}
    L4 -->|"no / unknown"| L4_NO["Hold dual-MCU shape until
esp-csi-rs / esp-radio matches
esp_wifi_set_csi_rx_cb in jitter & quality."]
    L4 -->|"yes (benchmarked)"| L5

    L5{"L5: Mesh control plane:
WiFi or 802.15.4?"}
    L5 -->|"WiFi (ESP-WIFI-MESH)"| L5_WIFI["Comms MCU = ESP32-S3.
Stays on existing ADR-029 shape."]
    L5 -->|"802.15.4 (Thread)"| L5_THREAD["Comms MCU = ESP32-C6.
Hybrid: WiFi data + Thread control."]

    L6{"L6: Heavy compute SoC?"}
    L6 -->|"Pi Zero 2W"| L6_ZERO["dm-verity + signed FIT.
NOT immutable-ROM secure boot."]
    L6 -->|"CM4 / Pi 5"| L6_CM4["RPi-foundation secure boot path.
+~$30-50 BOM."]

    HYBRID --> L6
    L5_WIFI --> L6
    L5_THREAD --> L6

    L4_NO -.->|"if gated long-term"| HYBRID

    style KEEP_TODAY fill:#cfe
    style HYBRID fill:#cfe
    style L4_NO fill:#fec
    style L4_SINGLE fill:#cfe

The tree's recommended cheapest-first path is: L1 → L3 (per-cluster) → HYBRID, which keeps today's ESP32-S3 sensor nodes and adds one Pi per 3–6 nodes. This captures most of the QUIC / ML / secure-boot value without re-spinning the per-node PCB.

3. Decision detail — what evidence justifies each branch

L1 — Per-node BOM ceiling

L2 — Single vs dual MCU per node

L3 — Per-node vs per-cluster heavy compute

L4 — CSI no_std maturity gate

L5 — Mesh control-plane technology

L6 — Heavy-compute SoC choice

4. Independent decisions — make in parallel

Each of these can be evaluated in isolation; none depend on the L-decisions.

5. Recommended ADR sequence

If the three-tier proposal is partially adopted, the recommended ADR sequence is outside-in — address the cheapest, most independent decisions first, gate the load-bearing ones on real evidence:

1. Independent ADRs first (any order):
   • I1 LoRa fallback chip choice.
   • I2 Power-path / PMIC choice (probably BQ24074 if panel stays ≤ 2 W, BQ25798 otherwise).
   • I3 QUIC vs MQTT-over-TLS (likely MQTT for the heartbeat-only case, QUIC if model updates and fleet sync are real).
2. Per-cluster-Pi ADR (L3, hybrid branch) — the high-value, low-cost first step. One Pi per 3–6 nodes. Captures most of the ML/QUIC/ secure-boot value at minimal per-sensor BOM impact.
3. Mesh control-plane ADR (L5) — only if deployments target > 25 nodes. Otherwise stays on ESP-WIFI-MESH per ADR-029.
4. CSI no_std maturity benchmark ADR (L4 evidence) — investigate, but do not commit to dual-MCU until benchmarked.
5. Dual-MCU node ADR (L2) — only after L4 evidence + a clear ML or ISR-jitter problem on the single-MCU node.
6. Three-tier-PCB ADR (full proposal) — last, only if BOM / threat- model / scale all justify it.

This ordering deliberately keeps the bulk of the deployable surface on today's ADR-028 / ADR-081 baseline while letting each separable upgrade be evaluated on its own evidence.

6. Out-of-scope for this document

• Re-evaluating ADR-029 mesh choices beyond mentioning Thread as alternative — that belongs in a Mesh-control-plane ADR.
• Specific PCB layout of any of the candidate boards.
• Cloud-side architecture (gateway, fleet-sync target, time-series storage). Out of scope of the node architecture proposal.
• Cross-environment domain generalization (ADR-027) — orthogonal to the hardware shape.
• Multistatic fusion algorithms (wifi-densepose-ruvector::viewpoint) — orthogonal to the hardware shape.

7. References to other documents in this set

• architecture/three-tier-rust-node.md — the seed proposal.
• sota/2026-Q2-rf-sensing-and-edge-rust.md — SOTA evidence per topic.
• architecture/implementation-plan.md — earlier (2026-04-02) GOAP plan for ESP32-S3 + Pi Zero 2 W; the three-tier proposal is most usefully read as an extension of this plan.
• architecture/ruvsense-multistatic-fidelity-architecture.md — multistatic fusion architecture, orthogonal to node hardware shape.