Service Design Matrix designed
This page is the missing bridge between high-level architecture and coding. A developer should use it to find the owning service, data model, flow, state machine, and first validation gate before implementation starts.
Service Families
| Service family | Owns | Primary implementation anchors | First design page |
|---|---|---|---|
| IAM / Access | tenants, projects, memberships, service accounts, MFA posture | packages/platform/iam, auth middleware, Keycloak realm/profile config | IAM and Access Service |
| Billing / Metering / Payments | usage, rating, ledger, balance, payment reconciliation | packages/platform/billing, workers, ledger schema | Billing, Metering, and Payments |
| App Runtime / SDK | app manifests, catalog, runtime instances, app controllers | packages/products/appplatform, app SDK scripts, runtime smokes | App SDK Proof |
| GPU Runtime / Provisioning | SKUs, nodes, allocations, provider lifecycle, GPU slicing | packages/products/gpuaas, provisioning worker, node agent | GPU Slicing and Scheduling |
| Terminal / Workload Access | browser terminal, SSH/session access, token/session binding | cmd/terminal-gateway, API session minting, node-agent stream relay | Workload Access Runtime Surfaces |
| Audit / Evidence / Status | privileged audit, release/UAT/security evidence, readiness readbacks | packages/platform/audit, evidence artifacts, ops read models | Audit, Evidence, and Status/Ops |
| Registry / Artifacts / Trust | app/product registry, artifact trust, promotion, runtime bundles | registry/trust contracts, app SDK promotion path | Registry, Artifacts, and Trust |
Cross-Service ER Anchor
This is a reader map, not a schema migration. Use canonical SQL and ERD source docs for exact columns.
User Launch Sequence
Runtime State Boundary
Every implementation should identify whether it is changing desired state, execution state, observed provider/node state, or projected UI state.
Implementation Checklist
Before coding a service change:
| Question | Required answer |
|---|---|
| Which service family owns the behavior? | one row from the matrix above |
| Which contract changes first? | OpenAPI, AsyncAPI, manifest, CLI, or no contract change |
| Which state model changes? | allocation, app runtime, billing, IAM, terminal, evidence, or none |
| Which data owner changes? | table/schema owner, event owner, read-model owner |
| Which UAT flow proves it? | user, tenant admin, app developer, platform admin, ops |
| Which CI gate catches drift? | codegen, web e2e, route guard, script smoke, docs check |
| Which evidence proves it? | artifact path, readback, screenshot, log, or API response |
Where To Add Detail
If this page is too shallow for implementation, add detail in the narrow service page first. Do not bury engineering design in a product overview.
| Missing detail | Add it here |
|---|---|
| IAM claim, role, service account, MFA behavior | IAM and Access Service |
| Ledger, metering, billing, payment behavior | Billing, Metering, and Payments |
| App manifest, controller, launch/connect behavior | App SDK Proof, Add a New App |
| Node agent, GPU slicing, scheduler behavior | Node Agent Runtime Depth, GPU Slicing and Scheduling |
| Terminal/session behavior | Workload Access Runtime Surfaces |
| Evidence/readiness behavior | Evidence Readiness Model, Service Version Readback |