Platform administration

The superadmin surface most tenants never see. These views are platform-wide, not tenant-scoped, and are reachable only by a platform superadmin. This is a brief tour, not an operations manual.

All tenants #

A superadmin sees every tenant on the platform, not just the ones they belong to, and can create new tenants. Creating a tenant seeds it with its first Owner, who then manages members from inside the tenant.

The waitlist #

A user who signs in but belongs to no tenant is parked on the waitlist. The waitlist view lists those pending users, each with their email and name. A superadmin can approve one into a chosen tenant with a chosen role (which creates their membership in one step) or reject them. If a user gains a tenant by another path in the meantime, their entry resolves automatically, so the pending queue never lists someone who already has access.

Ingest services #

The ingest services registry tracks every deployed receiver. Each entry carries its public base URL, its kind (a shared service or one dedicated to a tenant), an optional region, and an enabled flag. One shared service can be marked the default, used by any app without an explicit route. Each receiver reports a heartbeat, so the registry shows live health: last-seen time, reported version and instance, queue depth, and throughput. A receiver that has not checked in within the staleness window is flagged.

Ingest routes #

An ingest route pins one app's beacons, for one environment, to a specific ingest service. Routes are how you place an app on a dedicated or regional receiver. An app with no route for an environment falls back to the default shared service. The resolved endpoint per environment is exactly what an app's Install tab reads to fill the SDK embed snippet, so a route change flows through to the generated snippet with no app change.

Platform LLM config #

Selene runs on language models provisioned at the platform level. A superadmin configures two things:

• Providers. The LLM provider credentials (API key, optional base URL, enabled flag). A key is accepted once on write and never shown again; the view only reports its last four characters and whether one is configured.
• Model tiers. Two tiers, high (the main reasoning model) and fast (a lighter model), each mapped to a provider, a model id, and caps such as max output tokens, temperature, and reasoning budget. Tenant admins can override the model ids per tenant in their Assistant settings; these are the platform defaults.