Docs: security page has no data-residency information, and states Entire does not receive transcripts

Summary

docs.entire.io/security is subtitled "Where your data lives, which redaction layers run before each write, when data leaves your machine…" but contains no data-residency information, and one sentence in it reads as ruling out the hosted side of the product entirely.

I spent a while establishing the actual picture from the API, and I think a short section on that page would save others the same trip.

1. No residency information on the page that promises it

The page never mentions jurisdictions, regions, clusters, or homeJurisdiction. But all of these are real and user-visible:

$ entire api /api/v1/clusters
# four clusters, each with a jurisdiction: au, eu, in, us

$ entire api /api/v1/me
# "homeJurisdiction": "us"

entire api --help documents --to core vs --to cell and a --jurisdiction flag; entire auth token --help describes minting "a jurisdictional identity token for that jurisdiction's entire-api cells". So the CLI is explicit that jurisdictional cells exist. The security page is silent.

2. "Entire does not operate a service that receives your transcripts"

From the Threat Model and Boundaries accordion:

Entire does not operate a service that receives your transcripts. Checkpoints travel to the Git remotes you push to.

And the top of Where Your Data Lives:

Checkpoints live in your Git repository, not in a service Entire controls.

Both are hard to square with:

• Mirrors. A repository can be mirrored to an Entire-operated cluster (entire repo mirror create), and the web console presents this as a hosting/data-residency feature.
• Server-side search. What is indexed says semantic search covers "user prompts and assistant prose from sessions". That index is server-side and queried through the control plane, so transcript content is received and indexed by an Entire service.

The same accordion's Who can read what table already concedes this three paragraphs further down, listing entire.io as reading "The repositories you authorize, and the checkpoints in them". The flat sentence above contradicts the table below it.

3. Account jurisdiction is invisible in every surface

An account's homeJurisdiction is fixed at creation and determines which cell holds account-level aggregates. It is independent of where a repository is mirrored, so the two can differ, and I think most people would not expect that.

In my case the repository mirror is eu and the account is us. The web console's repository Settings → General shows a green "European Union / Frankfurt / Synced" hosting panel, which is accurate for the repository and reasonably reads as your data is in the EU. Nothing in the console or the docs indicates the account is elsewhere. I only found it via /api/v1/me.

Content does appear to stay with the repository's cluster, and the account cell holds metadata only (commit SHAs and dates, diff line counts, repo names, session/checkpoint/token counts, tool mix). That is a reasonable design. It just is not written down anywhere.

Suggested fix

1. Add a Data residency section to the security page: the jurisdictions available, what lives in a repository's cluster versus the account's home cell, and that the two are set independently.
2. Reword or qualify "Entire does not operate a service that receives your transcripts" so it is scoped to the local-only configuration, and note what changes once a repository is mirrored and indexed.
3. Document whether homeJurisdiction can be changed after account creation, and whether it can be chosen at signup. I could not find a CLI or console route, and GET https://eu.auth.entire.io/api/v1/me returns foreign_jurisdiction for a us account.
4. Consider surfacing the account's jurisdiction in the console next to the repository hosting panel, since that panel is where people go to answer the residency question.

Happy to test any wording against what the API actually returns.

CLI version 0.10.3.

Start with docs.entire.io/security and compare its residency and transcript statements with /api/v1/clusters, /api/v1/me, the CLI help, and the What is indexed guide. Document the available jurisdictions, the independent repository and account locations, and the local-only versus mirrored/indexed cases; clarify the unresolved homeJurisdiction behavior or record it as needing product confirmation.