Purpose
Use this page to identify the product and layer that owns an observed behavior before proposing a change. Start with current source evidence, preserve the boundaries between products, and avoid creating a second source of truth in the surface that merely displays the behavior.This is a public ownership and diagnostic map, not runtime proof. Verify current-runtime claims in the owning implementation and deployment evidence before changing canon.
Source-first routing order
Before proposing a change:- Name the product surface where the behavior is observed.
- Identify the layer that owns the behavior, not merely the layer that displays it.
- Classify the problem as documentation, UI and presentation, runtime intelligence, authentication and durable state, evaluation and evidence, or future architecture.
- Verify the current implementation and deployment identity in the owning system.
- Change the smallest owning layer that can correct the defect without duplicating authority.
- Add regression evidence in the owning test or evaluation surface when behavior changes.
Public ownership map
Ownership boundaries
Lucia Library
Start in the Library when the task changes canonical documentation, doctrine, or the published ownership map. Verify runtime statements in the owning application before updating the Library. A documentation mismatch does not make the Library the runtime owner.Lucia Admin
Start in Admin for visible operator UI, presentation, interaction, or client request-shaping defects. If the browser request is correct but the returned behavior is wrong, investigate Engine instead of teaching Admin to synthesize Engine truth.Lucia Engine
Start in Engine for operator behavior, classification, routing, prompts, model execution, runtime provenance, or Fieldwork intelligence. Do not infer an effective deployed model from a source default alone; environment resolution and same-request provenance (provider, resolved model, request id, latency, fallback) determine runtime truth. Since 2026-09-04 the gateway serves two providers; the model id names the provider, and a pin on one task is not a fleet default.The Lucia Algorithm
Start on the Algorithm’s own records when the question is what should rank, when, and why. Its two files are the Algorithm Engineer’s alone; the Scientist proposes, the Evaluator measures, and no change merges without the plain-English before/after and the replay table (instruments before intelligence). Copy that the Algorithm serves is owner language and changes through the same gate with deltas confined to display fields. The Algorithm’s weights, thresholds, and reason-code semantics are proprietary and are not published in this Library.lucia-world
Start in lucia-world only when the question is about the synthetic Villa itself: its scenarios, its clock anchor, or the doors it plays through. It never explains a production behavior, and it is never a surface an owner sees.Lucia Fieldwork App
Start in the Fieldwork App for employee-facing conversation, composer, mobile layout, form synchronization, device recovery, or submission experience. The App does not own server authority or a production model version.Lucia Fieldwork API
Start in the Fieldwork API for authentication, property scope, durable conversation or item truth, replay behavior, media coordination, recurring work, submission delivery, or Engine relay. Do not move API authority into the browser or duplicate Engine intelligence in this layer.Guest Agent
Start in Guest Agent for guest conversation behavior, booking verification, guest UI, or guest-specific generation configuration. Guest Agent owns its generation configuration independently; a model name shared with Engine does not imply inheritance.Eval Labs
Start in Eval Labs for suites, runners, roles, persisted run or review evidence, analysis, and runtime verification. Eval Labs proves and records behavior; when evidence identifies a product defect, correct the owning runtime rather than compensating inside the evaluator.Diagnostic routing examples
Lucia chose the wrong operator response
Start in Engine. Inspect the classification and routing inputs before changing output wording.Lucia chose the right response but phrased it badly
Start in Engine’s Focus composition (one composition from the house pack on Fable since 2026-09-04; the older refinement pass left the served Focus route on 2026-09-04, Focus answers from one brain, ALGO-40). Do not patch Admin copy unless Admin rendering introduced the defect. If the words are the Algorithm’s served copy, it is an owner-language change through the Algorithm’s gate.A model should change
First identify the runtime. Engine and Guest Agent own separate model configurations. Never apply one product’s model decision globally by name. Inside Engine, name the task: the provider follows the model id per task, the Fieldwork conversation stays on GPT, and a fleet-wide default flip is a founder decision (Fable is Lucia’s voice, ALGO-39).Focus Ops looks or behaves wrong in the browser
Start in Admin. Cross into Engine only after proving the browser request or rendering is not the source of the defect.Fieldwork conversation or submission is wrong
- Visual, composer, local recovery, or submission UX: Fieldwork App.
- Authentication, property scope, durable conversation or item truth, replay, media, or delivery: Fieldwork API.
- Prompt, structured intelligence, guardrail, model, or provenance: Engine.
- Operator-facing maintenance presentation: Admin.
Evidence is missing or unclear
Start in Eval Labs when the problem is evaluation execution, run and review evidence, analysis, or runtime verification. Start in the owning runtime’s tests when the behavior contract itself is wrong. Do not turn an evaluator workaround into product behavior.Guest-facing Lucia is wrong
Start in Guest Agent. Cross into Engine only when evidence points to a shared booking-verification or operational-signal contract, not merely because both systems use Lucia branding.Anti-drift rules
Do not
- assume ownership from the surface where an error appears
- use Lucia Library as runtime proof
- use Admin to synthesize or override Engine truth
- use the Fieldwork App as server authority
- make the Fieldwork API a second intelligence layer
- infer Guest Agent model ownership from Engine configuration
- make Eval Labs compensate for a runtime defect
- treat package versions, folder names, cached artifacts, historical staging claims, or old test totals as release identity
- assume a model swap fixes classification, truth selection, or routing
- change the Algorithm’s files outside the Algorithm Engineer’s lane or without the before/after
- treat lucia-world as a product surface or its records as production truth
- read a Linear status as evidence of deployed behavior
Do
- recover current context from owning sources first
- distinguish current truth, dated history, plan, and unknown
- verify deployment claims by exact build identity and owning control-plane evidence
- use same-request provenance for effective model claims
- patch the smallest correct layer
- preserve stable contracts and unrelated work
- add focused regression evidence when behavior changes
- keep doctrine, implementation, evaluation, and presentation connected without merging their ownership
Two-step diagnostic default
For a new or ambiguous problem:- identify the owning product and controlling layer;
- inspect or change the smallest high-value seam allowed by the task.