Privacy Policy

Astro Clock AI is an astrology, numerology and life-intelligence service. It is operated by [LEGAL ENTITY NAME], whose registered address is [REGISTERED ADDRESS]. In this policy, we and us mean that entity. You means the person using the service. That entity is both the agency collecting your personal data and the agency retaining it.

Under India's Digital Personal Data Protection Act, 2023 we are the Data Fiduciary for the personal data described here, and you are the Data Principal. This policy covers the website and web app at [APP DOMAIN], including the pages you can use without an account: the free calculators, the Convergence page, the shared-result pages, the insight articles and the WhatsApp opt-in page. The Convergence page is worth naming separately because it takes a full birth record - date, time and place - from someone who has no account at all.

The service is provided as it is described in the Terms of Service. A separate DPDP compliance statement works through the Act obligation by obligation and says which ones this product meets today. Readings, verdicts and timings produced here are interpretations of traditional systems. They are not medical, legal, or financial advice.

A note on how to read this. Sections that begin with a plain statement of a limitation are not hedging. Where the product does not yet do something you might reasonably assume it does, this policy says so in the same words we would use internally.

Two regimes are relevant, and only one of them has started. Saying so matters, because a policy that describes only the law that has not commenced is incomplete on its face.

What binds us now. Section 43A and section 72A of the Information Technology Act, 2000, and the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 - the SPDI Rules. Those rules require a published and accessible privacy policy stating our collection, purpose, disclosure and security practices; notice of the fact of collection, the purpose, the intended recipients and the name and address of the agency collecting and retaining the data; a route to review and correct what we hold; a way to opt out and withdraw; a named Grievance Officer who answers within one month; permission before a third-party disclosure; and transfer abroad only to a recipient maintaining the same level of protection. This notice is written to satisfy those alongside the DPDP Act.

What is coming. The DPDP Act, 2023 was brought into force in stages. The sections covering notice, consent, the rights described below, and the repeal of section 43A are in the tranche currently expected to commence on [DPDP COMMENCEMENT DATE - RE-VERIFY AGAINST THE GAZETTE]. That date is stated as a placeholder rather than a fact for two reasons we would rather show than hide: published summaries differ by a day over whether the Rules were gazetted on 13 or 14 November 2025, and a proposal to shorten the commencement period had not been gazetted as at the last check. Whoever publishes this page must confirm the date against the Gazette itself.

We are not waiting for that date. Where this notice describes a DPDP obligation we do not yet meet, it says so rather than deferring it to commencement.

Three separate things happen to data here, and they deserve separate lists: what you type in, what we compute from it, and what is recorded without you doing anything. The tables below are field-level rather than categorical, because a category summary would hide the fields that matter most.

What you give us

Four of those fields are open free text that no schema constrains beyond a length cap: your chat questions, your life-event descriptions, your outcome notes and your Prashna questions. People write things about health, money, family and grief into fields like these. We store what you write, word for word, and we do not filter or redact it. Please treat those boxes accordingly. Your goal is not one of them - it is a six-way choice, and you cannot type into it.

What we compute

Almost everything the product shows you is calculated, not stored from an outside source. These derived values are still personal data about you, and several of them are close enough to your birth details that they should be treated as such.

The Full Reading deserves a paragraph of its own, because of when it happens. It is a narrative of several hundred words about you. Generation is triggered the moment your account is created, without you asking for it - but that request is fire-and-forget, and on the serverless hosting this product runs on it usually does not survive the response being sent. In practice the reading is therefore written the first time you open your Kundali screen, which fires the request again and waits for it. Either way it is produced without you requesting it, it is regenerated whenever your birth details change, and it is stored on your profile record until you delete your account.

We think generating it before you ask is wrong, and we are changing it. Under a consent-based regime we may process only what is necessary for the purpose you agreed to, and shipping your chart to an AI provider before you have opened a single reading is not that. It should be behind a button you press. Until it is, this paragraph is the disclosure, not a defence.

What is collected automatically

We set no cookies at all. Not for sessions, not for preferences, not for anything else. The two localStorage entries above are the complete list of what this site stores on your device. One is your sign-in credential and the other is a display preference.

Your check-in dates are worth calling out because they are not obviously birth data: they are a rolling record of which calendar days you opened your dashboard, and they are visible to you in the product as your streak.

This is the most sensitive thing we hold, so here is exactly why each part is needed and what happens if it is missing.

