Skip to main content
Focus Ops is Lucia’s primary operator-facing intelligence surface. It turns operational noise into a calm, ranked next move.

​
Definition

Focus Ops is not a search box. Focus Ops is not a generic assistant. Focus Ops is the operator relief layer. It answers:

​
Current Runtime Behavior

Focus Ops receives operator prompts through the Admin UI and routes them to the Engine. Current canonical Focus Ops route:
Eval Labs should validate v0.1.3.6 against:
v0.1.3.6 is not promoted to staging yet. Staging promotion waits until the Eval Labs dev baseline is captured and reviewed. Eval Labs production is currently routed to this Development endpoint. The routing correction was live-verified on 2026-07-10; that correction does not itself promote the Engine to Staging. The Engine returns a stable response contract:
Core data includes:
Lucia Engine v0.1.3.6 uses gpt-5.6-sol (GPT-5.6 Sol) as the default model, with Lucia JSON gateway calls running through the OpenAI Responses API.

​
Runtime and model provenance

The same /admin/operator-focus response exposes the evidence needed to interpret how the answer was produced. The stable top-level contract remains ok / data / meta.
The gateway captures provider-returned response.model as task-level resolved_model. Per-task records also state whether the model call was attempted, a response arrived, parsing succeeded, fallback was used, and the task status. Truthful path interpretation:
Model invocation does not by itself prove provider success; task evidence records whether a response arrived, parsing succeeded, and a provider-resolved model was captured. Provider failure can combine model invocation with fallback, while client-disabled/no-attempt behavior can combine a deterministic path with fallback. The configured default is not proof that a model ran for a particular prompt. A 200 response proves neither invocation nor provider success; provenance owns those distinctions. The owner-only Eval Labs runtime verification on 2026-07-10 returned Verified with configured and provider-resolved model gpt-5.6-sol, model_invoked=true, deterministic_path=false, and fallback_used=false. This is dated verification evidence, not a claim about every historical or future request. 06 - Semantic Conversational Intent Assist is live in Focus Ops. It is semantic lightweight utility and conversational intent classification, not phrase patching. Current live-dev runtime evidence:
The current product pillar is:
Focus Ops now participates in the full Admin/Engine loop:
Calendar and Booking Pulse provide booking-time reality. Signal Stream provides active attention context. Focus Ops reasons over that verified context and explains the safest operator-facing next move. Current payment attention boundary:

​
Workspace Sidebar and Shared Conversation

Focus Ops is now shared across Dashboard embedded mode and Lucia Workspace Sidebar mode. Current Development truth:
The operator should be able to keep the same Lucia conversation alive while moving through Dashboard, Calendar, Signal Stream, DAW, Full Booking, Bookings, Maintenance, Concierge, Tasks, and Reconciliation.

​
Workspace Context Awareness

Engine normalizes active_context.workspace safely and uses it to answer workspace-orientation and next-step prompts. Supported prompt families include:
Explicit prompt subject still wins over page context. If the operator asks about Nora’s payment from Calendar, Nora’s payment remains the subject; Calendar context should not overwrite it. Lucia must not expose raw metadata language to the operator:

​
Calendar-Rooted Context

Focus Ops is not a chatbot bolted onto Admin. Focus Ops is the reasoning/conversation layer above booking reality:
The deterministic layer owns those facts. GPT-5.6 Sol may interpret them, explain them, and soften the operator-facing language, but it must not invent them.

​
Primary Output Goal

Focus Ops should produce:
It may include supporting context, but it must not bury the lead.

​
Focus Ops CTA Handoff Contract

  • Workflow-specific Focus Ops CTAs must route to the exact workflow surface where the work gets completed.
  • Engine owns the recommended_action destination contract.
  • recommended_action.label, recommended_action.path, recommended_action.destination.path, destination.kind, and destination.action_view must stay aligned.
  • Workflow CTAs should resolve through the Dynamic Action Workspace contract.
  • CTA label is copy. Structured action intent and metadata are routing truth.
  • Every structured Focus Ops CTA should route to a focused operator action workspace.
  • /ops/actions is the default universal Dynamic Action Workspace.
  • Default route:
    • structured Focus Ops action → /ops/actions
  • Specialized pages may remain available as supporting or future-specialized surfaces, but they are not the default Focus Ops CTA destination.
  • Generic booking overview is fallback only.
  • The operator should never click a Lucia CTA and have to hunt for the work.

