Tenancy matrix

The narrative is in Multi-tenancy; this is the exhaustive surface — every integration, the tiers it reaches, and how. Tiers (TenantIsolationMode) are none < tagged < namespace < dedicated, classified by the isolation you get:

• none — a deliberately shared resource with no tenant boundary at all.
• tagged — one shared container, a tenant marker you filter on (leakable by a forgotten predicate).
• namespace — a separate key / path / schema / collection / dataset / index per tenant; a name boundary a query can't cross.
• dedicated — a separate instance/connection per tenant (a routed client).

tenant_aware=True reaches tagged on a column store and namespace on a key/path store (the prefix is a separate key). A per-tenant resolver reaches namespace; a routed client reaches dedicated.

Stores you query¶

A store read under the bound tenant scopes itself — adapters call ctx.inv_ctx.get_tenant() on their own, no handler argument.

‡ The dynamic-read plane declares origin="compiled", so its floor is namespace and both tagged and none are refused as statement_origin_isolation_floor. Its statements are written at runtime, so an isolating predicate cannot be reviewed, cannot be checked at wiring, and when it is missing the read succeeds with another tenant's rows. A per-tenant schema is the weakest container that does the scoping the statement cannot be trusted to do.

† Neo4j reaches namespace with a per-tenant database on one driver (the usual multi-tenant Neo4j shape); dedicated needs a genuinely per-tenant driver/instance, which routing supports but is the less common deployment.

Messaging you consume — the read-side catch¶

A stream, queue, or table drained in the background has no ambient tenant — the consumer isn't inside a tenanted request. So isolating the resource doesn't isolate the read: the consumer must bind the tenant itself.

Here tenant-global means the resource is deliberately shared across tenants (≈ tier none) — the sensible default for anything a tenant-less worker drains, since the worker can't bind a tenant to read an isolated one. It is not the tagged tier: rows may carry a tenant_id, but that's for the worker to route each item, not a filter that isolates the store. Isolating the resource itself moves the worker to a sharded, per-tenant read.

The rule across all of these: the reader binds the tenant. A handler-read store binds it from the request; a background consumer binds it from the resource it was assigned (a sharded stream key) or from each item it processes (the relay per row). That's why the default for relay/worker-drained resources is tenant-global, and isolating them is opt-in — it costs a sharded reader.

Declaring and enforcing a floor¶

required_tenant_isolation on a deps module refuses to wire anything weaker than the declared tier — checked once at startup, never per request. Each module derives the tier it reaches from its config (routed client → dedicated, resolver → namespace, tenant_aware → tagged/namespace by backend). A floor a backend can never reach fails as a capability mismatch, not a silent misconfiguration:

See Multi-tenancy → Declaring a minimum for the wiring, and → Provisioning for creating the per-tenant containers the stronger tiers assume.

The floor a route can't lower: statement origin¶

The tier tells you how strong a route's container is. It doesn't tell you what kind of text runs inside it, and that's the other half of whether the route is safe. A route declares its StatementOrigin, and its tier has to reach that origin's floor:

No shipped route declares an origin yet, so today this changes nothing you wire — including the Neo4j raw hatch, which is still governed by allow_raw_query and your own required_tenant_isolation, not by the raw floor above. The floors bind a route the moment it declares one; until then the table tells you which tier a route would need.

compiled floors at namespace, not tagged, and the reason is worth internalizing before you argue for the weaker tier: verification raises confidence in a claim; it doesn't create a boundary. A read-set check runs over generated text, so a compiler bug or a construct the checker renders imprecisely yields a statement that passes the check and reads what it shouldn't. At tagged that's a silent cross-tenant read in a report that renders perfectly. At namespace the same defect names a relation that doesn't exist, or stays inside the tenant's own container. The floor follows from what happens when the check is wrong, not from how good the check is.

The consequence is architectural: compiled at namespace means per-tenant containers, so whatever names those containers is a security-relevant component, not a readability one. A compiler that bakes namespace names into its artifacts is baking in an isolation boundary.

Origin composes with required_tenant_isolation — a route clears both, and the stronger requirement is the one that governs. They fail differently on purpose:

When both are unmet you get the origin one, because it's the floor you can't negotiate with — lowering your declaration would leave the route failing anyway.

Origin is a wiring fact, checked once at startup. No statement is ever parsed to infer where it came from.