Pillar 1 / Jurisdiction-aware inference router
Dynamic, latency-optimized jurisdiction-aware AI routing.
Every request resolves to an endpoint inside the legal zone its policy allows, chosen by tenant domicile, user location or data class. Failover stays inside that zone or does not happen at all.
This is the same resolution order the gateway runs. Pick a strategy, set the tenant's home country, where the end user is, and what the classifier found in the prompt. The panel shows the zone, the endpoint pool and the decision trace written to the log.
ep_vllm_hds_par
Customer vLLM on HDS-certified hosting / par-hds-1 / Paris
French health data: HDS-certified hosting required by the French Public Health Code
Single endpoint pool: if it is down the request fails closed with HTTP 503.
01 strategy = data_sensitivity 02 tenant.domicile = FR -> zone EU 03 classifier.data_class = health 04 pool = eu-fr-hds 05 resolved = ep_vllm_hds_par (par-hds-1)
| Strategy | Signal it reads | Best for | Precedence | Worked example |
|---|---|---|---|---|
| Tenant domicile | The tenant record: country of the customer account that owns the data, set at onboarding and carried in X-YTT-Tenant. | B2B SaaS where each customer contract fixes a hosting region, and the controller is your customer. | Default. Wins unless a pack says otherwise. | A Dutch insurer's tenant always resolves to the EU zone, even when an adjuster logs in from a hotel in New York. |
| Geo-IP & locale | Client IP geolocation at the edge POP, the Accept-Language locale, and an optional X-YTT-User-Region hint from your app. | Consumer apps and shared tenants where the data subject's location is the deciding fact. | Used when the pack enables it; falls back to domicile when the country has no data plane. | A shopping assistant keeps a user in Lyon on EU endpoints and a user in Leeds on UK endpoints within one tenant. |
| Data sensitivity | The in-path classifier's data class (general, health, financial, government ID) plus any class your app asserts. | Mixed workloads where one assistant handles both routine questions and special category data. | Narrows the zone chosen by domicile or geo-IP to a stricter pool. Never widens it. | French health data goes to an HDS-certified cluster; banking data goes only to endpoints in the tenant's DORA register. |
Strategies compose in one direction only: domicile or geo-IP picks the zone, sensitivity narrows the pool inside it. No rule can widen the set of allowed endpoints, which is what lets a DPO sign off the pack once instead of reviewing every application that uses it.
A German tenant under eu-gdpr-strict has three EU endpoints in priority order. Take them down one at a time. Traffic moves from Frankfurt to Amsterdam, then to Dublin. When the last EU endpoint goes, the gateway refuses the request with a 503 instead of sending it to Virginia.
Mark an endpoint down
HTTP/2 200 x-ytt-region: germanywestcentral x-ytt-endpoint: ep_azure_gwc x-ytt-failover: none x-ytt-proof-signature: eyJhbGciOiJFZERTQSIs...
- < 8 ms
- p99 added gateway latency, policy evaluation plus receipt minting
- YTT Secunet production telemetry, 2026
- 80 to 100 ms
- typical round trip between Frankfurt and US East (Northern Virginia) before any model compute
- Speed-of-light fibre path, public cloud inter-region latency measurements
- 6 zones
- regional data planes: EU, UK, CH, GCC, APAC and US, each with its own endpoint pools
- YTT Secunet deployment, 2026
Routing profiles live in Git next to your policy packs and are applied through the API or Terraform provider. The gateway reloads them without a restart, and every receipt records the profile and pack version that produced the decision.
Ranking happens last. Health checks run every five seconds per endpoint from each regional data plane; among healthy endpoints the router prefers the lowest rolling median latency, then cost. Because ranking only sees in-zone candidates, there is no configuration mistake in this file that can route an EU request out of the EU: the zone list comes from the policy pack, not from here.
The model name in your request is a logical alias such as mistral-large. Each pool maps the alias to a concrete deployment, so failover keeps the same model family where the next endpoint offers it and returns a clear error where it does not.
apiVersion: yttsecunet.com/v1
kind: RoutingProfile
metadata:
name: claims-assistant
spec:
strategy: data_sensitivity
zoneFrom: tenant_domicile
geoOverride:
enabled: true
header: X-YTT-User-Region
pools:
eu-general: [ep_azure_gwc, ep_scw_par]
eu-health: [ep_vllm_fra_health, ep_scw_ams_health]
eu-finance: [ep_stackit_eu01, ep_azure_gwc]
failover:
scope: same_zone
onExhausted: fail_closed # HTTP 503, never cross-zone
ranking: [health, p50_latency, cost]Customer engineering note
“Our Swiss clients resolve to Zurich and our EU clients to Frankfurt with under 8 ms added at p99. In a year of regional incidents, failover has never once left the jurisdiction.”
What happens if no endpoint in the jurisdiction is healthy?
The request fails closed. The gateway returns HTTP 503 with error type no_in_jurisdiction_capacity and a Retry-After header, and it does not forward the prompt anywhere. Out-of-zone endpoints are removed from the candidate list before health is considered, so they cannot be selected by a failover path.
How is the user's location determined for geo-IP routing?
At the edge POP that terminates TLS, from the client IP against a commercial geolocation database, combined with the request locale. If your backend calls YTT Secunet on behalf of users, pass the user's region in the X-YTT-User-Region header, because the IP we see is your server's.
Can one tenant use different strategies for different applications?
Yes. The strategy is part of the policy pack, and the pack is chosen per request by X-YTT-Policy. A support assistant can use domicile routing while a clinical summariser in the same tenant uses data sensitivity routing with a stricter pack.
Does the router ever send traffic to a cheaper or faster out-of-zone endpoint?
No. Latency and cost only rank endpoints that are already inside the allowed zone and pool. A US endpoint that is 30 ms faster for a given request is never a candidate under an EU pack.
Where does the 8 ms figure come from?
It is YTT Secunet's own production telemetry for 2026: p99 added latency across policy evaluation, PII detection and receipt minting, measured at the gateway. Network time to the model endpoint and model compute are separate and depend on the provider.
Sovereign route ready
Stop risking 4% global turnover GDPR fines on AI inference.
Deploy sovereign, cryptographically proven AI routing in 15 minutes.