Badge-Presence Twin: Access Logs Cross-Checked Against Bodies
Checks every badge swipe against whether there was actually a body standing there.
Contested Space · Contested capability
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.
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.
The correlation window is ±2–5 seconds, never milliseconds: 6.6 Hz sampling, mesh clock sync and the badge system’s own seconds-class skew are three independent sources of slack. Presence without a badge pages immediately; a badge without presence clears nothing, ever.
Across Camera Shield Jam the mesh and the wake never fires. Two people moving together read as one disturbance. Re-rack a row and the fade map is wrong until you recalibrate.
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.
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.
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 worksProperties you can map to your own controls
These are properties, not certifications. Latent does not assert compliance with any framework on your behalf.
The evidence is proven or strong, but this capability still needs a capability-specific ESP32 or Rust runtime adapter.
Published physics or adjacent results support the hypothesis; capability-specific product and site validation are still required.
No browser runtime is assigned to this capability yet.
No capability-specific offline runtime is mapped yet. Keep the feature visible, explain the required edge adapter, and never fabricate a live result.
Intended capability
This describes the intended outcome. Readiness is needs edge adapter, 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.
No rendered revision is available yet.
Bundled recording
This is one recorded vertical scenario. It is not separate validation of every capability in the catalog.
Presence at a cabinet or console is a 6.6 Hz observable, so the best per-node event timing is around ±150 ms before mesh clock synchronization adds tens of milliseconds more. Access-control and network-access systems carry their own skew at the seconds scale. The correlation window is therefore seconds by physics, and a seconds window is operationally sufficient: a cabinet event with no human-scale presence in that zone within ±5 s is a real and damning flag.
Zone presence verdicts with per-event timestamps -> host-side join against badge, door and console events on a ±5 s window -> asymmetric rule evaluation (presence-without-event pages; event-without-presence records an unresolved row and never clears) -> per-asset correlation ledger.
This is a capability design path. Components may be shared with other catalog entries; it is not presented as a unique algorithm.
Own-hardware: six nodes on a rack row wired to a real badge reader log and a console session log, 200 scripted badge-and-approach events plus 30 deliberate unbadged approaches at slow walking speed; report correlation accuracy inside the ±5 s window, unbadged-presence catch rate, and the count of unresolved rows generated by ordinary badge traffic. No runtime kernel computes the headline — the join is host-side, following the rack-tamper-geometry-door-panel-blanking precedent.
'Reality Check' — the physical cross-check for a CISO who already trusts the badge log more than it deserves, sold with the asymmetry in the contract: unbadged presence pages the SOC, and an unmatched badge is filed as unresolved rather than cleared.
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.