Overview
What Exo is, what it owns, and how these docs are organized.
EXO is mission control for launching apps. Its products are components: Exo ID, Exo Key, Exo Deploy, EXO Verify, Exo Analyze, Exo Rank, Exo Inform and the other services in the platform and stack docs. People build apps, and each app picks the components it needs. It is modular: no app uses everything. EXO is infrastructure, not a general-purpose application generator and not a CMS. Its reusable core is schemas, access controls, provider adapters, provisioning, deployment contracts, evidence, and documentation (architecture, ADR 0013).
Exo lives at exo.now. Its shared staging environment is
https://staging.exo.now, and every managed app stages under it at staging.exo.now/{app}.
The product hierarchy
EXO is mission control for launching apps. Its components are its products. People build apps, and each app picks its components. Construct, one of those apps, publishes Surfaces, and Surfaces carry Cards.
| Term | Meaning |
|---|---|
| Organization | Ownership and collaboration: a person or a team. Legacy Payload tenants records are migration input, not a synonym for anything here. |
| Account | A walled-off space on EXO with its own users, data, secrets, environments and audit trail. Anything that needs walled-off money or data (for example Foundation's donor money) gets a separate account, not a separate platform. |
| Component | One EXO product an app can pick, declared in the app's project.yaml as a top-level components list. Components are either core or specialty (see below). |
| App | What people build on EXO. It picks the components it needs and owns its persistent runtime state, privileged workflows and operating responsibility. The artwork shows an app as a rocket ship; the prose always says app. |
| Starter kit | A saved set of components that new apps start from. Each app still declares its own components. |
| Version | One iteration of an app. Launch means a version reaching Production; Staging is the launch pad and EXO Verify is the preflight. |
| Surface | An interaction layer for users, published by Construct: a web surface (website), a mobile surface (PWA), a phone surface (iOS or Android app), or any combination. Surfaces are published, not launched. |
| Card | A UI unit that sits on a Surface and gives it functionality. Cards inherit the Surface's identity and release boundary, and are published with it. |
| Page | A routable content unit inside a web Surface, owned by Construct. Exo sees Pages only as typed resources for grants, routing, deployment evidence, and aggregate policy. |
| UI component | A reusable implementation or UI unit inside an app's code, with no identity responsibility. Not the same thing as an EXO component. |
Core components and specialty components
Core components are the ones most apps need:
source: code and its history (Entire); recommended, but an app may opt outidentity: sign-in for the app's users (Exo ID); an app with no users who sign in setssignIn: falseand skips itpreflight: checks before a launch (EXO Verify Level 1)runtime: where the app runssecrets: keys and credentialsevidence: the record of what was checked and launcheddata: the app's database (Convex)
Specialty components are the ones only some apps need (not every app needs comms and support, or model routing through Exo Rank):
comms: email, SMS and messaging (Bird)paymentsmodels: AI model routing (Exo Rank)support: help for the app's users (Exo Ask, proposed)analytics: product analytics (Exo Analyze)surfaces: screens published through Construct
The control plane (Exo, driven through Hark, with Hermes as the open-source option; see the stack) is recommended in the same way as source control, and an app may opt out of it too.
EXO Verify requires preflight, runtime, secrets and evidence, plus identity unless signIn is
false. Source is recommended, not required. Data is core because almost every app uses it, but an app without a database
is still valid. A starter kit is a saved set of components, so a family of similar apps can
start from the same picks.
Surface, app, or account?
- A Surface in Construct when it is mostly screens over Construct's components.
- Its own app when it has its own backend and data.
- Its own account on EXO only when it needs walled-off money or data, for example regulated money or a different owner.
Applied: Hadron is an app in the Interspace account. Foundation's donor money lives in its own account on EXO, while its landing page stays a Surface in Construct. If Hadron is sold, each customer gets their own account on EXO and their own Hadron app, the same pattern as Parlour's Construct.
Five responsibilities, kept separate
Exo is easiest to understand as five connected responsibilities rather than one large admin panel. They are deliberately separate: a green build is not a deployment, a provider deployment is not a review, and a completed issue is not a Production approval.
| Responsibility | Question it answers | Primary interface | Source of truth |
|---|---|---|---|
| Work | What are we trying to change, and who owns the next action? | Exo portfolio | Exo work item |
| Product | What app, account, environment, grant, and release state do we manage? | Exo control plane | Convex records and versioned contracts |
| Source | What exact code and agent context produced the result? | Entire | Commit, branch, session, checkpoint, and tag |
| Runtime | What is configured and running now? | Railway or another OCI provider | Live provider state and secrets |
| Evidence | Is the declared version healthy, reviewable, and approved? | Exo portfolio | Provider observations, manifests, checks, and approvals |
What Exo owns, and what it does not
- Exo owns app registration, accounts, organizations and access, environments, provider provisioning, deploy/release/rollback state, runtime-dependency metadata, policy and security controls, audit evidence, orchestration, health, and bounded usage and cost aggregates (ADR 0003).
- Construct owns Page and website editing, Puck, publishing, Page authorization, and authenticated Surfaces.
- Independent apps own their domain records. Exo provisions and observes their resources and accepts only bounded operational observations. It does not centralize their prompts, content, user data, datasets, or financial ledgers.
Platform services
Exo provides its services as components that each app picks, so apps skip basic plumbing:
- Exo Key: the single identity provider and OAuth client. Apps are relying parties.
- EXO Verify: code verification as a service, with a standard verify contract, sandboxed runs, live staging checks, and AI review.
- Exo Analyze: Exo-owned product analytics, from visits through cost to serve.
- Exo Deploy: one release path for every surface (web on Railway, mobile on Expo).
- Exo Rank (code and URLs still say router): Exo's smart model routing, one metered AI egress. Apps never hold provider keys.
- Exo Inform: docs and READMEs that agents and people can read (
/llms.txt, the docs MCP tool andexo docsCLI); offering it to every app is planned (roadmap).
How these docs are organized
Tenets
The four principles every decision is checked against.
The stack
Twelve dimensions: platform, boundary, replaceability, cost, and status.
Cost and unit economics
Every cost figure recorded in the ADRs, in one place.
Platform services
The components apps pick: Exo Key, EXO Verify, Exo Analyze, Exo Deploy, Exo Rank and more.
How work ships
Canary branch → Staging → Release Candidate → Production.
Decision records
The ADRs, rendered straight from docs/adr.
Roadmap
Rendered from roadmap/items.
Conventions
Every statement here is drawn from the repository: docs/, docs/adr/, roadmap/, and the
code. Each page links to its sources. Anything the repository does not record is marked
TBD, not estimated. When a source document and these pages disagree, the source document
(and the newest accepted ADR) wins, and the page should be fixed.
Source: content/docs/index.mdx