Architectural tiers

Full definitions live in docs/frontend/DOMAIN_MODEL.md. This page is the practical, routing-level version: given a URL or a permission string, which tier does it belong to?

User
 ├── Platform
 └── Organization (Workspace)
      └── Application

User sits above both Platform and Organization, not inside either. You authenticate once as yourself, then reach an Organization you belong to or — if you hold a platform role — Platform administration. Both are reachable from the neutral post-login /dashboard.

Tier	Answers	Routes	Permission prefix	Roles
User	"Who am I, where do I want to work?"	/dashboard, /account/*	—	—
Organization	"What can I do in this organization?"	/org/:slug/*	portal:*, org:*	OWNER/ADMIN/MEMBER (system, three since VIEWER's 2026-08-19 retirement) + custom roles, per-org
Platform	"What can I manage across the whole system?"	/platform/*	platform:*	SUPER_ADMIN, P4P Owner, P4P Admin (P4P Member deleted 2026-08-19 — see IAM)
Application	Independent products running inside an Organization	/org/:slug/<app>/*	scoped to the app	inherits Organization membership

A distinction the old design docs get wrong — and a later correction

docs/frontend/INFORMATION_ARCHITECTURE.md describes "Projects"/"CRM"/etc. as generic Applications every organization could subscribe to. That's not what got built, but it's closer to the truth today than it first looks. What actually exists under /team/* and /platform/staff is the Internal Company Workspace — P4P's own staffing/PM tool for managing its internal team, departments, projects, and tasks. Until 2026-08-18 it was gated by platform:staffing:* permissions, a genuine Platform-tier feature. docs/staffing/ADR-002-org-rbac-migration.md moved it onto Organization RBAC, scoped to the P4P Internal organization — the same Role/Permission/TenantGuard+PermissionsGuard mechanism every other organization uses, now under workspace:staffing:*/workspace:calendar:*/ workspace:finance:* keys. So /team/* is genuinely Organization-tier today, just permanently scoped to one specific organization (P4P Internal) rather than the one currently selected — the one place this table's "which tier" shortcut (route prefix ⇒ tier) doesn't hold, since the URL still reads /team/*, not /org/p4p-internal/*. PlatformStaffMembership is unchanged by this — it still answers a separate question ("is this person P4P staff at all", an HR/roster fact) from "what can they do in Team Management" (now the org-role question above). See Platform Administration and the Staffing module doc.

The genuinely Organization-tier, per-org-subscribed features that exist today are the AI Assistant (ai:chat:use, ai:agents:manage, ai:mcp:manage) and file storage (files:*) — both live under /org/:slug/* and are gated per-organization, matching the Application tier as originally designed.

Why this matters when reading the rest of this wiki

Every module doc's frontmatter lists routes and permissions. If a route starts with /platform/ or a permission with platform:, you're looking at Platform-tier behavior — it applies once, platform-wide. If it starts with /org/:slug/ or portal:/org:, it's Organization-tier — the same page behaves differently (or isn't visible at all) depending on which organization you're currently in.