Data residency and rights

Verified against docs/superpowers/specs/2026-09-14-p2-h-golive-legal-ci.md §1.1 and §1.4 and the code cited in sources:; re-verified against the code at close-out.

Every control this page describes is visible only to an owner or an administrator; the rights section is a member's own, exercised from their own account.

What this does for you

This page explains residency as something the system enforces on every model call, how long each kind of record is kept, and how a member's own request to see or erase their data is answered.

Before you start

• You know your organisation's residency policy — EU/EEA only, EU/EEA first or Anywhere a route requires — set on Organisation → Policies (covered on the Organisation policies page).
• For a self-hosted deployment, you can run a command on the machine the product runs on; the hosted service instead answers a member's own request from their account.

Steps

1. Treat residency as an enforced filter, not a promise in copy. Every model call is resolved against the routes your policy admits — EU/EEA only admits only a route guaranteed inside the EU/EEA or run on your own machine; EU/EEA first also admits an EU/EEA-inference route; Anywhere a route requires admits every route. A call with no admitted route fails outright rather than using one outside the policy.

   <!-- shot: data-residency-and-rights-01-phone.png | The residency control on Organisation → Policies, on a phone --> <!-- shot: data-residency-and-rights-01-desktop.png | The residency control on Organisation → Policies, on a desktop -->

2. Look up how long a kind of record is kept. Every table in the product carries a floor your organisation cannot shorten, a default, and a ceiling it cannot exceed. A message, an attachment or a reaction is kept for a default of 730 days (floor 30, ceiling 2,555); the audit log for a default of 365 days (floor 180, ceiling 730); a run's own event ledger for a default of 90 days (floor 30, ceiling 365); the record that an AI disclosure was shown on an outward message for a default of 365 days (floor 180, ceiling 1,825). Deleting your account is always available regardless of any one kind of data's own schedule.

3. On Settings → General, a member exercises their own rights: Delete my account removes and overwrites their own rows without a grace period, and is available whatever their role. A deletion does not destroy the organisation's own encryption key — that key is shared by every member of the organisation, so destroying it to answer one member's request would make every other member's data unreadable — so a record another member's own action refers to (an audit-log or run-event entry naming the erased member, for example) is stripped of the member's identity rather than shredded, and stays technically decryptable under the organisation's key. On a self-hosted deployment the same rights run from the command line as botseon privacy export and botseon privacy erase, documented in full on the self-hosting reference.

   <!-- shot: data-residency-and-rights-03-phone.png | Settings → General, the danger zone, on a phone --> <!-- shot: data-residency-and-rights-03-desktop.png | Settings → General, the danger zone, on a desktop -->

4. Read the imprint for who to write to about a right this page does not cover, and know what this product does not claim: no certification is held or claimed, and the residency wording above is the only residency wording this product uses anywhere — no stronger synonym for it appears in its copy or its documents. The imprint page itself is not live on this deployment yet, so there is no screen to show for this step.

A worked example

Exporting one member's own data from the command line, on a self-hosted deployment:

botseon privacy export --org <orgId> --user <userId> --actor <actorId> --out export.json

What can go wrong

See also

• Organisation policies
• Members and access requests