Privacy Policy
Mental Offload ("the App", "we", "us", or "our") helps couples manage household responsibilities. This policy explains what personal data we process, why we process it, who receives it, how long it is kept, and your rights.
The App keeps a working copy of household data on your device using Apple SwiftData so it can remain responsive and tolerate temporary connection loss. The public launch service also requires a Mental Offload account and synchronizes supported data through Supabase. Local-only builds are development configurations, not the public launch architecture.
1. Data Controller
Name: Adam Khelifi
Operator status: Individual operator, not registered in CVR
Location: Denmark
Contact: [email protected]
2. Data We Process
2.1 Data kept on your device
| Data | Examples and purpose |
|---|---|
| Names and preferences | Your name, partner name, language, appearance, default owner, view mode, and notification choices. |
| Tasks and subtasks | Titles, descriptions, due dates, status, ownership, work type, estimates, actual time, completion state, and recurrence. |
| Responsibilities and categories | Titles, descriptions, category, ownership assignments, and active/archive state. |
| Routines and routine blocks | Titles, descriptions, schedules, reminders, start times, durations, owners, order, and notes. |
| Appointments | Titles, descriptions, location, time, all-day state, audience/owner, recurrence, and reminder preferences. |
| Offload data | Quick-capture items, notes, and task-draft metadata used before an item becomes a synced entity. |
| Technical state | Session, queue, migration, analytics-choice, diagnostics-queue, and other app-operating state. |
Offload items and Offload task drafts are local by default and are not in the current active domain-sync table set. If you convert one into a task, responsibility, routine, or appointment, the resulting entity can be synchronized. A full data export includes the current device's Offload queue/drafts in a local JSON snapshot and may also include historical server-side Offload rows in the separate cloud ZIP.
2.2 Account, profile, and couple data
The launch service uses Sign in with Apple and Supabase authentication. We process:
- Apple-provided user identifier, identity token, and email when Apple makes it available;
- Supabase user ID, account email, session tokens, and session expiry;
- couple and membership identifiers, role, and status;
- your name and partner name;
- invited partner email, invite token, expiry, status, and acceptance details.
Authentication tokens are stored in the device Keychain. Supabase receives the Apple identity token and nonce to establish the authenticated session.
2.3 Cloud-synchronized household data
The current active sync set includes categories; responsibilities and assignments; recurrence rules; routines and routine blocks; tasks and subtasks; appointments and per-member appointment reminder preferences; and work-follow records used for notification delivery.
These records include stable entity, user/member, and couple identifiers, relevant content and scheduling fields, timestamps, soft-deletion state, and actor metadata. Cloud writes also create an item-change history containing changed fields and old/new values or row snapshots so changes can be synchronized and audited.
2.4 Notifications
If you enable notifications, the App sends Supabase the APNs device token and environment; notification enablement and delivery modes; digest, quiet-hours, daily-brief, and partner-brief preferences; time zone; language; your name; and partner name.
Some transmitted preference fields are not yet used by the server, but they still leave the device and are covered by this policy. Apple Push Notification service receives the notification payload. A partner notification can include the actor's display name and routing identifiers, but Mental Offload does not send the task title in that payload.
2.5 Billing
When billing is enabled and you buy a subscription through Apple, we process Apple transaction/original-transaction identifiers, plan and entitlement status, billing period, grace/revocation state, and account/couple linkage. Apple receives a Mental Offload user UUID as the StoreKit app-account token. We do not receive payment-card details or Apple account credentials.
2.6 YAP voice processing
YAP is active and runs only when you choose the voice action, grant microphone access, record, and submit audio.
The App sends the YAP Supabase Edge Function the temporary audio recording, active responsibility titles, transcription language, a stable installation identifier, and account authentication when signed in. The Edge Function sends the audio and language to OpenAI for transcription, then sends the full transcript and responsibility titles to OpenAI for structured extraction.
Mental Offload does not persist raw audio or the full transcript in Supabase. The temporary local audio file is deleted after processing or cancellation. Extracted Offload item titles are stored locally; if no item is extracted, the App can use up to the first 80 transcript characters as a local fallback title. OpenAI's provider-side retention rules still apply. OpenAI states that API data is not used to train models unless the customer opts in, but abuse-monitoring logs and application state can be retained according to endpoint and project data-control settings.
2.7 Optional first-party usage analytics
The App does not record or send product/performance analytics until you explicitly enable them. If enabled, it sends allowlisted events to Supabase to understand feature use, onboarding, and performance.
| Data | Examples |
|---|---|
| Product interaction | Screen/flow/step, task created or completed, routine/appointment action, YAP outcome, paywall, auth/invite/sync/export action. |
| Performance | Measurement name, duration, threshold, counts, and whether a path was slow. |
| Technical context | App version/build, OS, device family, locale, environment, timestamp, and session ID. |
| Pseudonymous identity | Server-side keyed hashes derived from installation, verified user, and verified couple identifiers. |
Raw installation and reported couple identifiers travel to Supabase so the server can validate and hash them; authenticated requests also expose the verified account to Supabase. Analytics rows store keyed hashes. Raw IP addresses are used transiently to derive rate-limit hashes.
Analytics rejects sensitive property names and redacts common bearer tokens, JWTs, token query values, and email patterns. It is designed not to include names, task/description content, notes, responsibility/routine titles, invite tokens, YAP audio, or transcripts. You can disable analytics in Settings; disabling stops capture and clears pending local events.
2.8 First-party error, crash, and hang diagnostics
Diagnostics are separate from optional analytics and are enabled for reliability and security. The App can send Supabase error message/type/domain/code/fingerprint; severity and handled/fatal state; source location; bounded stack, underlying error, context, breadcrumb, and tag data; app/OS/device/locale/time-zone context; session and stable installation identifiers; verified user/couple identifiers for some signed-in errors; and MetricKit crash, exception/signal/termination, and hang summaries.
MetricKit reports omit current user/couple attribution, current breadcrumbs, and bearer token, but still include installation/session and device diagnostics. Automated sanitizers remove credential-shaped keys and common bearer/JWT/query-token/email patterns and truncate payloads. We do not intentionally include household content, but automated redaction cannot guarantee removal of every arbitrary name, title, note, transcript fragment, or other value if a failing path placed it in an error, context, or breadcrumb.
2.9 Website visits, hosting, and cookies
The public website is hosted by OpenAI through ChatGPT Sites. When you visit it, the hosting service receives the information needed to deliver and protect the site, including your IP address, request date and time, requested page, browser and device information, and security or diagnostic data. Mental Offload does not add third-party analytics, advertising pixels, or cross-site tracking to the website, and its site code does not read these host-set cookies or combine them with your App account.
The ChatGPT Sites origin uses these first-party cookies before the website code runs. Mental Offload's customer-controlled Cloudflare edge filters the undocumented visitor cookie from the public response:
| Cookie | Provider and purpose | Duration observed on 11 August 2026 |
|---|---|---|
__cf_bm | Cloudflare, acting through the hosting service, uses this cookie for bot detection and website security. Cloudflare describes it as strictly necessary. | About 30 minutes. |
__Host-appgarden-visitor | ChatGPT Sites uses a unique visitor identifier as part of operating the hosted site. Mental Offload does not use it for advertising or its own analytics. A customer-controlled Cloudflare Worker removes it from origin requests and responses and sends a deletion instruction when an older copy is presented. | About 90 days at the origin; not retained after the verified public response. |
No cookie preference is currently available because the website does not intentionally use optional cookies. A consent banner would be required before any analytics, advertising, personalization, or other non-essential storage is added. A banner implemented in Mental Offload's page code cannot prevent cookies that the hosting layer sets before that code runs. The customer-controlled Cloudflare edge was verified on 12 August 2026: clean requests retained no __Host-appgarden-visitor, and a synthetic older copy received the exact deletion cookie.
2.10 Website waitlist
The current public website does not provide a waitlist form. If a waitlist form is made available again and you choose to join it, we process your email, consent record, browser locale, signup source, page path, request/confirmation timestamps, request count, and confirmation status. IP and email-domain values are used transiently to derive rate-limit hashes. Resend receives the email address and confirmation message when confirmation delivery is enabled.
If an address was previously archived or removed, another public form submission records a rejoin request but does not reactivate the address. We use an atomic delivery claim to suppress concurrent duplicate owner-verification/support messages, and reactivation requires confirmation through support. If delivery fails or the provider's delivery result is uncertain, a later explicit rejoin request may trigger another verification message.
2.11 Data exports
A full export requires a signed-in session and fresh Sign in with Apple authorization. Supabase first generates a private cloud ZIP containing relevant account/profile, couple, billing, synchronized household, requester-visible current or historical server Offload, item-history, requester notification-delivery, analytics, diagnostic, retained project/section, and visible orphan recurrence-rule/history records.
After download, the App creates a JSON snapshot of the current device's local work, preferences, actual Offload queue/drafts, and routine occurrence completions/owner overrides. The App packages that JSON beside the untouched cloud ZIP and a top-level manifest in one ZIP; the local JSON is created on-device and is never uploaded during export preparation.
The export excludes authentication/session/APNs/invite bearer tokens, partner-private task, appointment, reminder, history, and notification data, pending task graphs whose current cloud visibility cannot be proven, other members' notification-delivery rows, service secrets, internal quota and sync-repair rows, provider retry details, raw Apple event payloads, diagnostic stacks/context/breadcrumbs, and selected external billing identifiers. The App requires a fresh successful visibility refresh before it packages device data. The signed cloud link lasts 15 minutes; the private server file expires after 72 hours and is removed by server cleanup. App-managed temporary cloud/full ZIPs become eligible for deletion after 72 hours and are removed during a later download/export cleanup pass. Copies you save or share remain under your control.
2.12 Data we do not collect or use
- We do not collect precise or coarse location, contacts, health/fitness data, or browsing/search history.
- We do not receive payment-card details.
- We do not use IDFA, advertising SDKs, data brokers, targeted advertising, or cross-app/cross-website tracking.
- We do not sell or rent personal data.
- We do not use third-party analytics or crash-reporting SDKs. We do use the first-party analytics and diagnostics disclosed above.
- Mental Offload does not add website analytics or advertising cookies. The host-set website cookies and hosting data are disclosed in Section 2.9. Visual assets are served from the Mental Offload website origin.
- The Apple privacy manifest declares tracking as false.
3. Why We Process Data
| Activity | GDPR Article 6 basis | Reason |
|---|---|---|
| Account, sync, household features, preferences, notifications, exports, and billing | Contract performance, Art. 6(1)(b) | Needed to provide requested App features. |
| YAP voice processing | Contract performance, Art. 6(1)(b) | Necessary to provide voice-to-task conversion when you actively request and submit a recording. Microphone permission is a device permission, not a separate GDPR consent record. |
| Website delivery, security, and technical diagnostics | Legitimate interests, Art. 6(1)(f) | Needed to deliver and protect the public website, prevent abuse, and diagnose failures. Any non-essential cookie or similar technology requires prior consent. |
| Website waitlist and launch emails | Consent, Art. 6(1)(a) | You choose to join and receive messages. |
| Optional usage analytics | Consent, Art. 6(1)(a) | No capture occurs until you explicitly enable it. |
| Error/crash/hang diagnostics and abuse prevention | Legitimate interests, Art. 6(1)(f) | Secure, diagnose, and improve service reliability with minimization and redaction. |
| Couple invitation email | Legitimate interests, Art. 6(1)(f) | Delivers an invitation you ask us to send. |
| Legal, tax, dispute, and fraud records | Legal obligation, Art. 6(1)(c), or legitimate interests, Art. 6(1)(f) | Comply with law or establish, exercise, or defend claims. |
The GDPR is supplemented in Denmark by the Danish Data Protection Act. If processing genuinely requires consent, you may withdraw it without affecting earlier lawful processing.
4. Recipients and Processors
Supabase
Receives account/authentication, synchronized household/couple, item-history, notification, billing, waitlist, transient YAP, optional analytics, diagnostic, and export data for authentication, storage, Edge Functions, sync, notifications, analytics/diagnostics, abuse prevention, and exports. The configured Mental Offload region is AWS eu-west-1, Ireland. Supabase privacy policy.
Apple
Receives Sign in with Apple requests and credentials, purchase requests and app-account token, and APNs notification payloads/device tokens for authentication, payments/subscriptions, and push delivery. Apple acts as an independent controller for payment services. Apple privacy policy.
OpenAI for YAP
Receives YAP audio/language for transcription and transcript/responsibility titles for structured extraction. OpenAI privacy policy.
OpenAI Ireland Ltd, ChatGPT Sites, and Cloudflare
Receives website requests, IP address, request time, requested page, browser/device information, security and diagnostic data, and host-set cookie identifiers to host, deliver, maintain, secure, and diagnose the public website. Cloudflare provides security and delivery infrastructure within the hosting service. OpenAI Ireland Ltd is the contracting processor for an EEA-based operator under the current Sites Terms and Sites DPA. ChatGPT Sites does not currently offer data-residency controls. The Sites DPA includes contractual transfer safeguards, including Standard Contractual Clauses where applicable. See the OpenAI privacy policy, ChatGPT Sites terms, ChatGPT Sites DPA, and Cloudflare cookie information.
Resend
Receives authentication, partner invitation, waitlist, operational-alert, and support email addresses and the email content needed for transactional delivery or support receipt. Support messages sent to [email protected] are forwarded as bounded plain text to the operator's private support inbox; attachments remain in Resend Receiving. Mental Offload keeps only a minimal 30-day webhook-delivery record with provider identifiers, event type, status, and timestamps, not message bodies or addresses. The selected sending region is AWS eu-west-1 in Ireland; Resend states that account data, email metadata, logs, and API records remain stored in the United States. See the Resend privacy policy and Resend DPA.
Google Gmail
Receives the support sender address, subject, and bounded plain-text message body forwarded from Resend so the operator can read and answer support mail. Attachments are not forwarded. See the Google privacy policy. The operator approved this production support-inbox route on July 21, 2026. It remains subject to the applicable Google account terms, retention rules, and international-transfer safeguards; that approval is not represented as execution of a formal Google Cloud data-processing agreement.
We do not sell, rent, or trade personal data. Some processors may use infrastructure outside the EEA. Applicable data-processing agreements and transfer safeguards, such as adequacy arrangements or Standard Contractual Clauses where required, must be verified as part of the public-release checklist. YAP or email processing must not be treated as launch-ready until that verification is complete.
5. Retention
| Data | Retention |
|---|---|
| Local App data | Until you delete it through the App or remove the App, subject to copies you export/share. |
| Active cloud data | While your account/service relationship is active and as needed to provide the service. |
| Soft-deleted synchronized rows | A cleanup function uses a 45-day cutoff, but no automatic production schedule was verified. Do not treat the limit as guaranteed until deployment is verified. |
| Invite tokens | Default expiry is 72 hours; expired rows may remain until operational cleanup. |
| Waitlist | Until you withdraw, unsubscribe, request deletion, or the waitlist is no longer needed. |
| Website host cookies | __cf_bm lasts about 30 minutes. __Host-appgarden-visitor was observed at the origin with an expiry of about 90 days, but the customer-controlled public edge now suppresses it and deletes an older copy. |
| Website hosting and security logs | Retained by the hosting provider under the ChatGPT Sites agreement and data-processing terms for as long as needed to host, maintain, secure, and support the site. OpenAI does not publicly specify a fixed operational log period for Sites. |
| Billing/legal records | As needed for subscription administration, disputes, tax, fraud prevention, or legal duties. |
| Usage analytics | Up to 13 months, then deleted or aggregated. |
| Diagnostics | No longer than reasonably necessary. Six months is the intended automatic ceiling, but the cleanup migration is not yet production-verified. |
| Terminal notification event history | The pending cleanup uses 90 days for sent and skipped rows. pending, sending, and failed rows are not age-deleted. The cleanup is not yet production-verified. |
| Item-change history | The pending cleanup uses a 12-month ceiling. It is not yet production-verified. |
| YAP audio/transcript in Mental Offload systems | Temporary processing only; not persisted in Supabase. OpenAI endpoint/project retention applies. |
| Completed Resend webhook ledger | 30 days. Support message bodies and addresses are not stored in this ledger. |
| Data-export ZIPs | Server cloud file expires after 72 hours and is removed by server cleanup; signed cloud link lasts 15 minutes. App-managed temporary cloud/full ZIPs become eligible after 72 hours and are removed during a later download/export cleanup pass. |
| Authentication session | Until expiry, sign-out, account deletion, or revocation. |
Account deletion has role-specific shared-data effects:
- A partner who deletes their account deletes that Auth account and their couple-scoped private tasks, private appointments, Offload data, settings, and membership. Shared work assigned to that partner remains for the owner as shared work without an assigned member.
- An owner who deletes their account deletes that Auth account and the complete couple data graph, including both members' couple-scoped private data. The linked partner's Auth account is not deleted, but it is disconnected from the deleted couple.
- Completed server data-export archives that are still represented by request metadata are deleted through the Storage API before the related account or couple rows are removed. Database teardown is refused while a discoverable archive path remains.
- Sign in with Apple token revocation is attempted for the requesting user when fresh authorization is supplied. App Store subscription cancellation remains a separate action managed through Apple.
Backups may retain deleted records for a limited recovery period and are not restored to bypass a valid deletion request.
6. Your Rights
Subject to the GDPR and applicable law, you may have rights to access, correct, delete, restrict, port, or object to processing; withdraw consent; and complain to a supervisory authority.
Use Settings > Manage Account > Request Data Export for the full cloud-plus-device export. Use the in-app deletion controls to initiate local or account deletion where available, or contact [email protected]. Disable optional analytics in Settings. For YAP, do not submit another recording. For waitlist mail, reply to the confirmation message or contact us; there is currently no automated unsubscribe endpoint.
For Denmark, the supervisory authority is Datatilsynet.
7. Security
Controls include TLS in transit, iOS Data Protection, device-only Keychain session storage, Supabase Row-Level Security, scoped private export storage, short-lived signed links, rate limiting, server-side identity verification where required, allowlisted analytics, diagnostic sanitization, and secrets managed outside source code.
Not every endpoint uses a user JWT: public waitlist, anonymous/identified YAP, analytics ingestion, and diagnostic ingestion use purpose-specific publishable-key, bearer, installation, validation, rate-limit, or secret controls. Authenticated household, billing, and export operations require verified account context and enforce their own authorization rules.
8. Children
Mental Offload is intended for adults aged 18 or older. We do not knowingly collect personal data from children. Contact us if you believe a child has supplied data.
9. Additional regional information
For California and other US residents, categories processed can include identifiers, commercial information, internet/electronic activity, audio, diagnostics, user content, and product inferences. We do not sell or share personal information for cross-context behavioral advertising.
Residents of the UK, Switzerland, Canada, Australia, and other jurisdictions may have comparable access, correction, deletion, objection, portability, or complaint rights. Contact us and we will assess the request under applicable law.
10. Changes
We may update this policy when the product, processors, law, or data practices change. We will update the date above and provide additional notice or request renewed consent where required.
11. Contact
Email: [email protected]
Location: Denmark
We aim to respond to data-rights requests within one month, subject to lawful extensions.