Privacy Policy — KarmicCompass

How It Works

Diksha Dutt operates KarmicCompass. This summary explains the main ways the App handles your information. The sections below describe the details and exceptions.

You provide your name, date of birth, gender, country, journal entries and chat messages. You may also provide voice recordings and photographs.

The App uses your content to generate AI insights, karma and dharma scores, astrological readings, quiz scores and badges.

(a)
Voice recordings
1. (1)
  Google’s Gemini AI transcribes your recordings. The original .m4a audio may remain temporarily in private files on your device. The operating system protects these files from other apps, but KarmicCompass does not separately encrypt them.
2. (2)
  The normal retry queue holds up to 10 recordings. Each is removed after successful transcription or 7 days, whichever comes first. A recovered transcript may remain for up to 90 days while the App retries inserting it without duplication.
3. (3)
  If the operating system does not confirm deletion, the App retains a cleanup record without the recording’s content and retries. That record remains until deletion is verified or the App’s storage is removed. See sections 1 and 10.
(b)
Photographs
1. (1)
  Photographs attached to Arya chats are sent to Gemini Vision for analysis. We do not keep them as separate files on our servers.
2. (2)
  Journal photographs are kept in our cloud storage so they can appear in your journal. They are removed when the related entry or your account is deleted.
(c)
Device identification
1. (1)
  The App keeps a stable identifier specific to this app on your device. It is random on iOS and normally derived through a one-way transformation of Android’s identifier for this app.
2. (2)
  The identifier enforces one trial per device. A one-way version helps limit repeated AI use. It also checks that deletion codes and certain failed Apple sign-in requests come from the same App installation. Section 1 explains these uses.
(d)
If you set an App Passcode, the device’s secure storage keeps a protected, one-way representation and information about failed attempts. We do not keep the readable passcode or send it to our servers. Biometrics can confirm removal of App Lock in Settings; they cannot unlock the App.
(e)
A background task reschedules local reminders no more than once every 12 hours. This task sends no data to our servers.
(f)
We do not sell your data, share it for advertising, train our own models with your content or authorise providers to use it for model training. Sections 5, 9 and 10 explain the provider terms and settings that must support this commitment.
(g)
You can start account deletion or choose “Delete now” in Settings. Section 12 explains the grace period, deletion processing, backups, legal records and anti-abuse information that may remain.

1. Information We Collect

These categories describe information handled by the App and its supporting services. Some provider agreements, logging settings and backup arrangements still require verification before release. Sections 9 and 10 explain those limits; the App’s design alone does not establish a provider’s live practices.

(a)
Account and sign-in information
1. (1)
  At onboarding, we collect your name, email address, date of birth, gender, country and stated intention. Firebase assigns your account a unique identifier.
2. (2)
  If you choose Google or Apple sign-in, the provider supplies proof of your identity. We check that Apple’s sign-in identity matches the Apple account linked to your App account.
3. (3)
  For Apple sign-in, we keep one encrypted authorisation record linked to your account so we can disconnect that sign-in when you delete your account. Only our service can access it. A later successful sign-in replaces the previous record.
4. (4)
  Apple states that cancelling one valid authorisation credential cancels the associated sign-in authorisation. We use our stored record only for this deletion-time cancellation, then remove it. We never store Apple’s single-use sign-in code or a readable authorisation credential in our cloud database.
5. (5)
  If sign-in cannot be completed safely, including an account conflict or a failure during account deletion, we try to cancel the unused Apple authorisation immediately. If cancellation fails, we retain only an encrypted copy for limited retries. The cleanup rules below and section 10 explain the information kept and the time limits.
(b)
Journal and chat content
1. (1)
  Our cloud database stores your journal text and dates, optional mood categories inferred on your device from journal wording, AI-generated karma and dharma scores, emotions and other qualitative assessments. A journal mood category is different from the optional Mentor check-in scored from 1 to 5.
2. (2)
  We store chat messages, their times, whether they came from you or Arya, and the language used. Older messages move into a separate archive when the active chat reaches its limit.
3. (3)
  We store commitments you make with Arya, their text and dates, and whether Arya has followed up. We also store the text and dates of personal notes you ask Arya to remember.
4. (4)
  We store starred chat messages and their times, your daily intention text, your chat session count and the date of your first chat.
(c)
AI-generated observations
1. (1)
  Our cloud database stores a life digest of psychological and behavioural themes drawn from your journal, periodic observations about your patterns, weekly narratives and life reports.
2. (2)
  It also stores summaries of earlier chat sessions, unresolved emotional themes detected in conversations, karma and dharma scores, and the previous score snapshot used to comment on changes.
(d)
Wellness and activity information
1. (1)
  For eligible Mentor sessions, we store the karma scores before and after the session and the difference between them. These records do not contain the optional Mentor check-in scored from 1 to 5.
2. (2)
  That optional check-in stays in the App’s memory for the current session. It is added to the next Arya request to adjust the tone of the reply. It is not saved in our cloud database or kept after the session.
3. (3)
  We store quiz attempts, scores, difficulty paths and high scores; active 30-day challenges and progress; earned badges; and acknowledged milestones.
4. (4)
  We also store preferred discussion topics inferred from your conversations. These topics are inferred rather than explicitly selected by you.
(e)
Preferences and settings
1. (1)
  We store your preferred Arya reply language, including its label, language code and the language name used for AI requests.
2. (2)
  We store your preferred tone and response length, topics you have asked Arya to avoid, and whether Incognito Mode is active.
(f)
Voice recordings and recovered transcripts
1. (1)
  When you use the microphone, the App records an .m4a audio file privately on your device and sends it securely to Google Cloud Vertex AI for transcription. We do not save the original audio in our cloud database or cloud file storage.
2. (2)
  iOS or Android isolates the private audio files from other apps, but KarmicCompass does not separately encrypt them. Your operating system may include them in device backups, depending on your settings.
3. (3)
  The App can keep up to 10 recordings awaiting another transcription attempt. Each is deleted after successful transcription or 7 days, whichever comes first.
4. (4)
  If transcription succeeds but the text cannot yet be inserted into the intended journal entry or Mentor draft, the recovered text can remain locally for up to 90 days. A stable recovery identifier prevents it from being inserted more than once.
5. (5)
  The recovered text is removed when insertion succeeds, when you discard it, when the relevant feature is cleared or when your account is deleted.
6. (6)
  File deletion can fail or be interrupted. If removal is unconfirmed, the App retains a cleanup record without the audio’s content and retries. The record is removed when deletion is verified or the App’s storage is removed. Account deletion requests immediate cleanup but does not treat an unconfirmed deletion as complete.
(g)
Photographs
1. (1)
  Before sending a chat photograph to Gemini Vision, the App reduces its size and recreates the image file on your device. The longest edge is limited to 3,072 pixels, JPEG quality is about 90%, and further compression is applied if it still exceeds 6 MB.
2. (2)
  Recreating the image removes embedded information such as GPS coordinates, device identifiers and original timestamps before it is sent. We do not keep chat photographs as separate files on our servers.
3. (3)
  Journal photographs are stored in Firebase Storage so we can display them in your journal. They remain only while the related entry exists and are also deleted with your account. Separate checks for abandoned files provide additional cleanup; they do not replace deletion linked to the entry.
(h)
Crisis signals and safety follow-up
1. (1)
  Outside Incognito Mode, the App checks your submitted text for crisis-related keywords. If it finds a match, our service checks the exact reflection or message, up to 5,000 characters, after confirming the request comes from your account. It also receives whether the text was typed, transcribed or of unrecorded origin.
2. (2)
  A confirmed crisis record keeps only the first 100 characters, together with an identifier and time assigned by our service. Unexpected extra information is rejected. Records older than 90 days are removed, and no more than the latest 500 are kept.
3. (3)
  The record relates to the text that actually triggered the warning; a later message is not substituted. Stored crisis records are used only for contextual safety follow-up in later sessions and are not shared externally. Section 3 explains consent and how to stop or delete this memory.
4. (4)
  When submitted text does not match the keyword list, Google Cloud Vertex AI may assess its suicide or self-harm risk as none, possible or acute. The result only tells Arya whether to offer a relevant helpline in that reply.
5. (5)
  We do not store that AI risk rating or add it to your crisis records. No KarmicCompass staff member reads the rating.
6. (6)
  Google processes the text for that safety assessment. Its abuse-monitoring safeguards may retain a flagged prompt temporarily and allow review by authorised Google personnel. Sections 5, 9 and 10 explain this provider processing.
(i)
Device identifiers and trial protection
1. (1)
  The App keeps an identifier specific to this app. On iOS it is random and normally kept in secure device storage. On Android it is normally created through a one-way transformation of Android’s identifier for this app. The original Android identifier is not saved or sent.
2. (2)
  If the usual identifier is unavailable, the App uses a random value in secure storage. If that fails, ordinary app storage is used; if neither works, the identifier lasts only for the current session.
3. (3)
  We link this identifier to your account to enforce one trial per device. AI requests carry only a one-way, 32-character version of it, used to limit daily device-level abuse and record that the device has used its trial.
4. (4)
  The identifier also ties an email deletion code to the requesting App installation. Certain failed Apple sign-ins use it for the same protective purpose; only a protected one-way version is retained in short-lived attempt records.
5. (5)
  Account deletion removes your account identity from the trial record but leaves a pseudonymous marker showing that the device has used its trial. The identifier is not used for advertising or tracking across apps or websites and is never shared with advertising networks.
(j)
App Passcode and biometrics
1. (1)
  Your device’s secure storage keeps a salted hash of the App Passcode: a one-way representation with added random information, rather than the readable code. It also keeps information identifying the passcode’s owner and limiting failed attempts. These values are never sent to us.
2. (2)
  If an older App version saved a readable passcode, it can be accepted once. The next successful unlock replaces it with the protected, one-way version.
3. (3)
  The App does not allow biometric unlocking because it cannot reliably check that the enrolled fingerprints or faces have stayed unchanged. Face ID, Touch ID or Android biometrics can only confirm removal of App Lock in Settings. Your operating system handles biometric data; we and our providers never receive it.
(k)
Saved insights and birth details on your device
1. (1)
  The App stores daily insights, karma cards, horoscope and daily readings, cosmic scores and a profile snapshot in encrypted local storage separated by account. These saved copies reduce AI requests and support offline viewing.
2. (2)
  Personalised Daily Horoscope readings are saved only in that encrypted storage. If it is unavailable, a reading stays only in memory for the current app session. It is not copied to ordinary unencrypted app storage.
3. (3)
  Optional birth time and a verified birthplace selection are kept in the same encrypted storage. The selection contains city, country and timezone, not a street address or live location. The App uses these details locally for Cosmic Energies and ten Daily Horoscope theme scores.
4. (4)
  Birthplace search uses a GeoNames city list bundled with the App. Search text, selected place, birth time, city, country, timezone and the GeoNames place identifier are not sent to us, Gemini, GeoNames or another provider. Only the locally calculated scores described in section 5 are sent for the requested Daily Horoscope, not those details or your birth date.
5. (5)
  Signing out clears saved AI results from encrypted storage and memory. Optional birth details remain separated by account so they return when the same account signs in again. Account deletion clears those details.