• Birth date. Required. It fixes the positions of the slow-moving planets, the Vimshottari dasha sequence, and every numerology number that derives from a date - Mulank, Bhagyank, your personal year and personal day. Without it there is no chart at all, which is why there is no way to use the product without supplying one.
• Birth time. Optional, and the single highest-value field you can give us. The ascendant moves roughly one degree every four minutes, so the birth time is what decides your rising sign, the cusp of all twelve houses, and therefore which area of life every planet is read as governing. It also fixes the Moon to within a fraction of a degree, which is what pins the nakshatra, the pada and the starting point of your dasha timeline.
• Birth place. Required, because it is not the name we need but the latitude, longitude and timezone behind it. Latitude changes the house cusps; longitude and the timezone convert your local clock time into the exact UTC instant of birth. A place resolved to the wrong coordinates silently corrupts the ascendant and every house, so we resolve it properly rather than accepting free text.

What actually happens without a birth time. We do not refuse to give you a reading, and we do not pretend the reading is unaffected. Where a reading needs the ascendant or the houses, it is withheld and your confidence score is reduced. Everything else is computed from an assumed midday birth, because the calculation needs some instant to work from: that includes your Moon position, your nakshatra and pada, and your entire dasha timeline. Those are approximations. The Moon moves about thirteen degrees a day, so without a real birth time the nakshatra can come out wrong and the dasha boundaries can be out by months, and nothing on the screen looks different from a timed chart. Your planetary signs and the whole of your numerology never needed a time and are unaffected.

Two secondary uses of birth data you should know about. Both are honest, and neither is obvious. First, when you ask a Prashna question, the chart for that question is cast using the coordinates stored on your birth record, as a stand-in for where you are now. Second, the timezone offset derived from your birth place is used as your assumed present-day timezone when working out what hour it is where you are for message scheduling. If you were born somewhere you no longer live, both of those are approximations.

What we store, and in what form. Your birth date and time exactly as you typed them, the place label, the resolved latitude and longitude, the timezone offset, and the UTC instant we calculated from them - which is a midday-assumed instant if you gave no birth time. The coordinates and that instant are stored on your record and never sent back to your browser: the app shows you only the date, time and place label you entered. The place-lookup suggestions are the exception, and only while you are choosing - each suggestion carries coordinates to your browser so the app can send the right ones back when you pick one. All of these are held twice, once on your account record and once on your own profile record.

On whether this counts as sensitive data. Indian law does not classify birth date, time and place as sensitive: the DPDP Act draws no special categories at all, and the SPDI Rules' closed list does not include birth data. We think that understates the risk. A birth date and an exact birth place together are a strong quasi-identifier, and a birth date is a common security question. What we will not do is tell you we therefore treat these fields as sensitive, because the Security section below lists what we do not encrypt, do not log and do not rate-limit, and a claim like that would contradict it. The accurate statement is narrower: we minimise what we send out, we keep these fields out of web addresses, we do not sell them, and we are working through the security gaps listed at the end of this notice.

You can add profiles for a partner, a family member, a client, or anyone else, and each profile holds a complete birth record for that person: their name, their relationship to you, their birth date and time, their birth place, and the precise coordinates we resolve from it. We also generate and store an AI-written narrative reading about them - written by the same third-party model when one is configured, and by our own engine when none is - exactly as we do for you.

That is another living person's personal data, given to us by someone other than them. Please read the rest of this section before you add anyone.

What we ask of you. Only enter another adult's birth details if they know and agree, or if you are their parent or lawful guardian. Do not enter the details of a person who would object to a stranger holding them. If you are adding client profiles in the course of your own practice, you must have that person's permission before you enter their details.

That does not move our duty onto you. Under the DPDP Act we remain the Data Fiduciary for that person's data and remain responsible for how it is handled here, irrespective of any agreement to the contrary and irrespective of whether you actually asked them. Some policies use a clause like the one above to transfer the notice and consent duty to the user. It cannot be transferred, and we are not attempting it: the duty stays with us, and we are not currently discharging it - see below.

What we do with it. We compute their chart and readings, we generate and cache an AI reading about them, and we send derived values from their chart to the same AI provider described below. We do not contact them and we do not build any relationship with them. Their record is visible only to your account, with one exception: if you publish a compatibility result as a share link, that public page carries their first name, cut to fourteen characters, alongside the match percentage and the verdict phrase. Anyone holding the link can read it. Nothing else about them is published, and you can revoke the link at any time.

What we cannot currently offer them. Being direct about this matters more than sounding compliant. A person whose profile you create receives no notice from us, and has no self-service way to see or delete what we hold about them. That is a failure of our own notice duty, not a gap in yours. Their practical routes are two: ask you to delete the profile, or write to the grievance officer named below. If they write to us we will ask for the name, birth date and birth place as entered, and for enough information to satisfy us that they are the person those details belong to, and we will then delete the record and confirm that we have. We will not require them to hold an account here to make that request.

