Platform schema
Tenant catalog, identity, invitations, and API tokens. These tables exist exactly once in the database and survive unchanged into a future per-tenant physical split — they're what every tenant needs to know about every other tenant, plus the identity layer that lets one human belong to many tenants.
ER diagram
Tables
- Organizations — tenant catalog row.
- Users & membership — identity (
users) and per-tenant membership (organization_users). - User invitations — cross-tenant invitation flow.
- API tokens — Personal Access Tokens (PATs) for programmatic access.
What's not here
Workflow status types. PO / WO / SO / fulfillment statuses are not separate tables — they're Postgres ENUM types defined alongside their consumers in the org schema. See the relevant entity pages (Purchase orders, Work orders, Sales orders) for the actual values.
User preferences. No platform.user_preferences table at v1. There's no real per-user preference to store yet, and we deliberately don't introduce one until there is.
Cross-schema relationships
The only platform↔org reference is org_id: every org.* table's org_id column references platform.organizations(id). There are no other cross-schema FKs.