> ## Documentation Index
> Fetch the complete documentation index at: https://helloluciallc.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Guest Identity and Linkage Contract

<Note>
  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.
</Note>

***

## Purpose

Guest-facing Lucia needs to help people before the system knows who they are.

That requires a strict identity/linkage contract:

<div className="hl-flow"><span>guest orientation</span><span>claim collection</span><span>safe linkage state</span><span>allowed behavior</span></div>

Lucia may be warm while the system remains cautious.

***

## Identity States

Canonical guest identity states:

```text theme={"dark"}
verified_booked_guest
claimed_booked_guest
guest_of_guest
prior_inquiry_or_lead
new_unbooked_visitor
unknown_or_anonymous
```

These states describe who the guest appears to be from the system's current evidence.

***

## Linkage States

Canonical linkage states:

```text theme={"dark"}
verified_booking
operator_linked_booking
candidate_booking
guest_claim
inquiry_record
unlinked
none
```

These states describe what the conversation is connected to.

***

## Verification States

Canonical verification states:

```text theme={"dark"}
verified
unverified
guest_claimed
operator_confirmed
not_applicable
```

These states describe whether the system or operator has confirmed the relationship.

***

## Capability Boundary

### Anonymous / Unlinked

Default anonymous state:

```text theme={"dark"}
identity_state: unknown_or_anonymous
verification_state: not_applicable
linkage_state: unlinked
access_scope: public_only
operator_action: review_only
booking_mutation: no mutations
```

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:

```text theme={"dark"}
identity_state: claimed_booked_guest
verification_state: guest_claimed
linkage_state: candidate_booking
access_scope: public_plus_claim_context
operator_action: operator_link_required
booking_mutation: no mutations
```

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:

```text theme={"dark"}
identity_state: verified_booked_guest
verification_state: verified
linkage_state: verified_booking
access_scope: booking_context_allowed
operator_action: booking_action_allowed
booking_mutation: still bounded by operator/product rules
```

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:

```text theme={"dark"}
guest-provided booking IDs are claims until verified
guest-provided names are claims until verified
guest-provided dates are claims until verified
guest-provided group names are claims until verified
service overlap is never identity evidence
airport pickup overlap is never identity evidence
candidate lookup exposes no private booking fields
guest-entered email is never trusted as the verification destination
```

Airport pickup overlap must never attach an unlinked guest to Luca/Nora or any existing guest.

***

## See Also

* [03 - Magic Link Booking Verification](/lucia/guest-facing-lucia/magic-link-booking-verification)
* [04 - Guest Verification Email](/lucia/guest-facing-lucia/guest-verification-email)
* [02 - Truth State Doctrine](/lucia/foundation/truth-state-doctrine)
* [07 - Guest-Facing Eval Requirements](/lucia/guest-facing-lucia/guest-facing-eval-requirements)