Sovereign architecture · GCC
Sovereign cloud, proven — not promised.
The hero promises cloud you control. This is the architecture behind it: where data lives, who holds the keys, where model calls are allowed to go, and how each Gulf regulator's requirements map to the same governed gates.
01
Where your data lives.
Data residency
Tenant data is pinned to a chosen GCC region on Cloud.Ski — in-country where the jurisdiction requires it, air-gap-capable for sovereign workloads. No silent replication across borders.
Control plane
The control plane runs inside the residency boundary. Orchestration, gates, and the decision loop never reach back to a foreign region to make a call.
Evidence ledger
Every decision, exception, and access event is written to an append-only ledger inside the boundary — reconstructable on demand for a regulator or auditor.
02
The model-call boundary.
Where calls may go
Model endpoints are declared per tenant. A call to an external model is blocked by default and only allowed when the residency policy and the use case explicitly permit it — enforced at the gate, not by convention.
In-region inference
Sovereign workloads run inference inside the boundary on self-hosted or in-region models, so prompts and outputs never leave the jurisdiction.
Logged at the seam
Every model call — internal or external — is logged at the boundary with its purpose, so the data path is inspectable rather than assumed.
03
Encryption & key ownership.
Keys you own
Encryption keys are held by the tenant — bring-your-own-key or hold-your-own-key. Binnovy operates the platform without the ability to read tenant data unilaterally.
In transit & at rest
Data is encrypted in transit and at rest with per-tenant keys; key rotation and revocation are tenant-controlled and logged to the ledger.
Separation of duties
Operators, approvers, and key-holders are distinct roles. No single party can both change a system and unlock its data.
04
When something goes wrong.
One incident path
A single, rehearsed escalation path: detect, contain, notify, and record — logged in the runtime incident register (A-T71) and carried to closure, with the regulator-notification clock mapped per Doc5 jurisdiction group (AIIX-JG) and JP state so deadlines are met, not missed.
Reconstructable timeline
Because every event is on the ledger, the post-incident timeline is reconstructed from evidence, not pieced together from memory.
Owned, not buried
Every incident has a named accountable owner. Exceptions are justified and recorded — never silently absorbed.
05
Jurisdiction crosswalk.
| Jurisdiction | Authority & instrument | How Binnovy maps it |
|---|---|---|
| Saudi Arabia (KSA) | SDAIA · PDPL · NCA ECC | In-Kingdom residency on Cloud.Ski; PDPL data-subject rights honoured; NCA Essential Cybersecurity Controls mapped to governance gates. |
| Qatar | NPC · PDPPL · NCSA | Doha / Qatar Free Zones residency; PDPPL lawful-basis and breach-notice path wired to the incident ledger. |
| United Arab Emirates | UAE PDPL · DESC · ADGM/DIFC | Onshore or ADGM/DIFC residency; DESC and free-zone data rules mapped; cross-border transfer registered. |
| Bahrain | PDPL (Law 30/2018) | In-country or approved-region residency; data-protection guardian role mapped to the accountable owner. |
| Kuwait | CITRA Data Privacy Protection Regulation | Residency and CITRA cloud-classification mapped; processing register reconstructable from the ledger. |
| Oman | PDPL (Royal Decree 6/2022) · Oem CERT | In-country residency option; consent and breach-notification mapped to the same evidenced path. |