Privacy-by-Design: From Local AI Infrastructure to Everyday App

Purpose

JoggMini is a children-first learning app. That means privacy cannot be a legal page added at the end of development. It must shape the product architecture, the parent experience, the teacher workflow, the reward system, the subscription model, and the way learning data moves between a device and the cloud.

This article explains the privacy-by-design model behind JoggMini: how the app can support everyday learning while limiting unnecessary personal data, protecting children from avoidable account exposure, and keeping reward/progress systems auditable without turning them into surveillance systems.

The current implementation is local-first with optional cloud recovery. Some infrastructure pieces are implemented in source and migrations but still require staging, device, legal, store, and production verification before release.

1. What privacy-by-design means for JoggMini

Privacy-by-design means privacy is treated as a core engineering constraint. For JoggMini, the practical rules are:

1. Collect only what the product needs to teach, protect, and recover progress.
2. Keep children out of direct account systems when a parent-managed profile is the safer design.
3. Use local device storage where cloud storage is not necessary.
4. Use cloud synchronization only when it has a clear purpose: recovery, parent management, household access, teacher workflows, subscription entitlement, or safety/legal operation.
5. Never trust a client to award rewards, change progress, or mutate parent/teacher-owned records directly.
6. Make deletion and export behavior explicit, including what can be deleted immediately and what may require retention for safety, abuse prevention, accounting, or legal reasons.

The result is a product that is still practical for families and schools, but does not default every child action into a broad cloud identity profile.

2. Local-first learning as the default child experience

JoggMini’s learning design supports local-first child progress. A child can learn, answer questions, earn Stars, move through Tiers, and build local reward state without every interaction depending on a cloud write.

This matters for three reasons.

First, children often use shared family devices, school tablets, or low-connectivity environments. Local-first learning keeps the experience usable even when the network is unreliable.

Second, local-first storage reduces unnecessary cloud exposure. If a child is using a free local profile and the parent has not opted into recovery or account-linked management, JoggMini does not need to treat every learning session as cloud account data.

Third, local-first behavior creates a clearer safety boundary. Local progress is useful to the child on that device, while cloud recovery requires an explicit account or eligible profile relationship.

This is why the reward architecture separates local reward events, cloud synchronization eligibility, and server-authoritative reward validation.

3. Cloud recovery is explicit, not automatic for every child

JoggMini supports cloud recovery when it is appropriate:

• a signed-in parent manages a child profile;
• a subscription plan allows broader recovery or multi-device use;
• a self-managed teen profile is eligible under the age/role model;
• a teacher/classroom workflow needs authorized quiz participation or results.

The cloud layer is not treated as a dumping ground for all local activity. Instead, the app uses a policy boundary to decide whether a kid profile can sync canonical reward events and snapshots.

For example, the Freemium model permits a parent-linked recovery path for the first child, while paid plans expand recovery and device benefits. Family plans shift the benefit from one device to the household account. This makes the privacy and subscription model align: the cloud stores more because the user has asked for recovery, family continuity, or multi-device access.

4. No direct child authentication for young children

For under-13 users, JoggMini is designed around parent-managed child profiles rather than direct child-owned cloud accounts. The child profile is a learning identity inside the family account structure, not an independent account with its own email/password credential.

This is deliberate. It avoids asking children to manage adult-style account credentials, reduces personal-data exposure, and places consent/management in the parent experience.

The age gate is therefore important. A new provider identity does not automatically become a parent, teacher, or child profile without age/role classification. Ages and roles determine the safest next step:

• younger children remain parent-managed;
• teen/self-managed scenarios use a separate hybrid path;
• adults can become parent or teacher profiles;
• parent and teacher roles remain separate records even when one provider identity can access both roles.

5. Parent PIN protects the device boundary, not the cloud account

JoggMini’s parent PIN is a local protection mechanism for parent-only areas on a device. It is not a cloud password and it is not a replacement for Google or Apple authentication.

This distinction matters. A parent PIN should prevent a child using the device from entering parent controls, changing restrictions, viewing reports, managing subscriptions, or deleting data. It should not be represented as a cross-device account credential.

That is why the current architecture treats the PIN as device-local, optional, and recoverable through proper account reauthentication or reset flows. Parent authentication remains provider-based; device unlock remains a local safety boundary.

6. Server-authoritative rewards prevent cheating and accidental over-collection

The reward architecture is canonical and policy-driven. The client submits answer facts and activity context; it does not submit trusted reward amounts.

For World Lane, Daily Quest, Random Quiz, Parent Tasks, Teacher/Joined Quiz, and Arcade, the system uses stable idempotency keys and validated server rules. This has privacy benefits as well as fairness benefits:

• duplicate submissions cannot inflate rewards;
• local retries can sync safely without producing duplicate cloud records;
• reward calculations stay explainable and auditable;
• the app does not need to collect unrelated behavior signals to determine progress;
• parent/teacher reports can be based on bounded learning records rather than raw surveillance data.

