Account & Data Deletion and Data-Subject-Request (DSAR / ARCO) Procedure

1. Purpose

This document is the operative procedure by which Happy Songs receives, verifies, executes, and closes a request to delete an account and its data, or to exercise any other data-subject right (access, rectification, cancellation/erasure, opposition, portability, opt-out, and withdrawal of consent — the derechos ARCO in Mexico; the consumer-privacy rights of the CCPA/CPRA, the Texas TDPSA, and the amended COPPA Rule in the United States).

It is both Customer-facing (the in-app screens, the web deletion page, and the confirmation copy) and internal (the intake, verification, execution, and audit engine). It is written so that a request cannot be lost, cannot be executed against the wrong person, and cannot close before every data store returns a documented result within the applicable legal deadline.

2. Definitions

• The Customer. The account holder: an adult — at least 18 years old, or the age of majority where the Customer resides — who registers, operates, and pays for the service, and who is the sole person entitled to file and receive the response to any request under this procedure. The Customer's identifier of record is a verified phone number (Section 7).
• Parent or legal guardian. The capacity in which the Customer acts when the Customer supplies the information of a minor. Where the Customer provides a minor's first name, the Customer represents that the Customer is that minor's parent or legal guardian and consents to the processing on the child's behalf. A minor never holds an account, never operates the service, and never files a request; the Customer exercises every right relating to a minor's data (Section 8).
• Recipient first name. The single item of information Happy Songs stores about the person a song is created for: a first name only. Happy Songs does not store a surname, nickname, age, date of birth, profile, precise location, or any special-category data of that person. Age or life-stage may be used in the moment to browse or tailor a song and is not stored.
• Account deletion. Erasure of the entire account and the cascade in Section 9, initiated by the Customer through the in-app control or the web deletion page.
• DSAR / ARCO request. Any exercise of a data-subject right: access/Acceso, rectification/Rectificación, cancellation-erasure/Cancelación, opposition/Oposición, portability, opt-out of "sale"/"sharing" and honoring Global Privacy Control, and withdrawal of consent.
• Server-side data. Everything Happy Songs or its subprocessors hold. In scope for deletion, subject to the retention reconciliation in Section 11.
• On-device cache. The App-managed copy of songs stored on the device solely for offline playback inside the App. Under the closed-ecosystem access model (Section 3) it is not a Customer-owned file, is not exportable, and is within the App's reach; it is purged on deletion or end of access (Section 9.4).
• SLA clock. Begins when a verified request is received; measured per regime (Section 12).
• Suppression list. A minimal, non-sensitive keyed record retained after deletion so that a restore-from-backup or a re-signup does not resurrect deleted data or re-target the former Customer (Sections 9.5 and 13).

3. The access model that this procedure enforces

Happy Songs operates a closed ecosystem. The Customer receives a personal, non-exclusive, revocable license to access and play each song inside the App only. A song is not owned by the Customer, is not delivered as a downloadable or exportable file, and is not unique or exclusive (a name-fill is reused; another Customer whose recipient shares the same first name may receive the same song). Because no exportable file is ever delivered, deletion is complete: there is no Customer-held copy for the deletion to leave behind. The on-device cache exists only to permit offline playback and is purged when access ends. This is the factual predicate for the deletion and cache-purge representations made throughout this procedure and must not be contradicted by Customer-facing copy (Section 15).

4. Rights in scope (the request menu)

The in-app "Privacy & Data" screen, the web deletion page, and the privacy inbox must offer, at minimum, the rights below. Every channel is free of charge for a first request; a manifestly unfounded or excessive repeated request may be handled under the applicable regime's rules, applied narrowly and never as a barrier to a genuine request.

For any right that concerns a minor's data, the Customer is the only eligible requester (Section 8).

5. Flow A — In-app account deletion (self-service, store-mandated)

Entry point. Settings → "Privacy & Data" → "Delete my account", reachable in no more than [2] taps from Settings. Apple requires deletion to be initiable inside the App; Google Play additionally requires a web deletion URL (Flow B).

Steps.

