Organisation settings and your home region
The settings that belong to the organisation rather than to a person, what a home region actually guarantees, and the one exception we refuse to paper over.
Some settings belong to a person and some belong to the organisation. This article is about the second kind — the ones that describe your tenancy as a whole, and in particular the home region, which is the setting most likely to appear in a client's security questionnaire.
The second half of the article is about a distinction we insist on making, and it is the reason this page exists rather than a paragraph on the pricing site: where your data is stored and where an AI model processes it are two different questions with two different answers.
What the organisation record holds
Your organisation carries a small set of properties that shape everything else. Most of them you will never change; all of them are worth being able to read when somebody asks.
- Name and slug
- The display name and the short identifier used in URLs and in provisioning. The slug is part of how a repeated provisioning request is recognised as the same organisation rather than a new one.
- Home region
- The region your organisation is bound to. This is the setting the rest of this article is about.
- Active cell
- Which deployment of the platform actually serves you. A cell is an isolated running copy of the platform; Enterprise customers can have a dedicated one to themselves, in the EU.
- Lifecycle state
- Active, suspended or deprovisioned. See the next section — the middle one has teeth.
- Service tier and provisioning status
- Which plan you are on and whether the tenancy has finished being set up. Both appear in the diagnostics view an operator can request; see Support access, and what we can see.
- Residency policy and placement version
- The recorded rule about where your tenancy may run, and a version number so that a change to your placement propagates as an ordered event rather than a race.
The three lifecycle states
| State | Effect |
|---|---|
active | Normal operation. Members can be invited, API keys created, single sign-on providers configured. |
suspended | An emergency hold. The organisation is marked inactive, your organisation's API keys are revoked, and active sessions for your members are deleted. Anyone signed in is signed out. |
deprovisioned | Terminal. The record remains so that history stays attributable, but the organisation is inactive and cannot be reactivated through the current API. |
What a home region actually guarantees
Your organisation is bound to one region, and the binding is checked rather than assumed. A request carrying a token from a different region is refused rather than silently served. That is the whole claim, and it is deliberately narrower than the phrase 'EU data residency', which we do not use unqualified.
When the check refuses, the reason is this string, which you may see quoted in a support thread:
residency: org home region does not match cell regionThe reason the refusal is worth more than a promise is that it is the wrong-region case failing loudly. A design that quietly served the request would be indistinguishable, from your side, from one that had no residency model at all — right up until an auditor asked and nobody could show anything.
Placement is created by the control plane before your traffic is routable, and traffic is enabled only once both the placement record and the cell serving you are ready. Three parts of that design are still pending: dedicated capacity APIs for operators, cryptographically signed placement records, and per-cell confirmation of completed bootstrap. None changes what you can do today; all would strengthen the guarantee, which is why they are on the list rather than in the marketing.
A contractual residency addendum — as opposed to the architectural binding described above — is an Enterprise arrangement. The distinction is real: the binding is a property of the software, and the addendum is a promise in a contract, and neither substitutes for the other.
The exception: AI inference is a separate question
Storing your data in a region and processing it with a large language model in that region are two different things. A model endpoint has a configured region, and that is not a statement about where inference actually runs — providers may route work elsewhere. Treating the two as the same is how a vendor makes a residency claim it cannot evidence, and this product did exactly that once: the AI system card hardcoded the words 'EU only', and it was not true.
What it says now is the literal string unverified in every case except one. Your organisation's AI system card reports an inference region, and the value depends on which of four situations you are in.
| Situation | Reported as | What it means |
|---|---|---|
| The verdict is in-EU, its provenance is verified or derived, and no override is recorded | The actual region and its location | The only case in which EU residency for inference is reported as holding. This is the one branch that produces a real region. |
| An operator has explicitly allowed non-EU inference or a non-EU endpoint | unverified | The override is recorded on the card, along with a disclosure stating that alert text, process command lines, hostnames, user names and sign-in addresses go to a non-EU endpoint, and that no EU data-residency guarantee applies to AI inference for that deployment. |
| The model platform publishes no EU inference geography for that model family | unverified | We know we cannot establish it, so we say so rather than inferring it from the endpoint's region. |
| Anything else | unverified | EU residency for inference is not established to a verifiable standard for that deployment. An operator asserting it is not evidence. |
One consequence is the point of the whole design. If somebody at Qorionix types a region into the configuration, it is reported separately as the configured endpoint region, labelled informational only and not the basis of any claim above. It cannot flip the residency answer to yes. An operator assertion is not permitted to become a customer-facing guarantee, and that is enforced in the code that builds the card rather than left to whoever writes the copy.
The EU-resident AI processing add-on, and why you cannot buy it
There is a priced add-on for EU-resident AI processing — €3 per identity per month, for Complete and above — and it is deliberately not available. It is published with its price and marked unavailable rather than removed from the page, which is unusual enough to deserve an explanation.
The reason is the one described above: our model provider does not currently offer a contractual guarantee that inference runs inside the EU. Selling the add-on would mean charging you for a residency claim we could not evidence, and we would rather sell you nothing. It becomes available when the guarantee does. The same applies to the human escalation add-on, also priced and also unavailable: a named specialist for escalated cases does not exist yet and we will not pre-sell it. If you need a person on the phone at three in the morning today, buy that from somebody who has one.
Running without the model features
If the inference question is a blocker for your organisation — a public-sector client, a data protection impact assessment that will not accept unverified, a sector rule you cannot argue with — you can run the platform with the model features switched off. The posture assessment, the detection library, log collection, the identity and privileged access modules and the evidence bundle all work without them.
What you lose is the triage layer: alerts arrive and are recorded, and nothing investigates them and writes you a plain-language verdict. For most firms with no security staff that is the wrong trade. But it is your decision to make with the facts in front of you, which is why the inference region is reported as unverified rather than smoothed over.
No tenant data is used to train models, in any configuration. AI conversation history is retained against the same retention window as the rest of your data — see Retention, and how far back you can look.
What to do next
- Check that your home region is actually recorded, rather than assuming it. An empty value passes the residency check silently.
- Read your AI system card before answering any questionnaire question about AI processing, and quote the field rather than paraphrasing it.
- Read /trust for the published version of everything above, which is the page a client can check without an account.
- If a residency requirement is contractual rather than architectural, that is an Enterprise conversation. Start it before you sign the client, not after.