Multi-tenancy — tenancy by, tenantOwned, crossTenant

First-class B2B tenant isolation. One system-level declaration names the tenant claim and the tenant registry; every aggregate then declares its stance explicitly, and the toolchain applies the read scope to every generated query — the "forgot the filter on one query" cross-tenant leak becomes a compile error instead of an incident.

One clause opts a read out of it, and it is the only one: ignoring tenantOwned / ignoring * (the deliberate platform-admin cross-tenant report — see ignoring and the tenant filter below). It is not silent: every read that drops a tenancy filter raises loom.tenancy-filter-bypass, in every auth { enforcement: } mode.

Design record: proposals/multi-tenancy-design-note.md (R1–R5); implementation plan: plans/multi-tenancy-implementation.md.

Surface

system Billder {
  user { id: guid  email: string  tenantId: string }

  tenancy by user.tenantId of Organization      // claim + registry, one line

  subdomain Billing {
    context Catalog {
      aggregate Plan crossTenant { code: string  monthlyPrice: decimal }
    }
    context Invoicing {
      aggregate Invoice with tenantOwned { number: string  amountDue: decimal }
    }
    context Accounts {
      // The registry — named in `of`, no tenancy marker.  `with crudish` is not
      // decoration: the signup bootstrap two sections down turns on `POST
      // /organizations` existing, and an aggregate with no `create` emits a
      // read-only API.  `tenancy-owned.ddd` — the fixture that pins the
      // bootstrap end-to-end — declares it the same way.
      aggregate Organization with crudish { name: string }
    }
  }
  // deployables need `auth: required` — the filter/stamp read the principal
}

• tenancy by user.<claim> of <Registry> — a system member (peer of user {} / auth {}). Names the user-shape field that carries the tenant id and the one aggregate that is the tenant registry. At most one per system; the claim field must exist on user {}; the registry must exist.

• with tenantOwned — a built-in prelude capability (src/macros/prelude.ts, next to auditable / softDeletable). Unfold it and you get exactly:

  aggregate Invoice {
    number: string
    amountDue: decimal
    // — what `with tenantOwned` expands to —
    tenantId: string internal
    dataKey: string? internal
    stamp onCreate {
      tenantId := currentUser.tenantId
      dataKey := currentUser.orgPath
    }
    filter this.tenantId == currentUser.tenantId
  }
  

  The tenantId column lands in the migrations automatically — with a derived non-unique <table>_tenant_id_idx (every tenant read prefixes on that column; derived in the shared MigrationsIR, so all DB backends emit it); internal keeps both columns out of create inputs (the client can never pass them); the filter is AND-ed into every generated read on all five backends; the stamp copies the claim at create.

  The two tenantIds are different things. The one on the row is the COLUMN this capability provides — always spelled tenantId, not the author's to rename. The one it is compared against is the declared claim, whatever tenancy by user.<claim> named. They coincide in the examples here only because those declare the claim as tenantId. Under tenancy by user.orgId, node emits eq(t.tenantId, requireCurrentUser().orgId) and stamps tenantId: currentUser.orgId. The capability itself cannot see the declaration (a prelude definition has no system in scope), so enrichment binds the principal side in phase ⑥ — the same pass that derives the registry self-scope, which is why both halves now agree on one claim.

  dataKey (multi-tenancy Phase 2, plan P2.3) is the materialized DataKey path, stamped unconditionally from currentUser.orgPath — the same claim-copy stamp mechanism as tenantId, riding the identical contextStamp pipeline (no per-backend code: every backend already renders currentUser.orgPath for the P2.1/P2.2 filter use-site; a stamp assignment is the same expression renderer, a different call site). It is stamped on every tenantOwned aggregate regardless of whether the registry has opted into implements tenantRegistry — under flat tenancy orgPath resolves to the tenancy claim itself (P2.1's fallback, a correct root-only path); once the registry opts into hierarchy, orgPath resolves to the real materialized path with nothing here needing to change. Unlike tenantId, dataKey is not just internal — authorization.md §2 calls it a persistence column only, so wireFieldsForAggregate (src/ir/enrich/enrichments.ts) drops it from wireShape entirely: it never appears in .loom/wire-spec.json, a DTO, or any read response — a stricter exclusion than tenantId's (which stays in wireShape, just filtered out of API reads). No read-side filtering rides dataKey yet — that is the policy { data {} } ladder, P2.4.

• crossTenant — an aggregate-header modifier, for shared reference data (Plan, Country). A stance marker: attaches nothing, generates nothing — it exists so "no tenant filter" is a declared decision, never an accident. It sits in the header region after the aggregate name, alongside the realization axes (persistedAs: / shape: / inheritanceUsing:) and order-independent with them — aggregate Plan crossTenant { … }. It is deliberately not a leading adjective like abstract: abstract says what the aggregate is, while crossTenant declares how it participates in the tenancy by facility. (M-T5.17 sort-by-meaning amendment.)

• The registry gets no marker — it is self-keyed (its "tenant" IS its own id), so neither stance fits it. Since Phase 1b it DOES get generated read behavior: the derived self-scope filter (below). Who may read or edit organizations beyond that is authorization's job.

The registry: derived self-scope + claim-less bootstrap (Phase 1b)

tenantId ≡ <Registry>.id is a derived type link (capstone decision 4): from the tenancy by declaration alone, every read of the registry is scoped to the caller's own org. You never write this filter — enrichment appends it to the registry's capability filters, so it rides the exact pipeline tenantOwned's predicate uses:

aggregate Organization { name: string }   // you write only this
// derived by the toolchain (never in source):
//   filter this.id == currentUser.tenantId

// node — db/repositories/organization-repository.ts (generated)
async all(): Promise<Organization[]> {
  const rootRows = await this.db.select().from(schema.organizations)
    .where(eq(schema.organizations.id, requireCurrentUser().tenantId));
  ...
}

So GET /organizations/<own id> → 200, GET /organizations/<other id> → 404 (existence hidden), and the list contains exactly your own org.

Claim-less signup bootstrap. Filters never gate creates and the registry carries no stamp, so POST /organizations works for any authenticated principal — including one whose token has no (or a foreign) tenant claim. The created org's id is then a valid tenantId claim value (that's the identity), closing the signup loop: create org → issue token with tenantId = <org id> → read it back. Pinned end-to-end by test/e2e/tenancy-isolation.test.ts (LOOM_TENANCY_E2E=1).

