Tenets
The four principles behind every Exo decision, and the concrete rules that enforce them.
The four tenets appear on exo.now. This page pairs each one with the repository rules that turn it into behavior.
1. Opinionated, not restrictive
A clear operating model and reusable primitives—then enough room for every property to remain unmistakably itself.
What it means in practice:
- One design foundation, many expressions. The Structured Liquidity foundation is mandatory
for every Exo-managed application: shadcn primitives, square geometry, a controlled visual
vocabulary, and visible focus. Tenants still choose their own palette, typography, imagery, and
content density through documented tokens
(design standard).
pnpm check:ui-systemenforces the foundation, and it runs insidepnpm lint. - One promotion path. Every managed App uses the same Preview → Staging → Release Candidate → Production order (How work ships).
- One named standard per dimension. Each of the twelve stack dimensions names a preferred platform and the boundary it sits behind.
2. Open by preference
We start with inspectable, open-source foundations. Proprietary services must earn their place and stay behind a replaceable boundary.
What it means in practice:
- Open-source defaults where they exist: Convex Auth for identity, Expo (MIT) for mobile, Arch-Router (open weights, self-hosted) for exo-router's difficulty scoring, Vitest and Playwright for continuous integration, Puck for composition, shadcn/ui for the design system, and Twenty for CRM.
- "Proprietary managed services may be used operationally, but a self-hosted path must remain documented" (architecture).
- For any framework or platform choice, state the open-source status and license up front, and keep the free framework separate from the paid hosted service. For example, Expo is MIT and EAS is an optional paid service (exo-deploy).
3. Integrated, not locked in
Deeply integrated, never welded shut. Content exports as schema + NDJSON, media as files + checksums, design as tokens, routes with SEO and redirects, delivery as manifests, plus a deployable static archive. Leaving should be boring, complete, and documented.
What it means in practice:
- Portability is a product contract. Export is a normal authenticated action. It uses a documented, versioned format and needs no Exo account to read. There is no punitive exit fee; direct egress costs may be passed through (portability).
- Adapters, not integrations. Platforms sit behind Exo-owned adapters so that swapping one is an Exo change, not an App change. Examples: PostHog behind exo-analyze, Bird behind the communications layer, and the Convex AI Gateway behind exo-router.
- Vendor-neutral names. Sending subdomains are
mail.andinbox., neverbird., so a provider swap never touches DNS (Bird roadmap item).
4. Automated, not unsupervised
Machines observe, compare, and prepare. Humans approve consequential production, billing, domain, and data changes.
What it means in practice:
- Staging is automatic; consequential changes are not. Validated commits deploy to Staging without an approval step. Creating a Release Candidate, promoting to Production, changing DNS, paid plans, data migrations, credentials, and external communications each keep an explicit human approval gate (approval boundaries).
- Failures are loud. exo-router fails a job, and records the failure, rather than falling
back silently, because a silent fallback would hide a spend or configuration problem
(exo-router). Routing decisions made without an assessor are flagged
fallback: true. - Evidence over claims. Nothing is called live until the deployed commit, health, access boundary, and browser behavior are verified.
Source: content/docs/tenets.mdx