Product IA And Role Model designed
The product IA defines how GPUaaS should feel as one platform instead of a set of disconnected routes. It separates role, scope, navigation, and page family so product and engineering teams can add surfaces without repeatedly redesigning the shell.
For the underlying ownership hierarchy, read Tenant, Department, Project, And Resource Hierarchy. This page explains where surfaces belong in the shell; the hierarchy page explains where authority, attribution, and resources actually live.
Authenticated Shell
The authenticated product shell has seven durable top-level groups:
| Group | Owns |
|---|---|
| Workloads | Active/runnable work, workload details, tasks, runtime activity |
| Compute | Catalog, launch, allocations, GPU capacity, infrastructure compute choices |
| Apps | App catalog, app launch, app details, artifacts, app platform entry points |
| Storage | Buckets, datasets, mounts, checkpoints, artifact/data lifecycle |
| Access | Projects, team, service accounts, credentials, entitlements, policies |
| Account | Profile, billing, personal SSH keys, sessions, personal settings |
| Platform | Platform admin, ops, fleet, governance, finance, evidence, telemetry |
Developer portal and public docs are separate surface families. They should not be treated as an eighth authenticated left-nav group.
Role Modes
Mode changes emphasis and default landing behavior. It does not bypass backend authorization.
| Mode | Primary reader/user | Default emphasis |
|---|---|---|
| User | Someone launching and operating workloads | Workloads, Compute, Storage, Account |
| Tenant Admin | Someone managing tenant access, spend, and governance | Access, Account, tenant-scoped usage/governance |
| Project Admin | Someone managing project members, workload access, and project posture | Access, Workloads, Storage, project-scoped governance |
| Platform Admin | Someone managing users, nodes, SKUs, audit, payments, and platform config | Platform, Fleet, Governance, Finance |
| Ops | Someone managing runtime health, incidents, release evidence, and fleet posture | Platform Ops, Evidence, Telemetry, Lifecycle |
The shell remains stable across modes. Disabled or unauthorized groups can be visible with reason text, but authorization still comes from the backend.
Navigation Layers
| Layer | Rule |
|---|---|
| Global shell | Move between top-level groups and keep mode/project/region context visible |
| Family local nav | Required when a surface family has multiple sibling pages, especially Platform, Access, and Account |
| Resource header | Detail pages must have stable parent back links, not only browser history |
| Resource tabs | Move between views of the same resource without changing identity |
| Evidence pivots | Explicit links to audit, logs, tasks, traces, or correlated resources |
| Wizard stepper | Multi-step mutations keep previous steps reachable and forward movement validation-gated |
Product IA Map
Design Rules
- Workload is the primary product noun for active/runnable things.
- Allocation remains the compute substrate and billing/runtime record.
- Apps remain a peer group and a strategic product surface.
- Storage is a top-level group because buckets and datasets outlive workloads.
- Platform is the privileged home for ops/admin/fleet/evidence surfaces.
- Major new surfaces must fit this IA before implementation starts.