Resource Model and Naming implemented
This page is the portal-native explanation of what a resource is in AI Cloud, who owns it, how it is named, and how different identifiers relate to each other.
Ownership Hierarchy
The stable hierarchy is:
organization -> department -> project -> principal -> product resource
Where:
- organization is the product-facing billing and ownership root;
- department is the attribution and reporting layer;
- project is the operational workspace and primary resource scope;
- principal is the human, service account, or group acting in that scope;
- product resource is the actual compute, storage, app, route, or other product-specific object.
Identifier Classes
Do not collapse every identifier into one field. Different identifiers serve different purposes.
| Field class | Purpose | Example |
|---|---|---|
| Display name | reader-facing label; mutable | training-cluster, research-bucket |
| Slug | human-friendly scoped key when needed | rke2-demo |
| Internal id | primary DB/API identity | 41000000-0000-4000-8000-000000000002 |
| Canonical resource identifier | cross-service, policy, audit, evidence identity | core42:aicloud:us-east:tenant-1:project-1:gpuaas/allocation:alloc-1 |
| Provider resource id | external provider/runtime identity | VM id, MAAS system id, Kubernetes object uid |
| Route/path identity | URL placement for one surface | /api/v1/projects/{project_id}/app-instances/{id} |
Canonical Resource Identifier
The accepted format is:
core42:aicloud:{region}:{tenant_id}:{project_id}:{resource_type}:{resource_id}
Rules:
- Namespace is
core42. - Platform is
aicloud. tenant_idandproject_idare mandatory for tenant-owned resources.resource_typeis service-qualified.- The canonical identifier is immutable and external-facing, but not the primary database key.
Resource-Type Examples
| Resource family | Example resource_type | Notes |
|---|---|---|
| Compute allocation | gpuaas/allocation | allocation lifecycle identity |
| Node | gpuaas/node | inventory/control-plane node identity |
| Storage bucket | storage/bucket | bucket owner stays the project |
| App instance | appplatform/app-instance | runtime-owned app surface |
| Service account | iam/service-account | project-scoped machine principal |
| Managed route | edge/route | route intent plus endpoint binding |
Product Examples
Compute allocation
display_name: "L40S training run"
internal_id: 3ef9...uuid
canonical_id: core42:aicloud:us-buffalo:tenant-a:project-ml:gpuaas/allocation:3ef9...uuid
provider_resource_id: maas-system-42 or lxd-vm-991
App instance
display_name: "slurm-reference"
slug: "slurm-reference"
internal_id: appinst_123
canonical_id: core42:aicloud:us-buffalo:tenant-a:project-ml:appplatform/app-instance:appinst_123
provider_resource_id: namespace/workload identity inside the runtime backend
Service account
display_name: "training-and-inference-ci"
internal_id: svcacct_456
canonical_id: core42:aicloud:us-buffalo:tenant-a:project-ml:iam/service-account:svcacct_456
Route Naming Versus Resource Identity
API routes are not the identity model.
- Route paths are surface-specific and may evolve.
- Canonical resource identifiers stay stable across API, events, policy, evidence, and incident tooling.
- Provider ids are never the main product identity.
This is why /api/v1/v3/* or other migration namespaces must not become the
default naming model for permanent resources.
Reader Guidance
| Audience | What matters most |
|---|---|
| Product | hierarchy and ownership boundaries |
| IAM / Security | principal scope, tenant/project attribution, canonical identity |
| Infra / Ops | provider id vs product id vs canonical id |
| Developers | which id to store, show, send, and correlate |