The case for sovereign hosting is usually argued on principle. The case I want to make is engineering: that where a system runs and who has compelled access to it are properties of the system, not properties of the contract. That perspective shaped the design of Petrichor Labs, and it starts with reading the law the way you'd read a spec.
The CLOUD Act's operative clause is short and most summaries soften it. A provider subject to US jurisdiction must produce data in its possession, custody, or control regardless of where that data is stored. Not "data on US soil." Not "data of US persons." The trigger is jurisdiction over the provider, and jurisdiction follows corporate reality: incorporation, ownership, personnel, assets. Which is why the popular architecture (a US-controlled hyperscaler's eu-west or ca-central region, wrapped in a data-residency addendum) answers a question nobody was asking. The bytes are in Frankfurt or Montreal; the compellable entity is in the United States; the addendum is a promise about storage, and the statute isn't about storage.
Taking that seriously means treating jurisdiction as architecture. The compelled-access surface of a system is the set of entities that can be ordered to act against it, and you design that surface the way you design any other: enumerate it, minimize it, and don't let a convenient managed service quietly expand it. Every dependency is a jurisdiction question wearing a technical costume: the DNS provider, the CDN, the observability vendor, the company that can push firmware to the boxes. A "sovereign" stack with a US-controlled control plane is a US-controlled stack with extra steps.
Why Canada is the boring, useful answer: for Petrichor's customers the requirement was operating outside US CLOUD Act reach without leaving the North American legal and business context they actually work in. A Canadian-incorporated, Canadian-hosted, Canadian-staffed posture does that. Canadian privacy law (PIPEDA and its provincial siblings) is a workable, court-tested regime; the latency to customers is unremarkable; the corporate structure contains no entity a US order can attach to. Nothing about that paragraph is exciting, which is precisely its virtue. Jurisdiction shopping for the most exotic flag is how you end up sovereign on paper and unreachable by your own lawyers.
Vendor selection is where the pitch decks come in, because "sovereign" is now on all of them. The filter that works is the one from the paragraph above, applied without mercy: who controls each layer, not who brands it. Ask who can be compelled, in which courts, to do what, layer by layer: hardware supply, network, control plane, support organization. A vendor that answers slowly is answering.
And the promises we deliberately don't make, because honesty is load-bearing in this market: Petrichor is not beyond the reach of Canadian law, and no one hosting your data anywhere is beyond the reach of the local legal system; that's what jurisdiction means. Mutual legal assistance between governments exists and functions, on its own slower, court-supervised terms. What we claim is narrower and checkable: no entity in our stack can be compelled under the CLOUD Act specifically, because no entity in our stack is subject to US jurisdiction. Customers who need that claim tend to know exactly why they need it.
The trade-offs are real and we accepted them knowingly: a smaller talent pool than a US hub, fewer regional points of presence than a hyperscaler, and constant vigilance about vendor lock-in, because the convenient managed dependency is always one procurement decision away. Sovereignty isn't free. It's just, for some businesses, no longer optional. If it's in your requirements, it belongs in your architecture review, not your contract review.