---
type: concept
tags: [parking, entry, admin, devices, threat-model, presence]
sources: []
updated: 2026-07-04
status: settled
---

# Entry presence-gate bypass (faulty radar / faulty camera)

The transient entry gates require a **real vehicle** before a ticket can mint: the radar/loop
presence input and the camera vehicle-detection ([[entry-double-press]] for the physical button,
[[operator-issued-entry]] for the booth button). When one of those devices is **faulty** — a dead
radar, a camera that stopped pushing ([[g3h-anpr-push-gotchas|it happens]]) — the gate blocks
**legitimate** transient entry until support fixes the hardware. This feature lets the **admin**
drop a specific signal as a requirement until then. Built 2026-07-02 (migration `0020`).

## The principle: the admin is NOT the adversary

The [[threat-model]] adversary is the **booth operator**; the admin is the trusted party. So the
admin *may* weaken an anti-fraud gate — but weakening it stays **attributed and auditable**
(signed), because "trusted" never means "invisible" in this system. Compare
[[operator-issued-entry]], where the untrusted role gets capability + a red flag on every use;
here the trusted role gets a switch + a signed record of flipping it.

## Decisions (2026-07-02)

- **Granular, not a master switch.** One flag per signal: a faulty camera drops only the camera
  check (radar still gates); a faulty radar drops only radar. Chosen over a single "bypass all"
  toggle so a single broken device never silently disables the *other*, still-working gate.
- **Persists until turned OFF, and every flip is signed.** No auto-expiry (support visits are
  unpredictable); instead each enable/disable appends a **`config_change`** ledger event
  (`setting: entryPresenceBypass.<signal>`, `value`, `prev`, `operator`) — the append-only chain
  records *who weakened the gate and when*, and the OFF transition too. A no-op write (same value)
  signs nothing.

## What a bypass changes

- **Physical button** (`EntryFlow.#suppressReason`): camera bypassed → the camera press-gate is
  skipped; radar bypassed → the presence-loop check is skipped and the press falls through to the
  **cooldown backstop**. ⚠️ A dead loop can't re-arm one-car-one-ticket, so with radar bypassed
  and **no `entryCooldownSec` configured there is no anti-double-press left** — the admin's
  accepted tradeoff while bypassed (set a cooldown when bypassing radar).
- **Operator button** (`issueForOperator`): the bypassed signal is dropped as a requirement; a
  refusal only happens when a **still-required** signal fails to confirm.
- **Auditability on every ticket:** a ticket minted under a bypass carries
  `presenceBypassed: ["radar"|"camera", ...]` on its signed `vehicle_entry` (and refusal anomalies
  record it too) — so reconciliation can always tell which entries happened under a weakened gate.
- **Booth lights** ([[booth-console]]): a bypassed signal renders as satisfied, so the operator's
  button-enable logic matches the server's.

## As-built

- **Schema:** `site_config.bypass_presence_radar` / `bypass_presence_camera` (booleans, default
  off = the normal both-required gate), migration `0020_entry_presence_bypass.sql`. Read **live**
  per decision — a toggle needs no restart.
- **Endpoint:** `PUT /api/site-config/presence-bypass` (`routes/site.ts`), admin-only
  (`site:update`), signs one `config_change` per actually-changed signal, 400 on non-boolean/empty.
- **UI:** SetupWizard "presence gate" panel (two checkboxes + an amber "active" warning) after the
  controller section; `config_change` events render amber in the booth feed.
- **Tests:** `entry-presence-bypass.test.ts` (gate decisions under each combination),
  `presence-bypass-route.test.ts` (RBAC, signing, no-op, validation), and
  `entry-press-gate.test.ts` (camera bypass on the physical press).
- Fixing this surfaced a latent bug: `firstRelayByDirection` never attached `presenceInput`, so
  the operator-issue radar check had always read "presence loop unavailable" (fixed 2026-07-02).