1. Disclosure before confirmation (screen copy, subject to Section 15). The screen states, truthfully and without guilt or friction:
   • What is deleted: the account; the Customer's data (phone number, any optional email, device/technical data, usage/analytics, and communications); every recipient first name the Customer supplied; and every generated song (lyrics, cover art, and audio) — on Happy Songs' servers and at our providers.
   • That songs cached in the App are also removed: because songs live only inside the App and no exportable file exists, deletion stops playback and purges the on-device cache together with all server copies; nothing playable remains afterward.
   • What it costs: irreversibility; loss of access to all songs; forfeiture of in-app entitlements and rewards (Jacks) and severance of any "restore purchases" and retroactive-recovery-via-code linkage.
   • That records Happy Songs is legally required to keep — chiefly transaction, subscription, and tax records, and any active legal-hold or security records — survive account deletion in minimized, access-restricted form (Section 11).
   • Timing: deactivation is immediate; the full server and subprocessor purge completes within [30] days, the single value mirrored from the Data Retention Schedule (D17 §6.2), except records lawfully retained under Section 11.
2. Re-authenticate by one-time passcode to the phone of record, or an authenticated-session step-up (Section 7).
3. Confirm by typed confirmation or an explicit toggle. No dark-pattern friction and no retention nudges are permitted; this screen is operated by the adult Customer, and the anti-manipulation standard applies to that Customer.
4. Immediate deactivation. Session tokens are revoked, login is disabled, and content is de-listed from the account; the request enters the deletion queue.
5. Confirmation on-screen and by a message to the phone or email of record, stating that the request was received, the completion window, that in-app access has ended, and that the on-device cache has been purged.
6. Ticket created in the engine (Section 10) with the SLA clock started.

Grace / cancellation window. An optional soft-delete window (recommended: no more than [72] hours) may allow the Customer to cancel before hard purge. If adopted, it must be disclosed and must never extend past any applicable statutory deadline. Default posture: short, or none.

6. Flow B — Web deletion page (required by Google Play)

• A public page at https://happysongs.ai/delete-account (and its Spanish equivalent), reachable without installing the App and without passing a login or paywall, linked from the Play Console Data Safety form and from the Privacy Notice.
• The page presents the same truthful scope copy as Flow A, collects the phone of record, and triggers one-time-passcode verification (Section 7) so that no third party can delete a Customer's account.
• Once verified, the request enters the same engine and queue as Flow A. A Customer who cannot verify (for example, a lost number) is routed to the DSAR/ARCO channel (Section 7 fallback) for manual identity verification.
• The page states the timelines and the retention reconciliation (Section 11).

7. Flow C — DSAR / ARCO channel, and identity verification

Channels. The in-app "Privacy & Data" request form; the web deletion page (for deletion); and the monitored inbox privacy@happysongs.ai (an ARCO request may be made in writing). Every channel is free for a first request and funnels into a single ticketing system with one SLA clock. No request may live only in an inbox thread.

What intake captures. Requester identity; capacity (self, or parent/legal guardian acting for a minor); the right requested; scope; the residency signal that drives the deadline (Section 12); and the identifier.

Identity verification (anti-abuse gate). Deletion and access are destructive and disclosive; Happy Songs verifies before executing, and minimizes verification data — it is not repurposed and is never more sensitive than the data originally collected.

• Primary. The account identifier is the Customer's phone number; verification is by one-time passcode to that number (via Twilio). This is proportionate and self-service.
• Session step-up. An already-authenticated in-app session may re-confirm with a fresh one-time passcode or a device biometric unlock.
• Fallback (lost number, edge cases). Manual verification by the privacy operator using a limited set of non-sensitive, account-specific facts [define the corroboration set — must not over-collect]. Sensitive data is never required.
• Requests concerning a minor. The Customer verifies the Customer's own account; there is no separate child-identity step, because a minor never holds an account. A request that concerns a person not linked to the requester's account is denied and logged.
• Failed verification. Do not disclose and do not delete; log the attempt; respond that identity could not be verified and how to retry, without revealing whether the account exists (to prevent enumeration).

8. Minors — rights exercised by the parent or legal guardian

Happy Songs is a Customer-operated service: a minor never registers, operates, pays, provides data, or files a request; the adult Customer is the only user. This is a lawful-processing model, not a child-protection exemption. Happy Songs does not market to, advertise to, track, profile, or collect data from children, and does not knowingly permit a child to operate the account. To the extent the service may be accessed by a child, that is addressed proportionately — by not marketing to children and by keeping data about a minor to a first name the adult Customer supplies with consent — not by designing a child-user interface. The amended COPPA Rule's parental-deletion and data-minimization protections apply to that first name, and this procedure does not narrow them.

