Data Sovereignty in the EU

Why Aura is built by a Swiss company, how GDPR flows through a self-hosted engine, and the Mothership placement strategy for keeping code inside the jurisdiction you configure.

Overview

Naridon, Inc. is headquartered in Zürich, Switzerland. Switzerland is not a member of the European Union, but it sits inside the Single European Market through bilateral agreements, operates under an adequacy decision with the EU for personal data transfers, and has its own strong data protection regime under the revised Federal Act on Data Protection (revFADP) that entered into force in September 2023.

This geography is relevant to enterprise customers for two reasons. First, Swiss corporate law places meaningful constraints on what a foreign government can compel Naridon to produce — no CLOUD Act exposure, no ex parte gag orders, no national security letters. Second, Naridon can serve EU customers without the Transfer Impact Assessment machinery that US-based vendors must carry.

But the deeper point is that none of this matters when you self-host Aura, because Naridon never sees your code at all. Data sovereignty in Aura is enforced at the infrastructure layer, by the customer, on infrastructure the customer controls. Our geography is a backstop, not a primary control.

This page covers three topics: why Naridon chose Zürich, how GDPR applies when you deploy Aura yourself, and the concrete Mothership placement strategy we recommend for EU data sovereignty.

Why Zürich

Naridon is a Swiss Aktiengesellschaft (AG) registered in the Canton of Zürich. The choice of jurisdiction was made deliberately for four reasons:

Legal insulation. Switzerland is not subject to the US CLOUD Act, the UK Investigatory Powers Act, or Chinese cybersecurity law. Compelled disclosure of customer-related records requires a Swiss court order following Swiss procedure, which includes the possibility of notifying the customer.
Adequacy with the EU. The European Commission's adequacy decision for Switzerland (most recently reaffirmed) means personal data can flow between the EU/EEA and Switzerland without Standard Contractual Clauses and without Transfer Impact Assessments. This simplifies contracts for our EU customers materially.
Strong domestic protection. The revFADP closely parallels the GDPR, adds stricter rules for high-risk profiling, and includes criminal sanctions for specific violations. It is a regime we respect and are comfortable operating under.
Engineering talent. Zürich's federal institute of technology (ETH) and its spillover ecosystem produce the kind of systems engineers Aura requires.

When you self-host Aura inside the EU (or EEA, or UK, or Switzerland), the GDPR posture is unusually clean: Naridon is not a processor of your data. The engine runs on your infrastructure. The intent log, the AST fragments, and the peer traffic never leave your perimeter. Naridon provides software; Naridon does not touch data.

This simplifies three things that are painful for most developer-tooling vendors:

No Data Processing Agreement is required for the use of the software itself. DPAs are for processors. Naridon is not one under self-hosting.
No Transfer Impact Assessment is required. No transfer takes place.
No Article 30 record of processing activity needs to list Aura as a processing operation, because there is no processing by a third party.

If you engage Naridon for professional services — migration engineering, on-site training, a hosted evaluation — then we do become a processor for the limited scope of that engagement, and a standard EU-compliant DPA applies. The engagement is documented and narrow; it ends when the statement of work ends.

What about PII in code?

Source code is not typically personal data under GDPR. But it sometimes contains personal data — an email address in a test fixture, a name in a log message, a comment referencing a specific user. Aura treats these with care:

Secret detection runs on every commit pre-hook and can be configured to block commits containing email addresses, names, or other PII-suggestive patterns, not just credentials.
Fragment storage is encrypted at rest with AES-256-GCM; keys are held in the customer's KMS.
Right-to-erasure requests under GDPR Article 17 are served by the customer, not by Naridon. The engine supports cryptographic redaction of intent log records (see Compliance & Audit) so that a record's payload can be made unreadable without breaking the hash chain.

Mothership placement strategy for EU sovereignty

For customers who have contractual or regulatory requirements that engineering artifacts remain inside a specific jurisdiction, the recommended shape is one Mothership per jurisdiction, with federated allow-lists between them.

Single-jurisdiction shape

