Vendor security pages blur two claims that differ in kind, not degree. Data residency is a promise about where servers sit. Data sovereignty is a property of architecture — whether the data can leave your control at all. A buyer who conflates them signs contracts that feel like boundaries and are not.

Why the distinction decides outcomes

Residency is enforced by contract and configuration, which means it is enforced by people — the vendor's and yours. Servers can be in Singapore while a support engineer in another region reads a log that contains your prompt. Sovereignty, done architecturally, removes the possibility: matter processing that runs on the device has no transmission to mis-configure, no log to over-share, no region to guess. That is why our security brief publishes a capture-the-traffic test instead of a map of server locations — the evidence you want is a packet capture, not a promise about geography.

The questions that separate them

“Where is data stored?” — a residency question. Worth asking; insufficient alone.
“What leaves my control during a task?” — the sovereignty question. Demand the list.
“Can I verify the answer myself?” — the question that separates the two. If verification means trusting the vendor's auditor, it is residency. If verification means running a test on your own machine, it is architecture.

A region is a promise. A boundary is a fact. Buy facts.

None of this makes residency worthless — jurisdiction still governs what happens to data that does exist on someone's servers, and our own jurisdiction disclosures live in the privacy notice. It makes residency the wrong *only* answer. The strong position is both: an architecture that minimises what exists outside your control, and honest paperwork for what remains.