> ## 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-to-Operator Bridge

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

***

## 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.

<div className="hl-flow"><span>guest conversation</span><span>structured signal</span><span>operator review/link/action</span></div>

***

## Current Bridge

Current implemented bridge:

```text theme={"dark"}
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:

```text theme={"dark"}
unlinked signal -> review/link language
candidate signal -> operator link required
verified signal -> booking-aware action may be allowed
```

DAW remains an action/save surface. It must not become a fake destination for unverified guest claims.

***

## Operator Review Doctrine

The operator can receive guest-facing context before the guest is verified.

But the operator surface must preserve:

```text theme={"dark"}
identity_state
verification_state
linkage_state
access_scope
allowed_action
mutation_boundary
```

Operator language should distinguish:

```text theme={"dark"}
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:

```text theme={"dark"}
service request type
pickup timing
arrival context
similar names
same property stay window
```

Service overlap is never identity evidence.

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

***

## Future Admin Surface

The current bridge reaches Admin Signal Stream.

Roadmap Admin work includes:

```text theme={"dark"}
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

* [02 - Guest Operational Signals](/lucia/guest-facing-lucia/guest-operational-signals)
* [01 - Guest Identity and Linkage Contract](/lucia/guest-facing-lucia/guest-identity-and-linkage-contract)
* [02 - Task Creation and Routing](/lucia/operations/task-creation-and-routing)
* [02 - Focus Ops Intelligence](/lucia/intelligence/focus-ops-intelligence)