Skip to main content

Portal Roadmap in-progress

This page is the working content map for the Docusaurus track. The portal should grow from audience entry points into page families, not from a folder mirror of the existing doc/** corpus.

Expansion Principle​

Use the same sequencing rule we use for architecture work:

  1. Map the audience, source docs, visibility, and status.
  2. Add guard visibility for missing sources, broken links, and stale metadata.
  3. Expand content pages only after the map and guard are in place.
  4. Keep a standing sync track so canonical doc changes update the portal when reader-facing meaning changes.

Page Family Backlog​

Page familyAudienceFirst pagesCanonical sourcesStatusPriority
Internal Team OnboardingProduct, architecture, development, CISO, ops, infra, app developersPersona paths, common starting point, team-specific outcomesPRD, product IA, architecture overview, production baseline, governance overviewDesignedP0
Platform OverviewProduct, architecture, security, operators, developersBuilt capabilities, product shape, capability map, where to read nextarchitecture overview, implementation roadmap, product IA, production baselineDesignedP0
Build on GPUaaSApp developersApp SDK overview, quickstart, manifest model, local test workflow, promotion workflowApp_Developer_Starter_Pack, App_Platform_Quickstart, App_Manifest_Registration_Guide, Launchable_OCI_Workload_Profile_ContractDesignedP0
Security & Production ReadinessSecurity, operators, architectsCurrent controls, production gaps, release rings, evidence bundles, guard graduationGPUaaS_Security_CD_Current_State_Gap_Roadmap, Production_Platform_Baseline, platform-foundation gap portfolioIn progressP0
Use GPUaaSUsers, tenant adminsLaunch flow, access, storage, billing, troubleshooting, tenant administrationUX_Journeys, UX_Implementation_Spec, Product_Surface_IA, account/billing/storage contractsDesignedP0
Developer APIsAPI and SDK consumersREST reference, AsyncAPI reference, auth/access, idempotency, error model, contract artifacts, API rendering options, API playground, CLI/SDK linksopenapi.draft.yaml, asyncapi.draft.yaml, external app integration guide, error catalog, NATS stream configIn progressP1
OperatorsPlatform operatorsRelease model, environment profiles, observability, runbook index, UAT evidenceproduction baseline, release policy, ops runbooksRunbookP1
ArchitectureEngineers, architectsSystem overview, platform foundation, shared services, domain ownership, route model, code boundariesarchitecture overview, platform-foundation docs, domain operating model, API authoring modelDesignedP1
ProductProduct and UXProduct strategy, user interactions, competitive context, journeys, v3 IA, page families, gapsPRD, product IA, v3 navigation, UX journeys, competitive matrixDesignedP1
Governance & AgentsEngineers, coordinatorsGovernance model, agent-native SDLC, coding/testing standards, Fairway coordination, release authoritygovernance overview, governance standards, platform-control policyDesignedP1
ReferenceAll technical readersGlossary, error codes, policies, state machines, event taxonomyreference specs and generated contract artifactsContractedP2

First Content Tasks​

  1. Keep the Platform Overview and System Overview current as the first review path for cross-functional readers.
  2. Build the App SDK overview and quickstart under Build on GPUaaS.
  3. Build the Security & Production Readiness overview with current controls, gaps, release evidence, and guard graduation.
  4. Build the Use GPUaaS journey map for user and tenant-admin workflows.
  5. Add generated OpenAPI rendering or a static generated reference path.
  6. Add a metadata guard for required frontmatter fields on every portal page.

Publication Track Decisions​

Keep the first version internal. Preserve visibility metadata so later publishing can split pages into public, customer, partner, and internal tracks. Do not hardcode access control into the first portal implementation.

Operating Pages​

Canonical sources