Simplest case: all engineering is inside the EU. One Mothership, deployed in an EU region, Postgres in the same region, fragment store in the same region, all peer traffic routed through the region.

             +-----------------------------+
             |     EU-Central (Zürich)     |
             |                             |
             |   Mothership (aura-eu)      |
             |   Postgres (eu-central)     |
             |   Fragments (S3 eu-central) |
             +-----------------------------+
                          ^
                          |
              peers in EU, UK, CH only

Enforce this at the network layer: reject peer connections originating from IP ranges outside your allowed set. The Mothership also supports identity-based geofencing:

[sovereignty]
allowed_peer_countries = ["CH", "DE", "FR", "NL", "IE", "AT", "IT", "ES"]
enforce_mode = "reject"

Multi-jurisdiction shape

Global engineering organizations with EU sovereignty requirements for specific repositories run one Mothership per jurisdiction and federate selectively. An EU repository's primary Mothership is in the EU; a US repository's primary Mothership is in a US region; they can share open-source libraries through explicit federation rules.

    +-------------------+       federation (opt-in per repo)
    |   EU Mothership   | <---------------------+
    |   (Zürich)        |                       |
    +-------------------+                       v
                                  +-----------------------+
                                  |   US Mothership       |
                                  |   (Virginia)          |
                                  +-----------------------+

Federation is repository-scoped and opt-in: only repositories explicitly allowed in the federation config replicate across borders. The default is no replication. An EU customer can pin specific internal repositories to never leave EU Mothership, while shared open-source libraries replicate freely.

[federation]
region = "eu-central"
peers = [
  { region = "us-east", endpoint = "https://aura-us.example.com",
    allow  = ["monorepo/public-libs/**"],
    deny   = ["monorepo/billing/**", "monorepo/customer-data/**"] },
]

Encryption scope

Fragments in Aura are encrypted at rest with keys held in the customer's KMS. For EU-sovereign deployments we recommend a KMS instance geographically inside the same jurisdiction (for example, AWS KMS in eu-central-1 or eu-central-2, Azure Key Vault in a Swiss region, or a self-hosted HSM).

[fragment_store]
backend = "s3"
bucket = "aura-fragments-eu"
region = "eu-central-2"
kms_key_arn = "arn:aws:kms:eu-central-2:…:key/…"

The Naridon commitment

In a commercial agreement, Naridon makes the following guarantees in writing:

The software you receive is built in the European Economic Area or Switzerland.
The software does not phone home. We do not receive telemetry, metrics, or any network-level heartbeat from your deployment unless you explicitly enable it.
Professional-services engagements in the EU are staffed by personnel located in the EEA or Switzerland unless you agree otherwise in writing.
Support interactions are handled through channels that do not require sharing your source code. We debug against anonymized reproducers or redacted traces.
Any request from any government for data about your use of Aura is fought to the extent permitted by Swiss law, and you are notified to the extent permitted.

These are contractual commitments. The architectural commitments above — that self-hosted Aura cannot phone home, that fragments never leave your KMS boundary — are stronger because they do not rely on us keeping a promise. They are properties of the software.

For customers using Aura to manage the engineering of systems that themselves process PII, Aura supports the engineering side of subject-rights responses:

Article 15 (access). The intent log can be queried by author identity: aura audit by-author user:subject@example.com.
Article 16 (rectification). Code changes are made through ordinary commits and logged normally.
Article 17 (erasure). Cryptographic redaction removes payload content while preserving chain integrity.
Article 20 (portability). The evidence export format (NDJSON + detached signatures) is portable and non-proprietary.

Swiss-specific considerations

Swiss customers have a small number of additional options:

Naridon maintains a primary operating entity in Zürich. Contracts can be governed by Swiss law with the Zürich commercial courts as the forum.
Swiss-hosted professional services engagements can be staffed entirely by personnel resident in Switzerland, if required by the customer's own compliance posture (for example, FINMA-regulated entities).
The intent log can be timestamped against a Swiss-qualified RFC 3161 time-stamp authority for compatibility with Swiss electronic signature law (ZertES).

Brexit and the United Kingdom

UK customers are generally served through the same shape as EU customers, with two notes. The UK operates under its own GDPR ("UK GDPR") post-Brexit, and the UK adequacy decision with Switzerland remains in force. A UK-resident Mothership in a UK region satisfies UK GDPR sovereignty requirements, and federation rules can be written to allow or deny replication to EU peers as the customer's own data map requires.