Arcqtype

Legal

Account Deletion & Data Retention

Effective: Pending attorney review · Last updated July 29, 2026 (draft) · counsel-review draft

Draft — pending attorney review. This document reflects how Arcqtype is built today but has not yet received final legal sign-off. Wording may change before launch.

1. How a user deletes their account (the in-app flow)

Arcqtype satisfies the App Store Review Guideline 5.1.1(v) requirement (apps that support account creation must offer in-app account *deletion*, not just deactivation) with a self-service, in-app delete flow:

The deletion is immediate and self-service — no email round-trip, no support ticket, no waiting period before the data operation runs. This meets the App Store bar: a real delete (not a hidden/deactivate-only path), reachable from inside the app.

Open question for counsel: App Store guidance says deletion may be initiated in-app even if completion is finished elsewhere, but Arcqtype completes deletion synchronously. Confirm the user-facing copy ("cannot be undone") accurately reflects that there is no grace/undo window — see §6.

---

2. What the backend does on DELETE /api/users/account

The route handler runs three ordered steps:

1. Storage cleanup first — uploaded files are removed from Supabase Storage *before* the database delete, so a storage failure surfaces instead of leaving orphaned objects behind a successful DB wipe. 2. Database hybrid delete — calls the Postgres function account_delete_hybrid(target_user_id). 3. Auth identity delete — removes the Supabase Auth user via the Admin API.

Step 3 is treated as non-fatal: if the auth-user delete errors, it is logged but the data is already gone. A durable tombstone (see §4) prevents the still-valid auth token from silently re-bootstrapping a new account.

2.1 Storage buckets erased

cleanupUserStorage deletes every object the user uploaded across three athlete-keyed buckets, recursing one level for nested paths:

Storage cleanup failures are logged and surfaced but are non-fatal — the DB delete still proceeds, and the audit log captures the residue for manual follow-up.

---

3. The four-bucket hybrid retention policy

account_delete_hybrid (defined in migration 210, then re-defined in migration 243 to add the tombstone — arcqtype-api/migrations/210_account_delete_hybrid.sql, arcqtype-api/migrations/243_account_status_gate.sql:52-187) deliberately does not do a single blanket cascade. It splits the user's data graph into four buckets:

3.1 Why bucket 4 is retained (the retention rationale, from code comments)

After anonymization these rows carry user_id = NULL plus an anonymized_at timestamp, severing the link back to the (now-deleted) identity while preserving the operational record.

Open question for counsel: Counsel must confirm that "anonymized" here meets the legal definition of anonymized/de-identified data under the applicable regime (GDPR Recital 26, CCPA/CPRA "deidentified," etc.). The code sets user_id = NULL but does not scrub free-text content inside chat_insights.content or athlete_events_log metadata. If retained safety insights contain re-identifying free text, "anonymized" may not hold and a true de-identification / minimization step may be required. See §7.

---

4. The durable tombstone — preventing account "zombies"

Because Supabase auth tokens can remain valid after the app-user row is deleted, the system writes a durable tombstone keyed on auth_id (and email) into user_account_tombstones during deletion.

On the next authenticated request, the auth middleware reads this tombstone. Behavior depends on the tombstone status:

This means deleted is not a permanent lockout — it is a clean break. The old data is gone/anonymized; signing in again creates a new account from scratch.

Open question for counsel: The user_account_tombstones row retains the deleted user's email (lowercased) indefinitely for the blocklist/dedup function. Counsel should confirm indefinite retention of the email of a deleted account (potentially a minor's email) is defensible, or whether the tombstone email needs a retention window or hashing. There is no scheduled job that purges tombstones or anonymized rows anywhere in the codebase (verified by search) — retention is currently *indefinite*. See §6.

---

5. Account status states (disabled / deleted / banned)

Beyond user-initiated deletion, an account can be in one of four account_status values, constrained at the DB level to active | disabled | deleted | banned. Each blocked state has its own timestamp column: disabled_at, deleted_at, banned_at, plus an account_status_reason.

The access-state resolver treats any of disabled/deleted/banned (or the presence of the corresponding timestamp) as a hard block that zeroes all capabilities. The same blocked-status logic is enforced in the auth middleware before any route runs.

Open question for counsel: disabled and banned are soft states that retain all user data indefinitely while blocking access. The code paths that *set* disabled/banned were not found in the API routes/services (only the *enforcement* of those states) — these appear to be ops/admin operations performed directly against the DB. Counsel should confirm (a) whether a privacy-law access/erasure request can land on a disabled/banned account whose data is fully retained, and (b) the retention basis for keeping a banned user's full athletic + health data indefinitely.

---

6. Retention windows — current state

There is no automated retention-window enforcement in the codebase. A search across src/, migrations/, and scripts/ found:

In practice, today's retention windows are:

Open question for counsel — required decisions: 1. Define the retention schedule. The policy should state concrete windows (e.g., "anonymized safety insights retained for N years for abuse-pattern review"; "billing records retained for N years per tax/financial requirements"; "tombstone email retained for N months"). The engineering side currently has none — these are legal/business decisions that then need implementation as a scheduled purge job. 2. Grace / undo window. There is currently no grace period — deletion is immediate and irreversible. Confirm whether App Store / platform expectations or business preference call for a soft-delete grace window before the hard cascade runs. 3. RevenueCat / Apple subscription records. The subscriptions row is retained (anonymized) for refund/dispute handling, but Apple/RevenueCat hold their own billing records outside Arcqtype's control. The policy must disclose that subscription/billing history may persist with the payment processor and platform after Arcqtype-side deletion.

---

7. Minor-account deletion (COPPA / under-13 considerations)

Arcqtype serves minors under a 13+ launch posture. Current backend code still enforces guardian consent for under-13 saves as a backstop/divergence to align.

When a minor's account is deleted, the same account_delete_hybrid path runs — there is no separate minor-specific deletion flow in code. Notable consequences for minor data:

Open question for counsel — minor-specific, high priority: 1. COPPA consent-record retention conflict. COPPA (16 CFR §312) generally requires operators to retain records of verifiable parental consent and to delete a child's personal information when no longer needed. Here, coppa_audit_log and guardian_consent_tokens are hard-deleted on account deletion. Counsel must decide whether the consent *record* itself must survive the child's data deletion (to prove consent was obtained), which would require flipping these FKs from CASCADE to SET NULL / a retained anonymized record — the opposite of current behavior. 2. Who may delete a minor's account. The in-app delete is triggered by whoever is signed in on the device. COPPA gives the *parent* the right to direct deletion of a child's data. Confirm whether the policy and product need a guardian-initiated deletion path (e.g., via Arcqtype-Parent) distinct from the athlete-initiated one. No guardian-initiated deletion endpoint was found in code. 3. Retaining a minor's anonymized safety insights. Bucket 4 retains chat_insights (which can include crisis/self-harm/eating-disorder signals) indefinitely for a deleted minor, with user_id nulled but content not scrubbed. Counsel must weigh the safety/abuse-review rationale against COPPA/state-minor-privacy minimization duties, and confirm the de-identification is adequate for a child's sensitive data. 4. Minor email in tombstone. As in §4, the deleted minor's lowercased email persists in user_account_tombstones indefinitely. Confirm this is permissible or define a window.

---

8. What this document does NOT establish (must come from counsel)

---

Appendix A — Grounding citations