Deleting someone else's profile. You can delete any profile other than your own from the Profiles page. That removes the profile record, including their birth details and the cached AI reading about them. Be aware of one gap: any life events, practice logs or chat messages you recorded against that profile are not removed with it, and remain linked to your own account. Deleting your account does remove them, and clearing your chat history removes the chat messages. We describe that in full in the retention section.

Read this first, before the list. Every purpose below names consent as its basis, and that consent has not yet been asked for or recorded. The signup flow does not present a consent checkbox, does not link to this policy, and stores nothing to say you accepted it. Creating an account is the only affirmative act, and reading a notice is not consent - the DPDP Act requires a clear affirmative action, a consent request in plain language, an option to read it in an Eighth Schedule language, and the contact details of the person who answers about it. None of that exists today. The honest position is that we have no valid consent record for your data. That is a defect under s.6 and it is being fixed. It is not cured by this page, and it is not cured by your continuing to use the service.

The bases named below are therefore stated as intended bases. Under the DPDP Act there are only two routes: your consent under s.6, or one of the closed list of certain legitimate uses in s.7. The only one of those that could apply to a service like this is s.7(a) - personal data you voluntarily provided for a specified purpose, where you have not indicated that you object to it being used for that purpose. There is no legitimate-interest ground and no contractual-necessity ground in the Act, and we do not claim either.

• Running your account. Your name, email and password hash exist to create your account, sign you in, and tell you apart from other users. Intended basis: your consent under s.6; and for the account record itself, s.7(a) - you gave us these details for exactly this purpose and have not objected to their being used for it.
• Computing your charts and readings. Your birth date, time and place, and everything we derive from them, exist to produce the astrology and numerology output that is the entire product. Intended basis: your consent under s.6.
• Answering your questions with an AI model. Your chat questions, the recent conversation and the life events logged for the profile a question is about, and that profile's derived chart values, are sent to a third-party AI provider so it can write an answer grounded in the chart. Your Full Reading is generated the same way, without your asking, as described above. Intended basis: your consent under s.6 - which, for the Full Reading in particular, has not been given, because you were never asked before it ran.
• Remembering your history. Your life events, decisions, outcomes and practice logs exist to make later answers reflect what has actually happened to you, and to show you patterns over time. Intended basis: your consent under s.6, given when you log each entry.
• Messaging you. If, and only if, you opt in, your phone number is used to send you at most one message a day. Basis: your separate, explicit consent under s.6, recorded with the exact wording you agreed to and the time you agreed to it. This is the only place in the product where a real consent record exists, and it is the model the rest should follow.
• Preventing abuse. Your IP address is held briefly in server memory to limit how often a small number of endpoints can be called. It is never written to our database. This is not a separate lawful basis: it is transient technical data handled in the course of delivering the service you asked for under s.7(a), and it is discarded within minutes.
• Fixing errors. When something fails, our server writes a log line. Same footing as the line above - part of operating the service you provided your data to under s.7(a), not a business interest of ours. What can end up in those logs is described under Security.

There is also no way to keep your account while switching off the AI processing described above. The only granular consent you can withdraw today is the WhatsApp one. The Act expects withdrawing consent to be as easy as giving it, and offering you nothing but account deletion does not meet that. We would rather write that down than imply a control that does not exist. A per-user switch for AI processing is the fix, and it is on the list at the end of this notice.

Six external parties receive data, in four groups, and this is the complete list: two AI providers, a place-lookup service, a font service, our hosting provider and our database provider. Nothing else leaves our servers.

Groq, and Anthropic - the AI providers

When you use the AI chat, and when your Full Reading is generated, we send a request to Groq. If no Groq key is configured, we send it to Anthropic instead. Both are companies in the United States, so this is a transfer of your personal data outside India. If neither provider is configured, or if the provider call fails or times out, a deterministic engine on our own server writes the answer instead and nothing leaves our infrastructure - which is why a reading can be genuine output of this product without an AI having touched it.

