PlayGM Data Retention Policy

Effective date: {{PLACEHOLDER: launch date}}
Version: RETENTION-2026.1
Publisher: PlayGM Inc — PO Box 95, Armonk NY 10504 — stefan@playgm.app

This policy states, for each category of personal information PlayGM collects, the purpose we collect it for, the business need to retain it for that period, the deletion timeframe, and the deletion trigger. It is published because the amended COPPA Rule requires it to be publicly posted and referenced from our notice of information practices (16 CFR § 312.10, in force since April 22, 2026).

We do not retain personal information from a child for any purpose other than the ones stated in this policy. We do not retain it indefinitely.

Every record we hold is tagged with the retention policy version in force when it was collected. Shortening a duration applies retroactively. Lengthening a duration applies only prospectively and requires fresh consent from every affected household.

1. Retention schedule

#	Category	Purpose	Business need	Duration	Trigger
1	Child display name and age band	Identify the child in the app; serve age-appropriate content	Required to render the account	Life of the child profile, plus 24 months of inactivity	No login and no recorded gameplay for 24 months
2	Child gameplay records (drafts, rosters, scores, trivia answers)	Run the game	Required for continued gameplay	Life of the child profile, plus 24 months of inactivity	Same as #1
3	Questions typed to Ask Scout	Get an answer from the assistant	Answer is returned in real time; no need to retain	Not retained	Discarded at response time
4	Ask Scout content-free telemetry (classification, refusal category, latency, timestamps)	Prove safety controls are functioning	Required for safety and audit	12 months	Age-out
5	Card-scanner recognized-card identifier	Track which cards the child has scanned	Required for gameplay	Life of the child profile, plus 24 months of inactivity	Same as #1
6	Session tokens, cookies, and authentication material	Keep the app logged in and secure	Required for security	Rotating; max 90 days per token	Rotation or logout
7	Parent email address (plaintext)	Send parent communications	Required for account management	Life of the household account, plus 30 days	Account closure or parent revocation
8	Parent payment information	Bill the subscription	Held by our payment processor, not by us	Not stored on PlayGM servers	Handled by the payment processor
9	Consent evidence (minimized — see § 3)	Prove verifiable parental consent existed	Federal statute-of-limitations analysis for FTC actions supports 5 years	5 years from `consent_state = COMPLETE` or revocation	Age-out
10	Abandoned or incomplete consent records (including parent email pending consent)	Complete the consent flow	No longer needed once abandoned	14 days from creation	Age-out
11	Audit logs (rights-request events, admin actions, guardrail refusals, purge events)	Prove compliance controls held	Required for audit and enforcement response	12 months	Age-out
12	Security logs (authentication events, IP-based anomaly signals)	Detect and investigate abuse	Required for security operations	12 months	Age-out
13	Export artifacts (files we generate when a parent asks for data)	Deliver the export	Access is authenticated in-product; parent can regenerate any time	7 days from generation	Age-out
14	Deletion evidence and deletion log entries	Prove deletion occurred; drive re-deletion on backup restore	Required to satisfy the re-deletion-on-restore commitment (§ 4)	Persistent (no PI in the entry, only opaque record identifiers and timestamps)	Never
15	Anonymized aggregate gameplay statistics (population-level, non-reidentifiable)	Product improvement	Not personal information under COPPA	Indefinite	N/A

Where a value in this table appears in the Privacy Policy or in the Direct Notice, it is the same value. The Privacy Policy links here for detail.

2. What "life of the account" means

An account's life ends at the earliest of:

Parent-initiated deletion (see § 5).
Parent-initiated account closure (deletes every profile in the household).
24 consecutive months without a login and without recorded gameplay on any profile in the household (inactivity trigger).
Subscription lapse plus a 90-day grace period during which we retain the account for the parent to reactivate, followed by inactivity processing.

When an account's life ends by any of these paths, the retention clocks in the table above start.

We retain proof of consent for 5 years, but we retain the smallest record that still proves it. Specifically:

The parent's email address is stored as a salted SHA-256 hash, not plaintext. The plaintext is used to send the message and then discarded.
The child's name is not in the consent record.
The direct notice text is retained by version identifier only, so any served notice can be reproduced from the immutable notice archive.

