# Overview

https://exo.now/docs

> 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](./platform/index.mdx) and [stack](./stack/index.mdx) 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](../../docs/architecture.md),
[ADR 0013](../../docs/adr/0013-exo-is-mission-control-apps-pick-components.md)).

Exo lives at [exo.now](https://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 [#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-and-specialty-components]

**Core components** are the ones most apps need:

* `source`: code and its history (Entire); recommended, but an app may opt out
* `identity`: sign-in for the app's users (Exo ID); an app with no users who sign in sets
  `signIn: false` and skips it
* `preflight`: checks before a launch (EXO Verify Level 1)
* `runtime`: where the app runs
* `secrets`: keys and credentials
* `evidence`: the record of what was checked and launched
* `data`: 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)
* `payments`
* `models`: 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](./stack/control-plane.mdx)) 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? [#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 [#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 [#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](../../docs/adr/0003-convex-first-control-plane.md)).
* **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 [#platform-services]

Exo provides its services as components that each app picks, so apps skip basic plumbing:

* **[Exo Key](./platform/exo-key.mdx)**: the single identity provider and OAuth client. Apps are
  relying parties.
* **[EXO Verify](./platform/exo-verify.mdx)**: code verification as a service, with a standard
  verify contract, sandboxed runs, live staging checks, and AI review.
* **[Exo Analyze](./platform/exo-analyze.mdx)**: Exo-owned product analytics, from visits through
  cost to serve.
* **[Exo Deploy](./platform/exo-deploy.mdx)**: one release path for every surface (web on Railway, mobile on Expo).
* **[Exo Rank](./platform/exo-router.mdx)** (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
  and `exo docs` CLI); offering it to every app is planned
  ([roadmap](../../roadmap/items/exo-inform.md)).

## How these docs are organized [#how-these-docs-are-organized]

<Cards>
  <Card title="Tenets" href="/docs/tenets" description="The four principles every decision is checked against." />

  <Card title="The stack" href="/docs/stack" description="Twelve dimensions: platform, boundary, replaceability, cost, and status." />

  <Card title="Cost and unit economics" href="/docs/stack/economics" description="Every cost figure recorded in the ADRs, in one place." />

  <Card title="Platform services" href="/docs/platform" description="The components apps pick: Exo Key, EXO Verify, Exo Analyze, Exo Deploy, Exo Rank and more." />

  <Card title="How work ships" href="/docs/shipping" description="Canary branch → Staging → Release Candidate → Production." />

  <Card title="Decision records" href="/docs/adr" description="The ADRs, rendered straight from docs/adr." />

  <Card title="Roadmap" href="/docs/roadmap" description="Rendered from roadmap/items." />
</Cards>

<Callout title="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.
</Callout>