> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tuturuuu.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Data protection gaps and delivery plan

> Risk-ranked gaps, small dependent PR boundaries, migration approvals and behavioral acceptance for platform data protection.

## Phase boundary

Phase 1 delivers the [standard](https://docs.tuturuuu.com/platform/data-protection-standard.md), [inventory](https://docs.tuturuuu.com/platform/data-protection/inventory.md) and source appendices. It does not implement retention, apply migrations, access production data, change processor settings or authorize phase 2. The integration owner reviews this packet and obtains the user's go-ahead. Every migration, including D1 or the memory sidecar schema, requires explicit user approval through that owner before implementation or execution.

The findings below are source-backed compliance and data-lifecycle risks. They are not claims of an exploited vulnerability, production data exposure or complete absence of other safeguards. Severity describes the consequence if the observed gap remains in the applicable processing flow. Owners and acceptance are proposed work allocations, not claims that those owners have accepted delivery.

## Top five risks

| ID and priority | Trigger and consequence | Source evidence and existing protection | Smallest useful next change |
| - | - | - | - |
| DP-01, high | A subject or workspace is considered deleted while profile details, embeddings, files or processor copies remain. The platform cannot demonstrate full erasure by its deadline. | Account deletion removes the Auth identity but the trigger soft-deletes private details. Memory sidecar forget retains content/embeddings. Workspace deletion deletes a DB row with best-effort subscription cleanup. These are real product paths, but no cross-store completion ledger was established. See Identity, AI and memory, and the sidecar in the inventory. | Define subject discovery and one request/adapter receipt contract. Implement physical memory purge and account/workspace adapters as separately reviewed changes. Preserve legally justified records explicitly. |
| DP-02, high | A delayed queue consumer, provider sync, backfill, offline client or backup restore republishes data after withdrawal or deletion. | Per-feature claims/retries and memory consent checks exist. This review did not establish a platform deletion generation checked by every writer, or a backup restore barrier. See asynchronous state, calendar, chat and backups in the inventory. | Add durable fences and exercise write-versus-delete races before connecting purge workers. Preserve original identities for unknown provider writes. |
| DP-03, high | Ordinary security events or development email sending place raw personal values into long-lived logs outside the erasure graph. | Abuse protection logs a sanitized IP, and email DEV\_MODE logs recipient lists and subject. `sanitizeLogValue` removes control characters and bounds length; it does not redact PII. See the precise links below. | Replace raw values with allowlisted diagnostic fields at these callers, preserve native `console.*` severity, then expand in small product scopes. Set sink retention and artifact hygiene separately. |
| DP-04, high | Raw events or person-linked metadata outlive their purpose or the 90-day ceiling. | `link_analytics` and `email_audit` have raw IP/UA fields. [API-key usage logs](https://github.com/tutur3u/platform/blob/8d6a13e58762aedff6b1ea5eabb6de474a257e99/apps/database/supabase/migrations/20251023193610_add_workspace_api_key_usage_logs.sql) also retain `ip_address`, `user_agent`, `request_params` and `error_message`; a 90-day cleanup RPC exists, but scheduled execution was not established. Studio metadata defaults to 365 days and can be configured longer. Cleanup RPCs and short-lived Redis counters protect some stores but do not establish the platform schedule. | Classify raw versus necessary accounting metadata. Add approved TTL/index changes and bounded Cloudflare purge adapters, and verify PII-free aggregate output. |
| DP-05, high | A rights request is scheduled for 30 days even when an earlier legal deadline applies, or is declared complete before a processor/backup answers. | Product-specific exports exist, and legal acceptance versions are recorded. A unified request/deadline/processor receipt path was not established. Provider registries differ. Decree 13's historical shorter deadlines require legal triage; current successor-law applicability is unresolved. | Legal owner confirms current-law mapping and processor roles. Add deadline-aware intake and truthful partial-state reporting, then verify processor and backup expiry/restore evidence. |

DP-03 source examples are [abuse IP logging](https://github.com/tutur3u/platform/blob/8d6a13e58762aedff6b1ea5eabb6de474a257e99/packages/utils/src/abuse-protection/index.ts#L465), [email development logging](https://github.com/tutur3u/platform/blob/8d6a13e58762aedff6b1ea5eabb6de474a257e99/packages/email-service/src/email-service.ts#L386), and [log-injection sanitization](https://github.com/tutur3u/platform/blob/8d6a13e58762aedff6b1ea5eabb6de474a257e99/packages/utils/src/log-sanitizer.ts). This distinction prevents treating a log-injection fix as PII redaction.

## Principle-by-principle gap register

| Standard principle | Existing foundation | Gap and acceptance owner |
| - | - | - |
| Consent and purpose evidence | Versioned legal acceptance with network hashes; user/workspace memory settings; separate Meet memory opt-in. | DP-06, high: publication acceptance is not a purpose registry. Product owners and legal owner must map basis, source, purpose, notice version, scope and withdrawal across learners, guests, contacts, employees, health, AI and integrations. Preserve provenance and existing preferences. |
| Export/erasure by 30 days or earlier | Product memory, forms, attendance, financial and other exports; account/contact deletion routes. | DP-01 and DP-05: missing platform discovery/completion contract. Privacy service owner must prove all store receipts, cross-tenant authorization, earlier due times, exception subsets and secure export expiry. |
| Deletion fences | Local claims, revisions, memory consent checks and per-feature cancellation. | DP-02: no universal writer/restore coverage established. Owning service teams must cover queues, caches, replicas, embeddings, providers and offline replays. A new global store cannot be introduced without approved design and migrations. |
| Workspace purge within 30 days | Workspace row deletion, FK cascades, feature-level media cleanup. | DP-01 and DP-02: DB-row success omits R2, Storage, D1, DOs, sidecar and providers. Infrastructure owner must own the manifest and deadline, with product adapters and a restore gate. |
| Minimal IP/UA and redacted logs | Legal acceptance hashes, limited temp tokens, log-injection sanitation and feature TTLs. | DP-03 and DP-04: raw event fields, key names, error messages and direct log values remain candidates. Security and product owners must minimize at ingress, define short TTLs and prove sink configuration. |
| Bounded raw-event retention and PII-free aggregates | Studio content expiry, some cleanup RPCs, rate-limit TTLs and feature aggregate queries. | DP-04: no complete raw-event TTL matrix. Analytics owners must remove person joins, free text and identifying small cohorts before indefinite retention. TTL must cover replicas and backup exceptions. |
| Least-privilege access supporting all principles | RLS, private schemas, audited RPCs, product permissions and scoped export links. | DP-07, medium verification gap: static policy declarations are indexed for 412 of 655 table candidates, not a verified effective-grant census. Some private service-only tables intentionally have no user policy. Remaining access scopes are unresolved, not proven public. Database owners must test actual grants, RLS, definer RPCs and API authorization on an isolated applied schema. |

## Small PR sequence

Use native GitHub stacks for actual dependencies. Keep independent documentation, log fixes and processor evidence on separate branches. Each row is a review boundary and can split further by product or store. No row authorizes a migration or a production cutover.

`Yes` means explicit user approval is required for the proposed schema migration. `No` means the proposed scope avoids schema changes, not that deployment or processor writes are already authorized. If implementation discovers a schema change in a `No` row, stop that part and obtain approval through the integration owner.

| PR | Depends on | Reviewable deliverable | Migration | Required acceptance |
| - | - | - | - | - |
| DP-A: legal and processor schedule | Phase-2 go | Confirm successor-law/deadline mapping, controller roles, approved purpose matrix, provider contracts/regions, backup expiry and exception record fields. Reconcile existing legal registries from actual callers. | No | Legal-owner sign-off and processor-owner evidence. No blanket compliance claim. |
| DP-B1: security log minimization | Go; can parallel A | Remove raw IP/user identifiers and unfiltered error content from the identified abuse logging paths. Preserve useful error codes and severity. | No | Capture actual `console.*` output with synthetic PII canaries. Assert raw values never reach any severity or retry path. Keep log-injection negative controls. |
| DP-B2: email log minimization | Go; parallel B1 | Remove recipient/subject data from DEV\_MODE and provider diagnostics in the email-service scope. | No | Exercise allowed/blocked recipients, provider failure and dev send paths with synthetic payloads. Verify useful non-content diagnostics. |
| DP-C: lifecycle contract | A | Define typed subject/workspace identities, purposes, absolute deadlines, adapter receipts and exception states in a framework-independent service boundary. Map existing first-party callers. | No | Contract tests through representative product callers. Model partial, failed, unknown, complete and retained-exception outcomes truthfully. No fake persistence. |
| DP-D: request and deletion ledger foundation | C | Add minimal private rights-request, per-store completion and durable subject/workspace deletion-fence storage with narrow RPCs. Schema design first; no auto-backfill. | Yes: Supabase | Explicit approval, isolated reset and upgrade, RLS/grant/search-path negatives, deadlines, duplicate requests, fencing generations and concurrent mutations. |
| DP-E1: memory purge foundation | D | Add the smallest approved sidecar tombstone/physical-purge support if existing storage cannot satisfy the fence and erasure contract. Do not create another product memory store. | Yes: sidecar schema if needed | Explicit approval of exact schema. Preserve scope, provenance, consent, embeddings/full-text removal and replacement-before-original-delete rules. |
| DP-E2: memory rights adapter | D, E1 | Implement physical memory erasure/export and generation checks through the existing memory service. Keep Meet separately scoped. | No after E1 | Real sidecar fixture: forget versus erase, concurrent consolidation/edit, failed replacement, stale backfill, revision conflict, partial deletion and restored old memory. |
| DP-F1: account and workspace DB adapter | D | Map account IDs, contacts/guests and workspace identities to relational rows. Add narrow purge/export RPCs and required indexes in one bounded table family at a time. | Yes: Supabase | Explicit approval per migration. Applied FK/cascade/RESTRICT/SET NULL cases, shared-content exceptions, orphan discovery, SQL permissions and no cross-tenant export. |
| DP-F2: lifecycle API integration | F1 | Connect account/workspace/privacy-request APIs to durable request state and truthful progress. Billing failures do not erase or hide privacy intake. | No | Route-level tests for current callers, subscription failures, partial cleanup, identity checks, request deadlines and expiring export downloads. |
| DP-G1: object-store adapter | D, F1 | Inventory object prefixes and remove bytes, multipart remnants, exports and cache copies for Supabase Storage and Mail R2, one bucket/owner per PR. | No if current metadata suffices | Real isolated storage fixture, paginated retries, delete-versus-upload race, duplicate delete, private export authorization and unknown provider result. Approval required if new metadata tables are needed. |
| DP-G2: Lettin rights foundation | D | Add subject/workspace lookup and purge-fence support to D1 where required. Include imports, profiles and both bookmark stores. | Yes: D1 | Explicit approval, isolated upgrade and rollback-by-disable, FK and cross-workspace tests. Preserve media deletion claims. |
| DP-G3: Worker and Lettin adapters | G2; other Workers can stack on D | Connect D1/R2 and then individual DO owners to export/purge and terminal acknowledgments. Treat each Worker as a small PR. | No after approved foundations | Real local Worker/DO/D1/R2 acceptance, disconnect/reconnect, stale alarms, cached checkpoints, fence persistence on restart and no resurrection. Hosted media boundaries remain separate. |
| DP-H1: event retention foundation | A, D | Classify raw events, approve per-service IP/UA TTL, add expiry indexes/fields or narrow cleanup RPCs by table family. Resolve Studio metadata's 365-day conflict explicitly. | Yes: Supabase | Explicit approval per family; boundary timestamps, legal exception subset, lock/batch bounds and no deletion of unexpired required financial evidence. |
| DP-H2: bounded Cloudflare purges | H1; adapters as needed | Add default-off Cron Control jobs and bounded processors for approved table families. Remove or retire redundant owners only through the existing guard. | No new schema beyond H1 | Count operations under failure, retry/DLQ expiry, duplicate tick, stop/restart, no-progress terminal handling and deadline escalation. No new Vercel Cron, pg\_cron or Edge Function. |
| DP-H3: anonymous aggregates | H1 | Replace indefinite person-linked metrics with PII-free aggregates, one analytics family per PR. | Yes if aggregate tables/RPC changes are needed | Explicit approval where needed. Show raw identifiers, stable pseudonyms, free text and identifying small cohorts cannot be reconstructed from output. Preserve required financial totals separately. |
| DP-I: queue and sync fences | D; adapters per product | Add checks at admission and the final write boundary for mail/report jobs, external chat, calendar sync, AI backfill and offline replay. Split by product owner. | No if D provides required state | Delete/withdraw during awaited preparation, retry after restart, stale lease, imported old consent, unknown provider send and provider event replay. Never blind-retry an unknown write. |
| DP-J: processor and backup closure | A, adapters | Implement scoped processor requests, backup expiry/restore barrier, cache/replica invalidation and private evidence receipts. Configuration/provider changes require their own authorization. | No planned; reclassify if required | Disposable-data deletion/export receipts, documented unavailable APIs, real restore rehearsal with fence replay before traffic/jobs, exact remaining expiry and lawful exception. |
| DP-K: customer controls and rollout | Required adapters, I, J | EN/VI rights intake/progress and secure export flow across affected Web/mobile surfaces, support runbook and controlled pilot. | No planned | Relevant exact-commit CI and app builds off local workstations per the [resource policy](https://docs.tuturuuu.com/reference/packages/sdk.md#local-resource-control), browser/device behavior, deadline/partial-state UX, cross-tenant security review, staged approved migrations and explicit production rollout scope. |

The first useful enforcement stack is C → D → E1/E2 or F1/F2. Storage and Worker stacks depend on the same fence contract. Event TTLs and logging can advance independently once their approved scopes are clear. Integrate a verified contiguous stack prefix only through the integration owner. Do not merge a later layer as implied approval for an unapproved migration below it.

## Verification and release evidence

Documentation-only changes require navigation/link/frontmatter checks, a source-count reconciliation, a focused secret scan of the diff and `bun check:changed` before push. Run heavy validation off local workstations per the [resource policy](https://docs.tuturuuu.com/reference/packages/sdk.md#local-resource-control). A refused resource gate requires an authorized remote run or a reported blocker, without bypassing admission. Documentation validation does not require builds, `bun validate`, database resets, production data queries or provider writes.

Later implementation uses focused non-build tests locally and admitted isolated environments for database/runtime tests. Offload builds and broad suites according to current host/resource policy. Each migration needs explicit approval, isolated reset/upgrade evidence, exact-SHA staging application and the gated production migration result after an authorized release. Documentation alone never authorizes migration execution.

Before rollout, the integration owner records exact source, CI, security review, deployed identity, approved migration receipts, processor evidence and a subject/workspace fixture whose purge is complete across every in-scope store. Maintain the hard release hold for open critical/high security findings under the repository security policy. The source-risk register does not replace independent security review of implementation changes.

Completion of a rights request requires all required store receipts, or a precise lawful retained subset and expiry communicated under the applicable rules. Any missing provider response, unconfirmed delete, inaccessible backup expiry or unresolved unknown write remains visible. Metrics report deadline misses and partial completion without customer content or raw identifiers.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.