What is sent: your question exactly as you typed it; up to six previous turns of your conversation about the same profile; up to five of the life-event entries you recorded against that profile, with their type, tags and date as well as the words you wrote; up to three behavioural pattern notes we derived from those entries; your Moon, Sun and Ascendant including their longitudes to four decimal places, their nakshatra, nakshatra lord, degree in sign and pada; your dasha lords and the effect our engine reads into them; your numerology numbers, your karmic-debt flags and your pinnacle cycles with their age ranges; the yogas and doshas detected in your chart; your strongest and weakest planet with per-planet strength scores; your dominant element and life theme; your Navamsa vargottama and Arudha Lagna placement; your Janma Nakshatra trait; the transiting Moon's sign and house; the verdict, confidence and reasoning our decision engine produced; and your daily energy score. The Full Reading request sends the chart and numerology parts of that, but no question, no conversation history and no life-event text.

Whose history goes with a question. Conversation turns, life events and the patterns drawn from them are kept per profile. A question about someone else's profile carries only what you recorded against that profile, never your own entries, and a question about you never carries what you recorded for someone else. Chat messages stored before this separation existed carry no profile, and we treat them as your own.

What is not sent: your name, your email address, your password or its hash, your birth date, your birth time, your birth place name, your latitude and longitude, and your phone number. None of those fields is included in the request.

Do not read that as anonymous. A four-decimal-place ascendant longitude is a function of the exact instant and location of your birth, and the Moon longitude narrows the date to minutes. Your numerology numbers are arithmetic reductions of your birth date, and the pinnacle age ranges we send bound your birth year independently. The payload converges on your date of birth from several directions at once, so someone holding it could work backwards toward your birth moment. We describe it as your birth details being withheld and precise derivations of them being sent, because that is what it is.

Retention, training and deletion at the provider. What Groq and Anthropic retain, for how long, and whether they use it to improve their own models is governed by their contracts rather than by this policy, and we will not restate their commitments here as though they were ours. We train no model of our own on your data. Our duty does not stop at their door: the Act requires us to have a valid contract with each processor, to include an appropriate contractual security provision, and to cause a processor to erase personal data we made available to it when your data is erased here. The current status of those contracts is [DPA STATUS - GROQ, ANTHROPIC, VERCEL, MONGODB]. On erasure we will issue a deletion instruction to the AI provider for the data we sent. Be clear about the limit of that: nothing in our software can reach into their systems, so what happens after the instruction is sent depends on their contract, not on our code.

Cross-border. Transfers outside India are permitted under the DPDP Act subject to any restriction the Central Government may notify for a particular country; no country is presently notified as restricted, and if that changes we will say so here. Under the SPDI Rules, which bind us today, we may transfer only to a recipient maintaining at least the same level of protection, and only where necessary to provide the service or with your consent. Whether either provider's endpoint is pinned to a particular processing region is part of the contract review above.

Open-Meteo - the place lookup

When you type a birth place, we ask Open-Meteo's free geocoding service to resolve it, unless our bundled city list already returns a full set of matches on its own. In practice most of what you type in the place field is sent to them, and it is sent as you type it - the typeahead fires on each pause in your typing, not once per finished place name. The place text is part of the web address of that request, along with the network address the request comes from. Nothing else goes with it - no name, no date, no time, no account identifier. This happens at signup, when you edit your birth details, and when an anonymous visitor uses one of the free calculators or the Convergence page. Open-Meteo operates from [OPEN-METEO OPERATING REGION], so the place text may be processed outside India.

Place of birth is personal data, and a place name travelling in a web address is visible in the recipient's own access logs. Two further details, because this page enumerates rather than summarises. We hold the resolved result in our server's memory for up to an hour, keyed by the place text you typed, so a repeated lookup does not re-ask Open-Meteo; that cache is not attached to your account, is not reached by account deletion, and clears itself. And a failed lookup writes a log line that records the length of what you typed and the reason it failed, but not the text itself.

Google Fonts

Our pages load two typefaces from Google's font service. That means your browser contacts Google on every page load, and your network address and browser identification are disclosed to Google as a result. Google LLC is a company in the United States, so this too is a transfer of personal data outside India, and it happens on every page load - including on public pages, before you interact with anything and whether or not you have an account. We set no cookie through it and we receive nothing back from it; what Google does with the request is governed by their terms, not by ours, and we do not make claims on their behalf. Self-hosting the two fonts would remove the only third-party request a visitor's browser makes, and it is on the list at the end of this notice.

Our infrastructure providers

Our application runs on Vercel and our data is stored in MongoDB. Vercel receives every request you make and holds our server logs; MongoDB holds every field in the three tables above. Both process data on our instructions in order to run the service. The region our database sits in is [DATABASE HOSTING REGION], and the region our server functions run in is [SERVER HOSTING REGION]. If either of those resolves to a region outside India, then your account record and every field in the tables above is stored outside India, and this notice will say so in plain words once the regions are filled in.

Who does not receive your data

