d7d1a490f9
The estate has built multi-tenancy across five documents that each cover a slice and do not compose. This records the whole model and names what is missing. Core framing: multi-tenancy here is four orthogonal planes — identity, authorization, data isolation, placement — not one property. Identity and authorization are ratified and solid. Data isolation is stated but unverified. Placement is owned by nobody and is precedent-by-accident. Three findings that motivated the draft: - R0 -> R1 -> R2 does not improve tenant isolation at all. Those rungs buy consumer isolation and capacity. Only R3 makes the tenant boundary structural. A plan tier selling R2 as isolation would be false. - No fleet mechanism verifies that any consumer actually enforces the tenant boundary it is obliged to enforce. A missing WHERE tenant_id would be a cross-tenant breach that no probe fails and no log shows as an error. Highest-severity gap; needs an appointed owner. - platform-pg holds roughly six consumers (100 max_connections, 14 each) and memory likely binds before connections do. Two are provisioned. The runway is shorter than the ladder implies. Also reconciles two already-ratified and contradictory defaults: instance-per-client for business apps, pooled for platform services, with no rule for telling a new service which it is. Proposed, not ratified. Carries a ratification path so it does not join the shared-platform-relational-storage draft in limbo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| architecture | ||
| constitution | ||
| projects | ||
| standards | ||
| tpsc | ||
| values | ||