This design lets us prove consent existed for a given household without holding identifiable child data past the child's own retention clock. Full schema in 04_GUARDIAN_CONSENT.md § A.2.

Counsel review: the 5-year duration rests on the federal statute-of-limitations analysis under 28 U.S.C. § 2462 and on prior FTC consent-order practice, not on an express COPPA requirement. Counsel to confirm.

4. Backups

We keep operational backups so we can recover from a failure. Backup retention on our infrastructure is {{PLACEHOLDER: number of days for scheduled backups}} for scheduled snapshots and {{PLACEHOLDER: number of hours or days for point-in-time recovery}} for point-in-time recovery.

When we honor a deletion, we purge the record from production immediately after the recovery window (see § 5). We do not surgically edit backup files. Backups age out on their normal rotation. If we ever restore from a backup, we re-delete records that were previously deleted, using the persistent deletion log kept for that purpose (§ 1 row 14). Restored backups do not resurrect deleted records.

Counsel review: industry practice supports age-out plus re-deletion, but the FTC has not blessed this approach in a rulemaking or consent order. The published re-deletion commitment is the mitigation. Counsel to confirm posture before publication.

5. Deletion — how it actually runs

The Privacy Policy (§§ 9–11) states the parent's rights and the turnaround. This section states the technical timeline our workers follow.

VERIFIED  →  RECOVERY_WINDOW   (14 days; child access suspended, collection halted)
RECOVERY_WINDOW  →  PURGE_QUEUED    (irreversible from here)
PURGE_QUEUED  →  PROCESSOR_PURGE    (deletion instruction sent to every service provider in the manifest)
PROCESSOR_PURGE  →  BACKUP_AGING    (record purged from production; backups aging out per § 4)
BACKUP_AGING  →  COMPLETED

Timing:

Acknowledgement: within 5 business days of the request.
Verification: parent account session plus a fresh single-use code emailed to the parent address on record.
Immediate on verification: the child's access is suspended and collection halts on that profile. Collection during the recovery window would be an independent violation regardless of the pending deletion.
Recovery window: 14 days. The parent can cancel from Settings → Privacy Requests or by email. After 14 days the purge is irreversible.
Production purge: initiated at the end of the recovery window; completes within 24 hours in ordinary operation.
Processor purge: deletion instructions sent to every provider in the current processor manifest at production purge. Providers acknowledge per their DPA.
Backup age-out: completes as backups rotate per § 4. Re-deletion applies on any restore.
Case closed: when backup age-out is complete for the record's provider set, the case is marked COMPLETED and the parent is notified.

Counsel review: the position that "completed within the response deadline" means reaching PURGE_QUEUED (deletion becoming irreversible), not COMPLETED (backup age-out), is stated in PRIVACY_RUNTIME_DECISIONS.md § 1.2. Counsel to confirm this reading and to sign off on stating it here.

6. When we may lawfully hold a deletion

We may suspend a pending deletion request under a legal hold — for example, a preservation letter under 18 U.S.C. § 2703(f), a subpoena, a court order, an ongoing regulatory investigation, or an obligation to preserve under 18 U.S.C. § 2258A. We route every held case to counsel individually. If a court order or statute prevents us from telling you a hold is in place, we still tell you the request is on hold, without the specific reason.

7. Version control and change management

Every retention record includes a retention_policy_version tag.
Prior versions of this policy are archived at {{PLACEHOLDER: URL of policy archive}} and remain available so any record can be audited against the rules in force when it was collected.
A change that shortens a duration takes effect immediately for all records.
A change that lengthens a duration is a material change that applies only to newly collected records and requires fresh consent from every affected household (see 04_GUARDIAN_CONSENT.md § A.7).

8. How to reach us with a retention question

Email: stefan@playgm.app
Mail: PlayGM Inc, Attn: Stefan Martinovic, PO Box 95, Armonk, NY 10504
Phone: 914-294-5209

Placeholders in this document

Effective date (header)
Scheduled backup retention (days) — from Supabase plan (§ 4)
Point-in-time recovery window — from Supabase plan (§ 4)
URL of policy archive (§ 7)
Counsel confirmation that a PO Box satisfies the postal-address requirement (§ 8; box number supplied by the owner 12 September 2026)