Built on Supabase. Designed for scale.
Atlantis One is engineered as a layered, real-time, multi-tenant platform on Supabase — PostgreSQL at the core, Row Level Security for isolation, Realtime for live updates, and an AI layer compatible with OpenAI, Anthropic, and Azure OpenAI.
Presentation → Application → Supabase → PostgreSQL → AI.
Each layer has a clear responsibility. Data flows down to a shared PostgreSQL core and back up as real-time updates, analytics, and AI-driven recommendations.
Presentation Layer
Mobile-first apps for frontline, location managers, and field leaders — plus a web console for HQ and executives.
Application Layer
The execution engine and business logic that turn strategy into structured, trackable work across every location.
Supabase Services Layer
Managed Supabase services powering auth, real-time updates, file storage, and serverless edge functions.
PostgreSQL Data Layer
A multi-tenant PostgreSQL schema with Row Level Security enforcing the organization → region → district → location hierarchy.
Analytics / AI Layer
One AI and analytics that surface risks, draft plans, and benchmark performance — compatible with OpenAI, Anthropic, and Azure OpenAI.
The managed services that power Atlantis One.
We don't reinvent infrastructure. We build on Supabase's managed, battle-tested services so your team gets enterprise reliability without enterprise overhead.
PostgreSQL
Relational data layer (Supabase)
Supabase Auth
Identity, SSO, MFA, magic links
Supabase Realtime
Live updates across the estate
Supabase Storage
Photo, video & evidence vault
Edge Functions
Serverless business logic
Row Level Security
Multi-tenant data isolation
A multi-tenant PostgreSQL schema.
Every domain of the operation — tenancy, execution, verification, communication, learning, and intelligence — has its own tables, all sharing the same organization-scoped, RLS-protected core.
Tenancy & Identity
- organizations
- people
- location_nodes
- teams
Functional Roles & Permissions
- functional_roles
- permissions
- role_permissions
Execution
- tasks
- task_assignments
- store_readiness_projects
- store_openings
- assets
- asset_inspections
Verification
- audits
- audit_responses
- corrective_actions
- incidents
Communication & Knowledge
- communications
- messages
- announcements
- knowledge_base_articles
- sops
Learning & Engagement
- training_courses
- course_completions
- recognition
Intelligence & Delivery
- performance_metrics
- dashboards
- notifications
Row Level Security, by hierarchy.
Every query is scoped by the user's position in the organization → region → district → location hierarchy. Users only ever see the data they're authorized to see — enforced at the database, not the application.
- RLS policies are enforced in PostgreSQL — impossible to bypass from the app layer.
- A district manager never sees another district's stores, even by accident.
- Multi-brand and multi-region tenancy on the same secure foundation.
Organization
Top-level tenant boundary. Data never leaks across organizations.
Division
Divisional leaders see every region, district, and location beneath their division.
Region
Regional leaders see only their region's locations and metrics.
District
District managers are scoped to their district's stores.
Location
Location teams see only their own store's execution data.
Import your org from the location lens, the people lens, or both.
Atlantis One models every business as two reconciled hierarchies. The location lens maps where work happens; the people lens maps who is accountable. Row Level Security derives each user's visible scope from the join of the two — so the structure you import is the structure that enforces access.
Location Lens
Where work happens
Organization
The tenant root — one per business.
Division
Brand, format, or country grouping.
Region
Geographic cluster of districts.
District
A field leader's span of stores.
Location
A single store or site.
Organization → Division → Region → District → Location
People Lens
Who is accountable
Chief Retail Officer
Sees the entire organization.
Divisional Manager
Scoped to a division.
Regional Manager
Scoped to a region.
District Manager
Scoped to a district's stores.
Store Manager
Attached to one location.
Assistant Store Manager
Attached to one location.
Employee
Attached to one location.
CRO → Divisional → Regional → District → Store Mgr → ASM → Employee
Two lenses, one source of truth
The location lens maps where work happens; the people lens maps who is accountable. Both resolve to the same RLS scope.
Span of control drives visibility
A field leader's span_location_node_id determines exactly which locations — and only those — they can see and act on.
Store-level isolation by default
Employees, ASMs, and store managers see only their own store and the tasks assigned to it. No configuration required.
Import from either lens
Upload a location org chart, a people roster, or both — the platform reconciles them into a single secure hierarchy.
How span of control becomes visibility
Each person carries a span_location_node_id. A district manager's span is a district node — they see that district and every location beneath it. A store manager's span is a single location — they see only that store. The CRO's span is the organization root — they see everything.
Employee / ASM / Store Mgr
Their location only
District Manager
Their district's stores
Regional / Divisional Mgr
Their region / division
CRO / Org Admin
Entire organization
Eight roles, scoped to the right data.
From the platform-level SuperUser to read-only auditors, every role sees exactly what it should — and nothing more. Only SuperUser crosses tenant boundaries; every other role is scoped to its own organization.
SuperUser
The only platform-level role. Full access to the entire platform across every organization and tenant — reserved for Atlantis One operators.
Scope: All organizations (platform)
Organization Admin
Full control of their organization's locations, users, standards, and roles. The tenant master — scoped to their own organization by RLS.
Scope: Entire organization
Regional Leader
Visibility and action across every district and location in their region.
Scope: Region
District Manager
Risk-prioritized visibility and coaching across their district's locations.
Scope: District
Location Manager
Runs a single location's execution plan, tasks, and team.
Scope: Single location
Department Manager
Scoped to a department or zone within one or more locations.
Scope: Department
Frontline Employee
Executes assigned tasks, walks, and learning on the floor.
Scope: Assigned work
Read Only User
Auditors and stakeholders with view-only access to permitted data.
Scope: Per policy
What you can see is not what you can do.
Atlantis One separates two concerns legacy platforms conflate. Position decides which data a user can see; functional role decides what they can do with it. The two are independent — a Store Manager (single-store visibility) can hold an Editor role (broad capabilities), while a District Manager (district visibility) might hold a custom, permission-limited Manager role.
Data visibility
Position
Encoded in people.role (SuperUser → Employee) and resolved by span_location_node_id. Decides which locations, people, and records a user can SEE.
visible_location_nodes() + RLS
Capabilities
Functional Role
Encoded in people.functional_role_id (SuperUser / Admin / Editor / Manager / Associate). Decides what a user can DO within their visible scope. SuperUser is the only platform-level role; Admin and Editor are organization-scoped.
has_permission() + role_permissions
SuperUser
Platform roleThe only platform-level role. Full access to the entire platform across every organization and tenant — reserved for Atlantis One operators. Not customizable, not duplicable, not assignable to organization members. has_permission() always returns true.
Admin
Organization roleThe organization-level master role. Full access to everything within the Admin's own organization — every module, setting, and role. Not customizable, not duplicable. has_permission() always returns true inside its org; RLS enforces the tenant boundary.
Editor
Organization roleA customizable organization-level role. Admins tune its permissions and duplicate it to spawn specialized editorial roles — Content Editor, Audit Editor, Communications Editor — within their org, without starting from scratch.
Manager
Base roleThe building block for custom roles. Duplicate it, rename it, and grant any subset of permissions to model any role your organization needs — as many copies as you want, per organization.
Associate
Base roleThe frontline execution role — complete assigned tasks, report incidents, take training, give recognition. The default capability set for store-level users.
How capabilities are enforced
Every person carries a functional_role_id pointing to a role in the functional_roles table. That role's permissions live in role_permissions. The has_permission('module.action') function resolves the current user's role and returns true if the permission is granted — or automatically for SuperUser (platform-wide) and Admin (within their org). Write policies combine visibility and capability: a user can only insert a task if they can see the location AND hold the tasks.create permission.
1 · Duplicate
An Admin clones the Manager (or Editor) base role and renames it — e.g. 'Field Coach'.
2 · Tune
Grant or revoke any of 50+ granular permissions across every module.
3 · Assign
Attach the custom role to any number of people, independent of their position.
Identity, your way.
Support for the auth methods your enterprise and frontline already use — from magic links to Microsoft Entra ID and MFA.
An AI layer built for choice.
The One AI layer is compatible with OpenAI, Anthropic, and Azure OpenAI — so you choose the model that fits your security, residency, and cost requirements. Enterprise customers get isolated model contexts and data residency controls.
See the architecture on your operations.
Get a technical walkthrough of how Atlantis One's Supabase foundation fits your IT, security, and compliance requirements.