Where a model processes prompts, and who made it

A model node (nodeType:LanguageModel) carries two marks, and they answer two different questions:

The two marks are independent. GLM 5.3 is made in China and can be processed in the EU; Claude is made in the US and is processed wherever Anthropic or Azure route it. Both are open string-constant vocabularies (policy open-vocabulary-string-constants): DataResidency and ModelOrigin in MeshWeaver.AI.

The rule: only Eu is EU

DataResidency.IsEu is true for Eu and nothing else. Only an unset or blank mark becomes Unknown. Any other value stays as authored, because the vocabulary is open: CH stays CH, and so does a typo. None of them ever counts as EU, and each satisfies only a requirement that names exactly that value. DataResidency.Satisfies(actual, required) never admits Unknown, even when the requirement itself names Unknown.

The mark describes the route, not the model:

Where the marks come from

The model node's own dataResidency is the only value any consumer reads. The picker badge, the provider page, tier resolution and the round's refusal all read it, so they cannot disagree. The emitters seed it with ModelProvenance.Seed, and a value authored on the node always wins:

1. Declared by the deployment. {Section}:DataResidency and {Section}:DataRetention apply to every model of that catalog section, e.g. AzureFoundry__DataResidency=Eu for a DataZone-only account.
2. Implied by the endpoint (DataResidency.FromEndpoint), for the hosts in the table above.
3. Otherwise unset, which reads Unknown.

The maker and its country are inferred from the id. The org slug is tried first (z-ai/, moonshotai/, anthropic/), then the family token (Kimi-K2.6, claude-haiku-4-5, DeepSeek-V4-Flash). An id nothing recognises stays Unknown; the platform never guesses.

A ModelProvider node carries dataResidency / dataRetention too. This is a seed for the models the provider creates, never a verdict. The built-in provider node is create-if-absent, so a mark added to its configuration later reaches its model children, which are synced, and not the provider node itself.

Where the marks show

• The model picker (/model in the composer). Every model row carries two badges, 🇪🇺/🌍/❔ and the maker's flag. The tooltip and accessible name are in the viewer's language: "Processed in the EU only · retention: ZDR", "Z.ai — model maker based in China".
• The provider page (Settings → Providers → a provider). Its model grid has Processing and Origin columns.
• All text comes from [Description]/[Translation] declarations on the constants and on ModelProvenanceText, in English and German.

Requiring EU: fail closed

A requirement is set in one of two places. When both are set, both apply.

The refusal happens before any prompt leaves the process. The user sees a localized sentence naming the model, its mark and who requires EU, and the refusal is logged at Warning. An explicit pick of a non-admitted model is healed onto an admitted one, the same way an unusable pick is healed. When none is admitted, the round is refused; it never falls back to a Global model. A bare model id that matches several catalog entries with different marks reads Unknown: which entry would serve it cannot be promised.