(l)
Local reminders and background activity
1. (1)
  If you allow notifications, the App schedules local journal reminders, Mentor check-ins and daily check-ins. It keeps their identifiers and your preferred check-in time in ordinary app storage. Reminder wording is generic and contains no personal content.
2. (2)
  A background task reschedules check-in reminders no more than once every 12 hours. This task makes no network requests and sends no data to our servers.
3. (3)
  Background audio support allows the Mindful music player to continue while the screen is off.
(m)
Push notification delivery
1. (1)
  Your profile stores an Expo notification-delivery identifier, called a Push Token, plus a limited number of earlier identifiers to improve delivery reliability. Expo passes notifications through Apple Push Notification service on iOS or Firebase Cloud Messaging on Android.
2. (2)
  These identifiers are not used for advertising or cross-app tracking. You can stop “A letter from Arya” push notifications in Settings.
(n)
Security and abuse-prevention records
1. (1)
  When you request deletion while signed out, we briefly retain a one-way, 32-character version of your IP address to limit repeated code requests. It normally uses a secret key; some services use an unkeyed version. The record does not contain the original IP address or secret key.
2. (2)
  Daily AI-use counts and trial records use a one-way version of the device identifier described above. We also briefly retain RevenueCat billing-event records, including your account identifier, so the same event is not applied twice.
3. (3)
  A deletion request keeps the requesting App’s identifier for up to 7 days. Confirming the email code requires the same identifier, preventing use of an intercepted code from another App installation. It is the App identifier described above, not a separate identifier issued by Firebase.
4. (4)
  At startup, Apple or Google checks that the request comes from a genuine, unmodified app on a real device. Firebase App Check uses Apple App Attest or Google Play Integrity for this check. It contains no account information or user content.
5. (5)
  This security check runs before the consent screen to prevent fraud, relying on legitimate interests under GDPR Article 6(1)(f). Optional analytics and crash reporting do not start before you choose. Section 9 explains crash reporting.
6. (6)
  Apple sign-in registration is limited to 6 attempts per account each hour. A temporary record holds your account identifier, the purpose, start of the hourly period, count and expiry. It contains no sign-in codes or credentials. It is included in an available machine-readable access response and deleted with your account.
7. (7)
  A separate counter limits Apple registration to 1,000 attempts across the service each hour. It records the purpose, period, total and expiry, with no account identifier, IP information, sign-in code or credential. It expires automatically or is cleared in approximately two hours.
8. (8)
  Cleaning up a failed Apple sign-in before you are signed in requires the app-authenticity check. We use the network address and App identifier only to create protected one-way records, never retaining the original values. The device-storage fallback rules above also apply.
9. (9)
  This cleanup permits 3 attempts per network and 3 per App installation each hour, with a shared limit of 1,000 per hour. Records contain the protected identifier or shared period, purpose, start time, count and expiry. They contain no account or Apple identity, readable network or App identifier, sign-in code or credential, and last approximately two hours.
(o)
Subscriptions and billing
1. (1)
  RevenueCat updates the subscription status, plan, tier, expiry and any billing grace period in your profile. It uses your Firebase account identifier to recognise your account. We do not receive full payment-card details.
2. (2)
  Your profile is frozen during the reversible seven-day account-deletion period. Billing changes, including purchases, refunds, expiry or loss of access, are temporarily marked on the existing profile with the time received rather than applied immediately.
3. (3)
  If a subscription is transferred between accounts while any participant is in deletion grace, each existing account involved is marked for a later billing check, unless its irreversible erasure has already begun.
4. (4)
  If deletion continues, the marker disappears with your profile. If you cancel deletion by email link or in the App, we check the current subscription with RevenueCat and apply it before removing the marker. If RevenueCat is unavailable, an hourly process retries until the check succeeds.
(p)
Feedback and reported AI messages
1. (1)
  If you send in-app feedback, we store up to 1,000 characters of text, your rating from 1 to 5, a severity category derived from that rating, your account email address, your Firebase account identifier and the submission time.
2. (2)
  Reporting a chat message stores your account identifier, the message identifier, whether it was written by you or Arya, the selected reason, up to the first 500 characters of the message and the submission time. A report about your own message includes your own text.
3. (3)
  Before a reported excerpt leaves the device, the App filters it for email addresses, phone numbers and card-like number sequences. Reports are used only to review AI safety and quality problems. They are not shared externally or used to train an AI model.
(q)
AI and voice-use allowances
1. (1)
  Our cloud database stores daily AI-call counts linked to your account to enforce your plan’s allowance. Separate counters track journal analyses, individual features, overall daily totals and short-lived request limits.
2. (2)
  We have reserved an account-linked record type for a future text-to-speech allowance. The App does not currently write to it, so it holds no information about you in normal use. Our account-deletion process still clears it.
(r)
Support and deletion requests
1. (1)
  We retain emails you send us while resolving your enquiries.
2. (2)
  An email deletion request stores your registered email address, a six-digit code, the expiry time and the requesting app’s device identifier. The code expires after 15 minutes. The request record may remain for up to 7 days to support retries and is deleted when account deletion completes.
3. (3)
  An enquiry entered into our support system can include contact details, an available account reference, subject, correspondence, status and resolution time. Internal notes contain the note, the operator’s identity and the creation time.
4. (4)
  Support records linked through an account identifier or verified authentication identity are included in supported self-service access, export and deletion processes. Older correspondence linked only by email requires an operator to verify both the requester and the link. Matching email text alone is not sufficient proof.
5. (5)
  Resolved support records are retained for 365 days after resolution. Internal notes remain for 365 days after creation. Open enquiries remain while needed to resolve them, subject to the legal-claim exception in section 10.
(s)
Crash diagnostics and operational records
1. (1)
  Crash reporting is optional and off by default. If enabled in Settings, Sentry receives crash reports, error information and basic performance data. Our iOS privacy declaration treats these as information linked to a user and used for analytics. The same switch withdraws consent.
2. (2)
  App reports use a 16-character pseudonym created from your account identifier and a random installation-specific value. Sentry does not receive the original account identifier. Only our service can access the record linking your account to this pseudonym.
3. (3)
  We retain that link while Sentry export or deletion remains unresolved. Sentry offers no per-user deletion facility, so account deletion alone does not prove that its diagnostics have been erased. Section 12 explains this limitation.
4. (4)
  If an EU or UK user waives the 14-day withdrawal right to start a subscription immediately, we save that choice on the profile. If saving online fails, the record remains temporarily on the device until it can be sent.
5. (5)
  Records linked to your account also track AI requests in progress, devices used, unfinished cleanup, Apple sign-in attempt limits and the single encrypted Apple authorisation. They do not contain journal or chat text. A request-in-progress record is removed when the request finishes.
6. (6)
  Photo records track uploads awaiting completion, the number of stored photographs and photographs awaiting deletion. Upload records are cleared when the upload finishes. A deletion record identifies the account and journal entry, without the photograph’s content, so removal can continue after the App closes.
7. (7)
  Account deletion is recorded before information is removed, so work can resume after an interruption. The instruction is removed when the relevant provider steps finish. Older cases requiring manual action are retained for 30 days, then cleared.
8. (8)
  A further completion record prevents delayed App or support-system updates from restoring deleted information. It contains the account identifier, completion and expiry times, and an extra billing flag if a subscription was active when deletion began. It is not used for analytics.
9. (9)
  This completion record normally expires after two hours and is removed by the next hourly cleanup, so it can remain for approximately three hours. An active subscription can require longer retention under the exception in section 10.
(t)
Unfinished Apple authorisation cleanup
1. (1)
  If Apple sign-in fails before an authorisation can be safely linked to your account, we first try to cancel the unused authorisation. This includes account conflicts, failed checks or saving, and sign-in interrupted by completed account deletion.
2. (2)
  If Apple does not accept cancellation, we retain only an encrypted authorisation record for retry. It contains a random record identifier, public details identifying the App to Apple, relevant times, attempt counts, retry and expiry times, and a limited error code.
3. (3)
  This temporary record contains no Firebase account identifier, Apple identity, readable sign-in code or readable credential. It can be read only by our service. Cleanup requests made before sign-in also undergo the app-authenticity and attempt-limit checks described above.
4. (4)
  We retry hourly and remove the record when Apple accepts cancellation. After at most 7 days, we delete the encrypted record even if cancellation still fails and alert the operator. We do not report cancellation as successful without Apple’s confirmation.
(u)
Interrupted delivery and cleanup on your device
1. (1)
  If a journal analysis or Mentor message cannot be delivered, the App can keep it locally for another attempt. Failed or damaged items are separated in a limited recovery area rather than treated as delivered. They remain only while needed for retry and follow journal, chat-clear and account-deletion controls.
2. (2)
  An undelivered crisis report can remain encrypted on your device until sent, for up to 7 days. It contains the reflection or message that triggered the crisis check.
3. (3)
  Delivery receipts contain identifiers and delivery status, not your content. They prevent duplicate journal analyses or Mentor messages. A journal receipt may remain after its entry is deleted so an older retry cannot apply that analysis again.
4. (4)
  “Clear chat & memory” removes messages, archives and retry content on the current device. Content-free receipts and a record of the clear action prevent old retries on another device from restoring those messages. Both journal and Mentor receipts are deleted with your account.
5. (5)
  If removal of a local file or older shared storage remains unconfirmed, the App keeps a cleanup record without the deleted content. Exact file locations needed for the retry are stored separately in encrypted form and are not included in readable error reports.
6. (6)
  The cleanup record cannot be overwritten and remains until removal is verified or the App’s storage is removed. It is not an analytics record or a copy of deleted journals, chats, transcripts or audio.
(v)
Historical parent or guardian consent records
1. (1)
  The App is for adults aged 18 and over. It no longer requests parent or guardian email addresses or sends new approval links. Older records can contain a parent’s email address, consent status, which request the record concerns, request and approval times, and expiry.
2. (2)
  These older records are kept only for evidence of consent, withdrawal and deletion handling, never for marketing. We do not create a separate guardian account. Records are deleted with the account; a guardian can email app.karmiccompass@gmail.com to request earlier removal.
3. (3)
  Historical withdrawal links remain usable, but parental approval cannot activate an under-18 account.
4. (4)
  Older abuse-prevention counters contain send dates and counts, with no email address or message content. They expire 60 days after the last send or are deleted with the account.
5. (5)
  A separately reviewed update may use those counters to send replacement historical withdrawal links, subject to the existing limit of five attempts per day. It cannot send a new parental approval invitation.
(w)
No use of your content for model training
1. (1)
  We do not use your content to train our own models or authorise a provider to use it for model training. Google Cloud Vertex AI is our only current AI processor.
2. (2)
  Before release, we must verify the agreement applying to our actual Google Cloud account, its effective date and relevant settings. Google’s published terms are described in section 5, but a public statement alone does not prove that our account is covered.
3. (3)
  The former Gemini Developer API fallback is retired. If Vertex AI is unavailable, requests fail instead of going to another AI service.
4. (4)
  If the verified terms or settings do not support our commitment, affected processing must stop. It can resume only when the commitment is supported or an updated policy and fresh consent permit the change.

2. How We Use Your Information

