Skip to main content
You declared your workspace residency as eu, generated a SOC 2 report under it, then later switched the workspace to us. What happens to the old eu report? OrcaRouter withholds it. A signed compliance report is region-stamped at generation time, and it is only served while your workspace’s current declared region still matches that stamp. A cross-region read is denied — the artifact is never handed over under a residency claim it can no longer satisfy. This page covers that one rule: the read restriction. For declaring and changing the region itself, see Data residency; for what’s inside the artifact, see Signed report.

​
1. Why a data residency report restriction exists

A signed report carries a residency claim. When you generate it under eu, the report’s disclosure states the evidence artifact is stamped to the European Union and stored region-partitioned. If the gateway then served that same artifact after you moved the workspace to us, the served copy would be making a residency claim it no longer holds.
The restriction is about the evidence artifact, not your inference traffic. Declaring a region stamps and locality-partitions the compliance reports the gateway produces. It is an honest disclosure + artifact-locality control — it does not geo-pin which region an upstream model provider processes your prompts in. Upstream providers (subprocessors) process request data in their own regions, and the report discloses exactly that.
So instead of silently serving a now-mismatched artifact, OrcaRouter withholds it and tells you to regenerate under the current region.

​
2. The matching rule

The rule is a single comparison at download time, between the region stamped on the report and your workspace’s current declared region.
The artifact is returned normally, in whichever format (PDF, JSON, or CSV) it was generated under.
The download is denied. The artifact is never served under a residency it can’t satisfy. You regenerate the report under the current region to get a fresh, correctly-stamped artifact.
A report generated while the workspace had no residency declared carries no residency claim, so there’s nothing to mismatch — it is served under any region. Declaring a region only stamps reports generated after the declaration.
The declarable regions are the closed set us, eu, uk, ap, cn, and global (plus the unset / no-restriction state).

​
3. One concrete walkthrough

A workspace that switched regions mid-quarter:
1

Declare eu and generate

As a workspace Admin, set residency to eu and generate the quarter’s SOC 2 report. The artifact is stamped eu and stored under the EU partition.
2

Switch the workspace to us

Later, an Admin changes the declared region to us. The change is recorded in the workspace audit trail.
3

Try to download the old eu report

The download is withheld with:
this report's data-residency region no longer matches the workspace — regenerate it
4

Regenerate under us

Generate a fresh report; it is stamped us and downloads normally. The old eu artifact stays on record under its region but is not served while the workspace is declared us.
If you only need to read an old report after a region switch, switch the declared region back to the one the report was stamped under (Admin), download, then switch back. The stamp on the artifact never changes — the gate is purely the current-vs-stamped comparison.

​
4. Who can change what

Reading the residency setting and browsing reports is open to every workspace member. The actions that move the region — and therefore what gets withheld — are Admin-only and server-gated.
ActionRouteRole
Read declared regionGET /api/compliance/residencyMember
Change declared regionPUT /api/compliance/residencyAdmin
Download a report (region-checked)GET /api/compliance/reports/:id/downloadAdmin
All of these run against the /api/compliance/* routes under your console session. No relay (sk-orca-…) key is involved — residency is a compliance-surface setting, not something a /v1/* request carries.
Changing the declared region is consequential: it immediately withholds every previously-generated report stamped under a different region. Coordinate region changes with whoever is mid-audit, and regenerate the reports they need under the new region.
A read-only auditor share link serves the same region-stamped artifact it was minted for. The link does not bypass the residency stamp on the underlying report — it is a tokenized view of an artifact that already carries its region claim. Mint share links after you’ve settled the workspace’s declared region, so an auditor isn’t handed a link to a report you later have to regenerate.

​
6. Where this fits

The cross-region restriction is the read-side guarantee that makes a region-stamped report trustworthy. The pieces around it:

Data residency

Declare and change the region your reports are stamped and stored under.

Signed report

Generate the Ed25519-signed, region-stamped evidence pack itself.

Export evidence

Auditor share links and the CSV / JSON / PDF formats.

Plan gating

Which compliance actions are free vs. paid, and who can run them.
For the boundary between what the gateway attests and what stays yours — including residency as a disclosure control rather than inference geo-pinning — see Shared responsibility.