Shared Platform Builders in-progress
This path is for teams that extend or operate GPUaaS as shared platform infrastructure: IAM, infra, token-factory builders, and platform service owners.
Start Here
Shared Platform Decision Route
| If the team needs to decide... | Open this first | Then go here |
|---|---|---|
| whether a capability belongs in shared platform or product code | Platform Foundation | Shared Services |
| how a second product should onboard without reimplementing core services | Product Onboarding | Shared Platform Consumer Track |
| how identity, billing, policy, and evidence should stay reusable | System Overview | Developer APIs, IAM and Identity Team Guide |
| which environment assumptions are safe to bake into shared services | Production Baseline | Infrastructure and Environment Guide |
Audience Map
| Team | Primary question | First route |
|---|---|---|
| IAM | How do identity, roles, scopes, service accounts, and recovery boundaries fit into the product? | Security & Production Readiness, Developer API Auth, Platform Foundation |
| Infra | What must exist in the environment for release, routes, secrets, storage, and node lifecycle to work? | Operators, Production Baseline, Release Operations |
| Token factory / shared-platform builders | How should another product build on shared platform services instead of reimplementing IAM, billing, policy, or evidence? | Build on AI Cloud, Product Onboarding, Shared Services |
| Platform service owners | Which contracts and evidence models must remain product-neutral? | Architecture, Domain Ownership, Developer APIs |
What This Group Must Preserve
| Platform contract | Why it matters |
|---|---|
| Identity and access boundaries | Products should consume shared IAM and entitlement patterns, not invent incompatible account models |
| Registry and product onboarding | Shared services need one product onboarding path for identity, billing, evidence, status, and portal support |
| Policy and quota composition | Product-specific policy must compose through shared scopes and dimensions |
| Runtime and evidence models | Products need consistent status, ops, release, and audit surfaces |
| Environment profile discipline | Dev, kind, demo, staging, and later prod/air-gapped profiles must stay config-driven rather than one-off shell state |
Reading Packs By Team
| Team | Read next |
|---|---|
| IAM | Current Controls, Security Controls, User Interactions |
| Infra | Day-2 Operations, Node Lifecycle, Incident Workflow |
| Token factory / product builders | Shared Platform Consumer Track, Product Onboarding, Platform Status |
| Platform service owners | Shared Services, API Domain Authoring, Governance Model |
Practical Handoff Rules
| Rule | Meaning |
|---|---|
| Reuse shared platform first | New products and services should plug into identity, billing, evidence, policy, and portal models before inventing local variants |
| Keep product contract neutral | Cloudflare, local laptop paths, and one environment’s DNS/TLS assumptions are implementation profiles, not product contracts |
| Make environment assumptions explicit | If a flow only works in one environment profile, document that as a profile boundary rather than hiding it |
| Route through current evidence models | Build new service/operator work so release, status, UAT, and incident evidence stay machine-readable |
Builder Review Rule
If a team cannot tell from this route whether work belongs to shared platform, product integration, or environment profile, the portal is still too shallow. That ambiguity should be fixed here before it leaks into new service design.
Canonical sources