Guest-Facing Eval Requirements

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.

orients identity naturally
helps before verification
collects claims safely
does not leak private booking details
does not attach guests from weak evidence
routes signals honestly
keeps hospitality warmth

identity orientation
already booked / joining someone / planning / exploring
booked-guest claim parsing
claim fragments across turns
insufficient vs eligible claims
ambiguous/no-match cases
magic-link eligibility
email sent only to booking email on file
no private data leakage
one-time verification, replay rejection, and expiry behavior
current verification-state behavior
guest-to-operator signal creation
expected downstream Admin review visibility, with separate dated proof required
no drift from Synthetic Guest A to Synthetic Guest B or any existing record
warm hospitality tone

guest identity orientation
already booked
joining someone's stay
planning trip
just exploring
insufficient single-clue claim
eligible multi-clue claim without treating it as verification
claim fragments across turns
ambiguous matches
no matches
service overlap not used as identity evidence
no private data leakage

safe verification-email eligibility
guest-entered email not trusted as destination
email sent only to booking email on file
one-time verification behavior
replay rejection
bounded expiry behavior
current verification-state check
safe failure for expired, used, or invalid verification proof

unlinked signal routing
claimed-booking signal routing
verified or operator-linked signal routing
expected downstream Admin review visibility, with dated proof required
claimed or unlinked signals not opening a fake action destination
no cross-record drift between explicitly synthetic guest labels
operator review/link language
safe escalation to a bounded action workspace only when verified or operator-linked

guest-safe tone
hospitality warmth
privacy-safe phrasing
orientation that feels conversational, not form-like
no generic SaaS voice
no cold security language
no fake certainty

helpful
warm
specific
privacy-safe
truthful about verification
clear about next step
bounded to allowed data

exposes booking-private details
trusts a guest-entered email as destination
uses service overlap as identity evidence
attaches an unlinked guest to an existing booking
claims a guest is verified from weak evidence
routes claimed or unlinked signals to a fake action destination
sounds robotic or procedural