​
Resolver Matrix

The Resolver Matrix is the safety/routing mechanism that proves messy, infinite CTA possibilities resolve into structured, actionable workspace destinations. Plain-language definition:
Infinite CTA languageResolver Matrixfinite Action Workspaceoperator can actually do the thing
The Resolver Matrix protects against a common failure: the label sounds specific, but the route lands somewhere generic or unusable. Resolver proof must check the structured destination, not just the CTA text.

​
Dynamic Action Workspace

Dynamic Action Workspace is the universal operator-facing workspace where structured Lucia CTAs land. Its rule:
Dynamic Action Workspace at /ops/actions is the default destination for structured Focus Ops actions. It should render the actionable object, context, and next operator controls needed to do the work. Specialized pages may remain available as supporting or future-specialized surfaces, but they are not the default Focus Ops CTA destination.

​
Scoped Entity Routing

Named guest, service, or request prompts must override generic ranking. Examples:
If the operator names a concrete entity, Lucia should resolve that entity first and rank inside that scope. It should not silently substitute the current global top item.

​
Signal Stream Attention Rule

Signal Stream is one coherent intelligent stream shaped by:
Newest meaningful attention event wins:

​
Active Context and Prior Recommendation Memory

Focus Ops now supports active_context from Signal Stream Chat. When the operator starts from a Signal Stream card, the current signal can scope the conversation before generic ranking runs. Focus Ops also keeps prior recommendation memory for short follow-ups:
Short follow-ups resolve over verified prior recommendation context instead of guessing from the latest global top item. Newest verified concrete recommendation replaces prior recommendation memory. Clarifying, informational, or non-concrete replies should not overwrite it. Focus Ops also keeps prior offer context. A short response like “yes” should confirm the last offered action when that action is verified in context, instead of falling back to generic triage. Filler and preamble text should not become fake entity context. “Understood? Anything after that?” must not cause Lucia to treat “Understood” as a guest or booking subject. Next-step prompts such as “What’s next?”, “Now what?”, and “What should I handle next?” should resolve through workspace context, prior recommendation context, and saved DAW workflow state before generic ranking.

​
Guest Signal Boundary

Guest signals may seed Focus Ops context. Focus Ops must preserve the identity/linkage contract before it reasons over guest-facing signals:
Candidate and unlinked guest signals must not drift into similar existing bookings. Service overlap is never identity evidence. Airport pickup overlap must never attach an unlinked guest to Luca/Nora or any existing guest. Focus Ops may explain the guest signal to the operator. It must not claim that the guest is verified, attached, or safe for DAW routing unless the signal is verified or operator-linked.

​
Saved DAW Workflow Awareness

DAW saved state can enter Focus Ops through active_context.workspace. Lucia may recognize that a workflow step was saved, but must preserve unresolved operational truth:
When payment DAW has known guest identity, Lucia should use it:
not:
Current payment DAW proof:

​
Payment Truth Attention

Current implemented Development behavior:
Deferred behavior:

​
Reminder Semantics

“Remind me” creates real Engine reminder state. When due, Lucia resurfaces it. “Got it” means the operator saw the reminder. It does not mean the underlying issue was resolved. No reminder/action copy should imply handled, resolved, notified, completed, or externally acted on unless verified by system state.

​
Example Good Output

Why it works:
  • names the issue
  • identifies urgency
  • connects timing
  • gives the operator a clear starting point

​
Example Bad Output

Why it fails:
  • no priority
  • no next move
  • creates more cognitive load

​
Ranking Signals

Focus Ops may consider:

​
Protected Prompt Families

Focus Ops now correctly handles prompt families such as:
These prompts should not be forced into generic triage or rejected as off-topic simply because they are short, social, or context-light. Lucia should read the human first, identify the purpose second, and preserve the boundary third.

​
Tone Requirements

Focus Ops must feel:
Focus Ops must not become open-domain ChatGPT. Even when the prompt is conversational, Lucia stays oriented toward operator guidance, scoped utility, and truthful boundaries.

​
Permission-Based CTA Rule

Lucia should not imply action was taken unless it actually was. Correct:
Incorrect:

​
Relationship to Maintenance Inbox

Maintenance Inbox creates structured maintenance signals. Focus Ops must eventually route those signals into priority reasoning so that real-world maintenance reports affect what Lucia says matters most. Current state:

​
See Also