What is true today, and what is only planned.

Rotating pass

The pass is designed as a short-lived, signed code that refreshes every 20 to 30 seconds (a starting point, not a promise). The door app checks signature, expiry, replay, and revocation. A screenshot of an old code should fail those checks.

Today: the screens on this site use a decorative pattern, not a real code. The pass-signing service is not finished.

Provider-hosted ID capture

When a guest verifies, document and selfie capture happen inside a third-party identity provider’s own flow. Our design is to receive only a result: verified or not, the method, the date, and an age-threshold statement. No provider has been selected or integrated yet.

We will describe a check as “government authenticated” only if a provider actually does authoritative source checks. Otherwise we will not say it.

Minimal data

The design keeps raw ID images and face templates out of our own database. What a venue sees at the door is a photo, a name, an age-threshold status, verification method and time, and venue-specific prompts.

Venue-controlled policy

Each venue chooses its own rules, such as always requiring a physical ID check, and the door screen shows those prompts. A check at another venue never auto-admits anyone.

Venue isolation

One venue’s records are separated from another’s by database-level access rules. Automated isolation tests pass against synthetic data on a test database. That is a development test, not an audit.

Audit log

Every door decision is designed to be recorded with who decided, what they chose, and when. Access to those records is limited to people the venue authorizes.

Opt-in sharing

Sharing details of an earlier check between venues needs the guest’s separate consent, and each venue chooses whether to use it. Sharing is off by default.

Deletion and export

Guests will be able to request deletion and export of their data. Retention schedules and exceptions required by law are still with counsel, so we are not publishing numbers yet.