Residency is a filter, never a preference
Published
Residency is the reason this project exists, so it is also the place where a small convenience becomes a large problem. A request carries a region filter. Every candidate device is checked against it. What happens when nothing satisfies that filter is the whole design, and the answer is that nothing is scheduled.
A filter and a preference are different products
A preference would rank devices that match first and fall back when none do. A filter returns a refusal instead. The consequence is visible and boring, which is the point: if no device satisfies the request, the result is an explicit error and no work happens anywhere. The dispatch path cannot widen the search, because there is no branch that widens it.
Every refusal has a name
The contract defines a union of policy refusals, and a denial always names one of them. There is no refusal without a code, which is what makes an audit possible: you can read exactly which rule stopped a job.
- no_candidate_for_policy: no device satisfies the request at all. This is the case where the filter is never relaxed.
- model_not_held: devices exist, but none already holds the model. A job that would need a download is not scheduled.
- insufficient_memory: no candidate has the memory floor the model needs, a hard filter rather than a score.
- no_matching_accelerator: no candidate announces an accelerator the model can run on.
- region_not_permitted: the region filter excludes every candidate.
- epoch_stale: the candidate capability claim was revoked by a newer epoch.
- device_over_daily_ceiling: the candidate has reached its per-device daily earning cap.
The region is a jurisdiction, and an unchosen one is a lie
Because a region is a residency claim rather than a routing hint, the capability validator requires the announced region to be a two-letter ISO 3166-1 alpha-2 country code and refuses anything else with a 400 region_invalid. The backend label dev-mock is not a country, so a device announcing it cannot register at all.
The headless contributor requires its region to be set. There is no default: unset, it refuses at startup and exits before it makes a single network call. A malformed value such as dev-mock is refused the same way. The earlier default was the interesting defect, because it meant a machine in France, Poland or anywhere else could announce German residency on the dispatch path while a comment next to the code claimed the opposite. That was found by running the assembled product rather than a unit test, and the fix is proven by a check that counts HTTP requests and finds zero of them, not merely by an exit code.
Residency is about which law can compel disclosure
One more distinction stops the rule from being read as a performance setting. The point of EU residency is which law can compel disclosure, not where a datacentre happens to stand. A region in Frankfurt run by a company domiciled elsewhere is still reachable under that country law, while a provider domiciled in the EU is not reached the same way. That is stated as a fact about jurisdiction rather than as a judgement about any provider.
The same reference makes the residency question market-specific. For UK users the adequacy position differs from the EU one, so residency decisions should be made per market rather than assumed from a European address. A filter that quietly treated every European locale as one jurisdiction would get that wrong for exactly the users who need it right.
The check that matters here
The acceptance test runs the real coordinator, two real contributor processes and the dashboard over HTTP, and asserts a device outside the requested regions receives no job and no credit moves. The refusal code is the one the policy engine itself emits, not a string written for the test.
The honest limit is the one the same document states: this is enforcement over a mock backend. No real model ran, so what is proven is the routing decision and the money movement, not that a compliant device produced a good answer.
Why this is written down as a rule
The project rules call a residency escape a P0 defect, and that severity is deliberate. A silent fallback would not look like a bug from the outside. It would look like a working service that answered a request, which is exactly why it cannot be a runtime option that a future change can switch on quietly.
Where this can be checked
The guide cited below is the source the model registry rows name for every model fact this post repeats. It is not the source for the routing decisions themselves: this project documents those in docs/01-architecture.md, docs/07-swarm-v1-spec.md, docs/08-credits-and-chain.md and data/models.mjs in the llmeuchain repository, which is self-hosted and has no public remote to link to. Until it is published, treat the internal numbers here as unverified by a reader and checkable only against the repository.
Zdroje
Each link goes to the source the post cites. Where a source does not state a fact, the post shows it as unverified instead of filling it in.