"No endpoint" never means "a US default". Under the instance switch, every request is also checked at the point where it is built, by ChatClientCredentialResolver.InstanceRouteRefusal (called by the OpenAI, Azure OpenAI, Anthropic and Azure Foundry factories and by the image generator). A request with no endpoint is refused, because the OpenAI SDK would fall back to api.openai.com and the image generator would use the same host. A request whose endpoint is a known global host is refused too. An Azure host passes this check: the model node's own mark was already checked. Listing a provider's models (ProviderModelLister, against the maker's API) sends no prompts and is not gated.

What the instance switch does NOT cover:

• Per-user bring-your-own-key models ({user}/_Memex/…, {user}/_Provider/…, ModelProvenance.IsPersonal) stay allowed and visible. They are still marked: a BYOK model is never seeded Eu. It reads Global for a known global host and Unknown otherwise, because the person's account settings are theirs and not established here.
• CLI harnesses (Claude Code, Copilot, Codex) run on the person's own subscription, straight to Anthropic, GitHub and OpenAI. The maintainer decided they stay. They count like BYOK: allowed, and marked NOT-EU (Global) with origin US.
• An agent requirement applies to every model, BYOK included.

Code review (policy code-review-eu-only): the reviewer's model is bound to Provider/OpenRouterEU (eu.openrouter.ai) with a pinned providerRouting region, which the review-binding change owns (MeshWeaver.Plugins#2446). Its DataResidencies.EU value "EU" reads as Eu here, because the comparison is case-insensitive. The agent-level marker requiredDataResidency: Eu is not set on Governance/Agent/reviewer yet, and that is deliberate. That agent also reviews every governed activity, and no model on the control instance is marked Eu today. Declaring the requirement now would refuse every review, including the approvals the elimination below needs. Set it in the same change that marks the EU review model.

Pinned by:

• DataResidencyRoundTest: on an EU-only instance, the provider is never called for a Global or an unmarked model. The negative control (the gate disabled) fails both cases.
• ModelProvenanceTest: the vocabulary, the seeding, the BYOK exemption, the route guard and the localized texts.

The fleet audit (2026-09-27)

A read-only audit covering every Deployments/* record on the control instance, the LanguageModel/ModelProvider nodes on four meshes (systemorph, memex, pearl, partnerre), every Azure AI Services account (az cognitiveservices account deployment list, subscription explicit), and the OpenRouter EU region (https://eu.openrouter.ai/api/v1/models/<id>/endpoints).

No chat or embedding model served by any instance is EU-only today. The only EU-only rows are the in-cluster Whisper speech model (AKS, swedencentral) and two Azure deployments that no instance references.

The Azure accounts: s-meshweaver (rg-meshweaverai, sub 7ecc5974-…), fy-meshweaver3-dev-swc-001 (rg-meshweaver3-dev-swc-001, sub c45ca8ae-…) and partnerre-memex-ai (memex-aks-rg, PartnerRe tenant). All three are in swedencentral with SKU S0. Every Claude model in swedencentral is offered as GlobalStandard only. claude-haiku-4-5 v20251001 is hostedOn=anthropic, so it may be processed outside Azure.

Bring-your-own keys live as ModelProvider nodes at {user}/_Memex/<Provider>, with their models at {user}/_Provider/<Provider>/<model> and the key stored enc:v1:. They are never seeded Eu: a known global host reads Global, and anything else reads Unknown. Row-level security hides other users' BYOK nodes, so the audit counts only the auditor's own.

Every model, by route

Not established by the audit

1. The running pods' configuration. The records are not the pods. Overlay-only helm keys and live environments were not read.
2. Embeddings on pearl and partnerre. Pearl's record declares no Embedding__* key. partnerre has no control record; its account holds text-embedding-3-small GlobalStandard, which is probably the one in use, but that is not proven.
3. Retention. It was not checked whether any Azure account has approved modified abuse monitoring (zero retention), whether OpenRouter has account-level ZDR or provider filters, or what Inceptron's terms are. On GLM 5.3, the EU Mistral endpoint is tagged nvfp4, not zdr.
4. Inceptron's location. OpenRouter lists it in its EU region, and that is the only basis for calling it EU.
5. GitHub Copilot CLI residency was not researched, so it is Unknown. The build instance's mesh was not reachable.

Proposed elimination (not executed)

Every change below is a record change or an Azure deployment change. Each goes through a governed Hosting/InstanceAction / Governance/Activity on the control instance, and each needs the maintainer's approval. Nothing here has been applied.

The target tiers, as the maintainer decided, are all served through eu.openrouter.ai on our OpenRouter account:

These apply to memex, memex-cloud and pearl. Pearl runs on our OpenRouter account, not a key of its own, and moves to the EU endpoint with the others.

partnerre is out of this scope. It uses its own OpenRouter Business account, so its models are its own to choose. They are marked the same way, with processing decided by its own route.

1. Route the tiers above through the EU region. Use an OpenRouterEU provider section at https://eu.openrouter.ai/api/v1, which is marked Eu by its endpoint. It is config-seeded, and its chart and Hosting rendering are owned by the fleet-switch work.
2. Drop or mark the models with no EU route: moonshotai/kimi-k3, openai/gpt-5.2, google/gemini-3.1-pro-preview, google/gemini-3.7-flash, deepseek/deepseek-v4-pro, x-ai/grok-4.6 and every Qwen model. None of them has an EU provider on OpenRouter. The tiers above replace them; any that stay offered are marked Global.
3. Embeddings: deploy text-embedding-3-small as DataZoneStandard on s-meshweaver (offered in swedencentral) and point Embedding__Endpoint there. It is the same model, so no re-index is needed. The alternative is mistralai/mistral-embed on eu.openrouter.ai, which does need a re-index.
4. Claude in Foundry (memex, memex-cloud, control) has no EU zone. The heavy tier moves to Claude through eu.openrouter.ai. Any Foundry Claude still offered is marked Global.
5. Azure GlobalStandard deployments on our accounts: redeploy as DataZoneStandard where swedencentral offers it (gpt-5-mini, gpt-5.4, Mistral-Large-3, DeepSeek-V4-Flash 2026-04-23). Mark the rest only. Delete the unreferenced s-meshweaver deployments.
6. Declare the marks on the records: {Section}__DataResidency per provider section (Anthropic__DataResidency=Global; AzureFoundry__DataResidency=Eu only once its deployments are DataZone or regional), and AI__RequiredDataResidency=Eu on each instance that must be EU-only. 🚨 Measured on core main: the portal chart renders none of these keys yet, and it renders no OpenRouter__Endpoint or OpenRouterEU__* either. Its ConfigMap names every key explicitly, so a record that sets them reaches no container until the chart adds them.

Incidental findings from the audit, not about residency:

• partnerre's Provider/AzureFoundry offers four deployment names its Azure account does not have.
• memex-cloud's Provider/Anthropic still lists claude-opus-4-7 and claude-sonnet-4-6, which have no deployment behind them.
• The records name anthropic/claude-opus-5.5 where the meshes list anthropic/claude-opus-5.