Architecturally, yes — and that seam is the product. Your application calls your country's sovrgn instance; the instance resolves a capability to a concrete provider under your jurisdiction's rules, with failover, residency enforcement, and metering happening at that boundary. Your code never talks to a vendor directly, which is exactly what makes vendors swappable.

The routing decision is in-memory and adds single-digit milliseconds to calls whose inference time is measured in hundreds of milliseconds to seconds. The fast capability exists for latency-sensitive paths, and failover only engages once the primary has already failed — the happy path stays one hop.

From your side: nothing. A retryable upstream failure reroutes to the next provider in the capability's chain within the same inbound call — one request, one billed unit, however many attempts it took. A provider that keeps failing trips a circuit breaker and gets skipped until a probe confirms it's healthy again.

Usage-based — you pay for what you route through it, and commercial terms are set per jurisdiction as each instance opens. We won't invent a pricing table before the terms are real: ask us and we'll tell you exactly where pricing stands for your country.

The protocol speaks plain OpenAI, so anything that can point an OpenAI SDK at a base_url works unchanged. Behind the seam, capabilities resolve across the provider market — OpenAI, Azure, Anthropic and others — ending in the national sovereign-silicon backstop for in-jurisdiction chains.

The opposite is the point. You code against capabilities, not vendors, so you leave the same way you arrived — change one base_url back. Your prompts, your SDK and your code never change either way.

With residency pinned (X-Sovereign-Residency), you get a clean, structured rejection — fail-closed. Your data never silently crosses a border to keep a request alive, and the refusal itself is logged: auditable evidence the control works.