The platform surfaces
The engines and verticals are what a tenant runs. This section is the machinery that runs them — the deployments and control surfaces that turn "a vertical" into "a vertical serving a customer at a hostname." Four pieces, each its own deployment:
| Surface | Audience | Answers |
|---|---|---|
| Control plane | the platform | the shared directory every vertical registers against — tenants, scopes, roles, entitlements, the admin log |
| Console | Substrat operators | run the platform — the whole fleet, every tenant, provisioning, the audit log |
| Router | inbound traffic | hostname → (tenant, scope, surface), then dispatch — one worker in front of every vertical |
| Dashboard | a customer's admin | run my org — self-service tenant + apps, seeing only their own tenant |
The split that matters most is Console vs Dashboard: same underlying platform, opposite audience and blast radius. The Console is the operator's back office (all tenants, staff SSO); the Dashboard is the customer's home (one tenant, customer sign-up). "Console" reads as a back-office tool; "dashboard" reads as the customer's home — the naming is deliberate, and neither takes the word "portal", which the docs reserve for a vertical's own end-user surface.
These are private deployments, not published packages. They are documented here because they are how the platform actually runs — the same architecture the concepts and reference sections describe, made concrete.
Where deploy fits
A vertical reaches these surfaces via substrat push: a listed vertical's pushes land pending in the control plane and an operator admits them in the Console; a private vertical's pushes land admitted automatically. See the deploy model. The Router serves an admitted version once a scope is bound.