(a)
Providing the App
1. (1)
  We use your information to personalise Arya’s replies, generate wellness scores and insights, and provide journal analysis, life digests and wellness reports.
2. (2)
  We transcribe your voice recordings for journal entries and chat messages, and analyse photographs you attach to Arya chats so responses can take them into account.
3. (3)
  We remember your preferences, including language, commitments and conversation history across sessions. We also manage your subscription and access rights.
(b)
Operating and protecting the service
1. (1)
  We use information to operate, maintain, secure and improve the App. With the relevant crash-reporting consent, Sentry helps us investigate reported errors and improve stability.
2. (2)
  We send important account, billing and policy communications. If you have allowed notifications, we also send Compass push notifications through Expo, Apple Push Notification service or Firebase Cloud Messaging.
3. (3)
  We use information to meet legal obligations and enforce our Terms.
(c)
We do not sell your personal data to advertisers or data brokers. We do not share it for advertising based on activity across services, and we do not use your content to train an AI model.

3. Legal Grounds, Sensitive Information and Data Principles

The grounds below describe how we intend to justify processing where the named laws apply. Qualified legal advisers must confirm the appropriate grounds, consent arrangements and local conditions before each market launch. Listing a ground here does not make it applicable or establish that it has been verified.

(a)
Providing the service you request
1. (1)
  We rely on the need to perform our contract where applicable. This covers the App and requested services such as AI replies, journal analysis, voice transcription and image analysis. Relevant provisions include GDPR Article 6(1)(b), UK GDPR, Brazil’s LGPD Article 7(V) and India’s DPDPA.
(b)
Legitimate interests
1. (1)
  Where permitted, we rely on legitimate interests to improve the App, prevent fraud and trial abuse, limit misuse of deletion codes and Apple sign-in exchanges, and protect our systems. Relevant provisions include GDPR Article 6(1)(f), UK GDPR and LGPD Article 7(IX).
2. (2)
  We balance these interests against your rights and reasonable expectations in a documented assessment, summarised in our Data Protection Impact Assessment at karmiccompass.app/privacy/DPIA. You may object to processing based on legitimate interests at any time.
(c)
Consent
1. (1)
  Where we rely on consent, you can withdraw it without affecting processing already carried out. Examples include notification permissions, optional Sentry crash and performance reporting, and the EU or UK confirmation waiving the 14-day withdrawal right. Sentry reporting is off by default.
2. (2)
  Relevant consent provisions include GDPR Article 6(1)(a), India’s DPDPA, Singapore’s PDPA and Japan’s APPI. The legal basis must be confirmed for the market concerned.
3. (3)
  You can change notification and crash-reporting consent in Settings. Withdrawing health-data consent is different because journalling, mood features and Arya conversations involve that processing. You cannot withdraw it fully while continuing to use those features.
4. (4)
  To withdraw health-data consent completely, delete your account through Settings. Section 12 explains deletion and the information that may remain temporarily or under stated exceptions.
5. (5)
  You can make narrower choices without deleting the account. Turning off “Safety follow-up memory” in Settings → Arya Settings stops crisis records being saved and deletes existing records. Incognito Mode prevents conversations from being saved as described in section 8.
(d)
Health-related and other sensitive information
1. (1)
  Journal entries, mood check-ins, emotional patterns, crisis signals and psychological inferences can contain health-related sensitive personal information. Under GDPR Article 9, UK GDPR and equivalent laws, we process this information on the basis of your explicit consent.
2. (2)
  During onboarding, a dedicated screen explains that entries may contain health-related information. You must affirmatively agree before using journal, mood or AI features. This consent is separate from general acceptance of the Terms.
3. (3)
  GDPR Article 9(2)(a) explicit consent is the main basis for saving crisis records. The “Safety follow-up memory” setting provides a separate opt-out. Article 9(2)(c), protecting vital interests, is only a narrow fallback for a genuine emergency when consent cannot be obtained.
(e)
Crisis records and your choices
1. (1)
  When your text matches a safety keyword, our service confirms the request comes from your account and checks the exact text, up to 5,000 characters. It also receives whether the text was typed or transcribed. The stored record keeps no more than its first 100 characters, with an identifier and time assigned by our service.
2. (2)
  The server removes crisis records older than 90 days and retains no more than the latest 500. They support contextual safety follow-up in later sessions under the consent and narrow emergency grounds described above.
3. (3)
  You can delete these records through Settings → Arya Settings by turning off “Safety follow-up memory” or choosing “Clear chat & memory”. Account deletion also removes them.
4. (4)
  Turning off stored safety-follow-up memory does not remove live safety warnings in the current session. It lets you stop crisis-record storage while retaining those warnings.
(f)
Legal obligations
1. (1)
  Where the law requires processing, we rely on that legal obligation, including GDPR Article 6(1)(c) where applicable. Examples include financial record-keeping and responding to regulatory requirements.
(g)
Data Protection Impact Assessment
1. (1)
  We have conducted a Data Protection Impact Assessment covering health-related processing at scale, AI inferences about wellbeing, the risks involved and measures to reduce them. It is published at karmiccompass.app/privacy/DPIA and is available to supervisory authorities on request where required by law, including GDPR Article 35.
(h)
Data protection principles
1. (1)
  We commit to the following principles throughout our processing, consistent with GDPR Article 5, LGPD Article 6 and equivalent laws.
2. (2)
  We process information lawfully, fairly and transparently.
3. (3)
  We limit processing to specified purposes and collect only the information needed for them.
4. (4)
  We take account of accuracy and limit how long information is kept. Section 10 describes retention.
5. (5)
  We protect the integrity and confidentiality of information and remain accountable for our processing.

4. Automated Assessments and Your Rights

(a)
What is automated
1. (1)
  Software or AI generates karma and dharma scores, life digests, inferred mood trends, weekly narratives, life reports, Daily Horoscope readings and locally calculated Cosmic Energy theme scores.
2. (2)
  Crisis detection also uses software: an on-device keyword list and, for unmatched text, an AI assessment of suicide or self-harm risk. Sections 1 and 5 explain the information involved.
(b)
How the results are used
1. (1)
  These results are for personal reflection. They are not used to make decisions with legal or similarly significant effects, deny service, change your price or take adverse action against you.
2. (2)
  We do not disclose these results to insurers or employers or permit an independent third party to use them for its own purposes. Contracted processors receive only the feature-specific information described in section 5 to provide the service on our instructions.
3. (3)
  This automated use constitutes profiling under GDPR Article 4(4). Its purpose and effects are limited to personal reflection within the App, as explained above.
(c)
Your choices
1. (1)
  You can request human review of an AI-generated inference about you and a plain-language explanation of how it was produced.
2. (2)
  You can contest an inference and request its correction or deletion.
3. (3)
  You can withdraw consent for future automated processing by deleting your account. To stop storage of crisis records specifically, turn off “Safety follow-up memory” in Settings.
(d)
Email app.karmiccompass@gmail.com to exercise these rights.

5. AI Processing and the Information Sent

(a)
Our AI provider and connection
1. (1)
  We check that AI requests come from your signed-in account, then send them securely through Google Cloud Run to Google Cloud Vertex AI in us-central1. Nightly letters are generated by our service rather than by a request from your phone.
2. (2)
  Google Cloud Vertex AI is our only current AI processor. The former Gemini Developer API fallback is retired. If Vertex AI is unavailable, the request fails instead of going to a different provider.
3. (3)
  The service forwarding requests does not permanently store message content. Connections are encrypted, and app-authenticity checks are attached where available.
4. (4)
  Failed Apple sign-ins have a separate cleanup process that can run before you are signed in. It requires an app-authenticity check and the network, device and shared attempt limits described in section 1.
(b)
Filtering and safety controls
1. (1)
  Interactive requests and scheduled letters use the same text and safety filters. The text filter looks for common email addresses, phone numbers, payment-card numbers and US Social Security number patterns.
2. (2)
  This filtering is best effort. It cannot reliably find every name, address or other piece of personal information. Do not submit information you do not want processed.
3. (3)
  Server-side safety filters block content assessed at medium or higher risk for harassment, hate speech, sexually explicit material or dangerous content.
(c)
Training and provider retention
1. (1)
  Google’s published customer-data terms state that it does not use Customer Data to train or fine-tune AI or machine-learning models without prior permission or instruction. We do not give that permission. We must separately verify the agreement applying to our actual production account and retain evidence of that coverage.
2. (2)
  The training restriction does not mean that Google retains nothing. Depending on the applicable terms and project settings, Google may temporarily process or cache prompts and responses to provide and secure the service, or log them for abuse monitoring.
3. (3)
  Google documents project-isolated, in-memory caching for published Gemini models with a default lifetime of 24 hours unless disabled. Request and response logging is configurable and off by default. Eligible customers can apply for an exception from abuse-monitoring logging.
4. (4)
  We do not use Google’s Interactions API feature that stores conversations, or add information from Google Search or Maps to AI requests.
5. (5)
  We do not claim zero provider retention or confirmed account coverage without verifying the applicable agreement, effective date, any exception and live settings. Section 10 explains retention.
(d)
Adult eligibility
1. (1)
  Before any AI processing, our service checks that the declared date of birth shows you are at least 18. An under-18 or unreadable date prevents transcription, photograph analysis, crisis assessment, scheduled letters and other AI requests.
2. (2)
  Existing data can still be exported without requiring a newly generated AI letter. Parental approval does not grant access to an under-18 account.
(e)
Arya chat
1. (1)
  A chat request includes your first name, age in whole years, gender, country and stated intention. Your device calculates the age from your date of birth; the date itself is not sent.
2. (2)
  It includes karma and dharma scores, recent karma-score changes and the previous score snapshot. If you answered the optional Mentor check-in during this session, the request includes its score from 1 to 5 and its label. That check-in is not subsequently written to our cloud database.
3. (3)
  It also includes your AI-generated life digest and insights, inferred discussion preferences, unresolved emotional themes, recent challenge information, the number of starred messages, feedback context, blocked topics, session summaries, chat-memory summary and selected reply language.
4. (4)
  A request includes up to 3 active commitments and up to 15 personal notes you asked Arya to remember. Each note is limited to 300 characters, with a total limit of 1,500 characters across the notes.
5. (5)
  Conversation context includes up to 30 recent journal entries at 600 characters each and up to 40 recent chat messages. Your current message is sent with a language instruction. Any photograph you attach is included as encoded image data.
(f)
Voice transcription
1. (1)
  The request contains your encoded audio recording and an instruction to transcribe it. It does not include profile information.
(g)
Journal analysis
1. (1)
  A journal-analysis request includes the entry text; your first name, age, gender, country and intention; quiz history, earned badges and karma points; and up to 30 recent journal entries at 500 characters each. An attached journal photograph is included as encoded image data.
(h)
Daily insights and longer reports
1. (1)
  These requests include your first name, age, gender, country and intention; karma and dharma scores; AI digest information; chat-memory summary; and current active challenge.
2. (2)
  A daily insight uses up to 5 recent journal entries at 400 characters each. Monthly, yearly and life reports use up to 90 entries at 500 characters each. Requests can also include up to 8 messages from today’s Arya conversation at 200 characters each.
3. (3)
  The separate “This Week” narrative uses only the last seven days of journal excerpts, at 150 characters each, and statistics derived from them. It sends no profile details or chat content and uses the same safeguards.
