Lucy Frontline — how the platform works

The question we hear most from IT: “Why not Teams or WhatsApp?” The answer is boundaries and operations — not chat features.

And the lifecycle: when employment ends, offboarding closes access — data does not walk out the door with the private phone.

Each hotel or workplace is its own tenant — the primary security boundary. A person works through a workplace-specific employee identity, and visibility follows membership: if you are not a member of a space, you do not see it. Beyond server logic, data is protected by database Row Level Security and permission-controlled storage policies — several independent layers, not one.

Honest limitation: there is currently no self-service switch to disable individual AI features or select an AI provider per feature — this is handled per customer agreement.

Lucy Frontline exposes a REST API and an MCP (Model Context Protocol) surface for automation. All integration calls pass through the same tenant, membership and permission resolution as the user interface — an integration acts as an identified employee in an identified tenant, never as a global superuser.

Cloud provider and region

Application tier: DigitalOcean App Platform, Frankfurt (Germany). Data platform: Supabase, Ireland (eu-west-1).

Which models are used, and for what

AI is used for bounded features: task analysis and employee import (OpenAI — currently gpt-4o-mini and gpt-5.6-sol respectively), channel avatars (OpenAI Images — currently gpt-image-1-mini) and translation (Google Cloud Translation). Model names are operational configuration and may change within the contracted processing region.

Region and training

Current OpenAI and Google Translation endpoints are global — we do not describe today's AI processing as EU-only. OpenAI does not use API data for training by default; abuse monitoring may retain content up to 30 days. EU endpoints are planned, and for customers requiring Swedish processing we can scope a solution using open models on Swedish infrastructure — planned, not deployed.

Human oversight

AI never grants permissions and makes no decisions about employees. Employee-import output is always human-reviewed before use, and the prompt contract prohibits invented contact details, roles and permissions. Frontline's AI features do not evaluate employee work performance.

Logging and transparency

Execution logs record provider, model, feature and outcome — but never raw prompt content or raw model responses.

Your own model contracts (Bring Your Own Tokens)

The prompt framework is provider-independent by design — provider and model are configuration, not architecture, and adapters exist for more than one provider. For customers who already hold their own model contracts and committed capacity, for example Azure OpenAI or Bedrock, we can scope a setup where Lucy's calls run against your endpoints instead of ours. It does not exist as self-service today; we set it up per customer. The work involved is per-tenant provider credentials and prompt activation — not rebuilding the platform.

Admin roles are tenant-scoped — there is no “global hotel manager”. Visibility follows membership, shared spaces are invite-only, and all authorisation is resolved server-side. Automation credentials are bound to a tenant, workspace, actor and explicit scopes (messaging, tasks, KPIs).

Capacity is scaled manually today, with an internal availability objective of 99.9% — a target, not a contractual SLA. The platform is load-tested with 100 simultaneously active authenticated users in real read and write flows. The production database has point-in-time recovery with a seven-day window. Error and performance telemetry is ingested in Germany.