# 0011: Exo forges Bases that launch Ships

https://exo.now/docs/adr/0011-forge-bases-and-ships

> Status: superseded by ADR 0013 (2026-10-13) · Date: 2026-10-12



# ADR 0011: Exo forges Bases that launch Ships [#adr-0011-exo-forges-bases-that-launch-ships]

* Status: superseded by [ADR 0013](0013-exo-is-mission-control-apps-pick-components.md) (2026-10-13)
* Date: 2026-10-12
* Decided by: Samir (owner)

> **Superseded.** ADR 0013 replaces this model: EXO is mission control for launching apps, its
> products are components, and people build apps that pick the components they need. "Forge", "each owner builds a Base" and Ship as
> a product noun are retired. Kept for history.

## Context [#context]

Exo described itself as "mission control for launching apps", and its docs used App as the top
noun. That hid what Exo actually provides: a well-defined set of software parts (identity, data,
runtime, checks, secrets, messaging) that apps are built on, which each owner uses selectively.
Construct also needed a clear place in the hierarchy for websites, PWAs and native apps, and the
mini-apps that sit on them.

## Decision [#decision]

1. **Exo is the forge.** "Forge" describes Exo; it is not a product noun. The name stays Exo, never
   "Exobase" or "Base Forge". In repository contracts the Entire role is now `primary-host`, because
   "forge" now means Exo.
2. **A Base** is the buildout of parts Exo forges for an owner (an Organization: a person or team).
   Parts come from one catalog. Each Base declares the parts it uses in `project.yaml` as
   `base.parts` (schema 1.9):
   * Required core: `source`, `preflight` (EXO Verify Level 1), `runtime`, `secrets`, `evidence`,
     plus `identity` (Exo ID) unless `base.signIn` is false.
   * Optional: `data` (Convex), `comms` (Bird), `payments`, `models` (Exo Rank), `support`
     (Exo Ask, proposed), `analytics` (Exo Analyze), `surfaces` (Construct).
   * Shared services (the Exo ID provider, Exo Rank, EXO Verify, Bird) run once in the forge. Each
     Base gets its own clients, configuration, data, environments and secrets on top of them. A
     Base is not private or resold infrastructure.
3. **A Ship** is an app a Base launches. A Base has a fleet: it can launch several Ships. Ships
   return, get refitted and fly again: each iteration is a **version**. **Launch** means a version
   reaching Production through the owner-approved promotion. Staging is the launch pad, and EXO
   Verify is the preflight. Rollback means relaunching an earlier version. Environment names stay
   Staging, Release Candidate and Production.
4. **Construct** is the construct that produces **Surfaces**, the interaction layers for users: web
   surfaces (websites), mobile surfaces (PWAs), phone surfaces (iOS and Android apps), or any
   combination. Surfaces carry **Cards**, components that give a Surface its functionality.
   Surfaces and Cards are **published**, not launched.
5. **Placement rule.** Something is a Surface in Construct if it is mostly screens over Construct's
   parts. It is its own Ship if it has its own backend and data. It gets its own Base only when it
   needs walled-off data, secrets and audit trails, for example regulated money or a different
   owner.
   * Hadron is a Ship on the Interspace Base.
   * Foundation gets its own Base because it handles donor money; its landing page stays a Surface
     in Construct.
   * If Hadron is sold, each customer gets their own Base (users, data, agent keys) and launches
     their own Hadron Ship, the same pattern as Parlour's Construct.

## Consequences [#consequences]

* Code, schema, Convex tables and URLs keep `app` (for example `staging.exo.now/{app}`). Ship is
  the product word; no data migrates.
* `project.yaml` schema 1.9 adds `base`; EXO Verify Level 1 checks it. 1.8 projects stay valid and
  get a skip until they migrate.
* Rollout is light: the homepage, docs overview, platform index, README, llms.txt and the
  repository contract. Deeper docs still say App and move over as they are next edited.