Authentication and enrollment
Access tokens are signed JWTs and refresh tokens are opaque, persisted, and rotated. Self-registration is disabled: accounts begin through platform provisioning or an Organization invitation. Invite and reset tokens are hashed, expiring, one-time credentials. Password changes update the security stamp so existing refresh tokens fail validation.
Explicit Organization context
Organization-scoped dashboard and API URLs carry the Organization ID. Cross-Organization resources are concealed with 404. Platform Administrators do not receive synthetic Memberships or implicit tenant authority: they must hold a real Membership to use Organization routes. This current rule supersedes the transient-superuser wording in the older explicit-context ADR.
Organization creation and membership
Any authenticated user may create an Organization, becomes its immutable Creator and initial Owner, and receives default model configuration. Names are mutable and need not be globally unique. The default per-creator limit is five non-deleted Organizations. Membership workflows preserve the unique Owner and protect ownership transfer and sensitive Admin changes.
Organization View and Platform View
Organization View lives under /dashboard/[orgId]. Platform View lives under /dashboard/platform and never establishes an active Organization. The Organization selector is always derived from Memberships, even for Platform Administrators. Switching Organization clears known tenant-scoped query caches.
Platform oversight boundary
Dedicated Platform APIs may expose explicitly allowlisted identity, lifecycle, activity, model, and cost projections. They must not reuse tenant DTOs or expose messages, tool inputs/results, logs, prompts, Templates, Skills, configuration, credentials, or raw Telemetry.