All capabilities
Airspace Watch — RF Noise, Rogue Emitters & Jamming Shared-family mapped

Deaf Node

Link-Denial Tripwire: Own-Channel Jam Detection

Notices the moment the sensors stop hearing, and says which room went quiet.

Feasibility path · not a production offer

Airspace Watch Floor Kit

This offer is scoped to this capability only. It does not promote sibling catalog entries or replace physical deployment validation.

~$320 parts · 6 Nodes · ~120 minReview feasibility scope →No charge today · configuration and quote confirmed first

Contested Space · Contested capability

What this capability does not do.

Does not act.

Latent emits a reading. It does not switch cameras, unlock cages, cut power or open a ticket. Your VMS, PoE switch or access controller does that, on your side of the boundary. A Latent blueprint contains no executable code, no remote URLs and no device secrets — by schema, not by policy.

Does not identify.

No face, no plate, no MAC, no device identity, no payload. A movement signature is a shape moving through a room, not a person. Nothing stored here resolves to an individual.

Does not survive everything.

A jammer that stays below the escalation threshold of your baseline is invisible, and a jammer already running when the baseline was taken is written into “normal”. The baseline must be captured in a verified-quiet window; a baseline of unknown provenance is worth nothing.

Across Airspace A jammer already running when you took the baseline is invisible. The baseline must be captured in a verified-quiet window, and a baseline of unknown provenance is worth nothing.

Observable
Collapse of the node’s own CSI frame rate against a rolling baseline, corroborated by received power on the protected 20 MHz channel.
Retention
Event rows: which node went deaf, when, and by how much. No IQ capture, no payload, no attacker identity, and no claim about any other band.
Node minimum
2 nodes
Export policy
Conditional — Exportable into a signed release, subject to the deployment’s own preflight.
Chain of custody

Node identity

Each node mints its own key over USB, in your hand. Physical possession is the root authority: a device that cannot prove physical presence is refused enrollment outright. A cloud pairing PIN is a weaker ownership claim and is never treated as liveness.

Reading provenance

Every reading is attributable to a device id, profile id, hardware id and firmware version recorded at install and verified by mutual HMAC-SHA256 proof over an LFW1 nonce exchange. A node whose proof did not verify is marked untrusted, not merely offline.

Install attestation

Completing an installation is a high-risk action. It requires your explicit browser approval, an approval snapshot that still matches, an idempotency key, and heartbeats less than three minutes old. There is no silent commissioning.

How enrollment works

Properties you can map to your own controls

  • No optical sensor is present in this capability’s node set.
  • Raw CSI does not leave the node. Only derived event rows are stored or exported.
  • No stored identifier resolves to a person. Where access events are correlated, that correlation happens in your systems, against your logs.
  • The runtime executes on the node and in your browser. This capability has no cloud inference path.

These are properties, not certifications. Latent does not assert compliance with any framework on your behalf.

A capability description, not an incident record.
Readiness Shared-family mapped

Mapped to a shared offline runtime family and usable with a recording or compatible ESP32 CSI stream.

Evidence Strong theory Supported hypothesis

Published physics or adjacent results support the hypothesis; capability-specific product and site validation are still required.

Runtime family Link denial

Collapse of the node’s own CSI stream and received power against a learned baseline. This is evidence that one link on one 20 MHz channel went deaf — never attacker identification, and never a claim about any other band.

When no ESP32 is connected

No compatible ESP32 stream is connected. Use the bundled Airspace recording; it demonstrates the shared Link denial runtime, not independent proof of this capability.

Intended capability

Pilot this intended outcome through the shared Link denial family, then validate it against site-specific ground truth: Fires when the mesh stops hearing: successfully received frames per second collapse against a learned baseline while received power moves the wrong way, and the event row names the node and the room that went deaf. This is evidence that one link on one 20 MHz channel lost reception — never attacker identification, never a claim about any other band. A single node's collapse never pages; corroboration count across links is the entry's real tuning knob, because a microwave oven produces the same shape on one node. On radar-equipped nodes the mmWave radar — an HLK-LD2410C attached to the node over a short serial cable — keeps in-room presence alive at 24 GHz through the denial window, so the event row can carry 'room occupied' or 'room empty' while the node is deaf. That answer has its own defeats, stated plainly: a 24 GHz jammer blinds the radar too, and an approach routed outside its aimed cone was never in view.

This describes the intended outcome. Readiness is shared-family mapped, evidence is class B, and a catalog mapping or recording is not proof of this outcome at a real site.

Solution blueprint

This exact kit is one of 191 first-class designs. It includes geometry, objects, nodes, wording, scenarios, installation, limitations, and catalog-bound readiness.

Shared-family mapped

No rendered revision is available yet.

Bundled recording

A related Airspace scene

This is one recorded vertical scenario. It is not separate validation of every capability in the catalog.

01 The physics

An ESP32-S3 has no spectrum analyzer and does not need one to notice it has gone deaf. Interference or jamming on the 20 MHz channel the node occupies destroys frames before they demodulate, so the count of successfully received frames per second falls while received power on the frames that do survive holds or rises. Rate and power moving apart is the jam signature; rate falling with power falling is a link that simply walked out of range.

02 Shared processing path

On-node frame inter-arrival timing (measured directly from the receive stream, never from the reported sampling rate) + received-power series -> adaptive PCA baseline over the node's own verified-quiet rate/power history -> CUSUM on the rate-collapse residual gated by power direction -> multi-node corroboration count -> compartment attribution to the largest-deficit node's named room -> on radar-equipped nodes, the radar's presence verdict over its serial line annotates the event row with occupied/empty for the denial window.

This is a capability design path. Components may be shared with other catalog entries; it is not presented as a unique algorithm.

03 Validation plan

Own-hardware: six-node bench mesh on one channel, baselined across a verified-quiet hour, then degraded with a co-channel saturating transmitter and separately with a microwave oven at rising duty cycle; report detection latency, false-page rate against the oven, and the corroboration count at which benign interference stops paging. CSI-Bench for rate/power feature stability under interference; no public dataset covers jamming at this hardware class, so this trial is the evidence.

04 Commercial hypothesis

'Deaf Node' — for the netsec lead who logs every login and nothing about the air: a per-room tripwire that fires the moment the mesh loses reception, sold on the understanding that it reports one channel's health and says nothing about who caused it.

A quiet reading is not an all-clear. If nodes are stale, degraded or jammed, this runtime says so explicitly. It never infers safety from missing data.