ATLAS · P4 · TENANT ONBOARDING · LIVE ON /admin · v3.1 STYLING

Tenant Onboarding

The path from nothing to a tenant that can trade. W0, W1, W3 and W4 are wired to the real employee API and write real rows — the checklist is read from GET /admin/partners/tenant/:id/onboarding, provisioning posts to POST /admin/partners/launch, grants post to POST /admin/partners/user/:id/scopes. W2 is still a drawing and is labelled as one. Every screen names the endpoint behind it.

ADMIN SESSION reading GET /admin/session… TENANT

W0 · Checklist Home

The launch checklist, as the platform measures it

NO TENANT SELECTED

Reading…

NOTES · Rationale

Every row is measured, not self-reported. The checklist comes from GET …/onboarding, which computes each step from real rows — accounts, events, tiers, branding, orders, payouts. Nothing on this screen can be ticked by hand, which is the point of it.
The evidence line is the step's receipt — 2 active accounts, last 2026-09-14, a named event. A done step with no evidence would be an assertion; the API returns evidence only for steps that are done.
A day count is only shown when a creation date was actually read (it comes from the roster row, not the checklist). No row, no "day N of 30" — the horizon is not invented to fill the space.
An unreadable checklist draws nothing. It prints the failure and no steps at all, because an empty list here would read as "nothing is done" — which is a different claim from "we could not ask".
Status glyphs only: ● △. Progress bar is single-series ELECTRIC over steps-done ÷ steps-total, a real ratio and labelled as one. Never red.

W1 · Provision

Provision a tenant, then its first venue

GATE 01 · PROVISION TENANT

Organisation name * 2–80 CHARS · BECOMES Tenant.name

Operator email * THE FIRST SIGN-IN ACCOUNT · ONE TENANT PER EMAIL

Initial password BLANK = GENERATED & SHOWN ONCE · TYPED = NEVER ECHOED BACK

Tenant kind THE ONLY THREE THE PROVISIONER ACCEPTS

Audit reason RECORDED ON THE PARTNER AUDIT TRAIL WITH YOUR EMPLOYEE NAME

SANDBOX TENANT — not a trading org

⚑ Removed — ATLAS does not record these Legal entity, tenant slug, currency and density profile have no column anywhere in the schema, so this form no longer collects them. Default table minimum and deposit % are not tenant-level either — Inventory.minSpend and Inventory.deposit are per-table, and deposit is absolute integer cents, never a percentage. They are set per table, after the venue exists.

⚑ TAKE-RATE NOT SET HERE · VENUE REPORTING ONLY, NEVER MARKETED

W1b · First venue · POST /admin/partners/tenant/:tenantId/venue

Venue name * 2–120 CHARS · IDEMPOTENT ON (TENANT, NAME) · A REPLAY RETURNS THE EXISTING VENUE UNCHANGED, IT DOES NOT RE-HOME IT

City

Timezone * IANA ZONE IDS ONLY · AN OFFSET (+05:30) OR ABBREVIATION (EST) IS REFUSED WITH 400 · DRIVES THE NIGHT BOUNDARY

⚑ NO TENANT IN SCOPE — PROVISION ONE ABOVE, OR PICK ONE AT THE TOP

POST /admin/partners/launch · POST /admin/partners/tenant/:tenantId/venue · both behind AdminGuard

NOTES · Rationale

Required fields carry an amber * — the alarm color's lightest weight, attention not blocking.
The form is the DTO. Every field maps to something LaunchPartnerDto accepts. Four fields that used to live here — legal entity, tenant slug, currency, density profile — had no column anywhere in the schema, and two more (table minimum, deposit %) are per-table, not per-tenant. They were removed rather than posted into a void: a form that accepts input it discards is the same lie as a fabricated number. The gap is printed on the form.
Provisioning is two writes, and the page never conflates them. The tenant + operator account land first; the first venue is a second call. If the first succeeds and the second does not, this screen says PARTIALLY PROVISIONED and names which half exists — it never shows a success state for half a tenant.
Timezone is load-bearing: it defines the night boundary the whole console pivots on, so the venue call requires a real IANA id. An offset or an abbreviation is refused by the API with a 400, and the refusal is shown verbatim.
The generated password is shown once. When you type one it is not echoed back — the API deliberately returns initialPassword: null rather than adding a copy of a live credential to a response.
Take-rate is deliberately absent from provisioning — ⚑ placeholder, venue reporting only. No rate marketing on an operator surface.

W2 · Connectors

Connector states — live · stub · expired

GATE 02 · CONNECT SOURCES

● LIVE · from the checklist read PARTNER APP DOORS FOR THIS TENANT

No tenant selected.

BELOW: ILLUSTRATIVE ONLY · NOT WIRED TO ANY ENDPOINT

◇ DRAWING · every row below is design, not state — no button here calls anything

Square · Payments & tabs

● LIVE · WEBHOOKS RECEIVING

SYNCED 2m AGO142 events today

Spotify · Taste graph

● LIVE · CONSENTED

SYNCED 1h AGOconsent on file

SoundCloud · Taste graph

△ STUB · NO KEY SET

Apple Music · Taste graph

△ STUB · NO KEY SET

Ticketmaster · Demand feed

● LIVE · 74 EVENTS SYNCED

VIA ATLAS GUEST FEEDra-cron · nightly

Eventbrite · Demand signals

△ STUB · NO KEY SET

Instagram · Marketing reach

△ STUB · SEEDED DATA

Stripe · Deposits & payments

● LIVE · WEBHOOKS RECEIVING

SYNCED 5m AGOholds + refunds

Klaviyo · Lifecycle & campaigns

