Data residency
Sovereignty is only as strong as the paths that could violate it. System9 makes data residency a first-class, live-resolved policy on the work boundary itself, not a deployment-time label and not a per-organization region setting. A workspace or clean room carries a residency constraint, and every placement and egress decision is re-resolved against it, so failover never crosses the pinned boundary and an impossible constraint refuses rather than quietly degrading to the wrong jurisdiction.
Where the constraint lives, and what it pins
Residency is expressed as a cell selector persisted on the scope, a workspace's residency selector, or a clean room's region constraint, and it resolves against the physical topology the whole platform shares. The boundary can be pinned at any level of the hierarchy (region, zone, or rack) plus the orthogonal cloud-provider dimension. Because the constraint sits on the scope, it travels with the workspace or clean room wherever that portable environment goes.
The three behaviors that make it a sovereignty control
Figure A16: residency enforcement. Green cells are in-boundary and eligible; failover from the active cell stays within Region A. The amber cell is healthy but out of the boundary, so it is held apart and never chosen (the crossed edge). When no in-boundary cell can satisfy a required constraint, the decision refuses (red) rather than placing work in another jurisdiction. This is the shipped mechanism; it is re-resolved live on every placement and egress decision.
Table equivalent
| Situation | What residency does | Outcome |
|---|---|---|
| Normal placement or egress | Resolve the pinned selector against live fabric; choose an in-boundary cell | Placed on an in-boundary cell (verified) |
| The active cell fails | Fail over to another cell within the same pinned level | Continuity, boundary preserved (verified) |
| The only healthy cell is out of the boundary | Do not choose it; the boundary holds | Out-of-boundary cell held apart (refusal) |
| A required constraint that no live cell can satisfy | Refuse the operation | Deny: never degrades to the wrong jurisdiction |
1. Pinned at a level: region, zone, or rack, plus cloud
The constraint is not "one region or nothing." It pins to whatever level of the topology the deployment needs, a region for a jurisdiction, a zone for an availability boundary, a rack for a failure domain, and independently constrains the cloud provider, which is an orthogonal dimension rather than a level in the tree. A workspace can be pinned to "this region, on this provider" without conflating the two.
2. Failover stays within the pinned boundary
Because residency is re-resolved on every placement and egress decision, a cell failure triggers failover within the pinned level. The system does not reach for a healthy cell in a neighboring region to keep a workspace up; keeping the data in-jurisdiction outranks reaching for the nearest spare. Resilience is bounded by the residency constraint, not the other way around.
3. An unsatisfiable required constraint refuses
If a residency constraint is required and no live cell can satisfy it, the decision refuses rather than silently placing work somewhere that violates it. A refusal is a recorded, honest outcome; a quiet degradation to the wrong jurisdiction would be a sovereignty breach that looked like success. This is the same discipline the platform applies wherever a control cannot be honored, it refuses at the boundary rather than fabricating a pass.
Re-resolved live, not decided once
The load-bearing property is that residency is re-resolved against live fabric membership on every placement and egress decision, not evaluated once at provisioning. Cells join and leave; a fleet scales in and out. A constraint checked only at setup would drift the moment the fabric changed. Checking it live means the answer to "may this run here, and may this leave to there" reflects the estate as it actually is at the moment of the decision.
In the console
Residency is set where the boundary lives: as a Residency tab in the
workspace and clean-room console, at /workspace/:id/residency and
/cleanroom/:roomId/residency (labelled "Residency, where data & compute
live; failover stays in-boundary"). It is gated on the membership capability
workspaces.console.read, deliberately an owner's right on the scope, not an
operator capability. (A separate, operator-scoped resolver view exists under the
topology admin surface, gated on topology.admin.read.)
The tab shows the current policy in plain language, the pinned level
(region / zone / rack / cloud_provider) and value, with the
"failover stays within the boundary" assurance, an editor (a level picker; clearing
the level and saving removes the policy so work resolves fabric-wide), and a
"Where it resolves now" card that shows live cell resolution inside the
boundary. See Administration & Configuration for how
this fits the operator surfaces.
The Residency tab is backed end to end. The node's admin surface serves the endpoints it calls, reading and writing the residency policy and resolving it, for a workspace and for a clean room alike. Where a cell does not serve them the tab degrades rather than erroring, showing a banner that residency management may not be enabled there. One thing to know while editing: the "where it resolves now" preview reflects the saved policy, not the unsaved draft in front of you, so save before reading the preview as the answer.
Related topics
- Deployment topology, the region → zone → rack → cell hierarchy, and the orthogonal cloud dimension, that residency resolves against.
- The two work boundaries, the workspace and clean room the residency selector is pinned on.
- Administration & Configuration, the operator surfaces and how config deploys.
- Replication, DR and federation, how replication scope is likewise resolved from the same topology.