• No payment processor. We do not collect payment card details, and no payment provider receives anything from us, because there is no payment code in the product at all and nothing is charged.
• No messaging provider. Even if you opt in to WhatsApp messages, no messaging vendor is connected today. Messages are composed and recorded on our own server, and nothing is transmitted to your phone. We will not enable an external provider without telling you first.
• No advertising or analytics vendor. See the next section.

Separately from all of this: if you tap share on a result card, your device hands that card to whichever app you choose. If you choose WhatsApp, the text of the card travels in the web address that opens it. What that app does with it is outside our control and outside this policy.

• No analytics of any kind. There is no analytics library, no tag manager, no product-analytics tool and no session-recording tool anywhere in this application.
• No advertising, and no advertising pixels. We run no ads, and we carry no advertising network code. Nothing here profiles you for advertising, and nothing about you is passed to an ad platform.
• No selling or renting of your data. We do not sell, rent, or trade your personal data, your birth details, or anything derived from them. The recipients named in the previous section are the only ones, and they are service providers, not buyers.
• No cookies, and no cross-site tracking. We set no cookies at all, and we do not track you across other websites.
• No tracking of people who open a shared link. A shared result page increments a plain counter, and that is the whole of it. No network address, no browser identification, no referring page and no per-visitor record is created.
• Nothing extra on a shared card. A shared result can carry a match percentage or an energy score, a short verdict phrase, and first names cut to fourteen characters. There is no field in that record for a birth date, birth time, birth place, email address, Moon sign, nakshatra, ascendant or dasha lord, so none of those can appear on it. What we cannot yet promise is that the page stays out of search results: we ask search engines not to index it, but that instruction is added by the page's own script, and our robots file does not cover the share path, so a crawler that does not run scripts will not see it. Treat a share link as fully public - anyone with the address can open it, and it may be indexed until we move that instruction to the server.
• No account needed for the free tools. The public calculators, the Convergence page and the reading preview do not create an account, and nothing you type into them is written to our database - we checked each of those handlers rather than assuming it. The one thing that does leave is the Open-Meteo place lookup described above.
• No passwords or sign-in tokens in our logs. No log statement in this application is written to record a password, a password hash, or an authentication token. One caveat we would rather give you than leave you to discover: our unexpected-error handler writes the whole error object, so we cannot rule out a credential reaching a log through that path. Redacting that handler is on the list at the end of this notice.

Deleting your account is one button, in Settings, under Data and Privacy. It takes effect immediately. Here is precisely what it removes.

Deleted with your account: your account record, including your name, email, password hash, goal, birth details and check-in history; every profile you created, including profiles for other people and every cached AI reading on them; your entire chat history; your life events, including the descriptions and outcome notes you wrote in your own words; your practice logs; your Prashna questions; every message we composed for you and the values behind it; your delivery settings, including your stored phone number; every share link you created, which stops those public pages resolving; your WhatsApp consent record; and your reactions to insights, each of which stores the exact wording you reacted to. That is ten collections, and it is all of them - the code iterates a single declared list, so a collection added later either goes on that list or shows up as a gap in review.

That last one was missing from this page. This paragraph said nine collections and listed nine, while the code has iterated ten since insight reactions were added - and the sentence claiming it was all of them was the part that was wrong. The list in the code was always correct and deletion always cleared all ten; what failed was the review this page promises, and the test that was supposed to catch it had been written from the same nine-item list. Both are fixed. Recording it here for the same reason the paragraph below exists.

An earlier version of this page said that life events, practice logs and Prashna questions survived account deletion. That was true when it was written and it is no longer true: all three are now deleted, and there is a test that writes a real row into each one and fails if any of them is still there afterwards. We are leaving this paragraph in rather than quietly removing the admission.

One gap that remains. Deleting a single profile for another person does not remove the life events, practice logs or chat messages you recorded against that profile. They stay attached to your account until you delete the account itself - or, for the chat messages, until you clear your chat history. If you want them gone sooner, write to the grievance officer below.

How long we keep things otherwise - and this is the honest weak spot. Two automatic limits exist in the whole product. A share link stops resolving ninety days after it is created, and the database is instructed to delete the record itself at that point. And your check-in dates keep only the most recent ninety, with older ones rolling off. Nothing else expires. Your account, your profiles, your chat history, your life events, your practice logs and your questions are kept until you delete them or delete your account, with no purge after any period of inactivity.

