Children's privacy (COPPA) — requirements

Epic — release gate. MVP-1 requirements for the child-privacy goal (see the feature architecture). These are pass/fail launch conditions, audited each release and continuously in production. Not legal advice — counsel must sign off, especially under the FTC's 2025 COPPA amendments.

Type	Non-functional (compliance gate)
Layer (build approach)	Cross — verifiable-consent flow + data-min + parental controls (UI + SDK + RLS)
RICE	R 10 × I 3 × C 80% / E 5 = 4.8 · Tier MVP-1 (legal blocker) — re-score pending: full VPC raises Effort and lowers Confidence (see Open decisions)
KPI (summary)	100% verifiable-consent capture before child-data collection · zero child-marketing events — see Success criteria
Traces to	feature childrens-privacy-coppa · Personas / authz · Terms & consent · C4 auth + data layer
Depends on	Personas / authz (child kind + parental control) · Terms & consent (consent records) · Account (parent is the account holder) · Analytics (no-child-marketing gate)

Policy (the governing decision)

Under-13 children participate — by design — so they can do their own chores. A per-child record (wallet, goals, completions, name, age) is a persistent identifier + personal information under COPPA, so we operate inside COPPA's verifiable-parental-consent regime rather than trying to avoid it. That is workable because the parent creates and controls the child's account:

• Parent-created, parent-controlled. Children never self-register; a parent creates the child member and is the account holder.
• Verifiable parental consent (VPC) before collection. No child PII is persisted until a VPC record exists for that child, tied to the consenting parent.
• Data minimization. Only what the economy needs — display name, emoji, age band, wallet/goals. No contact info from the child, no precise geolocation.
• Never any marketing to a child. No behavioral profiling, ads, or promotional surfaces; no child data sold or shared with third parties for ads.
• Parental control. The parent can review and delete the child's data and revoke consent at any time.
• Supervised action (the primary way a child uses the app). A child acts under the authenticated parent's session — on the parent's phone, a shared tablet, or the TV — to sign off their own chores, with per-action parent approval where required. Consistent with the consent already granted; there is no standalone child session and no separate child login. (The TV dashboard is one surface of this, not a special case.)

Success criteria (definitive KPI)

Success = these gates hold at 100%, verified each release and sampled continuously in production:

• Consent: 100% of under-13 child members have a recorded VPC before any child data is collected → zero child records written without a consent record.
• No child marketing: zero analytics/ad events carrying a child identifier or targeting a child; zero child data shared with third parties.
• Parental control: 100% of parent deletion/revocation requests fulfilled within the stated SLA; data-minimization schema review passes.

Window: continuous; every release must re-prove the gates before ship. A single violation fails the gate (no ramp, unlike a functional KPI).

Measurement & audit

Instrument the gate so it is provable (consent-gated substrate; no child PII in any payload — child references are opaque/hashed):

Event	When	Key properties
child_consent_captured	parent completes VPC for a child	parentRef, method, consentVersion, timestamp
child_member_created	child record written (must follow consent)	parentRef, consentRef (required)
child_data_deleted	parent deletes child / revokes consent	parentRef, scope
tv_child_bounty_optin	child opts into a bounty on TV	parentAuthenticated, parentApproved — no child PII
(audit)	release + nightly	assert 0 child-marketing events and 0 child records lacking a consentRef

Non-functional requirements

NFR-COPPA-1 — Parent-created child accounts only

Priority: P1 · Status: 🔨 to build Statement. A child member exists only via a parent (no self-registration); the parent is the controlling account holder. Acceptance — Given an unauthenticated user When they attempt signup Then only an adult account is creatable; children are added by a parent.

NFR-COPPA-2 — Verifiable parental consent before child-data collection

Priority: P1 · Status: 🔨 to build Statement. No under-13 child PII is persisted until a verifiable-parental-consent record exists for that child, tied to the parent and a consent version. Acceptance

• Given a parent adding a child When VPC has not been captured Then no child record / PII is written (child_member_created requires a consentRef).
• Given VPC captured Then a consent record (method, parent, version, timestamp) is stored and auditable.

NFR-COPPA-3 — Data minimization for child members

Priority: P1 · Status: 🔨 to build Statement. Only fields the economy needs are stored for a child (name, emoji, age band, wallet/goals); each retained field has a documented purpose; no child contact info or precise location.

