Plan AI — Parent / Guardian Consent Policy

Effective date: `TO BE SUPPLIED: effective date

DRAFT AND FORWARD-LOOKING. Unlike the other documents in this folder, this one mostly describes a mechanism that does not exist yet. It is written as a specification a lawyer can review and an engineer can build from. Sections that describe unbuilt behaviour are marked [NOT YET IMPLEMENTED]. Nothing in this document may be published as a description of current behaviour until the flow it specifies is live. See COMPLIANCE-GAPS.md §1–§3.

1. Why consent is required

Plan AI is intended for children aged roughly 8–13.

COPPA (US) requires verifiable parental consent before an operator

collects personal information from a child under 13.

GDPR Art. 8 requires consent from the holder of parental responsibility

where a child is below the applicable age of digital consent (13–16 depending on the member state).

KVKK requires a lawful basis, and for a child that is normally exercised

through the legal representative.

An email address, a display name, and a persistent account identifier are all personal information. The app collects all three at sign-up, so consent is required before sign-up completes — not afterwards.

2. What does NOT count as consent

Stated first, because the app contains something that could be mistaken for it.

The 4-digit reward PIN is not consent. Verified in services/rewardService.ts: it is stored in plaintext in the device's local database (strategic_metadata['rewardsConfig'].parentPin), has no server component, and is never linked to any adult's identity. A child can read it out of browser devtools, and a child could just as easily set it themselves.

It must never be presented — in the UI, in store metadata, or in any policy — as parental consent, age verification, or identity verification. It is a convenience lock on a settings screen.

Also insufficient on their own: an unverified "I am over 18" checkbox; an unverified "I am a parent" checkbox; an email address typed in by the child.

3. Recognised methods of verifiable parental consent

COPPA (16 CFR § 312.5(b)) recognises, among others:

Method	Notes
Signed consent form returned by post, fax, or scan	Reliable, high friction
Payment transaction	A charge (or an authorisation that notifies the account holder) on a credit/debit card
Telephone or video call with trained personnel	Operationally expensive
Government-issued ID check, promptly deleted after verification	Heavy for a children's planner
Knowledge-based authentication	Must be sufficiently difficult
"Email plus"	Email to the parent plus a second confirming step (a delayed second email, or a follow-up by phone/post). Only permitted where the child's personal information is used internally and not disclosed to third parties.

"Email plus" is probably not available to Plan AI. The app sends the child's content to Google's Gemini AI service, which is a disclosure to a third party. A stronger method is likely required. `TO BE SUPPLIED: counsel's determination on whether processor-only disclosure to Gemini defeats the "email plus" exemption.

4. The proposed flow — [NOT YET IMPLEMENTED]

Designed to be the least intrusive option that is still defensible.

Step 1 — Neutral age screen

At first launch, before any account exists, ask for date of birth (or year of birth) on a neutral screen: no illustrations implying a "right" answer, no warning that a low age loses features, no pre-filled adult default. Store only the resulting bracket, not the raw date, if the raw date is not otherwise needed.

Step 2 — Branch

13 or over (or at or above the local digital-consent age): normal sign-up.
Under 13 (or below the local age): the child cannot create an account. Show

a "ask a grown-up to set this up" screen that collects only a parent's email address and nothing about the child.

Step 3 — Parent creates and owns the account

The parent receives an email, verifies it, and creates the account in their own name. They then create a child profile under it. The parent is the account holder throughout.

Step 4 — Explicit, itemised consent

Before the child profile becomes usable, present the parent with a screen that states plainly what will be collected, and take a separate, unbundled decision on:

Core planner — account, tasks, routines, goals. Required for the app to

function.

AI planning features — that the child's typed text is sent to Google's

Gemini service. Optional; the planner must remain fully usable without it.

Photo-to-plan — that an uploaded image is sent to Google's Gemini service.

Optional and separate from (2), because the privacy exposure is materially greater.