4. (4)
  Monthly, yearly and life reports are generated only when you open them on Home. Each counts within your daily Arya allowance, as explained in sections 5 and 7 of the Terms.
(i)
In-app letters and memory updates
1. (1)
  An in-app letter from Arya uses your first name, age, gender, country and stated intentions; psychological digest information; up to 30 journal entries at 600 characters each; up to 24 recent chat turns at 240 characters each; and the last 3 Arya letters.
2. (2)
  An update that rebuilds the memory digest uses the existing digest, up to 40 journal entries at 800 characters each, up to 50 recent chat messages at 350 characters each, up to 8 session summaries and a count of recent moods. It does not include your profile details.
3. (3)
  Content written in Incognito Mode is never included in these letters or memory updates.
(j)
Daily Horoscope
1. (1)
  A horoscope request includes your zodiac sign, the current date and a sky briefing calculated on your device. The briefing describes the Moon’s sign and phase, planets appearing retrograde, and supportive, tense or intense relationships between planets and your zodiac sign.
2. (2)
  It also includes ten whole-number theme scores from 45 to 95: love, career, wellness, creativity, intuition, social, resourcefulness, communication, vitality and luck. Your device calculates them from the sky and your date of birth, adding birth time and selected birthplace if supplied.
3. (3)
  We do not send your date or time of birth, birthplace, place-search text, city, country, timezone, GeoNames identifier, coordinates, journal or chat content for this feature.
4. (4)
  Google Cloud Vertex AI uses the briefing and scores only to write the reading and affirmation you requested.
(k)
Quiz generation
1. (1)
  Quiz requests contain general subject context only. They contain no personal information.
(l)
Export letters and cover text
1. (1)
  For an eligible export that generates a new Arya letter and cover tagline, the requests contain a summary of your journey, including scores and a digest overview. They do not contain raw journal entries. Section 6 explains the export process and exceptions.
(m)
Nightly letters from Arya
1. (1)
  Our service may generate one nightly letter a day without a request from your phone. It uses Vertex AI with the same text and safety filters, and does not switch to the Gemini Developer API if Vertex AI is unavailable.
2. (2)
  It sends your first name, age, gender, country and stated intentions; psychological digest information, including mental-health and core-wound notes; and the topics you have asked Arya to avoid.
3. (3)
  It also sends up to 30 recent journal entries, each limited to its first 100 words; up to 24 recent chat turns, each limited to its first 40 words; and the last 3 Arya letters.
4. (4)
  Every free-text field in that list passes through the personal-information filter first. Your first name, age, gender and country do not.
5. (5)
  A letter is not generated while Incognito Mode is on, during an account-deletion grace period or when the required age and consent checks fail. There is currently no separate setting to switch off letter generation.
(n)
Other short Arya requests
1. (1)
  Several shorter requests support your conversations. Each sends only the information needed for that task and none includes your profile details. Content written in Incognito Mode is excluded.
2. (2)
  A welcome-back request includes how long you have been away and your last session summary. Commitment and karma follow-ups include the commitment title, days elapsed and score changes.
3. (3)
  An opening response after a difficult journal entry includes an excerpt of that entry. Detecting unresolved themes uses up to 5 session summaries.
4. (4)
  “Summarise” uses chat turns for the selected period, at up to 800 characters each, together with your chat-memory summary, digest information and between 3 and 20 recent journal entries at 600 characters each.
5. (5)
  A rolling memory update uses the existing memory summary and chat turns added since the last update, at 300 characters each.
(o)
Automated crisis assessment
1. (1)
  If the on-device keyword list finds no match, the first 1,200 characters of your latest message or journal entry may be sent to Vertex AI with a fixed safety-assessment instruction. No profile details are included.
2. (2)
  The model returns only a suicide or self-harm risk rating of none, possible or acute. It is used to tell Arya whether to offer a relevant helpline in the same reply. We do not store the rating or add it to crisis records.
3. (3)
  This assessment affects only a shared daily usage count with no account identifier. Section 1 explains stored crisis records separately, and section 10 explains Google’s possible abuse-monitoring retention.

6. Exporting Your Information

(a)
What the journey PDF contains
1. (1)
  “Export Data” in Settings creates a readable journey PDF. Depending on the categories you select, it includes journal entries and available journal photographs, Arya chat history, wellness summaries, badges, scores, your Wisdom Collection of starred messages, Arya’s compressed memory, session summaries and any safety records.
2. (2)
  An account appendix includes available Stars birth details and saved Daily Horoscope readings, consent and account information, subscription details, usage records and information we retrieve after checking your account identity.
3. (3)
  An unavailable source or an archive that has not finished loading is clearly marked as partial. We do not describe the export as complete when a source reports a failure or more information remains to be loaded.
(b)
How the file is created
1. (1)
  An eligible journal export normally includes a personalised Arya letter and a one-line cover tagline. Creating them uses two AI requests containing a journey summary, not raw journal text. Existing information remains exportable without requiring a new AI letter where the age restriction prevents that processing.
2. (2)
  The PDF is assembled on your device from available information. Each attached journal photograph requires a separate download from Firebase Storage. It can also request the account information described above after checking your identity.
3. (3)
  The finished PDF is unencrypted. We do not send it to or receive it on our servers. Once you share it, you are responsible for protecting the file and controlling any further distribution.
(c)
Structured copies and missing information
1. (1)
  The PDF is a readable document, not a structured file for import into another service. For a machine-readable copy or information marked unavailable in the App, email app.karmiccompass@gmail.com.
2. (2)
  After checking your identity, we include supported records linked to your account in the separate operator system. Content-free journal and Mentor delivery receipts are also included while they exist.
3. (3)
  Older support correspondence linked only by email requires an operator to verify the requester and account link before disclosure or deletion. An unverified match to email text is not enough.
4. (4)
  The response includes available Apple sign-in attempt records linked to your account. It also includes public details identifying the App to Apple, sign-in registration times, the number of stored authorisations, which cannot exceed one, and the record format version.
5. (5)
  For security, we do not return sign-in codes, readable credentials, encrypted credential copies or the information used to encrypt them. Exact protected cleanup-file locations and secret-derived security identifiers are also excluded.
6. (6)
  Temporary records for unfinished Apple sign-in cleanup contain no App account or Apple identity, so we cannot link them to an individual access request. This does not exclude the separate sign-in attempt records linked to your account.
7. (7)
  The short-lived limits for cleanup before sign-in likewise contain no account identifier. We do not reverse their protected one-way network or device identifiers to answer an account request. The shared service counter has no user or device link.

7. Storage, Security and Our Website

(a)
Cloud storage and account security
1. (1)
  Diksha Dutt, operating as KarmicCompass, uses Google Firebase’s database and file storage to hold cloud data. These cloud services encrypt data at rest, and connections use TLS encryption in transit.
2. (2)
  Sign-in checks and access rules restrict personal information to authorised users. Encryption and access controls do not make any system completely secure.
3. (3)
  Local files have the separate protections and limits described in sections 1 and 6. In particular, raw voice files are protected by the device’s app isolation but are not separately encrypted by KarmicCompass, and exported PDFs are unencrypted.
4. (4)
  Use a strong, unique password and protect your account credentials. Report a suspected breach immediately to app.karmiccompass@gmail.com. Our runbook at karmiccompass.app/privacy/BREACH_RUNBOOK describes the GDPR Article 33 72-hour response process; section 16 explains breach notifications.
(b)
Website hosting and deletion forms
1. (1)
  Vercel hosts our marketing and legal website at karmiccompass.app. The site sets no cookies and uses no analytics, advertising or tracking technologies.
2. (2)
  Vercel may process standard request information, such as your IP address, browser information, requested page and time, to deliver and secure the site.
3. (3)
  If you use the website’s account-deletion form, your email address and verification code go directly from your browser to our Firebase deletion service. Vercel serves the page but does not receive the form contents.
4. (4)
  New deletion-cancellation links keep the account identifier and single-use cancellation code in a browser-only part of the address. The website host does not receive those credentials.
(c)
Optional website error reports
1. (1)
  If a website page fails, it can offer an “Allow error reports” choice. Reporting to Sentry is off by default. It does not start, and no report is transmitted, until you opt in.
2. (2)
  A browser report contains the error message and stack trace, standard browser information and the page path with query information and the browser-only address fragment removed. The filtering described in section 9 runs before transmission. Information entered into the deletion form is never included.
3. (3)
  The website’s server-side Sentry reporting is disabled because the server cannot read your browser-only choice.
4. (4)
  Your choice is stored only in your browser’s local storage, not a cookie, and is not sent to us. Declining leaves the site fully usable.
5. (5)
  You can withdraw a previous opt-in by clearing this site’s browser storage; reporting then stops. The optional diagnostics prompt asks permission for error reporting. Because the site sets no cookies, it does not use a cookie-consent banner.

8. Incognito Mode

(a)
Conversation handling
1. (1)
  In Incognito Mode, Arya chat messages are not saved to our cloud servers or your profile. Conversation content stays in the device’s session memory and is discarded when you exit the chat.
2. (2)
  Voice transcriptions and photographs used during an Incognito session are processed only for the AI response. They are not stored in your profile.
3. (3)
  The App uses no product-analytics services such as Mixpanel, Amplitude or Segment. It does not collect session content or behavioural event data from Incognito sessions.
(b)
Errors and security exceptions
1. (1)
  If you previously allowed App crash reporting, an unexpected error can still produce a Sentry report during Incognito Mode. These reports do not include conversation content. If you have not opted in, the App sends no Sentry report.
2. (2)
  Separately, our server functions may report failed operations to Sentry regardless of the App’s crash-reporting choice. These reports contain only the operation name and a redacted error message and stack trace.
3. (3)
  Server failure reports contain no account identifier of any kind, journal, chat, voice, image or profile content, request body or IP address.
4. (4)
  Safety or abuse-prevention records may still be kept by the service forwarding AI requests where legally required.
(c)
Incognito Mode does not change your journal entries or profile information.

9. Service Providers

The providers below help us operate the App and website. The current provider register, including effective dates, is available at karmiccompass.app/privacy/SUBPROCESSORS. We share only the information needed for the relevant service.

(a)
Google Firebase and Google Cloud
1. (1)
  Google LLC provides account sign-in, cloud data and file storage, services that run the App’s online functions, and app-authenticity checks. These services handle profile, journal, chat and account information.
2. (2)
  The cloud database uses Google’s nam5 multi-region location in the United States. The configured Cloud Functions, Cloud Run, Vertex AI and user-media storage use us-central1.
3. (3)
  Google manages the infrastructure for account sign-in and app-authenticity checks. We do not represent those services as confined to us-central1.
4. (4)
  We intend to rely on Google Cloud’s data-processing terms and Standard Contractual Clauses where applicable. Before launch, we must verify their coverage of our actual production account and keep evidence of the agreement. This policy alone does not prove an agreement has been accepted.
(b)
Google Cloud Vertex AI
1. (1)
  Google LLC’s Vertex AI is the sole current AI provider. It generates replies, insights, horoscope readings and quizzes, transcribes voice recordings and analyses images. It receives the prompt and response information described in section 5.
