The guest-to-operator bridge is the contract that lets public guest conversation become operator-visible clarity without pretending every guest is verified or every request is actionable.
Product Role
Guest-facing Lucia is a front-of-house teammate.
Operator-facing Lucia is a calm operating partner.
The bridge between them must be structured, signed, privacy-safe, and honest about verification.
guest conversationstructured signaloperator review/link/action
Current Bridge
Current implemented bridge:
guest-facing Lucia generates operational_signal v0
guest agent signs and POSTs signals server-side to Engine
Engine accepts signed guest signals through /v1/guest/signals
Engine persists guest signals safely
Admin /admin/dashboard exposes sections.guest_signals
Admin Signal Stream renders guest signals
Guest signals can seed Focus Ops context
Routing Safety
Unlinked/candidate guest signals do not open fake DAW.
Linked/verified signals may eventually route to DAW when safe.
Current routing rule:
unlinked signal -> review/link language
candidate signal -> operator link required
verified signal -> booking-aware action may be allowed
Operator Review Doctrine
The operator can receive guest-facing context before the guest is verified.
But the operator surface must preserve:
identity_state
verification_state
linkage_state
access_scope
allowed_action
mutation_boundary
public guest signal
guest claim
candidate booking
verified booking
operator-linked booking
Focus Ops Drift Protection
Focus Ops was hardened so unlinked/candidate guest signals do not drift into similar existing bookings.
This matters most when two guests share:
service request type
pickup timing
arrival context
similar names
same property stay window
Future Admin Surface
The current bridge reaches Admin Signal Stream.
Roadmap Admin work includes:
guest signal review/link surface
operator-linked booking verification
clear audit trail for link decisions
safe escalation from guest signal to DAW when verified or operator-linked
See Also
