Trust

Data residency

Your data lives, moves and is processed inside the jurisdiction you designate. Residency is enforced by the platform, not promised by a policy.

The boundary is technical.

Everything that touches your data (storage, retrieval, inference, memory) runs inside one designated boundary.

Designated jurisdiction

chosen per engagement

Storage: Documents, records and indexes at rest, encrypted in-region.
Retrieval: Grounded search runs where the sources live. Nothing is copied out to answer a question.
Inference: Model routing respects residency first: tasks reach only models eligible to run in-boundary.
Memory & logs: Organisational memory and the audit trail stay under the same rules as the data they describe.

no cross-border processing · no shadow copies · no exceptions for convenience

Four commitments, enforced in the platform and visible in the audit trail.

01
You choose the jurisdiction
The boundary is set per engagement, a country, a region or your own facilities, and recorded in the contract.
02
Routing respects it first
Residency and data classification narrow the model field before fit, cost or speed are considered. Ineligible models are never reached.
03
Classification travels with data
Each data class carries its own handling rules: masking before inference, retention, and where it may be processed.
04
Provable, not asserted
The audit log records where every retrieval and inference ran. Residency can be verified from the record, per task.

Chosen per engagement

Managed cloud: Run on vetted in-region infrastructure inside your designated boundary.
Regulation-ready: Configurations designed to meet GDPR, PDPL and sector rules: residency, masking and retention per framework.
Sovereign & air-gapped: Fully isolated deployment on your infrastructure, with local models, for regulated and government environments.