Platform Admin vs. Org Admin: Why the Distinction Matters

"Admin" is an overloaded word in a multi-tenant platform. The platform has admins. Each tenant org has admins. They share the word but not the powers. The platform’s URL structure makes the distinction visible.

Platform-only pages

/admin/platform/trust-scoring (configure the platform-wide trust scoring weights), /admin/escrow/disputes (adjudicate disputes across tenants), /admin/auction/strikes/[companyId] (pardon strikes — platform-staff only), /admin/exchange-rates (manage the rate feed). These pages are gated by getAdminScope() returning a platform-tier role; an org-admin can’t reach them no matter how their permissions are configured.

Org-only pages

/admin/organizations/[slug] (manage your own org settings, users, billing), /admin/users (manage your own org’s users), /admin/storage (your own storage tier), /admin/email-provider (your own outbound email config). These pages let an org-admin do everything within their own tenancy without seeing other tenants.

Cross-tenant visibility

Platform staff can read across tenants for support reasons — a customer files a ticket about a deal that bounced, the platform staff needs to see the deal to investigate. The visibility is logged: every cross-tenant read writes an entry to the activity log with the staff user, the target tenant, and the action. So "did somebody from the platform look at our data" has an answer that isn’t a guess.

Why two URL prefixes

Because nesting platform-only pages and org-only pages in the same URL tree leads to access-control mistakes. /admin/platform/* is unambiguous. /admin/organizations/* is unambiguous. A page at /admin/[ambiguous-name] requires you to read the code to know which role enforces it. Naming makes the audit easier.