GDPR Policy

Effective February 20, 2026 | Last Updated June 8, 2026

Soleur -- Company-as-a-Service Platform

Effective Date: February 20, 2026 Last Updated: 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 in Helsinki, Finland (EU) -- no international data transfers. DPA (AVV) concluded via the Hetzner Cloud Console (signed 2026-03-19).
  • 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 [email protected], 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 [email protected].

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 Helsinki, Finland (EU-only).
  • 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 [email protected]; 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).

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 [email protected].

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 [email protected]. 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.

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 ([email protected])
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 [email protected]:

  • 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 [email protected] 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 in Helsinki, Finland (EU). No international data transfers. DPA (AVV) signed 2026-03-19 via Cloud Console.
  • 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 (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:

  1. Documentation website hosting (soleur.ai via GitHub Pages) -- IP addresses, browser metadata of visitors
  2. 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.
  3. Source repository management (GitHub) -- contributor profile data, issue reporters
  4. Legal and GDPR inquiry handling ([email protected]) -- names, email addresses, inquiry content
  5. 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).
  6. 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.
  7. 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.
  8. 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).
  9. Web Platform infrastructure hosting (app.soleur.ai via Hetzner (Helsinki, Finland, EU)) -- 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.
  10. 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).
  1. 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 [email protected]), (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:

To exercise your data subject rights under GDPR, send a written request to [email protected]. 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.

Stay in the loop

Monthly updates about Soleur — new agents, skills, and what we're building next.