Skip to main content
Guest-facing Lucia is HelloLucia, LLC’s public concierge product surface. She helps guests warmly before verification, preserves privacy while identity is uncertain, and turns guest conversation into structured operational clarity for the property team.

​
Product Line

HelloLucia, LLC now owns three major product lines: 
Lucia AI - Operator / Owner-Facing OS
Lucia AI - Public / Guest-Facing Concierge
Eval Labs - Evaluation + Regression System
Guest-facing Lucia is not simply a chatbot. She is a front-of-house teammate connected to operational truth. The operator-facing Lucia OS remains the calm operating partner for owners and property teams. Guest-facing Lucia is the warm public concierge surface that can help, collect claims, and escalate structured signals without violating booking privacy. Eval Labs is the proof and regression system for both surfaces.

​
Current Implemented State

Current guest-facing Lucia implementation recorded by this Canon milestone: 
Product milestone: Guest Agent v0.1.0 - Guest Identity + Magic-Link Lab
Current live proof: Controlled Reservations + Magic-Link Verification Loop
GitHub repo: hello-lucia/lucia-guest-agent
Local path: /Users/avivhadar/Desktop/lucia-guest-agent
Live guest-facing route: https://guest.hellolucia.ai/
Live guest reservations route: https://guest.hellolucia.ai/reservations
Guest Agent lab route: https://lucia-guest-agent.netlify.app/lucia-lab/
Model selection: VV_AI_MODEL
Current requested model doctrine: GPT-5.5
Visible page identity: Guest Agent build tag is visible in the lab
Current Guest Agent build evidence: 51a47fb
This is live-development product truth. It is not a full production-readiness claim.

​
Guest Product Versioning

Current guest-facing product milestone: 
Guest Agent v0.1.0 - Guest Identity + Magic-Link Lab
Definition: 
first working guest-facing Lucia lab
GPT-5.5 guest-facing concierge
identity orientation handshake
booked-guest claim collection
claim fragment memory
Engine candidate lookup
Resend magic-link verification
verified session state
verified-session recognition after magic-link click
resend/status intent split for guest verification
safe verification_expires_at metadata in pending guest-agent state
controlled/test guest reservation creation with owned/test email
Engine seed booking persistence
Guest Agent /reservations availability calendar using Engine truth
server-side Guest Agent signing boundary for seed booking requests
Admin calendar visibility for generated seed bookings
guest operational signal bridge
Admin Signal Stream visibility foundation
Versioning boundary: 
commit tag = engineering truth
product version = milestone/product truth
The guest-facing UI should eventually show both: 
Guest v0.1.0 · <commit>

​
What Changed

Guest-facing Lucia is now a distinct major product surface inside the Canon. Current implemented surface: 
Villa/Lucia-style lab page created and polished
editorial visual system: Canela, nucleus divider, black top bar, refined chat card
guest identity orientation lives inside Lucia's first message
identity orientation must be selected before normal chat begins
generated orientation prompt appears in the composer
guest sends the orientation prompt
identity buttons disappear after orientation
normal conversation begins
The interaction should feel like Lucia orienting herself, not like a form.

​
Completed Reservations + Verification Loop

The completed live-development proof now connects: 
Guest Agent /reservations
Engine seed booking truth
Admin calendar booking visibility
guest-facing magic-link verification
verified guest session
booking-specific guest planning
This remains a controlled seed/test reservation loop. It is not a public booking engine, payment system, Lodgify replacement, auth system, or production OTA integration.

​
Identity Orientation Options

Guest-facing Lucia begins by asking the guest to orient the relationship: 
I'm already booked
I'm joining someone's stay
I'm planning a trip
Just exploring
These are not decorative buttons. They are the first step in privacy-safe context collection.

​
Product Doctrine

Guest-facing Lucia may help before verification. Guest-facing Lucia may collect claims. Guest-facing Lucia may not expose booking-private details or mutate booking records until identity/linkage is verified or operator-linked. Core public-facing doctrine: 
helpful first
privacy-safe always
claims are claims until verified
service overlap is never identity evidence
operator linkage is required before unsafe attachment
Guest-facing Lucia should remain: 
warm
friendly
welcoming
capable
hospitality-native
privacy-safe
helpful first, careful with verification
Guest-facing Lucia must not become: 
robotic
procedural
generic SaaS
cold privacy language
a form disguised as chat

​
Guest-Facing Lucia Eval Track

Eval Labs now needs a first-class Guest-Facing Lucia Eval Track separate from operator-facing Lucia evals. Purpose: 
Manual testing cannot cover every possible guest phrasing.
Eval Labs must stress-test guest identity, verification, privacy, tone, and guest-to-operator routing at scale.
The track must cover identity orientation, booked-guest claim parsing, claim fragments across turns, weak vs strong claims, ambiguous/no-match cases, magic-link eligibility, verification-email privacy, token consume/replay/expiry, verified session state, guest operational signals, Admin Signal Stream visibility, Focus Ops no Luca/Nora drift, and warm hospitality tone.

​
Knowledge Center Map

Start here, then read:

​
Current Boundary

Implemented does not mean production-hardened. Current non-production gaps include: 
automated testing of guest verification combinations
Eval Labs guest identity battery
Admin guest signal review/link surface
production booking engine/payment/OTA integration
owner/operator-configured reservation rules
durable persistence for guest signals and verification state
rate limiting / replay / spam hardening
operator-linked booking verification
inquiry record support
guest-of-guest verification paths
production privacy/consent copy
Villa Valentin launch hardening
Canon should record implemented state, doctrine, and roadmap separately.