The lock-code dual gate

A door code is physical access to a unit, so it is the most tightly governed thing the system releases. The rule is one sentence: a guest gets a code only when their payment is verified AND their identity is verified - both checked at the moment of sending. Everything else on this page is that sentence playing out.

The life of one code release

Follow a single booking from confirmation to key-in-hand:

1. pending - the moment the booking confirms, a relay record is born. Nothing is sent; the configured lead window before check-in hasn’t opened yet.
2. The lead window opens, and the gate is evaluated - now, not at configuration time. Fully paid (advance and on-property both cleared) and, where your ID policy applies, every guest on the booking verified?
   • armed - the gate is clear. The code is ready, and the relay card on Today lights up for the human hand-off.
   • held - the gate is not clear. The hold is recorded with its reason (not fully paid, or ID not verified) and surfaces on Today. Held is not a dead end: the gate re-evaluates on every tick, so verifying the payment or the ID later releases the code with no further step.
3. relayed_to_poc - the Point of Contact reveals the code to themselves. The reveal is audited; the code’s value never enters the audit trail.
4. handed_to_guest - the POC completes the hand-off. Terminal. (A cancelled or no-show booking instead ends the relay as cancelled - void, nothing sent.)

The one autonomous path

By default a human sends every code. The only way a code reaches a guest without a person pressing the button is a rule you author yourself in the Agent Hub: “Door code to the guest before check-in” (guest.lock-code-pre-checkin), with a lead time you choose. No rule configured means no automated send, ever.

Even with the rule enabled, the dual gate applies unchanged - re-evaluated at send time by the executor, exactly as in the human flow. There is no rule setting that weakens or skips it. A rule-driven send that hits the gate goes held, shows on Today, and re-tries as the blockers clear; every automated action is recorded with system as the actor plus the rule that acted.

Fine print on the ID half

The ID condition applies where your workspace’s policy requires verification, and it demands the status verified for every guest on the booking - one unverified co-guest holds the code. A waived check (a human chose to skip screening) does not count as verified; a carry-forward (a human confirmed this guest was verified on a prior stay) does.

No path around it

The gate has no override - not for admins, not for automations, not for anyone. Roles decide who may press the button (the POC hands codes over; the same seat holds the automated-send permission, so revoking the seat revokes both), but nobody’s role lets an unpaid or unverified guest through. And the sharpest boundary of all: agent rules can release a door code under this gate, but no rule can move money - that verb does not exist in the rule vocabulary.

Watching it work

The tenant-wide Lock Codes screen is the relay ledger - every code’s lifecycle across all bookings, with no code values on it. The day’s own releases and holds live on Today.