That is not what the Act asks for. Under DPDP s.8(7) a Data Fiduciary must erase personal data when you withdraw your consent, or as soon as it is reasonable to assume the purpose it was collected for is no longer being served - whichever comes first - unless retention is required by law. Withdrawal we handle: deleting your account erases everything listed above. Purpose exhaustion we do not, because no dormancy rule is implemented anywhere in this product. What we intend to define and build is a dormancy period after which an untouched account and every reading derived from it are erased, with a warning to you before it happens. Until that ships, the accurate statement is the one above: we keep it until you tell us not to. We would rather write that than print a retention schedule the software does not enforce.

You can clear your chat history at any time without deleting your account, using the Clear chat history control on the chat screen; it asks you to confirm, and the messages are erased on our server, not just hidden. You can revoke an individual share link from the shared page itself. Turning off WhatsApp messages deletes the stored phone number rather than just flagging it unused, although the consent record showing what you agreed to and when is deliberately kept as evidence while your account exists - deleting the account removes that record too.

Two things deletion does not reach. Data already sent to an AI provider cannot be recalled by our software; what we can do is issue the deletion instruction described in the previous section. And your sign-in token remains cryptographically valid until it expires, because we do not maintain a revocation list; in practice it stops working because the account it points at no longer exists.

One qualification on any promise to remove records by hand. The DPDP Rules require a Data Fiduciary to retain certain processing records for a minimum period in relation to specified purposes, and whether that is a general floor or a narrow one is genuinely unsettled. So: we will remove what you ask us to remove, except where a law requires us to keep a minimal record, and if that ever applies to you we will tell you which record and why.

The rights below come from the DPDP Act, whose relevant sections commence on the date discussed under The law that applies, and from the SPDI Rules, which give you a right to review and correct what we hold today. We are not waiting for the later date. Each right is listed with the actual route to exercising it now, including where that route is a manual one.

• See what we hold, and what we do with it. The right has two halves and this page tries to serve both. For the data: your birth details, name, email, plan and language are on the Settings page, and your chart, readings, chat history, life events and questions are visible on their own pages. For the processing: the How we use it and Who else receives it sections above are the standing account of what we do with it and who it goes to. Ask the grievance officer and we will send you both in one document, written for your account rather than in general.
• Take a copy away. There is no full data export. The only download in the app is the plain-text file on the Reports page, which covers one report and nothing else. If you want a complete copy in a portable form, write to the grievance officer and we will compile it manually. Building a real export endpoint is on the list at the end of this notice.
• Correct your birth details. Settings, under Birth Details. Editing them updates both copies we hold and regenerates your cached AI reading, so a corrected chart does not sit behind a stale narrative.
• Correct your name. There is no control for this in the app yet, although the underlying service supports it. Ask the grievance officer and we will change it. Your name is not cosmetic here - it feeds several numerology numbers.
• Correct your email address. No screen in the app can change it, because your email is your account identifier. That is our design problem, not a limit on your right: write to the grievance officer from the address on the account, or tell us enough about the account for us to be satisfied it is yours, and we will change it directly for you. Decoupling the login identifier from the email address so you can do it yourself is on the list at the end of this notice.
• Erase your data. Settings, under Data and Privacy, then confirm. Read the retention section above for exactly what that reaches.
• Withdraw consent for messaging. The WhatsApp page, one tap. It takes effect immediately and deletes your stored number. Turning it off is never made harder than turning it on.
• Withdraw consent for everything else. There is no partial switch, and we will not describe deleting your account as one. The Act expects withdrawal to be comparable in ease to giving consent, and closing your account is not comparable to unticking a box. Today, deleting the account is the only mechanism that exists; a per-purpose switch, starting with AI processing, is on the list at the end of this notice.
• Nominate someone. You may nominate a person to exercise these rights in the event of your death, or of your inability to exercise them yourself because of unsoundness of mind or infirmity of body. There is no form for this in the app. Write to the grievance officer with the nominee's full name, their contact details, their relationship to you, and how their authority is to be evidenced when they use it, and we will record it. The corresponding clause in the Terms of Service sets out the same particulars.
• Complain. Use the grievance route below first. If you are not satisfied, you may complain to the Data Protection Board of India. The route to the Board is [DATA PROTECTION BOARD COMPLAINT ROUTE], and it is a placeholder because the Board's own complaint channel is not yet operating - its complaint-handling powers are not in force and no members have been appointed. When a channel exists we will publish the link here rather than describe it.

To let us find your records, tell us the email address on your account. We will not ask you for your password, and we will never ask for it by email or message.

This service is for people aged 18 and over. Under Indian law anyone under 18 is a child, and processing a child's personal data requires verifiable consent from a parent or lawful guardian. Please do not create an account if you are under 18, and please do not create an account on a child's behalf.

