Residency
Today, residency is determined by the upstream provider regions in your model catalogue. Named profiles (eu-only, fr-only, etc.) and per-request residency enforcement are on the roadmap.
What works today
Each model mapping in the catalogue points at a specific upstream endpoint (e.g. https://eu-west-3.api.mistral.ai/... or https://eastus.api.cognitive.microsoft.com/...). The data residency of a request is the residency of whichever mapping ultimately served it.
You can read the served region from the response: the upstream model identifier in X-Meridian-Model, plus the provider in X-Meridian-Provider, lets you correlate to your catalogue's region tagging.
Self-curated EU pool
The fastest way to enforce EU residency today is to maintain a chain that lists only EU-region mappings:
{
"models": [
"mistral/large-fr",
"gpt-4o-azure-eu-west"
]
}If every entry is EU-resident, the response is too — there's no silent substitution.
Profile-based routing (roadmap)
Named residency profiles (eu-only, fr-only, health-hds, …) and a request-level residency_profile field are tracked. They are not yet implemented in the router. Until then, build the constraint into your models chain.
The GPAI gating helper (strict_eu_compliance) for filtering models by Article 53 compliance posture is also a roadmap item.