Crate heldar_entry 

Heldar Access Control — generic, open (Apache-2.0) reference app.

Built on the open heldar-kernel platform. Provides ANPR authorization (plate → registry resolution → canonical entry event), the vehicle/visitor-pass/watchlist registry, the guard confirm/reject workflow, and entry/exception/audit reports. It is domain-neutral — any gated-entry deployment (residential, corporate, industrial) uses it as-is. It plugs into the kernel purely through public seams: heldar_kernel::services::consumer::DetectionConsumer (the ANPR engine), heldar_kernel::state::AppState + the shared SQLite pool, the auth primitive, and the error/model types. The kernel has no dependency on this crate — the composing server links it.

Proprietary vertical/client products depend on THIS crate and layer their domain specifics on top; the generic access-control core stays open. See ARCHITECTURE.md for the open-core split.

Modules

anpr

ANPR entry engine (Stage 4): consolidates per-frame plate reads from the AI worker into one authoritative entry/exit event per vehicle track via temporal voting, resolves the plate against the registered-vehicle / visitor-pass / watchlist registry, classifies authorization (matched / exception / unmatched / blocked), and writes a canonical entry event with an evidence frame.

config

The access-control app’s own configuration, loaded from the environment by the composing server. The open kernel does not carry any entry-app tuning knobs.

models

Access-control domain models (registry + canonical entry events). The RBAC/auth models (User, ApiKey, …) remain in the kernel auth module for now.

retention

The access-control app owns the lifecycle of its own data: it prunes old entry events (and deletes their evidence frames) on the entry-retention TTL. The kernel’s retention sweeper handles only kernel-owned data (segments, detections, outbox, zone events, sessions, audit, events).

routes

Stage 4 access-control surface: registered vehicles, visitor passes (+ check-in/out), watchlist, the canonical entry-event feed with a guard confirm/reject workflow, and reports (daily entry log, exceptions, audit). Reads require any authenticated principal; registry mutations require manager+, gate operations require guard+, and the audit report requires manager+.

schema

The access-control app owns its own schema, applied idempotently against the shared kernel pool on startup (single-tenant-per-deployment). The open kernel does not define these domain tables.

Functions

manifest

This app’s module manifest (served at GET /api/v1/modules so the dashboard renders its nav).