At a glanceThe Operations layer describes how Lucia should turn real-world signals into structured work for the operator. Current implementation claims on this page are bounded to the dated evidence below.
Operations Layer Purpose
Operations is where Lucia becomes useful. It connects:Source-verified operational center — 2026-08-12
The accepted Admin and Engine Development source implements this primary operator loop:Calendar / booking spineBooking PulseSignal StreamLucia Workspace / Focus with LuciaDynamic Action Workspace save surfaceReminder resurfacing
Calendar is the root operational reality in the product doctrine. The audited source connects Calendar and Booking Pulse to the Engine booking source, and implements Signal Stream, Focus Ops, and Dynamic Action Workspace as operator surfaces around that truth.
The audited Admin source implements Lucia Workspace as a context-aware reasoning surface beside the operator, including a shared Focus Ops context across the embedded and workspace presentations. This is source and Development-deploy evidence, not proof of a specific authenticated operator session.
Durable cockpit doctrine:
Signal StreamLucia Workspace / Focus with LuciaDynamic Action WorkspaceReminder resurfacing
Maintenance Inbox and Signal Stream are implemented in the audited Admin and Engine source. Signal Stream is the broader attention surface for operational state, reminders, dismissals, and ordering. The source implementation does not by itself prove that an external provider delivered a message or that an operator completed a live workflow.
Fieldwork item thread — verified 2026-08-19
After an employee explicitly submits an item, the employee and operator can continue in one durable thread attached to that item. The Maintenance Inbox renders employee and operator messages as one chronology, records operator seen state, and keeps the existing reply composer. Initial loading is calm rather than briefly presenting an empty or contradictory thread. The employee sees matching Sent, Seen, unread, and Needs your reply state in Fieldwork. A dismissed item keeps its history but locks the employee composer. V1 is online-only, has no push-notification claim, and keeps Lucia out of the message loop. The operator’s displayed sender name must come from a real Clerk identity. See Messages and replies. The intended maintenance-intake channels are:guest conversationidentity orientation / claim collectionbounded concierge signalauthenticated server contractEngine intakeoperator review surfaceoperator review/link/action when safe
The payment-truth doctrine separates the following owners and evidence types:
Property payment policy shapecalendar/booking temporal truthStripe movement truthLucia Core durable ledgerLIEA payment attention judgmentAdmin read-only payment truth rendering
Evidence boundaries
See Current System State for the fleet-wide evidence ledger and freshness limits.
Operator workflow doctrine
This flow is durable product doctrine, not fresh end-to-end provider, payment, or authenticated operator proof.Booking reality anchors timeSignal arrivesCalendar and Booking Pulse give temporal contextSignal Stream shapes attentionLucia Workspace / Focus with Lucia helps the operator decide in contextResolver Matrix proves the action routeDynamic Action Workspace opens the focused action/save workspaceFull Booking Page remains the record/review destination for booking clicksReminder state can bring work back when dueGuest signals can enter operator review without pretending linkage is verifiedPayment truth can enter operator review without pretending Admin owns or mutates payment state
Operations Principle
Lucia should not simply collect reports. Lucia should turn reports into:See Also
- 01 - Maintenance Workflow
- Fieldwork Messages and replies
- 02 - Task Creation and Routing
- 06 - Calendar and Booking Spine
- Lucia Payment Truth Foundation
- 05 - Guest-to-Operator Bridge
- 02 - Guest Operational Signals
- 04 - Lucia Workspace OS Milestone
- 01 - Ingestion Layer
- 02 - Focus Ops Intelligence