The canonical reward model uses Stars, Gems, Tiers, badges, streaks, and certificates. Legacy reward-point concepts have been removed from active product UI and current key documentation; retained legacy database field names exist only for historical migration compatibility until they can be removed safely.

7. Parent and teacher access is scoped by role

Parents and teachers need different data.

A parent needs household-level child progress, tasks, settings, device recovery, subscription status, deletion/export controls, and parent-only account management.

A teacher needs classroom-scoped quiz creation, join-code management, student participation, results, and exports for authorized classroom activity.

Those should not collapse into one broad “adult can see everything” model. JoggMini’s role architecture separates parent profiles, teacher profiles, household membership, classroom membership, and active role switching. Supabase row-level security and validated RPCs are used so each role can only read or mutate the records it is authorized to access.

The practical goal is simple: a teacher can run classroom learning without gaining family-dashboard access, and a parent can manage a child without gaining unrelated classroom data.

8. Classroom joining uses limited codes, not broad discovery

The teacher flow uses six-digit join codes instead of public classroom discovery. A code is easier for students and parents, but it must still be constrained.

The intended design includes:

• active-code lookup only;
• rate limits on attempts;
• code expiry/rotation as needed;
• classroom membership records with RLS;
• teacher result views scoped to authorized participants;
• CSV/JSON exports that include only classroom-relevant fields.

This design supports everyday classroom use while avoiding searchable public student or classroom directories.

9. Subscriptions should not create advertising pressure

JoggMini is a kids app, so the business model avoids ads. That is a privacy decision as much as a product decision.

Advertising models often push products toward tracking, profiling, retargeting, and behavioral measurement. JoggMini’s subscription model is designed to fund the app without making children the product.

Freemium access provides limited world-question allowances, Daily Quest, limited quiz joining/creation, and a basic parent profile model. Premium and Family plans expand learning access, recovery, devices, kids, tasks, and co-parent support. Store purchase verification must still be completed through Apple/Google and server-side entitlement verification before production release.

10. Privacy documentation must match implementation reality

Privacy-by-design fails when documents overclaim.

The privacy policy, terms, security article, deletion document, parent guide, pricing page, and website copy must all agree with the implementation. If account deletion is implemented but backups or audit records have retention windows, the public document must say that. If local-only progress can be lost on uninstall, the document must say that. If subscription cancellation happens through Apple/Google rather than inside Supabase, the document must say that.

JoggMini’s documentation set therefore separates:

• implemented source behavior;
• authored but unexecuted migrations/tests;
• legal/security drafts that need approval;
• website copy that still needs publication;
• external store/provider setup that must be completed outside the repository.

That distinction is not bureaucracy. It prevents the product from promising a privacy or recovery behavior that has not been verified.

11. Export and deletion are product features, not hidden support tasks

Families should be able to understand what data exists and how to remove it.

JoggMini’s deletion model needs to cover:

• local device-only data;
• parent account data;
• child profile data;
• reward/progression data;
• tasks and completions;
• teacher/classroom participation;
• exports and reports;
• subscription entitlements;
• notification/device records;
• provider account linkage;
• backups and audit retention.

Some data can be deleted immediately. Some data may need a controlled job, reauthentication, parent authority, classroom ownership validation, or retention explanation. The important point is that deletion is designed into the system, not handled manually after a support request.

12. Security architecture supports the privacy model

The technical privacy model depends on security controls:

• Google/Apple provider authentication for eligible adult or teen accounts;
• parent PIN for local protected areas;
• Supabase RLS for table-level authorization;
• SECURITY DEFINER RPCs only where validated server logic is required;
• private reward commit functions that app roles cannot call directly;
• stable idempotency keys for offline/retry safety;
• immutable ledger records for canonical rewards;
• device registration and revocation for notification targeting;
• clear separation between parent, teacher, child, classroom, task, subscription, and reward domains.

Security does not replace privacy, but it makes the privacy promises enforceable.

13. What still requires verification before public claims

The source architecture is not enough on its own. Before release, JoggMini must verify:

1. migrations on staging and production-shaped data;
2. RLS and role-boundary tests;
3. provider login, age gate, role switching, and account recovery flows;
4. local/offline/reinstall recovery behavior;
5. parent PIN setup, unlock, reset, and removal;
6. subscription receipt validation, restore, cancellation instructions, and entitlement refresh;
7. push notification lifecycle, token refresh, revoked devices, and timezone behavior;
8. data export and deletion flows with audit evidence;
9. website/legal copy against the verified implementation.

Until that evidence exists, the correct public wording is “designed to” or “implemented in source pending verification,” not “proven in production.”

Conclusion

Privacy-by-design in JoggMini is not one feature. It is the sum of local-first learning, parent-managed child profiles, scoped teacher workflows, server-validated rewards, subscription instead of advertising, explicit cloud recovery, device-local parent protection, and honest documentation.

The goal is to let children learn AI concepts in a playful everyday app without forcing unnecessary account exposure or behavioral tracking. The architecture supports that goal by making privacy a default constraint, not an afterthought.