Incidental, parent-supervised access by a child does not make Happy Songs directed to children. As with any general-audience app, an adult Customer may let a child hear a song on the adult's own device; that incidental, supervised listening is not a child "using" or "accessing" the service as a user, and it does not convert an adult-operated service into one directed to children — nor does it give Happy Songs "actual knowledge" that it is collecting personal information from a child — under the amended COPPA Rule. Three affirmative facts about how the product is built hold this line: (1) Happy Songs builds no profile of the child — it holds only the first name the adult provides; (2) Happy Songs directs no feature, screen, content, character, or message at a child — there is no child login, no child-facing mode, and nothing that invites a child to act, earn, or transact; and (3) Happy Songs collects no data from the child — every input is provided by, and the account is operated by, the adult Customer. The honest boundary, which this procedure does not over-claim past: a minor's first name is processed, with the adult's parental consent, and Happy Songs still does not market to, advertise to, track, or profile a child. If a future feature were to speak to a child or be operated by a child, that would change this analysis, and Happy Songs would re-assess before it ships.

• The only information Happy Songs holds about a minor is the minor's first name — supplied by the Customer as a recipient first name — and that first name as it appears inside the song's lyrics and audio. Happy Songs holds no surname, nickname, age, date of birth, profile, precise location, or special-category data of any minor.
• Where the Customer supplies a minor's first name, the Customer represents and warrants that the Customer is that minor's parent or legal guardian and consents to the processing on the child's behalf.
• The Customer exercises every right over a minor's data: access to, rectification of, and erasure of the recipient record and any song or derived data referencing that first name. Deleting the account deletes all such records; the Customer may also delete an individual recipient record without deleting the whole account, through the in-app manager.
• A minor's data is treated as a priority target in the cascade: purged first, with no soft-delete parking beyond what is technically unavoidable, and only a minimized suppression key retained.
• Consistent with the amended COPPA Rule, a minor's data is never retained indefinitely; the retention carve-outs in Section 11 are read most narrowly for a minor's data, and the Data Retention Schedule (D17) imposes an affirmative inactivity cap so that nothing is kept "forever."

9. Deletion cascade (server-side) — what is purged, and where

On a verified account deletion, the engine executes the cascade below. Each target has an owner action, a mechanism, and a completion check. A deletion is not "done" until every target returns success or a documented lawful exception (Section 11).

9.1 Primary datastore (Supabase — system of record)

Transaction, subscription, and tax records are not hard-deleted by the cascade; they are retained in minimized, access-restricted form under Section 11.

9.2 Object storage and CDN

Delete the audio objects (which carry the Google SynthID watermark) and the cover-image objects from object storage, and purge the CDN edge caches so that any re-download URL returns 404.

9.3 Subprocessors

The Subprocessor List (D11) is the source of truth for the providers and the data each receives; each provider's DPA must contain a deletion-assistance obligation on which this cascade relies. The engine calls each provider's deletion mechanism and records the result. A key minimization applies: the recipient's real first name is sent only to the music provider, which sings it; the lyric providers receive a placeholder name and the real name is inserted locally. This narrows where a real first name is ever retained provider-side.

A distinction the engine must honor: data that transited a provider to generate a song is separate from the stored output in canciones. Happy Songs deletes the stored output; provider-side inputs are handled per each DPA. Both are covered.

9.4 On-device cache purge

• Under the access model, a song is delivered by in-app access only. The on-device copy is an App-managed offline cache, not a Customer-owned file, and it is within the App's reach.
• On account deletion (or on end or revocation of access), the App stops playback and purges the on-device cache, while Happy Songs deletes the server and provider copies. Because the song is never delivered as an exportable file, no Customer copy survives outside the App. This is stated on the pre-confirmation screen (Section 5) and in the confirmation message.
• The on-device cache is out of scope for every retention carve-out in Section 11: no legal-hold, tax/merchant-of-record, security, or accountability basis ever preserves a playable copy. Carve-outs reach only minimal, access-restricted server-side records. The cache is therefore purged in full and immediately on deletion or end of access, regardless of any server-side record that lawfully continues.
• The cache is protected by a technical protection measure; extracting, copying, re-hosting, or sharing a song outside the App is prohibited by the Terms (D1/D7) and, where a technical protection measure is circumvented, may engage the anti-circumvention provisions of 17 U.S.C. § 1201. This is an engineering dependency: the protection is only available where the technical measure is in fact implemented.

9.5 Backups

Deleted data may persist in encrypted, access-controlled backups until they age out on the backup rotation (Section 13). The deletion is recorded on the suppression list so that any restore re-applies the deletion and the data is never returned to production. The backup lag is disclosed in the Privacy Notice (D2).

10. The engine — intake → verify → route → execute → confirm → audit

A single ticketing/case-management system is the source of truth. Every request from every channel (Sections 5–7) becomes one ticket with a started SLA clock.

