Organization
The merchant tenant. Every record in the system belongs to exactly one, and queries are scoped to it rather than filtered after the fact.
LaurelID Console
The control plane for every verifier you own.
Create devices, activate them once, bind them to a location, and govern what they are allowed to do — from a control plane designed without patron identity.
01 · Provisioning
Created in the portal. Activated exactly once.
A device record is created before any hardware is touched. Activation consumes a single-use code and issues an encrypted device credential that never leaves the device’s hardware-backed keystore. A code that has been used is spent — there is no second activation from the same code.
Step What happens
create Device record, bound to one organization and one location
activate Single-use code exchanged for an encrypted device credential
protect Android Keystore, StrongBox where the hardware provides it
configure Verifier retrieves its configuration and policy version
report in Heartbeats begin; the device appears in Fleet Health
02 · Structure
Organizations and locations, not a flat device list.
Location is the canonical operational model. Reporting rolls up to it, permissions scope to it, and policy is evaluated against it — which is why a verifier cannot be reassigned in place.
Location
A physical site. Verifiers, aggregate counts, and reporting all hang off it. The address stored here is the venue’s, never a patron’s.
Roles
Owners, operators, installers, and viewers see different surfaces. Report suppression applies to every role, including the highest one.
03 · What the Console shows
Fleet state, at the level a manager can act on.
Four states
Ready, Setting up, Needs attention, Off. A verifier that needs attention says why in one sentence and names the one thing to do about it.
Verification, reporting, connection
Three separate answers for every verifier. A verifier that lost its network keeps its last confirmed “verifying” answer, with the time it was confirmed, instead of looking broken.
Everything else behind Advanced
Versions, configuration, trust freshness and the complete diagnostic record stay one disclosure away for support, and out of the way for everyone else.
04 · Auditability
Operational events, about our system rather than your customers.
Lifecycle actions, policy changes, and fleet-health transitions are recorded as typed operational events. Their metadata is constrained by a schema keyed to each event type, so there is no free-text field where a name could land “just this once.”
Record Contents
operational_events Typed system events with schema-bound metadata
fleet_health_events Connectivity and trust-freshness transitions
verification_totals Cumulative counters per location and outcome
verification_aggregates The same counters, bucketed by day
patron entity no table · no key · no foreign key possible
Review the control model against your own locations.
Pilot scope includes Console access, deployment support, and the same reporting-suppression rules described in the trust center.