Regions & residency.
A tenant is pinned to a region, and for KSA that pin is a hard routing constraint rather than a preference.
Choosing a region
Region is chosen at signup and locked once data has been ingested. Locking it is the point: a residency guarantee that can be switched off later is not a guarantee.
| Region | Means |
|---|---|
global | Default. No residency constraint. |
ksa | Stored and processed on KSA infrastructure only. |
eu | EU, for GDPR posture. |
us | US. |
What the KSA guarantee covers
For a KSA-region tenant, data is stored and processed in KSA and is not routed through non-KSA infrastructure. That includes model endpoints, not just databases — a retrieval that reached out to a non-KSA inference provider would break the guarantee just as surely as a non-KSA replica would.
- Storage — the canonical store for that tenant's rows.
- Processing — retrieval and answer generation.
- Anything downstream that would carry tenant content off-region.
This is one of the behaviours the codebase deliberately keeps out of model instructions. A residency rule that depends on a system prompt being followed is not a control. Routing decisions are code, and code is reviewable.
Why MENA first
The initial wedge is MSSPs in MENA and the GCC: nested multi-tenancy, white-labelling, KSA residency from day zero, and regional source coverage that global feeds under-serve. Residency is not a compliance checkbox bolted on late here — it shaped the tenancy model.
White-labelling
A tenant carries its own theme — brand name, logo, primary and accent colour, footer text, support address, and whether OmniIntel branding is shown at all. An MSSP's customers can therefore see their provider's brand rather than ours.
org_themes.color_scheme is tenant branding — the default every member sees. An individual's light/dark preference is a per-user cookie that overrides it, so one person switching does not re-theme the organisation.