Lifecycle.

1. Intake. Capture channel, requester, right, scope, jurisdiction/residency, identifier, and timestamp; auto-acknowledge to the requester.
2. Verify. Identity per Section 7. The substantive-action clock runs; verification delays are logged but do not indefinitely pause statutory limits.
3. Classify and route. Determine the right type and jurisdiction to derive the deadline (Section 12) and the required steps (deletion cascade, access export, portability, opt-out).
4. Execute. Run the cascade (Section 9) through an orchestrator that calls each target and records per-target success or failure; failures retry with backoff and alert the operator; a target that cannot complete is escalated.
5. Apply carve-outs. Record each retention exception and its legal basis (Section 11).
6. Verify completion. Automated check that every in-scope target returned success or a logged exception. No ticket closes with an open target.
7. Confirm to the requester. Within the deadline, state what was deleted (server and provider copies and the on-device cache), that in-app access has ended, and what is lawfully retained and why.
8. Audit. Immutable log entry (request id, actions, targets, timestamps, operator, exceptions), minimized/anonymized, retained per D17.

Roles. Privacy Operations owner = [name / role], with backup [name / role], reachable at privacy@happysongs.ai. Engineering on-call owns the cascade orchestrator and the subprocessor integrations. [Legal / counsel] owns carve-out determinations, legal holds, and deadline configuration.

Escalation triggers. Identity unverifiable; a subprocessor deletion API failing past retries; an active legal hold; a request spanning a carve-out; a request subject to a tighter deadline than the default; suspected fraudulent or enumeration activity.

Monitoring. A dashboard of open tickets against their deadlines; an alert at [X] days before any deadline; monthly metrics (volume, median time-to-complete, on-time percentage, exceptions). Target: zero breached statutory deadlines.

Automation. Flow A and Flow B deletions are substantially automated (self-service into the queue into the orchestrated cascade). Broader DSAR/ARCO requests and carve-out cases are operator-driven on the same clock.

11. Retention reconciliation — what may lawfully survive deletion

Deletion is not absolute. The engine applies, and the confirmation copy reflects, that Happy Songs retains only the minimum necessary, for a stated purpose, in access-restricted form, and deletes it when the basis expires. The periods are governed by the Data Retention Schedule (D17); the categories below are the bases that may survive an account deletion.

• Transaction, subscription, and tax records (merchant-of-record). Happy Songs is a paid subscription service, currently offered with free promotional access (no card captured and no auto-charge during the promotion). Where a paid transaction has occurred — via Apple/Google in-app purchase (subscription status and receipts through RevenueCat) or a direct web sale (a tokenized card through the web payment processor) — Happy Songs retains the transaction, subscription, and tax records for the statutory period. Happy Songs does not store card numbers. During free promotional access there is generally no such record to retain.
• Referral Program records (presented in the App as "Familia Emprendedora"). Where Happy Songs has made or must make a referral reward payout to the adult Customer (the payee is always the adult Customer; a minor is never a participant or a payee), Happy Songs retains the payout, chargeback-clawback, and tax-reporting records (CFDI/withholding in Mexico; Form 1099 in the United States) for the statutory period. These are ordinary adult-payee records; deleting the account does not erase a tax obligation. The payout rail is Wise, which runs its own KYC and retention.
• Security, abuse, and fraud logs; legal hold. Where a dispute, investigation, or authority request is active, the relevant records are preserved under legal hold (see D15).
• Proof of consent and proof of request. Minimal accountability records, anonymized where possible.
• Suppression-list key. A minimal, non-sensitive key (Section 13).

Rules. Retained data is minimized, access-restricted, and purpose-locked, and is deleted when its basis expires. Carve-outs are read most narrowly for a minor's data (amended COPPA Rule). The on-device cache is never a retention target and is always purged (Section 9.4). Each carve-out applied to a specific request is logged with its legal basis and surfaced to the requester ("we deleted X; we are required to retain Y until Z for [reason]").

12. Deadlines (United States and Mexico)

The ticket's deadline is configured from the requester's jurisdiction and residency. Happy Songs commits to a global internal standard and meets or beats each specific regime. Deltas for other jurisdictions are handled in the separate jurisdiction-deltas document.

Notes. For US-state requests, honor the opt-out of "sale"/"sharing" and Global Privacy Control (D6). For Mexico, the authority is the Secretaría de Anticorrupción y Buen Gobierno (following the dissolution of INAI) under the 2025 Ley Federal de Protección de Datos Personales en Posesión de los Particulares; the Spanish-language channel is required.

