Data inventory ​
Status: updated 2026-10-14 (hosted edition operations and billing) and 2026-10-13 (Bitbucket, Gitea, Forgejo and release hardening); earlier updates added GitLab, Azure DevOps and work trackers and consolidated the baseline inventory. Source for the records of processing activities, the DPIA templates and the personal-data registry used by quavon dsar. Legal bases are proposals for review by the controller's DPO.
Default tenant retention (tenants.data_retention_days) is 90 days unless the tenant changes it.
Identity and access ​
| Data | Table / store | Personal data | Purpose | Retention (default) | Proposed legal basis |
|---|---|---|---|---|---|
User identity (provider github or oidc, host or issuer, external id, login, name) | users | Yes | Sign-in, authorisation, audit attribution | Until removed by an instance admin or a DSAR deletion | Art. 6(1)(b)/(f) GDPR |
| Sessions (hashed tokens, encrypted GitHub token; for OIDC: identity provider id and IdP group names, no provider token) | auth_sessions (incl. idp_groups, identity_provider_id) | Yes | Authentication; per-request OIDC grants | Until expiry (≤ 8 h), purged daily; deleted with the identity provider | Art. 6(1)(b)/(f) |
| MCP access tokens (owner, name, SHA-256 hash, last four characters, scopes, expiry, last use, revocation time and revoking actor; for OIDC users: identity provider id and IdP group snapshot) | mcp_tokens | Yes (user_id, deleted on erasure; revoked_by, anonymised on erasure) | Authenticating coding agents on /mcp for one tenant (ADR-0018) | Until the owner or a tenant admin revokes it or the user is deleted; expired and revoked tokens stay listed as history | Art. 6(1)(b)/(f) |
| Tenant and repository roles | tenant_memberships, repo_memberships | Yes | Authorisation (cache for OIDC users, refreshed at sign-in) | Refreshed at sign-in; removed when access ends | Art. 6(1)(f) |
| Identity providers (issuer, client id, encrypted client secret, claims configuration, creating admin) | identity_providers | Minimal (created_by) | OIDC sign-in configuration | Until deleted by an instance admin | Art. 6(1)(f) |
| OIDC group-to-role mappings (group name, roles, creating admin) | oidc_role_mappings | Minimal (created_by; group names can name people in rare cases) | Authorisation for OIDC users | Until deleted by a tenant admin; deleted with the provider or repository | Art. 6(1)(f) |
| Setup / break-glass tokens (hashed) | setup_tokens | No | Bootstrap and recovery | Purged 1 day after expiry or use | — |
| Pre-login state (state, nonce, PKCE verifier) | Valkey quavon:login:* | No | OIDC and GitHub login flow | ≤ 10 min | — |
Repository events and content ​
| Data | Table / store | Personal data | Purpose | Retention (default) | Proposed legal basis |
|---|---|---|---|---|---|
| Installations and repositories (account login, repository names, visibility) | installations, repositories | Minimal (account login of a personal account) | Connecting repositories | Until uninstalled or removed | Art. 6(1)(f) |
| People seen in events (provider id, login) | people | Yes | Linking PRs/issues to authors | Tenant retention | Art. 6(1)(f) |
| Webhook payloads | webhook_deliveries.payload | Yes (logins, text) | Processing and redelivery | 14 days, then payload removed (row kept for idempotency) | Art. 6(1)(f) |
| PR/issue metadata (title, state, author, opened/closed/merged times) | pull_requests, issues, pr_revisions | Indirect | Review, triage, analytics | Tenant retention | Art. 6(1)(f) |
| Issue and PR text (body ≤ 64 KiB, labels, author association) | issues, pull_requests | Possibly (free text) | Triage, duplicate search, grounded replies | Tenant retention; deleted with the issue or repository | Art. 6(1)(f) |
| Issue, PR and review comments (body ≤ 64 KiB, author, association) | issue_comments | Yes (free text, logins) | Replies, chat commands, duplicate search | Tenant retention; deleted with the comment, issue or repository | Art. 6(1)(f) |
| Repository labels | repo_labels | No | Triage label allowlist | Refreshed from GitHub | — |
Tenant rules and learnings (text, globs, creating user; for learnings from replies or the learn command also the PR number, comment id, finding fingerprint, the author's code-host login and the deciding maintainer) | rules | Minimal (created_by, decided_by, source_login; source_login cleared on erasure), possibly in the learning text | Custom review rules and team learnings | Until deleted; proposals until activated or rejected | Art. 6(1)(f) |
Code index (ADR-0017) ​
Only when a repository's features.index.mode is not off (default off). The index is a derived cache of repository content, not personal data by registry, and is not subject to data_retention_days (D7). Content is stored in plaintext; at-rest protection is volume or disk encryption (D6). The tables have no person columns; DSAR export and delete do not cover them (content, not attributable to a subject).
| Data | Table / store | Personal data | Purpose | Retention (default) | Proposed legal basis |
|---|---|---|---|---|---|
| Index snapshots (default-branch commit, status, counts, embedding model, error code) | code_index_snapshots | No | Which commit is indexed; status page | Two ready snapshots per repository; deleted when the mode is off, with the repository or the tenant | Art. 6(1)(f) |
| File manifest (path, blob SHA, language, size per snapshot) | code_index_files | Possibly (paths can contain names) | Mapping blobs to paths | As snapshots | Art. 6(1)(f) |
| Indexed blobs (blob SHA, language, size, chunk count) | code_blobs | No | Incremental indexing, storage cap | Until no snapshot references them (garbage collected after each build); deleted when the mode is off, with the repository or the tenant | Art. 6(1)(f) |
| Code chunks (source text of up to 4 000 characters, lines, definition name, identifier terms, full-text vector) | code_chunks | Possibly (names, e-mail addresses or other data in source code and comments) | Related code and usages in reviews | As blobs | Art. 6(1)(f) |
| Definitions (name, kind, lines) | code_symbols | No | Definition lookup | As blobs | Art. 6(1)(f) |
| Embeddings (model, dimensions, vector) | code_chunk_embeddings | Possibly (derived from code chunks) | Semantic search (hybrid mode) | As chunks; rows of a replaced model are removed once the new model covers the snapshot | Art. 6(1)(f) |
| Repository links and pattern repositories (source repository or none for a pattern repository, target repository, creating admin) | repository_links | Minimal (created_by, anonymised on erasure) | Cross-repository context in reviews | Until removed by a tenant admin; deleted with either repository or the tenant | Art. 6(1)(f) |
Review, triage, replies, fixes ​
| Data | Table / store | Personal data | Purpose | Retention (default) | Proposed legal basis |
|---|---|---|---|---|---|
| Review runs (SHAs, mode, decision, summary, generated pull request description and title, statistics, cost) | review_runs | Indirect | Review results, analytics | Tenant retention | Art. 6(1)(f) |
| Review findings (path, lines, rationale, suggested replacement and the replaced lines, each at most 20,000 characters) | findings | Possibly (code) | Review results, suggestion diffs in the dashboard | Deleted with the pull request or repository | Art. 6(1)(f) |
| Posted comments (external ids, fingerprints, state) | posted_comments | Indirect | Reconcile, feedback | Tenant retention | Art. 6(1)(f) |
| Pending outputs for approval (preview, deciding user) | pending_outputs | Yes (decided_by), possibly in preview text | Approval workflow | Tenant retention; expire when undecided | Art. 6(1)(f) |
| Publish intents (idempotency key, target, result) | publish_intents | Indirect | Exactly-once publishing | Tenant retention | Art. 6(1)(f) |
| Deterministic scanner results (tool, rule, path, lines, message) | sast_runs, sast_findings | No | Review findings, optional code-scanning upload | Tenant retention; deleted with the repository | Art. 6(1)(f) |
| Triage results, reply drafts, chat command log, finding suppressions | triage_runs, reply_drafts, chat_commands, finding_suppressions | Indirect (logins in chat log and suppressions) | Triage, replies, audit of commands | Tenant retention | Art. 6(1)(f) |
| Sandbox runs (purpose, image digest, limits, status, byte counts; no output) | sandbox_runs | No | Operating and auditing the sandbox | Tenant retention | Art. 6(1)(f) |
Repository snapshots for sandbox jobs (gzip tar of the work tree, no .git, AES-256-GCM per blob) | Valkey quavon-sandbox:blob:* | Possibly (code) | Scanners and fix tests | Deleted after the job; TTL ≤ 15 min | Art. 6(1)(f) |
| Fix runs (trigger login, plan, patch, test output tails ≤ 8 KiB, summary, review run and finding ids of review fixes) | fix_runs | Yes (trigger login), possibly in code | Issue→Draft PR, review fixes, approvals, audit | Tenant retention; deleted with the repository | Art. 6(1)(f) |
| Acceptance-criteria checks (criteria text, statuses, evidence) | ac_checks | Possibly (issue text excerpts) | AC check in reviews | Tenant retention; deleted with the repository | Art. 6(1)(f) |
| Dry runs (count, status, starting user, policy and prompt version, cost) | dry_runs | Minimal (requested_by, anonymised on erasure) | Trying reviews on past pull requests | Tenant retention; deleted with the repository | Art. 6(1)(f) |
| Dry run results per pull request (number, title, author login, SHAs, findings, cost) | dry_run_items | Yes (pr_author_login, anonymised on erasure), possibly in code | Comparing CodeLotse findings with human reviews | Tenant retention; deleted with the dry run | Art. 6(1)(f) |
| Human review comments of dry-run pull requests (path, line, author login, body ≤ 1,000 characters; never sent to a model) | dry_run_comments | Yes (free text, logins; deleted on erasure) | Showing human comments next to the findings | Tenant retention; deleted with the dry run | Art. 6(1)(f) |
| CI failure analyses (pull request number, head SHA, failed check names and links, verified causes with path, line and suggestion, mode, decision, confidence, cost; never the raw log, log excerpts are redacted and not stored) | ci_analyses | No (CI output may quote code or test names) | Explaining failed checks, approvals and audit | Tenant retention; deleted with the repository | Art. 6(1)(f) |
Learning and assignment ​
| Data | Table / store | Personal data | Purpose | Retention (default) | Proposed legal basis |
|---|---|---|---|---|---|
| Feedback events (finding outcome, labels kept/removed, reassignment factor values; no free text) | feedback_events | Indirect | Per-repository learning, analytics | 6 months | Art. 6(1)(f) |
| Suppression proposals and calibration (deciding maintainer, counts) | suppression_rules, calibration_params | Minimal (decided_by) | Noise reduction | Expire (default 90 days) / recomputed | Art. 6(1)(f) |
| Assignment records (target, requested/effective mode, selected people, explanation facts, factor values of the selected people, outcome) | assignments | Yes | Reviewer/assignee suggestions, audit of applied assignments (ADR-0014) | 6 months (tenant-configurable, shorter in works-council mode) | Art. 6(1)(b)/(f) |
| Per-path code familiarity (decayed commit/review values, last commit and last review time, blame share per path and person; no per-person totals) | expertise_cache | Yes | Expertise-aware assignment | Recomputed, not historised; rows outside the lookback window and of opted-out people deleted | Art. 6(1)(f) |
| Availability intervals (from/to only, manual or ICS-derived) and encrypted ICS feed URL | availability, availability_feeds | Yes | Skip people who are away (opt-in) | 30 days after the interval ends; feed until removed by the person | Art. 6(1)(f), opt-in |
| Assignment and analytics privacy flags (opt-out, availability opt-in, working hours, analytics self-view opt-in) | people | Yes | Honour objections and preferences | Until changed by the person | Art. 21 GDPR (objection); opt-in |
| Assignment legal sign-off (outcome, permitted modes, document reference) | assignment_legal_sign_offs | Minimal (recording admin) | Gate for leaving shadow mode | Append-only | Art. 6(1)(c)/(f) |
Analytics and costs ​
| Data | Table / store | Personal data | Purpose | Retention (default) | Proposed legal basis |
|---|---|---|---|---|---|
| Daily rollups (numerator/denominator per repository, day, metric, dimension; no person dimension) | analytics_daily | No (aggregates; populations computed at query time and never stored or returned) | Team analytics | Tenant retention | Art. 6(1)(f) |
| Analytics teams (name, repositories, creating admin) | analytics_teams, analytics_team_repositories | Minimal (created_by) | Grouping repositories | Until deleted | Art. 6(1)(f) |
| Budget alerts (scope, period, threshold, spent and cap, acknowledging admin) | budget_alerts | Minimal (acknowledged_by) | Cost control | Tenant retention | Art. 6(1)(f) |
| Analytics settings (k, self view switch, thresholds) | tenant_settings.settings.analytics | No | Configuration | Until changed | — |
Code hosts and work trackers ​
| Data | Table / store | Personal data | Purpose | Retention (default) | Proposed legal basis |
|---|---|---|---|---|---|
| GitLab/Azure DevOps connections (host, scope, encrypted token or Entra client secret and webhook secret, 4-character hint, status, last error, creating admin) | provider_connections | Minimal (created_by, anonymised on erasure) | Connecting GitLab and Azure DevOps | Until deleted by a tenant admin | Art. 6(1)(f) |
| Code-host account of the connection token | provider_connections.bot_login, bot_external_id | Yes (login) | Recognising the bot's own comments | While the connection exists; removed on delete | Art. 6(1)(f) |
| GitLab and Azure DevOps webhook payloads (user names, e-mail addresses as sent by the host) | webhook_deliveries.payload (with connection_id) | Yes | Processing and redelivery | As for webhook payloads (14 days) | Art. 6(1)(f) |
| People seen on GitLab and Azure DevOps (host user id, login, display name) | people, expertise_cache (provider gitlab/azure) | Yes | Linking PRs/issues to authors, assignment | As for people and expertise rows | Art. 6(1)(f) |
Bitbucket, Gitea and Forgejo connections (kinds bitbucket, bitbucket-dc, gitea, forgejo: encrypted access token and webhook secret) | provider_connections.encrypted_credentials | No (secret, encrypted) | Connecting Bitbucket Cloud, Bitbucket Data Center, Gitea and Forgejo | Deleted with the connection | Art. 6(1)(f) |
| Token user of Bitbucket Data Center, Gitea and Forgejo connections (null for Bitbucket Cloud) | provider_connections.bot_login, bot_external_id | Yes (login) | Recognising the bot's own comments | Removed on delete | Art. 6(1)(f) |
| Bitbucket, Gitea and Forgejo webhook payloads (Bitbucket account ids, nicknames, display names; Data Center user names and e-mail addresses; Gitea/Forgejo logins and e-mail addresses in user and commit objects) | webhook_deliveries.payload (with connection_id) | Yes | Processing and redelivery | As for webhook payloads (14 days) | Art. 6(1)(f) |
| People seen on Bitbucket, Gitea and Forgejo (host user id, Bitbucket uuid, login; Bitbucket Data Center commit authors keyed by e-mail address) | people, expertise_cache (provider bitbucket, bitbucket-dc, gitea, forgejo) | Yes | Linking PRs/issues to authors, assignment | As for people and expertise rows | Art. 6(1)(f) |
| Tracker connections (kind, base URL, encrypted credentials incl. the account e-mail of Jira API-token connections, hint, encrypted webhook secret, settings with project keys, label and status names, last error, creating admin) | tracker_connections | Minimal (created_by, anonymised on erasure; e-mail only inside the encrypted credentials) | Connecting Jira, Linear and Azure Boards | Until deleted by a tenant admin | Art. 6(1)(f) |
| Linked ticket snapshots (key, URL, title, description, acceptance criteria, status, labels, components, update time) | tracker_issues | Possibly (free text; not searched by DSAR, like issue bodies) | Acceptance check, sync | Deleted with the connection | Art. 6(1)(f) |
| Tracker links and sync state (issue/PR number ↔ ticket key, source, label and status values, timestamps) | tracker_links | No | Bidirectional sync, loop prevention | Deleted with the connection or repository | — |
| Tracker deliveries (delivery id and status only, payload never stored) | webhook_deliveries (provider jira, linear, azure-boards) | No | Idempotency | As for webhook deliveries | — |
| Tracker write intents (label/status names, link comment, title and description of tickets created from repository issues) | publish_intents | Possibly (free text) | Exactly-once tracker writes | As for publish intents | Art. 6(1)(f) |
Tracker audit entries (tracker_connection.* with admin actor, tracker.* and publish.blocked_secret with actor publisher) | audit_log | Minimal (admin actor) | Accountability | As for the audit log | Art. 6(1)(c)/(f) |
| Jira OAuth state (tenant, connection, starting admin) | Valkey | Minimal (admin actor id) | OAuth 3LO flow | ≤ 10 min, single use | Art. 6(1)(f) |
| Notification channels (kind, name, encrypted webhook URL and signing secret, target hint, subscribed events, e-mail recipients, enabled flag, last test and digest time, creating admin) | notification_channels | Yes (recipients: e-mail addresses entered by an admin, not searchable by person; created_by, anonymised on erasure) | Sending notifications to Slack, Microsoft Teams, e-mail and webhooks | Until edited or deleted by a tenant admin | Art. 6(1)(f) |
| Notification deliveries (event, de-duplication key, status, attempts, last error without URLs, summary with repository, pull request number and title, counts or budget amounts, code-host link) | notification_deliveries | Possibly (pull request titles) | Exactly-once delivery, delivery history | Tenant retention; deleted with the channel | Art. 6(1)(f) |
| MCP servers (name, URL, encrypted credential, credential hint, allowlisted tool definitions, enabled flag, acknowledging and creating admin, last discovery and error code) | mcp_servers | Minimal (created_by and acknowledged_by, anonymised on erasure) | External review context from MCP servers (mcp-context.md) | Until deleted by a tenant admin | Art. 6(1)(f) |
| MCP tool calls (server, review run, tool name, status, duration, request and response size, SHA-256 of the arguments; never arguments or results) | mcp_tool_calls | No | Call history for admins, budgets, metrics | Tenant retention; deleted with the server or the review run | — |
| MCP search terms and results during a review (sent to the tenant's MCP servers, results wrapped as untrusted data) | Not stored (encrypted debug prompt logs only when the tenant enables them) | Possibly (free text from pull requests and the external system) | External review context | Not stored; prompt logs for their TTL | Art. 6(1)(f) |
Operations ​
| Data | Table / store | Personal data | Purpose | Retention (default) | Proposed legal basis |
|---|---|---|---|---|---|
| Tenant and instance settings | tenants, tenant_settings, instance_settings, repo_policies | Minimal (transparency contact text, if a tenant enters a person) | Configuration | Until changed | Art. 6(1)(f) |
| Product telemetry state (mode, random instance id, preview payload, last sent time and status) | instance_settings key telemetry.product (enabling admin stored as enabledBy actor) | No (bucketed counts and feature modes only; instance id is random and deleted at opt-out) | Opt-in product statistics (self-hosted only) | Preview rebuilt daily; instance id deleted at opt-out | — (no personal data) |
| Outbox jobs (ids only) | outbox | Indirect | Reliable job delivery | 7 days after dispatch | Art. 6(1)(f) |
| LLM usage records (no prompts by default) | llm_calls | No | Cost accounting, budgets, analytics | tenants.data_retention_days | Art. 6(1)(f) |
| LLM prompt logs (debug opt-in, redacted, encrypted) | llm_prompt_logs | Possibly (code, PR text) | Debugging model behaviour | Tenant-set TTL ≤ 7 days, purged daily | Art. 6(1)(f) |
| Evaluation runs (metrics only) | eval_runs | No | Quality gates, eval history | Until deleted | — |
| Audit log (actor login, action, target, IP; DSAR entries hold a hash of the subject) | audit_log | Yes | Security, accountability | Append-only; retention and pseudonymisation open (counsel) | Art. 6(1)(c)/(f) |
| GitHub App and LLM credentials | provider_apps, llm_credentials, provider_credentials | No | Integrations | Until deleted | — |
| Installation tokens, ETag cache, rate-limit and budget counters, membership cache | Valkey (quavon:*; tokens encrypted) | Minimal (user ids in membership cache keys) | GitHub API access, rate limiting | ≤ 1 h | Art. 6(1)(f) |
| Application logs, metrics and traces | stdout / OTLP backend (Prometheus, Jaeger) | Minimal (ids, no bodies or tokens; metrics carry no tenant, repository or person attributes) | Operations | Operator-defined | Art. 6(1)(f) |
| Pilot reports and default-enable reports | stdout, eval-results/default-enable-<date>.{md,json} written by quavon pilot | No (team and tenant aggregates; cells with fewer than k authors are suppressed; no logins or person ids) | Pilot evaluation, default-enable decisions | Operator-defined | Art. 6(1)(f) |
Release metadata (release notes, versions.json, SBOMs) | Release artefacts, dist/release/ in a dry run | No (commit subject lines only; author names, bodies and trailers are not copied) | Release management, CRA SBOM duty | Kept with the release | — |
Hosted edition ​
Only with QUAVON_EDITION=enterprise. A self-hosted instance has none of these tables filled, none of these stores and sends nothing to Mollie, VIES or an SMTP server. Tenant hard delete keeps audit_log, saas_tenants, billing_accounts and invoices (see the tenant deletion section of the hosted edition's operations runbook, not part of this repository); the hourly billing cycle deletes the kept invoices and billing_accounts rows once the configurable retention period (retention.invoiceYears) has passed (see the tenant deletion section of the hosted edition's billing documentation, not part of this repository).
| Data | Table / store | Personal data | Purpose | Retention (default) | Proposed legal basis |
|---|---|---|---|---|---|
| Hosted tenant lifecycle (status, owner user, owner email, verification time, email token hash and expiry, claim and deletion times, deleting admin) | saas_tenants | Yes (owner email, owner user id, admin actor) | Contract contact, sign-up, deletion | Owner data erased at tenant deletion; tombstone kept | Art. 6(1)(b) |
| Agreement acceptances (organisation, document, version, SHA-256 of the accepted text, accepting user and actor, time) | agreement_acceptances; audit saas.agreement.accepted | Yes (accepting user id and actor) | Proof that the terms of sale and the data processing agreement (Art. 28(9) GDPR) were concluded | Kept at tenant deletion; deleted by the billing cycle with the billing account once the retention period (retention.invoiceYears, default 8 years) after the hard delete has passed. The application role cannot change rows | Art. 6(1)(b), (c) and (f) |
| Support access grants (requesting operator user and actor, reason, duration, deciding admin, times) | support_access_grants | Yes (actors) | Accountability for operator access | Deleted with the tenant | Art. 6(1)(c)/(f) |
| Support reads | audit_log (support_access.read) | Minimal (operator actor) | Accountability | As for the audit log | Art. 6(1)(c)/(f) |
| Hosted settings (shared app id, SMTP host, user and sender, encrypted SMTP password, status webhook URL and encrypted secret) | saas_settings | No | Operations | Until changed | — |
| Verification emails (owner address, link) | Quavon's own SMTP server (EU) | Yes (email) | Owner verification | Mail server logs per Quavon's own operations policy (to define) | Art. 6(1)(b) |
| Grace reminder emails (invoice email of the billing account, read-only date, payment link) | Quavon's own SMTP server (EU) | Possibly (invoice email of a person) | Payment reminders on days 0, 7 and 12 after a failed payment | Mail server logs per Quavon's own operations policy (to define) | Art. 6(1)(b) |
| Status state (overall state, incident id) | Valkey quavon:saas:status | No | Incident webhooks | Until the next change | — |
| Tenant export files | Downloaded by the tenant admin, not stored | Yes (all tenant data) | Portability, exit | Not stored by Quavon | Art. 6(1)(b), Art. 20 GDPR |
| Model key verification time | llm_credentials.verified_at | No | BYOK gate | With the key | — |
| Billing details (company name, invoice email, address, country, VAT ID or tax number, VIES result, time and consultation number, Mollie customer and mandate ids) | billing_accounts | Possibly (invoice email, names of sole traders) | Invoicing, tax compliance, payment collection | While the customer relationship lasts; kept at tenant deletion; then deleted automatically once no invoice row is left, the mandate is revoked and 8 years (configurable) have passed after the end of the calendar year of the hard delete; the 8 years are pending confirmation by Quavon's tax adviser | Art. 6(1)(b), (c) |
| Subscription state (plan, interval, status, periods, seats, scheduled changes, checkout payment id) | subscriptions | No | Billing | Deleted with the tenant | Art. 6(1)(b) |
| Usage rollups (seats, review runs, tokens per month) | usage_records | No (counts) | Limits, invoicing, export | Deleted with the tenant | Art. 6(1)(b) |
| Invoice metadata (Mollie ids, number, amounts, VAT treatment, PDF and payment links) | invoices; invoice PDFs at Mollie | Indirect (recipient data in the Mollie PDF) | Invoicing | Kept at tenant deletion; then deleted automatically 8 years (configurable) after the end of the calendar year in which the row was created; the 8 years follow the 2025 German change from 10 to 8 years and are pending confirmation by Quavon's tax adviser. Mollie keeps its own copies under its terms | Art. 6(1)(c) |
| Mollie webhook dedupe (object id, status) | billing_events | No | Idempotency | Until deleted (no retention job yet) | — |
| Public sandbox progress (rounded percent, reached) | public_metrics, Valkey quavon:public:sandbox-progress | No | Marketing progress bar | Overwritten; cache 1 h | — |
| Operator overview (instance-wide counts of signed-in and active users, review, triage and model runs, review durations, outbox age; per tenant: name, lifecycle and subscription status, plan, seats, review runs this month) | Computed on request from users, auth_sessions, review_runs, triage_runs, llm_calls, outbox, saas_tenants, tenants, subscriptions, usage_records under the system operation saas.operator_stats; not stored | Minimal (user counts are instance-wide and shown only from 5 users upward; no logins, emails, person, repository or content data; the tenant name can be a personal GitHub account when the app is installed on a user account; per-tenant figures are billing and contract data) | Operating and capacity planning of the hosted service (DPA clause 3.5); billing overview | Not stored; each view audited as saas.operator_overview.read | Art. 6(1)(b)/(f) |
| Seat list (provider, login of active people) | Computed on request from people, pull_requests, issues | Yes (login) | Seat count transparency for admins | Not stored | Art. 6(1)(b)/(f) |
| Billing outbox jobs (tenant id, metric, Mollie object ids) | outbox | No | Reliable jobs | 7 days after dispatch | — |
Billing audit entries (billing.account.update, billing.checkout.start, billing.subscription.*) | audit_log | Minimal (admin actor) | Accountability | As for the audit log | Art. 6(1)(c)/(f) |
Reminder, mandate-revocation and purge records (billing.grace_reminder.sent, billing.mandate.revoked, billing.retention.purged) | audit_log | No (system actor, ids, counts) | Idempotency, accountability | As for the audit log | Art. 6(1)(c)/(f) |
Deletion cancellation (saas.tenant.deletion_cancelled, admin actor) | audit_log | Minimal (actor) | Accountability | As for the audit log | Art. 6(1)(c)/(f) |
| Data sent to Mollie (company name, invoice email, tenant id metadata, payment data, invoice recipient) | Mollie (payments and invoices) | Possibly | Payments and invoices | Mollie's terms; the mandate is revoked within about an hour of the hard delete, and when a cancelled subscription's period has ended | Art. 6(1)(b) |
| VAT ID sent to VIES | European Commission, VIES | No (business identifier) | VAT ID validation | Only the result is stored | Art. 6(1)(c) |
Not stored ​
Passwords, e-mail addresses (OIDC sign-in stores none; the hosted edition stores only the owner email and the invoice email listed above), calendar contents, source code at rest outside the code index above (review context checks out the head commit into a temporary workspace that is deleted after each run; symbol context is computed from that checkout and not stored). Exceptions: the patches of fix runs, the lines that review suggestions replace and the transient sandbox snapshots listed above; prompts and completions only when a tenant enables debug logging. Model calls send PR/issue content to the LLM provider the tenant configured; CodeLotse sends nothing to providers the tenant did not configure (ADR-0010, sub-processors).
Data subject requests ​
quavon dsar export|delete covers every person-linked column listed above through the personal-data registry (packages/db/src/personal-data.ts). Audit log entries are retained and reported as retained. Procedure: data-subject-rights.md; operator guide: dsar.md.