Shared Platform Consumer Track designed
This path is for a team building the next product on AI Cloud shared services, not for an app developer packaging one workload. Token Factory is the canonical example: it must consume platform IAM, billing, policy, registry, audit, evidence, and status instead of rebuilding them.
Use This Track When
Use this route if your team is doing any of the following:
- adding a second product surface with its own routes, flows, and operators;
- introducing new scopes, usage units, resource types, or audit actions;
- depending on platform billing, registry, policy, or evidence contracts;
- deciding what remains product-owned versus platform-owned.
If you only need to package and launch an app through the App SDK, use Build on AI Cloud instead.
First-Read Sequence
- Platform Overview
- Shared Services
- Product Onboarding
- Current State and Roadmap
- Shared Platform Builders
- Platform Contracts for Builders
Product-Versus-Platform Split
| Concern | Product owns | Shared platform owns |
|---|---|---|
| Customer workflow | domain resources, workflow semantics, product UX | platform shell, identity context, evidence posture |
| Identity | product-specific scopes, role intent, persona flows | API keys, service accounts, memberships, authz surfaces |
| Billing | accepted usage source and product pricing intent | usage ingestion, rating, ledger, balances, refunds |
| Audit/evidence | product action meanings and invariants | append-only custody, evidence bundle model, retention posture |
| Status/ops | product components and degradation rules | shared status surfaces, incident/release evidence shape |
| Notifications | product triggers and recipient intent | delivery plumbing, preferences, dispatch state |
| Registry/artifacts | product artifact kinds and trust transitions | product/scope/unit/template/evidence registries |
| Policy | product quota dimensions and overrides | policy value authority and entitlement composition |
Consumption Contract
What A Second Product Must Declare
| Category | Minimum declaration |
|---|---|
| Product identity | product id, slug, lifecycle, owners, exposure posture |
| Ownership | package, route, schema, event, worker, and frontend owners |
| IAM | scopes, roles, service-account needs, entitlement rows |
| Billing | usage units, resource types, rating posture, ledger owner |
| Audit | privileged mutations, audit actions, read-model expectation |
| Status/evidence | component ids, invariants, release/UAT evidence bundle |
| Notifications | template keys, escalation, user-visible notices |
| Policy/quota | dimensions, snapshot kinds, override scopes |
| Portal/docs | user, developer, operator, security, product, architecture pages |
| Extraction | keep/split/extract recommendation with blockers |
Token Factory As The Reference Consumer
Token Factory is the cleanest stress test for the shared-platform model because it needs request-path enforcement without becoming a platform fork.
| Token Factory need | Correct platform pattern |
|---|---|
| API key and scope enforcement | consume platform IAM read models and scope registry |
| Spend and usage attribution | emit accepted usage into platform billing ingestion |
| Customer-visible rate/limit behavior | compose through policy/quota contracts, not local literals |
| Gateway operating evidence | publish status/evidence through shared ops model |
| Product onboarding | use the same onboarding packet as any second product |
The gateway remains product-owned. IAM, ledger, registry, evidence, and policy do not move into the gateway.
From Model To Code
This page explains what a second product must consume. When the builder needs actual package anchors and method shapes, go straight to Platform Contracts for Builders.
Review Questions Before Build Starts
| Question | Why it matters |
|---|---|
| Are we introducing a product or just an app/runtime? | Prevents app-SDK work from growing into accidental product work |
| Which routes, schemas, and events remain product-owned? | Avoids hidden cross-domain ownership |
| Which shared-service registries must activate first? | Prevents hardcoded scopes, units, and audit actions |
| What evidence proves this product uses shared services correctly? | Keeps readiness review anchored to proof, not prose |
| What would force a future extraction? | Separates current onboarding from premature service sprawl |
Exit Criteria
A second-product onboarding track is ready to leave planning only when:
- the onboarding packet is complete and reviewable;
- shared-service registry entries are defined or intentionally blocked;
- the product can explain its audit, billing, policy, and evidence posture;
- the portal has a developer/product/operator path for the new surface.