Compute
Set region and jurisdiction rules
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.
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
- 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.
- Plan the profile, approve it if your organization requires approval, then apply it.
- Read the applied profile back. Confirm the state is
VERIFIEDrather thanAPPLIED_UNVERIFIED. - 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.