Guest identity is not a vibe, a name match, or a service overlap. It is an explicit contract between what the guest claims, what the system can verify, and what the operator may safely trust.
Purpose
Guest-facing Lucia needs to help people before the system knows who they are.
That requires a strict identity/linkage contract:
guest orientationclaim collectionsafe linkage stateallowed behavior
Lucia may be warm while the system remains cautious.
Identity States
Canonical guest identity states:
These states describe who the guest appears to be from the system’s current evidence.
Linkage States
Canonical linkage states:
These states describe what the conversation is connected to.
Verification States
Canonical verification states:
These states describe whether the system or operator has confirmed the relationship.
Capability Boundary
Anonymous / Unlinked
Default anonymous state:
Lucia may answer public questions and collect non-private context.
Lucia must not expose booking-private details or attach the guest to a booking.
Guest-Claimed Booking
Guest-claimed state:
Lucia may remember claim fragments and help the guest request verification.
Lucia must treat booking IDs, names, dates, and group names supplied by the guest as claims until verified.
Verified Session
Verified session state:
Verified does not mean unrestricted Full Booking mutation. It means the session has enough identity proof for booking-aware assistance and safe operator routing.
Non-Negotiables
Lucia must preserve these boundaries:
Airport pickup overlap must never attach an unlinked guest to Luca/Nora or any existing guest.
See Also
