Region is a decision, not a setting.

Choosing a region takes two seconds at sign-up. It is a dropdown with two entries, sitting between the company name and the billing details, and it looks like a preference.

It is the one tenant property that cannot be changed from inside the product. Everything else — document classes, fields, keys, cost caps, who may sign in — is configuration you revise on a Tuesday afternoon. The region is a boundary, fixed when the tenant is created, and moving it is an offline operation.

That asymmetry is the whole article. A decision that is cheap to make and expensive to reverse belongs in the design review, not on the sign-up form. This is what the choice actually controls, what it leaves untouched, and the questions worth answering before anyone types a company name.

What the region decides

Two regions are in service today, and the region a tenant is created in is where its documents, prompts and audit trail stay.

Residency jurisdictions beyond those two are handled case by case rather than as a self-serve region. If a contract names a country that is not on that list, that is a conversation before the build, not a setting to hunt for afterwards.

In code, the difference is one environment variable. The samples read COGNERIS_BASE_URL precisely so that the region is a deployment detail rather than something threaded through every call site:

# EU tenant (default)
COGNERIS_BASE_URL=https://api-eu.cogneris.ai

# US tenant
COGNERIS_BASE_URL=https://api-us.cogneris.ai

If picking a region means editing anything other than that value, the region has leaked into your application, and the second tenant will be more expensive than the first.

What the region does not decide

The more useful half of the answer is the list of things that are identical on both sides, because this is where architecture decisions get made on bad assumptions.

The region is not a capability tier. Nothing is withheld from one side and sold on the other, and no endpoint answers differently depending on where it is hosted. A team that picks us because it assumes the EU deployment lags on features is optimising against a difference that is not there.

The rate limit deserves its own sentence, because it is a fixed window rather than a token bucket: the allowance resets on the minute instead of refilling gradually, requests above it get a 429, and the ceiling is tunable on Enterprise plans. It is the same policy in both regions, which means a distant region never buys extra headroom.

Latency is distance, not tiering

Since neither region is faster than the other in itself, the only latency question is geographic: how far is it from where documents originate to where they are processed, and from there to where the people reading the results sit.

Those are frequently two different places, and the second one gets forgotten. An invoice queue fed by a European shared-services centre, processed in eu, reviewed by a team in Chicago, pays the crossing on the human side of the workflow rather than the machine side — which is the half nobody instruments.

Submit-and-poll workloads absorb distance well. A batch that hands over a document and collects the result later cares about throughput and completion, not about a single round trip, and a few tens of milliseconds vanish inside processing time. Synchronous calls in an interactive path are where the crossing is felt, and that is the traffic worth measuring before committing.

Measure it with the region you intend to buy, from the network you intend to call from. A round trip from a laptop on office Wi-Fi is not evidence about a container in your production VPC.

The decision is pinned at tenant creation

The region is set when the tenant is created. Moving afterwards is an offline operation that starts with a ticket to support@cogneris.ai, not a toggle in the dashboard.

This is deliberate, and it is worth defending rather than apologising for. A residency guarantee that any administrator can flip in a settings panel is not a residency guarantee — it is a default. The value of the commitment comes precisely from the fact that changing it is a deliberate, supported, auditable act.

The practical consequence is one of sequencing. The region has to be decided while you still have the four inputs in front of you:

• Origin — where the documents are actually created and stored today, which is not always where the company is headquartered.
• Readers — where the people and systems consuming extracted data sit, including auditors and support staff.
• Contract — which jurisdiction the customer agreement, DPA or tender response commits to.
• Growth — whether a subsidiary, acquisition or new market will need a different answer within the life of the integration.

Only the last one is speculative, and it is the one that most often turns a single tenant into two.

When one tenant is not enough

A group with European operations and a US parent has two residency answers, so it has two tenants. That is the correct shape rather than a workaround, but it has consequences worth planning for rather than discovering.

Each tenant carries its own keys, its own document classes and fields, its own cost caps and its own audit trail. Consolidated reporting happens in your systems, downstream of both, because there is no cross-region view inside a tenant — which is the same boundary you asked for, seen from the other side.

The failure mode is configuration drift. Two tenants configured by hand diverge within a quarter: a field added in one, a class renamed in the other, and extraction results that no longer reconcile across the group. Treat class and field configuration as a versioned artifact you deploy to both tenants from one source, exactly as you would application config, and the drift stops being inevitable.

The compensation is real, though: blast radius, credentials and audit history are separated along a line that a regulator already recognises. Teams that end up with two tenants for residency reasons often keep the shape afterwards because the isolation turns out to be useful on its own.

Residency, isolation and sovereignty are three different questions

Security questionnaires routinely collapse these into one row, and the answers are genuinely different.

• Residency — where the data physically lives. Two regions ship today, chosen per tenant.
• Isolation — who else shares the network and compute around it. Private VPC deployment, customer-managed networking and customer-managed keys are roadmap capabilities unless they are written into a signed deployment scope; the private cloud page keeps that list current.
• Sovereignty — the contractual and jurisdictional posture around both, which is a procurement category rather than a deployment flag. We treated it as its own subject in residency as a contract clause.

A buyer asking whether EU residency is available and a buyer asking for a dedicated VPC are asking two questions with two different answers, and answering the first when you were asked the second is how deals unravel late.

Retention sits on yet another axis. Retention controls are configurable today, and how long a document is kept is independent of which region kept it — the data protection page covers that boundary.

Where the EU answer is not really a choice

For some workloads the decision is made before the design review starts. EU residency is the answer for GDPR-driven requirements, and it is required for high-risk uses under the EU AI Act.

When a use case lands in that category, the region stops being an optimisation and becomes a precondition: latency arguments do not outrank it, and a US tenant serving that workload is a finding waiting for an auditor. Establish which side of that line the workload sits on first, and the remaining trade-offs become simple, because there is only one region left to evaluate.

Ten minutes, before anyone signs up

Six questions settle it, and none of them require a proof of concept:

1. Which jurisdiction does the customer contract, DPA or tender commit us to?
2. Is this workload high-risk under the EU AI Act, or otherwise GDPR-bound?
3. Where are the documents created, and where do the results get read?
4. Is the interactive path synchronous enough for a crossing to be noticeable?
5. Will a subsidiary or new market need a second residency answer within 2 years?
6. If it will, what one source will configure both tenants?

Answer those and the dropdown fills itself in. Skip them, and the region gets chosen by whoever happened to create the account, which is how a two-second decision turns into a support ticket and a migration 18 months later.

The environments documentation carries the current regions, endpoints and limits; the quickstart is where the base URL gets set for the first time. Both are worth reading before the account exists, rather than after.