carlos / platform Public

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>
Paul Campbell 34a6c1e0994b3adcb3b68ed8abc125d06e5e2e97 parent 1d76bdb
2 files changed, +21 −1
  • docs/superpowers/specs/2026-08-01-carlos-platform-design.md +15 −1
  • docs/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 |