2. (2)
  Vertex AI is configured in us-central1. The wider Google services retain the region distinctions described above.
3. (3)
  Google’s published terms prohibit using Customer Data to train or fine-tune AI models without prior permission or instruction. Before release, we must confirm that the terms applying to our production account support that restriction. We do not authorise training with your content.
4. (4)
  Google’s data-processing terms and Standard Contractual Clauses are intended transfer safeguards where applicable and verified. Temporary service caching or abuse-monitoring logs may still apply, depending on the governing terms and settings.
5. (5)
  We do not claim zero provider retention without verified contractual and configuration evidence. Sections 5 and 10 explain the distinction between the training restriction and retention.
(c)
Former Gemini Developer API service
1. (1)
  The Gemini Developer API is no longer used, and current requests cannot be sent through the former fallback. It is listed only to make the change from earlier policy versions clear.
(d)
RevenueCat
1. (1)
  RevenueCat, Inc. manages subscription access, billing and trial status, and purchase restoration. It receives your Firebase account identifier as its app user identifier and receipt information from Apple or Google. Processing is in the United States.
2. (2)
  The intended safeguards are RevenueCat’s terms, data-processing agreement and Standard Contractual Clauses where applicable to the verified production account. We must retain agreement and retention evidence before launch.
(e)
Sentry
1. (1)
  Functional Software, Inc., trading as Sentry, provides crash and error monitoring in the United States. App and browser reporting require the separate opt-ins described in sections 7 and 8. Server failure reports have the limited, separate treatment explained below.
2. (2)
  After App opt-in, reports may contain a 16-character pseudonym created from your account identifier and a random installation-specific value. They do not use the original account identifier. Reports also include technical details of where the error occurred, with sensitive fields removed, and error messages limited to 120 characters.
3. (3)
  Journal entries and chat messages are not intended to be sent. Before transmission, the App checks the report’s additional details, context and request information for sensitive content.
4. (4)
  Website browser reports begin only after the browser choice in section 7. The website’s server-side reporting is disabled.
5. (5)
  Our online services can separately report failed operations using only the operation name and technical error details with sensitive information removed. Those reports contain no account identifier, user content, request body or IP address.
6. (6)
  Sentry’s data-processing agreement and Standard Contractual Clauses are intended safeguards where applicable to the verified production account. Account settings and retention evidence must be confirmed before launch. Account deletion alone does not establish that Sentry diagnostics have been removed; section 12 explains this limitation.
(f)
Expo Push Service
1. (1)
  Expo, Inc. relays Compass notifications to Apple Push Notification service and Firebase Cloud Messaging. It receives the Expo Push Token and generic notification title and body, without personal content. Processing is in the United States.
2. (2)
  We must verify the Expo terms and any transfer terms applying to the actual production service. Evidence of the agreement and notification-delivery retention is required before launch.
(g)
Gmail or Google Workspace email delivery
1. (1)
  Google LLC’s server-side email service delivers account-deletion codes. It processes your registered email address, the six-digit code and the email text. Processing is in the United States.
2. (2)
  The terms applying to the operator’s actual email account govern this service. We do not claim coverage by a Google Workspace data-processing agreement or Standard Contractual Clause module unless the account and agreement have been verified.
(h)
Apple App Store
1. (1)
  Apple Inc. provides iOS distribution and subscription billing. It handles information and processing locations under Apple’s terms. We do not see payment-card details.
2. (2)
  The relevant arrangements are Apple’s standard developer terms and privacy policy.
(i)
Google Play
1. (1)
  Google LLC provides Android distribution and subscription billing. It handles information and processing locations under Google Play’s terms. We do not see payment-card details.
2. (2)
  The relevant arrangement is the Google Play Developer Distribution Agreement.
(j)
Vercel
1. (1)
  Vercel Inc. hosts and protects our marketing, legal, support and account-deletion pages. It may process IP addresses, browser information, requested page paths and timestamps. Deletion-form contents go directly from your browser to Firebase, not Vercel.
2. (2)
  Processing occurs in Vercel’s hosting regions, which may include the United States. We must verify the terms and data-processing terms applying to the operator’s account, their acceptance and the relevant transfer settings before release.
(k)
Other services
1. (1)
  Google Fonts is not a data processor for the App’s fonts. Font files are bundled with the App and loaded locally. The App does not contact a font-delivery service, so no IP address or other information is sent to Google for font loading.
2. (2)
  Google Sign-In and Sign in with Apple are optional authentication services.
(l)
These providers may process information in the United States and other countries. The register at karmiccompass.app/privacy/SUBPROCESSORS lists current providers and effective dates.

10. How long we keep your information

The periods below explain how long we keep each type of information. Account deletion removes information from our active systems through the process in section 12. Some records have different deadlines or cannot be matched to an individual account.

(a)
Your account and personal content
1. (1)
  We keep your profile, name, date of birth, gender, country, intention, language preference, scores and settings while your account is active. We also keep your journal entries, chats and archived chats during that time.
2. (2)
  These records are erased from active systems after the seven-day deletion grace period. Choosing “Delete now” skips that period, signs you out and queues irreversible deletion. A background process first disables access and then performs deletion, ordinarily on its next hourly run. This does not promise immediate physical erasure.
3. (3)
  AI-generated digests, insights, session summaries, memory and reports are deleted with your account. The same applies to wellness records, including changes in karma scores, quiz history, badges, challenges and preferred topics.
4. (4)
  The optional 1–5 Mentor check-in is held only for the current app session. It is not stored beyond that session. Your push-notification delivery tokens are deleted with your account.
(b)
Safety follow-up records
1. (1)
  A saved crisis-related record contains no more than 100 characters from the exact message that triggered it, how the message was submitted, and a server-set time. The service that saves these records removes those older than 90 days and keeps no more than the latest 500.
2. (2)
  These records are deleted with your account. You can also delete them at any time in Settings → Arya Settings.
(c)
Voice recordings and recovered transcripts
1. (1)
  Raw voice recordings are not stored on our servers. Up to 10 recordings can remain in the App’s private files on your device for no more than seven days. They are removed after successful transcription or when that period expires.
2. (2)
  Your operating system separates these files from other apps, but KarmicCompass does not add separate encryption to the raw audio files. Device backups may include them according to your operating-system settings.
3. (3)
  A recovered transcript that has not yet reached its intended journal entry or Mentor draft may remain on your device for retry for up to 90 days. A unique recovery reference prevents it from being inserted more than once.
4. (4)
  If your operating system does not confirm that a recording was deleted, the App keeps a content-free record of the unfinished cleanup and retries. That record is removed when deletion is verified or the App’s storage is removed. Account deletion requests immediate cleanup; it does not prove that an unconfirmed file deletion succeeded.
(d)
Images
1. (1)
  Photos sent in Arya’s chat are used temporarily for AI processing. We do not store them as separate image files on our servers.
2. (2)
  Photos attached to journal entries remain in our cloud storage until the corresponding entry or your account is deleted, whichever happens first. Deleting the entry starts deletion of its photo. A separate cleanup process checks for leftover files.
(e)
Account usage and short-lived security records
1. (1)
  Usage and journal photos
  1. (a)
    We delete account-linked AI usage limits, journal-analysis limits, export limits and other request limits with your account. We also clear the reserved voice-playback counter, although the App does not currently write to it.
  2. (b)
    Journal-photo upload reservations, photo-count records and unfinished photo-deletion records are deleted with your account. An individual photo-deletion record is also removed when the background cleanup completes; that process runs every 15 minutes.
2. (2)
  Apple sign-in attempts and device changes
  1. (a)
    A security record for registering Sign in with Apple stores your account identifier, request timing and count, but no authorisation code or token. It allows up to six attempts per account per hour and expires approximately two hours after each update. It is included in a data export while present and is deleted with your account.
  2. (b)
    Records of the different device identifiers used by your account each day prevent people from bypassing limits by cycling through devices. They expire after three days and are also removed when your account is erased.
3. (3)
  Network and service protection
  1. (a)
    Deletion-code request limits use a shortened, one-way representation of your network address. The relevant records remain only for the limit period, usually minutes to a few hours. Where a request binds a secret, the one-way calculation also uses a secret key; the raw address and key are not stored in the record.
  2. (b)
    Service-wide Apple registration limits allow up to 1,000 attempts per hour. These aggregate records contain no account identifier or network address.
  3. (c)
    Cleanup after an Apple sign-in conflict uses separate one-way network and app-specific device references. Each allows up to three attempts per hour, alongside a service-wide limit of 1,000 attempts per hour. These records contain purpose, time, count, expiry and one-way references, but no readable address, device identifier, account identifier, Apple identity, authorisation code or token.
  4. (d)
    These service and security records expire automatically or are removed by a cleanup process within roughly two hours. Records without an account link cannot be located through an individual account-access or deletion request.
(f)
Your Apple sign-in connection
1. (1)
  While Sign in with Apple remains linked, we keep one current encrypted credential that lets us revoke the connection when you delete your account. The record also contains the encryption details, the App’s Apple identifier and registration times. It is protected on the server and cannot be read directly by the App.
2. (2)
  A later successful Apple sign-in replaces the previous credential rather than adding another. We delete it after Apple confirms revocation. Apple states that revoking this valid credential removes the associated authorisation for the App.
3. (3)
  Sometimes a newly issued Apple credential cannot be safely attached to an account and cannot immediately be revoked. We keep only an encrypted copy in a separate cleanup queue, without your KarmicCompass account identifier or Apple identity. A background process retries revocation hourly.
4. (4)
  The queued copy is deleted immediately after Apple accepts revocation. If revocation is still unconfirmed after seven days, the encrypted copy is deleted and an alert is raised. We do not report successful revocation. Because the record has no account or Apple identity, we cannot locate it for an individual access or deletion request.
5. (5)
  To prevent abuse, cleanup requests made during a failed sign-in must come from a verified copy of the App and meet the network, device and service limits above. We do not retain readable Apple sign-in credentials in this retry list.
(g)
Records needed to complete account deletion
1. (1)
  While deletion is in progress
  1. (a)
    Before deletion starts, we create a server-held progress record so an interruption does not leave work untracked. It contains your account identifier, the reason for deletion, each service’s progress, the access-lock requirement, retry counts, times and limited outcome information. It contains no journal, chat or profile content.
  2. (b)
    If a store subscription is active when deletion starts, this record also states that fact and its paid-through date. These details determine how long to prevent later billing notices from recreating records for the deleted account. We do not add the plan, price or payment details.
  3. (c)
    During ordinary deletion, we attempt Apple revocation before deleting the sign-in account and stored content. With “Delete now”, we first record the irreversible request and attempt to disable access. The hourly worker retries access disabling first, then processes Apple, Firebase sign-in and storage, Sentry and RevenueCat. Section 12 explains the remaining provider limitations.
2. (2)
  After erasure succeeds
  1. (a)
    After every applicable step succeeds, we remove the progress record and the link used to locate your Sentry diagnostics. In the same operation, we create a short-lived completion record to stop delayed app or operator requests from recreating information linked to the deleted account.
  2. (b)
    For most accounts, the completion record contains only the former account identifier and completion and expiry times. Its expiry is set two hours after completion. An hourly cleanup ordinarily removes it on the next run, so it may remain for approximately three hours. It is inaccessible to the App and is not used for analytics.
