Start Here implemented

GPUaaS documentation is not short on detail. The missing piece is a maintained front door for each reader. Start with your persona, make the first decision the portal asks of you, then move into the canonical section that owns the detail. The portal is the curated map; the canonical specifications remain in doc/** and doc/api/**.

Choose Your Path First

Persona	First-read path	Decision points	Next-action pages
End user	Use GPUaaS, User Journeys, Platform Overview	Am I launching capacity, operating an active workload, managing storage, or resolving billing/access friction?	Billing and Storage, Troubleshooting, Developer APIs auth
Tenant admin	Use GPUaaS, Product IA Role Model, User Interactions	Am I managing projects/members, spend posture, access policy, or auditability?	Billing and Storage, Security Readiness, Product Journeys
Platform operator	Operators, Production Baseline, Day-2 Operations	Is this release, incident, fleet, observability, billing diagnostics, or node lifecycle work?	Release Operations, Incident Workflow, Runbook Index
Security reviewer	Security & Production Readiness, Current Controls, Release Evidence	Am I reviewing implemented controls, known gaps, release evidence, or external-readiness posture?	Security Controls, Gaps Roadmap, External Security Path
App developer	Build on GPUaaS, App Developer Onboarding, App SDK Overview	Am I learning the boundary, building locally, defining a manifest, proving runtime behavior, or promoting an artifact?	Quickstart, Manifest Model, Artifact Trust and Promotion
Architecture reviewer	Architecture, System Overview, Domain Ownership	Am I checking runtime shape, service boundaries, route ownership, state machines, or data/security lifecycle?	Shared Services, API Domain Authoring, State Machines
Product stakeholder	Product Team Handoff, Product Strategy, User Interactions	Am I reviewing market fit, persona journeys, v3 IA, launch/runtime experience, implementation truth, or roadmap gaps?	Journeys and v3 IA, Launch Allocation Runtime, Portal Roadmap
Agent/coordinator	Governance & Agents, Evidence-First Execution, Change Control	Am I claiming work, proving readiness, routing review, or preserving source-of-truth discipline?	Governance Model, Portal Source Of Truth, Discovery Index

Then Use The Section Map

Internal Teams

For Product, Architecture, Development, CISO, Operations, Infrastructure, Governance, and app-developer onboarding.

Open team paths

Platform Overview

For reviewers who need the product shape, built capabilities, and main system map first.

Open overview

Use GPUaaS

For users and tenant admins who need to launch capacity, manage projects, and understand billing.

Open user path

Build on GPUaaS

For internal, partner, and external app developers using the App SDK and manifest model.

Open developer path

Security

For reviewers who need controls, release discipline, current gaps, and readiness evidence.

Open security path

Operators

For platform operators who need environment, release, patching, observability, and runbook entry points.

Open operator path

Architecture

For engineers and architects who need the system overview, boundaries, and platform foundation model.

Open architecture path

Product

For product handoff, strategy, user interactions, competitive context, personas, journeys, and v3 IA.

Open product path

External Viewers

Draft publication paths for product, security, architecture, and developer reviewers.

Open external paths

Completion Map

The internal portal now has a first-read path for every primary audience, a clean static build gate, publication-track validation, source-doc inventory, and a documented Cloudflare Pages publish path. Remaining work is mostly external-track hardening and iterative depth, not first-time portal creation.

Area	Current state	Follow-up direction
Persona-first portal	Implemented for product, architecture, security, ops, developers, app builders, and governance readers	keep audience pages current as product surfaces move
API and SDK references	Implemented through synced OpenAPI/AsyncAPI artifacts, reference pages, and App SDK proof/onboarding paths	improve renderer/playground only when it adds value over current synced artifacts
Publication and deploy path	Implemented for internal static publication with metadata, preflight, Cloudflare Pages wrapper, and publication-track checks	add tighter external filtered builds when sharing broadens
Visual explanation layer	Implemented at baseline with Mermaid across major product, architecture, security, and governance pages	continue adding deeper sequence/C4/runtime visuals where readers still struggle
Continuous gates	Implemented through `make docs-portal-check`, source-doc validation, synced artifacts, inventory, and static deploy preflight	extend only when a real stale-content or publication miss escapes the current gate

Build Identity

Use the portal build metadata when reviewing screenshots, exported pages, or a Cloudflare-hosted copy of the portal.

Commit	`9725f0e5236d`
Full SHA	`9725f0e5236dc0f3f14d9a5c89d15ecd5a64dc1b`
Build timestamp	`2026-06-18T02:31:05.632Z`
Published timestamp	`2026-06-18T02:31:03Z`
Publication track	`internal`
Public URL	`https://docs.aicloud.core42.dev`

Portal Rules

Entry pages summarize and route; canonical docs remain authoritative.
Every high-level claim should point to a source doc, contract, code path, or evidence artifact.
App SDK docs are a product surface and stay visible as a top-level journey.
Security and production readiness pages distinguish implemented controls, report-only controls, and gaps.
Page metadata carries audience, visibility, status, and source-doc references so publication tracks can be split later.

Canonical sources

Choose Your Path First​

Then Use The Section Map​