Sovereign-by-design.

The term has been over-used

Read any cloud-vendor pitch from the last three years and "sovereign" shows up alongside "digital" and "trust." Most uses of the word in marketing material describe a deployment posture: my containers run in a datacenter that happens to be inside the European Union. That's residency, not sovereignty.

Sovereignty in its useful sense covers four properties simultaneously. Jurisdiction — which legal system can compel disclosure or modification of the data? Operational control — who has root access to the production infrastructure? Contractual recourse — when the relationship ends or the vendor changes posture, what protects the customer? Architectural reversibility — can the data move out as cleanly as it moved in?

Sovereign-by-design as a constraint

Sovereign-by-design means treating each of those four as a hard architectural constraint, not a feature shipped on top. It rules out designs even when those designs would be technically simpler.

Cross-region replication is the cleanest example. Most cloud-native CMS architectures replicate writes across two or three regions for disaster recovery; if Frankfurt goes down, requests fail over to Dublin or Paris. That's good for the customer's SLA. It's incompatible with sovereign-by-design. When a Belgian bank's customer-data row sits in Dublin during a 90-second failover, the Belgian supervisor's answer to "was the data in Belgium? " becomes "mostly." Mostly is not the right answer.

So we don't do cross-region replication. Each region is a standalone Postgres + Object Storage + queue stack. If Brussels has an outage, the Brussels workspaces are offline until Brussels recovers. The sovereign-by-design architecture chooses regulator-defensibility over uptime in that exact scenario, and it does so contractually rather than on a best-effort basis.

What this looks like in code

Day-to-day, sovereign-by-design is a series of small decisions that together remove ambiguity. The audit chain is the spine of the platform rather than a plugin — every workspace ships with one, every action lands in it, every chain head is signed by the regional KMS. Per-country residency is a deployment topology, not a region label — eu-bru-1 is a different stack from eu-fra-1, with different KMS keys, different workers, different backups.

The exit plan is a contractual right rather than a vendor-discretionary favour. Schemas export as TypeScript that compile against @estokad/schema. Content exports as JSON in a stable IR documented publicly. Assets export as a tar archive with their original filenames and metadata. The audit log exports as JSONL with the Merkle roots required to re-verify off-platform.

Sub-processor management surfaces in the Studio, not in a Confluence page. Adding a sub-processor requires 30 days' notice to every workspace; the customer can object on reasonable grounds. The register is read-only on every customer's DORA evidence pack.

The trade-offs

Sovereign-by-design isn't cost-free. Three trade-offs we accept:

We can't use US-headquartered SaaS vendors for anything that touches customer content. Sentry GmbH on its EU instance is fine; Sentry on its US instance isn't. Stripe Payments Europe Ltd. (Ireland) is fine; Stripe's US-routed processing isn't. The sub-processor list reads narrower than most B2B SaaS companies — that's deliberate.

We don't do cross-region replication by default, so a regional outage is a regional outage. Customers on the Premium SLA module get 99.99% per region — but the per-region commitment doesn't turn into a global one through automatic failover. Customers who want the trade-off the other way can subscribe to the EU failover backup module (€299/mo) for nightly encrypted copies to a designated secondary EU country. It's opt-in by design and contractually acknowledged: the data leaves the primary region for backup purposes only, and the secondary stays cold until the customer promotes it. Banks and insurance carriers we've briefed prefer this shape over automatic failover — they want the disaster-recovery option without losing the "data was here" answer for the supervisor.

Per-customer dedicated infrastructure (the Sovereign tier) is more expensive than shared multi-tenancy. Customers paying for it know why; customers who don't need it don't pay for it. The architecture supports both topologies; the pricing reflects the cost.

Why the brand

The brand metaphor is the estacade — the French / Dutch breakwater. A structure that holds, that you can build on, that protects what's behind it. The wordmark is estøkad — Latin small letter o with stroke as the brand fingerprint. The visual identity uses graphite surfaces with cyan as the only signal colour. The voice is short, declarative, factual.

The brand is engineered to match the architecture. A breakwater is sovereign-by- design — it doesn't ask for sovereignty, it has it by what it does. The wordmark uses a Nordic letter to anchor the European identity without leaning on a specific country. The graphite palette signals durability rather than excitement. The voice avoids the marketing puffery (no "robust," "seamless," or "world-class") that softens the message.

What comes after

Sovereign-by-design is a posture, not a finish line. Q3 2026 brings draft / published data separation — today the approval workflow gates publish but PATCH still hits the production-served data immediately. Q4 brings per-asset ACL control for customers needing private assets. H1 2027 brings SOC 2 Type II and ISO 27001 stage 1.

Each of those is a step toward making the sovereignty observable from the customer's side. Read the rest at /roadmap and the trust posture at /trust.