> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Set region and jurisdiction rules description: >- Separate where data is read, processed and written, record the choice in a policy profile, then read it back and learn what a refusal looks like before you run work. route: /docs/compute/security/regions-and-jurisdiction page_id: docs-compute-security-regions-and-jurisdiction page_type: howTo content_layer: guided documentation surface_profile: guided_docs audience: Administrators setting locality rules for an organization or project voice: D reader_question: How do I set where my data may be read, processed and written, and what happens if a job breaks that rule? primary_action: Review policy profiles source_locale: en-US source_status: APPROVED source_version: docs-compute-security-regions-and-jurisdiction-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## Before you start Locality is three questions, not one. Where your source data may be read from. Where it may be processed. Where a result may be written. They can have different answers, and most surprises come from the third. You need management access to create or change a policy profile; work submission cannot change one. ## Separate the three constraints - **Source.** A registered source and its credential reference decide where data is read from. - **Processing.** A policy profile, referenced by the job, carries the processing rules. - **Destination.** A registered destination and its delivery authority decide where a result lands. Naming all three is the actual work. A single answer about "our region" usually hides a destination that sits somewhere else. ## Record the choice as a policy profile 1. Describe the profile options your account supports, in the portal or through the management surface. Do not code a value you have not read back. 2. Plan the profile, approve it if your organization requires approval, then apply it. 3. Read the applied profile back. Confirm the state is `VERIFIED` rather than `APPLIED_UNVERIFIED`. 4. Version the profile when the rule changes, instead of editing a live one in place. Re-applying the same change returns its prior verified result, so a repeated apply is safe. ## Reference the profile from the work Your request's `policy` object carries a `profile_id`. That reference is the only place a job states its locality rules. The rule stays in one reviewable object rather than in every call site. Your quote is priced against the same profile. If the priced facts drift before you approve, admission answers `REPLAN_REQUIRED` and asks you to price the new facts. ## What success looks like The profile reads back as verified. Your quote repeats the profile it was priced against. The job is admitted and runs, and the delivery lands only at a destination you registered. ## What a refusal looks like An unsupported combination refuses at admission, before work starts. The refusal is a typed non-success outcome carrying a safe reason and a non-empty next action. A locality refusal is not a capacity refusal. They are separate states with separate next actions, and retrying a locality refusal on a timer will never clear it. Usual next actions are choosing a supported profile, registering a destination that satisfies the rule, or narrowing the source. ## What this page will not tell you Lithi does not publish the physical locations or the machines behind a policy choice, and no supported setting exposes them. Where a named data category is stored, processed, backed up or transferred depends on your configuration, the service path and your current terms. Bring the exact category to your contract review. [Review policy profiles](/docs/compute/configure/profiles)