What we do not do yet. We collect a birth date from everyone, but we do not currently check it against a minimum age at signup, and we have no parental consent flow. Nothing stops a person under 18 from registering today. That is a gap we are closing, and stating it is more useful to you than a clause implying a gate that is not there.

The prohibition that is about the product, not the paperwork. Section 9(2) of the DPDP Act bars processing that is likely to cause any detrimental effect on the well-being of a child, and no consent makes that permissible. For a product that generates predictive statements about a person's health, marriage, money and misfortune, that is a design constraint rather than a policy line. Our position is that this service is not designed or offered for anyone under 18, and that the age gate that keeps them out is the fix. We will not dress that up: the instructions we give the AI model tell it to be honest and specific and never fear-based, but there is no hard rule in the product today barring a reading from making a prediction about health, death or misfortune, and we are not going to claim one here. Writing that rule is on the list at the end of this notice. If you see output you would not want a young person to read, tell the grievance officer - we would treat that as a defect.

What happens if we find out. If we learn that an account belongs to someone under 18, we will delete the account and everything in it. Account deletion now reaches every collection we hold for a user, so that removal is complete, and we will confirm to you when it is done. If you believe a child has an account here, tell the grievance officer and we will act on it.

On the two related prohibitions: we carry no advertising network code and no behavioural analytics, we run no ads, and we do not profile or track anyone across sites, child or adult. That is a statement about what is in our application. It does not extend to the Google font request described above, which discloses a visitor's network address and browser identification to Google on every page load regardless of age - which is one more reason to self-host those fonts.

This section describes only measures that exist in the running product. Nothing here is aspirational.

• Your password is stored only as a bcrypt hash. The password itself is never written down, and cannot be recovered from what we hold.
• Your sign-in token carries nothing but an opaque account identifier and an expiry. No name, email, birth data or plan travels inside it. It is sent in a request header, never in a web address.
• No personal data is placed in the web address of any page on this site, so your details do not leak through your browser history or through the referring-page header sent to third parties. Three things do travel in a web address, and none of them is a page you navigate to: the place text you type goes to our own place-lookup request and on to Open-Meteo, as described above; some background requests carry the internal id of the profile being read; and if you tap share and choose WhatsApp, the text of the card you chose to share is in the address that opens it. The first two are visible in our hosting provider's request logs.
• Share links use ninety-six bits of random data as their identifier rather than a sequential or guessable one, and what a share record is allowed to contain is fixed in its structure rather than filtered on the way out.
• Your phone number is stored in exactly one place and is never sent back to your browser, not even to you. The app shows only its last four digits.
• When a request fails on our side, you get a generic message. Internal error detail is not exposed to your browser.
• No log statement is written to record a password, password hash or authentication token, and credentials are not stored in our source code repository.

The honest limitations. This application does not itself encrypt your birth details, your email or your chat messages. They are stored in plain form in our database, and any protection against physical or storage-level access comes from the database provider rather than from us. We do not enforce an encrypted connection to the database from within our own code. We do not rate-limit or lock out repeated sign-in attempts, so we cannot claim protection against password-guessing; we also accept passwords as short as six characters and do not check them against known-breached lists, and our signup form will tell anyone who asks whether a given email address already has an account here, which discloses membership of an astrology service to a stranger. We do not offer two-factor authentication, email verification, a password reset flow, or a way to sign out of other devices. Our API accepts requests from any website rather than only our own, and we keep no list of revoked tokens - so if a sign-in token were ever taken, we could not invalidate it, and it would remain usable from anywhere until it expires thirty days after it was issued. We do not keep an access log or audit trail, which means we could not tell you who accessed a particular record. We set no browser security headers - no Content-Security-Policy, no HSTS, no X-Frame-Options - and your sign-in token is held in browser storage where any script running on our pages could read it. We are working on each of these; none of them is stated here as though it were solved.

What the abuse limits actually do. Less than the phrase suggests. The limit counts requests in one server's memory, it covers only a handful of public endpoints, and it resets whenever we deploy or a new instance starts. Because of how our hosting sits in front of the application, requests arrive carrying our host's address rather than yours, so the limit is shared across everyone rather than applied per visitor. Two public endpoints - the place typeahead and the reading preview - have no limit at all.

What can end up in a log. Our log lines identify you by account identifier, so a person with access to the server console can tell that a particular account was active and what kind of message it was sent. Two paths can carry more than that. When a request fails unexpectedly, our error handler writes the whole error object, and a validation or type error embeds the value that caused it - so a birth field, a name or a phone number can reach a log that way. And our message system prints the composed body of a message outside production; in production it prints only the account id, the language and the trigger. Neither path is redacted today. A failed place lookup no longer records the place text you typed - only how long it was and why it failed.