NFR-COPPA-4 — No marketing to children; no third-party child data

Priority: P1 · Status: 🔨 to build (analytics + UI gate) Statement. No behavioral ads, profiling, or promotional surfaces target a child; no child data is sold/shared with third parties; analytics emits zero child identifiers. Acceptance — Given any child interaction When analytics fires Then no event carries a minor identifier or marketing flag, and no child-facing view renders a promotional surface.

NFR-COPPA-5 — Parental review, deletion, and consent revocation

Priority: P1 · Status: 🔨 to build Statement. A parent can review the child's collected data, delete it, and revoke consent; revocation stops further collection. Acceptance — Given a parent revoke/delete request When executed Then the child's PII is erased, collection stops, and the action is logged (child_data_deleted).

NFR-COPPA-6 — TV supervised action under granted consent

Priority: P1 · Status: 🔨 to build Statement. On the TV dashboard a child acts under the authenticated parent's session with per-action approval; this rides the consent already granted, not a new standalone collection. Acceptance

• Given the TV with a parent authenticated and prior child VPC When the child opts into a bounty Then a parent-approval step commits the opt-in.
• Given no authenticated parent Then the opt-in is blocked.

NFR-COPPA-7 — Kids' privacy policy + child-data security

Priority: P1 · Status: 🔨 to build Statement. A published privacy policy discloses under-13 practices (what is collected, why, parental rights); child data is encrypted and access-scoped.

NFR-COPPA-8 — Versioned consent + re-consent on material change

Priority: P2 · Status: 🔨 to build Statement. Consent is versioned; a material change re-prompts the parent before continued child-data processing (ties to Terms & consent).

Architecture considerations

• Consent gates collection in the SDK service, not just the UI: the service refuses to persist child PII without a valid consentRef — enforced in the local service (offline) and server-side (cloud RLS / policy), so the rule can't be bypassed by a direct write.
• Consent record is a first-class entity (parent, child, method, version, timestamp) joined to the child member; deletion cascades child PII.
• Persistent-identifier reality: the per-child member id + name/age make the record PI — there is no "anonymous per-child" shortcut; minimization + consent + no-ads are the controls, not anonymity.
• Supervised-action path (TV) needs a first-class "acting-as-child under parent session + per-action approval" concept in Personas / authz; actor ≠ authenticated principal.
• Analytics PII-scrubbing is a hard pre-emit filter for minors at the substrate; no event type can leak a child identifier or reach a third party.
• Household-scoped RLS already isolates data; child records carry no cross-household exposure.

Design work (ahead of build)

• The VPC flow — the actual verifiable-consent UX (card-transaction on paid / email-plus on free / e-sign), including the pre-collection gate and the "consent pending" state.
• Parent-adds-child step wired to the consent gate (no child record before consent).
• Parental data dashboard — review / delete child data, revoke consent.
• TV supervised-bounty opt-in + parent approval interaction on a lean-back display.
• Child-facing-views audit — a design checklist proving no promotional surfaces.

Decisions (resolved for MVP-1)

Resolved — see the MVP-1 decisions log for the canonical record, rationale, and status legend (✅ decided · ⚖️ counsel confirms · 🔜 MVP-1.x).

• D-COPPA-1 — VPC method. ⚖️ Email-plus (free, internal-use-only) + card-on-file (paid) (anchor); counsel confirms. Drives NFR-COPPA-2.
• D-COPPA-2 — 2025 FTC amendments. ⚖️ Adopt data-retention limits + separate consent for any third-party sharing + a written security program as design requirements (folded into NFR-COPPA-3/4/7). Counsel confirms scope.
• D-COPPA-3 — Teens (13–17). ✅ Handled in the deferred Privacy & GDPR feature, not MVP-1 COPPA; MVP-1 treats all minors under the parent-supervised / VPC model. CCPA 13–15 opt-in + GDPR-K flagged as forward items.
• D-COPPA-4 — Re-score. ✅ Done — re-scored RICE 4.8 → 2.1 in the prioritization matrix (C 80% → 50%, E 5 → 7); stays MVP-1 as a legal blocker.

Out of scope (MVP-1)

• GDPR-K erasure/portability SLAs → Privacy & GDPR (pre-EU).
• General admin audit-log surface → Audit log (the consent record is in scope; the broad audit view is not).