Residency as a routing constraint rather than a contract clause

The usual way data residency is handled: choose vendors whose terms say the right things, sign a DPA, list them in a register, and audit annually.

That works, and it is enforced entirely outside the system. Nothing in the running software knows about it. If an engineer adds a provider on a Tuesday, the register is wrong until somebody notices — and the mechanism for noticing is a person reading a document.

The alternative

Make it a property of the model, and a gate the router runs:

- id: infra-large
  provider: infra
  residency: in_infra

- id: vendor-frontier
  provider: anthropic
  residency: vendor

moneypath.verify:
  constraints:
    residency: in_infra

Now a request classified as money-path cannot reach a vendor model, because the filter removed it before anything ranked. Adding a provider does not silently widen what critical work can reach — a new model arrives with a residency label, and if it is vendor it is invisible to any concept pinned to in_infra.

And the decision is visible per request:

"eliminated": {"vendor-frontier": "residency"}

That is the difference. Not "our policy says" but "here is the request, and here is the model it was not allowed to use, and why".

Why the fallback chain matters more than the filter

A filter is easy. What is hard is that a critical request whose compliant models have all failed must be refused, not served by the next thing down the list.

That is the moment the constraint is tested, and it is the moment every availability instinct pushes the other way. A model was right there. The user is waiting. Serving it would work.

Serving it means the compliance decision held right up until it was inconvenient, and the caller cannot tell, because the response looks identical.

So the chain is the survivor list, and when the survivor list is exhausted the answer is a refusal. Legible, typed, and something the caller can act on — rather than a silent downgrade that nobody records.

Where we currently are, which is awkward

moneypath.verify requires residency: in_infra and min_tier: high. The only model satisfying both is infra-large, and it does not exist — the gateway it points at has never been built.

So money-path requests are refused. The router classifies them correctly, eliminates the vendor model on residency correctly, finds an empty survivor set, and refuses. Every fifteen minutes a monitor confirms this is working as designed.

We wrote that up as a decision rather than a bug (PDR-0007), and the reasoning was: the demonstration that sells the idea already works and is public at /v1/explain, while the cheap alternatives — pointing infra at a hosted provider, or relaxing the concept — both leave the product's central claim weaker than its documentation says.

Which is a real cost. There is a concept we cannot serve, and the honest way to describe the product is to say so rather than to imply otherwise.

When this is worth the trouble

Not always. If all your traffic can go to one vendor, residency is a procurement question and putting it in a router adds machinery.

It earns its place when some work is constrained and most is not — when the majority of requests should go to whatever is cheapest and best, and a minority must never leave a boundary. That mix is common in products that touch money or health data, and it is exactly the case where a contract clause is a poor enforcement mechanism: it covers everything uniformly and knows nothing about the request in front of it.

The router is not a substitute for the contract. It is the thing that makes the contract's promise checkable on a Tuesday afternoon.

← All posts