Residency Pinning Across Dubai and Johannesburg
Phil Hofsteder · · 10 min read

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.


