Legal

Data Retention Policy

Last updated: August 24, 2026

1. Purpose

This Written Data Retention Policy documents specific timeframes for which DaySteps LLC retains personal information collected through the DaySteps application, the business justifications for each period, and the processes by which data is deleted. Maintained in compliance with 16 CFR §312.10 (COPPA 2025 amendment, effective April 22, 2026), Quebec's Law 25, and PIPEDA.

No data governed by this policy is collected before parental consent. Guest classroom mode (designed but not yet launched) is architected so that session participants will generate no data at all — nothing to retain.

2. Retention Schedule

Data Category	Retention	Deletion Trigger	Enforcement Method	Justification
Active child profile and account data	Account duration + 30 days after deletion request	Account holder deletion request (subject to the sole-guardian safeguard, see Section 3.2)	delete_account() RPC records the request immediately (soft delete). The account holder may cancel during the 30-day grace period. The nightly purge_deleted_accounts job permanently deletes the account once the grace period has elapsed.	30-day grace period allows recovery from accidental deletion.
Routine completion and step data	Life of the child profile	Profile or account deletion	Deleted with the account through the purge pipeline (Section 3.2). No rolling time-based purge is currently implemented.	Longitudinal clinical value: completion history is deliberately preserved for the life of the profile so families and authorized professionals can see long-term patterns.
Mood and reflection entries	Life of the child profile	Profile or account deletion	Deleted with the account through the purge pipeline (Section 3.2). No rolling time-based purge is currently implemented.	Mood-routine correlation requires longitudinal data.
Inactive account (all data categories)	Retained while the account remains open	Account holder deletion request	No automated inactivity-based deletion is currently implemented. If an inactivity deletion pipeline is built, this policy will be updated before it takes effect.	Stated honestly pending a product decision; any future inactivity threshold will be disclosed here with advance notice.
Consent records and audit logs	Retained indefinitely as append-only legal records (see Section 3.2)	No automatic deletion	Append-only ledger: modification and deletion are blocked at the database layer for all app clients. When an account is deleted, references from consent records to that account are severed, but the records themselves are retained.	Regulatory demonstration of consent (COPPA / Law 25). Records contain the fact, version, and evidence of consent only — no routine or behavioral data. A maximum retention horizon after account closure is an open item for counsel.
Crash and error reports (Sentry)	Sentry platform default (not separately configurable on DaySteps' current plan)	Sentry platform auto-purge	Managed by Sentry. DaySteps applies key-based redaction before events are sent.	Crash diagnostics only. Redacted events may still include device metadata and app breadcrumbs (disclosed in the Privacy Policy).
Authentication credentials and push tokens	Life of the account (password hashes, push tokens); provider-managed (Apple / Google sign-in tokens)	Account deletion	Sign in with Apple and Google Sign-In tokens are managed by those providers. For email/password accounts, a salted password hash is stored by DaySteps' authentication layer (Supabase Auth). Apple push (APNs) device tokens are stored with backend-only access; hashed copies in the push-delivery-failure log are purged after 30 days.	Authentication and notification delivery.
Classroom records and rosters (classes, and the child profiles linked to them)	Life of the educator's account — open item	Educator account deletion; deletion of a linked child's profile removes that child's roster entry	Deleting a class marks it inactive rather than removing it, and removing a child from a class marks the roster entry removed — both rows are retained. Rows are permanently deleted when the educator's account is purged (Section 3.2), which cascades to the roster and join codes; deleting a child's profile removes that entry by cascade. No time-based purge exists for inactive classes or removed entries — open item.	Continuity across a school year, and a durable record of which guardian approved each roster entry. A purge schedule for inactive classes and removed entries is an open item.
Classroom join codes	Redeemable for 30 days; the row is retained for the life of the class	Expiry 30 days after issuance (redeemability); class or educator account deletion (the row itself)	Codes are issued with a 30-day expiry and cannot be redeemed after it — the same window as invite codes. Any extension is capped at seven days by a database rule. App clients can read codes but cannot delete them; expired and redeemed codes are removed only when the class is deleted with the educator's account (database cascade). No purge of expired codes exists — open item.	Secure classroom enrollment. A code carries a class reference, a six-character string, and timestamps — no child data.
Classroom session records (live session state and per-child participation)	Life of the class — open item	Educator account deletion; deletion of a participating child's profile removes that child's participation rows	Ending a session marks it ended rather than deleting it, and neither the app nor any scheduled job removes ended sessions or their participation rows. They are deleted when the educator's account is purged (Section 3.2), and a child's participation rows are deleted with the child's profile by database cascade. No rolling time-based purge is implemented — open item.	Educators reviewing how a session went. Participation rows hold step counts and timestamps, not routine or mood content. A retention limit for ended sessions is an open item.
Classroom routine assignments (routines an educator has pushed to a class)	Until the educator unassigns the routine, or the educator's account is deleted	Unassignment by the educator; educator account deletion	Changing which classes a routine is assigned to deletes the records for unassigned classes outright and writes new ones for newly assigned classes — superseded assignments do not accumulate. Assignments still in place are deleted when the educator's account is purged (Section 3.2). Marking a class inactive does not remove its assignments — open item.	The assignment is what makes a classroom routine available to a class. It holds a copy of the routine template the educator sent, not child data.
Guest classroom session data (feature designed, not yet launched)	Not retained	N/A — nothing collected	N/A	COPPA-invisible. No data exists to retain.
Focus sessions and to-do items	Life of the profile or account	Profile or account deletion	Deleted with the account through the purge pipeline (Section 3.2).	Service functionality (focus timer history, to-do lists).
Imported calendar events (Google / Outlook mirror copies)	While the account remains active	Account deletion	Stored in the primary Canadian database; deleted with the account.	Calendar display and scheduling features.
Spotify authorization token (optional Focus-timer music)	While the connection remains active — no separate lifecycle	Disconnecting Spotify, Spotify refusing the token, or account deletion	This is a column on your existing account record rather than a table of its own, so it has no retention period apart from the account's. It is cleared to null immediately when you disconnect Spotify, and cleared automatically by the server-side token function whenever Spotify stops accepting it. It carries no read permission for the app or any signed-in browser session, and client writes are blocked by a database trigger. On account deletion the nightly purge deletes the account row itself, which removes this column with it — there is no Spotify-specific step in the purge and none is needed. Note that DaySteps clearing its copy does not revoke the grant at Spotify; you can withdraw DaySteps' access from your Spotify account settings.	Keeping the optional Spotify audio source working without holding a client secret inside the app.
Website contact-form submissions	No automated purge currently implemented — open item	None currently	Retained to answer your enquiry and to keep a record of what was asked; a purge schedule is an open item. Submissions are written only by the server-side function behind the form, and row-level security is enabled on the table with no read policy at all — no browser or app session can read them back, including a signed-in one. They are not linked to any account record that would remove them, so they persist until a purge is built or you ask us to delete them (privacy@daysteps.app).	Answering enquiries sent through the website contact form. Holds the name, email address, role and message submitted; no child content.
Onboarding survey responses	Life of the account	Account deletion	Deleted automatically with the account (database cascade).	One-time survey; product improvement.
Waitlist email addresses	No defined retention period — open gap	Manual request	Manual deletion on request (privacy@daysteps.app). A defined purge policy is an open item.	Interest list collected before the App Store release on 10 August 2026. No longer being added to from a pre-launch page.
Security and rate-limit logs (invite-code, sign-in, and classroom join-code attempt records)	No automated purge currently implemented — open item	None currently	Retained for abuse prevention; a purge schedule is an open item. Classroom join-code attempts are written only by the server-side lookup functions that enforce the limit, are readable by no app client, and are not linked to any account record that would remove them — so they persist until a purge is built.	Fraud and abuse prevention. Contain device fingerprints, an account identifier, timestamps, and whether the attempt succeeded; no child content.
Push-delivery-failure log	30 days	Rolling	Nightly purge job (04:00 UTC). Push tokens are stored as hashes.	Notification delivery diagnostics.
Inbox items (in-app coordination messages)	Until per-item expiry or account deletion	Item expiry or account deletion	Items carry a per-item expiry timestamp after which they are no longer surfaced; rows are deleted with the account. No dedicated expired-row purge job currently runs — open item.	Family / care-team coordination.
Invite codes	30 days	Expiry 30 days after issuance	Codes cannot be redeemed after expiry; unredeemed codes are removed with the issuing account.	Secure device linking and connection setup.
Provisional child profiles (setup not yet completed)	Until activated or cleaned up	Activation on invite redemption; abandoned-setup cleanup	Profiles are created in a provisional state after consent and become active when a linked device redeems the invite. Abandoned setups are captured by the nightly cleanup jobs (Section 3.1); no dedicated provisional-profile sweep exists.	Consent always precedes creation; the provisional state limits access until activation.
Anonymous and abandoned accounts	7 days (anonymous); nightly cleanup (abandoned onboarding, orphaned device accounts)	Automated	Nightly jobs (Section 3.1).	Hygiene for accounts that never completed setup.

3. Deletion Processes and Enforcement

3.1 Automated Deletion — Daily Jobs

The following pg_cron jobs run automatically in the Supabase CA project (ejcotfjluztmtuslpwgs) every day without manual intervention:

Job	Schedule (UTC)	What It Does
purge_deleted_accounts	03:15 daily	Permanently deletes accounts whose 30-day deletion grace period has elapsed. Re-checks the sole-guardian safeguard at purge time; family-shared records that another guardian still needs are reassigned to an internal sentinel account rather than destroyed. Logs each run to integrity_check_log.
prune-orphaned-anonymous-accounts	02:00 daily	Deletes anonymous accounts older than 7 days with no references from any dependent table.
expire-pending-suggestions	02:00 daily	Marks pending Care Team suggestions expired once their expiry time has passed. This job changes a status rather than deleting anything; the suggestion records themselves are removed with the account.
cleanup-orphaned-devices	03:00 daily	Removes device-authentication accounts no longer linked to any child device.
cleanup_anonymous_auth_users	03:30 daily	Purges anonymous authentication users after 30 days.
cleanup_abandoned_onboarding_accounts	03:45 daily	Removes accounts abandoned partway through onboarding.
purge_push_delivery_failures	04:00 daily	Deletes push-delivery-failure log entries older than 30 days.
check-connection-auth-lookup-integrity	06:00 daily	Verifies the authorization lookup table used by access control; results are logged to integrity_check_log.
repair-connection-auth-lookup-drift	06:15 daily	Automatically repairs drift detected by the integrity check.
monitor_child_profiles_age_group	06:30 daily	Monitors child profile age-group values for consistency with consent requirements.

Note: Scheduled job runs are logged to an internal integrity_check_log table (job outcome and record counts). There is no separate deletion_audit table. Job logs record execution outcomes, not per-record detail.

3.2 Account-Holder-Initiated Deletion

Account holders may request deletion of their account and associated data at any time. The process:

• The account holder navigates to Settings > Delete Account in the DaySteps app.
• A confirmation flow explains that the account will be scheduled for deletion, that deletion becomes permanent after a 30-day grace period, and that it can be canceled from the same screen during that window.
• The account holder confirms, and the delete_account() RPC records the deletion request server-side (soft delete). If the requester is the sole active guardian of a child profile, the request is refused with guidance to first add another guardian or remove the child profile (sole-guardian safeguard).
• The request takes effect immediately: the account is marked for deletion and write access is blocked. Permanent deletion is performed by the nightly purge_deleted_accounts job once the 30-day grace period has elapsed.
• The account holder is signed out automatically.

During the 30-day grace period, the account holder may cancel the deletion (cancel_account_deletion), fully restoring the account. At purge time, the sole-guardian safeguard is re-checked; where a co-managed child has another active guardian, records shared with that guardian are preserved by reassignment to an internal sentinel account rather than destroyed.

Deletion requests are fulfilled when the nightly purge next runs after the 30-day grace period ends — no later than 31 days from the request. For requests received via email (privacy@daysteps.app), DaySteps will confirm completion in writing.

Consent records associated with the account are retained as append-only legal records after account deletion — these records contain no routine or behavioral data, only the fact, version, and evidence of consent events. (See Section 2; a maximum post-closure retention horizon is an open item for counsel.)

3.3 Revoked Connection Data

When a parent revokes a Care Team member's or teacher's access:

• The connection is immediately marked as revoked. Access terminates without delay.
• Historical data the authorized party previously viewed is not deleted from the parent's account — the parent retains it.
• The authorized party loses all access to the child's data immediately and permanently.

4. Data Residency

All DaySteps user data is stored in Canada (AWS ca-central-1, Montreal region) via Supabase Inc. No personal information is transferred outside Canada for primary storage.

Ancillary flows outside Canada:

• Sentry (US): redacted crash reports. Key-based redaction is applied before sending; events may still include device metadata and app breadcrumbs.
• Apple (US): authentication and push notification (APNs) delivery. Routine-tied push payloads may carry the child's first name and routine name in transit through Apple's infrastructure.
• Google (US): authentication; imported Google Calendar events are stored in DaySteps' Canadian database (see Section 2).
• Microsoft (US): Outlook calendar authentication; imported events are stored in DaySteps' Canadian database.
• RevenueCat (US): subscription receipt and entitlement processing, keyed to an internal account identifier (no name or email).
• Resend (US): transactional account email (sign-up confirmation, password reset) sent via Supabase Auth's custom SMTP configuration — recipient email addresses transit Resend's US infrastructure.
• Follow-Along push relay: a DaySteps-operated relay service designed to hold push tokens and family/child identifiers. It is not currently reachable from the shipped app; its hosting region is unverified — open item pending its production rollout.

5. Rights of Account Holders and Parents

6. Policy Updates

Material changes to this policy will be communicated through the app with 30 days' advance notice. The effective date above will be updated.