| Document | Status | Lifecycle | Revision | Owner | Reviewed | Review due | Currency |
|---|---|---|---|---|---|---|---|
| NetKingdom Tenancy Posture v0.1 | proposed | active | draft-8 | net-kingdom | 2026-08-17 | 2027-02-17 | current |
Canon and architecture decisions at stable addresses, with visible currency.
| Document | Status | Lifecycle | Revision | Owner | Reviewed | Review due | Currency |
|---|---|---|---|---|---|---|---|
| NetKingdom Tenancy Posture v0.1 | proposed | active | draft-8 | net-kingdom | 2026-08-17 | 2027-02-17 | current |
A framework for describing, holding and improving multi-tenancy — including where we are not there yet.
Source: net-kingdom · canon/standards/tenancy-posture_v0.1.md · cced59d3aa1dc0aa08fc128fc8c76699f59dcd90
Review due: 2027-02-17
Proposed, draft-8; ratification-ready. Relocated from the-custodian/canon/architecture on 2026-08-17: multi-tenancy is part of the IT-security framework NetKingdom provides, so this framework belongs in NetKingdom canon beside the IAM Profile and the tenant-engine boundary contract, not in the work-factory canon.
R4 had no mechanism beyond waiting, and the noisy-neighbour evidence artifact asserted something shared infrastructure cannot provide.tenant-engine's review: five changes, including an axis that did not fit its data shape.audit-core, railiance-platform and flex-auth. Eleven further changes, two of them corrections to statements this document made as fact about other repos. Every posture I guessed was too generous, on every repo that has now self-reported.adaptive-pricing's review, the last of the six, and the consistency review across all declarations. It adds the missing availability axis, a canonical declaration schema, explicit authority for tier assurance, retention/placement coupling, downgrade propagation, and honest sanctioned customer language. It also corrects the distinction between an implemented control and an evidenced current level.Reviewed by all six. The score: six repos found three live defects in their own code by reading the ladders — tenant-engine's unfiltered event accessor, audit-core's unfiltered read path, flex-auth's unauthenticated /v1/check — and railiance-platform found apps-pg running with no backup configured at all while writing its §10.2 disclosure. The framework changed to fit the repos; no repo was told to fabricate a posture.
Informed by five external research digests plus their index in the-custodian/research/2026-08-17-adr008-*, which carry full citations for the external claims made here.
docs/platform-identity-security-architecture.md — accepted, 2026-07-23 — already uses plane for a trust and deployment layer: the bootstrap plane, the platform control plane, and tenant planes. That meaning is established, ratified, and owned by this repo.
Drafts 1–4 of this document, written elsewhere, used plane for something different: an independent dimension of concern. Two incompatible senses of one word inside one canon is exactly the concept-ownership collision the estate has been careful about elsewhere, and the newcomer yields.
+This framework therefore describes six axes. They are orthogonal to NetKingdom's planes, not a subdivision of them:
+A workload in the tenant plane has a position on all six axes. A platform control plane service does too. The two vocabularies compose and neither replaces the other.
+The rename is also an improvement. A posture vector is literally a point in six-dimensional space, and "axis" says that where "plane" did not.
+Drafts 1–4 opened by claiming the estate "has never written down what it is building". Relocation proved that wrong, and the correction is worth keeping visible: docs/platform-identity-security-architecture.md has described the trust model, the tenant model and a capability progression since 2026-07-23. The accurate claim is narrower — what was missing is a way to say how far a given service has got, and to hold several answers at once. Seven documents cover slices of the subject and none of them does that:
| Document | Covers | Status |
|---|---|---|
iam-profile_v0.3 (NetKingdom) | Tenant identifier shape, tenant_roles claim, staleness rules | Ratified |
tenant-engine-boundary-contract_v0.1 (NetKingdom) | Who owns tenant records, roles, plan assignment | Ratified |
business-app-service-contract_v0.1 §1 (Custodian) | Business apps: instance-per-client, tenant-keyed data | Ratified |
rapp-postgres ADR-0001 | Consumer + tenant isolation in PostgreSQL | Proposed, governs one repo |
rapp-postgres ADR-0002 | Per-consumer retention and the erasure horizon | Proposed, governs one repo |
shared-platform-relational-storage_v0.1 | The stacked-boundary gap | Routed 2026-08-10, still unratified |
platform-identity-security-architecture (NetKingdom) | Trust model, planes, tenant model, capability progression | Accepted 2026-07-23 |
This document is downstream of that architecture and must not restate it. It answers one question the architecture leaves open: given the model, where is this particular service today, and how would anyone know?
+Four failures existed when drafting began.
+The gap was diagnosed once and the fix stalled. The v0.1 draft was written to fill this hole and has sat unratified in neither canon directory. §20 attaches a ratification path so this one does not join it.
+Placement was owned by nobody. user-engine-pg and target-revenue-pg are dedicated; apps-pg, net-kingdom-pg, platform-pg, state-hub-db and forgejo-db are shared. Both live, neither written down. tenant-engine raised this with railiance-platform on 2026-08-16. Draft-8 resolves the authority split in §8.2.
Two contradictory defaults were already ratified. Business apps get instance-per-client; platform services pool. Nothing says which shape a new service takes, and no definition separates the categories. Decision 4.4.1 now supplies the default; §19.4 retains the missing classification rule.
+There is no honest way to describe a repo that is not there yet. The estate absorbs repos with weak or absent tenant separation. Today such a repo is simply non-conformant, leaving it two bad options: misrepresent its posture, or stay outside the framework.
+A framework, not a model. It specifies no single correct implementation. It supplies terminology (§3, §4), a declaration (§5), a conformance rule (§6), methodology (§12), and evidence definitions (§13).
+A service is conformant when its declared posture is accurate and its trajectory recorded. A service is non-conformant when it claims a level it cannot evidence — regardless of how high or low that level is.
+"Is this multi-tenant?" is treated as one question. It is six, and they are independent:
+| Axis | Question | Vocabulary owner |
|---|---|---|
| Identity (I) | How is a tenant named and validated? | tenant-engine / IAM Profile |
| Authorization (A) | How is a request bound to the tenants it may act for? | flex-auth |
| Enforcement (E) | Where, mechanically, is the tenant boundary enforced? | This framework |
| Placement (P) | Which substrate holds a tenant's data? | railiance-platform |
| Retention (R) | How long does data persist, and how is it erased? | The storage platform; policy by the consumer |
| Availability (V) | What failure can the complete service path survive, and within what recovery objective? | The delivering service; substrate facts by its providers |
Conflation produces errors today. rapp-postgres's PostgresConsumer carries tenantIsolation: consumer-service-boundary — an E-axis fact in a P-axis artifact, reading as though storage enforces something it does not. The "dedicated versus shared" argument mixes P (capacity, blast radius) with E (correctness).
The axes are separated precisely so each may sit at a different level.
+Decision 3.1: every document, declaration and plan tier that says "isolation" MUST name which axis it means.
+Decision 3.2: the axes couple at their tops and the couplings MUST be stated where they apply, not used to argue the axes are one:
+E4 is reachable only at P3 or above.R's erasure horizon is bounded below by P — on shared substrate, a consumer's horizon is the instance maximum (§4.5).R4 by key destruction is bounded by the key boundary, which is an E-axis property. Shredding a single tenant's data requires the application to encrypt under a per-tenant key before writing; the storage platform cannot supply it. Reaching the top of the retention ladder is not a retention project.V composes as the minimum across the critical request path, not the maximum of its components. A replicated application on a single-instance database is not V2. A tested degraded mode may remove a dependency from that path, but the bypass itself is part of the V evidence.Decision 3.3 — scope. The P and R ladders describe a service's primary datastore. The V ladder describes the service's complete critical request path, including providers it synchronously depends on. Caches, search indices, message queues and background jobs are named leak surfaces in the external baselines and are assessed separately, not silently covered by a datastore level. A declaration names material secondary stores and asynchronous paths as exceptions rather than implying that one vector proves them safe.
+Each axis carries an ordered ladder. Higher is stronger, not better: the right level is the one a service can evidence and its risk warrants.
+tenant-engine re-query for privileged, destructive, credential-vending or aal2-class decisions.I1 now explicitly absorbs request-supplied tenant identifiers. "Never trust client-supplied tenant IDs without validation" is a named anti-pattern; a service reading the tenant from a header is at I1 however canonical the string.
+An axis is assessed on a service's own inbound surface, never on its authority over the concept. tenant-engine is the source of existence for tenant records and is nonetheless at I1, because it takes the acting identity from the request body rather than from a verified token. Draft-5 conflated these by naming the authority inside the I2 definition, which made the level describing canonical identity unclaimable by the service that provides it. Corrected on tenant-engine's review — a reader would otherwise assume the authority must be at I2 by definition.
business-app-service-contract §2.1 sets app-local accounts as the v1 baseline for business apps — a sanctioned low level with recorded triggers for moving up. That is the pattern this framework generalises.
flex-auth as PDP, with live re-query where the IAM Profile requires it.This ladder describes enforcement points. A decision point cannot occupy A3 — "delegated to flex-auth" is not something flex-auth can do. A service that is a PDP declares two numbers: its own inbound level, and the maximum it enables for consumers. flex-auth reads A0, enables A3 — accurate, and considerably more alarming than A3, which is the point. Raised by flex-auth, whose absence from the §5 worked examples was this surfacing implicitly.
A4 is new. The specification reached Final in January 2026 and Keycloak shipped experimental support in May; the argument for it is interoperability — a swappable decision point and an enforcement point not coupled to one engine's request shape.
+Correction from flex-auth's review: earlier drafts also justified A4 as ending the copying of action strings between repos. It does not. AuthZEN standardises the envelope — subject, action, resource, context, endpoint — and deliberately does not standardise the action vocabulary or the policy language. At A4, tenant.guardrail.set still has to be agreed and still gets copied. Those are two problems with different fixes, and the cheaper one is not A4: flex-auth's registry already carries action definitions per system and could serve them read-only. The vocabulary argument is withdrawn.
Internal service-to-service calls are in scope for this axis. "Skipping tenant validation for internal services" is a named anti-pattern and our estate is mostly internal calls.
+Correction from flex-auth's review: earlier drafts asserted that flex-auth calls tenant-engine synchronously on the authorization path. That is not true. The adapter is built and complete and has no non-test caller, so the IAM Profile's live re-query exists and is unwired — which is also why flex-auth cannot reach I3. Built-and-unwired is the worst of the three states because it reads as capability.
The requirement, narrowed on their proposal because the original was too strong to be met and would have made tenant-engine a hard availability dependency of every decision in the estate:
Tenant context MUST be carried on every internal hop and MUST NOT be re-derived from a service identity. It MUST be revalidated against tenant-engine at least once per request chain — at the service that holds or mutates the tenant's data, or before a privileged, destructive, credential-vending or aal2-class decision, whichever comes first. A hop that neither holds tenant data nor makes such a decision may carry the context without revalidating it.
And carrying tenant context is worthless without an authenticated hop to carry it over. flex-auth found this in itself: it carries tenant context faithfully and cannot distinguish "user-engine asking on behalf of tenant X" from "any pod asking on behalf of tenant X".
Correction from draft-2. Draft-2 described E3 as something "the application cannot trivially route around". That is false and it was this document overclaiming in exactly the way §6 prohibits. Any session can re-issue SET on a custom GUC, so an attacker with SQL execution can reset the tenant and read across the boundary. What E3 buys is precise, and the ladder must say so:
| Threat | E1 | E2 | E3 | E4 |
|---|---|---|---|---|
| A developer forgets a tenant predicate | ✗ | ✓ | ✓ | ✓ |
| A new code path bypasses the choke point | ✗ | ✗ | ✓ | ✓ |
| SQL injection reaching the connection | ✗ | ✗ | ✗ | ✓ |
| The application process is compromised | ✗ | ✗ | ✗ | ✓ |
E3 is a strong control against accident — the common case, and the one that causes real breaches — and no control at all against compromise. Only E4 holds against both, because the credential itself cannot address another tenant's data.
+Correction: E3 layers on E2, it does not replace it. External practice treats application-layer and database-layer filtering as complementary. A service that dropped its choke point on reaching E3 would be worse off, since E3 fails open under injection. Claiming E3 therefore requires the E2 evidence artifact as well.
+Correction: the GUC is set transaction-locally. Draft-2 said "at pool checkout", which is session scope and the wrong instrument. Under a pooler in statement mode, SET leaks between clients and returns other tenants' rows — a failure that appears only under production concurrency and produces no error. Use SET LOCAL inside an explicit transaction.
Platform enforcement is a platform obligation. Reaching E3 requires the storage platform to offer the mechanism: provisioned policies, a documented GUC contract, and a probe. Where a consumer wants E3 and the platform has not supplied it, the gap is the platform's. §19.6 asks rapp-postgres to define that contract, which must carry FORCE ROW LEVEL SECURITY on every tenant table (without it the table owner bypasses policies silently, and ADR-0001 already established that our migration role owns the tables it creates), no BYPASSRLS on leased roles, SECURITY INVOKER for ordinary logic, and an EXPLAIN comparison because RLS disables functional indexes built on non-leakproof functions.
Not all data is tenant-keyed, and the ladder must not pretend otherwise. A registry whose rows are the tenants has no per-tenant predicate to scope a policy by; enforcing one would break the service's function rather than secure it. tenant-engine's tenants table is the worked example — key-cape enumerates it at token issuance and flex-auth queries it live, both of which are cross-tenant reads by design.
A service with mixed data shapes declares E-level plus a registry exception: the level its tenant-keyed tables hold, and a named list of tables excluded because they are registries rather than tenant data. The exception is part of the claim and is reviewable; an unnamed exception is an overclaim. Without this, mixed-shape services either overclaim or stay at E2 permanently, and tenant-engine declined to claim E3 on precisely that reasoning.
Default expectation for a new platform service: E2 at first serve, E3 recorded as target. Services whose cross-tenant exposure would be a reportable breach SHOULD target E3 or above.
+Enforcement and placement are independent axes. Plotted together, with where each service actually sits — parenthesised entries are targets or defaults rather than current positions, and — marks a cell the coupling in §3.2 makes unreachable:
P0 → P1 → P2 is movement along the horizontal axis only. Those steps buy consumer isolation, capacity predictability, independent retention and a smaller operational blast radius. They do not raise the tenant boundary by one step. Only P3 makes E4 reachable. This is the most misusable fact in the framework and §11 governs how it may be described.
+Decision 4.4.1: P1 is the default for platform services; P3 for client-facing business apps, as already ratified. A service unsure which it is must resolve that first (§19.4).
+Decision 4.4.2 — placement scopes to data substrate. Identity-provider placement (realm-per-tenant versus Organizations) is the same silo/pool decision on a different substrate, is live in our estate, and is undecided. Realm-per-tenant carries a stated ceiling around 5–20 tenants, far below our target. Recorded here as a parallel question (§19.7), not folded into P.
+New in draft-3. Implemented abstractly by the storage platform for any dataset; policy is built on top of that interface by the consumer or its governance layer. Reference implementation: rapp-postgres ADR-0002.
R4 has two routes and a service MUST name which one it uses.
+| Route | Mechanism | Cost |
|---|---|---|
| Horizon-elapsed | Wait out the published erasure horizon; the data ages out of every retained copy. | Available to everyone, proves little, and the wait is set by a co-resident's retention requirement rather than your own. |
| Key-destroyed | Encrypt per entity, then destroy the key. Retained copies survive but are unreadable. | Requires per-entity keys, strong encryption, and an auditable destruction record. Immediate. |
Decision 4.5.3 — key destruction is not sufficient on its own. The key-destroyed route requires that no retained commitment reveals the erased content. Found by audit-core, and it is a general defect rather than a fact about them:
So a service claiming R4 by key destruction must show that its retained commitments — hashes, chains, indexes, search keys — do not reveal what was erased. The remedies are an HMAC under a per-subject key that dies with the key, or a per-record salt destroyed alongside it. audit-core cannot reach R4 under its current design and targets R2; a fleet R4 target must exempt it explicitly.
Regulatory standing of the key-destroyed route, stated carefully because overclaiming here is worse than anywhere else in this framework. Data protection authorities have accepted key destruction as erasure where physical deletion would be manifestly disproportionate, and the practice is recognised under conditions — strong encryption, irreversible destruction, and an auditable record of it. The EDPB has not formally endorsed it as Article 17 erasure. A service reaching R4 by key destruction is making a defensible claim, not a settled one, and must say so rather than reporting a clean "deleted".
+Three further properties.
+The erasure horizon is the interval between deleting data and it ceasing to be recoverable from anything the platform holds. Deleting a row does not remove it from yesterday's backup. With an N-day window, deleted data remains recoverable for N days. That is the difference between "deleted" and "erased" and the estate had never written it down.
+On shared substrate, retention is not per-consumer. Physical backup is instance-wide — one WAL stream, one window — so the instance retention is derived as the maximum across co-resident consumers, and every consumer's horizon is that maximum. A consumer declaring 7 days beside one declaring 90 gets 90. This is the retention analogue of ADR-0001's blast-radius disclosure: state the coupling rather than imply an isolation that is not there.
+Retention is therefore a placement trigger. A consumer needing a horizon shorter than the instance floor cannot have one at P1. It moves to P2 for a reason with nothing to do with performance — which is exactly why it needs recording, since nobody looks for a retention argument when reviewing placement.
+Decision 4.5.4 — a retention promise binds both R and P. A tier making a retention claim records an R minimum and a maximum erasure horizon in days. It also requires P2 or above unless its provider contract guarantees that the shared-substrate horizon stays within that maximum and rejects or notifies before a co-resident change would extend it. A bare R2 minimum is insufficient: at P1 another consumer can change the promise without changing the tier or its holder.
Deletion splits mechanism from policy. The platform deletes whole datasets on instruction and records an opaque policy reference it never interprets, so every deletion traces to what authorised it. Rows are not a dataset: row expiry is the consumer's own DML under its migration lease. Dropping a consumer's whole database is an operator-gated offboarding step, never a scheduled one.
+New in draft-8. adaptive-pricing found that §11 required availability claims to map to a minimum level while the framework supplied no availability vocabulary. Placement is not a substitute: a dedicated cluster can still be a single instance on a single node.
Decision 4.6.1 — V is end-to-end. A service declares the minimum across the components and synchronous providers required to serve the operation. An application with three replicas over a V1 database is V1. A status page or replica count is not evidence of a higher level.
+Decision 4.6.2 — availability claims name the operation. A read-only degraded mode and a mutation path may have different V levels. Decision 5.2 applies: declare the paths and quote the minimum unless the customer-facing claim explicitly and unambiguously names the narrower operation.
+A service states one level per axis, plus a target, review dates, evidence and any exceptions. current is the highest evidenced level; a control present in code but still awaiting the evidence required by §13 goes in implemented, not in current:
schema_version: "0.1"
+framework: netkingdom-tenancy-posture
+service: example-service
+role: tenant-data-service
+tenancy:
+ current: { I: 2, A: 3, E: 2, P: 1, R: 1, V: 1 }
+ implemented: { E: 3 }
+ target: { I: 2, A: 3, E: 3, P: 1, R: 2, V: 2 }
+ reviewed: "2026-08-17"
+ review_due: "2027-02-17"
+ service_class: interactive
+ gap:
+ E: "RLS is implemented; the §13 E3 probe is still absent."
+ R: "Retention declared; erasure horizon not yet published to consumers."
+ V: "Automated failover is not implemented or exercised."
+evidence:
+ A3: "docs/evidence/authorization-denial.md"
+ E2: "docs/evidence/cross-tenant-review.md"
+ P1: "rapp-postgres/docs/evidence/isolation-2026-08-10.md"
+Placement exceptions. Draft-2 assigned one P level per service, which cannot express the vertically partitioned model — most tenants pooled, some dedicated — that §11's isolation tiers require. A tier requiring P2 bought by three tenants would put the service at two levels at once, forcing an over- or under-claim. Placement is therefore declared as a default plus exceptions:
placement_exceptions: + - tenants: ["tenant:enterprise:*"] + P: 3 + reason: "isolation tier; see adaptive-pricing tier definition"+
A service with exceptions must be able to say which tenants are on which substrate. That mapping is a first-class artifact, not archaeology.
+Decision 5.5 — a provider declares what it makes reachable, not where it sits. The six ladders describe a consumer of infrastructure. They describe a provider of it badly, and railiance-platform's review demonstrated how badly: apps-pg is I0 A0 E0 because a database has no tenant concept, carries no tenant claim and applies no tenant predicate. Those zeros are structural, not weak — the cluster is exactly as strong as its consumers make it.
The sharp case is OpenBao at E0. Literally correct, and actively misleading: the mechanism in place is credential-scoped structural separation — E4 machinery — pointed at a consumer boundary rather than a tenant one. A reader scanning a column of E values would rank it below a service doing per-query filtering in application code, inverting the real security position.
So a platform service additionally declares, per axis, the level available now, the maximum it can make reachable, and what a consumer must do to reach it. For apps-pg: E4 unreachable (shared credential per consumer, no per-tenant credential), E3 conditional on the GUC contract, R2 blocked on a backup target, V1 at most on the single-node rail. That is the sentence a consumer actually needs, and no arrangement of the consumer ladders produces it.
A provider's own P is n/a, not a number. apps-pg provides P1; it is not at P1, and writing P: 1 there would later read as an isolation claim.
Worked examples after applying the evidence rule and minimum-across-paths rule consistently:
+| Service | Current | Notes |
|---|---|---|
tenant-engine | I1 A0 E1 P n/a R0 V0 | Acting identity is caller-supplied; unauthorised read paths set the A minimum; E2-shaped child-table controls are not evidenced; SQLite is outside P; no erasure or availability evidence. This corrects draft-7, which quoted A2/E2 despite its own minimum/evidence rules. |
audit-core | I1 A2 E1 P1 R2 V0 | E2 is implemented on both paths but awaits the adversarial artifact, so current remains E1. Its 30-day retention and erasure horizon are now declared and published. |
flex-auth | I1 A0 E1 P n/a R n/a V0 | Enables A3 for consumers. /v1/check authenticates no caller; E2 is implemented but not evidenced. |
platform-pg (provider) | I0 A0 E0 P n/a R2 V1 | Provides P1; backup/restore and single-node recovery are evidenced. Provides no tenant boundary by itself. |
apps-pg (provider) | I0 A0 E0 P n/a R0 V0 | Zeros are structural, except R0/V0 are live gaps: no backup and no recovery evidence. |
adaptive-pricing observatory | I0 A0 E0 P n/a R n/a V0 | Local, unauthenticated, single-user analysis surface; not a production service. |
| A newly absorbed repo | I1 A1 E1 P0 R0 V0 | Conformant if declared, with a recorded path. |
Decision 5.1: the posture vector is declared in the repo, not in the hub, consistent with local-files-are-source-of-truth.
+Decision 5.2 — declare per path, quote the minimum. A service whose mutations are authorized and whose reads are not is at the reads' level. The quoted number is the minimum across paths; the per-path detail is declared beside it.
+Draft-6 required only the minimum, on tenant-engine's review. audit-core then showed why that is insufficient on its own: a bare minimum destroys signal, because E3-write/E1-read declares identically to E1/E1. Bare per-path invites "our write path is E3", which is the sentence §6 exists to stop. Both, related explicitly, is the rule.
Two services found this shape in themselves within a day of each other — tenant-engine (writes authorized, three read routes not) and audit-core (write path tenant-filtered, read path not filtered at all). Most services enforce harder on write than read, so this is the common case, not the corner.
Decision 5.3 — n/a is a level, and it is conformant. P0 presupposes a shared database and R0 presupposes retained data. A service holding nothing at rest — flex-auth runs with its registry and policy baked read-only into the image and no decision log persisted — is neither. A datastore outside a ladder's substrate vocabulary, such as tenant-engine's current SQLite PVC, also uses n/a rather than inventing a level. Without an admissible n/a, a missing rung forces the fabrication §6 prohibits, which is precisely what draft-1 was rejected for. n/a is declared with a stated reason.
Decision 5.4 — the vector lives at tenancy.yaml in the repo root. Draft-6 said "in the repo" and not where or in what shape, which left §12's guard needing per-repo archaeology. flex-auth adopted tenancy.yaml speculatively; adopted here as the convention. A repo representing one service uses the single-service form above. A layer repo uses the schema's services list in the same root file — one vector per service, never an average. The normative schema is canon/schemas/tenancy-posture_v0.1.schema.json; prose documents may explain a declaration but do not replace it. The schema carries current, implemented, target, reviewed, review_due, gap, placement_exceptions, service_class (§8.3), per-path detail (§5.2), and provider reachability (§5.5). From the net-kingdom repo, owners validate one or more declarations with uv run tools/tenancy-posture/validate.py <path>...; the validator applies the JSON Schema and the evidence, date, implemented/current and provider-range rules that JSON Schema alone cannot express.
A service is conformant when its declared posture is accurate, its target is recorded, and it does not claim a level it cannot evidence. It is non-conformant when it overclaims — at any altitude.
E0 is conformant. Concealing E0 is not.flex-auth is I1 and always will be: a decision point evaluates the claims it is handed, and verifying its own inputs would make it the identity provider its scope refuses to be. A target equal to current with a reason is a settled position, not a stalled trajectory, and §12's guard must not nag it as though it were one.Decision 6.1 — downgrades propagate. Before a planned downgrade of a current level or a provider's available level, the declaring repo MUST resolve the tier definitions and consumers that reference it. A downgrade below a recorded minimum blocks the change until the claim is changed, the workload is moved, or the affected owner explicitly accepts the gap. An unplanned regression is an incident and triggers the same notifications. Updating tenancy.yaml without notifying dependants is declaration drift, not a completed downgrade.
Without the axis separation, "not rigorous about tenant separation" is one verdict a repo passes or fails. With it, the same repo is I1 A1 E1 P0 R0 V0 with a path — a plan, not an indictment.
Movement between P levels must be operational, not a rebuild:
+Decision 7.1: mandatory at P1 and above. At P3, SHOULD rather than MUST — a per-client instance that never moves is not misconformant for naming its own database.
+Recorded at provisioning time: noisy neighbour on a latency-critical path; a compliance or residency requirement; a plan tier requiring a higher minimum; an erasure horizon that no longer fits (§4.5); connection or memory ceiling reached.
+Decision 8.1: triggers MUST be monitored, not merely recorded. A trigger in a YAML comment nobody re-reads is documentation, not control.
+Decision 8.2 — split authority, machine-reconciled. railiance-platform owns the placement rule; the package repo owns the substrate numbers and enforcement; the consuming repo owns its workload requirements; adaptive-pricing owns any tier minimum. adaptive-pricing declined a standing co-signature and the framework accepts the replacement: typed tier minima are joined to consumer and provider declarations at tier definition and whenever one changes. A machine-checkable constraint must not depend on somebody remembering to collect a signature.
Decision 8.2.1 — trigger monitoring has an owner. The provider monitors capacity ceilings and co-residency; the consumer monitors latency, compliance and erasure requirements; adaptive-pricing monitors tier-definition changes. The placement owner reconciles those signals. A trigger marked unmonitored is an explicit gap and cannot support a customer assurance claim.
A latency-critical consumer and a batch consumer can share an instance today with nothing distinguishing them. tenant-engine sits on flex-auth's synchronous authorization path and chose a 5s statement timeout for that reason; audit-core, co-resident, is not latency-critical. Nothing prioritises between them.
The framework does not add a QoS axis, because the platform cannot enforce one. Community PostgreSQL has no resource governor: no per-role CPU or I/O priority, no resource queues, no workload classes. Those exist in EDB's enterprise variant, in Greenplum, and in SQL Server — not in what we run. A declared priority level would therefore be an unenforced claim sitting in a declaration, which is precisely what retiring tenantIsolation was about. An axis implies graduation and enforcement; this has neither.
Decision 8.3.1 — co-residents are equal. On shared substrate no consumer's query yields to another's. A consumer whose latency requirement cannot survive an unprioritised neighbour must escalate to P2. That is the honest mechanism and it is the only one we have.
Decision 8.3.2 — service class is declared anyway, as a category rather than a level: latency-critical, interactive, or batch. It buys three things, none of which is priority:
latency-critical with batch on one instance is a recognised mismatch. It may still be the right call — it is right today — but it should be a decision, not an accident of who was provisioned when.latency-critical consumer acquiring a batch co-resident is a recorded placement trigger under §8, on the same footing as noisy neighbour.batch may be an outage for latency-critical.Decision 8.3.3 — class mixture must be visible. The platform reports which classes are co-resident. An unenforceable risk that nobody can see is strictly worse than one that is stated.
+The known escalation short of P2 is gateway-level prioritisation — ordering submissions in a connection proxy by the requesting tenant's current consumption. It is real, it is where the industry puts this when it must, and it is new infrastructure we do not run. Recorded as the option, not adopted.
+Short-lived leased credentials re-read at connection checkout, with overlap-first rotation, bound the residual risk at every E level below E4: a leaked credential expires rather than persisting. Stronger than the industry norm of a long-lived per-service secret.
+Decision 9.1: static long-lived database credentials are not a sanctioned path for any service above E0.
+Decision 9.2 — the rule extends to consumer-facing credentials. Draft-6 named database access only. audit-core pointed out that its ingest credentials are static long-lived bearer tokens, rotated by publishing a second alongside the first — and that the argument applies with more force to the credential that actually carries the tenant claim than to the one that reaches the database behind it. Read as an accidental omission; it was. Consumer-facing credentials are named in. Where a service cannot yet meet this, it is a stated gap rather than a silent exclusion.
Decision 10.1: every platform holding consumer data MUST publish, in concrete terms, what a leaked runtime credential can and cannot reach at the levels it operates. rapp-postgres ADR-0001 §5 is the reference. Where the model cannot provide a guarantee, the platform says so and names the escalation.
Decision 10.2 — quotas are disclosed, not discovered. The same obligation extends from what a leaked credential can reach to what the platform will refuse to do for you. Every consumer MUST be told, at provisioning, the throttles and quotas enforced against it — connection limits, statement timeouts, idle-transaction timeouts — and told again when they change. A consumer learning its statement timeout by hitting it in production is a disclosure failure, not a consumer bug. This is how tenant-engine was provisioned, by good practice rather than by rule; the rule now exists.
E3 P2 R2 V2 and a maximum erasure horizon; it need not print those labels anywhere customer-facing.tenancy.yaml is authoritative for the delivering service's current level; provider declarations are authoritative for what infrastructure makes available. None is derived by copying another. Approval joins them and fails closed on a missing, stale or insufficient declaration. A performance-differentiated tier requires P2 or an enforceable resource governor; service class alone grants no priority.Analyze. Assess a repo against the ladders; produce tenancy.current with reasoning recorded. Applies to new and absorbed services alike.
Establish. Declare the target and gap. The target is set by data class, tenant groupings served and plan tiers carried — not by ambition.
+Improve. Move one axis at a time. Raising P while leaving E untouched is the characteristic misstep.
+Guard. Verify continuously that the declared posture holds — against the service's own declaration, not a universal maximum. Nobody must prove every service is at E4; the check is that none is below what it declared.
+Regression found by guarding is a defect; regression declared in advance is a decision. The estate has been bitten twice by silent pin rollbacks producing ordinary-looking 403s and 404s rather than errors. Posture regression looks the same — an RLS context leak returns correct-looking rows for the wrong tenant. Guarding must be designed for invisible failure, not for crashes.
+Decision 13.1: a current level is claimed only with its evidence artifact present. This turns §6's accuracy rule from an honour system into a check. implemented records a control observed in code or configuration whose required artifact is still absent; it never satisfies a tier minimum.
Decision 13.1a — the floor needs no artifact, only a reason. Found independently by audit-core and flex-auth: the table below defines artifacts from I2, A2, E1, P1, R2 upward and none below, so a literal 13.1 made the lowest rungs unclaimable — including §5's own worked example of a conformant absorbed repo, I1 A1 E1 P0 R0, which could not satisfy it on any axis. A rule that forbids the declaration §6 exists to permit is a defect in the rule.
At I0/I1, A0/A1, E0, P0, R0/R1, V0, or n/a, a declaration requires a stated reason, not an artifact. Evidence is what stops you overclaiming, and there is nothing to overclaim at those floors.
Decision 13.4 — an artifact must assert something achievable. Draft-3's noisy-neighbour evidence required proof that a saturating consumer "does not breach" another's allowance. Shared infrastructure cannot provide that; the risk is inherent and cannot be wholly removed. An artifact that can only fail, or that passes by being run gently enough, is an overclaim wearing the costume of evidence. Where a property cannot be guaranteed, the artifact measures and records it instead.
+Decision 13.2 — evidence is of two kinds, and conflating them is an overclaim. Mechanical evidence is a structural assertion a machine can make and belongs in CI. Adversarial evidence is semantic, requires setting up separate tenant contexts and comparing responses, and carries a review date rather than a green build. Cross-tenant findings are the category external testing practice identifies as needing human review. A passing CI run is not E2 evidence.
+| Level | Evidence | Kind |
|---|---|---|
| I2 | Identifiers validated against the vocabulary; rejection test for a malformed id; binding shown to come from a verified token | Mechanical |
| I3 | Live re-query demonstrated on an aal2-class path; cached-claim path shown unused there | Mechanical |
| A2 | Choke point identified; test that an unbound request is refused | Mechanical |
| A3 | Live decision with a denial observed at the endpoint, not only at the decision surface | Mechanical |
| A4 | Decision served over the standard interface; a second PDP substituted without PEP change, with the decision differences between the two recorded — substitution proves interface portability, not decision equivalence | Mechanical |
| E1 | Every tenant-owned table carries the tenant key | Mechanical |
| E2 | Choke point identified; identity bound to tenant A demonstrably cannot read tenant B | Adversarial, with a review date |
| E3 | FORCE ROW LEVEL SECURITY on every tenant table; no BYPASSRLS on leased roles; probe that a session without the GUC reads nothing; probe that a wrong GUC reads nothing; EXPLAIN comparison | Mechanical |
| E4 | Per-tenant credential demonstrated unable to connect to another tenant's substrate | Mechanical |
| P1–P4 | Provisioning declaration plus the platform's isolation probes | Mechanical |
| Shared P1–P2 capacity assurance | A recorded baseline of per-consumer resource usage; a run in which one consumer saturates its declared allowance; evidence that the governance controls bind (the greedy consumer is held at its limits) and that the degradation co-residents experience is measured, recorded and judged acceptable against each one's declared service class (§8.3); the aggregate headroom at time of measurement | Adversarial, load-generated, with a review date |
| R2 | Declared retention rendered; erasure horizon published and reported in the operator surface | Mechanical |
| R3 | Sweep evidence records: timestamp, dataset, identifiers removed, authorising policy reference | Mechanical |
| R4 | Erasure demonstrated across live data, backups and derived copies within the horizon | Adversarial |
| V1 | Critical dependencies enumerated; restart/recreate recovery exercised; interruption and measured recovery time recorded | Mechanical exercise |
| V2 | One instance terminated while traffic continues or recovers automatically; measured RTO/RPO and remaining shared failure domains recorded | Adversarial, failure-injected |
| V3 | Declared failure domain removed in an exercise; complete critical path and degraded modes observed against RTO/RPO | Adversarial, failure-injected |
| V4 | Region made unavailable in an exercise; traffic and state recover in the alternate region against RTO/RPO | Adversarial, failure-injected |
The P1–P4 artifact proves the declared placement topology. The shared-capacity artifact is additional: it is required before a P1/P2 service can claim that a noisy-neighbour control binds, that the trigger is actively guarded, or that a customer performance assurance survives co-residency. It is not required merely to report the true topology as P1 or P2. No such capacity artifact exists in the estate today, so §11 requires P2 or an enforceable governor for a performance-differentiated tier.
+Decision 13.3: the tenant-boundary E2/E3 and noisy-neighbour artifacts do not exist anywhere in the estate today. rapp-postgres runs 19 adversarial probes, all against the consumer boundary, none against the tenant boundary inside a consumer. Externally, what this framework calls a tenant boundary failure is Broken Object Level Authorization — OWASP API1, top of the API Security Top 10 since that list launched, and the most commonly exploited API vulnerability in published assessments. We have no coverage for the highest-ranked risk in our class of system. §19.3 records the owner.
Decision 14.1: external research is design input. This estate adopts published standards and structural patterns; it does not adopt tooling unless that tooling is an established industry standard with broad application. Everything else is built ground-up, so it can be optimised and refactored as the estate sees fit.
+| Class | Stance |
|---|---|
| Security baselines (OWASP Multi-Tenant Security Cheat Sheet, API Security Top 10) | Adopt as the external reference our ladders answer to |
| Standards bodies (OpenID AuthZEN 1.0) | Adopt — this is what A4 is |
| Reference taxonomies (Azure tenancy models, AWS SaaS Lens, cell architecture) | Adopt as structure |
| Engine behaviour (PostgreSQL RLS mechanics) | Facts, not tooling |
| Third-party analyzers and test frameworks | Do not adopt. Take their rule taxonomies as checklists for probes we write ourselves |
The practical effect is small and good: rapp-postgres already owns a ground-up probe harness — bash and psql, no dependency tree — that found four real defects in its own provisioning SQL. The evidence artifacts in §13 become new probes in a tool we control. One idea worth reimplementing from the external survey is policy-diff classification: labelling a change to an enforcement policy as safe or breaking before it lands.
One fixed model with a single set of characteristics (draft-1). Rejected: cannot describe a repo that is not there yet, forcing absorbed repos to misrepresent their posture or stay outside. A framework that can only describe its own end state is not a framework.
+A maturity model with a single overall level. Rejected: collapses the axis separation. A service strong on identity and weak on enforcement has a specific, actionable gap; one composite score hides it and invites averaging.
+Prohibiting row-level security (draft-2's inherited position). Rejected in draft-2, refined in draft-3: RLS is a real rung against the common threat. The error was never RLS — it was describing E3 in E4's language.
+Schema-per-consumer in one database. Rejected: pg_catalog is readable per-database, so every co-resident enumerates every other's table and column names regardless of grants. Retained as a describable state, never a target.
Mandating E4 for everyone. Rejected: the tenant taxonomy includes consumer (private individuals) and family. A cluster per private individual is economically impossible; the taxonomy is itself evidence pooling is required.
Per-consumer physical backup retention. Rejected: CNPG retention is a property of the instance's WAL archive. There is no mechanism, and claiming it would be a fabricated guarantee. Hence the derived maximum in §4.5.
+Platform-scheduled row expiry. Rejected: requires the platform to hold DML authority over consumer schemas and interpret consumer data semantics, both forbidden by ADR-0001. The consumer's migration lease is the correct instrument.
+Leaving each repo to its own model. Rejected: the status quo, which produced two contradictory ratified defaults and an unowned placement question.
+The graduated reframe is corroborated, not invented here. Microsoft's tenancy-model guidance states it almost verbatim: "Instead of viewing isolation as a discrete property, consider it a spectrum. You can deploy components of your architecture that are more isolated or less isolated than other components in the same architecture." The same guidance derives our E↔P coupling independently — shared deployment means enforcement lives in application code; dedicated deployment means it is structural.
+Stronger than typical. Most multi-tenancy literature models one boundary, tenant-to-tenant. This estate has two stacked boundaries: platform-service to platform-service, and tenant to tenant inside a consumer. Naming them separately and refusing to enforce both with one mechanism is uncommon and correct. Graduated per-axis levels also beat the silo/pool/bridge trichotomy, which is approximately our P axis with the other four missing — which is why it cannot express "pooled infrastructure, structurally enforced boundary".
+Weaker than typical. The pool model's standard mitigation is a verified enforcement layer every service is demonstrably routed through. We have the concept and none of the verification (§13.3).
+Adopted without naming it. Short-lived leased credentials re-read at checkout beat the long-lived-secret norm. §9 promotes it to a tenancy control.
+Still unexplored. Neither P nor R describes a cell — a slice of infrastructure with a fixed maximum size, sized so one cell's failure is survivable and cell count scales linearly. platform-pg is, in these terms, an uncapped cell: §17 computes a ceiling and nothing enforces it (§19.8).
Sources: the five research digests in the-custodian/research/2026-08-17-adr008-*, which carry full citations for the claims in this section.
Derived from the live platform-pg specification. Connection arithmetic is exact; the per-backend memory estimate remains unmeasured and is explicitly a gap in rapp-postgres ADR-0004.
instances: 1 (no HA; single-node rail) +max_connections: 100 +memory limit: 1Gi +per consumer: 14 connections (12 runtime + 2 migration)+
The hard connection bound is roughly six declarations; the enforceable operational ceiling is four. Seven declarations request 98 of 100 connections before CNPG's instance manager, metrics exporter and reserved slots. Every one of them is politely inside its declared 14-connection allowance; the instance still fails. ADR-0004 sets four because memory is expected to bind first and fails by OOM-killing every co-resident rather than refusing one connection.
+That distinction matters because our governance addresses the wrong shape. Per-consumer connection_limit, statement_timeout and idle_in_transaction_session_timeout guard well against one greedy consumer. They do nothing about the aggregate of many modest ones, which is the second and less intuitive noisy-neighbour failure and the one this number describes. Two workload consumers plus the isolation probe occupy three of the four declared slots. The next workload request must trigger measurement and the overflow decision before admission.
Memory likely binds first. 100 backends against 1Gi is ~10MB per backend. Connection exhaustion errors clearly; memory pressure OOM-kills and degrades every co-resident at once.
+E3 and pooling. Corrected from draft-2, which had this backwards. Transaction-scoped context (SET LOCAL inside an explicit transaction) is what makes E3 safe under a pooler. Statement-level pooling is what breaks it, serving other tenants' rows under concurrency with no error. E3 constrains which pooling mode is available, not whether pooling is available.
Retention consumes the volume. WAL accumulates with the window, and §4.5 makes the window the maximum across consumers. A consumer declaring a long retention extends everyone's horizon and everyone's storage draw against a 20Gi volume.
+Restore time couples all consumers. Physical backup is instance-wide, so a consumer's RTO is a function of total instance size, not its own.
+platform-pg is V1. instances: 1 on a single-node rail provides exercised restart recovery and no failover. P1 describes its consumer placement and says nothing about this availability fact; the new V axis carries it.
tenantIsolation in PostgresConsumer is revealed as a mislabelled field.rapp-postgres acquires an obligation to define and offer the mechanism.tenantIsolation field — resolved. rapp-postgres retired it. A consumer declaration asks for mechanisms; posture lives in the consumer's tenancy.yaml.whitehat-security (WHITEHAT-WP-0001), an independent adversarial evidence facility seeded for this purpose. audit-core and tenant-engine were right to decline it as fleet-scope work; the answer was a home of its own rather than a volunteer.Owned by NetKingdom — corrected 2026-08-17; an earlier revision of this section proposed otherwise on independence grounds and was overruled. Offensive security is security work and belongs with the repo that owns security. The facility is framed offensively rather than as a conformance checker: it is pointed at infrastructure we choose, our own estate among them, and conformance testing is one use of a general capability.
+The residual tension is recorded rather than resolved: NetKingdom owns this framework and the facility that tests conformance to it, so those findings are NetKingdom assessing NetKingdom. The mitigation is that findings leave for risk-nexus, under the-custodian, rather than being closed in place. Proportionate, not perfect. Revisit if conformance findings start getting quietly closed.
Two consequences land back here. Cadence is now a security parameter, not a schedule — for any control whose guarantee is detection rather than prevention, the interval between probe runs is the exposure window, and rapp-postgres ADR-0003 leaves that number to the facility. And a passing suite is not proof of isolation; it is proof that the attacks attempted did not work. §13's evidence artifacts should be read with that distinction, because a green run recorded as "E2 verified" would be exactly the overclaim §6 prohibits.
repo-classification-standard_v1.0.adaptive-pricing owns typed minima and wording; tenant-engine owns plan assignment by id. Current tiers make no assurance claims.rapp-postgres ADR-0003 publishes the GUC contract with the FORCE/BYPASSRLS/SECURITY INVOKER/EXPLAIN requirements.key-cape: realm-per-tenant or Organizations? Realm-per-tenant's ~5–20 tenant ceiling is below our target.platform-pg. rapp-postgres ADR-0004 sets four consumers and names absent overflow target platform-pg-2; measurement and provisioning remain live gaps.audit-core: crypto-shredding a tenant's audit records destroys the evidence the service exists to hold, and ADR-0001 §2 deliberately built the role model so history could not be rewritten. The usual resolution separates the fact of an event, retained, from its personal payload, encrypted per subject and shreddable. Raised because a naive "R4 everywhere" target would instruct the audit service to destroy its own evidence. audit-core targets R2 and is explicitly not a fleet R4 target. The legal basis for retaining audit facts remains a risk/legal question outside this framework.Routed elsewhere, deliberately. The tenant identifier tenant:<grouping>:<name> embeds headcount bands (small, medium, large) that change as a tenant grows, contradicting the consensus that identifiers should not encode mutable attributes. That is a critique of ADR-0013, not of this framework, and belongs to tenant-engine and NetKingdom canon. Folding it in here would overreach.
tenant-engine, flex-auth, audit-core, rapp-postgres, railiance-platform and adaptive-pricing against §19. Complete in draft-8.rapp-postgres/docs/canon-drafts/shared-platform-relational-storage_v0.1-draft.md, whose §§3–8 are absorbed here. That draft is withdrawn rather than left pending.rapp-postgres ADR-0001 through ADR-0004 move to accepted and are annotated as the PostgreSQL implementation of the E, P, R and shared-capacity rules.A framework for describing, holding and improving multi-tenancy — including where we are not there yet.
Source: net-kingdom · canon/standards/tenancy-posture_v0.1.md · cced59d3aa1dc0aa08fc128fc8c76699f59dcd90
Review due: 2027-02-17
Proposed, draft-8; ratification-ready. Relocated from the-custodian/canon/architecture on 2026-08-17: multi-tenancy is part of the IT-security framework NetKingdom provides, so this framework belongs in NetKingdom canon beside the IAM Profile and the tenant-engine boundary contract, not in the work-factory canon.
R4 had no mechanism beyond waiting, and the noisy-neighbour evidence artifact asserted something shared infrastructure cannot provide.tenant-engine's review: five changes, including an axis that did not fit its data shape.audit-core, railiance-platform and flex-auth. Eleven further changes, two of them corrections to statements this document made as fact about other repos. Every posture I guessed was too generous, on every repo that has now self-reported.adaptive-pricing's review, the last of the six, and the consistency review across all declarations. It adds the missing availability axis, a canonical declaration schema, explicit authority for tier assurance, retention/placement coupling, downgrade propagation, and honest sanctioned customer language. It also corrects the distinction between an implemented control and an evidenced current level.Reviewed by all six. The score: six repos found three live defects in their own code by reading the ladders — tenant-engine's unfiltered event accessor, audit-core's unfiltered read path, flex-auth's unauthenticated /v1/check — and railiance-platform found apps-pg running with no backup configured at all while writing its §10.2 disclosure. The framework changed to fit the repos; no repo was told to fabricate a posture.
Informed by five external research digests plus their index in the-custodian/research/2026-08-17-adr008-*, which carry full citations for the external claims made here.
docs/platform-identity-security-architecture.md — accepted, 2026-07-23 — already uses plane for a trust and deployment layer: the bootstrap plane, the platform control plane, and tenant planes. That meaning is established, ratified, and owned by this repo.
Drafts 1–4 of this document, written elsewhere, used plane for something different: an independent dimension of concern. Two incompatible senses of one word inside one canon is exactly the concept-ownership collision the estate has been careful about elsewhere, and the newcomer yields.
+This framework therefore describes six axes. They are orthogonal to NetKingdom's planes, not a subdivision of them:
+A workload in the tenant plane has a position on all six axes. A platform control plane service does too. The two vocabularies compose and neither replaces the other.
+The rename is also an improvement. A posture vector is literally a point in six-dimensional space, and "axis" says that where "plane" did not.
+Drafts 1–4 opened by claiming the estate "has never written down what it is building". Relocation proved that wrong, and the correction is worth keeping visible: docs/platform-identity-security-architecture.md has described the trust model, the tenant model and a capability progression since 2026-07-23. The accurate claim is narrower — what was missing is a way to say how far a given service has got, and to hold several answers at once. Seven documents cover slices of the subject and none of them does that:
| Document | Covers | Status |
|---|---|---|
iam-profile_v0.3 (NetKingdom) | Tenant identifier shape, tenant_roles claim, staleness rules | Ratified |
tenant-engine-boundary-contract_v0.1 (NetKingdom) | Who owns tenant records, roles, plan assignment | Ratified |
business-app-service-contract_v0.1 §1 (Custodian) | Business apps: instance-per-client, tenant-keyed data | Ratified |
rapp-postgres ADR-0001 | Consumer + tenant isolation in PostgreSQL | Proposed, governs one repo |
rapp-postgres ADR-0002 | Per-consumer retention and the erasure horizon | Proposed, governs one repo |
shared-platform-relational-storage_v0.1 | The stacked-boundary gap | Routed 2026-08-10, still unratified |
platform-identity-security-architecture (NetKingdom) | Trust model, planes, tenant model, capability progression | Accepted 2026-07-23 |
This document is downstream of that architecture and must not restate it. It answers one question the architecture leaves open: given the model, where is this particular service today, and how would anyone know?
+Four failures existed when drafting began.
+The gap was diagnosed once and the fix stalled. The v0.1 draft was written to fill this hole and has sat unratified in neither canon directory. §20 attaches a ratification path so this one does not join it.
+Placement was owned by nobody. user-engine-pg and target-revenue-pg are dedicated; apps-pg, net-kingdom-pg, platform-pg, state-hub-db and forgejo-db are shared. Both live, neither written down. tenant-engine raised this with railiance-platform on 2026-08-16. Draft-8 resolves the authority split in §8.2.
Two contradictory defaults were already ratified. Business apps get instance-per-client; platform services pool. Nothing says which shape a new service takes, and no definition separates the categories. Decision 4.4.1 now supplies the default; §19.4 retains the missing classification rule.
+There is no honest way to describe a repo that is not there yet. The estate absorbs repos with weak or absent tenant separation. Today such a repo is simply non-conformant, leaving it two bad options: misrepresent its posture, or stay outside the framework.
+A framework, not a model. It specifies no single correct implementation. It supplies terminology (§3, §4), a declaration (§5), a conformance rule (§6), methodology (§12), and evidence definitions (§13).
+A service is conformant when its declared posture is accurate and its trajectory recorded. A service is non-conformant when it claims a level it cannot evidence — regardless of how high or low that level is.
+"Is this multi-tenant?" is treated as one question. It is six, and they are independent:
+| Axis | Question | Vocabulary owner |
|---|---|---|
| Identity (I) | How is a tenant named and validated? | tenant-engine / IAM Profile |
| Authorization (A) | How is a request bound to the tenants it may act for? | flex-auth |
| Enforcement (E) | Where, mechanically, is the tenant boundary enforced? | This framework |
| Placement (P) | Which substrate holds a tenant's data? | railiance-platform |
| Retention (R) | How long does data persist, and how is it erased? | The storage platform; policy by the consumer |
| Availability (V) | What failure can the complete service path survive, and within what recovery objective? | The delivering service; substrate facts by its providers |
Conflation produces errors today. rapp-postgres's PostgresConsumer carries tenantIsolation: consumer-service-boundary — an E-axis fact in a P-axis artifact, reading as though storage enforces something it does not. The "dedicated versus shared" argument mixes P (capacity, blast radius) with E (correctness).
The axes are separated precisely so each may sit at a different level.
+Decision 3.1: every document, declaration and plan tier that says "isolation" MUST name which axis it means.
+Decision 3.2: the axes couple at their tops and the couplings MUST be stated where they apply, not used to argue the axes are one:
+E4 is reachable only at P3 or above.R's erasure horizon is bounded below by P — on shared substrate, a consumer's horizon is the instance maximum (§4.5).R4 by key destruction is bounded by the key boundary, which is an E-axis property. Shredding a single tenant's data requires the application to encrypt under a per-tenant key before writing; the storage platform cannot supply it. Reaching the top of the retention ladder is not a retention project.V composes as the minimum across the critical request path, not the maximum of its components. A replicated application on a single-instance database is not V2. A tested degraded mode may remove a dependency from that path, but the bypass itself is part of the V evidence.Decision 3.3 — scope. The P and R ladders describe a service's primary datastore. The V ladder describes the service's complete critical request path, including providers it synchronously depends on. Caches, search indices, message queues and background jobs are named leak surfaces in the external baselines and are assessed separately, not silently covered by a datastore level. A declaration names material secondary stores and asynchronous paths as exceptions rather than implying that one vector proves them safe.
+Each axis carries an ordered ladder. Higher is stronger, not better: the right level is the one a service can evidence and its risk warrants.
+tenant-engine re-query for privileged, destructive, credential-vending or aal2-class decisions.I1 now explicitly absorbs request-supplied tenant identifiers. "Never trust client-supplied tenant IDs without validation" is a named anti-pattern; a service reading the tenant from a header is at I1 however canonical the string.
+An axis is assessed on a service's own inbound surface, never on its authority over the concept. tenant-engine is the source of existence for tenant records and is nonetheless at I1, because it takes the acting identity from the request body rather than from a verified token. Draft-5 conflated these by naming the authority inside the I2 definition, which made the level describing canonical identity unclaimable by the service that provides it. Corrected on tenant-engine's review — a reader would otherwise assume the authority must be at I2 by definition.
business-app-service-contract §2.1 sets app-local accounts as the v1 baseline for business apps — a sanctioned low level with recorded triggers for moving up. That is the pattern this framework generalises.
flex-auth as PDP, with live re-query where the IAM Profile requires it.This ladder describes enforcement points. A decision point cannot occupy A3 — "delegated to flex-auth" is not something flex-auth can do. A service that is a PDP declares two numbers: its own inbound level, and the maximum it enables for consumers. flex-auth reads A0, enables A3 — accurate, and considerably more alarming than A3, which is the point. Raised by flex-auth, whose absence from the §5 worked examples was this surfacing implicitly.
A4 is new. The specification reached Final in January 2026 and Keycloak shipped experimental support in May; the argument for it is interoperability — a swappable decision point and an enforcement point not coupled to one engine's request shape.
+Correction from flex-auth's review: earlier drafts also justified A4 as ending the copying of action strings between repos. It does not. AuthZEN standardises the envelope — subject, action, resource, context, endpoint — and deliberately does not standardise the action vocabulary or the policy language. At A4, tenant.guardrail.set still has to be agreed and still gets copied. Those are two problems with different fixes, and the cheaper one is not A4: flex-auth's registry already carries action definitions per system and could serve them read-only. The vocabulary argument is withdrawn.
Internal service-to-service calls are in scope for this axis. "Skipping tenant validation for internal services" is a named anti-pattern and our estate is mostly internal calls.
+Correction from flex-auth's review: earlier drafts asserted that flex-auth calls tenant-engine synchronously on the authorization path. That is not true. The adapter is built and complete and has no non-test caller, so the IAM Profile's live re-query exists and is unwired — which is also why flex-auth cannot reach I3. Built-and-unwired is the worst of the three states because it reads as capability.
The requirement, narrowed on their proposal because the original was too strong to be met and would have made tenant-engine a hard availability dependency of every decision in the estate:
Tenant context MUST be carried on every internal hop and MUST NOT be re-derived from a service identity. It MUST be revalidated against tenant-engine at least once per request chain — at the service that holds or mutates the tenant's data, or before a privileged, destructive, credential-vending or aal2-class decision, whichever comes first. A hop that neither holds tenant data nor makes such a decision may carry the context without revalidating it.
And carrying tenant context is worthless without an authenticated hop to carry it over. flex-auth found this in itself: it carries tenant context faithfully and cannot distinguish "user-engine asking on behalf of tenant X" from "any pod asking on behalf of tenant X".
Correction from draft-2. Draft-2 described E3 as something "the application cannot trivially route around". That is false and it was this document overclaiming in exactly the way §6 prohibits. Any session can re-issue SET on a custom GUC, so an attacker with SQL execution can reset the tenant and read across the boundary. What E3 buys is precise, and the ladder must say so:
| Threat | E1 | E2 | E3 | E4 |
|---|---|---|---|---|
| A developer forgets a tenant predicate | ✗ | ✓ | ✓ | ✓ |
| A new code path bypasses the choke point | ✗ | ✗ | ✓ | ✓ |
| SQL injection reaching the connection | ✗ | ✗ | ✗ | ✓ |
| The application process is compromised | ✗ | ✗ | ✗ | ✓ |
E3 is a strong control against accident — the common case, and the one that causes real breaches — and no control at all against compromise. Only E4 holds against both, because the credential itself cannot address another tenant's data.
+Correction: E3 layers on E2, it does not replace it. External practice treats application-layer and database-layer filtering as complementary. A service that dropped its choke point on reaching E3 would be worse off, since E3 fails open under injection. Claiming E3 therefore requires the E2 evidence artifact as well.
+Correction: the GUC is set transaction-locally. Draft-2 said "at pool checkout", which is session scope and the wrong instrument. Under a pooler in statement mode, SET leaks between clients and returns other tenants' rows — a failure that appears only under production concurrency and produces no error. Use SET LOCAL inside an explicit transaction.
Platform enforcement is a platform obligation. Reaching E3 requires the storage platform to offer the mechanism: provisioned policies, a documented GUC contract, and a probe. Where a consumer wants E3 and the platform has not supplied it, the gap is the platform's. §19.6 asks rapp-postgres to define that contract, which must carry FORCE ROW LEVEL SECURITY on every tenant table (without it the table owner bypasses policies silently, and ADR-0001 already established that our migration role owns the tables it creates), no BYPASSRLS on leased roles, SECURITY INVOKER for ordinary logic, and an EXPLAIN comparison because RLS disables functional indexes built on non-leakproof functions.
Not all data is tenant-keyed, and the ladder must not pretend otherwise. A registry whose rows are the tenants has no per-tenant predicate to scope a policy by; enforcing one would break the service's function rather than secure it. tenant-engine's tenants table is the worked example — key-cape enumerates it at token issuance and flex-auth queries it live, both of which are cross-tenant reads by design.
A service with mixed data shapes declares E-level plus a registry exception: the level its tenant-keyed tables hold, and a named list of tables excluded because they are registries rather than tenant data. The exception is part of the claim and is reviewable; an unnamed exception is an overclaim. Without this, mixed-shape services either overclaim or stay at E2 permanently, and tenant-engine declined to claim E3 on precisely that reasoning.
Default expectation for a new platform service: E2 at first serve, E3 recorded as target. Services whose cross-tenant exposure would be a reportable breach SHOULD target E3 or above.
+Enforcement and placement are independent axes. Plotted together, with where each service actually sits — parenthesised entries are targets or defaults rather than current positions, and — marks a cell the coupling in §3.2 makes unreachable:
P0 → P1 → P2 is movement along the horizontal axis only. Those steps buy consumer isolation, capacity predictability, independent retention and a smaller operational blast radius. They do not raise the tenant boundary by one step. Only P3 makes E4 reachable. This is the most misusable fact in the framework and §11 governs how it may be described.
+Decision 4.4.1: P1 is the default for platform services; P3 for client-facing business apps, as already ratified. A service unsure which it is must resolve that first (§19.4).
+Decision 4.4.2 — placement scopes to data substrate. Identity-provider placement (realm-per-tenant versus Organizations) is the same silo/pool decision on a different substrate, is live in our estate, and is undecided. Realm-per-tenant carries a stated ceiling around 5–20 tenants, far below our target. Recorded here as a parallel question (§19.7), not folded into P.
+New in draft-3. Implemented abstractly by the storage platform for any dataset; policy is built on top of that interface by the consumer or its governance layer. Reference implementation: rapp-postgres ADR-0002.
R4 has two routes and a service MUST name which one it uses.
+| Route | Mechanism | Cost |
|---|---|---|
| Horizon-elapsed | Wait out the published erasure horizon; the data ages out of every retained copy. | Available to everyone, proves little, and the wait is set by a co-resident's retention requirement rather than your own. |
| Key-destroyed | Encrypt per entity, then destroy the key. Retained copies survive but are unreadable. | Requires per-entity keys, strong encryption, and an auditable destruction record. Immediate. |
Decision 4.5.3 — key destruction is not sufficient on its own. The key-destroyed route requires that no retained commitment reveals the erased content. Found by audit-core, and it is a general defect rather than a fact about them:
So a service claiming R4 by key destruction must show that its retained commitments — hashes, chains, indexes, search keys — do not reveal what was erased. The remedies are an HMAC under a per-subject key that dies with the key, or a per-record salt destroyed alongside it. audit-core cannot reach R4 under its current design and targets R2; a fleet R4 target must exempt it explicitly.
Regulatory standing of the key-destroyed route, stated carefully because overclaiming here is worse than anywhere else in this framework. Data protection authorities have accepted key destruction as erasure where physical deletion would be manifestly disproportionate, and the practice is recognised under conditions — strong encryption, irreversible destruction, and an auditable record of it. The EDPB has not formally endorsed it as Article 17 erasure. A service reaching R4 by key destruction is making a defensible claim, not a settled one, and must say so rather than reporting a clean "deleted".
+Three further properties.
+The erasure horizon is the interval between deleting data and it ceasing to be recoverable from anything the platform holds. Deleting a row does not remove it from yesterday's backup. With an N-day window, deleted data remains recoverable for N days. That is the difference between "deleted" and "erased" and the estate had never written it down.
+On shared substrate, retention is not per-consumer. Physical backup is instance-wide — one WAL stream, one window — so the instance retention is derived as the maximum across co-resident consumers, and every consumer's horizon is that maximum. A consumer declaring 7 days beside one declaring 90 gets 90. This is the retention analogue of ADR-0001's blast-radius disclosure: state the coupling rather than imply an isolation that is not there.
+Retention is therefore a placement trigger. A consumer needing a horizon shorter than the instance floor cannot have one at P1. It moves to P2 for a reason with nothing to do with performance — which is exactly why it needs recording, since nobody looks for a retention argument when reviewing placement.
+Decision 4.5.4 — a retention promise binds both R and P. A tier making a retention claim records an R minimum and a maximum erasure horizon in days. It also requires P2 or above unless its provider contract guarantees that the shared-substrate horizon stays within that maximum and rejects or notifies before a co-resident change would extend it. A bare R2 minimum is insufficient: at P1 another consumer can change the promise without changing the tier or its holder.
Deletion splits mechanism from policy. The platform deletes whole datasets on instruction and records an opaque policy reference it never interprets, so every deletion traces to what authorised it. Rows are not a dataset: row expiry is the consumer's own DML under its migration lease. Dropping a consumer's whole database is an operator-gated offboarding step, never a scheduled one.
+New in draft-8. adaptive-pricing found that §11 required availability claims to map to a minimum level while the framework supplied no availability vocabulary. Placement is not a substitute: a dedicated cluster can still be a single instance on a single node.
Decision 4.6.1 — V is end-to-end. A service declares the minimum across the components and synchronous providers required to serve the operation. An application with three replicas over a V1 database is V1. A status page or replica count is not evidence of a higher level.
+Decision 4.6.2 — availability claims name the operation. A read-only degraded mode and a mutation path may have different V levels. Decision 5.2 applies: declare the paths and quote the minimum unless the customer-facing claim explicitly and unambiguously names the narrower operation.
+A service states one level per axis, plus a target, review dates, evidence and any exceptions. current is the highest evidenced level; a control present in code but still awaiting the evidence required by §13 goes in implemented, not in current:
schema_version: "0.1"
+framework: netkingdom-tenancy-posture
+service: example-service
+role: tenant-data-service
+tenancy:
+ current: { I: 2, A: 3, E: 2, P: 1, R: 1, V: 1 }
+ implemented: { E: 3 }
+ target: { I: 2, A: 3, E: 3, P: 1, R: 2, V: 2 }
+ reviewed: "2026-08-17"
+ review_due: "2027-02-17"
+ service_class: interactive
+ gap:
+ E: "RLS is implemented; the §13 E3 probe is still absent."
+ R: "Retention declared; erasure horizon not yet published to consumers."
+ V: "Automated failover is not implemented or exercised."
+evidence:
+ A3: "docs/evidence/authorization-denial.md"
+ E2: "docs/evidence/cross-tenant-review.md"
+ P1: "rapp-postgres/docs/evidence/isolation-2026-08-10.md"
+Placement exceptions. Draft-2 assigned one P level per service, which cannot express the vertically partitioned model — most tenants pooled, some dedicated — that §11's isolation tiers require. A tier requiring P2 bought by three tenants would put the service at two levels at once, forcing an over- or under-claim. Placement is therefore declared as a default plus exceptions:
placement_exceptions: + - tenants: ["tenant:enterprise:*"] + P: 3 + reason: "isolation tier; see adaptive-pricing tier definition"+
A service with exceptions must be able to say which tenants are on which substrate. That mapping is a first-class artifact, not archaeology.
+Decision 5.5 — a provider declares what it makes reachable, not where it sits. The six ladders describe a consumer of infrastructure. They describe a provider of it badly, and railiance-platform's review demonstrated how badly: apps-pg is I0 A0 E0 because a database has no tenant concept, carries no tenant claim and applies no tenant predicate. Those zeros are structural, not weak — the cluster is exactly as strong as its consumers make it.
The sharp case is OpenBao at E0. Literally correct, and actively misleading: the mechanism in place is credential-scoped structural separation — E4 machinery — pointed at a consumer boundary rather than a tenant one. A reader scanning a column of E values would rank it below a service doing per-query filtering in application code, inverting the real security position.
So a platform service additionally declares, per axis, the level available now, the maximum it can make reachable, and what a consumer must do to reach it. For apps-pg: E4 unreachable (shared credential per consumer, no per-tenant credential), E3 conditional on the GUC contract, R2 blocked on a backup target, V1 at most on the single-node rail. That is the sentence a consumer actually needs, and no arrangement of the consumer ladders produces it.
A provider's own P is n/a, not a number. apps-pg provides P1; it is not at P1, and writing P: 1 there would later read as an isolation claim.
Worked examples after applying the evidence rule and minimum-across-paths rule consistently:
+| Service | Current | Notes |
|---|---|---|
tenant-engine | I1 A0 E1 P n/a R0 V0 | Acting identity is caller-supplied; unauthorised read paths set the A minimum; E2-shaped child-table controls are not evidenced; SQLite is outside P; no erasure or availability evidence. This corrects draft-7, which quoted A2/E2 despite its own minimum/evidence rules. |
audit-core | I1 A2 E1 P1 R2 V0 | E2 is implemented on both paths but awaits the adversarial artifact, so current remains E1. Its 30-day retention and erasure horizon are now declared and published. |
flex-auth | I1 A0 E1 P n/a R n/a V0 | Enables A3 for consumers. /v1/check authenticates no caller; E2 is implemented but not evidenced. |
platform-pg (provider) | I0 A0 E0 P n/a R2 V1 | Provides P1; backup/restore and single-node recovery are evidenced. Provides no tenant boundary by itself. |
apps-pg (provider) | I0 A0 E0 P n/a R0 V0 | Zeros are structural, except R0/V0 are live gaps: no backup and no recovery evidence. |
adaptive-pricing observatory | I0 A0 E0 P n/a R n/a V0 | Local, unauthenticated, single-user analysis surface; not a production service. |
| A newly absorbed repo | I1 A1 E1 P0 R0 V0 | Conformant if declared, with a recorded path. |
Decision 5.1: the posture vector is declared in the repo, not in the hub, consistent with local-files-are-source-of-truth.
+Decision 5.2 — declare per path, quote the minimum. A service whose mutations are authorized and whose reads are not is at the reads' level. The quoted number is the minimum across paths; the per-path detail is declared beside it.
+Draft-6 required only the minimum, on tenant-engine's review. audit-core then showed why that is insufficient on its own: a bare minimum destroys signal, because E3-write/E1-read declares identically to E1/E1. Bare per-path invites "our write path is E3", which is the sentence §6 exists to stop. Both, related explicitly, is the rule.
Two services found this shape in themselves within a day of each other — tenant-engine (writes authorized, three read routes not) and audit-core (write path tenant-filtered, read path not filtered at all). Most services enforce harder on write than read, so this is the common case, not the corner.
Decision 5.3 — n/a is a level, and it is conformant. P0 presupposes a shared database and R0 presupposes retained data. A service holding nothing at rest — flex-auth runs with its registry and policy baked read-only into the image and no decision log persisted — is neither. A datastore outside a ladder's substrate vocabulary, such as tenant-engine's current SQLite PVC, also uses n/a rather than inventing a level. Without an admissible n/a, a missing rung forces the fabrication §6 prohibits, which is precisely what draft-1 was rejected for. n/a is declared with a stated reason.
Decision 5.4 — the vector lives at tenancy.yaml in the repo root. Draft-6 said "in the repo" and not where or in what shape, which left §12's guard needing per-repo archaeology. flex-auth adopted tenancy.yaml speculatively; adopted here as the convention. A repo representing one service uses the single-service form above. A layer repo uses the schema's services list in the same root file — one vector per service, never an average. The normative schema is canon/schemas/tenancy-posture_v0.1.schema.json; prose documents may explain a declaration but do not replace it. The schema carries current, implemented, target, reviewed, review_due, gap, placement_exceptions, service_class (§8.3), per-path detail (§5.2), and provider reachability (§5.5). From the net-kingdom repo, owners validate one or more declarations with uv run tools/tenancy-posture/validate.py <path>...; the validator applies the JSON Schema and the evidence, date, implemented/current and provider-range rules that JSON Schema alone cannot express.
A service is conformant when its declared posture is accurate, its target is recorded, and it does not claim a level it cannot evidence. It is non-conformant when it overclaims — at any altitude.
E0 is conformant. Concealing E0 is not.flex-auth is I1 and always will be: a decision point evaluates the claims it is handed, and verifying its own inputs would make it the identity provider its scope refuses to be. A target equal to current with a reason is a settled position, not a stalled trajectory, and §12's guard must not nag it as though it were one.Decision 6.1 — downgrades propagate. Before a planned downgrade of a current level or a provider's available level, the declaring repo MUST resolve the tier definitions and consumers that reference it. A downgrade below a recorded minimum blocks the change until the claim is changed, the workload is moved, or the affected owner explicitly accepts the gap. An unplanned regression is an incident and triggers the same notifications. Updating tenancy.yaml without notifying dependants is declaration drift, not a completed downgrade.
Without the axis separation, "not rigorous about tenant separation" is one verdict a repo passes or fails. With it, the same repo is I1 A1 E1 P0 R0 V0 with a path — a plan, not an indictment.
Movement between P levels must be operational, not a rebuild:
+Decision 7.1: mandatory at P1 and above. At P3, SHOULD rather than MUST — a per-client instance that never moves is not misconformant for naming its own database.
+Recorded at provisioning time: noisy neighbour on a latency-critical path; a compliance or residency requirement; a plan tier requiring a higher minimum; an erasure horizon that no longer fits (§4.5); connection or memory ceiling reached.
+Decision 8.1: triggers MUST be monitored, not merely recorded. A trigger in a YAML comment nobody re-reads is documentation, not control.
+Decision 8.2 — split authority, machine-reconciled. railiance-platform owns the placement rule; the package repo owns the substrate numbers and enforcement; the consuming repo owns its workload requirements; adaptive-pricing owns any tier minimum. adaptive-pricing declined a standing co-signature and the framework accepts the replacement: typed tier minima are joined to consumer and provider declarations at tier definition and whenever one changes. A machine-checkable constraint must not depend on somebody remembering to collect a signature.
Decision 8.2.1 — trigger monitoring has an owner. The provider monitors capacity ceilings and co-residency; the consumer monitors latency, compliance and erasure requirements; adaptive-pricing monitors tier-definition changes. The placement owner reconciles those signals. A trigger marked unmonitored is an explicit gap and cannot support a customer assurance claim.
A latency-critical consumer and a batch consumer can share an instance today with nothing distinguishing them. tenant-engine sits on flex-auth's synchronous authorization path and chose a 5s statement timeout for that reason; audit-core, co-resident, is not latency-critical. Nothing prioritises between them.
The framework does not add a QoS axis, because the platform cannot enforce one. Community PostgreSQL has no resource governor: no per-role CPU or I/O priority, no resource queues, no workload classes. Those exist in EDB's enterprise variant, in Greenplum, and in SQL Server — not in what we run. A declared priority level would therefore be an unenforced claim sitting in a declaration, which is precisely what retiring tenantIsolation was about. An axis implies graduation and enforcement; this has neither.
Decision 8.3.1 — co-residents are equal. On shared substrate no consumer's query yields to another's. A consumer whose latency requirement cannot survive an unprioritised neighbour must escalate to P2. That is the honest mechanism and it is the only one we have.
Decision 8.3.2 — service class is declared anyway, as a category rather than a level: latency-critical, interactive, or batch. It buys three things, none of which is priority:
latency-critical with batch on one instance is a recognised mismatch. It may still be the right call — it is right today — but it should be a decision, not an accident of who was provisioned when.latency-critical consumer acquiring a batch co-resident is a recorded placement trigger under §8, on the same footing as noisy neighbour.batch may be an outage for latency-critical.Decision 8.3.3 — class mixture must be visible. The platform reports which classes are co-resident. An unenforceable risk that nobody can see is strictly worse than one that is stated.
+The known escalation short of P2 is gateway-level prioritisation — ordering submissions in a connection proxy by the requesting tenant's current consumption. It is real, it is where the industry puts this when it must, and it is new infrastructure we do not run. Recorded as the option, not adopted.
+Short-lived leased credentials re-read at connection checkout, with overlap-first rotation, bound the residual risk at every E level below E4: a leaked credential expires rather than persisting. Stronger than the industry norm of a long-lived per-service secret.
+Decision 9.1: static long-lived database credentials are not a sanctioned path for any service above E0.
+Decision 9.2 — the rule extends to consumer-facing credentials. Draft-6 named database access only. audit-core pointed out that its ingest credentials are static long-lived bearer tokens, rotated by publishing a second alongside the first — and that the argument applies with more force to the credential that actually carries the tenant claim than to the one that reaches the database behind it. Read as an accidental omission; it was. Consumer-facing credentials are named in. Where a service cannot yet meet this, it is a stated gap rather than a silent exclusion.
Decision 10.1: every platform holding consumer data MUST publish, in concrete terms, what a leaked runtime credential can and cannot reach at the levels it operates. rapp-postgres ADR-0001 §5 is the reference. Where the model cannot provide a guarantee, the platform says so and names the escalation.
Decision 10.2 — quotas are disclosed, not discovered. The same obligation extends from what a leaked credential can reach to what the platform will refuse to do for you. Every consumer MUST be told, at provisioning, the throttles and quotas enforced against it — connection limits, statement timeouts, idle-transaction timeouts — and told again when they change. A consumer learning its statement timeout by hitting it in production is a disclosure failure, not a consumer bug. This is how tenant-engine was provisioned, by good practice rather than by rule; the rule now exists.
E3 P2 R2 V2 and a maximum erasure horizon; it need not print those labels anywhere customer-facing.tenancy.yaml is authoritative for the delivering service's current level; provider declarations are authoritative for what infrastructure makes available. None is derived by copying another. Approval joins them and fails closed on a missing, stale or insufficient declaration. A performance-differentiated tier requires P2 or an enforceable resource governor; service class alone grants no priority.Analyze. Assess a repo against the ladders; produce tenancy.current with reasoning recorded. Applies to new and absorbed services alike.
Establish. Declare the target and gap. The target is set by data class, tenant groupings served and plan tiers carried — not by ambition.
+Improve. Move one axis at a time. Raising P while leaving E untouched is the characteristic misstep.
+Guard. Verify continuously that the declared posture holds — against the service's own declaration, not a universal maximum. Nobody must prove every service is at E4; the check is that none is below what it declared.
+Regression found by guarding is a defect; regression declared in advance is a decision. The estate has been bitten twice by silent pin rollbacks producing ordinary-looking 403s and 404s rather than errors. Posture regression looks the same — an RLS context leak returns correct-looking rows for the wrong tenant. Guarding must be designed for invisible failure, not for crashes.
+Decision 13.1: a current level is claimed only with its evidence artifact present. This turns §6's accuracy rule from an honour system into a check. implemented records a control observed in code or configuration whose required artifact is still absent; it never satisfies a tier minimum.
Decision 13.1a — the floor needs no artifact, only a reason. Found independently by audit-core and flex-auth: the table below defines artifacts from I2, A2, E1, P1, R2 upward and none below, so a literal 13.1 made the lowest rungs unclaimable — including §5's own worked example of a conformant absorbed repo, I1 A1 E1 P0 R0, which could not satisfy it on any axis. A rule that forbids the declaration §6 exists to permit is a defect in the rule.
At I0/I1, A0/A1, E0, P0, R0/R1, V0, or n/a, a declaration requires a stated reason, not an artifact. Evidence is what stops you overclaiming, and there is nothing to overclaim at those floors.
Decision 13.4 — an artifact must assert something achievable. Draft-3's noisy-neighbour evidence required proof that a saturating consumer "does not breach" another's allowance. Shared infrastructure cannot provide that; the risk is inherent and cannot be wholly removed. An artifact that can only fail, or that passes by being run gently enough, is an overclaim wearing the costume of evidence. Where a property cannot be guaranteed, the artifact measures and records it instead.
+Decision 13.2 — evidence is of two kinds, and conflating them is an overclaim. Mechanical evidence is a structural assertion a machine can make and belongs in CI. Adversarial evidence is semantic, requires setting up separate tenant contexts and comparing responses, and carries a review date rather than a green build. Cross-tenant findings are the category external testing practice identifies as needing human review. A passing CI run is not E2 evidence.
+| Level | Evidence | Kind |
|---|---|---|
| I2 | Identifiers validated against the vocabulary; rejection test for a malformed id; binding shown to come from a verified token | Mechanical |
| I3 | Live re-query demonstrated on an aal2-class path; cached-claim path shown unused there | Mechanical |
| A2 | Choke point identified; test that an unbound request is refused | Mechanical |
| A3 | Live decision with a denial observed at the endpoint, not only at the decision surface | Mechanical |
| A4 | Decision served over the standard interface; a second PDP substituted without PEP change, with the decision differences between the two recorded — substitution proves interface portability, not decision equivalence | Mechanical |
| E1 | Every tenant-owned table carries the tenant key | Mechanical |
| E2 | Choke point identified; identity bound to tenant A demonstrably cannot read tenant B | Adversarial, with a review date |
| E3 | FORCE ROW LEVEL SECURITY on every tenant table; no BYPASSRLS on leased roles; probe that a session without the GUC reads nothing; probe that a wrong GUC reads nothing; EXPLAIN comparison | Mechanical |
| E4 | Per-tenant credential demonstrated unable to connect to another tenant's substrate | Mechanical |
| P1–P4 | Provisioning declaration plus the platform's isolation probes | Mechanical |
| Shared P1–P2 capacity assurance | A recorded baseline of per-consumer resource usage; a run in which one consumer saturates its declared allowance; evidence that the governance controls bind (the greedy consumer is held at its limits) and that the degradation co-residents experience is measured, recorded and judged acceptable against each one's declared service class (§8.3); the aggregate headroom at time of measurement | Adversarial, load-generated, with a review date |
| R2 | Declared retention rendered; erasure horizon published and reported in the operator surface | Mechanical |
| R3 | Sweep evidence records: timestamp, dataset, identifiers removed, authorising policy reference | Mechanical |
| R4 | Erasure demonstrated across live data, backups and derived copies within the horizon | Adversarial |
| V1 | Critical dependencies enumerated; restart/recreate recovery exercised; interruption and measured recovery time recorded | Mechanical exercise |
| V2 | One instance terminated while traffic continues or recovers automatically; measured RTO/RPO and remaining shared failure domains recorded | Adversarial, failure-injected |
| V3 | Declared failure domain removed in an exercise; complete critical path and degraded modes observed against RTO/RPO | Adversarial, failure-injected |
| V4 | Region made unavailable in an exercise; traffic and state recover in the alternate region against RTO/RPO | Adversarial, failure-injected |
The P1–P4 artifact proves the declared placement topology. The shared-capacity artifact is additional: it is required before a P1/P2 service can claim that a noisy-neighbour control binds, that the trigger is actively guarded, or that a customer performance assurance survives co-residency. It is not required merely to report the true topology as P1 or P2. No such capacity artifact exists in the estate today, so §11 requires P2 or an enforceable governor for a performance-differentiated tier.
+Decision 13.3: the tenant-boundary E2/E3 and noisy-neighbour artifacts do not exist anywhere in the estate today. rapp-postgres runs 19 adversarial probes, all against the consumer boundary, none against the tenant boundary inside a consumer. Externally, what this framework calls a tenant boundary failure is Broken Object Level Authorization — OWASP API1, top of the API Security Top 10 since that list launched, and the most commonly exploited API vulnerability in published assessments. We have no coverage for the highest-ranked risk in our class of system. §19.3 records the owner.
Decision 14.1: external research is design input. This estate adopts published standards and structural patterns; it does not adopt tooling unless that tooling is an established industry standard with broad application. Everything else is built ground-up, so it can be optimised and refactored as the estate sees fit.
+| Class | Stance |
|---|---|
| Security baselines (OWASP Multi-Tenant Security Cheat Sheet, API Security Top 10) | Adopt as the external reference our ladders answer to |
| Standards bodies (OpenID AuthZEN 1.0) | Adopt — this is what A4 is |
| Reference taxonomies (Azure tenancy models, AWS SaaS Lens, cell architecture) | Adopt as structure |
| Engine behaviour (PostgreSQL RLS mechanics) | Facts, not tooling |
| Third-party analyzers and test frameworks | Do not adopt. Take their rule taxonomies as checklists for probes we write ourselves |
The practical effect is small and good: rapp-postgres already owns a ground-up probe harness — bash and psql, no dependency tree — that found four real defects in its own provisioning SQL. The evidence artifacts in §13 become new probes in a tool we control. One idea worth reimplementing from the external survey is policy-diff classification: labelling a change to an enforcement policy as safe or breaking before it lands.
One fixed model with a single set of characteristics (draft-1). Rejected: cannot describe a repo that is not there yet, forcing absorbed repos to misrepresent their posture or stay outside. A framework that can only describe its own end state is not a framework.
+A maturity model with a single overall level. Rejected: collapses the axis separation. A service strong on identity and weak on enforcement has a specific, actionable gap; one composite score hides it and invites averaging.
+Prohibiting row-level security (draft-2's inherited position). Rejected in draft-2, refined in draft-3: RLS is a real rung against the common threat. The error was never RLS — it was describing E3 in E4's language.
+Schema-per-consumer in one database. Rejected: pg_catalog is readable per-database, so every co-resident enumerates every other's table and column names regardless of grants. Retained as a describable state, never a target.
Mandating E4 for everyone. Rejected: the tenant taxonomy includes consumer (private individuals) and family. A cluster per private individual is economically impossible; the taxonomy is itself evidence pooling is required.
Per-consumer physical backup retention. Rejected: CNPG retention is a property of the instance's WAL archive. There is no mechanism, and claiming it would be a fabricated guarantee. Hence the derived maximum in §4.5.
+Platform-scheduled row expiry. Rejected: requires the platform to hold DML authority over consumer schemas and interpret consumer data semantics, both forbidden by ADR-0001. The consumer's migration lease is the correct instrument.
+Leaving each repo to its own model. Rejected: the status quo, which produced two contradictory ratified defaults and an unowned placement question.
+The graduated reframe is corroborated, not invented here. Microsoft's tenancy-model guidance states it almost verbatim: "Instead of viewing isolation as a discrete property, consider it a spectrum. You can deploy components of your architecture that are more isolated or less isolated than other components in the same architecture." The same guidance derives our E↔P coupling independently — shared deployment means enforcement lives in application code; dedicated deployment means it is structural.
+Stronger than typical. Most multi-tenancy literature models one boundary, tenant-to-tenant. This estate has two stacked boundaries: platform-service to platform-service, and tenant to tenant inside a consumer. Naming them separately and refusing to enforce both with one mechanism is uncommon and correct. Graduated per-axis levels also beat the silo/pool/bridge trichotomy, which is approximately our P axis with the other four missing — which is why it cannot express "pooled infrastructure, structurally enforced boundary".
+Weaker than typical. The pool model's standard mitigation is a verified enforcement layer every service is demonstrably routed through. We have the concept and none of the verification (§13.3).
+Adopted without naming it. Short-lived leased credentials re-read at checkout beat the long-lived-secret norm. §9 promotes it to a tenancy control.
+Still unexplored. Neither P nor R describes a cell — a slice of infrastructure with a fixed maximum size, sized so one cell's failure is survivable and cell count scales linearly. platform-pg is, in these terms, an uncapped cell: §17 computes a ceiling and nothing enforces it (§19.8).
Sources: the five research digests in the-custodian/research/2026-08-17-adr008-*, which carry full citations for the claims in this section.
Derived from the live platform-pg specification. Connection arithmetic is exact; the per-backend memory estimate remains unmeasured and is explicitly a gap in rapp-postgres ADR-0004.
instances: 1 (no HA; single-node rail) +max_connections: 100 +memory limit: 1Gi +per consumer: 14 connections (12 runtime + 2 migration)+
The hard connection bound is roughly six declarations; the enforceable operational ceiling is four. Seven declarations request 98 of 100 connections before CNPG's instance manager, metrics exporter and reserved slots. Every one of them is politely inside its declared 14-connection allowance; the instance still fails. ADR-0004 sets four because memory is expected to bind first and fails by OOM-killing every co-resident rather than refusing one connection.
+That distinction matters because our governance addresses the wrong shape. Per-consumer connection_limit, statement_timeout and idle_in_transaction_session_timeout guard well against one greedy consumer. They do nothing about the aggregate of many modest ones, which is the second and less intuitive noisy-neighbour failure and the one this number describes. Two workload consumers plus the isolation probe occupy three of the four declared slots. The next workload request must trigger measurement and the overflow decision before admission.
Memory likely binds first. 100 backends against 1Gi is ~10MB per backend. Connection exhaustion errors clearly; memory pressure OOM-kills and degrades every co-resident at once.
+E3 and pooling. Corrected from draft-2, which had this backwards. Transaction-scoped context (SET LOCAL inside an explicit transaction) is what makes E3 safe under a pooler. Statement-level pooling is what breaks it, serving other tenants' rows under concurrency with no error. E3 constrains which pooling mode is available, not whether pooling is available.
Retention consumes the volume. WAL accumulates with the window, and §4.5 makes the window the maximum across consumers. A consumer declaring a long retention extends everyone's horizon and everyone's storage draw against a 20Gi volume.
+Restore time couples all consumers. Physical backup is instance-wide, so a consumer's RTO is a function of total instance size, not its own.
+platform-pg is V1. instances: 1 on a single-node rail provides exercised restart recovery and no failover. P1 describes its consumer placement and says nothing about this availability fact; the new V axis carries it.
tenantIsolation in PostgresConsumer is revealed as a mislabelled field.rapp-postgres acquires an obligation to define and offer the mechanism.tenantIsolation field — resolved. rapp-postgres retired it. A consumer declaration asks for mechanisms; posture lives in the consumer's tenancy.yaml.whitehat-security (WHITEHAT-WP-0001), an independent adversarial evidence facility seeded for this purpose. audit-core and tenant-engine were right to decline it as fleet-scope work; the answer was a home of its own rather than a volunteer.Owned by NetKingdom — corrected 2026-08-17; an earlier revision of this section proposed otherwise on independence grounds and was overruled. Offensive security is security work and belongs with the repo that owns security. The facility is framed offensively rather than as a conformance checker: it is pointed at infrastructure we choose, our own estate among them, and conformance testing is one use of a general capability.
+The residual tension is recorded rather than resolved: NetKingdom owns this framework and the facility that tests conformance to it, so those findings are NetKingdom assessing NetKingdom. The mitigation is that findings leave for risk-nexus, under the-custodian, rather than being closed in place. Proportionate, not perfect. Revisit if conformance findings start getting quietly closed.
Two consequences land back here. Cadence is now a security parameter, not a schedule — for any control whose guarantee is detection rather than prevention, the interval between probe runs is the exposure window, and rapp-postgres ADR-0003 leaves that number to the facility. And a passing suite is not proof of isolation; it is proof that the attacks attempted did not work. §13's evidence artifacts should be read with that distinction, because a green run recorded as "E2 verified" would be exactly the overclaim §6 prohibits.
repo-classification-standard_v1.0.adaptive-pricing owns typed minima and wording; tenant-engine owns plan assignment by id. Current tiers make no assurance claims.rapp-postgres ADR-0003 publishes the GUC contract with the FORCE/BYPASSRLS/SECURITY INVOKER/EXPLAIN requirements.key-cape: realm-per-tenant or Organizations? Realm-per-tenant's ~5–20 tenant ceiling is below our target.platform-pg. rapp-postgres ADR-0004 sets four consumers and names absent overflow target platform-pg-2; measurement and provisioning remain live gaps.audit-core: crypto-shredding a tenant's audit records destroys the evidence the service exists to hold, and ADR-0001 §2 deliberately built the role model so history could not be rewritten. The usual resolution separates the fact of an event, retained, from its personal payload, encrypted per subject and shreddable. Raised because a naive "R4 everywhere" target would instruct the audit service to destroy its own evidence. audit-core targets R2 and is explicitly not a fleet R4 target. The legal basis for retaining audit facts remains a risk/legal question outside this framework.Routed elsewhere, deliberately. The tenant identifier tenant:<grouping>:<name> embeds headcount bands (small, medium, large) that change as a tenant grows, contradicting the consensus that identifiers should not encode mutable attributes. That is a critique of ADR-0013, not of this framework, and belongs to tenant-engine and NetKingdom canon. Folding it in here would overreach.
tenant-engine, flex-auth, audit-core, rapp-postgres, railiance-platform and adaptive-pricing against §19. Complete in draft-8.rapp-postgres/docs/canon-drafts/shared-platform-relational-storage_v0.1-draft.md, whose §§3–8 are absorbed here. That draft is withdrawn rather than left pending.rapp-postgres ADR-0001 through ADR-0004 move to accepted and are annotated as the PostgreSQL implementation of the E, P, R and shared-capacity rules.A framework for describing, holding and improving multi-tenancy — including where we are not there yet.
Proposed, draft-5. Relocated from the-custodian/canon/architecture on 2026-08-17: multi-tenancy is part of the IT-security framework NetKingdom provides, so this framework belongs in NetKingdom canon beside the IAM Profile and the tenant-engine boundary contract, not in the work-factory canon.
R4 had no mechanism beyond waiting, and the noisy-neighbour evidence artifact asserted something shared infrastructure cannot provide.Every correction so far was found by research or by relocation, not by review.
-Informed by five external research digests in research/2026-08-17-adr008-*, which carry full citations for every external claim made here.
Reviewed by nobody yet. §19 lists what each owner is being asked to accept.
-docs/platform-identity-security-architecture.md — accepted, 2026-07-23 — already uses plane for a trust and deployment layer: the bootstrap plane, the platform control plane, and tenant planes. That meaning is established, ratified, and owned by this repo.
Drafts 1–4 of this document, written elsewhere, used plane for something different: an independent dimension of concern. Two incompatible senses of one word inside one canon is exactly the concept-ownership collision the estate has been careful about elsewhere, and the newcomer yields.
-This framework therefore describes five axes. They are orthogonal to NetKingdom's planes, not a subdivision of them:
-A workload in the tenant plane has a position on all five axes. A platform control plane service does too. The two vocabularies compose and neither replaces the other.
-The rename is also an improvement. A posture vector is literally a point in five-dimensional space, and "axis" says that where "plane" did not.
-Drafts 1–4 opened by claiming the estate "has never written down what it is building". Relocation proved that wrong, and the correction is worth keeping visible: docs/platform-identity-security-architecture.md has described the trust model, the tenant model and a capability progression since 2026-07-23. The accurate claim is narrower — what was missing is a way to say how far a given service has got, and to hold several answers at once. Seven documents cover slices of the subject and none of them does that:
| Document | Covers | Status |
|---|---|---|
iam-profile_v0.3 (NetKingdom) | Tenant identifier shape, tenant_roles claim, staleness rules | Ratified |
tenant-engine-boundary-contract_v0.1 (NetKingdom) | Who owns tenant records, roles, plan assignment | Ratified |
business-app-service-contract_v0.1 §1 (Custodian) | Business apps: instance-per-client, tenant-keyed data | Ratified |
rapp-postgres ADR-0001 | Consumer + tenant isolation in PostgreSQL | Proposed, governs one repo |
rapp-postgres ADR-0002 | Per-consumer retention and the erasure horizon | Proposed, governs one repo |
shared-platform-relational-storage_v0.1 | The stacked-boundary gap | Routed 2026-08-10, still unratified |
platform-identity-security-architecture (NetKingdom) | Trust model, planes, tenant model, capability progression | Accepted 2026-07-23 |
This document is downstream of that architecture and must not restate it. It answers one question the architecture leaves open: given the model, where is this particular service today, and how would anyone know?
-Four failures follow.
-The gap was diagnosed once and the fix stalled. The v0.1 draft was written to fill this hole and has sat unratified in neither canon directory. §20 attaches a ratification path so this one does not join it.
-Placement is owned by nobody. user-engine-pg and target-revenue-pg are dedicated; apps-pg, net-kingdom-pg, platform-pg, state-hub-db and forgejo-db are shared. Both live, neither written down. tenant-engine raised this with railiance-platform on 2026-08-16; unanswered.
Two contradictory defaults are already ratified. Business apps get instance-per-client; platform services pool. Nothing says which shape a new service takes, and no definition separates the categories.
-There is no honest way to describe a repo that is not there yet. The estate absorbs repos with weak or absent tenant separation. Today such a repo is simply non-conformant, leaving it two bad options: misrepresent its posture, or stay outside the framework.
-A framework, not a model. It specifies no single correct implementation. It supplies terminology (§3, §4), a declaration (§5), a conformance rule (§6), methodology (§12), and evidence definitions (§13).
-A service is conformant when its declared posture is accurate and its trajectory recorded. A service is non-conformant when it claims a level it cannot evidence — regardless of how high or low that level is.
-"Is this multi-tenant?" is treated as one question. It is five, and they are independent:
-| Axis | Question | Vocabulary owner |
|---|---|---|
| Identity (I) | How is a tenant named and validated? | tenant-engine / IAM Profile |
| Authorization (A) | How is a request bound to the tenants it may act for? | flex-auth |
| Enforcement (E) | Where, mechanically, is the tenant boundary enforced? | This framework |
| Placement (P) | Which substrate holds a tenant's data? | railiance-platform |
| Retention (R) | How long does data persist, and how is it erased? | The storage platform; policy by the consumer |
Conflation produces errors today. rapp-postgres's PostgresConsumer carries tenantIsolation: consumer-service-boundary — an E-axis fact in a P-axis artifact, reading as though storage enforces something it does not. The "dedicated versus shared" argument mixes P (capacity, blast radius) with E (correctness).
The axes are separated precisely so each may sit at a different level.
-Decision 3.1: every document, declaration and plan tier that says "isolation" MUST name which axis it means.
-Decision 3.2: the axes couple at their tops and the couplings MUST be stated where they apply, not used to argue the axes are one:
-E4 is reachable only at P3 or above.R's erasure horizon is bounded below by P — on shared substrate, a consumer's horizon is the instance maximum (§4.5).R4 by key destruction is bounded by the key boundary, which is an E-axis property. Shredding a single tenant's data requires the application to encrypt under a per-tenant key before writing; the storage platform cannot supply it. Reaching the top of the retention ladder is not a retention project.Decision 3.3 — scope. The P and R ladders describe a service's primary datastore. Caches, search indices, message queues and background jobs are named leak surfaces in the external baselines and are assessed separately, not covered by a posture vector. Saying so is honest; implying the vector covers them would not be.
-Each axis carries an ordered ladder. Higher is stronger, not better: the right level is the one a service can evidence and its risk warrants.
-tenant-engine is the source of existence.tenant-engine re-query for privileged, destructive, credential-vending or aal2-class decisions.I1 now explicitly absorbs request-supplied tenant identifiers. "Never trust client-supplied tenant IDs without validation" is a named anti-pattern; a service reading the tenant from a header is at I1 however canonical the string.
-business-app-service-contract §2.1 sets app-local accounts as the v1 baseline for business apps — a sanctioned low level with recorded triggers for moving up. That is the pattern this framework generalises.
flex-auth as PDP, with live re-query where the IAM Profile requires it.A4 is new. flex-auth uses a bespoke CheckRequest and a bespoke action vocabulary, with action strings copied verbatim between repos to avoid re-derivation — exactly the coupling AuthZEN removes. The specification reached Final in January 2026 and Keycloak shipped experimental support in May. We are not wrong, we are pre-standard, and the ladder should have somewhere to go.
Internal service-to-service calls are in scope for this axis. "Skipping tenant validation for internal services" is a named anti-pattern, and our estate is mostly internal calls — flex-auth calls tenant-engine synchronously on the authorization path. A service identity acting on behalf of a tenant must carry and revalidate tenant context to claim A2 or above.
Correction from draft-2. Draft-2 described E3 as something "the application cannot trivially route around". That is false and it was this document overclaiming in exactly the way §6 prohibits. Any session can re-issue SET on a custom GUC, so an attacker with SQL execution can reset the tenant and read across the boundary. What E3 buys is precise, and the ladder must say so:
| Threat | E1 | E2 | E3 | E4 |
|---|---|---|---|---|
| A developer forgets a tenant predicate | ✗ | ✓ | ✓ | ✓ |
| A new code path bypasses the choke point | ✗ | ✗ | ✓ | ✓ |
| SQL injection reaching the connection | ✗ | ✗ | ✗ | ✓ |
| The application process is compromised | ✗ | ✗ | ✗ | ✓ |
E3 is a strong control against accident — the common case, and the one that causes real breaches — and no control at all against compromise. Only E4 holds against both, because the credential itself cannot address another tenant's data.
-Correction: E3 layers on E2, it does not replace it. External practice treats application-layer and database-layer filtering as complementary. A service that dropped its choke point on reaching E3 would be worse off, since E3 fails open under injection. Claiming E3 therefore requires the E2 evidence artifact as well.
-Correction: the GUC is set transaction-locally. Draft-2 said "at pool checkout", which is session scope and the wrong instrument. Under a pooler in statement mode, SET leaks between clients and returns other tenants' rows — a failure that appears only under production concurrency and produces no error. Use SET LOCAL inside an explicit transaction.
Platform enforcement is a platform obligation. Reaching E3 requires the storage platform to offer the mechanism: provisioned policies, a documented GUC contract, and a probe. Where a consumer wants E3 and the platform has not supplied it, the gap is the platform's. §19.6 asks rapp-postgres to define that contract, which must carry FORCE ROW LEVEL SECURITY on every tenant table (without it the table owner bypasses policies silently, and ADR-0001 already established that our migration role owns the tables it creates), no BYPASSRLS on leased roles, SECURITY INVOKER for ordinary logic, and an EXPLAIN comparison because RLS disables functional indexes built on non-leakproof functions.
Default expectation for a new platform service: E2 at first serve, E3 recorded as target. Services whose cross-tenant exposure would be a reportable breach SHOULD target E3 or above.
-Enforcement and placement are independent axes. Plotted together, with where each service actually sits — parenthesised entries are targets or defaults rather than current positions, and — marks a cell the coupling in §3.2 makes unreachable:
P0 → P1 → P2 is movement along the horizontal axis only. Those steps buy consumer isolation, capacity predictability, independent retention and a smaller operational blast radius. They do not raise the tenant boundary by one step. Only P3 makes E4 reachable. This is the most misusable fact in the framework and §11 governs how it may be described.
-Decision 4.4.1: P1 is the default for platform services; P3 for client-facing business apps, as already ratified. A service unsure which it is must resolve that first (§19.4).
-Decision 4.4.2 — placement scopes to data substrate. Identity-provider placement (realm-per-tenant versus Organizations) is the same silo/pool decision on a different substrate, is live in our estate, and is undecided. Realm-per-tenant carries a stated ceiling around 5–20 tenants, far below our target. Recorded here as a parallel question (§19.7), not folded into P.
-New in draft-3. Implemented abstractly by the storage platform for any dataset; policy is built on top of that interface by the consumer or its governance layer. Reference implementation: rapp-postgres ADR-0002.
R4 has two routes and a service MUST name which one it uses.
-| Route | Mechanism | Cost |
|---|---|---|
| Horizon-elapsed | Wait out the published erasure horizon; the data ages out of every retained copy. | Available to everyone, proves little, and the wait is set by a co-resident's retention requirement rather than your own. |
| Key-destroyed | Encrypt per entity, then destroy the key. Retained copies survive but are unreadable. | Requires per-entity keys, strong encryption, and an auditable destruction record. Immediate. |
Regulatory standing of the key-destroyed route, stated carefully because overclaiming here is worse than anywhere else in this framework. Data protection authorities have accepted key destruction as erasure where physical deletion would be manifestly disproportionate, and the practice is recognised under conditions — strong encryption, irreversible destruction, and an auditable record of it. The EDPB has not formally endorsed it as Article 17 erasure. A service reaching R4 by key destruction is making a defensible claim, not a settled one, and must say so rather than reporting a clean "deleted".
-Three further properties.
-The erasure horizon is the interval between deleting data and it ceasing to be recoverable from anything the platform holds. Deleting a row does not remove it from yesterday's backup. With an N-day window, deleted data remains recoverable for N days. That is the difference between "deleted" and "erased" and the estate had never written it down.
-On shared substrate, retention is not per-consumer. Physical backup is instance-wide — one WAL stream, one window — so the instance retention is derived as the maximum across co-resident consumers, and every consumer's horizon is that maximum. A consumer declaring 7 days beside one declaring 90 gets 90. This is the retention analogue of ADR-0001's blast-radius disclosure: state the coupling rather than imply an isolation that is not there.
-Retention is therefore a placement trigger. A consumer needing a horizon shorter than the instance floor cannot have one at P1. It moves to P2 for a reason with nothing to do with performance — which is exactly why it needs recording, since nobody looks for a retention argument when reviewing placement.
-Deletion splits mechanism from policy. The platform deletes whole datasets on instruction and records an opaque policy reference it never interprets, so every deletion traces to what authorised it. Rows are not a dataset: row expiry is the consumer's own DML under its migration lease. Dropping a consumer's whole database is an operator-gated offboarding step, never a scheduled one.
-A service states one level per axis, plus a target, a date, and any placement exceptions:
-tenancy:
- current: { I: 2, A: 3, E: 2, P: 1, R: 1 }
- target: { I: 2, A: 3, E: 3, P: 1, R: 2 }
- reviewed: "2026-08-17"
- gap:
- E: "Choke point exists and is tested; RLS not provisioned. Blocked on
- rapp-postgres publishing the GUC contract. Target Q4."
- R: "Retention declared; erasure horizon not yet published to consumers."
-Placement exceptions. Draft-2 assigned one P level per service, which cannot express the vertically partitioned model — most tenants pooled, some dedicated — that §11's isolation tiers require. A tier requiring P2 bought by three tenants would put the service at two levels at once, forcing an over- or under-claim. Placement is therefore declared as a default plus exceptions:
placement_exceptions: - - tenants: ["tenant:enterprise:*"] - P: 3 - reason: "isolation tier; see adaptive-pricing tier definition"-
A service with exceptions must be able to say which tenants are on which substrate. That mapping is a first-class artifact, not archaeology.
-Worked examples, best-effort and subject to owner correction:
-| Service | Current | Notes |
|---|---|---|
tenant-engine | I2 A3 E2 P1 R1 | Moving to P1 under TEN-WP-0009; retention declared, horizon not yet published. |
audit-core | I2 A3 E2 P1 R1 | Holds audit evidence, so both E3 and R2 are urgent targets. |
| A newly absorbed repo | I1 A1 E1 P0 R0 | Conformant if declared, with a recorded path. |
Decision 5.1: the posture vector is declared in the repo, not in the hub, consistent with local-files-are-source-of-truth.
-A service is conformant when its declared posture is accurate, its target is recorded, and it does not claim a level it cannot evidence. It is non-conformant when it overclaims — at any altitude.
E0 is conformant. Concealing E0 is not.Without the axis separation, "not rigorous about tenant separation" is one verdict a repo passes or fails. With it, the same repo is I1 A1 E1 P0 R0 with a path — a plan, not an indictment.
Movement between P levels must be operational, not a rebuild:
-Decision 7.1: mandatory at P1 and above. At P3, SHOULD rather than MUST — a per-client instance that never moves is not misconformant for naming its own database.
-Recorded at provisioning time: noisy neighbour on a latency-critical path; a compliance or residency requirement; a plan tier requiring a higher minimum; an erasure horizon that no longer fits (§4.5); connection or memory ceiling reached.
-Decision 8.1: triggers MUST be monitored, not merely recorded. A trigger in a YAML comment nobody re-reads is documentation, not control.
-Decision 8.2: placement policy ownership is proposed to railiance-platform, co-signed by adaptive-pricing. Tenancy model selection is a commercial decision as much as a technical one; an operations-shaped repo should not hold it alone.
Short-lived leased credentials re-read at connection checkout, with overlap-first rotation, bound the residual risk at every E level below E4: a leaked credential expires rather than persisting. Stronger than the industry norm of a long-lived per-service secret.
-Decision 9.1: static long-lived database credentials are not a sanctioned path for any service above E0.
-Decision 10.1: every platform holding consumer data MUST publish, in concrete terms, what a leaked runtime credential can and cannot reach at the levels it operates. rapp-postgres ADR-0001 §5 is the reference. Where the model cannot provide a guarantee, the platform says so and names the escalation.
Decision 10.2 — quotas are disclosed, not discovered. The same obligation extends from what a leaked credential can reach to what the platform will refuse to do for you. Every consumer MUST be told, at provisioning, the throttles and quotas enforced against it — connection limits, statement timeouts, idle-transaction timeouts — and told again when they change. A consumer learning its statement timeout by hitting it in production is a disclosure failure, not a consumer bug. This is how tenant-engine was provisioned, by good practice rather than by rule; the rule now exists.
E3 P2 R2; it need not print that anywhere customer-facing.Analyze. Assess a repo against the ladders; produce tenancy.current with reasoning recorded. Applies to new and absorbed services alike.
Establish. Declare the target and gap. The target is set by data class, tenant groupings served and plan tiers carried — not by ambition.
-Improve. Move one axis at a time. Raising P while leaving E untouched is the characteristic misstep.
-Guard. Verify continuously that the declared posture holds — against the service's own declaration, not a universal maximum. Nobody must prove every service is at E4; the check is that none is below what it declared.
-Regression found by guarding is a defect; regression declared in advance is a decision. The estate has been bitten twice by silent pin rollbacks producing ordinary-looking 403s and 404s rather than errors. Posture regression looks the same — an RLS context leak returns correct-looking rows for the wrong tenant. Guarding must be designed for invisible failure, not for crashes.
-Decision 13.1: a level is claimed only with its evidence artifact present. This turns §6's accuracy rule from an honour system into a check.
-Decision 13.4 — an artifact must assert something achievable. Draft-3's noisy-neighbour evidence required proof that a saturating consumer "does not breach" another's allowance. Shared infrastructure cannot provide that; the risk is inherent and cannot be wholly removed. An artifact that can only fail, or that passes by being run gently enough, is an overclaim wearing the costume of evidence. Where a property cannot be guaranteed, the artifact measures and records it instead.
-Decision 13.2 — evidence is of two kinds, and conflating them is an overclaim. Mechanical evidence is a structural assertion a machine can make and belongs in CI. Adversarial evidence is semantic, requires setting up separate tenant contexts and comparing responses, and carries a review date rather than a green build. Cross-tenant findings are the category external testing practice identifies as needing human review. A passing CI run is not E2 evidence.
-| Level | Evidence | Kind |
|---|---|---|
| I2 | Identifiers validated against the vocabulary; rejection test for a malformed id; binding shown to come from a verified token | Mechanical |
| I3 | Live re-query demonstrated on an aal2-class path; cached-claim path shown unused there | Mechanical |
| A2 | Choke point identified; test that an unbound request is refused | Mechanical |
| A3 | Live decision with a denial observed at the endpoint, not only at the decision surface | Mechanical |
| A4 | Decision served over the standard interface; a second PDP substituted without PEP change | Mechanical |
| E1 | Every tenant-owned table carries the tenant key | Mechanical |
| E2 | Choke point identified; identity bound to tenant A demonstrably cannot read tenant B | Adversarial, with a review date |
| E3 | FORCE ROW LEVEL SECURITY on every tenant table; no BYPASSRLS on leased roles; probe that a session without the GUC reads nothing; probe that a wrong GUC reads nothing; EXPLAIN comparison | Mechanical |
| E4 | Per-tenant credential demonstrated unable to connect to another tenant's substrate | Mechanical |
| P1–P4 | Provisioning declaration plus the platform's isolation probes | Mechanical |
| P1–P2 (noisy neighbour) | A recorded baseline of per-consumer resource usage; a run in which one consumer saturates its declared allowance; evidence that the governance controls bind (the greedy consumer is held at its limits) and that the degradation co-residents experience is measured, recorded and judged acceptable; the aggregate headroom at time of measurement | Adversarial, load-generated, with a review date |
| R2 | Declared retention rendered; erasure horizon published and reported in the operator surface | Mechanical |
| R3 | Sweep evidence records: timestamp, dataset, identifiers removed, authorising policy reference | Mechanical |
| R4 | Erasure demonstrated across live data, backups and derived copies within the horizon | Adversarial |
Decision 13.3: the E2, E3 and noisy-neighbour artifacts do not exist anywhere in the estate today. rapp-postgres runs 15 adversarial probes, all against the consumer boundary, none against the tenant boundary inside a consumer. Externally, what this framework calls a tenant boundary failure is Broken Object Level Authorization — OWASP API1, top of the API Security Top 10 since that list launched, and the most commonly exploited API vulnerability in published assessments. We have no coverage for the highest-ranked risk in our class of system. §19.3 seeks an owner.
Decision 14.1: external research is design input. This estate adopts published standards and structural patterns; it does not adopt tooling unless that tooling is an established industry standard with broad application. Everything else is built ground-up, so it can be optimised and refactored as the estate sees fit.
-| Class | Stance |
|---|---|
| Security baselines (OWASP Multi-Tenant Security Cheat Sheet, API Security Top 10) | Adopt as the external reference our ladders answer to |
| Standards bodies (OpenID AuthZEN 1.0) | Adopt — this is what A4 is |
| Reference taxonomies (Azure tenancy models, AWS SaaS Lens, cell architecture) | Adopt as structure |
| Engine behaviour (PostgreSQL RLS mechanics) | Facts, not tooling |
| Third-party analyzers and test frameworks | Do not adopt. Take their rule taxonomies as checklists for probes we write ourselves |
The practical effect is small and good: rapp-postgres already owns a ground-up probe harness — bash and psql, no dependency tree — that found four real defects in its own provisioning SQL. The evidence artifacts in §13 become new probes in a tool we control. One idea worth reimplementing from the external survey is policy-diff classification: labelling a change to an enforcement policy as safe or breaking before it lands.
One fixed model with a single set of characteristics (draft-1). Rejected: cannot describe a repo that is not there yet, forcing absorbed repos to misrepresent their posture or stay outside. A framework that can only describe its own end state is not a framework.
-A maturity model with a single overall level. Rejected: collapses the axis separation. A service strong on identity and weak on enforcement has a specific, actionable gap; one composite score hides it and invites averaging.
-Prohibiting row-level security (draft-2's inherited position). Rejected in draft-2, refined in draft-3: RLS is a real rung against the common threat. The error was never RLS — it was describing E3 in E4's language.
-Schema-per-consumer in one database. Rejected: pg_catalog is readable per-database, so every co-resident enumerates every other's table and column names regardless of grants. Retained as a describable state, never a target.
Mandating E4 for everyone. Rejected: the tenant taxonomy includes consumer (private individuals) and family. A cluster per private individual is economically impossible; the taxonomy is itself evidence pooling is required.
Per-consumer physical backup retention. Rejected: CNPG retention is a property of the instance's WAL archive. There is no mechanism, and claiming it would be a fabricated guarantee. Hence the derived maximum in §4.5.
-Platform-scheduled row expiry. Rejected: requires the platform to hold DML authority over consumer schemas and interpret consumer data semantics, both forbidden by ADR-0001. The consumer's migration lease is the correct instrument.
-Leaving each repo to its own model. Rejected: the status quo, which produced two contradictory ratified defaults and an unowned placement question.
-The graduated reframe is corroborated, not invented here. Microsoft's tenancy-model guidance states it almost verbatim: "Instead of viewing isolation as a discrete property, consider it a spectrum. You can deploy components of your architecture that are more isolated or less isolated than other components in the same architecture." The same guidance derives our E↔P coupling independently — shared deployment means enforcement lives in application code; dedicated deployment means it is structural.
-Stronger than typical. Most multi-tenancy literature models one boundary, tenant-to-tenant. This estate has two stacked boundaries: platform-service to platform-service, and tenant to tenant inside a consumer. Naming them separately and refusing to enforce both with one mechanism is uncommon and correct. Graduated per-axis levels also beat the silo/pool/bridge trichotomy, which is approximately our P axis with the other four missing — which is why it cannot express "pooled infrastructure, structurally enforced boundary".
-Weaker than typical. The pool model's standard mitigation is a verified enforcement layer every service is demonstrably routed through. We have the concept and none of the verification (§13.3).
-Adopted without naming it. Short-lived leased credentials re-read at checkout beat the long-lived-secret norm. §9 promotes it to a tenancy control.
-Still unexplored. Neither P nor R describes a cell — a slice of infrastructure with a fixed maximum size, sized so one cell's failure is survivable and cell count scales linearly. platform-pg is, in these terms, an uncapped cell: §17 computes a ceiling and nothing enforces it (§19.8).
Sources: the four research digests in research/2026-08-17-adr008-*, which carry full citations for every claim in this section.
Measured against the live platform-pg specification, not estimated.
instances: 1 (no HA; single-node rail) -max_connections: 100 -memory limit: 1Gi -per consumer: 14 connections (12 runtime + 2 migration)-
Connection ceiling: roughly six consumers — and this is the aggregate noisy-neighbour bound, not a capacity statistic. Seven consumers request 98 of 100 before CNPG's instance manager, metrics exporter and reserved slots. Every one of them is politely inside its declared 14-connection allowance; the instance still fails.
-That distinction matters because our governance addresses the wrong shape. Per-consumer connection_limit, statement_timeout and idle_in_transaction_session_timeout guard well against one greedy consumer. They do nothing about the aggregate of many modest ones, which is the second and less intuitive noisy-neighbour failure and the one this number describes. Two consumers are provisioned. We are at roughly a third of the bound, and the third request will not feel like a scaling event.
Memory likely binds first. 100 backends against 1Gi is ~10MB per backend. Connection exhaustion errors clearly; memory pressure OOM-kills and degrades every co-resident at once.
-E3 and pooling. Corrected from draft-2, which had this backwards. Transaction-scoped context (SET LOCAL inside an explicit transaction) is what makes E3 safe under a pooler. Statement-level pooling is what breaks it, serving other tenants' rows under concurrency with no error. E3 constrains which pooling mode is available, not whether pooling is available.
Retention consumes the volume. WAL accumulates with the window, and §4.5 makes the window the maximum across consumers. A consumer declaring a long retention extends everyone's horizon and everyone's storage draw against a 20Gi volume.
-Restore time couples all consumers. Physical backup is instance-wide, so a consumer's RTO is a function of total instance size, not its own.
-No P1 tenant has HA. instances: 1 means a tier promising uptime cannot be satisfied at P1 as built — an availability floor belongs in §11's minimum-level vocabulary alongside isolation.
tenantIsolation in PostgresConsumer is revealed as a mislabelled field.rapp-postgres acquires an obligation to define and offer the mechanism.tenantIsolation field — rapp-postgres: rename to name its axis and carry a level (tenancy.E: 2), or move it out of the storage declaration.railiance-platform with adaptive-pricing: accept the ladder, triggers and the §8.1 monitoring obligation; appoint a recorded placement owner per workload.audit-core and tenant-engine have declined fleet-scope work on correct boundary reasoning, so this needs appointing. Highest-severity gap.repo-classification-standard_v1.0.adaptive-pricing and tenant-engine: required only for tiers making isolation, availability or retention claims.rapp-postgres: publish the GUC contract with the FORCE/BYPASSRLS/SECURITY INVOKER/EXPLAIN requirements in §4.3.key-cape: realm-per-tenant or Organizations? Realm-per-tenant's ~5–20 tenant ceiling is below our target.platform-pg's declared maximum size, and what is the overflow target?" The connection ceiling forces this whether or not we adopt the vocabulary.backupRetentionDays have a platform minimum (so a consumer asking for 1 day gets a validation error rather than a quiet disappointment) and a maximum (so nobody exhausts the volume)?audit-core: crypto-shredding a tenant's audit records destroys the evidence the service exists to hold, and ADR-0001 §2 deliberately built the role model so history could not be rewritten. The usual resolution separates the fact of an event, retained, from its personal payload, encrypted per subject and shreddable. Raised because a naive "R4 everywhere" target would instruct the audit service to destroy its own evidence. The answer is audit-core's, not this framework's.tenant-engine sits on flex-auth's synchronous authorization path and chose a 5s statement timeout for that reason; it shares an instance with audit-core, which is not latency-critical. Nothing prioritises between them. Either add a QoS dimension or state that all co-residents are equal and latency-critical consumers must escalate to P2.Routed elsewhere, deliberately. The tenant identifier tenant:<grouping>:<name> embeds headcount bands (small, medium, large) that change as a tenant grows, contradicting the consensus that identifiers should not encode mutable attributes. That is a critique of ADR-0013, not of this framework, and belongs to tenant-engine and NetKingdom canon. Folding it in here would overreach.
tenant-engine, flex-auth, rapp-postgres, railiance-platform and adaptive-pricing against §19.rapp-postgres/docs/canon-drafts/shared-platform-relational-storage_v0.1-draft.md, whose §§3–8 are absorbed here. That draft is withdrawn rather than left pending.rapp-postgres ADR-0001 and ADR-0002 move to accepted and are annotated as the PostgreSQL implementation of the E, P and R ladders.Moved permanently to /standards/tenancy-posture/v0.1/index.html.
diff --git a/deploy/nginx.conf b/deploy/nginx.conf new file mode 100644 index 0000000..1b7839d --- /dev/null +++ b/deploy/nginx.conf @@ -0,0 +1,38 @@ +map $uri $policy_cache_control { + default "no-cache"; + ~^/standards/.+/revisions/ "public, max-age=31536000, immutable"; +} + +server { + listen 8080 default_server; + listen [::]:8080 default_server; + server_name _; + server_tokens off; + absolute_redirect off; + + root /usr/share/nginx/html; + index index.html; + charset utf-8; + etag on; + + add_header Cache-Control $policy_cache_control always; + add_header Content-Security-Policy "default-src 'none'; style-src 'unsafe-inline'; img-src 'self' data:; font-src 'self'; base-uri 'none'; form-action 'none'; frame-ancestors 'none'" always; + add_header Permissions-Policy "camera=(), geolocation=(), microphone=()" always; + add_header Referrer-Policy "no-referrer" always; + add_header X-Content-Type-Options "nosniff" always; + add_header X-Frame-Options "DENY" always; + + location = /healthz { + access_log off; + default_type text/plain; + return 200 "ok\n"; + } + + location = /tenancy-posture.html { + return 308 /standards/tenancy-posture/v0.1/index.html; + } + + location / { + try_files $uri $uri/ $uri/index.html =404; + } +} diff --git a/docs/adr/ADR-0001-addressing-and-permanence.md b/docs/adr/ADR-0001-addressing-and-permanence.md new file mode 100644 index 0000000..bae45d2 --- /dev/null +++ b/docs/adr/ADR-0001-addressing-and-permanence.md @@ -0,0 +1,60 @@ +# ADR-0001 — policy addressing and permanence + +- Status: accepted +- Date: 2026-08-18 +- Owner: the-custodian + +## Decision + +A document has one stable current address and immutable revision addresses: + +```text +/Moved permanently to {escaped}.
\n' + ) + + +def _index_page(site: dict[str, Any], records: list[dict[str, str]]) -> str: + rows = [] + for record in records: + rows.append( + "Canon and architecture decisions at stable addresses, with visible currency.
' + "| Document | Status | " + "Lifecycle | Revision | Owner | Reviewed | " + "Review due | Currency | " + f"
|---|
Source: {html.escape(source_note)}
Review due: {html.escape(review_due)}
' + if review_due + else "" + ) + lifecycle = publication.get("lifecycle", "active") + successor = publication.get("successor", "") + lifecycle_notice = "" + if lifecycle == "superseded": + successor_link = ( + f' Read its successor.' + if successor + else "" + ) + lifecycle_notice = ( + 'Superseded.' + f" This address is retained as part of the policy record.{successor_link}
Withdrawn. ' + "This document is retained for historical reference and is not current policy." + "
Review overdue. ' + f"This document was due for review on {html.escape(review_due)}.
{html.escape(args.subtitle)}
' if args.subtitle else "") + + (f'{html.escape(subtitle)}
' if subtitle else "") + + source_line + + review_line + '