How work ships
Approval boundaries
The consequential actions that never follow implicitly from a validated commit, a green check, or a merged review.
Source: How Exo builds and ships.
The following never follow implicitly from a validated commit, staging integration, a green
check, a merged change review, a completed Exo item, or a project.yaml declaration:
- creating or replacing a Release Candidate;
- Production promotion or a public release;
- domain or DNS changes;
- adding or upgrading a paid service, or changing billing controls;
- database or persistent-data migration;
- credential creation, rotation, or provider-account linking; and
- external email or other communication.
These boundaries are deliberate. Routine code should move quickly to private Staging, and material business and production actions should stay unmistakably human decisions. This is the fourth tenet in practice.
Related gates
| Gate | What it checks | Source |
|---|---|---|
| projects.dev credential and spend gate | Environment match, credential inventory (names only), recent spend, a configured global spend limit that is not exceeded | Repository contract |
pnpm check:ui-system | Structured Liquidity foundation and visual vocabulary | Design standard |
| Staging evidence | Exact commit, /api/health, access boundary, environment label, browser pass | Environments |