01
One control, many outlets
The same verifier and the same three outcomes across every age-gated outlet on the property, each bound to its own location record.
Casinos and hospitality
A regulated floor, an auditable control, and a narrow data footprint.
Gaming and hospitality operators are used to proving that a control exists and works. LaurelID is designed to be shown to a regulator — including what it deliberately does not record.
01 · The problem today
Proving a control without building a surveillance record
Regulated operators must demonstrate that age controls are applied consistently across a property — gaming floor, bars, restaurants, retail — and be able to evidence it. That pressure often produces heavy logging, on the theory that more records make a better audit.
But records about patrons are not the same as records about your controls. A property can evidence that the control was deployed, active, versioned, and operating, without holding anything about the people who walked past it.
02 · The LaurelID workflow
How the check actually runs here.
02
Evidence about the system
Fleet Health, heartbeats, application and configuration versions, lifecycle state, and credential rotation status — an auditable record that the control was in place and current.
03
Aggregates for the property
Volume and outcome mix per outlet and per day, suppressed below a minimum group size so a report can never single out one interaction.
03 · The privacy advantage
Auditability without patron records
The audit surface here is deliberately about our system rather than your patrons: typed operational events, fleet-health transitions, device lifecycle actions, and version state. None of it references a person, because no person is represented anywhere in the schema.
Where a regulator expects patron-level records, LaurelID will not produce them. That is a genuine constraint and worth establishing early rather than discovering at an inspection.
04 · Deployment
What a rollout looks like in this setting.
Scoped during qualification against your real floor, not assumed from a template.
Dimension Shape
Posture Handheld, per outlet
Structure One organization, many locations
Roles Owner, operator, installer, viewer
Controls Suspend, quarantine, restore, revoke, rotate
Evidence Typed operational and fleet-health events
05 · Limitations
Where LaurelID is the wrong answer here.
If one of these is a hard requirement for you, it is better to know now than three weeks into a pilot.
No patron-level audit trail exists
If your regulatory posture requires evidence about individual patrons — who was checked, when, and with what result — LaurelID cannot supply it, in a pilot or in production. This is architectural, not a configuration choice.
Not an exclusion-list or self-exclusion system
LaurelID answers one age question. It does not identify individuals and therefore cannot support exclusion-list matching or any other identity-based program.
06 · Other settings
Nearby verticals.
Bars and nightclubs
Door staff make a judgement call every few seconds, in bad light, with a queue behind the person in front of them. LaurelID gives them a cryptographic answer instead of a squint.
Liquor retail
Retail age checks happen mid-transaction, under time pressure, with a line forming. The check needs to be fast, defensible, and free of the data exhaust that a scan log leaves behind.
Cannabis retail
Cannabis retail sits under strict age rules and equally strict scrutiny of what operators keep about their customers. A check that collects nothing is easier to defend than a check that collects carefully.
Pilot LaurelID in casinos and hospitality.
Thirty days, one location, two to five verifiers, and a written readout against metrics you agree to first.