The id-vs-claim type rule. The registry id is usually guid; JWT claims are usually strings. The comparison binds the claim as the id's value type at each backend's accessor site:

A malformed tenant claim (an authenticated token carrying tenantId: "not-a-guid") is an ordinary empty read on every backend — the same 200-with-an-empty-list / 404-by-id a foreign-but-well-formed claim gives, never a 500. That is what the parse-to-null accessor buys: the string claim is coerced in the host language before it reaches the database, so a value the guid id cannot represent binds NULL and matches no row. A missing principal claim takes the same path, for the same reason.

.NET has always done this (Guid.TryParse); the other four parsed unconditionally and answered a bad token with a stack trace until M-T3.7(c). Pinned on every behavioural leg by corpus/tenancy-owned (the harness principal's claim is not a uuid, so the registry reads 404 / empty, never 500), by the remaining .NET and Java tenancy-registry-self-scope generator suites for the guid-claim and Criteria arms, and end-to-end by assertCrossTenantIsolation (the tenancy-e2e matrix, all five backends × {flat, hierarchy}).

Per-backend registry read scope (all five compile-gated, and all five runtime-gated by the isolation e2e):

The derived filter is provenance-tagged tenancy in contextFilterOrigins. tenancy is not a capability, so a named ignoring tenancy is rejected (loom.filter-bypass-unknown-capability); only an explicit ignoring * read — the same authored escape hatch that drops tenantOwned's filter — bypasses it.

The bundled dev Keycloak's demo tenant

Because the self-scope matches only a uuid claim, the demo user of the bundled dev Keycloak (bundled for any auth { oidc … } block, whatever the provider) is seeded with a uuid tenancy claim, 00000000-0000-4000-8000-00000000de40 (DEMO_TENANT_ID, src/ir/util/demo-tenant.ts) — not demo-<claim>, which matched no registry row ever (eval-closure #26). A matching first-boot registry row ships through the ordinary seed path: enrichment appends a raw seed row (id = that uuid, dataKey = the same uuid when the registry is a tenantRegistry root, a synthetic value for every other required scalar column) in its own dataset, loomDemoTenant, and the generated dev compose sets LOOM_SEED: "loomDemoTenant" on the backend hosting the registry. Like every non-default dataset it runs only when LOOM_SEED names it, so a production boot never inserts a demo tenant. A registry whose required columns have no obvious synthetic value (a value object, an X id reference, a list), or that is inherited, event-sourced, non-relational or not on Postgres, gets no row — the realm claim is still the uuid. The demo user's permissions are deliberately not seeded, so denial stays demonstrable. The allow path is a second seeded user, demo-admin / demo-admin, emitted whenever the system declares a permissions { } block: it carries every declared permission (the <subdomain>.<name> runtime strings) through whichever claim permissions reads — the flat user attribute, or realm roles when it is mapped onto realm_access.roles. Every other id-typed claim (agentId: Agent id?) is seeded with the all-zero uuid the dev stub uses, and the realm's user profile sets unmanagedAttributePolicy: ENABLED, so a claim attribute granted later through the admin console survives into the token.

ignoring and the tenant filter

ignoring tenantOwned (and ignoring * on a tenant-scoped aggregate, which subsumes it and the registry self-scope above) is the ONE way to read across tenants, and it is a real, supported shape: the platform-admin report that has to total every tenant's rows. What it is not is a quiet one — it removes the boundary the whole feature exists to provide, and the emitted query then carries no tenant predicate at all:

projection PlatformRevenue {          // every tenant's revenue, to any caller
  revenue: money
  from WorkOrder as w ignoring tenantOwned
  select revenue = sum(w.amount)
}

// the emitted read — no `where`, where the un-bypassed sibling carries
// `.where(eq(schema.workOrders.tenantId, requireCurrentUser().orgId))`
const [row] = await db.select({ revenue: sum(schema.workOrders.amount) }).from(schema.workOrders);

So every such read raises loom.tenancy-filter-bypass (a warning, naming the read, the aggregate and the claim that no longer applies). Three properties of that gate are deliberate:

• It does not consult auth { enforcement: }. The language default is enforcement: opt, which gates nothing at all; and under denyByDefault, requires true satisfies the ungated-read check while leaking exactly as hard. The question this gate asks is "does this read drop the tenant filter", not "does this read have some gate".
• It is a warning, never an error. The escape hatch keeps working — the model still compiles and the cross-tenant read is still emitted.
• It fires only on a TENANCY bypass. ignoring softDeletable widens a read to rows the caller's own tenant already owns and stays silent, as does ignoring * on an aggregate with no tenancy filter in scope.

If the cross-tenant read is deliberate, gate it behind an explicit platform-admin requires and keep it off tenant-facing APIs; the warning stays, as the standing record that this read crosses the boundary.

The explicit-stance rule (the safety story)

Under a system with tenancy by, every persisted aggregate must declare a stance — with tenantOwned or crossTenant (the registry and abstract bases are exempt; a subtype inherits its base's stance). An unmarked aggregate is a hard error:

Inheritance: a subtype inherits its base's stance

An abstract base is exempt from the rule because it persists no rows; its stance reaches every subtype (D-INHERITED-CAPABILITIES). abstract aggregate Vehicle with tenantOwned makes each … extends Vehicle tenant-owned — the column, the stamp that fills it and the filter that scopes reads by it — with no marker of its own. Writing crossTenant on such a subtype is loom.tenancy-inherited-stance-conflict: the subtype would be both tenant data and shared data. A crossTenant base makes its subtypes crossTenant the same way.

There is deliberately no severity knob: the escape hatch is writing crossTenant — one keyword, intent declared. This is fail-closed without magic: nothing is ever injected by the distant tenancy by line; the capability the aggregate wrote carries the fields (unfoldable, reviewable).

What each backend emits

The filter and stamp ride the standard capability-filter/stamp pipeline — tenancy adds no bespoke backend code:

The principal-side spellings below assume the common tenancy by user.tenantId declaration; under any other claim name the currentUser.… half follows the declaration while the row column stays tenantId.

Frontends need nothing: enforcement is server-side, and neither tenantId nor dataKey ever appears in create forms. tenantId (like softDeletable's isDeleted) is wire-visible on reads today — internals aren't hidden from read DTOs by default. dataKey is the exception: it is dropped from wireShape entirely (see above), so it never reaches any read DTO either.

Cross-tenant reads of another tenant's row return 404 (existence hidden), falling out of the filter semantics: the row simply isn't found.

Reactors and timers — the system principal's tenant

An event reactor runs as the system principal (D-REACTOR-SYSTEM-PRINCIPAL), and filters and stamps inside it use the triggering event's tenant: the system principal copies the tenancy claim and orgPath from the principal of the request that raised the event, so a reactor reads and writes in exactly the tenant its event came from. A timerSource tick has no originating request and therefore no tenant — a tenant-owned read in a timer-driven reactor would match nothing — so it must be explicitly cross-tenant: declare it as a find (or an inline Repo.run) with ignoring tenantOwned, or loom.timer-tenant-read (error) refuses it.

repository Jobs for Job {
  find anyTenant(c: string): Job where this.code == c ignoring tenantOwned
}
workflow sweepRun {
  sweep: Sweep id
  create(t: SweepTick) by t.sweep {
    let j = Jobs.anyTenant("x")      // `Jobs.byCode("x")` here: loom.timer-tenant-read
    j.close()
  }
}

An event that crosses the transactional outbox or a broker carries its origin — tenant, orgPath, causedBy — on the outbox row and as the envelope's tenantid / loomorgpath / loomcausedby attributes, and the relay / consumer delivers it as the system principal of that tenant, so a relay- or broker-fed reactor reads and writes in the event's tenant too (channels.md § Event origin).

Hierarchy — the registry tree (implements tenantRegistry, Phase 2)

The tenant registry opts into a hierarchy by carrying implements tenantRegistry — a built-in prelude capability (src/macros/prelude.ts, next to tenantOwned). It provides two managed tree fields; the author writes neither (unfold the capability to see them):

tenancy by user.tenantId of Organization

aggregate Organization {
  name: string
  implements tenantRegistry
  // — what `implements tenantRegistry` provides —
  //   parent: Organization id?   immutable   // self-FK; null = root org
  //   dataKey: string?           managed     // the materialized path
}

• parent: Self id? — an immutable, nullable self-FK (Self resolves to the registry aggregate). immutable keeps it settable at create (the signup bootstrap passes it) but frozen after — reparent is out of scope (immutable paths are what make deep a cheap prefix scan). It lands in migrations as a nullable self-referential FK (parent uuid null references organizations(id)) plus an organizations_parent_idx.
• dataKey: string? — the managed materialized path (data_key text null, off create/update inputs, present on reads). Its value is computed server-side in the author-written signUp create factory via the workflow-tier repo-let on the parent (dataKey := parent.dataKey + "." + <segment>); a capability is a pure mixin, so it carries the field but cannot inject a repo-reading create body. Root orgs get a root-segment path; children extend the parent's.

Structural verification (src/ir/validate/checks/tenancy-checks.ts): only under a tenancy by system (loom.tenant-registry-without-tenancy), exactly one aggregate (loom.tenancy-registry-duplicate), and it must be the of <Registry> target (loom.tenancy-registry-not-target). parent's immutability and self-reference are structural (the access modifier + Self), so neither needs a check.

currentUser.orgPath under hierarchy

orgPath (the P2.1 principal member) is the caller's materialized path. With no tenantRegistry (flat tenancy) it is the tenancy claim itself — the root-segment path, since there is no dataKey column to read. Once the registry implements tenantRegistry, the principal resolves orgPath from the registry's data_key column, memoized per request, keyed by the tenancy claim:

select data_key from organizations where id = <currentUser.tenantId>

Fail-safe: a missing row, a null data_key (pre-tree data), or any lookup error falls back to the claim value — never null, never a crash. Wired on all five backends, each through its own request-scoped principal seam:

The policy {} read ladder (local / deep / global, Phase 2 P2.4)

A policy {} context member selects a per-aggregate read reachability level for tenant-owned aggregates — the directional ladder from proposals/authorization.md §3 (Self / Descendants / All ≈ local / deep / global). It is the read side of the hierarchy: P2.1–P2.3 wrote dataKey; P2.4 reads by it.

context Ledger {
  aggregate Invoice with tenantOwned { amount: Money }
  aggregate Org { name: string  implements tenantRegistry }
  // …
  policy {
    allow deep on Invoice        // caller's org + all descendant orgs
  }
}

Each rule rewrites the aggregate's tenantOwned capability filter (its contextFilters entry), riding the exact per-backend query seams the flat tenant floor already uses (Drizzle .where, EF HasQueryFilter, SQLAlchemy with_loader_criteria hook, JPA @Query/Specification, pinned Ecto where:) — no new backend plumbing. The levels:

The descendant test is two terms — an escaped LIKE prefilter and an anchored recheck, in that order (M-T3.17):

data_key LIKE <escaped-anchor> || '.%' ESCAPE '!'   -- sargable: rides <table>_data_key_idx
  AND strpos(data_key, <anchor> || '.') = 1         -- decides the row; no pattern language

The row is admitted by the anchored test, which has no pattern language at all — that is what keeps an org legitimately named acme_corp from reading acmeXcorp.… (#2562's orgXa.leak trap). The LIKE in front exists only so the planner can turn the pattern's fixed prefix into an index range over the data_key text_pattern_ops index instead of sequentially scanning the tenant's whole table; !, % and _ in the anchor are escaped with ESCAPE '!'. The two-term split is deliberate: a mistake in the escaping can only make the prefilter wider, and the recheck still throws the extra rows away, so sargability can never cost isolation. EXPLAIN proof: test/e2e/tenancy-subtree-explain.test.ts.

Generated deep filter, one line per backend (for allow deep on Account):

(esc(…) above is each language's inline escape chain — !→!!, %→!%, _→!_, then + ".%". The five spellings live together in src/generator/_expr/subtree-like.ts.)

Three settled semantics decisions (authorization.md §9 leaves them to P2.4):

1. NULL-dataKey fallback (OR-fallback, not pure fail-closed LIKE). Rows stamped before P2.3 — or by a principal-less save — carry a NULL data_key, which a bare prefix LIKE silently hides. deep therefore ORs in dataKey IS NULL AND tenantId == currentUser.tenantId: NULL rows degrade to exactly the local floor, staying visible to their own tenant and never widening past it (no cross-tenant leak). This preserves flat-tenancy correctness for legacy rows while the tree fills in.
2. Delimiter-correct prefix. The descendant match is path exactly OR path || '.' + more (the . segment separator), so org_a never prefix-matches org_ab. The text_pattern_ops opclass on data_key ships as P2.5 and is what the escaped-LIKE prefilter rides (M-T3.17).
3. global = the caller's root-org subtree (P2.5). authorization.md §2 says "all in my tenant, never the whole table." Under a hierarchy global is the full root subtree — every org descending from the caller's root org — emitted as the same descendant-or-self prefix scan as deep but anchored at currentUser.rootOrg (the first orgPath segment) instead of orgPath. The accessor is a pure string derivation off the already-resolved orgPath (no extra DB read); every backend exposes it beside orgPath. Under flat tenancy every org is its own root, so rootOrg == orgPath == the tenant floor and global == deep == local all coincide — and global/deep still require a tenantRegistry hierarchy (loom.policy-level-requires-hierarchy), so a flat model keeps the fail-closed floor. It never leaks past the tenant root.

The ladder is still a compiler-owned sentinel, not startsWith (yet). Both levels lower to an authz-filter { kind: "scope" } node that each backend renders natively — see buildDeepScopeFilter / buildGlobalScopeFilter in src/ir/util/tenant-stance.ts. The reconciled surface (tenancy-authorization-final-surface decision 2) retires that sentinel in favour of an ordinary filter written in the language, and its prefix operator now ships: startsWith is queryable on every backend (stdlib.md → string), lowering to an anchored strpos(col, $p) = 1 rather than a LIKE so a %/_ in the prefix VALUE matches literally. What the swap still needs is two more queryable shapes the sublanguage lacks — string concatenation (currentUser.orgPath + ".") and != null on the internal dataKey column — because the sentinel's NULL-dataKey OR-fallback (decision 1 below) is load-bearing and must survive it. Until then the operator is available to authors and the ladder keeps its sentinel.

Validation (fail closed). deep/global need a tenantRegistry hierarchy (loom.policy-level-requires-hierarchy); the target must be a tenant-owned aggregate in the same context (loom.policy-unknown-aggregate, loom.policy-target-not-tenant-owned); one level per aggregate (loom.policy-duplicate-target). The minimal surface is the read ladder only — operation/view/field gates, deny, and policy function/let helpers stay later proposal work.

organizationContext — the operating scope and its switch gate

currentUser is the principal: who is calling, their permissions, and — through currentUser.orgPath — their own org. organizationContext is the operating scope: the org this request acts in. The two coincide unless the request asks to operate in a descendant org, by sending an x-org-context header carrying that org's materialized path. Design record: organization-context; reconciled surface decisions 3–5 of tenancy-authorization-final-surface.

It has exactly one member, organizationContext.orgPath, and its first use is the tenant write stamp — an admin at org_a creating a row that belongs to org_a.b without a per-write registry read:

system OrgContext {
  user { id: guid  tenantId: string }
  tenancy by user.tenantId of Org

  // The reconciled surface's tenantOwned: the WRITE stamp follows the operating
  // scope, the read filter stays on the principal.  A user-declared capability
  // of the same name replaces the prelude's.
  capability tenantOwned {
    tenantId: string internal
    dataKey: string? internal
    stamp onCreate {
      tenantId := currentUser.tenantId
      dataKey := organizationContext.orgPath
    }
    filter this.tenantId == currentUser.tenantId
  }
  // … Org implements tenantRegistry, Account with tenantOwned,
  //   policy { allow deep on Account }, an `auth: required` deployable
}

// node — auth/middleware.ts (generated): the gate, between resolving the
// principal's orgPath and building the principal
const orgPath = await resolveOrgPath(String(claims.tenantId ?? ""));
const requestedOrgContext = c.req.header("x-org-context");
const orgContextPath = orgContextFor(orgPath, requestedOrgContext);
if (orgContextPath === null) return orgContextForbidden(c, requestedOrgContext ?? "", orgPath);
const user: User = { ...claims, orgPath, rootOrg: rootOrgOf(orgPath), orgContextPath };

// db/audit-stamp.ts (generated): the stamp reads the operating scope
return { ...row, tenantId: currentUser.tenantId, dataKey: currentUser.orgContextPath };

The gate. The accessor re-roots the write stamp from an unforgeable claim onto a value the caller submits, so it exists only together with a fail-closed, per-backend gate. Each backend's auth middleware resolves the operating scope once per request, before any handler runs:

The containment test is the delimiter-correct prefix every deep read uses — equality, or startsWith(orgPath + ".") — so org_a never admits org_ab. A refused request never reaches a handler: nothing is written, and the 403 is an RFC 7807 problem ("title": "Forbidden"). The deny is logged through the neutral catalog (org_context_denied, warn, fields org_context / reason / status) on all five backends.

Reads stay principal-anchored (reconciled decision 4, verified — not rebuilt): every derived tenant filter and the deep/global ladder anchor on currentUser, never on organizationContext. A switched request reads exactly what the caller would read without the header. A read that an author anchors on organizationContext.orgPath can only narrow: the gate guarantees the operating scope lies inside the principal's subtree.

What it does not do (yet). tenantId stays principal-anchored, so a row created under a switch carries the caller's tenantId and the target org's dataKey: it is visible to deep reads from the caller's org and the target's ancestors, and to deep reads from the target org itself, but not to the target org's local floor. There is no organizationContext.orgId (deriving an org id from a submitted path needs a registry read by dataKey). The prelude's own tenantOwned still stamps currentUser.orgPath; re-rooting it (so every tenant-owned write follows the operating scope) is a separate, owner-decided change, because it would put the gate in front of every tenancy system.

Validation (fail closed). loom.org-context-surface — a bare organizationContext, any member but orgPath, or any read inside a ui (a frontend has no switch gate). loom.org-context-gate-unmet — a read with no tenancy by … of <Registry> whose registry implements tenantRegistry (nothing to switch within), or a read in a context hosted by a backend deployable without auth: required. The runtime proof is the org-context leg of tenancy-e2e on all five backends (npm run test:tenancy-org-context*).

Scope and roadmap

Phase 1 is flat tenancy (local reads — tenant-id equality). The registry self-scope + claim-less bootstrap shipped as Phase 1b (above). The registry tree (implements tenantRegistry → parent + managed dataKey) + the orgPath registry read on all five backends shipped as Phase 2 P2.2 (above). Stamping dataKey on every tenantOwned aggregate (P2.3, above) shipped too. The deep/global policy {} read ladder (P2.4, above) shipped. The materialized-path dataKey prefix index (text_pattern_ops) + the currentUser.rootOrg accessor that widens global to the root-org subtree shipped as P2.5 (above) — closing multi-tenancy Phase 2. Also shipped since:

• The claim/registry cross-reference upgrade (capstone decision 5) — the tenancy by bindings are now real Langium cross-references (claim=[UserField:UserFieldName] 'of' registry=[Aggregate:ID] in src/language/ddd.langium), so an unknown claim/registry is a linking error (with navigation/rename) rather than a themed validator code. Byte-identical surface.
• tenant_id index — the derived non-unique <table>_tenant_id_idx is emitted for every tenantOwned table (via derive("tenant_id") in withTenantIndex, src/system/migrations-builder.ts), riding the shared MigrationsIR directly like the dataKey prefix index — a derived, non-authored index that needed no index: surface. (Consistent with the tenant_id_idx note under with tenantOwned above.)