User Journeys
AI Cloud documentation starts from the task a person is trying to finish.
Use this page as the checklist for a documentation walkthrough. If a step does not have a visible product path, a CLI/API equivalent, or a support handoff, it is a product or documentation gap.
End User
| Step | Goal | What good looks like |
|---|---|---|
| Sign in | Reach the product with the right tenant and project selected | The top bar shows the expected tenant and project. |
| Secure account | Add account protection and access keys | MFA, SSH keys, API keys, and sessions are visible in account settings. |
| Choose capacity | Pick compute or an app runtime | The catalog shows available runtime families and cost posture. |
| Launch | Start a runtime in the current project | The runtime moves from provisioning to active. |
| Connect | Open terminal, SSH, notebook, IDE, scheduler, or endpoint route | The connect action lands on the expected work surface. |
| Operate | Watch state, usage, storage, and spend | The user can understand health, hourly burn, and next action. |
| Release | Stop using capacity when finished | Billing stops and cleanup state is visible. |
End-User Acceptance Checklist
- User can find the current tenant and project without asking an operator.
- User can prepare account security from Account pages.
- User can see at least one launchable compute or app option.
- Launch form explains cost, access, image, and storage requirements.
- Active runtime has a connect action.
- Runtime detail shows enough state to decide whether to wait, retry, release, or ask for help.
- Release path is visible and does not require direct operator access.
Tenant Admin
| Step | Goal | What good looks like |
|---|---|---|
| Tenant setup | Confirm tenant name, workspace, and default project | The tenant has a usable project and visible admin context. |
| Project lifecycle | Create and review project ownership | Projects have clear names, roles, and lifecycle state. |
| Membership | Add users and assign least privilege | Members can use only the projects and roles they need. |
| Service accounts | Create automation identities | Credentials are scoped, rotatable, and auditable. |
| Quota and spend | Control capacity and budget exposure | Admins can see balance, quota, burn, and blocked states. |
| Access review | Remove stale access | Drift, stale members, and risky credentials are visible. |
Tenant-Admin Acceptance Checklist
- Admin can explain tenant and project ownership.
- Admin can add, review, and remove project members.
- Admin can create and review service accounts.
- Admin can see quota, billing, or entitlement blockers before users hit them.
- Admin can identify stale access and stale sessions.
- Admin can tell a user what evidence to send for support.
The Access surface should make project and membership review explicit. If the page shows drift, stale membership, or access-denied state, treat that as a review item before handing the tenant to users.
App Developer
| Step | Goal | What good looks like |
|---|---|---|
| Pick runtime family | Decide scheduler, compose, notebook/IDE, or inference endpoint | The runtime model matches the user workflow. |
| Define manifest | Describe launch, health, connect, storage, and cleanup | The manifest is reviewable before packaging. |
| Package artifact | Build the image or runtime bundle | The artifact has digest, version, and trust state. |
| Test lifecycle | Prove launch, status, connect, and release | The app can be operated without special workarounds. |
| Promote | Make the app available to users | Users can launch it through the product catalog. |
App-Developer Acceptance Checklist
- Runtime family is chosen before implementation starts.
- Manifest describes inputs, resources, endpoints, storage, health, and cleanup.
- Artifact source and digest/trust posture are clear.
- App can be launched in a clean project.
- App has a connect action users understand.
- Release cleanup is proven before promotion.
- Support can diagnose failures from product-visible state and correlation IDs.
CLI And API Consumer
| Step | Goal | What good looks like |
|---|---|---|
| Authenticate | Use bearer auth safely | Tokens are never placed in URLs or logs. |
| Set context | Send tenant/project context where required | API calls operate on the intended project. |
| Mutate safely | Use idempotency keys | Retries do not create duplicate work. |
| Handle errors | Use stable error codes and correlation IDs | Support can trace an issue without private data. |
| Automate | Prefer CLI or generated SDKs | Automation follows the same contracts as the UI. |
CLI/API Acceptance Checklist
- Auth setup is documented for the target environment.
- Project context is explicit.
- Retryable mutations use idempotency keys.
- Errors preserve stable codes and correlation IDs.
- Automation has a release or cleanup path.
- Logs do not contain tokens, cookies, private keys, one-time codes, or secrets.
When To Contact Support
Contact support with the visible correlation ID when:
- an access-denied state does not match your expected role;
- capacity remains unavailable after choosing another SKU or region;
- release or cleanup does not complete after retry;
- a route or connect action fails after the workload is active;
- billing or quota state does not match expected usage.
Public Guide Coverage
| Journey | Primary guide |
|---|---|
| First user walkthrough | Quickstart |
| Direct compute launch | Launch Compute |
| Account protection | Account Security |
| Tenant/project administration | Tenant Administration |
| App packaging | App Developer Guide |
| CLI/API automation | CLI And SDK Guide |