● LIVE · SENDING

SYNCED 12m AGOflows active

Lightspeed · POS & inventory

△ STUB · SEEDED DATA

Toast · POS & tabs

● LIVE · WEBHOOKS RECEIVING

SYNCED 3m AGO98 events today

SevenRooms · Reservations

● LIVE · SYNCING

SYNCED 4m AGOreservations mapped

Resy · Reservations

△ STUB · SEEDED DATA

Tock · Reservations

△ STUB · SEEDED DATA

Google Calendar · Event feed

◐ AUTH EXPIRED · TOKEN LAPSED

NOTES · Rationale

Border style is the state — read it before any label.
Solid mint border = LIVE. Carries a recency stamp (SYNCED 2m AGO) so the operator trusts the data is fresh, not just connected once.
Dashed border = STUB · SEEDED DATA. The surface works from day zero on demo data; a cyan CONNECT action swaps seed for real. Cyan = the forward, opt-in action.
Amber solid = AUTH EXPIRED. Alarm's tinted-fill weight — the token lapsed, action needed, but never red. RECONNECT is the recovery path.
Seeded stubs mean a tenant is never blocked by an unconnected source — they go live on seed and upgrade in place.
No connector ever shows red — expired auth is amber, the strongest weight used here.
Klaviyo setup = create one flow per Atlas metric. Delivery is server-side events, never a list blast — Atlas fires a metric event per consented guest and your Klaviyo flow sends the message. Create a flow triggered on each metric you want live: Atlas Event Match, Atlas Regulars Lock-In, Atlas Winback, Atlas Crew Rebook, Atlas Loyalty Claim, Atlas Campaign. A metric with no flow simply does nothing — opt-in per message type. Profiles match on email / phone / external_id (the Atlas guest id).

W3 · Grants

Grant model — SEE is read, DO is write

GATE 03 · ASSIGN GRANTS · NO ACCOUNT SELECTED

ACCOUNT

Select a tenant, then an account.

0 scopes selected · no change

W3b · CONFIRM GRANT · WHAT CHANGES

GET /admin/partners/tenant/:tenantId (accounts + grantableScopes) · POST /admin/partners/user/:userId/scopes

NOTES · Rationale

The rows come from the API, not from this page. Every resource and every scope string is built from grantableScopes in the tenant read. The mock's six rows named scopes that exist nowhere in ATLAS — bookings:write, floor:manage, tenant:admin — and a grant screen that invents its own scope strings is worse than no grant screen at all.
SEE is the :read scope, DO is the :write scope, paired per resource family. Where the grant has read and no write — payouts — the DO cell reads ⊘ NOT GRANTABLE rather than showing a toggle that would 400. "We paid you" stays the platform's claim to make.
Each toggle maps 1:1 to exactly one scope string — no bundles, no implied permissions. The strings show on hover.
W3b confirms the DIFF, not the end state: what is being added and what is being taken away from this specific account, then the server's own answer — including its note that a change only lands when the partner next signs in, because the token already issued still carries the old grant.
Accounts this console must not edit say so instead of offering a broken editor: the platform's own bootstrap account, and any account holding scopes beyond the partner grant, which a save here would silently strip.
Toggle on = cyan (the enabling action); off = neutral gray. Never red for an off permission.

W4 · Data Contract

The data contract — and the gate to go live

GATE 05 · REVIEW DATA CONTRACT

◇ WRITTEN CONTRACT · policy, not a live reading of the wire

↓ FLOWS IN

● square · payments
● square · tab events
● spotify · taste (consented)
● ticketmaster · demand feed
● door · check-in scans

▲ FLOWS OUT

● venue-link · booking
● wallet pass · updates
● closeout · reconciliation
● promoter · settled receipts
● outcomes · pillar scores

⊘ NEVER FLOWS

⊘ guest PII to promoters
⊘ raw card data (tokenized only)
⊘ taste data without consent
⊘ cross-tenant guest graph
⊘ take-rate to guest surfaces

PREREQUISITES FOR GO-LIVE · goLive.outstanding, computed by the API

No tenant selected.

⚑ GATED · NO CHECKLIST READ YET

GET /admin/partners/tenant/:tenantId/onboarding · the gate is goLive.ready from that read, and nothing else on this page can open it

NOTES · Rationale

Three lists, one glance. FLOWS IN (mint), FLOWS OUT (electric), and — the one that builds trust — NEVER FLOWS (amber, tinted panel).
NEVER FLOWS is the point of this screen. Stating the boundaries explicitly — no guest PII to promoters, no cross-tenant graph, no take-rate to guests — is what makes the contract worth accepting.
GO LIVE is gated, not hidden. It renders disabled with a ⊘ glyph and an amber gate-note naming exactly what is outstanding. The operator sees the finish line and the steps left.
The gate is the API's, not this page's. It reads goLive.ready from the launch checklist. The mock had a demo checkbox that un-gated the button from local form state — a page that can talk itself into "ready" is precisely the thing a gate exists to prevent, so it is gone.
Prerequisites use the same status glyphs as W0 — ● cleared, △ outstanding — so the gate reads consistently with the checklist.
Clearing the gate is a fact, not a switch. ATLAS records no "went live" event, so the un-gated button says so when pressed rather than implying it wrote something. The three flow columns above are a written policy contract, not a live reading of the wire, and are labelled that way.

ATLAS TENANT ONBOARDING · P4 · W0 W1 W3 W4 LIVE ON /admin · W2 STILL A DRAWING · RED-FREE · DARK-ONLY · MONEY FROM INTEGER CENTS · ⚑ TAKE-RATE PLACEHOLDER