3. (3)
  When a store subscription is still active
  1. (a)
    If a store subscription was active, the completion record also notes that billing notices must be ignored. It stays until roughly two months after the paid-through date, for at least two hours and no more than 400 days. If that date is unavailable, the full 400 days applies.
  2. (b)
    This longer period covers a renewal cycle and the store’s billing-retry allowance. Later renewal, refund or transfer notices are acknowledged and discarded instead of repeatedly failing or recreating records. The completion record contains no name, email, content, device or payment details and is included in a data export while it exists.
4. (4)
  Unfinished cleanup and older Apple accounts
  1. (a)
    A separate content-free cleanup record may retain your account identifier and the names of failed cleanup operations. It is removed when those operations succeed, or expires after 30 days if they do not.
  2. (b)
    For an older Apple account without a saved revocation credential, signed-in deletion requires one fresh Apple sign-in. If you cannot sign in and no credential exists, we erase local and supported-provider data but cannot claim to revoke Apple access. You must remove KarmicCompass in your Apple Account settings.
  3. (c)
    Once other applicable provider work is complete, that unresolved Apple outcome is kept with the former account identifier for 30 days and then explicitly removed. Further Apple retries stop. If Sentry or another provider remains unresolved, the overall deletion stays open rather than being falsely marked complete.
(h)
Device records used to prevent trial abuse
1. (1)
  Device-level AI abuse counters use a shortened, one-way device reference. Their 60-day expiry is refreshed while the device remains active. They cannot be found by account and are not individually deleted with your account; they expire on their own timer.
2. (2)
  When you delete your account, we remove its identity from the device trial records or replace it with a deleted-account marker. The remaining pseudonymous device marker prevents repeated free trials. We keep it only while the one-trial-per-device control remains operationally necessary.
3. (3)
  We retain the trial marker for fraud prevention under GDPR Article 6(1)(f). After its account link is removed, the remaining token cannot be linked to your former account. It is kept only to check whether the device has already received a trial, with no fixed deletion date while that control remains necessary.
4. (4)
  The device identifier itself can remain in your device’s protected storage until it is manually cleared by resetting the device. Account deletion removes its link to your account on our servers; it does not remove the remaining trial-abuse marker.
(i)
Billing events and subscription records
1. (1)
  Records preventing a billing event from being applied twice contain your account identifier and expire after 30 days. They remain for that period even after account erasure, because removing them too early could repeat a subscription grant. They are included in a data export while present.
2. (2)
  During the reversible deletion grace period, subscription changes do not alter the frozen account’s access. Instead, we temporarily mark the existing profile for a subscription check. This covers grants, renewals, refunds, expirations and other changes.
3. (3)
  If a subscription transfer affects several accounts and any is in the grace period, we mark each existing account that is not already undergoing irreversible deletion for this check.
4. (4)
  If you cancel deletion through either available route, we immediately ask RevenueCat for the current subscription state. The temporary marker is cleared after a successful update. If RevenueCat is unavailable, the hourly worker retries. If deletion continues, the marker disappears with the account.
5. (5)
  Subscription and financial records follow the applicable store or RevenueCat terms and the financial or tax law for the controller and transaction. We do not claim a universal seven-year retention period without evidence for the relevant jurisdiction.
(j)
Feedback, reports and support
1. (1)
  Feedback submissions expire 365 days after they are submitted. Reports about AI responses are also automatically deleted after 365 days. Both are removed by the account-erasure process if you delete your account sooner.
2. (2)
  Resolved support records are retained for 365 days after resolution. Internal support notes are retained for 365 days after creation. Open enquiries remain for as long as needed to resolve them. A specific legal claim may require a longer, documented hold.
3. (3)
  Health-related information in a support message receives the heightened protection required for special-category data under GDPR Article 9. Access is restricted, the content is never used for AI training, and you can request deletion unless a documented legal exception applies.
4. (4)
  Account-linked records in our separate support and administration system are included in authenticated data-access and deletion processing. Older support records identified only by email require a verified review before disclosure or deletion. An unverified matching email address is not enough to establish ownership. The same support and legal-hold periods apply.
(k)
Deletion verification codes
1. (1)
  A code sent to your registered email stops working after 15 minutes. The request record, including your email address and the App’s device reference, can remain for up to seven days so the request can be retried. It is deleted as soon as account deletion completes.
(l)
Information stored on your device
1. (1)
  Local AI caches are encrypted and cleared when you sign out or delete your account. If encrypted storage is unavailable, the personalised Daily Horoscope stays only in the running app’s memory. It is never saved in ordinary unencrypted app storage.
2. (2)
  Optional birth time and verified birthplace details stay encrypted on your device after an ordinary sign-out. They are cleared when you delete your account.
3. (3)
  The list of notification identifiers stored on your device is cleared on sign-out. Your passcode and lockout information are cleared when you remove the passcode or delete your account.
(m)
Crash diagnostics held by Sentry
1. (1)
  Sentry’s retention periods depend on the plan and type of diagnostic data. We have not yet verified the maximum period or backup expiry for the production account.
2. (2)
  The protected link between your account and its Sentry diagnostics remains while provider erasure is unresolved. This lets us identify the affected records. Contact us for the status of your particular export or deletion request. Section 12 explains why this work can remain incomplete.
(n)
Backups and other copies
1. (1)
  Backups, exports or snapshots may contain residual copies after information is erased from active systems, if those copies exist. We will state a maximum age only after the actual production settings and every copy location have been inventoried and tested.
2. (2)
  The previously stated 90-day period was a release-verification target, not a verified promise. Contact us for the evidence that applies to a completed deletion.
(o)
Information processed by Google Cloud Vertex AI
1. (1)
  The server handling our AI requests does not permanently store the raw content of interactive prompts and responses. Google Cloud processes that content as our AI provider. Google does not use customer data to train or fine-tune AI models without prior permission or instruction.
2. (2)
  Depending on the applicable agreement and project settings, Google may temporarily cache content to provide the service or log prompts and responses for security and abuse monitoring. Google documents a default 24-hour in-memory cache, separated by project, for published Gemini models unless disabled.
3. (3)
  Logging of prompts and responses is disabled by default unless configured. We do not use the Interactions API’s stored-conversation feature or Google Search or Maps grounding, which adds information from those services to AI responses.
4. (4)
  The provider’s actual maximum retention period depends on the verified production agreement, any applicable exception and the settings in use. We do not promise zero provider retention until those controls have been verified. Section 5 describes the information sent for each AI feature.
(p)
Pending submissions and unfinished local cleanup
1. (1)
  A journal submission or Mentor message awaiting delivery, or held because it failed, remains on your device only while needed to complete it or show the failure safely. It follows the corresponding entry-deletion, Clear Chat & Memory and account-deletion controls.
2. (2)
  Content-free processing receipts stop requests from being processed twice or old messages from reappearing. They contain no journal entry, transcript, prompt or response. A journal receipt may remain after its entry is deleted, solely to prevent repeat processing.
3. (3)
  Clear Chat & Memory removes message bodies, archives and retry content on the current device. It retains content-free Mentor receipts and advances a server-held deletion marker, so an offline device cannot later restore cleared messages. Journal and Mentor receipts are deleted with your account.
4. (4)
  A temporary AI-request progress record normally disappears when the request finishes. If a request is abandoned, it remains for no more than seven days. It carries your account identifier, is included in a data export while present, and uses this fixed period to prevent quota errors during retries.
5. (5)
  Content-free records of unfinished local deletion, including an encrypted list of file locations, remain until the files are verified absent or the App’s storage is removed. This can include raw audio, older files or files previously shared between accounts. These records are not analytics or an archive of your content.
(q)
Exceptions and the detailed retention schedule
1. (1)
  Information may be kept longer where required by law, fraud prevention, a security investigation or dispute resolution.
2. (2)
  The detailed operational retention schedule is published at karmiccompass.app/privacy/RETENTION.md. It may describe work that is not yet deployed. If it differs from this policy, this section governs the description of the App’s current behaviour.

11. Screenshots and screen recording

(a)
You control captures made while using the App
1. (1)
  You can take screenshots, record your screen, share it or mirror it while the App is active. The App does not detect screenshots or notify us when you take one.
2. (2)
  A capture may contain visible journal entries, Arya conversations, account details or photos. You control and are responsible for any copy you create or share.
(b)
Sensitive screens use a background overlay
1. (1)
  When the App leaves the foreground, it places a blank overlay over sign-in, email verification, onboarding, adult eligibility and passcode screens. It also covers your journal, Home, constellation map, Arya conversations, Arya’s memory and settings, account settings and deletion screens.
2. (2)
  Photos on the journal, constellation and Arya-conversation screens are covered as part of those screens. Screens outside this set, including your realm, yoga and horoscope, are not covered.
3. (3)
  The overlay aims to hide sensitive information from the app-switcher preview and background snapshot. It is a best-effort safeguard, not a guarantee. Operating-system timing, particularly on Android, may capture a preview before the overlay appears.
4. (4)
  The overlay does not prevent a screenshot, recording, screen share or mirror while you are actively viewing the App.
(c)
Protect access to your device
1. (1)
  If others can access your device, enable the App Passcode in Settings → App Lock and use your device lock. These controls protect access when the App is not in use. They cannot stop someone who can already see an unlocked screen from capturing it.

12. Deleting your account

(a)
How to request deletion
1. (1)
  When signed in, open Settings → Account → Delete Account.
2. (2)
  If you cannot sign in, use “Request Account Deletion” in the App or email app.karmiccompass@gmail.com. We send a six-digit verification code to your registered email. It expires after 15 minutes. Confirming the code starts the deletion process.
3. (3)
  To limit abuse of deletion-code requests, we briefly store a shortened, one-way representation of your network address calculated with a secret key. The record contains neither the raw address nor that key. Section 10 explains its retention.
(b)
The seven-day grace period
1. (1)
  Choosing the seven-day option, or confirming deletion through the signed-out route, deactivates your account and revokes its sign-in sessions. A background process erases the information described below from active systems after the seven days have passed.
2. (2)
  This grace period lets you undo a request made by mistake or by someone with access to an unlocked phone. We email you a one-click cancellation link when deletion starts.
3. (3)
  You can also sign in during the seven days and choose “Restore my account”. Signing in alone does not cancel deletion. If you do nothing or choose “Continue with deletion”, erasure continues. Deletion cannot be reversed after the grace period.
4. (4)
  If subscription changes arrived while your profile was frozen, either cancellation route immediately checks your current subscription with RevenueCat. If the provider is unavailable, we do not guess your access level. A background process retries hourly until it can confirm the current state.
(c)
What “Delete now” means
1. (1)
  “Delete now” requires recent authentication and skips the seven-day grace period. Before deleting files, the server permanently records the irreversible request and makes one time-limited attempt to disable access. The App clears local account data and signs you out.
2. (2)
  If access has not yet been disabled, the background worker retries that step first. It then handles Apple revocation where applicable, Firebase sign-in and storage, Sentry and RevenueCat, ordinarily on its next hourly run. Temporary failures are retried automatically.
