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

We now operate pinning for three production regions: ae-dubai, hk, and za-jnb. That is not three products. It is one policy object with three legal places a prompt is allowed to exist during inference.
Headquarters remains Dubai. Hong Kong and Johannesburg are operating offices. 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, three 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" Hong Kong with a nearby endpoint.
Failover is intra-pin. A Claude 503 in ae-dubai can hop to another Dubai-mapped model. It cannot hop to hk to ride out the incident unless the project policy explicitly allows multi-region, which production legal projects do not.
{
"residency": {
"region": "za-jnb",
"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, PDPL, PDPO
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 hk, 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.
Three regions is operationally harder than one. It is still cheaper than explaining an off-region prompt in three different exam rooms.

Phil Hofsteder
CTO
Phil Hofsteder is Chief Technology Officer of Eridian. He holds the accountability architecture of the operating system: policy enforced at invocation, dual control on high-risk actions, and an audit trail that survives examination. His work is the control discipline that lets a financial institution put intelligence into production without surrendering the decision to an unreviewed model.


