Regions become a per-deployment registry, not platform constants
Platform spec: region registry in the bucket (code, location, regional bucket, optional edge home); adding a region = registration + capacity; signup residency choices, wake eligibility, and relocation targets all derive from it. Tito spec: its five regions noted as one deployment's registry values.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2 files changed,
+21
−1
docs/superpowers/specs/2026-08-01-carlos-platform-design.md+15 −1docs/superpowers/specs/2026-08-01-tito-production-infra-design.md+6 −0
diff --git a/docs/superpowers/specs/2026-08-01-carlos-platform-design.md b/docs/superpowers/specs/2026-08-01-carlos-platform-design.md| index 93ff8bc3f..bf2169ec5 100644 |
| --- a/docs/superpowers/specs/2026-08-01-carlos-platform-design.md |
| +++ b/docs/superpowers/specs/2026-08-01-carlos-platform-design.md |
| @@ -83,7 +83,8 @@ State hierarchy in the bucket: |
| │ ├── channels (lease-guarded pointers to releases) |
| │ └── instances (records, leases, streams, parked databases) |
| ├── environment profiles (glue binding sets: sandbox, production, …) |
| - └── placement pools (shared, dedicated pools; host regions) |
| + ├── region registry (registered regions: code, location, buckets) |
| + └── placement pools (shared, dedicated pools; hosts tagged by region) |
| ## 4. Apps, releases, and channels |
| @@ -236,6 +237,19 @@ but serves no requests: digest senders, indexers, schedulers. |
| Hosts belong to **pools**: the `shared` pool and named dedicated pools. |
| Hosts carry a **region** attribute. |
| +**Regions are deployment configuration, never platform constants.** A |
| +deployment's **region registry** lives in the bucket: each entry declares |
| +a customer-visible code (`ie`, `au`, …), its provider location, and its |
| +region-scoped bucket (or bucket partition). Adding a region to the mesh |
| +is registration plus capacity — write the registry entry, create the |
| +regional bucket, point hosts at the deployment — and everything |
| +downstream derives from the registry: the residency choices offered at |
| +signup, wake eligibility, relocation targets. Which region (if any) |
| +homes the edge/control plane is likewise a registry attribute, not a |
| +platform assumption. A single-region deployment is simply a registry |
| +with one entry; the flagship, Tito, and Eleven each carry their own |
| +region sets. |
| + |
| - **Shared tier** — instances co-reside with other apps' instances on |
| fleet hosts. The default; fine for E2EE apps, whose hosts hold only |
| ciphertext regardless. |
diff --git a/docs/superpowers/specs/2026-08-01-tito-production-infra-design.md b/docs/superpowers/specs/2026-08-01-tito-production-infra-design.md| index 99e3a379f..057abc3ab 100644 |
| --- a/docs/superpowers/specs/2026-08-01-tito-production-infra-design.md |
| +++ b/docs/superpowers/specs/2026-08-01-tito-production-infra-design.md |
| @@ -85,6 +85,12 @@ supersedes; outcomes stand, mechanisms defer to the platform: |
| ## 3. Regions |
| +This table is **this deployment's region registry** (platform spec §6) — |
| +configuration, not platform architecture. Tito launches with five |
| +entries and homes its edge in IE; adding a sixth region later is a |
| +registry write plus a tofu `region` module instantiation, and other |
| +deployments (Eleven, the flagship) carry entirely different sets. |
| + |
| | Code | AWS region | Role | |
| |---|---|---| |
| | `us` | us-east-1 | instance region | |