13. Access, rectification, portability, backups, and suppression

• Access and portability. On a verified request, provide the data Happy Songs holds about the Customer and the recipient first names the Customer supplied, in a structured, commonly used, machine-readable format ([JSON/CSV]), within the applicable deadline. Under the access model, songs are provided as in-app access, not as exported files; the export contains the data records, not a downloadable audio file.
• Rectification. A phone number, optional email, or recipient first name may be corrected, mostly self-service in the profile.
• Suppression list. On deletion, store a minimal, non-sensitive key (for example, a hashed phone number) marking "deleted — do not restore, do not re-target." It is purpose-locked and itself deleted when no longer needed.
• Restore procedure. Any backup restore must re-apply the suppression list before data returns to production, so that a deleted subject is never resurrected.
• Backup aging. Deleted data in backups expires on the [35]-day backup rotation (mirrored from D17 §6.4); this is disclosed in D2.

14. Other jurisdictions

This procedure states the United States and Mexico baseline. Where a Customer or a data subject is in the European Union, the United Kingdom, Brazil, or another Latin-American jurisdiction, the separate jurisdiction-deltas document supplies the additional or shorter deadlines, the portability and objection specifics, any local-language requirement, and any local-representative routing. Those deltas add to the protections here and never reduce them.

15. Customer-facing copy — accuracy requirements

All screens and messages must be truthful and non-manipulative: no guilt or loss nudges to retain the account, no hiding of the delete path, and no false "we keep nothing" (lawful carve-outs exist). Under the access model it is accurate to tell the Customer that deletion ends in-app access and purges the on-device cache so that nothing playable remains, and that there is no exported copy to leave behind. Each confirmation states, in plain language: what was deleted (server, provider, and the on-device cache), that access has ended, what is lawfully retained and why, and the timeline. Copy meets WCAG 2.2 AA (D10) and is localized to Spanish for Mexican residents and Customers served in Spanish.

16. Consistency and reconciliation

This procedure must remain consistent with, and defers on their own subject matter to: D2 (Privacy Notice — the rights menu and channel), D17 (Data Retention Schedule — every period), D1/D7 (Terms/EULA — the access-model license and anti-circumvention), D9 (store configuration — the web deletion URL and Data Safety declarations), and D11 (Subprocessor List and DPAs — the providers and their deletion-assistance obligations).

Reconciliation actions flagged by this v1.0 (sibling documents predate the following locked decisions and must be conformed):

1. First-name-only minimization. This procedure stores, about the person a song is for, a first name only. Sibling drafts (notably D17 and D11) still describe that record as "name, nickname (apodo), and age range"; they must be conformed to the first-name-only standard. Age or life-stage is used only in the moment and is not stored.
2. Actor = the Customer. The account holder is the adult Customer, not "the parent" as a generic operator. "Parent or legal guardian" is used only where the Customer supplies a minor's first name and consents on the child's behalf.
3. Payments are live. Happy Songs is a paid subscription service currently in free promotional access; the transaction/subscription/tax retention basis in Section 11 is operative (not "N/A"), and card numbers are never stored (Apple/Google IAP via RevenueCat; a web payment processor tokenizes direct web sales).
4. Referral Program records for the adult payee (Section 11) are retained on deletion; a minor is never a payee.

17. Open items for licensed counsel (US / MX)

1. Mexico ARCO deadlines — confirm the response and effect terms under the 2025 Ley Federal and its pending reglamento, and the current authority routing (Secretaría de Anticorrupción y Buen Gobierno).
2. Global completion SLA — confirm [30] days as the internal commitment against every US-state and COPPA obligation.
3. Verification fallback — approve the lost-number corroboration set (must not over-collect).
4. Subprocessor deletion coverage — confirm each DPA (D11) contains a deletion-assistance clause and a working endpoint; document Twilio, Vertex/Lyria, Anthropic, OpenAI, and Nano Banana (cover art) retention limits (including flag-based retention). Nano Banana must be accessed via Vertex AI / a paid API tier, NOT the consumer Gemini Dev API (which bars under-18 services) — the same reason Lyria runs on Vertex.
5. Soft-delete grace window — confirm none or ≤ [72] hours; must not exceed any statutory deadline.
6. Backup rotation window — confirm [35] days and align D2/D17.
7. Repeated/excessive-request policy and any fee rules — confirm per regime.
8. First-name-only conformance — confirm the D17 and D11 category descriptions are updated to remove nickname and age range consistent with Section 16(1).