Jurisdiction as a property of the data.

How the data sovereignty solution actually works

At its core, the data-sovereignty solution composes three layers that together make jurisdictional control a property of every file rather than a clause in a contract.

1. Cryptographic isolation

Every file gets a per-file unique data-encryption key. The DEK is wrapped by a User Master Key derived from the user's password (via scrypt) or recovery key — never reaching the server in unwrapped form. On the Sovereign tier, the wrap composes AES Key Wrap (FIPS-published) with ML-KEM-1024 (FIPS 203) for hybrid post-quantum protection. A quantum break against the PQ half alone is insufficient — AES-256 remains.

2. Geometric distribution

The encrypted file is framed into ~5 MB chunks. Each frame is RS(5,2)">Reed-Solomon RS(5,2) encoded into seven shards: five data, two parity. Any five reconstruct the frame; up to two can be lost without data loss. The shards distribute across providers in your chosen jurisdictions — mathematically, fewer than five shards reveal nothing about the original.

3. Jurisdictional policy

Every provider connexion is region-tagged (probed via the provider's API where possible, declared by operator otherwise). At upload time the geo-policy engine enforces your allow-list, block-list, or strict-mode policy. Out-of-policy uploads fail rather than degrade silently. Per-account, per-company, and per-file policies cascade through the effective-policy resolver — every UI setting shows where it came from.

Worked example: PIPEDA-compliant healthcare data

An Ontario hospital configures the geo-policy to allow only Canadian-resident providers: AWS ca-central-1, Azure canadacentral, OVH Beauharnois (Quebec), Backblaze Canadian region, MinIO on-prem, plus two further sovereign endpoints. Every patient record uploaded is encrypted client-side, framed, and scattered across all seven providers within Canada. The SkyeMap shows per-record residency in real time. A compliance audit produces a signed JSON sovereignty report verifiable offline against our published issuer key.

The CLOUD Act doesn't reach this configuration — no provider in the constellation holds enough of any record to read it, and the providers' home jurisdictions don't intersect with US legal process. PHIPA's in-province residency expectations are satisfied per record, not just per region.

Beyond compliance: the strategic shift

Sovereignty as a property of architecture changes what the board can promise. "We can produce evidence of jurisdictional control for every record, dual-signed and externally verifiable" is a categorically different posture than "we have a contractual residency commitment." The first survives audit, regulator inspection, and legal-process challenge. The second produces protracted negotiations.