Data residency

What it does

A residency policy is a set of countries. A request held to one is only ever sent to a node, or to the network's own default engine, whose region is in one of those countries. When nothing inside them can serve it, the request is refused with 503. It is never routed outside the policy as a fallback, a retry or a verification replay.

Residency covers where inference runs: the machine that reads your prompt and writes the answer. The section What it does not cover lists what it does not pin.

Three levels, the strictest wins

Every level that sets a policy must hold, so a request may run only in the countries all of them allow. With the organization on eu and a request sending Silicon-Residency: de,fr, the request runs in Germany or France. A request can narrow its organization's or key's residency, never widen it: Silicon-Residency: us under an eu organization answers 400.

curl -si https://api.siliconnetwork.io/v1/chat/completions \
  -H "Authorization: Bearer $SILICON_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Silicon-Residency: eu" \
  -d '{"model": "fast", "messages": [{"role": "user", "content": "Hello"}]}'

HTTP/2 200
silicon-region: de-fra
silicon-residency: eu
silicon-node: <node id>

A key whose Allowed regions name node region codes (de-fra, eu-central) keeps that pin: only those exact regions serve it. Such a key states no residency of its own, but the organization's and the request's still apply on top.

Zones, countries and node regions

A node reports a region, chosen by its operator. The network reads a country from it as follows, and a node whose region names no country never serves a request with a residency policy:

Operators: join with a country coded region to take residency traffic: your country in the engine dashboard's Region list, or SILICON_NODE_REGION=de-fra on a node configured from the environment. See Run a node.

What is enforced

Each place that would send your prompt somewhere checks the policy first:

• Scheduling. The scheduler is asked only for nodes inside the policy, and the gateway checks the node it is given again before sending anything.
• The default engine. The network's own engine serves the request only when its configured region is inside the policy. A node that fails mid request fails over to it only then.
• Fallback chains. Every model of a chain (fast, best, a models list) is held to the same policy.
• Verification. Sampled requests are re-run on the network's trusted engine, or on other nodes for a quorum check. A request is sampled only when the trusted engine is inside its policy, and a quorum replay goes only to nodes inside it. Otherwise the request is not sampled at all: it counts as unverified, which also means its node's operator earns nothing on it.
• Content screening. When the deployment screens prompts with a classifier, a classifier outside the policy is not sent the prompt: the request is refused with 503 instead (or, where the deployment chose so, that check is skipped for it).
• Batches. Each request of a batch runs under the organization's and key's policy as they stand when it runs, and under the Silicon-Residency header the batch was created with.

Proving where it ran

For something you can keep and show, ask for a signed receipt. When a policy applied, the gateway's countersigned statement carries a residency block next to route.region:

"route": { "target": "node", "node_id": "<node id>", "region": "de-fra", ... },
"residency": {
  "policy": "de",
  "countries": ["de"],
  "levels": { "org": ["eu"], "request": ["de"] },
  "region": "de-fra",
  "country": "de"
}

The statement is signed with the platform key published at /.well-known/silicon-receipt-keys.json, so anyone holding it can check it offline. Receipts without a policy have no residency block.

Errors

What it does not cover

• The platform services. The gateway, the control plane and the relay (which carries traffic to nodes behind NAT) are hosted services that may run outside your policy. Your request passes through them, encrypted in transit; they keep no prompt or output, with the exception below.
• Batch and Files content. Batch requests, their results and uploaded files are stored by the control plane until they expire (see Files and batches). Residency decides where those requests run, not where that content is stored.
• A node's country is declared. It is the region its operator gives when joining; the network does not geolocate machines. Only operators the platform has approved can serve at all.
• Changes take a moment. The gateway reads the organization's setting with the key and keeps it for its key cache period (15 seconds by default), so a change applies within that.
• Availability. A request can only be served when a node inside its policy is online with the model. Where none is, the answer is 503, by design.

Residency is a routing guarantee, not a legal one. Whether it meets a particular obligation (GDPR transfer rules, a sector rule, a contract) is for you and your counsel to judge.