If there is a breach. If we become aware of a personal data breach we will tell you without delay, through your account or the contact details we hold, and the message will state what happened and how far it went, when it happened, what it means for you specifically, what we have done and are doing about it, what you can do to protect yourself, and a contact who can answer your questions. We will make an initial intimation to the Data Protection Board without delay and file the detailed report within seventy-two hours. Now the limitation, because a commitment without it would be worth nothing: we keep no access log and no audit trail, no request log and no monitoring, so we may not detect an unauthorised access at all, and if we do we may not be able to tell you precisely which records were touched. Adding that logging is part of the same work as everything else on this list, and it is the part that makes the rest of this paragraph deliverable.

If you have a complaint about how your personal data has been handled, or you want to exercise any of the rights above, contact our grievance officer.

• Name: [GRIEVANCE OFFICER NAME]
• Designation: [GRIEVANCE OFFICER DESIGNATION]
• Email: [GRIEVANCE OFFICER EMAIL]
• Telephone: [GRIEVANCE OFFICER PHONE]
• Postal address: [REGISTERED ADDRESS]

This one contact is designated to serve as our DPDP contact person for questions about processing, our Grievance Officer under the SPDI Rules, and our grievance officer under the Consumer Protection (E-Commerce) Rules, 2020. Where those regimes set different response periods, the shortest applies.

We aim to acknowledge your complaint within 48 hours of receiving it, and to resolve it within 30 days. If we cannot, we will tell you why and when we expect to. Those are the strictest periods that apply to us rather than the longest we could rely on, and they are an operational commitment: nobody should publish this page until the address above is genuinely monitored to that standard. This same contact answers questions about how we process your personal data, and it will be repeated in every reply we send about your rights.

If our answer does not satisfy you, you may take the matter to the Data Protection Board of India, by the route named under Your rights.

When this policy changes, we will update the effective date at the top of this page. If a change materially affects what we collect, what we do with it, or who receives it, we will tell you in the app before it takes effect rather than relying on you to re-read this page.

The list this page keeps referring to. In one place, the things this notice says we do not do yet: a consent step at signup with a stored record of what you agreed to; a per-purpose withdrawal switch, starting with AI processing; an 18+ age gate and a parental consent route; gating the Full Reading behind an action you take; a data export you can download yourself; decoupling your login identifier from your email so you can change it; a dormancy rule that erases data whose purpose has run out; access and audit logging, so a breach can be detected and scoped; redacting the unexpected-error handler and the message log; encryption of birth data at rest by this application; rate limiting and lockout on sign-in; browser security headers and an origin allowlist on our API; a server-side no-index rule on shared pages; a hard content rule stopping a reading from predicting death, serious illness or specific misfortune; self-hosting the two fonts; and a reviewed Hindi version of this notice behind a switcher on this page.

When those are fixed, this policy will be rewritten to match, and we will not quietly soften the wording without the underlying change landing first. That has already happened once in the other direction: the retention section above used to disclose three collections that survived account deletion, and it now records that they no longer do.

For anything about your data, use the grievance contact above - it reaches a person who can act on it. For everything else, including questions about your plan or a problem with the product, write to [SUPPORT EMAIL].

Our registered entity is [LEGAL ENTITY NAME] at [REGISTERED ADDRESS], and that entity is the one that collects and retains the personal data described here. Indian law governs how we handle it.

This notice is not a contract, and it does not ask you to agree to anything or to give up anything. In particular it names no court and no exclusive forum: nothing here affects your right to approach a consumer forum under the Consumer Protection Act, 2019 - including one where you live or work - or to complain to the Data Protection Board. Contractual terms, including governing law, live in the Terms of Service.

The product speaks Hinglish, English and हिंदी. This document is written in English only, deliberately: a legal text whose meaning drifts between three translations protects nobody. The English version governs, and if we ever publish a translation and the two disagree, the English version is the one that applies.

What the law asks for, and what we offer today. The DPDP Act gives you the option to access this notice in English or in any language listed in the Eighth Schedule to the Constitution of India, and it means an option you can take yourself, at the moment you are given the notice - not a translation produced after an email exchange. This page has no language switcher, so we do not meet that today. Given the app already ships in Hindi, that is harder to defend than most of the gaps on this page. A reviewed Hindi version of this notice, behind a switcher here, is on the list above. Until it exists: ask the grievance officer for any Eighth Schedule language and we will supply a translation, with the English version remaining the operative one.