GDPR Policy

Soleur -- Company-as-a-Service Platform

Effective Date: February 20, 2026 Last Updated: July 16, 2026 (Ref #6538 (chore-retire-web-2-fsn1-orphan) — factual accuracy correction; no change to the substance of processing. The hosting locative is now stated at the EU level, with the current data centres named in Section 2.2 and Section 6 (International Data Transfers). The host that serves app.soleur.ai and stores workspace data is in Helsinki, Finland (hel1); a second web host (web-2) has been in Falkenstein, Germany (fsn1) since July 13, 2026 (Ref #6393), and the prior "same Helsinki (EU) region" wording was inaccurate from that date. web-2 has never served user traffic and has never stored user data (no load balancer exists; app.soleur.ai resolves solely to the Helsinki host; its workspace volume is empty) and its retirement is decided. Both data centres are EU, under the same Hetzner account and the same signed AVV → no new sub-processor, no third-country transfer, GDPR Chapter V not engaged, and no change to lawful bases, retention, or data-subject rights. Output marked draft-requiring-professional-review). Previous: July 5, 2026 (Ref #6007 (feat-severity-ranked-inbox) — added the inbox_item table (migration 122), an operational-notification store for the founder's severity-ranked attention inbox (ADR-085). It holds server-generated notification metadata only — workspace_id (FK), an optional user_id (the recipient), severity, source, a server-generated title, ids-only source_ref, and read/act/archive timestamps — and no agent output, message body, or email content. Personally-targeted rows (user_id set) are INCLUDED in the Article 15 self-serve export — their created_at/read_at/acted_at/archived_at notification-interaction history is personal data held in no other exported table; workspace-broadcast rows (user_id NULL) are not personal to a subject and are excluded by the per-user export filter (Article 20 portability does not apply — the title/source_ref are controller-generated, not user-provided). Article 17 erasure is satisfied by ON DELETE CASCADE from public.users and public.workspaces (non-WORM operational data; no anonymise RPC). No new processing activity (no Article 30 amendment), no new sub-processor, recipient, or third-country transfer. Output marked draft-requiring-professional-review). Previous: July 2, 2026 (Ref #5274 Phase 3 (feat-multi-host-phase3d-cutover) — extended the Section 2.2 Hetzner sub-processor entry and the Section 6 Hetzner international-transfers entry to reflect the multi-host /workspaces GA setup: a second EU web host (web-2) and a dedicated per-workspace git-data host, all on the same Hetzner account and Helsinki (EU) region — no new sub-processor and no international data transfer. Stored workspace git data now sits on a LUKS-encrypted (encryption-at-rest) volume; traffic between hosts is encrypted in transit with TLS; and access to a workspace's git data is authorized per workspace (re-verified on proxied sessions). No new processing activity, personal-data category, lawful basis, or recipient. Output marked draft-requiring-professional-review). Previous: June 30, 2026 (Ref #5274 (feat-phase2-git-data-lease-fencing) — added the worktree_write_lease table (migration 116), an operational write-lease coordination record for the multi-host /workspaces layer (epic #5274, ADR-068 §2). It holds infrastructure-coordination fields only — workspace_id (FK), worktree_id, host_id (a host-stable infrastructure server identity, NEVER an auth.uid(); it identifies a machine, not a data subject), lease_generation, and two timestamps — and no user-provided content or personal-profile data, so it is excluded from the Article 15/20 self-serve export (DSAR exclusion: no personal data to disclose, no new disclosure section). Article 17 erasure is satisfied by ON DELETE CASCADE from public.workspaces (the row has zero audit lineage — no anonymise RPC needed; proven by the AC5 cascade integration test). No new processing activity (no Article 30 amendment), no new sub-processor, recipient, or third-country transfer. Output marked draft-requiring-professional-review). Previous: June 16, 2026 (Ref #5345 (feat-routines-management) — added a Section 3.7 "Web Platform Service Delivery" bullet for the new routine run-log (routine_runs, migration 107), an append-only WORM operational audit log of scheduled-routine executions (one row per terminal run: routine id, run id, completed/failed status, trigger source = scheduled/manual/agent, actor_class, started/ended/duration, scrubbed+truncated error_summary). Lawful basis: legitimate interest (Article 6(1)(f)) — operational audit, service reliability, and Article 32 integrity-of-processing — with the full three-part balancing test recorded inline; on the single-operator tenant the only data subject is Soleur itself (actor_id/delegating_principal = the operator's own id on off-schedule human/agent runs; NULL for scheduled system runs). Article 22 negative determination (an audit record, no automated decision). Retention: indefinite (low-volume audit log). Article 17 erasure via anonymise_routine_runs SECURITY DEFINER RPC (NULLs both actor columns under the WORM bypass, preserving the row), called BEFORE auth.admin.deleteUser — mirrors anonymise_workspace_activity. Articles 15/20: excluded from the self-serve export at present (operational system-audit log, not personal-profile data; promote when a non-Soleur tenant exists or the export chain is wired). No new sub-processor, recipient, or third-country transfer. Privacy Policy Section 4.12; Article 30 register Processing Activity 29; DPD Section 2.3(ac). Output marked draft-requiring-professional-review. Previous: June 15, 2026 (Ref #5325 (feat-agent-native-outbound-email) — added Section 3.11 documenting the Article 6(1)(f) / Recital 47 lawful basis for agent-assisted, human-approval-gated 1:1 outbound cold email used for the founder's outreach, sent from the dedicated subdomain outbound.soleur.ai via Resend (Privacy Policy Section 4.14; Article 30 register Processing Activity 28; LIA at knowledge-base/legal/legitimate-interest-assessments/2026-06-15-outbound-email-authority-lia.md) — the outbound counterpart to Section 3.10 / PA-27, overturning the 2026-06-11 inbound LIA's send-authority deferral: recipients are involuntary third-party data subjects whose contact details were obtained NOT from them (a published professional byline), so Article 14 applies and the disclosure is carried in-line in the first EU/UK communication (no reliance on the Article 14(5)(b) disproportionate-effort exemption, contrast Section 3.10); permanent per-send human-approval gate (no auto-send for cold mail); single compliance chokepoint with ordered refuse-to-send checks; plaintext recipient address and body never persisted (only a keyed recipient_hash = HMAC-SHA-256 with a Doppler pepper + body hashes); permanent / monotonic opt-out suppression honoured at send time; Article 17 erasure scrubs the keyed pseudonym with an Article 17(3)(b) accountability-period carve-out for the WORM send-audit; no LLM in the send path and no AI provider as a recipient on the outbound leg; Resend is the only new sub-processor surface (already documented; 30-day retention, no deletion API — same Chapter V finding as Section 3.10); DPIA screened at single-operator scale with the channel-level ePrivacy / PECR / CNIL analysis named as the accepted residual / pending counsel item; counsel review pending. Previous: June 11, 2026 (Ref #5103 (feat-operator-inbox-delegation) — added Section 3.10 documenting the Article 6(1)(f) lawful basis for AI-assisted triage of inbound email to the company operational address ops@soleur.ai (Article 30 register Processing Activity 27; LIA at knowledge-base/legal/legitimate-interest-assessments/2026-06-11-operator-inbox-triage-lia.md): deterministic statutory fast-path before any LLM, structural parse-and-discard (no body column in email_triage_items), Article 14(5)(b) public-notice posture for involuntary senders, Article 17 erasure via gated SECURITY DEFINER RPCs with a documented Article 17(3)(b) accountability-period carve-out for statutory rows, retention probe 7d / non-statutory 365d / statutory per accountability period, sub-processors Resend Inc (US — inbound custody, 30-day fixed retention, no deletion API) and Anthropic PBC (US — non-statutory mail only, truncated + sanitized, 30-day default retention until Zero-Retention amendment); DPIA screening memo at knowledge-base/legal/audits/2026-06-11-dpia-screening-operator-inbox-triage.md concludes no full DPIA at single-operator scale with three named accepted residuals; counsel review pending as a single bundle). Previous: June 8, 2026 (PR #5014 (#5005) — converged the DSAR export's workspace-files enumeration root (server/dsar-export.ts resolveDsarWorkspacePath) off the stale users.workspace_path column onto the workspace-id resolver (workspacePathForWorkspaceId(expectedUserId), solo/N2), fixing an Art. 15+20 completeness gap whereby data subjects provisioned after the ADR-044 users → workspaces relocation had their OWN workspace files silently omitted from the self-serve export (the legacy per-user column was empty/stale). No new processing activity, personal-data category, lawful basis, recipient, or sub-processor — the export now delivers the subject's own workspace files it always intended to; the solo-keyed resolver (single-arg, no active-workspace claim) structurally prevents the inverse over-export of a shared-workspace owner's files into a member's export. No Article 30 amendment (read-path completeness remediation, not a new processing purpose). Previous: PR #4627 (#4625) — extended Art. 15 + Art. 17 DSAR coverage with the byok_delegation_withdrawals consent-withdrawal ledger (mig 084, anonymise_byok_delegation_withdrawals step 5.12, before auth.admin.deleteUser); the consent gate (mig 083) makes recorded in-app acceptance the source of truth for the BYOK key lease, and a gate-side withdrawal stops in-flight billing within one turn (Art. 7(3)). No new sub-processor; gated by BYOK_DELEGATIONS_ENABLED (default OFF). Previous: PR #4559 (#4558) — added a Section 5.3 bullet "Workspace co-member access to a connected repository and knowledge-base" disclosing that, post-ADR-044 (migrations 079/080/081 relocating repo-connection state from the per-user users table to workspaces), joining a workspace as a Co-Member grants access to that workspace's connected GitHub repository AND its derived knowledge-base, and inviting a Co-Member grants them the same access (previously a joined member could not reach the owner's repo — the #4543 brand-survival defect); lawful basis is the Owner's Art. 6(1)(a) consent in the workspace_member_attestations invite attestation plus the existing Art. 6(1)(f) legitimate-interest basis for repo-derived signals (PA-17); github_installation_id is column-level REVOKED from the authenticated role and readable only via the membership-checked SECURITY DEFINER RPC resolve_workspace_installation_id; no new sub-processor — GitHub Inc. (Microsoft) remains the upstream source; cross-references DPD §2.3(u), Privacy Policy §4.11, Article 30 register PA-17, ADR-044. Previous: PR #4491 (#4358) — extended DSAR conversations fetch to include participated workspace conversations for Art. 15 completeness; subject-authored messages in co-member-owned conversations now included in the bundle. Previous: (#4290 — added byok_delegations WORM ledger Art. 15 read surface per PR-A of feat-byok-delegations (#4232); production exposure at PR-A merge is internal-only (gated by byok-delegations feature flag, default-off); DSAR worker wired with five per-column .eq() chains for OR-semantics; Art. 17 cascade RPC ships in PR-B (art_17_anonymise reserved in the migration's revoked_reason CHECK enum); previous: May 22, 2026 extended Section 5.3 Article 17 + Article 15 cascade prose with the workspace_member_removals WORM ledger introduced by migration 062 / PR #4294 (Article 30 register Processing Activity 19 — distinct from sibling PA-20 workspace_member_actions covered immediately below); 36-month retention floor (Art. 82(2) shortest-applicable-jurisdiction limitations period); anonymise_workspace_member_removals(p_user_id) SECURITY DEFINER RPC NULL-sets both PII columns removed_user_id AND removed_by_user_id; cascade step 3.905 in server/account-delete.ts runs BEFORE the cascade DELETE at step 3.91, BEFORE anonymise_workspace_member_actions step 3.93 (PA-20, 7-year retention), and BEFORE auth.admin.deleteUser (step 4); lineage columns (id, removed_at, workspace_id) preserved post-erasure per Art. 5(2) accountability; WORM trigger bypass is structural-shape detection at the trigger body itself (PII columns transition NOT NULL → NULL only; lineage columns unchanged) — NOT a SET LOCAL session_replication_role GUC bypass; the anonymise RPC does not issue the GUC. This is the post-#4294-review deliberate divergence from mig 037 / mig 051 precedent per learning 2026-05-18 (pg_cron runs as postgres, not service_role, so a role-gated bypass would silently fail the retention sweep); departed Co-Members exercise Art. 15 against PA-19 via the service-role DSAR worker — the is_workspace_member() RLS helper returns false post-removal so the standard self-serve surface omits the row; workspace_member_removals is queried single-arm on removed_user_id (the row's owner-of-record); a Workspace Owner's own DSAR returns rows where they were removed, not rows where they performed removals on others; PA-19 and PA-20 are sibling ledgers — distinct substrates, distinct retention floors (36-month vs 7-year), distinct anonymisation RPCs; no new sub-processor engaged; closes legal-doc-cross-document-gate lockstep gap from PR #4294 (#4333); previous: #4287 — extended Section 5.3 Article 17 cascade prose with the new anonymise_workspace_member_actions(p_user_id) SECURITY DEFINER RPC introduced by migration 063 / PR #4231: NULL-sets actor_user_id + target_user_id on the append-only workspace_member_actions audit log; lineage columns preserved per Article 5(2) accountability; idempotent; runs as step 3.93 in server/account-delete.ts between anonymise_organization_membership (3.92) and auth.admin.deleteUser (4); the cascade DELETE at step 3.91 does NOT create new audit rows because mig 063 re-CREATEs anonymise_workspace_members to set SET LOCAL session_replication_role='replica' which suppresses the AFTER trigger during the cascade (eliminates the orphan-PII window); WORM trigger bypassed at the RPC call site via the same SET LOCAL session_replication_role='replica' per mig 037 + mig 051 precedent (NEVER current_user='service_role' per learning 2026-05-18); Article 30 PA-20 records the activity; internal jikigai workspaces only at v1 (gated by FLAG_TEAM_WORKSPACE_INVITE); no new sub-processor engaged; previous: May 21, 2026 extended Section 5.3 Article 17 cascade prose with the template_authorizations ledger introduced by PR-I #4078: anonymise_template_authorizations runs between anonymise_action_sends and anonymise_scope_grants with semantic ordering (Article 5(2) audit-trail attribution); WORM trigger bypassed at the RPC call site via SET LOCAL session_replication_role = 'replica' per mig 051 §(h) precedent; Article 30 PA-18 records the activity; no new sub-processor engaged; previous: May 17, 2026 aligned Section 3.4 balancing-test prose and Section 2.2 sub-processor entry with Cloudflare R2 Lock Rules canonical vocabulary, dropping the transitional S3 implementation-equivalence framing now that the GDPR Article 17 admin-override procedure is implemented natively against R2 Lock Rules per #3924; the 10-year retention floor and the FreeTSA RFC 3161 monthly timestamp chain are preserved verbatim; previous: May 16, 2026 aligned Section 3.4 balancing-test prose and Section 2.2 sub-processor entry with Cloudflare R2 Lock Rules vocabulary per #3918; May 16, 2026 extended Section 3.4 CLA balancing test to cover the off-site Cloudflare R2 evidence archive with a 10-year retention floor and FreeTSA RFC 3161 monthly timestamping; added Section 2.2 sub-processor entry for Cloudflare R2 per #3209)

1. Introduction

This GDPR Policy explains how Jikigai ("we", "us", "our"), operator of Soleur, approaches data protection and privacy in compliance with the General Data Protection Regulation (EU) 2016/679 ("GDPR") and related European data protection legislation. Soleur is a Company-as-a-Service platform delivered as a Claude Code plugin, providing a full-stack AI organization with 60+ agents, 60+ skills, and a compounding knowledge base for solo founders and technical builders.

This policy applies to all individuals located in the European Economic Area ("EEA") who use or interact with Soleur, including the plugin software, Web Platform (app.soleur.ai), documentation site, and GitHub repository.

2. Data Controller and Processor Status

2.1 Soleur's Role

The Soleur Plugin operates as a locally installed CLI extension. All data generated, processed, and stored by the Plugin resides exclusively on the user's local machine. The Plugin does not collect, transmit, receive, or store any personal data on external servers.

As a result, the Plugin does not act as a data processor within the meaning of Article 4(8) of the GDPR with respect to user content, knowledge-base files, or any data created through the Plugin's operation.

Jikigai acts as a data controller for: (a) the documentation site hosted on GitHub Pages, where standard web server logs (IP addresses, browser metadata) are collected via GitHub's infrastructure, (b) the GitHub repository, where issue reports and contributions involve processing of GitHub profile data, and (c) the Soleur Web Platform (app.soleur.ai), where user account data, workspace data, and subscription data are processed on Jikigai-operated infrastructure via third-party processors (Supabase, Stripe, Hetzner, Cloudflare).

2.2 Third-Party Services

Users should be aware that interacting with Soleur may involve third-party services that have their own data controller or processor roles:

Anthropic (Claude API): When users invoke Soleur agents and skills, requests are sent to Anthropic's Claude API using the user's own API key. Anthropic acts as an independent data controller or processor under its own terms and privacy policy. Soleur does not intermediate, intercept, or store any data exchanged between the user and Anthropic.
GitHub Pages (Documentation Site): The Soleur documentation site at soleur.ai is hosted on GitHub Pages. GitHub acts as a data processor for the hosting service, collecting IP addresses, browser metadata, and other standard web server logs on Jikigai's behalf. GitHub's processing is governed by the GitHub Terms of Service and the GitHub Privacy Statement, which include GDPR compliance commitments. Note: GitHub's formal Data Protection Agreement applies to paid plans (Enterprise Cloud, Teams) only; Jikigai's free-plan organization is covered by GitHub's standard terms, under which GitHub acknowledges processor obligations and maintains EU-US Data Privacy Framework certification and Standard Contractual Clauses.
GitHub (Repository): Users who interact with the Soleur repository (issues, pull requests, discussions) do so under GitHub's terms and privacy policies. For repository interactions, GitHub and Jikigai act as independent controllers of the data involved in community participation.
Supabase (Web Platform): The Soleur Web Platform uses Supabase for authentication and database services. Supabase acts as a data processor on Jikigai's behalf, processing email addresses, hashed passwords, authentication tokens, and session data. Supabase Inc is US-based, but the Jikigai project is deployed to AWS eu-west-1 (Ireland, EU) -- no international data transfers occur for Supabase-processed data. DPA signed 2026-03-19 via PandaDoc. See Supabase DPA.
Stripe (Web Platform): The Soleur Web Platform uses Stripe for payment processing. Stripe acts as a data processor on Jikigai's behalf. The integration uses Stripe Checkout (PCI SAQ-A) -- card data is handled exclusively by Stripe and never reaches Jikigai servers. Stripe is PCI DSS Level 1 certified. International data transfers are governed by the EU-US Data Privacy Framework (DPF) and Standard Contractual Clauses (SCCs). See Stripe DPA.
Hetzner (Web Platform): The Soleur Web Platform is hosted on Hetzner servers. Hetzner Online GmbH acts as a data processor on Jikigai's behalf. The Web Platform is hosted on Hetzner data centres in the EU -- no international data transfers. DPA (AVV) concluded via the Hetzner Cloud Console (signed 2026-03-19). Current EU data centres (corrected July 16, 2026 -- Ref #6538): the host that serves app.soleur.ai and stores workspace data is in Helsinki, Finland (hel1); a second web host (web-2) has been in Falkenstein, Germany (fsn1) since July 13, 2026, plus a dedicated host for per-workspace git data. Both run under the same Hetzner account and the same signed AVV, and both are in the EU, so this introduces no new sub-processor and no international data transfer. web-2 has never served user traffic and has never stored user data (no load balancer exists; app.soleur.ai resolves solely to the Helsinki host; web-2's workspace volume is empty), and its retirement is decided (Ref #6538). Previously this section said the platform ran across more than one host "in that same Helsinki (EU) region", which was inaccurate from July 13, 2026. Stored workspace git data sits on a LUKS-encrypted (encryption-at-rest) volume; traffic between the hosts is encrypted in transit with TLS; and a workspace's git data is authorized per workspace (only that workspace's members can fetch it, re-verified when a session is served across hosts).
Cloudflare (Web Platform): The app.soleur.ai subdomain uses Cloudflare as a CDN and reverse proxy, extending the existing Cloudflare zone used for soleur.ai. International data transfers are governed by DPF, SCCs, and Global CBPR certification. See Cloudflare DPA.
Cloudflare R2 (CLA evidence archive): Cloudflare R2 hosts the off-site CLA evidence archive soleur-cla-evidence in region weur (Western Europe). Cloudflare, Inc. acts as a data processor on Jikigai's behalf for this distinct surface; the same Cloudflare Customer Data Processing Agreement applies. R2 Lock Rules enforce a 10-year retention floor (age-based, maxAgeSeconds = 315360000) providing write-once-read-many (WORM) semantics for archive contents at rest. See Section 3.4 for the balancing test and DPD §2.3(n) for the processing-activity description.
FreeTSA (RFC 3161 Time Stamp Authority): A monthly cron submits the SHA-256 of the CLA evidence bucket-state manifest to FreeTSA, a public RFC 3161 timestamping service operated from DE. FreeTSA receives no contributor data -- only a 32-byte hash. The returned .tsr is stored in R2 and on the cla-signatures branch. Because the input is not personal data within Article 4(1), FreeTSA processing falls outside Article 28 sub-processor scope; we disclose the dependency here for completeness.

3. Lawful Basis for Processing

3.1 Plugin Operation (Local Processing)

Because Soleur processes all data locally on the user's device and does not transmit personal data to Soleur-controlled infrastructure, there is no personal data processing by Soleur that requires a lawful basis under Article 6 of the GDPR.

3.2 Documentation Site

To the extent that GitHub Pages collects data when users visit soleur.ai, the lawful basis is legitimate interest (Article 6(1)(f)) -- specifically, the interest in providing and maintaining accessible product documentation. Users are directed to GitHub's own privacy documentation for specifics on data collected by GitHub Pages.

For website analytics via Plausible Analytics, the lawful basis is legitimate interest (Article 6(1)(f)) -- understanding documentation traffic patterns to improve content and user experience. This processing is cookie-free, stores no personal data, and does not require consent under the ePrivacy Directive (Article 5(3) does not apply as no information is stored on or accessed from the user's device). See Section 4.3 for details.

3.3 Repository Interactions

For processing of GitHub profile data when users contribute to the Soleur repository (issues, pull requests, discussions), the lawful basis is legitimate interest (Article 6(1)(f)) -- facilitating community participation in the project. The balancing test considers: (a) the processing is limited to publicly available GitHub profile data voluntarily shared by the user, (b) the user initiated the interaction, (c) the processing is necessary for the stated purpose, and (d) users can withdraw by deleting their GitHub contributions.

3.4 Contributor License Agreement (CLA) Signatures

For processing of CLA signature data when contributors sign the Contributor License Agreement via GitHub pull requests, the lawful basis is legitimate interest (Article 6(1)(f)). The data processed consists of the contributor's GitHub username, signature timestamp, associated pull request reference, the verbatim sign-comment body, and a SHA-256 hash of the CLA document text at the PR base SHA (the "evidence record"). The signature record is mirrored to two destinations: (a) the public cla-signatures branch of the GitHub repository (contributor-facing receipt; indefinite retention) and (b) the off-site Cloudflare R2 evidence archive soleur-cla-evidence, region weur (Western Europe), under R2 Lock Rules with an age-based ten (10) year retention floor providing write-once-read-many (WORM) semantics.

Three-part balancing test (signature data on the public branch): (1) Maintaining an enforceable record of contributor intellectual property license grants is a legitimate interest of the project maintainer, required to support dual licensing under the Business Source License 1.1. (2) The processing is limited to the minimum data necessary -- only the GitHub username (already public), timestamp, and PR reference are collected on the public branch. No additional personal data is requested. (3) Contributors' rights are not overridden because they voluntarily initiate the process by submitting a pull request and explicitly consenting by posting the signing comment. Signature data is stored on a dedicated branch (cla-signatures) in the public repository. Retention is indefinite because the license grants are irrevocable; however, contributors may request deletion of their signature record, noting that the underlying license grant survives deletion per the CLA terms (Section 8(e)).

Three-part balancing test (off-site evidence archive): The off-site archive captures the verbatim sign-comment body and the document-hash at sign-time in addition to the public-branch fields. A separate balancing test is required because (i) the data set is materially broader and (ii) retention is hard-set at 10 years rather than indefinite.

(1) Legitimate interest established. The interest is the establishment, exercise, and defense of legal claims regarding contributor IP grants, including a future Apache-2.0 (or other) relicensing event under the BSL 1.1 change date, and defense against potential disputes under EU/France jurisdiction. GDPR Article 17(3)(e) explicitly carves out the right to erasure where processing is necessary "for the establishment, exercise or defence of legal claims." The interest cannot be served by the public branch alone: a public GitHub branch can be force-pushed by repository administrators and is not tamper-evident; the off-site archive provides write-once-read-many (WORM) semantics via Cloudflare R2 Lock Rules (age-based retention floor, 10 years) plus a monthly RFC 3161 timestamp chain that an external auditor can verify offline using the bundled FreeTSA root CA. An administrator override remains possible for Article 17 erasure cases via the tombstone protocol described in sub-bullet (3) below.
(2) Necessity and proportionality. The retention period of 10 years is calibrated to the longest statutory limitation period likely to apply to a copyright-related dispute in the relevant jurisdictions: 10 years under German civil law (BGB §195 + §199 for delict claims; longer periods may apply but 10y covers the typical case), 6 years under UK Limitation Act 1980 §5/§9, 30 years under French Code civil art. 2227 (we accept the 10y floor as proportionate; longer retention is judged disproportionate at v1). The data minimisation tests: (a) only data essential to prove that the signer agreed to this specific text of the CLA at this point in time is captured (comment body + doc-hash); (b) the bucket region is EU (weur) and R2 Lock Rules use age-based retention so an administrator override remains possible for Article 17 erasure cases; (c) the monthly RFC 3161 timestamp protects only the bucket-state manifest hash -- FreeTSA never sees any contributor data; (d) the bypass-record path for allowlisted bot accounts uses a sanitised key (dependabot-bot) so no [bot] substring appears in object keys, and github-actions[bot] (DB-id 41898282) is filtered out entirely before any write.
(3) Data subject rights not overridden. Contributors voluntarily initiate the sign event by commenting on a pull request and have constructive notice of the off-site archive via this Policy, the Privacy Policy §4.5 and §5.11, the DPD §2.3(n), and the CLA preambles (§0 of individual-cla.md and corporate-cla.md). The right to erasure (Article 17) is honoured via an admin-override procedure documented in the operations runbook: under R2 Lock Rules the override consists of temporarily updating the bucket lock-rule list to exclude the offending object, deleting that object, then restoring the rule list; immediately upon deletion, a permanent tombstone (tombstones/<sha>.deleted.json) is written and that tombstone is included in the next monthly RFC 3161 manifest. The tombstone preserves the integrity of the timestamp chain (an auditor sees "object H replaced by tombstone T at month M+1") without retaining any personal data beyond the SHA-256 hash of the removed object and the GDPR request reference. The Article 17(3)(e) defense-of-claims carveout means erasure may be declined when the contributor's data is materially related to a live or reasonably anticipated legal claim; the CLO confirms scope per-request.

The off-site archive does not introduce a third-country transfer for archive contents at rest (Cloudflare R2 weur is in Western Europe) and FreeTSA is operated from DE -- intra-EU. See DPD §6.4 and Privacy Policy §5.11 for sub-processor details.

3.5 Legal and GDPR Inquiry Handling

For processing personal data contained in data subject rights requests and legal inquiries sent to legal@jikigai.com, the lawful basis is legal obligation (Article 6(1)(c)) for GDPR requests (fulfilling our obligations under Articles 12-22) and legitimate interest (Article 6(1)(f)) for other legal inquiries.

3.6 Newsletter Subscription

For processing of email addresses when visitors subscribe to the Soleur newsletter via the Docs Site, the lawful basis is consent (Article 6(1)(a)). Subscribers actively opt in by submitting the signup form and confirming their subscription via a double opt-in confirmation email sent by Buttondown. Consent may be withdrawn at any time by unsubscribing via the link included in every newsletter email. Upon withdrawal, the email address is removed from the active subscriber list.

For the technical metadata automatically collected by Buttondown during the subscription request (IP address, referrer URL, subscription timestamp, browser/device metadata), the lawful basis is legitimate interest (Article 6(1)(f)). The balancing test for this interest considers: (a) the data is minimal and limited to standard HTTP request metadata, (b) the processing is necessary for service delivery and abuse prevention, (c) the data is within the reasonable expectations of someone subscribing to a newsletter, and (d) the processing does not involve profiling or automated decision-making. Data subjects may object to this processing under Article 21 by contacting legal@jikigai.com.

3.7 Web Platform Service Delivery

For processing of account data, workspace data, and subscription data through the Soleur Web Platform (app.soleur.ai):

Account creation and management: The lawful basis is contract performance (Article 6(1)(b)) -- processing is necessary to provide the Web Platform service the user signed up for. Data processed: email address, hashed password (managed by Supabase), authentication tokens, session cookies.
Payment processing: The lawful basis is contract performance (Article 6(1)(b)) -- processing is necessary to fulfill the subscription agreement. Data processed: customer email, subscription metadata. Card data is handled exclusively by Stripe via Stripe Checkout (PCI SAQ-A) and never reaches Jikigai servers.
Infrastructure hosting: The lawful basis is contract performance (Article 6(1)(b)) -- processing is necessary to provide workspace environments. Data processed: user workspaces, encrypted API keys (AES-256-GCM), Docker containers. Hosted on Hetzner in the EU (EU-only); workspace data is stored in Helsinki, Finland. See Section 2.2 for the current EU data centres.
Conversation management: The lawful basis is contract performance (Article 6(1)(b)) -- processing is necessary to provide the conversational AI service. Data processed: conversation metadata (domain leader, status, timestamps), message content (user messages, assistant responses, tool call metadata), and -- when usage telemetry is enabled per operator configuration -- per-message usage jsonb (token consumption and cost metadata).
CDN/proxy processing: For authenticated users, the lawful basis is contract performance (Article 6(1)(b)) -- Cloudflare processes requests as part of delivering the Web Platform service. For unauthenticated traffic (visitors who have not signed up), the lawful basis is legitimate interest (Article 6(1)(f)) -- operating CDN and DDoS protection for app.soleur.ai is necessary for infrastructure security and service availability (see also GDPR Recital 49). Data processed: IP addresses, request headers, TLS termination data. Processed by Cloudflare (see DPD Section 4.2).
Operational telemetry and breach detection: Two lawful bases apply jointly. (i) Legitimate interest (Article 6(1)(f)) -- emitting structured application logs to standard output (retained in a fixed-capacity Hetzner-local rolling buffer; no off-host copies) and sending error and breadcrumb events to Sentry (Functional Software GmbH, DE region; SCCs) is necessary for service reliability, security, and abuse prevention, balanced against the pseudonymisation safeguard. (ii) Legal obligation (Article 6(1)(c)) -- the same telemetry is necessary to comply with the Article 33 breach-notification timeline (see DPD §7.2). Data processed: error messages, stack traces, request metadata (URL paths, HTTP headers, navigation breadcrumbs), pseudonymous user identifier (userIdHash, see DPD §2.3(m)). User identifiers are pseudonymised at the emission boundary by replacing the raw userId with a keyed cryptographic hash using a server-resident secret pepper; under Recital 26 the controller cannot re-identify a data subject from the hash alone. Retention: Sentry events 90 days rolling; pino stdout retained in the fixed-capacity Hetzner-local rolling buffer (see DPD §2.3(m) and §4.2). Balancing test for the legitimate-interest basis: (a) processing is limited to error and breadcrumb signals plus pseudonymous identifiers necessary to attribute an incident to a user lifecycle; (b) emitting service reliability and breach-detection telemetry is within the reasonable expectations of any web-service user; (c) Sentry does not use this data for profiling or advertising; (d) the controller cannot achieve Article 33 timely breach detection and Article 32 security of processing without operational telemetry. Data subjects may object under Article 21 by contacting legal@jikigai.com; note the Recital 26 Article 17 interaction described in DPD §2.3(m) regarding pseudonymous identifiers that cannot be re-identified. Sentry monitor classes processed under this activity are limited to issue alerts and cron monitor check-ins (vendor-hosted heartbeat for scheduled GitHub Actions jobs, carrying only structural metadata: job slug, status, timestamp); Sentry log ingestion (Logs product) is NOT enabled and no application log content is forwarded to Sentry. A future change introducing a Sentry log channel requires re-disclosure in DPD §2.3(m), Privacy Policy §5.10, this section, and an extension of apps/web-platform/server/sentry-scrub.ts before the channel is enabled. Better Stack Logs IS enabled for journald + host_metrics ingestion as of 2026-05-21 (PR #4279); VRL pseudonymisation (pii_scrub_drop_userdata + pii_scrub_structured + pii_scrub_string in apps/web-platform/infra/vector.toml) applies at the Vector boundary before egress — see DPD §2.3(m)(ii), Privacy Policy §5.14, and Article 30 register PA8 §(b)(vi).
Routine run-log (routine_runs): The lawful basis is legitimate interest (Article 6(1)(f)) -- maintaining an append-only operational audit log of scheduled-routine executions is necessary for service reliability, operational accountability, and security (Article 32 integrity-of-processing). Data processed: routine identifier, run identifier, status (completed/failed), trigger source (scheduled/manual/agent), actor_class, started/ended timestamps and duration, a scrubbed+truncated error_summary for failures, and -- for off-schedule (human-/agent-triggered) runs only -- the operator's account identifier (actor_id / delegating_principal, NULL for scheduled system runs). Balancing test: (a) the data is minimal — a structural execution record with no message content, no third-party data, and only the operator's own account identifier on off-schedule runs (NULL otherwise); (b) on the single-operator tenant the only data subject is Soleur itself, so the controller and the data subject are the same legal entity and the processing falls squarely within the operator's reasonable expectations of an audit log over their own automation; (c) maintaining a tamper-evident WORM run-log is necessary for diagnosing failures, demonstrating operational integrity, and Article 32 security, and cannot be achieved without recording who triggered each off-schedule run; (d) no profiling, no automated decision-making (Article 22 negative determination), and no cross-referencing for any product, marketing, or ML purpose. Data subjects may object under Article 21 by contacting legal@jikigai.com. Retention: indefinite (low-volume operational audit log, ~one row per run; revisit if volume grows). Art. 17 erasure: anonymise_routine_runs SECURITY DEFINER RPC NULLs actor_id/delegating_principal under the WORM bypass (preserving the audit row), called in server/account-delete.ts BEFORE auth-delete (mirrors anonymise_workspace_activity). Art. 15/20: excluded from the self-serve DSAR export at present (operational system-audit log, not personal-profile data; promote when a non-Soleur tenant exists or the export chain is wired). No new sub-processor, recipient, or third-country transfer. DPD §2.3(ac); Article 30 register PA-29. (Draft — requires professional legal review.)

3.8 Content Sharing (Knowledge Base Document Sharing)

For processing related to the knowledge base document sharing feature on the Web Platform:

Share link management (authenticated users): The lawful basis is contract performance (Article 6(1)(b)) -- processing is necessary to provide the sharing feature the user activated. Data processed: share link metadata (document ID, sharing user ID, creation timestamp, share token).
Viewer access logs (unauthenticated viewers): The lawful basis is legitimate interest (Article 6(1)(f)) -- infrastructure security and abuse prevention for publicly accessible endpoints. Data processed: IP address, timestamp, user-agent (standard server access logs via Cloudflare and Hetzner). No cookies are set, no additional tracking occurs, and no account or profile is created for viewers. The balancing test considers: (a) only standard HTTP connection metadata is processed, (b) viewers voluntarily access a public URL, (c) the processing is necessary for security and cannot be avoided, and (d) no profiling or cross-site tracking occurs.

A balancing test is not required for the contract performance basis used in account, payment, and infrastructure processing above. For the legitimate interest basis applied to unauthenticated CDN/proxy traffic, the balancing test considers: (a) the processing is limited to standard HTTP connection metadata (IP addresses, request headers), (b) operating CDN and DDoS protection is within the reasonable expectations of anyone visiting a web application, (c) Cloudflare does not use this data for profiling or advertising, and (d) the processing is necessary for infrastructure security and cannot be achieved without processing technical connection data from all visitors. Data subjects may object under Article 21 by contacting legal@jikigai.com.

3.9 Runtime feature-flag identity-trait evaluation (Flagsmith)

For the runtime feature-flag substrate that gates tenant-boundary capabilities (team-workspace-invite, byok-delegations) on the Web Platform:

Lawful basis: Legitimate interest (Article 6(1)(f) GDPR). Three-part test:
- Purpose: operate a runtime feature-flag substrate (Flagsmith — Bullet Train Limited, UK; see Section 2.2 sub-processor entry) that materially reduces the blast radius of capability flips against tenant-boundary surfaces. Skill-operable per-org rollout (org-targeted segment) AND instant operator kill-switch on cross-tenant-incident detection without container restarts.
- Necessity: ENV-only flag toggling (the pre-PR-2 baseline at apps/web-platform/lib/feature-flags/server.ts:16-24) requires a full container redeploy to flip a flag — minutes-to-hours of latency and broader rollback risk. A runtime substrate is necessary to bound the blast-radius of any single-tenant cross-tenant incident to seconds, satisfying Article 32(1)(b) "ongoing confidentiality" and Article 32(1)(d) "regular testing of TOMs" effectiveness.
- Balancing: the legitimate-interest of operating a low-blast-radius capability substrate is balanced against data-subject interests by a stack of mitigations: (a) only a pseudonymised identifier (operator-supplied, not raw userId) plus identity traits { role, orgId } egress to Flagsmith — message content, attachments, BYOK keys, and email addresses do NOT; (b) transient: true is MANDATORY on every getIdentityFlags(...) call (effective on PR-2 merge), opting out of Flagsmith server-side identity persistence; (c) dual-control gating means every flag flip is the AND of the Flagsmith boolean AND a server-side env-allowlist (*_ALLOWLIST_ORG_IDS) — a Flagsmith segment misconfiguration alone cannot expose data cross-tenant; (d) every flag flip writes a WORM flag_flip_audit row (migration 071, lands in PR-2) BEFORE the Flagsmith mutation, providing Article 5(2) accountability evidence; (e) for single-member workspaces, orgId is effectively a pseudonymous identifier of one natural person under Article 4(5) — re-identification requires the Soleur-side organizations join which Flagsmith does not hold. The processing is within the reasonable expectations of any operator-controlled feature-flag substrate, is necessary to achieve Article 32 security-of-processing for cross-tenant capabilities, and does not involve profiling or advertising.
Data processed: pseudonymised identifier (cardinality ≤ 5 at PR-1 merge, per-user pseudonym post-PR-2) + identity traits { role, orgId }. Processed by Bullet Train Limited (Flagsmith) — see Section 2.2.
Data subject rights: under Article 21 GDPR, you may object to processing based on legitimate interest by contacting legal@jikigai.com. Note: under the transient: true posture (post-PR-2), no persistent identity record is created on Flagsmith's side; targeted erasure (Article 17) is therefore not applicable for transient evaluation requests. Transient edge logs at Flagsmith age out per Flagsmith's published retention.
DPIA status: the processing carries low individual risk (pseudonymous identifier; data minimisation; dual-control; WORM audit), so Article 35(1) does NOT trigger a mandatory DPIA. The architecture decision (ADR-043 — drafted in PR-2 of umbrella #4456) documents the per-org segment approach + alternatives considered + why a DPIA is not triggered.

3.10 AI-assisted triage of inbound operational email (ops@soleur.ai)

For the AI-assisted triage of inbound email to the company operational address ops@soleur.ai (Privacy Policy Section 4.13; Article 30 register Processing Activity 27):

Lawful basis: Legitimate interest (Article 6(1)(f) GDPR). Three-part test (full LIA at knowledge-base/legal/legitimate-interest-assessments/2026-06-11-operator-inbox-triage-lia.md):
- Purpose: operate the company's inbound-mail function without silent failure, and meet statutory response clocks (Article 12(3) one calendar month for data-subject requests; Article 33 72 hours for breach notification) deterministically — deadline-bearing mail is detected by fixed rules before any AI model is involved.
- Necessity: the chosen architecture is the least intrusive that achieves the purpose — no mailbox credential exists anywhere (forwarding, not IMAP/OAuth); raw bodies are never persisted (the email_triage_items table has no body column — parse-and-discard is schema-enforced); the durable original remains in the company mailbox already operated under existing disclosures; statutory and synthetic-probe mail never reaches the AI model.
- Balancing: the data subjects are predominantly involuntary (senders to a business address, and persons mentioned in mail). The balancing weighs the business-correspondence expectation that mail to a company operational address is machine-processed, the minimal persisted footprint (summary + envelope metadata only), the bounded and disclosed sub-processor egress (Resend 30 days fixed with no deletion API; Anthropic 30 days default, non-statutory mail only, truncated and sanitized), and the fact that the statutory fast-path directly protects the rights of requesting data subjects. Special-category content may arrive unsolicited; the summarizer is instructed to omit it, and the residual risk that the instruction is not followed is named and accepted in the DPIA screening memo (knowledge-base/legal/audits/2026-06-11-dpia-screening-operator-inbox-triage.md) rather than claimed away.
Article 14(5)(b) information posture: individual notice to each inbound sender would involve disproportionate effort; the information is made publicly available in Privacy Policy Section 4.13 instead.
Data subject rights: Articles 15–21 are exercisable against Jikigai at legal@jikigai.com. Erasure (Article 17) of a triage item runs through an audited, gated deletion path; items recording statutory-clock correspondence may be retained for the accountability period under Article 17(3)(b) (compliance with a legal obligation), applied per-request and documented.
Retention: non-statutory items 365 days; synthetic-probe items 7 days; statutory items per the accountability period; Resend 30 days (vendor-fixed); Anthropic up to 30 days (default).
DPIA status: screening concluded a full DPIA is not required at single-operator scale (no Article 22 effects; no large-scale Article 9 processing); three residual risks are named and accepted with pinned re-screening triggers — see the screening memo above.

3.11 Agent-assisted, human-approved outbound email to professional contacts (outbound.soleur.ai)

For the agent-assisted, human-approval-gated 1:1 outbound cold email used for the founder's outreach, sent from the dedicated subdomain outbound.soleur.ai via Resend — a separate sender-reputation stream that isolates cold-outreach reputation from the soleur.ai apex transactional sender (notifications@soleur.ai); same registrable domain, distinct subdomain — (Privacy Policy Section 4.14; Article 30 register Processing Activity 28). This is the outbound counterpart to Section 3.10 and overturns the send-authority deferral recorded in the 2026-06-11 inbound LIA:

Lawful basis: Legitimate interest (Article 6(1)(f) GDPR; Recital 47). Three-part test (full LIA at knowledge-base/legal/legitimate-interest-assessments/2026-06-15-outbound-email-authority-lia.md):
- Purpose: enable founder-led 1:1 cold outreach to professional contacts at their published professional addresses without operating an uncontrolled send surface — promoting the controller's activities by contacting relevant professionals in their professional capacity (Recital 47), with every send individually human-approved and the volume 1:1, not a campaign blast.
- Necessity: the chosen architecture is the least intrusive that achieves the purpose — a permanent per-send human-approval gate (no auto-send for cold mail, ever); a single compliance chokepoint through which every send must pass (refuse-to-send if any check fails, before any third party receives the mail); the plaintext recipient address and the body are never persisted (only a keyed recipient_hash and body hashes are stored); and a deterministic keyed pseudonym (recipient_hash = HMAC-SHA-256 with a pepper held in the secrets manager) chosen over per-row salting because permanent opt-out matching requires it — a data-subject-protective tradeoff, not a weakening.
- Balancing: the recipients are involuntary third-party data subjects whose contact details were obtained NOT from them (a published professional byline), so the balance is earned by safeguards rather than assumed. It weighs the reasonable expectation of a professional who publishes a contact address that they may receive a single, identified, relevant, opt-out-bearing 1:1 message (CNIL professional-contact prospection guidance; Recital 47), against a low-to-moderate and bounded impact: no profiling, no second message without fresh human approval, permanent opt-out honoured at send time, and a structurally minimal pseudonymised footprint. The decisive safeguard is the permanent per-send human-approval gate.
Article 14 information posture: because the contact details were not obtained from the recipient, Article 14 applies. The required information (identity, purpose, legitimate-interest legal basis, the source of the contact details, retention, and rights) is provided in-line in the body of the first EU/UK communication (the compliance condition the chokepoint validates as six discrete present elements). No reliance on the Article 14(5)(b) disproportionate-effort exemption (contrast Section 3.10) — the first contact is itself an email to the subject, so in-line disclosure is both required and feasible.
Data subject rights: opt-out is the primary, immediate control (each message carries an opt-out line; suppression is permanent and a later send is refused at send time inside the send transaction). Articles 15–21 are exercisable against Jikigai at legal@jikigai.com. Erasure (Article 17) scrubs the keyed recipient pseudonym; the append-only send-audit record may be retained de-identified for the accountability period under Article 17(3)(b) (the same logic as Section 3.10's statutory rows), applied per-request and documented.
Retention: the opt-out set is permanent / monotonic by design (an expiring opt-out would re-expose the data subject); the send-audit record is retained for the accountability period (Article 5(2)); Resend retains sent content 30 days (vendor-fixed, no deletion API). No AI provider is a recipient on the outbound leg.
DPIA status: screened at single-operator scale (no Article 22 effects; no Article 9 processing — every body is human-authored and human-approved, with no unsolicited-arrival channel); the named accepted residual is the channel-level ePrivacy / PECR / CNIL analysis (LIA counsel item), with re-evaluation triggers pinned in the LIA (any move to auto-send, any expansion beyond 1:1 founder-approved outreach, any LLM introduced into the send path).

3.12 Concierge turn summaries (durable per-turn outcome narration)

For the durable, per-turn plain-language turn summary persisted by the Concierge (/soleur:go) conversation runtime on the Web Platform (Privacy Policy Section 4.7; Article 30 register Processing Activity 2, amended — this is not a new processing activity; migration 105 adds the additive, nullable message_kind='turn_summary' discriminator):

What it is: on a turn that completes successfully, the runtime writes one additional assistant-authored message row holding a short plain-language description of what the turn accomplished (for example, "Fixed the side panel layout"). A separate transient live status line shown while the agent works is never stored.
Whose data it is: the summary is agent-authored but is the user's own data — a record of the work the user requested — and is persisted under the user's own user_id. It therefore inherits the conversation row's existing handling in full.
Lawful basis: contract performance (Article 6(1)(b) GDPR) — the same basis as the parent conversation; the summary is part of providing the conversational service the user signed up for.
Recipients / transfers: no new sub-processor, recipient, or third-country transfer — the row is stored in the existing Supabase database (eu-west-1, Ireland) on the existing Hetzner-hosted infrastructure.
Retention and erasure: identical to the parent conversation — retained while the account is active, cascade-deleted on conversation deletion and account deletion (Article 17), and included in the self-serve Article 15 + 20 export. Because the Article 15(4) author-redaction keys on user_id (not message role), the user's own turn summaries are returned un-redacted in their export bundle.
Article 22: this processing involves no automated decision-making producing legal or similarly significant effects on the data subject — it is descriptive narration of work the user requested and makes no decision about the user.
Confidentiality measure (Article 32): the summary text passes through the same redaction and length-cap checks applied to other persisted message content before it is buffered or stored; a residual secret-shape match drops the entire narration (fail-loud). The same redacted string feeds both the persisted summary and the transient live frame, so the live frame is at least as protected as the stored row.

3.13 Owner-private beta-tester / prospect CRM (agent-native capture store)

For the operator's owner-private store of beta-tester / prospect conversations (Privacy Policy Section 4.7; Data Protection Disclosure Section 2.3(ad); Article 30 register Processing Activity 30; migration 126, ADR-102). Here the Web Platform user is the controller and Jikigai is the processor for the third-party personal data recorded:

What it is: three owner-only content tables (RLS keyed on the user's user_id) holding a contact head (beta_contacts), dated dual-lens conversation notes (interview_notes: verbatim body + lens[] in {sales, product}), and an append-only stage-transition history. Written/read on the operator's behalf by the cro/cpo agents via auth.uid()-pinned functions; agent write tools are human-gated.
Data subjects: the beta testers / prospects — involuntary, third-party data subjects → Article 14 applies. No special-category (Article 9) data is solicited.
Lawful basis: Legitimate interest (Article 6(1)(f) GDPR) — full LIA at knowledge-base/legal/legitimate-interest-assessments/2026-07-07-beta-crm-lia.md: routine business-relationship management; owner-only RLS + human-gated writes as the decisive safeguards; low, bounded impact within a professional relationship's reasonable expectation.
Recipients / transfers: record content is transmitted to Anthropic (US) for cro/cpo reasoning — a Chapter V transfer under the existing Anthropic DPA (SCCs Modules 2+3; Section 6). No new sub-processor.
Retention and erasure: 24 months from last_contact via in-database pg_cron. Article 17: whole-store deletion by ON DELETE CASCADE on account deletion; an individual third party's erasure via the auditable service-role-only crm_erase_contact function. Included in the owner's Article 15 + 20 export.
Read-accountability log (Article 5(2)): a further owner-only, append-only table (beta_contact_access_log; migration 127 / #6172, ADR-102 UI phase) records each time the operator opens a contact's full detail in the read-only CRM drawer — metadata only (user_id + contact_id + accessed_at; never a note body). Written atomically inside the crm_get_contact_detail SECURITY DEFINER RPC (fail-closed: no contact PII is returned unless the audit row is written; INSERT only via the RPC), same owner-only RLS + jti-deny posture as the content tables, included in the owner's Article 15 export (access-only — controller-generated, not Article 20-portable), and erased with the contact via the composite-FK ON DELETE CASCADE. No new lawful basis or data subject — inherits the Article 6(1)(f) basis above and the Article 5(2) accountability principle.
Article 22: no automated decision-making producing legal or similarly significant effects.

4. Categories of Personal Data

4.1 Data NOT Collected by Soleur

The Soleur Plugin does not collect, store, or process the following categories of personal data:

Names or physical contact information
Account credentials or authentication tokens
IP addresses or device identifiers
Location data
Financial or payment information
Content generated through the plugin (knowledge-base files, brainstorms, plans, code)

Note: The Docs Site collects email addresses from visitors who voluntarily subscribe to the newsletter (see Section 3.6). This data is processed by Buttondown, not by the Plugin.

4.2 Data That May Be Processed by Third Parties

The following data may be processed by third-party services when users interact with the broader Soleur ecosystem:

Category	Third Party	Purpose
IP address, browser metadata	GitHub (via GitHub Pages)	Hosting documentation site
Prompts, code context	Anthropic (via Claude API)	Powering AI agent responses (user authenticates with own credentials)
GitHub account data	GitHub (via repository)	Issue tracking, contributions
Name, email, inquiry content	Proton AG (via Proton Mail)	Handling legal and GDPR inquiries (legal@jikigai.com)
GitHub username, signature timestamp, PR reference	GitHub (via CLA Assistant)	Recording CLA signature for contributor IP license grants
Email address, IP address, referrer URL, subscription timestamp, browser/device metadata	Buttondown (via newsletter signup)	Managing newsletter subscriptions and delivering newsletter emails
Email address, auth tokens, session data, conversation metadata, message content	Supabase (via Web Platform)	Account management, authentication, and conversation storage
OAuth provider user ID, display name, profile picture URL	Google, Apple, GitHub, Microsoft (via Web Platform OAuth sign-in)	Authentication and account linking (auto-link on verified email)
Customer email, subscription metadata	Stripe (via Web Platform Checkout)	Payment processing (card data handled by Stripe, never reaches Jikigai)
User workspaces, encrypted API keys	Hetzner (via Web Platform hosting)	Infrastructure hosting for workspace environments
IP addresses, request headers	Cloudflare (via `app.soleur.ai` proxy)	CDN/proxy and DDoS protection

Users are responsible for reviewing the privacy policies of these third-party services.

4.3 Website Analytics Data

The Docs Site uses Plausible Analytics (plausible.io), a cookie-free, privacy-respecting analytics service. Plausible collects the following anonymous, aggregated data:

Data Point	Storage	Purpose
Page URL	Aggregated	Understanding which pages are visited
Referrer URL	Aggregated	Understanding how visitors find the site
Country	Derived from IP (IP not stored)	Geographic distribution
Device type	Aggregated	Desktop/mobile/tablet breakdown
Browser and OS	Aggregated	Technical compatibility

What Plausible does NOT collect: IP addresses (discarded after geolocation), cookies, local storage, device fingerprints, cross-site tracking identifiers, or any personally identifiable information.

Legal basis: Legitimate interest (Article 6(1)(f) GDPR). The three-part test is satisfied: (1) understanding documentation traffic patterns is a legitimate interest of the website operator; (2) cookie-free analytics is the least intrusive means -- no personal data is stored, no cross-site tracking, no device fingerprinting; (3) users' rights are not overridden because no identifying information is collected or retained.

ePrivacy Directive: Article 5(3) of the ePrivacy Directive does not apply because Plausible does not store information on or access information from the user's device (no cookies, no local storage).

5. Data Subject Rights

Under the GDPR, data subjects in the EEA have the following rights. For data processed through the Web Platform (app.soleur.ai), these rights are exercisable directly against Jikigai (see Section 5.3). For newsletter subscriptions and CLA signatures, most rights are exercisable against the relevant third-party service providers or by unsubscribing from the newsletter:

5.1 Rights Exercisable Against Third Parties

Right of Access (Article 15): Contact Anthropic or GitHub directly to request access to personal data they hold.
Right to Rectification (Article 16): Contact the relevant third party to correct inaccurate personal data.
Right to Erasure (Article 17): Request deletion of personal data from Anthropic or GitHub under applicable conditions.
Right to Restriction of Processing (Article 18): Request that Anthropic or GitHub restrict processing of your data.
Right to Data Portability (Article 20): Request your data in a portable format from the relevant third party.
Right to Object (Article 21): Object to processing by the relevant third party.

5.2 Rights Exercisable Locally

Right to Erasure of Local Data: Because all Soleur plugin data is stored on your local machine, you have full and immediate control over its deletion. Uninstalling the plugin and deleting the plugin directory removes all associated data.
Right to Access Local Data: All knowledge-base files, plans, brainstorms, and other artifacts are stored as plaintext files on your filesystem and are fully accessible to you at all times.

5.3 Rights Exercisable Against Jikigai (Web Platform)

For data processed through the Web Platform (app.soleur.ai) where Jikigai acts as data controller (see Section 2.1), data subjects may exercise the following rights by contacting legal@jikigai.com:

Right of Access (Article 15): Request confirmation of whether personal data is being processed and obtain a copy of the data (account data, workspace data, conversation data, subscription metadata).
Right to Rectification (Article 16): Request correction of inaccurate personal data held by Jikigai.
Right to Erasure (Article 17): Request deletion of personal data under applicable conditions. Note: payment records (subscription metadata, invoices) subject to French tax law retention (Code de commerce Art. L123-22) may be retained for up to 10 years (see Section 8.4).
Workspace member removal audit ledger — PA-19, distinct from PA-20 above (Articles 15 + 17 + 20, departed Co-Members): The per-workspace WORM ledger workspace_member_removals introduced by migration 062 / PR #4294 (Article 30 register Processing Activity 19) records one row per Co-Member removal event with the departed user's removed_user_id preserved for at least 36 months (shortest-applicable-jurisdiction Article 82(2) limitations floor — see ADR-039 for the retention-rationale derivation). PA-19 is the sibling of PA-20 workspace_member_actions covered immediately above (the broader add/remove/role-change ledger from migration 063 / PR #4231): the two are distinct substrates with distinct retention floors (PA-19 = 36 months, PA-20 = 7 years), distinct anonymisation RPCs, and distinct disclosure surfaces — do not conflate. Article 17 erasure cascade: anonymise_workspace_member_removals(p_user_id) SECURITY DEFINER RPC sets removed_user_id = NULL AND removed_by_user_id = NULL (both PII columns) on every row where either FK matched the departing user; cascade ordering in server/account-delete.ts runs as step 3.905 BEFORE the cascade DELETE at step 3.91 (anonymise_workspace_members), BEFORE step 3.93 (anonymise_workspace_member_actions, PA-20), and BEFORE step 4 (auth.admin.deleteUser); lineage columns id and removed_at are preserved post-erasure unconditionally for Article 5(2) accountability; workspace_id is preserved while the parent workspace exists and may transition to NULL via its ON DELETE SET NULL FK if the parent workspace + organization are themselves deleted at step 3.92 (per ADR-039 §Invariants workspace_id carve-out). WORM trigger bypass mechanism: the workspace_member_removals_no_mutate trigger admits UPDATEs only when lineage columns are unchanged AND PII columns transition NOT NULL → NULL — i.e. structural-shape detection at the trigger body itself, not a GUC bypass. The anonymise RPC does NOT issue SET LOCAL session_replication_role; the column-state transition IS the authorization. This is the post-#4294-review deliberate divergence from mig 037 / mig 051's session_replication_role precedent (per ADR-039 §Invariants and learning 2026-05-18-worm-trigger-bypass-role-check-fails-under-postgrest-routing.md), chosen because pg_cron runs as postgres rather than service_role and would silently fail a role-gated bypass on the retention sweep. Article 15 access (departed Co-Members): because the SECURITY DEFINER is_workspace_member() RLS helper returns false for a user after removal, the standard self-serve DSAR surface at /dashboard/settings/privacy does not expose the row via the workspace's RLS predicate; Article 15 requests grounded on PA-19 are fulfilled via the service-role DSAR worker. The allowlist entry keys on removed_user_id (the owner-of-record for the row) and the export query filters single-arm on .eq("removed_user_id", expectedUserId). A Workspace Owner exercising their own Art. 15 will see rows where THEY were removed but not the rows where they performed removals on others — those belong to the removed user under owner-of-record semantics. Email legal@jikigai.com if you are no longer signed in to the Web Platform. Article 20 portability: the row is included in the self-serve ZIP archive (per-table JSON) and in the email-channel manual export, identically structured to other allowlisted tables. Sub-processors: none new — substrate is internal to the existing Supabase row. PA-19 disclosure is the Article 30(1)(g) recipient-disclosure discharge; see Data Protection Disclosure Section 2.3(v) for the full ledger description and Section 2.3(u) for the parent workspace-membership substrate.
Workspace co-member access to a connected repository and knowledge-base (ADR-044, #4543 / #4558). As of ADR-044 (migrations 079/080/081 relocating GitHub repo-connection state — repo_url, repo_provider, github_installation_id, repo_status, repo_last_synced_at — from the per-user users table to the workspaces table), a workspace's repo connection is workspace-scoped rather than per-user. The consequence for data subjects: joining a workspace as a Co-Member grants access to that workspace's connected GitHub repository AND the knowledge-base derived from it; inviting a Co-Member to your own workspace grants that Co-Member the same access (previously a joined member could not reach the workspace owner's repository — the #4543 brand-survival defect). A Workspace Owner's repository content and repo-derived knowledge-base are therefore processed for the workspace's Co-Members at the workspace-ownership grain. Lawful basis for the Co-Member's processing of the Owner's repo/KB data: the Owner's consent (Article 6(1)(a) GDPR) captured in the migration-058 workspace_member_attestations invite attestation — the inviter attests at invite-time that the invited member will access the workspace's connected repository and knowledge-base — together with the existing legitimate-interest basis (Article 6(1)(f) GDPR) for repo-derived signals (Article 30 register PA-17). Confidentiality measure (Article 32 GDPR): the github_installation_id is a GitHub App token grant (a credential); it is column-level revoked from the authenticated role and readable only via the membership-checked SECURITY DEFINER RPC resolve_workspace_installation_id(p_workspace_id) (non-members receive NULL); repo reads resolve from workspaces only (single source of truth). No new sub-processor — GitHub Inc. (Microsoft Corporation) remains the upstream source already disclosed in Section 2.2; the new recipients are the workspace's own Co-Members already covered by the workspace co-member data category. See Data Protection Disclosure Section 2.3(u), Privacy Policy Section 4.11, Article 30 register Processing Activity 17 sub-clause (c), and ADR-044 (knowledge-base/engineering/architecture/decisions/ADR-044-workspace-repo-ownership.md).
Right to Restriction of Processing (Article 18): Request that Jikigai restrict processing of personal data.
Right to Data Portability (Article 20): Request personal data in a structured, commonly used, machine-readable format.
Right to Object (Article 21): Object to processing of personal data. The legal basis for Web Platform processing is contract performance (Article 6(1)(b)), so this right applies primarily when processing extends beyond strict contractual necessity.

Jikigai will acknowledge requests within 5 business days and respond substantively within one month of receipt, as required by GDPR Article 12(3). This period may be extended by two further months where necessary, taking into account the complexity or volume of requests, in which case we will inform you of the extension and reasons within the initial one-month period.

5.4 Supervisory Authority

Data subjects have the right to lodge a complaint with a supervisory authority in the EU Member State of their habitual residence, place of work, or place of the alleged infringement. A list of EU Data Protection Authorities is available at edpb.europa.eu.

6. International Data Transfers

The Soleur Plugin itself does not transfer personal data internationally. However, users should be aware of the following transfers:

Web Platform (app.soleur.ai):

Supabase: EU-based deployment (AWS eu-west-1, Ireland). No international data transfers. Supabase Inc is US-based, but the Jikigai project is deployed to the EU region. See Supabase DPA.
Stripe: US-based (Stripe, LLC). Transfer via EU-US Data Privacy Framework (DPF, adequacy decision) and Standard Contractual Clauses (SCCs), EEA Module 2. DPA auto-incorporated in Services Agreement (verified 2026-03-19). See Stripe DPA.
Hetzner: EU-based (Germany). Web Platform hosted on Hetzner data centres in the EU, across more than one host — the host serving app.soleur.ai and storing workspace data is in Helsinki, Finland (hel1); a second web host (web-2, never user-serving) is in Falkenstein, Germany (fsn1) — same Hetzner account, same signed AVV, both EU. No international data transfers, no new sub-processor. DPA (AVV) signed 2026-03-19 via Cloud Console. See Section 2.2.
Cloudflare: Global CDN. Transfer via EU-US Data Privacy Framework (DPF), Standard Contractual Clauses (SCCs), and Global CBPR certification. DPA self-executing via Self-Serve Agreement (verified 2026-03-19). See Cloudflare DPA.

Other services:

Anthropic Claude API: API requests may be processed in the United States or other jurisdictions where Anthropic operates. Users should review Anthropic's data processing terms regarding international transfer safeguards.
GitHub Pages / GitHub: GitHub infrastructure is located globally, including in the United States. GitHub (Microsoft Corporation) is certified under the EU-US Data Privacy Framework (adequacy decision C(2023) 4745), which provides the primary transfer mechanism. GitHub also maintains Standard Contractual Clauses as a supplementary safeguard. See GitHub's Global Privacy Practices.
Buttondown (Newsletter): Buttondown is a US-based newsletter platform. Transfers of subscriber data (email addresses, IP addresses, referrer URL, subscription timestamps, browser/device metadata) from the EEA to the United States are governed by the EU Standard Contractual Clauses (European Commission Implementing Decision (EU) 2021/914, Module 2: Controller-to-Processor), incorporated by reference into Buttondown's Data Processing Agreement. Buttondown's DPA applies to all plan tiers, including the free tier. See also Buttondown's Privacy Policy.

Users who are subject to the GDPR and have concerns about international data transfers should review the relevant third-party policies before using these services.

7. Data Security Measures

7.1 Local Security

Because Soleur operates entirely on the user's local machine:

All data remains within the user's filesystem security perimeter.
No data is transmitted to Soleur-controlled servers or cloud storage.
Users are responsible for securing their own devices, including filesystem permissions, disk encryption, and access controls.
API keys (e.g., Anthropic API keys) are managed locally by the user and are never collected or stored by Soleur.

7.2 Recommendations for Users

To maintain data protection when using Soleur, we recommend:

Enabling full-disk encryption on your device.
Using strong access controls for your user account.
Keeping your API keys secure and rotating them periodically.
Reviewing the security practices of third-party services (Anthropic, GitHub) before use.
Not including sensitive personal data of third parties in knowledge-base files unless you have a lawful basis to do so.

8. Data Retention

8.1 Local Data

Soleur does not impose any retention period on locally stored data. Files persist on the user's machine until the user deletes them. Users have full control over the lifecycle of all locally stored artifacts.

8.2 Legal and GDPR Inquiry Correspondence

Personal data contained in data subject rights requests and legal inquiries (names, email addresses, inquiry content) is retained for the duration necessary to resolve the inquiry, plus three years to comply with the French civil statute of limitations (prescription civile). After this period, correspondence is securely deleted.

8.3 Newsletter Subscriber Data

Newsletter subscriber email addresses are retained by Buttondown for as long as the subscriber remains subscribed. Upon unsubscription, the email address is removed from the active subscriber list. Buttondown may retain anonymized aggregate data (e.g., subscriber counts) after unsubscription. Upon termination of the service relationship, Buttondown will, at Jikigai's option, delete or return all personal data in accordance with Buttondown's Data Processing Agreement.

8.4 Web Platform Data

Web Platform account data (email, hashed password, auth tokens) is retained while the account is active and deleted upon account deletion request. Conversation data (messages and conversation metadata) is retained while the account is active and deleted upon account deletion request (cascade delete via foreign key). Encrypted API keys are deleted with the associated workspace. Payment records (subscription metadata, invoices) are retained for 10 years per French tax law (Code de commerce Art. L123-22).

8.5 Third-Party Retention

Retention periods for data held by Anthropic and GitHub are governed by their respective privacy policies and data retention schedules.

9. Data Protection Impact Assessment (DPIA)

Jikigai's data processing now includes both the Docs Site (standard web hosting via GitHub Pages) and the Web Platform (app.soleur.ai). A formal DPIA under Article 35 of the GDPR has been evaluated and is not required for Jikigai's direct operations. The analysis:

The Web Platform processes user PII (email addresses, hashed passwords, authentication tokens, encrypted API keys, subscription metadata, conversation metadata, and message content).
The addition of conversation data (user messages, assistant responses, tool call metadata) as a new PII category does not change the DPIA conclusion. Conversation data does not constitute special categories (Article 9), does not involve systematic monitoring of individuals, and does not involve automated decision-making with legal effects.
This processing does not meet the high-risk thresholds of Article 35(3): (a) no special categories of data (Article 9) are processed, (b) no systematic monitoring of individuals occurs, (c) no automated decision-making with legal effects is performed, and (d) processing is not at a scale that would trigger DPIA requirements for a pre-revenue SaaS with a small user base.
Payment data (card numbers) is handled exclusively by Stripe and never reaches Jikigai servers (PCI SAQ-A).
Infrastructure is hosted in the EU (Hetzner data centres; workspace data in Helsinki, Finland), reducing transfer risk.

This assessment will be revisited if processing activities expand significantly (e.g., large-scale user base, new data categories, automated profiling).

Important for users: If you use Soleur's AI agents to process personal data of third parties (e.g., including personal data in knowledge-base files, feeding personal data to the Anthropic API via agent prompts), you may be required to conduct a DPIA under Article 35. This is your responsibility as the data controller for locally processed data.

10. Record of Processing Activities (Article 30)

Jikigai maintains an internal record of processing activities as required by Article 30(1) of the GDPR. The SME exemption under Article 30(5) does not apply because, although Jikigai has fewer than 250 employees, the documentation site hosting constitutes non-occasional processing (continuous web hosting).

The register documents eleven processing activities:

Documentation website hosting (soleur.ai via GitHub Pages) -- IP addresses, browser metadata of visitors
Website analytics (soleur.ai via Plausible Analytics) -- page URLs, referrer URLs, country (derived from IP, not stored), device type, browser type. Legal basis: legitimate interest (Article 6(1)(f)). No personal data is stored; IP addresses are discarded after geolocation. Plausible Analytics is hosted in the EU.
Source repository management (GitHub) -- contributor profile data, issue reporters
Legal and GDPR inquiry handling (legal@jikigai.com) -- names, email addresses, inquiry content
CLA signature collection (GitHub CLA Assistant) -- GitHub username, signature timestamp, pull request reference. Legal basis: legitimate interest (Article 6(1)(f)). Signature data is stored on the cla-signatures branch in the public repository. Retention is indefinite (irrevocable license grants).
Newsletter subscription management (soleur.ai via Buttondown) -- (a) email addresses of newsletter subscribers, legal basis: consent (Article 6(1)(a)), verified through double opt-in; (b) IP address, referrer URL, subscription timestamp, and browser/device metadata automatically collected during subscription, legal basis: legitimate interest (Article 6(1)(f)) for service operation and abuse prevention. Data is processed by Buttondown (US-based). International transfers governed by EU Standard Contractual Clauses (Implementing Decision (EU) 2021/914, Module 2: Controller-to-Processor), incorporated into Buttondown's DPA. DPA applies to all plan tiers including free. Buttondown's sub-processor list is maintained at buttondown.com/legal/subprocessors. Email retention: until the subscriber unsubscribes. Technical metadata retention: governed by Buttondown's data retention practices.
Web Platform account management (app.soleur.ai via Supabase) -- email addresses, hashed passwords (managed by Supabase), authentication tokens (JWT), session data. Legal basis: contract performance (Article 6(1)(b)). Data is processed by Supabase Inc (US-based company; project deployed to AWS eu-west-1, Ireland, EU -- no international data transfer). Retention: while account is active; deleted on account deletion request.
Web Platform payment processing (app.soleur.ai via Stripe Checkout) -- customer email, subscription metadata. Card data is processed exclusively by Stripe (PCI DSS Level 1, SAQ-A integration) and never reaches Jikigai servers. Legal basis: contract performance (Article 6(1)(b)). Data is processed by Stripe Inc (US-based, DPF + SCCs). Retention: subscription records retained for 10 years per French tax law (Code de commerce Art. L123-22).
Web Platform infrastructure hosting (app.soleur.ai via Hetzner, EU -- served from Helsinki, Finland) -- user workspaces, encrypted API keys (AES-256-GCM), Docker containers. Legal basis: contract performance (Article 6(1)(b)). Data is processed by Hetzner Online GmbH (EU-based, no international transfer). Retention: while account is active.
Web Platform conversation management (app.soleur.ai via Supabase) -- conversation metadata (domain leader, status, timestamps), message content (user messages, assistant responses, tool call metadata), and -- when usage telemetry is enabled per operator configuration -- per-message usage jsonb (token consumption and cost metadata). Legal basis: contract performance (Article 6(1)(b)). Data is processed by Supabase Inc (project deployed to AWS eu-west-1, Ireland, EU -- no international data transfer). Retention: while account is active; deleted on account deletion request. Notes: in rare service-interruption cases (kernel-level process termination or container restart) between generation and persistence, a small portion of an in-progress reply may not be retained in the conversation record (see Privacy Policy Section 4.7).

Web Platform content sharing (app.soleur.ai via Supabase) -- share link metadata (document ID, sharing user ID, creation timestamp, share token) for authenticated users who activate document sharing; server access logs (IP address, timestamp, user-agent) for unauthenticated viewers accessing shared URLs. Legal basis: contract performance (Article 6(1)(b)) for share link records; legitimate interest (Article 6(1)(f)) for viewer access logs. No cookies are set for viewers; shared pages include noindex meta tags. Retention: share link records retained while active, deleted on revocation or account deletion; access logs per Cloudflare and Hetzner retention policies.

The register is maintained internally and is available on request to the competent supervisory authority (CNIL for France). Since the 2018 reform of the Loi Informatique et Libertes, no registration or prior declaration to the CNIL is required.

11. Data Breach Notification

11.1 Controller Obligations

In the event of a personal data breach affecting data for which Jikigai acts as controller, Jikigai will:

Notify the competent supervisory authority (CNIL) without undue delay and, where feasible, within 72 hours of becoming aware of the breach, as required by Article 33 GDPR, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons.
Where the breach is likely to result in a high risk to the rights and freedoms of natural persons, notify the affected data subjects without undue delay, as required by Article 34 GDPR.

11.2 Practical Context

The most likely breach scenarios include: (a) unauthorized access to the Supabase database (user account data), (b) compromise of the Hetzner server (workspace data, encrypted API keys), (c) unauthorized access to Proton AG (Proton Mail, handling legal@jikigai.com), (d) a compromise of the GitHub organization, or (e) unauthorized access to conversation history stored in the Supabase database (user messages, assistant responses). In all cases, the third-party provider would typically be the first to detect and communicate the breach. Jikigai would assess the impact on Web Platform user data and notify affected users as required by Articles 33-34.

12. Children's Data

Soleur is designed for professional use by solo founders and technical builders. It is not directed at children under the age of 16. We do not knowingly collect personal data from children. The only personal data collected by the Docs Site is email addresses voluntarily provided by newsletter subscribers, and no specific age-verification mechanism is implemented for this collection beyond the double opt-in confirmation process.

13. Changes to This Policy

We may update this GDPR Policy from time to time to reflect changes in our practices, third-party services, or applicable law. Updates will be published in the Soleur GitHub repository at github.com/jikig-ai/soleur and, where significant, noted in the project changelog.

We encourage users to review this policy periodically.

14. Contact Information

For questions about this GDPR Policy or data protection matters:

Email: legal@jikigai.com
GitHub Repository: github.com/jikig-ai/soleur (open an issue)
Website: soleur.ai
GDPR / Data Protection Inquiries: legal@jikigai.com (include "GDPR" in the subject line)

To exercise your data subject rights under GDPR, send a written request to legal@jikigai.com. We will acknowledge your request within 5 business days and respond substantively within one month of receipt, as required by GDPR Article 12(3). This period may be extended by two further months where necessary, taking into account the complexity or volume of requests, in which case we will inform you of the extension and reasons within the initial one-month period.

Soleur is a source-available project maintained by Jikigai, a company incorporated in France, with its registered office at 25 rue de Ponthieu, 75008 Paris, France.

Jikigai's data processing (standard web hosting, community repository interactions, and Web Platform account/payment/workspace management) does not meet the thresholds requiring a Data Protection Officer (DPO) under Article 37 of the GDPR: the processing is not core business activity involving regular and systematic monitoring of data subjects at large scale, nor does it involve large-scale processing of special categories of data. The Web Platform processes user account data but at a scale consistent with a pre-revenue SaaS and does not involve profiling or monitoring. Accordingly, no DPO has been appointed. Should this assessment change (e.g., significant user base growth), DPO contact information will be added to this policy.

15. Governing Law

This GDPR Policy shall be governed by and construed in accordance with the laws of France, without regard to its conflict of laws provisions. Any disputes arising under or in connection with this Policy shall be subject to the exclusive jurisdiction of the courts of Paris, France. If you are a consumer in the EU/EEA, nothing in this Policy affects your rights under mandatory EU or member state consumer protection laws, including your right to bring proceedings in the courts of your country of habitual residence.

Related documents: This GDPR Policy should be read alongside the companion Privacy Policy for broader privacy disclosures, the Cookie Policy for information about cookies used by the documentation site, and the Individual CLA and Corporate CLA for contributor license terms.