Consent for (2) and (3) must be genuinely refusable. Bundled all-or-nothing consent is not valid consent under GDPR.

Step 5 — Record it

Store server-side, in a record only the backend can write: which items were consented to, the timestamp, the method used, the parent's verified email, and the policy version in force. This record is the evidence of consent and must survive until the account is deleted.

Step 6 — Withdrawal must be as easy as granting

A single screen in the parent area where each consent can be withdrawn independently. Withdrawing (2) or (3) disables that feature and leaves the rest working. Withdrawing core consent deletes the child profile and its data.

5. What the parent must be told before consenting

Who the controller is, and how to contact them.
Exactly what is collected — the list in PRIVACY.md §3.
That the child's content is sent to Google's Gemini AI service if the AI features

are enabled, and that this is optional.

That there is no advertising, no tracking, no profiling, and no selling of data.
That there are no social features and no way for another user to contact the child.
How long data is kept (DATA_RETENTION.md).
Their rights, including deletion, and how to exercise them.
That consent can be withdrawn at any time, without penalty.

6. Rights the parent keeps after consenting

Review the child's data · correct it · delete it and close the account · withdraw any consent item · refuse a specific feature while keeping the rest · object to legitimate-interest processing · receive a copy in a portable format.

Contact `TO BE SUPPLIED: privacy contact email address`. We verify the requester is the account-holding parent before disclosing anything, precisely to avoid handing a child's data to the wrong adult.

7. Schools

Where a school deploys Plan AI, the school normally acts on the basis of its own lawful authority for pupil data and its own parental-notification process, and should complete a data-protection impact assessment.

TO BE SUPPLIED: decide whether school deployment is offered at all. There are currently no class, roster, or tenancy features in the codebase — COMPLIANCE-GAPS.md §3.

8. Re-consent

If we materially change what we collect or who we share it with, we obtain fresh consent rather than relying on a policy-update notice.

9. Implementation checklist

[x] Neutral age screen, and storage of the age bracket — components/AgeGate.tsx.

Stores only the bracket; the raw date of birth is discarded.

[x] Parent-owned account with child profiles — types.families.ts, Dexie v5,

services/childProfileService.ts, and a users/{parentUid}/children/{childId} subcollection in firestore.rules.

[x] Itemised, unbundled consent screen (core / AI text / AI photo) —

components/ConsentFlow.tsx. Each is independently refusable and the planner stays fully usable with both AI items declined.

[x] Server-side consent record with method, timestamp and policy version.

No client path can write it — proven by four adversarial tests in test/rules/firestore.children.test.ts.

[x] Consent-withdrawal screen with per-item granularity —

components/ConsentSettings.tsx.

[x] Feature flags that actually honour a withheld AI consent — hasConsent()

in types.families.ts, which fails closed when no profile or record exists.

[x] In-app account and profile deletion — components/AccountSettings.tsx and

functions/src/accountLifecycle.ts, with a 30-day window and a scheduled purge. Also required independently by Apple 5.1.1(v) and Google Play.

[x] Data export — exportAccountData, machine-readable JSON.
[ ] Parent email verification — EmailPlusVerifier is implemented against the

ConsentVerifier interface, but see the item below: whether it is the method that gets used is not yet settled.

[ ] A chosen, counsel-approved verification method (§3) — **the one remaining

blocker.** The flow is built behind ConsentVerifier (lib/consent/verifier.ts) precisely so this decision costs a single adapter rather than a rebuild. PaymentVerifier and IdVerifier exist as deliberately-unimplemented stubs so the shape of that work is visible.

Until the final item is resolved, this app must not claim COPPA compliance, and these documents say so. Building the flow is necessary but not sufficient: what makes consent *verifiable* is the method, and that is counsel's determination.

10. Under-13 sign-up blocking — status

Not yet wired end to end. The age bracket is captured and stored, and the consent flow exists, but the boot-time branch that prevents a self-identified under-13 user from completing sign-up without a completed parental consent record should be confirmed on a real first run before release.