Tenancy and isolation
A tenant is an isolated workspace. Every record belongs to exactly one, and nothing is shared between them.
Isolation is enforced in the database
Every tenant-scoped table carries a policy the database itself applies. A query that omits a tenant filter does not return everything — it returns nothing.
This is the difference between isolation that is enforced and isolation that is intended. Application-level filtering works until one query forgets, and that single omission is a cross-tenant data leak. Here, the query would have to defeat the database to leak.
Why cross-tenant reads look like 404, not 403
Requesting a record belonging to another tenant returns not found, not forbidden.
That is not obfuscation for its own sake — it is what the isolation actually does. The row is genuinely invisible to the query. Returning "forbidden" would mean the platform had looked, found it, and decided; it did not, and could not.
It also means an identifier cannot be probed to discover whether it exists in some other tenant.
What a tenant contains
Everything: entity types, attributes, records, match profiles, reference data, rules, users, roles, and audit history. Two tenants can model the same domain completely differently.
There is no shared schema imposed across tenants. Configuration is per tenant, which is what allows one deployment to serve organizations with genuinely different data models.
Identity across tenants
One person can belong to several tenants. Their access is resolved per tenant, and switching between them re-scopes everything — a fresh authorization context, not a filter applied to a broader view.
Platform scope
Some operations are inherently cross-tenant: provisioning a tenant, suspending one, reporting across the estate. These run under a separate platform scope that a tenant administrator cannot reach, however privileged they are within their own tenant.
Next
Last verified against commit 952ed91b (2026-08-03)