All services operational
Eridian
COMPLIANCE

Residency Pinning Across Dubai and Johannesburg

Phil Hofsteder · · 10 min read

Residency Pinning Across Dubai and Johannesburg

We now operate pinning for two production regions: me-central-1 and af-south-1, with ap-southeast-1 published as a generic Asia-Pacific pin on the order form. That is not two products. It is one policy object with the legal places a prompt is allowed to exist during inference.

Headquarters remains Dubai. Johannesburg is an operating office. The pin is the customer's, not the office's. A Johannesburg engineer on-call does not move a Dubai legal prompt to South Africa because they are awake.

One rule, two maps

Each region has a provider map, a cache partition, a log partition, and a list of models that actually terminate in that region. If the map is incomplete, the model is not eligible. We do not "approximate" a region with a nearby endpoint.

Failover is intra-pin. A Claude 503 in me-central-1 can hop to another Dubai-mapped model. It cannot hop to af-south-1 to ride out the incident unless the project policy explicitly allows multi-region, which production legal projects do not.

{
  "residency": {
    "region": "af-south-1",
    "pinning": "strict",
    "failover": "intra_region",
    "cache_scope": "region_project"
  }
}

Cache and evals follow the pin

A gold set used for a Johannesburg POPIA-tagged workflow is not served from the Dubai eval store. Scorecards carry a region. Promoting a model pin requires the scorecard for that region, even if the English task looks identical.

This annoyed engineering for a quarter. Then a playbook section differed between the Dubai pack and the South Africa pack on cross-border disclosure. The "identical" task was not identical. The split earned its keep.

POPIA and PDPL

We do not flatten these into a generic "privacy mode." Entity types, retention clocks, and transfer flags are unioned or intersected per the tighter-control rule we described in the PDPL/GDPR note. South Africa projects default to personal_data: true when the desk is legal or ops. Sandbox can turn that off. Production cannot without dual control and a named DPO-equivalent on the ticket.

What customers still get wrong

They copy a Dubai project, change the pin to ap-southeast-1, and assume the routing chain is still valid. It often is not. We now block copy when the destination region's chain would include an unmapped model. The error is residency_chain_incomplete. Fix the chain, then copy.

Two regions is operationally harder than one. It is still cheaper than explaining an off-region prompt in two different exam rooms.

Related Posts