exoDocs
Decisions (ADRs)

Decisions and roadmap

ADR 0013: EXO is mission control; apps pick components

  • Status: accepted
  • Date: 2026-10-13
  • Decided by: Samir (owner)
  • Supersedes: ADR 0011 (Exo forges Bases that launch Ships)

Context

ADR 0011 described Exo as a forge that builds a Base for each owner, and each Base launching Ships. In practice that put two invented layers (forge, Base) and a second word for an app (Ship) between people and what they actually do: build apps on EXO and use the components each app needs. Nobody builds Exo, and nobody builds a Base. The model needed to be simpler to say and to read.

Decision

  1. EXO is mission control for launching apps, the platform. There is one of it. "Forge" is dropped entirely, and so is "Base" as a product noun and "each owner builds a Base".
  2. EXO's products are components. The components today are Exo ID (sign-in for an app's users), Exo Key (keys and headless sign-in for agents, the CLI and MCP), Exo Deploy, EXO Verify, Exo Analyze, Exo Rank (model routing; code and URLs still say router), Exo Inform (docs and READMEs that agents and people can read) and the other services in the platform and stack docs, such as the Bird communications layer and Construct.
  3. People build apps. Each app picks the components it needs. It is modular, and no app uses everything. An app declares its components in project.yaml as a top-level components list (schema 1.10). Components come in two tiers:
    • Core components, the ones most apps need: source, identity (Exo ID), preflight (EXO Verify Level 1), runtime, secrets, evidence and data (Convex).
    • Specialty components, the ones only some apps need: comms (Bird), payments, models (Exo Rank), support (Exo Ask, proposed), analytics (Exo Analyze) and surfaces (Construct). Not every app needs comms and support, or an AI router like Exo Rank. (This tier was briefly called "add-ons"; the owner renamed it "specialty components" on 2026-10-13.)
    • The tiers are a docs and design grouping. Source control and the control plane are recommended but optional, and an app may opt out of either. The schema-required list is therefore preflight, runtime, secrets and evidence, plus identity unless signIn is false; ADR 0011 also required source. data is shown as core but is not schema-required.
    • The catalog and the wiring checks are unchanged (a declared source must still be wired to Entire); apart from source becoming optional, only the name and where the list lives change (base.parts becomes components, base.signIn becomes signIn).
  4. Apps, in every piece of prose. An app is visualized as a rocket ship in artwork, but the prose always says "app". "Ship" is no longer a product noun.
  5. Starter kits. A starter kit is a saved set of components that new apps start from, for a family of apps that share the same components. It is a convenience for creating apps, not a runtime layer; each app still declares its own components.
  6. Separate accounts, not separate Bases. Anything that needs walled-off money or data is a separate account on EXO, with its own users, data, secrets, environments and audit trail.
    • Foundation's donor money lives in its own account on EXO; its landing page stays a Surface in Construct.
    • Hadron is an app in the Interspace account.
    • If Hadron is sold, each customer gets their own account on EXO and their own Hadron app, the same pattern as Parlour's Construct.
  7. Launch is unchanged. Launch means an app version reaching Production through the owner-approved promotion. Staging is the launch pad, EXO Verify is the preflight, and rollback means relaunching an earlier version. Environment names stay Staging, Release Candidate and Production.
  8. Construct is unchanged. Construct publishes Surfaces (web, PWA, iOS and Android, or any combination) and the Cards on them. Surfaces and Cards are published, not launched.
  9. Placement rule, restated. Something is a Surface in Construct if it is mostly screens over Construct's components. It is its own app if it has its own backend and data. It gets its own account on EXO only when it needs walled-off money or data, for example regulated money or a different owner.

Consequences

  • Code, schema field names, Convex tables and URLs keep app (for example staging.exo.now/{app}). No data migrates and no URL changes.
  • project.yaml schema 1.10 moves the catalog to a top-level components list and signIn ($defs.component and $defs.componentsList in the schema). A 1.10 declaration must list components and must not keep a base block. 1.9 base.parts is still accepted as legacy (EXO Verify reports a skip pointing at 1.10), and 1.8 declarations without components are still skipped.
  • The EXO Verify Level 1 module is renamed from lib/level1/base.mjs to lib/level1/components.mjs (exports COMPONENTS, REQUIRED_COMPONENTS, validateComponents, componentsChecksFor), and its check names say components (components declared, components required core, component data wired).
  • The Entire contract role stays primary-host. Prose that called Entire "the primary forge" now says "primary source host". Contract constants such as forge-change and primaryForge are code identifiers and are unchanged.
  • Rollout covers the homepage, docs overview, platform index, README, llms.txt, the repository contract, EXO Verify Level 1 docs, AGENTS.md, HANDOFF.md and the changelog. Deeper docs that still say App, or Exo Router for Exo Rank, are already correct in meaning and move over as they are next edited.
  • Starter kits and accounts on EXO are named here but not yet modelled in code or schema; that is later work.

Source: docs/adr/0013-exo-is-mission-control-apps-pick-components.md

On this page