3. (3)
  Once the request is accepted, you cannot cancel deletion or restore the account. Acceptance confirms that deletion is queued; it does not mean that all information has already been physically erased.
(d)
Information removed by account erasure
1. (1)
  Account erasure removes your profile, journal entries and archives, chats and archives, journal view, experience points, badges, AI information and reports. It covers all account-linked locations used or reserved for these insights and reports.
2. (2)
  It removes your account’s usage and request-limit records, device links, deletion-code requests, submitted feedback and AI-response reports. It removes your account identity from trial-device records, while retaining the pseudonymous anti-abuse markers described in section 10.
3. (3)
  It removes your push-notification tokens, crisis-related safety records, temporary subscription-reconciliation markers and Firebase sign-in account. Photos attached to journal entries are deleted from our cloud storage. Deleting an individual entry also removes its corresponding photo.
4. (4)
  It clears pending or failed journal and Mentor submissions, recovered transcript drafts, local cleanup records and the encrypted list of files awaiting deletion. If the operating system has not confirmed a file’s removal, cleanup remains tracked until absence is verified or the App’s storage is removed.
5. (5)
  Content-free journal and Mentor processing receipts and the server’s chat-deletion marker are removed with the account. Clearing a single journal entry may leave its receipt to prevent duplicate processing. Clear Chat & Memory retains the relevant content-free safeguards to stop another device restoring deleted messages.
(e)
How interrupted deletion is handled
1. (1)
  Keeping unfinished work open
  1. (a)
    A server-held progress record is created before destructive work begins. It contains status and limited account information, not your content. It also prevents the separate support and administration system from recreating account-linked records while deletion is under way.
  2. (b)
    Ordinary deletion attempts Apple revocation first, keeping the encrypted credential for retry if Apple or our configuration is temporarily unavailable. It then processes Firebase sign-in and storage, Sentry, RevenueCat and supported records in the separate operator system. “Delete now” adds the access-lock step before that sequence.
  3. (c)
    A problem disconnecting Apple does not make your request complete while other services still need to finish deleting your information. We also recheck earlier Sentry deletion results that were not properly confirmed.
2. (2)
  Preventing deleted records from returning
  1. (a)
    Once every applicable step succeeds, we remove the progress record and the link used to identify your Sentry diagnostics, and create a temporary completion record. This prevents delayed requests from recreating account-linked information. It is not used for analytics.
  2. (b)
    Ordinarily, the completion record expires two hours after completion and is removed by an hourly cleanup, so it can remain for approximately three hours. If a store subscription was active, a limited billing-protection record can remain for up to 400 days. Section 10 gives the full timing and contents.
  3. (c)
    A separate record of a failed cleanup operation is removed when the operation succeeds, or expires after 30 days. Neither deletion progress nor these limited records justify treating unfinished physical erasure as complete.
(f)
Provider records and work that may remain incomplete
1. (1)
  We seek to remove the encrypted Apple revocation credential and associated Sign in with Apple authorisation, the account’s Sentry identity link and mapped diagnostics, and the RevenueCat subscriber profile. Completion depends on confirmation from each applicable provider.
2. (2)
  Sentry diagnostics
  1. (a)
    Sentry diagnostic information needs separate export and deletion by our support team using tools that Sentry supports. Earlier automated attempts did not confirm that the information was removed.
  2. (b)
    Until Sentry work is verified, the export remains incomplete and the deletion job and identity link remain open. A missing provider feature does not mean an empty export or successful deletion. Scrubbing new diagnostics does not remove information already sent.
  3. (c)
    For help with these records or the status of your request, email app.karmiccompass@gmail.com.
3. (3)
  Older Apple sign-in connections
  1. (a)
    An older Apple account may have no saved credential that we can revoke. If you are signed in, deletion asks for one fresh Apple sign-in. If you cannot sign in, we complete local and supported-provider erasure but direct you to remove KarmicCompass manually in your Apple Account settings.
  2. (b)
    We do not claim that this Apple authorisation was automatically revoked. After the other applicable work finishes, we stop further Apple retries and retain only the former account identifier and unresolved outcome for 30 days before explicitly removing that record.
(g)
Records in our support and administration system
1. (1)
  Supported records linked through your account or sign-in identity are included in the deletion process. Older support records identified only by email require verified operator review; an unverified matching email address is not sufficient proof that a record belongs to you.
2. (2)
  Two limited kinds of record can remain. If an operator disabled your account or revoked an operator permission, we retain only the revocation state, time and an indication that the account was erased. The reason, email copy and all other details are removed. This prevents an old operator action from silently restoring the deleted account.
3. (3)
  A deletion initiated in the operator system also leaves a progress record containing only status and times. It follows that system’s own retry and expiry rules so ongoing deletion is not abandoned.
4. (4)
  These reduced records contain no content, email, device or network address. They are included in a data export while they exist.
(h)
Records that expire separately
1. (1)
  Device-level abuse counters, one-way network or device security records, and service-wide counters cannot be located through your account identifier. They expire on the timers in section 10 rather than being deleted individually with your account.
2. (2)
  The separate encrypted Apple cleanup queue has no KarmicCompass account or Apple identity. Its record is removed after confirmed revocation or, at most, after seven days with an alert if revocation remains unconfirmed. We cannot match it to an individual data request.
3. (3)
  Billing-event records retain your account identifier for 30 days to prevent duplicate subscription changes. Temporary AI-request records also carry it while work is unfinished; they normally disappear when the request finishes, or after seven days if abandoned. Both are included in a data export while present.
4. (4)
  Account-linked Apple registration-limit records are also included in an export while present. Security records and the Apple cleanup queue that have no account link cannot be included by matching an account identifier.
5. (5)
  The limited operator records and subscription-related completion record described above can also outlive account erasure. They retain only the limited status and timing information explained here and in section 10.
(i)
Backups and subscriptions
1. (1)
  Residual copies may remain in backups, exports or snapshots if those copies exist. We have not verified their maximum age. The earlier 90-day figure was a release-verification target, not a promise. Section 10 explains how to request evidence for your deletion.
2. (2)
  Subscription billing records follow the applicable store or RevenueCat terms and financial law. Deleting your account does not cancel an Apple or Google subscription. Manage cancellation in your store account; Terms section 15 explains this separately.

13. International data transfers

KarmicCompass operates from India and uses cloud services mainly in the United States, including Google Firebase, Cloud Run, Vertex AI, Sentry, RevenueCat and Expo Push Service. Your information may be transferred to or processed in countries whose data-protection standards differ from those in your country.

(a)
European Union, European Economic Area and United Kingdom
1. (1)
  The App is not offered in these markets for this release. Before offering it there, we must verify that the production provider accounts have an applicable transfer safeguard, such as appropriate standard contractual clauses or an adequacy decision. Section 18 explains the other requirements for these markets.
2. (2)
  Google’s published data-processing terms are available at cloud.google.com/terms/data-processing-addendum. A public agreement alone does not prove that the particular KarmicCompass production account accepted it or is covered. We must retain evidence of the applicable agreement and transfer mechanism.
(b)
India
1. (1)
  Under the Digital Personal Data Protection Act 2023, transfers are permitted to countries not blocked by the Government of India. We use Google Cloud infrastructure. The applicable production agreement and any notified country restrictions must be verified for launch and ongoing compliance.
(c)
Brazil
1. (1)
  Before relying on a provider agreement or standard contractual clauses, we must verify that the mechanism covers the production account and the relevant transfer under the LGPD. A Brazilian launch and any transfer assessment require qualified legal advice and retained agreement evidence.
(d)
Canada
1. (1)
  Before a Canadian launch, qualified legal advisers must confirm the accountability, notices and contractual measures needed for our actual providers and transfer routes. We must retain the corresponding production agreements.
(e)
United Arab Emirates
1. (1)
  Before relying on an adequacy decision or contractual safeguards under Federal Law No. 45 of 2021, qualified legal advisers must confirm the mechanism for the actual destination and provider. We must retain evidence that it applies.
(f)
Saudi Arabia
1. (1)
  A launch under the Saudi Personal Data Protection Law first requires the applicable transfer assessment. Qualified legal advisers must verify the contractual, technical and approval requirements for the actual transfer route.
(g)
Turkey
1. (1)
  Before launch or transfer, qualified legal advisers must identify the mechanism available under the KVKK for the actual destination and provider. We do not assume that adequacy, consent or an approved undertaking is available.
(h)
Mexico
1. (1)
  Before launch or transfer, qualified legal advisers must confirm the notices, consent and agreements required under the LFPDPPP for the actual providers. We must retain evidence of the applicable arrangements.
(i)
Thailand
1. (1)
  Before launch or transfer, qualified legal advisers must confirm whether adequacy or another safeguard under the PDPA applies to the actual route. We must retain the supporting evidence.
(j)
Other countries
1. (1)
  This policy does not itself establish a transfer mechanism. Before entering another market, we must identify and retain the applicable production agreements, safeguards and any required consent for the actual recipients and transfer routes.

14. Your privacy rights

Your rights depend on the law that applies to you. To exercise them, email app.karmiccompass@gmail.com. We respond within 30 days, or sooner where required by law. We may need to verify your identity before acting.

(a)
European Union and European Economic Area
1. (1)
  Under the GDPR, you can request access, correction, erasure, restriction, portability and objection to processing. You can withdraw consent at any time. You have rights concerning decisions made entirely by automated processing that have legal or similarly significant effects; section 4 explains our automated processing.
2. (2)
  You can complain to your local supervisory authority. A list is available at edpb.europa.eu.
(b)
United Kingdom
1. (1)
  The UK GDPR and Data Protection Act 2018 provide the same rights listed above for the EU and EEA. You can complain to the Information Commissioner’s Office at ico.org.uk.
(c)
India
1. (1)
  The Digital Personal Data Protection Act 2023, Information Technology Act and SPDI Rules provide rights to access, correct and erase personal information, nominate a representative and raise a grievance. Section 18 gives our Grievance Officer’s details.
2. (2)
  You may complain to the Data Protection Board of India once it is operational. We treat health-adjacent information as sensitive personal data under the SPDI Rules and apply heightened protection.
(d)
California, United States
1. (1)
  The CCPA and CPRA provide rights to know, delete, correct, opt out of sale or sharing, limit the use of sensitive personal information, and receive equal treatment when exercising your rights. Send access, deletion or correction requests to app.karmiccompass@gmail.com.
2. (2)
  We do not sell personal information or share it for advertising across different services. We do not use sensitive information beyond providing the service you request, including for targeted advertising or another secondary purpose.
3. (3)
  On that basis, the right to limit sensitive-information use is satisfied by default under CPRA section 1798.121. No separate “Limit the Use of My Sensitive Personal Information” or “Do Not Sell or Share My Personal Information” link is required.
(e)
Brazil
1. (1)
  The LGPD provides rights to confirm processing, access information, correct it, request anonymisation, portability or deletion, learn about third-party recipients, and withdraw consent. You can complain to the Autoridade Nacional de Proteção de Dados at gov.br/anpd.
(f)
Washington and Nevada, United States
1. (1)
  Our separate Consumer Health Data Privacy Policy explains the health information we collect, its sources, uses and recipients, and rights to withdraw consent, access, deletion and appeal. Read it at https://www.karmiccompass.app/consumer-health-privacy. It supplements this policy and does not waive any applicable state rights.
