تم التحديث قبل أسبوع واحد

COPPA Data-Retention Policy

Effective Date: April 22, 2026 Last Updated: September 18, 2026 Version: v2.0 — counsel-reviewed

This document supplements the ConKarma Privacy Policy §3 (Children's Privacy) and §8 (Data Retention) with a complete, parent-readable schedule of how long ConKarma retains data associated with child accounts, the finite-bounding mechanisms in place, and the operational backing that enforces each window. It is published in fulfilment of the amended Children's Online Privacy Protection Act Rule effective 22 April 2026.

1. Scope and audience

This policy applies to all data associated with a child account — an account whose user is under 13 at the time of account creation as determined by the COPPA-amendment neutral age-gate. Verifiable parental consent is collected via the parent-consent flow before any personal information is collected from the child, per 16 CFR §312.5.

A child account remains in scope for this policy until either the child reaches 13 and the account is migrated to a teen account, the account is deleted at parental request, or the account is deleted at child request via the same procedure.

This policy does not cover adult-account data, which is governed by Privacy Policy §8.1 and §8.2.

2. Data categories collected from child accounts

Per 16 CFR §312.5(b)(1), the operator must disclose what personal information is collected, how it is used, and how it is retained before parental consent is given. ConKarma's parent-consent flow surfaces this list verbatim.

• Account profile: child's first name (or chosen display name), birthday (for age verification only; not displayed), parental contact, account creation timestamp, device + locale metadata.
• Cell-membership data: which family or close-friend "cell" the child belongs to; the child's role in that cell; cell-level preferences set by the parent.
• User-generated content: journal entries, mission completions, duty completions, experiences, photo proof, voice notes (where the child opts in), comments, reactions, scrapbook submissions.
• Calendar data: cell calendar events the child creates or is invited to; Important Dates the child or parent records.
• Conflict-resolution records: conflict markers and repair markers logged through the sibling- or parent-mediated conflict-resolution flow.
• Activity + gamification: DNA / EGO transaction ledger entries, streak history, daily quest completions, achievement unlocks, cosmetic ownership.
• Geolocation (separate verifiable parental consent required): emergency check-in coordinates are collected only under a distinct, verifiable parental consent for geolocation — separate from, and not bundled into, the general account-creation consent — and only when the child additionally opts in to the specific check-in (16 CFR §312.5(b)). A parent may withdraw geolocation consent at any time, which stops collection and purges retained coordinates within minutes.
• Diagnostic + safety data: crash logs, abuse-report submissions, content-moderation flags, support-ticket history.
• Audit log entries: structured records of administrative actions touching the child account.
• Parental-consent artefacts: consent tokens, parent email, parent IP and user-agent captured at consent submission, parental decision, revocation history.

The following are deliberately not collected from child accounts and therefore have no retention window: precise location outside emergency check-in, contact lists or address book, browsing history outside ConKarma, behavioural-advertising identifiers, biometric data, payment information (children cannot complete in-app purchases — see §4 below).

Voice notes (child — opt-in + separate parental permission). A child may record voice notes only where the parent has turned on the per-child 'allow voice notes' permission in the Parent Dashboard (off by default). Where the parent additionally enables voice transcription, the child's recording is sent to our speech-to-text sub-processor — OpenAI ('Whisper') or Google Cloud Speech-to-Text, via the vendor-neutral AI Gateway — solely to produce a text transcript, and is not used to train the provider's models. ConKarma does not create voiceprints and does not use voice for identification (see the biometric-data exclusion above); a child's voice note is treated as ordinary user-generated content and follows the voice-note retention window in the table below. The parent may turn voice notes off at any time, which stops capture; deleting a voice note removes both the recording and its transcript.

Photographs and image generation (child — separate per-class parental consent). Where an image-generation feature is offered, a child's photograph is sent to an image-generation sub-processor — OpenAI ('DALL·E 3') or Google ('NanoBanana'), via the vendor-neutral AI Gateway — only where the parent has granted the image of child AI consent class in the Parent Dashboard (off by default, distinct from the voice-note permission and from the general account-creation consent), and solely to produce the image the child asked for. The provider does not use the photograph to train its models and does not retain it beyond the request. On our side the source photograph is discarded within 24 hours of the generation request; only the generated image is kept, as ordinary user-generated content on the photo-proof retention window in the table below. ConKarma does not derive a biometric template, face template, or faceprint from a child's photograph and does not use it for identification (see the biometric-data exclusion above). The parent may revoke the image of child class at any time, which stops further transmission; deleting a generated image removes it like any other content. Revoking the overall parental consent (§4) withdraws this and every other AI consent class at the same moment.

3. Retention schedule

The schedule below applies purpose-bound, child-specific data minimisation: each category of a child's personal information is retained only for as long as is reasonably necessary to fulfil the specific purpose for which it was collected, and then deleted, consistent with the amended COPPA Rule's data-minimisation requirement (16 CFR §312.10). Non-financial child content (journal and calendar entries, photos, conflict-resolution records, and similar) is retained for the life of the account and purged within the 30-day tombstone after account deletion or immediately on a verified parental delete request, whichever comes first — it is not held to the longer adult-account horizons. Only categories with an independent statutory floor (the DNA/EGO transaction ledger and audit-log entries for tax, financial-integrity, and regulatory-inspection purposes) are retained longer, and those are anonymised rather than associated with the child once the purpose ends. Finite-bounding is enforced via account lifecycle, the 30-day post-deletion tombstone, the parental delete-on-request right, and the per-category ceilings below.

4. Parental rights and procedures

Parents of child users have the following rights at any time, exercisable by writing to parents@conkarma.app from the email address recorded on the parental-consent token, or via the in-app Parent Dashboard once the child account is active:

• Right to review. Parents may request a copy of all personal information held by ConKarma about their child. Response within 30 days. Per 16 CFR §312.6(a)(1).
• Right to delete. Parents may request deletion of their child's account and all associated personal information. As of v1.1 (shipped 2026-05-23), a verified parental delete-on-request triggers the immediate PII-erasure pathway rather than the standard 30-day soft-delete tombstone. The request is gated by a super-admin two-eye review (operator A initiates, operator B approves) so that parental identity is verified against the on-file Parent record before any erasure executes, per 16 CFR §312.5(b)(2) parental-identity verification. Once approved, every PII column on the child user row (name, date of birth, contact details, photo URLs, journal entries, parent contact) is nulled in a single atomic transaction; no 30-day grace window applies. Categories with statutory retention floors (DNA / EGO ledger entries; audit log entries) are not deleted but are anonymised via cell-system-user re-attribution; the audit log of the erasure event itself is retained 7 years for regulatory inspection. The verified parent receives an email confirming the scope of erasure and the retention exceptions. Per 16 CFR §312.6(a)(2).
• Right to revoke consent. Parents may revoke the parental consent at any time. Revocation also withdraws, at the same moment, every per-class AI consent granted for the child (image of child, voice of child, conversational, text helper) — the two controls are not independent. Revocation triggers account deactivation immediately and proceeds to deletion per the right-to-delete procedure unless the parent affirmatively elects to keep the account in a read-only archived state. Per 16 CFR §312.6(a)(3).
• Right to refuse further collection. Parents may instruct ConKarma to stop collecting further personal information from the child while keeping the existing record. Per 16 CFR §312.6(a)(4).

Payment-information carve-out. Child accounts cannot complete in-app purchases. The RefuseIfChildUser middleware blocks all IAP, voucher-redemption, and ad-reward endpoints for accounts whose cell_role = "child" or whose computed age is under 13. As a consequence, ConKarma collects no payment, billing, or financial identifiers from child accounts.

5. Operational enforcement

The retention windows in §3 are not aspirational. Each row maps to a real, running code path that enforces it.

• Scheduled purge workers (deployed in production today): maintenance_service, geolocation_purge_worker, photo_proof_prune_worker, scrapbook_prune_worker, audit_chain_service.RetentionSweepOnce.
• Per-row retention metadata: consent_tokens.retention_until, geolocation_consents.retention_days, admin_audit_logs.retention_class, users.deleted_at, dna_transactions.created_at (partition column).
• Zone-isolation invariants: middleware/refuse_if_child_user.go; server-side GA4 emission gate.
• Account-delete cascade (standard pathway): helpers/coppa_legal.go + the soft-delete pipeline + 30-day tombstone hard-purge in the maintenance worker.
• Immediate PII-erasure pathway (v1.1): services/hard_delete_service.go exposed via DELETE /admin/v1/users/{id}/hard-delete with typed_confirmation + reason payload, super-admin two-eye approval gate, atomic PII-column nulling, cell-system-user re-attribution for co-owned artifacts and ledger entries, and a non-deletable audit-log entry recording the erasure event (operator identities, approval timestamps, scope). Shipped 2026-05-23.
• Statutory retention ceiling: dna_transactions monthly partitions dropped at the 84-month horizon.

6. Out of scope

• Adult-zone retention windows are governed by Privacy Policy §8.2 and are not in scope here.
• Multi-region retention addenda are deferred to v1.x; the main Privacy Policy addenda (California, EEA/UK, Quebec, Brazil, Australia) already encode regional retention deltas for geolocation.
• SIEM / external audit-log export is a Phase 2 workstream.
• Counsel-authored language in this v1.0 document. Counsel review (Phase 1) may amend any section; amendments land in v1.1 with a change-log entry.

7. Contact

Parental requests: parents@conkarma.app. General legal inquiries: legal@conkarma.app.

8. Change log