Platform And Clinics

The central database holds tenancy and identity concerns. Tenant databases hold everything operational.

• Central: tenants, domains, clinic memberships, provisioning records, platform admin access, platform-authenticated users, signup intents, SSO identities, owner onboarding sessions, audit export jobs, and platform access policy.
• Tenant: patients, doctors, appointments, consultations, pharmacy, billing, Smart Insights, AI runs, and clinic settings.
• Tenant users keep global_user_id so a central identity can be rehydrated into the clinic-local user model on demand.

Platform admins create clinics from the switcher. Provisioning creates the tenant database, runs tenant migrations, seeds the owner, and writes membership state back to central tables while keeping demo readiness visible.

• ClinicProvisioningService creates the tenant record and owner identity no matter whether the request came from public signup, SSO, or platform admin tooling.
• Tenancy hooks create and migrate the clinic database automatically, then baseline migration state if a partial schema already exists.
• Memberships and pending invites stay central, while target tenant role slugs are applied on first clinic entry.
• Platform Health now reads cached non-PHI snapshots so the screen stays responsive even when a clinic is degraded.
• Per-clinic summaries include onboarding status, demo readiness posture, and latest docs evidence or smoke status for buyer work.

Public owner onboarding, platform onboarding, and buyer proof now reuse the same readiness and repair contract instead of sending operators through parallel setup paths.

• Public signup supports email and password or Microsoft and Google SSO, then moves owners into one onboarding session record before clinic launch.
• Wizard steps cover clinic basics, owner or admin assignment, plan selection, branding, timezone, demo data choice, readiness check, and launch clinic.
• Demo Concierge can provision or reset a clinic into healthy demo or degraded demo mode from the platform shell.
• Evidence and smoke status stay attached to clinic summaries so operators know whether a clinic is buyer-ready before a session starts.
• Launched clinics land in the same tenant dashboard, scorecard, Smart Insights, AI, and communications surfaces shown in the demo flow.

Provisioning, upgrade, repair, and demo reset now share one tenant-bootstrap contract so partial installs do not drift further apart over time.

• Required tenant runtime tables include AI runs, communications tables, permissions, roles, settings, and AI usage snapshots.
• Required tenant metadata includes users.global_user_id and AI run freshness metadata for variants and presentation modes.
• Operix:repair-tenant is the authoritative recovery path for missing schema, empty tenant migrations, stale provisioning rows, and missing owner memberships.
• Dashboard blocks and AI entrypoints now fail independently and surface a reason, a docs link, and a next action instead of crashing the tenant shell.

Clinic status now affects whether tenant routes can be entered, while platform pages remain available for diagnosis and repair.

• pending_verification, pending_checkout, and pending_launch stay inside owner onboarding until launch requirements are met.
• Active clinics are routable through the clinic switcher.
• Suspended, failed, provisioning, and archived clinics stay visible in platform health but cannot be entered as tenant workspaces.
• Membership suspension blocks clinic switching even when the user still has platform access.