(g)
Canada and Quebec
1. (1)
  Under PIPEDA and Quebec Law 25, you can request access and correction and withdraw consent. Quebec residents also have rights to portability, information about automated decision-making, and de-indexing. You can complain to the Office of the Privacy Commissioner of Canada at priv.gc.ca.
(h)
Australia
1. (1)
  The Privacy Act 1988 and Australian Privacy Principles provide rights to access and correct your personal information and remain anonymous where practicable. Nothing in our Terms excludes consumer guarantees that cannot be excluded under Australian Consumer Law. You can complain to the Office of the Australian Information Commissioner at oaic.gov.au.
(i)
South Africa
1. (1)
  POPIA provides rights to access, correct, delete and object to processing. You can complain to the Information Regulator at inforegulator.org.za.
(j)
Singapore
1. (1)
  The Personal Data Protection Act provides rights to access and correct personal information, withdraw consent with reasonable notice, and portability where applicable. You can complain to the Personal Data Protection Commission at pdpc.gov.sg.
(k)
Japan
1. (1)
  The APPI provides rights to disclosure, correction, addition, deletion, cessation of use and removal of personal information. You can request that provision to third parties stops. You can complain to the Personal Information Protection Commission at ppc.go.jp.
(l)
South Korea
1. (1)
  PIPA provides rights to access, correct, delete and suspend processing. Local consent rules do not lower the App’s minimum age of 18. You can complain to the Personal Information Protection Commission at pipc.go.kr.
(m)
United Arab Emirates
1. (1)
  Federal Law No. 45 of 2021 provides rights to access, correct, request deletion, object to processing and withdraw consent. You can complain to the UAE Data Office at dataoffice.ae.
(n)
Saudi Arabia
1. (1)
  The Saudi Personal Data Protection Law provides rights to access, correct, request deletion, object to processing and withdraw consent. You can complain to the Saudi Data & AI Authority through its Personal Data Protection platform at dgp.sdaia.gov.sa/wps/portal/pdp/services/reportscomplaints.
(o)
Turkey
1. (1)
  The KVKK, Law No. 6698, provides rights to know whether your information is processed, access and correct it, request deletion or destruction, object to automated processing, and claim compensation for damage. You can complain to the Personal Data Protection Authority at kvkk.gov.tr.
(p)
Mexico
1. (1)
  The LFPDPPP provides rights of access, correction, cancellation and objection, known as ARCO rights. You can also withdraw consent.
2. (2)
  Complaints go to the Unidad de Protección de Datos Personales of the Secretaría Anticorrupción y Buen Gobierno at updp.buengobierno.gob.mx. It took over the relevant private-sector data-protection functions following the 2025 reform.
(q)
Thailand
1. (1)
  The Personal Data Protection Act B.E. 2562 provides rights to access, correct, delete, restrict, port and object to processing, and to withdraw consent. You can complain to the Personal Data Protection Committee at pdpc.or.th.
(r)
Mainland China
1. (1)
  We do not market to, target or monitor users in mainland China, and the App is not listed on its app stores. On that basis, we do not currently undertake the PIPL cross-border-transfer formalities.
2. (2)
  If we identify material usage from mainland China, we will complete the required transfer assessment or restrict access before continuing to process that information.
(s)
Other countries
1. (1)
  We aim to use the most protective applicable law as a baseline for all users. Email app.karmiccompass@gmail.com to exercise the rights available in your country.

15. Adults only and children’s information

(a)
The minimum age is 18
1. (1)
  KarmicCompass is for adults aged 18 and over in every country where it is offered. Anyone under 18 may not use the App, including its journal, chat, audio and other wellness features. Parental or guardian approval cannot make an under-18 account eligible.
2. (2)
  We do not offer child or teen accounts and do not market the App to children.
(b)
How the age check works
1. (1)
  We ask for your date of birth during onboarding. Our server checks the stored date again and refuses access if it shows an age below 18 or cannot establish adult eligibility.
2. (2)
  You provide the date yourself. Email verification confirms control of an inbox, not your age or identity. We do not claim independent identity or document verification.
3. (3)
  You cannot change a known under-age date through self-service correction to obtain access. If a date is incorrect or cannot be read, contact app.karmiccompass@gmail.com for review.
(c)
Incomplete or rejected sign-ups
1. (1)
  Account creation and the first consent step happen before the date-of-birth screen. A rejected sign-up can therefore leave limited sign-in and consent records. The blocked-sign-up deletion process removes them, and support can help with immediate deletion.
2. (2)
  An incomplete sign-up without a date of birth may be removed by the abandoned-sign-up process after 24 hours. An unreadable date alone does not authorise erasure.
(d)
Older accounts and historical parental consent
1. (1)
  An existing account that no longer meets the adult-only rule cannot resume product features. The policy change does not itself authorise immediate deletion of records from teenagers who were previously eligible.
2. (2)
  Authenticated data-access and deletion services and support remain available. The restricted screen provides links to deletion and support for data requests.
3. (3)
  Historical parental-consent records follow the existing retention and deletion rules. We no longer send approval requests or offer approval links. Valid historical withdrawal links remain usable, and their previously disclosed cleanup continues.
(e)
Subscriptions and requests about a child
1. (1)
  Losing access, uninstalling the App or deleting an account does not cancel an Apple or Google subscription. Manage renewal through your store account and contact us for help with an affected subscription.
2. (2)
  If you believe a child has supplied personal information, email app.karmiccompass@gmail.com so we can restrict access and handle the information appropriately.

16. Our response to a data breach

(a)
If a personal data breach affects your information, we will take immediate steps to contain and investigate it.
(b)
We will notify the relevant supervisory authorities within 72 hours where required by GDPR Article 33 or equivalent law.
(c)
We will notify affected users without undue delay where the breach is likely to create a high risk to their rights and freedoms, as required by GDPR Article 34 or equivalent law. Where notification is required, we will use the email address associated with your account.
(d)
We will document the breach and our response in accordance with our legal obligations.
(e)
Our detailed response procedure, responsibilities and notification templates are published at karmiccompass.app/privacy/BREACH_RUNBOOK.

17. Changes to this policy

(a)
We may update this Privacy Policy from time to time. The updated policy is shown the first time you open the App after a change. Significant changes are explained in the “About this version” section.
(b)
We do not currently send advance notices by email. If fresh consent is needed, we ask when you first open the App after the change, rather than seven days beforehand. Please read the notice when it appears.
(c)
For routine updates, continuing to use the App after the effective date constitutes acceptance of the updated policy.
(d)
If a change materially affects how we process your information, particularly new processing of health-related data or a new purpose requiring consent, we obtain fresh, explicit consent before that processing starts. We do not rely on continued use for those changes.
(e)
If you do not agree, you can stop using the App and delete your account.

18. Contact and privacy responsibilities

(a)
General enquiries and privacy requests
1. (1)
  KarmicCompass is operated by Diksha Dutt, based in Panchkula, Haryana, India. For general enquiries, privacy concerns or requests about your information, email app.karmiccompass@gmail.com. Our website is karmiccompass.app.
2. (2)
  We aim to respond within 30 days. The response commitments for rights requests and grievances are set out in section 14 and below.
(b)
Privacy lead
1. (1)
  Diksha Dutt handles privacy enquiries directly at app.karmiccompass@gmail.com.
2. (2)
  Given our current scale and the EU, EEA and UK position below, we are not required to appoint a Data Protection Officer under GDPR Article 37(1). We will appoint one if our scale or processing later meets those criteria.
(c)
Grievance Officer for India
1. (1)
  Diksha Dutt is the designated Grievance Officer under the Digital Personal Data Protection Act 2023, Information Technology Act 2000 and the SPDI Rules. Email app.karmiccompass@gmail.com and include “GRIEVANCE” in the subject line.
2. (2)
  We will acknowledge your grievance within 48 hours and resolve it within 30 days. The same email address is our contact for correspondence with the Data Protection Board of India.
3. (3)
  The SPDI Rules classify the health information we collect as sensitive and require heightened protection. We do not collect biometric templates or raw biometric data. For an optional identity check, your operating system returns only the result to the device, as explained in section 1.
(d)
European Union, European Economic Area and United Kingdom
1. (1)
  KarmicCompass is not offered or marketed in the EU, EEA or UK. It must not be listed on the App Store or Google Play in those regions for this release.
2. (2)
  We do not target or advertise to people in those regions, monitor their behaviour, or collect information intended to profile their residents. On that basis, we have not appointed an EU or UK representative under GDPR Article 27.
3. (3)
  If you live in one of those regions and obtained the App through another route, email app.karmiccompass@gmail.com. We will honour your request about personal information as if GDPR applied.
4. (4)
  Before a future launch in these markets, we will complete the required legal, consumer, representative and consent work and update this policy. Section 13 explains the transfer requirements.

19. About this version

(a)
This is Privacy Policy v3.5, dated 7 September 2026.
(b)
This version reorganises the policy into plain English, with consistent headings, paragraph numbering and cross-references. It does not introduce new uses of your information or change your privacy rights.
(c)
The policy continues to describe the limits of account deletion, outstanding provider verification and the adult-only requirement. Earlier versions remain preserved as historical records; their descriptions of past arrangements do not replace this version’s current terms.

How It Works

Voice recordings

Photographs

Device identification

1. Information We Collect

Account and sign-in information

Journal and chat content

AI-generated observations

Wellness and activity information

Preferences and settings

Voice recordings and recovered transcripts

Photographs

Crisis signals and safety follow-up

Device identifiers and trial protection

App Passcode and biometrics

Saved insights and birth details on your device

Local reminders and background activity

Push notification delivery

Security and abuse-prevention records

Subscriptions and billing

Feedback and reported AI messages

AI and voice-use allowances

Support and deletion requests

Crash diagnostics and operational records

Unfinished Apple authorisation cleanup

Interrupted delivery and cleanup on your device

Historical parent or guardian consent records

No use of your content for model training

2. How We Use Your Information

Providing the App

Operating and protecting the service

3. Legal Grounds, Sensitive Information and Data Principles

Providing the service you request

Legitimate interests

Consent

Health-related and other sensitive information

Crisis records and your choices

Legal obligations

Data Protection Impact Assessment

Data protection principles

4. Automated Assessments and Your Rights

What is automated

How the results are used

Your choices

5. AI Processing and the Information Sent

Our AI provider and connection

Filtering and safety controls

Training and provider retention

Adult eligibility

Arya chat

Voice transcription

Journal analysis

Daily insights and longer reports

In-app letters and memory updates

Daily Horoscope

Quiz generation

Export letters and cover text

Nightly letters from Arya

Other short Arya requests

Automated crisis assessment

6. Exporting Your Information

What the journey PDF contains

How the file is created

Structured copies and missing information

7. Storage, Security and Our Website

Cloud storage and account security

Website hosting and deletion forms

Optional website error reports

8. Incognito Mode

Conversation handling

Errors and security exceptions

9. Service Providers

Google Firebase and Google Cloud

Google Cloud Vertex AI

Former Gemini Developer API service

RevenueCat

Sentry

Expo Push Service

Gmail or Google Workspace email delivery

Apple App Store