DPDP Compliance Statement

The Digital Personal Data Protection Act, 2023 is India's first comprehensive law on personal data. It sets out how any organisation that decides why and how personal data is handled must behave: give notice, take consent, keep the data secure, delete it when the purpose ends, and answer to the person it belongs to. It gives every individual a set of rights over their own data, and it is backed by penalties running to hundreds of crores of rupees. The Digital Personal Data Protection Rules, 2025 fill in the operational detail - what a notice must contain, what security measures count, how a breach must be reported.

Two words the Act uses, and which of them is you

• A Data Principal is the individual the personal data is about. That is you. If you enter someone else's birth details, that person is a Data Principal too, even though they do not have an account here.
• A Data Fiduciary is whoever determines the purpose and means of processing that data. That is us - [LEGAL ENTITY NAME], the operator of Astro Clock AI. The word is deliberate: a fiduciary holds something on trust for someone else.
• A Data Processor processes data on a fiduciary's behalf. The AI providers that write your reading, and the service that turns a place name into coordinates, process personal data on our instructions and we treat them as processors. As the table below records, we have not executed a processor contract with any of them, which the Act requires and which we are working on. Under the Act, using a processor does not move the responsibility off us.

This page is not the privacy policy and does not replace it. The Privacy Policy tells you what happens to your data. This page shows the working against the law, clause by clause, so that you can check our answer rather than take our word for it. The Terms of Service govern your use of the product itself.

This section is stated as at 7 September 2026 and is subject to change. The commencement position is genuinely moving, and two points in it could not be resolved with confidence, so both are flagged below rather than smoothed over. Check the Gazette before relying on any date here.

• The Act received assent on 11 August 2023 but did not come into force then. It provided that different provisions could be brought into force on different dates by notification.
• In November 2025 the Government issued the commencement notifications and the Digital Personal Data Protection Rules, 2025. Commencement was staged: a first tranche immediately, covering definitions and the establishment of the Data Protection Board; a second tranche a year later, covering the registration of Consent Managers; and a third tranche eighteen months later, covering nearly everything in this page's table.
• That third tranche is the one that matters here. Notice, consent, the general obligations including security, breach reporting and erasure, the rules on children, all of the Data Principal rights, cross-border transfer, the Board's power to hear a complaint and the entire penalty regime all fall into it. On the published notification dates that lands in mid-May 2027.
• First uncertainty. The notifications are dated 13 November 2025 and the clocks run from the date of Gazette publication, which some sources record as 14 November. The eighteen-month date therefore reads as 13 or 14 May 2027 depending on the source. We are not printing a single day as certain.
• Second uncertainty. A proposal to compress the eighteen months to twelve was reported during 2026, which would move the date to around November 2026. As at the most recent source consulted for this page, it had not been notified in the Gazette and remained a proposal. It may have changed since.
• What this means in practice today. The Data Protection Board exists as a body, but its power to inquire into a complaint and impose a penalty sits in the third tranche, and as at the most recent source consulted no Chairperson or Members had been appointed. There is, at the date of this page, no forum that can hear a DPDP complaint.
• Until the relevant provision commences, the older Indian regime remains the operative law: section 43A of the Information Technology Act, 2000 and the 2011 rules made under it, which require a published privacy policy, a designated grievance officer and redressal within one month. We are treating those as binding now.

What the older regime requires of us today, and where we fall short

Having said the 2011 rules bind us now, it would be evasive to measure ourselves only against a law that has not started. Here is the same honesty applied to the regime that is actually in force.

• Rule 4 - a published privacy policy. Met, at /privacy.
• Rule 5(3) - the name and address of the agency collecting the data. Not met. Both are placeholders on all three legal pages.
• Rule 5(7) - an opt-out, and a right to withdraw consent. Not met for AI processing. There is no way to keep your account and stop the AI processing; the WhatsApp opt-out is the only working withdrawal in the product.
• Rule 5(9) - a named grievance officer, redressal within one month. Not met. The officer is a placeholder, so there is no one to write to.
• Rule 7 - transfer only to a recipient ensuring the same level of protection. Not evidenced. We have no data processing agreement with any recipient, so we cannot show the protection is equivalent.
• Rule 8 - a comprehensive documented information security programme, with an audited ISO 27001 certification as the deemed-compliance safe harbour. None exists. The Safeguards section below is a description of the current state, not a documented programme.

Section 72A of the Information Technology Act, 2000 also sits over all of this: it criminalises disclosing personal information in breach of a lawful contract, and it attaches to individuals. Given that birth-derived data goes to vendors under nothing but their standard published terms, that is one more reason the processor contract review is the first item on our list rather than a later one.

We are not treating the 2027 date as permission to wait. Everything in the table below is measured against the standard the Act sets, not against what is enforceable this month. Where we fall short we say so, because the alternative is a page that claims compliance with a law that has not started and would not survive it starting.

One row per obligation, with the section or rule it comes from. The third column describes the running product, not an intention - except where it says planned, which marks work that is committed but not built.

Twenty-five rows, and not one of them says yes. Thirteen say Not yet, eleven say Partly, and one is Not applicable. That is worse than the first draft of this page reported, and it is worse on purpose: three rows that had awarded themselves a tick were downgraded when the evidence was checked against the code rather than against the intention. A page of unbroken ticks would tell you less than this does, and a page with three false ones would tell you something untrue.

On a narrow screen the table itself scrolls sideways; the page does not.

The Act gives you a set of rights over your own data. For each one, here is the control that exercises it today, and where there is no control, the fallback and what we will do with the request. They are in the same order as the table above, and none of the table's rights rows is missing from here.

One thing to read first. Until the contact details in the Grievance section are filled in, none of the by-email routes described below is actually reachable. That is the single blocking item before this statement can be published, and it is why several rows in the table above say Not yet rather than Partly.

Withdrawal of consent - stopping the processing

This one comes first because it is the page's worst rights gap and burying it would be the easiest dishonesty available. For WhatsApp messaging, withdrawal is one tap on the same page that took the consent. For everything else - the birth-data processing itself and the AI processing built on it - there is no route today other than deleting your account. You cannot keep your history and switch the AI off. We are not describing that as a choice; it is a missing control, and it is on the list at the end of this page.

Access - a summary of your data and what we do with it

Most of what we hold about you is visible in the app while you are signed in: your account and birth details in Settings, the people you have added in Profiles, your questions in Chat and in Ask a Question, your logged events in Memory, your kept practices in Practice, and your generated readings in Reports and on your Kundali. (Those are inside the app, so you will be asked to sign in first.) The processing activities themselves are described in the Privacy Policy.

Some of it is not visible, and you should know which parts. Your birth latitude, longitude and timezone offset are stored on your account and on every profile but are deliberately never returned to you. Your WhatsApp number is stored but only its last four digits are ever displayed. The messages our delivery system composed for you, and the computed values behind them - which can include text you wrote yourself in a logged life event - have no screen at all. That store is an untyped field, so we will not describe its contents as bounded. And the chat view returns only your first hundred messages, although we keep all of them. Until a machine-readable export exists, those are the parts you would have to ask us for.

What does not exist yet: a machine-readable export. There is no download-my-data button and no API for it. Until there is, email [GRIEVANCE OFFICER EMAIL] from the address on your account and we will compile your records by hand and send them to you.

Knowing who received your data

You do not have to ask. The recipients are published in the Cross-border section, with what goes to each, rather than held back until someone requests them. The list is not yet complete, and the gaps are blanks rather than refusals: our hosting provider and our database provider are not named, and between them they hold everything rather than a subset, so those two are the most important names missing. We also cannot yet tell you which of the two AI providers is configured in production. All three are placeholders in that section and on the list at the end of this page, which is why the corresponding row in the table says Partly.

Correction - fixing what is wrong

• Birth date, time and place. Settings, then Edit under Birth Details. The change updates your account and your own profile together, and regenerates the cached AI reading so that an old narrative built from wrong details does not survive the correction. This matters more than it sounds: a wrong birth place means wrong coordinates, and wrong coordinates silently corrupt every house in your chart.
• Gender and language. Settings. Gender is optional, is used for exactly one reading, and is never guessed from anything else.
• Your name. There is no edit control in the app, though the service can accept the change. Email [SUPPORT EMAIL] and we will make it. Your name is not cosmetic here - several numerology numbers are computed from its letters.
• Your email address. It cannot be changed by any route. It is your login identifier and nothing in the service updates it. The only remedy today is to delete the account and register again, which loses your history. We are not pretending otherwise.

Erasure - deleting what we hold

Settings, then Delete account under Data and Privacy. There is a confirmation step. The deletion removes every collection in our database that is keyed to your account: the account record itself, every profile you created including profiles for other people, your chat history, your logged life events and outcome notes, your daily practice log, your Prashna questions, your delivery messages and delivery settings, your publicly shared cards - which stop resolving immediately - and your WhatsApp consent record.

This was wrong until recently, and we would rather say so than quietly present the fixed version. Three of those collections - life events, the practice log and Prashna questions - were built after the delete path was written and were never added to it, so they survived deletion as orphaned rows keyed to an account that no longer existed. They are now deleted with everything else. The fix is not a promise: the test that covers it writes a real row into each of the nine collections through the public API, asserts the rows are actually there, deletes the account, and then asserts every one of them is empty - so a future collection added and forgotten fails the build rather than quietly surviving your deletion.

Four limits that still apply. Deleting a single profile you created for someone else does not remove the life events and practice records attached to that profile; deleting your whole account does. A sign-in token issued before deletion cannot be revoked and stays cryptographically valid until it expires, up to 30 days. Anything already transmitted to an AI provider cannot be recalled by us - we can stop sending, we cannot unsend. And the place-name cache described in the Cross-border section is held in the server's memory rather than the database, is keyed on the place text alone with nothing identifying attached, and is not reached by account deletion; it simply expires within the hour.

One qualification we are not going to hide. The Rules contain an unresolved minimum one-year retention of logs and associated processing data, which sits in tension with an unqualified promise of immediate erasure. We have not had it resolved by counsel. It is set out at the end of this page, and we would rather flag it than write a delete-everything promise we might not be able to keep.

Grievance redressal

Covered in full in the Grievance redressal section below, including the response window we hold ourselves to and the escalation path past us.

Nomination - who acts for you if you cannot

The Act lets you nominate one or more people to exercise your rights if you die or become incapable of exercising them yourself. The Rules allow a fiduciary to run this through its ordinary terms of service rather than a dedicated feature, which is what we do, because there is no nomination feature in the product.

To nominate someone, email [GRIEVANCE OFFICER EMAIL] from the address on your account with the nominee's full name and a contact address for them. We will record it against your account and confirm. Two honest caveats: we do not verify a nominee's identity today, and we have no automated way for a nominee to prove incapacity or a death to us, so any such request would be handled case by case.

At signup, for your birth details

Signup asks for your name, email, password, birth date, birth place and optionally your birth time and a goal. Short privacy notes sit beside the birth date and the birth place fields explaining what each is used for - though not beside the birth time field, which is the field that unlocks the ascendant and every house, and which should carry one. What there is not, and this is the honest position, is a consent step: no tick box, no link to this page or the policy, and no stored record that you were shown anything. Creating the account is the only affirmative act, and the Act asks for more than that. Building the consent step, and storing which version of the notice you saw, is the single largest piece of work on the list at the end of this page.

For AI processing of your chart and your questions

There is no separate consent for this and no way to switch it off while keeping your account. Two things happen automatically: a narrative reading is generated for a profile when it is created or when its birth details change, which means an external model is called at signup before you have opened the chat; and questions you ask in the AI chat are sent for an answer along with recent conversation turns and recent life events you logged. What is sent, and to whom, is in the next section. If you do not want this, the only control available today is not using the chat, and for the automatic reading, deleting the account.

For WhatsApp messages - the one consent we take properly

This is the exception, and it is built the way the Act expects consent to be built:

• The box starts unticked. The submit button stays disabled until you tick it, and the server independently rejects any request that does not carry an explicit true - it checks that before it even reads the phone number.
• The wording is written by the service, not by the page, and is stored word for word with your consent record. It reads: I agree to receive at most one WhatsApp message a day from Astro Clock AI on the number I have given, sent only when my own chart, my own numerology cycle or something I logged myself produces a reason to write, and only inside the hours I choose. I understand I can turn this off at any time from the same page, and that doing so deletes my number.
• The consent record stores the version of that wording, the language your account was set to at the moment you agreed, the time you gave it, and the last four digits of the number - never the number itself. Your number is stored in exactly one field, the one the messages would be sent to. The opt-in page shows you the last four digits only.
• One correction to a claim we used to make here. We used to say the number is never returned to the app, not even to you. That is true of the opt-in page but it is not true of the product: a separate settings endpoint (/api/delivery/settings) does return the full number to a signed-in request on your own account, and echoes it back when it is changed. Nothing returns it to anyone else, and opting out deletes it. Narrowing that endpoint is on the list at the end of this page.
• Withdrawal is one tap on the same page that took the consent. It switches messaging off, stamps the time you withdrew, and deletes the stored number rather than flagging it unused. The delivery engine checks that switch before it composes anything. Opting out is never rate-limited more tightly than opting in. The intended design gives the two a shared budget of twenty changes an hour, which would already mean opt-in attempts consuming the allowance an opt-out needs; in the product as it actually runs, neither is limited at all, because that limit is declared on a route that a duplicate registration shadows - see the Safeguards section. Either way, turning messages off is never the harder request, and giving the opt-out its own budget when the limit is reconnected is on the list below.
• A second caveat we would rather state than hide. The consent check above guards the opt-in endpoint. The same settings endpoint mentioned two bullets up will accept a destination number and an enabled flag from any signed-in request on that account, with no consent check and without creating a consent record - a second, unguarded path to the messaging-enabled state. It has no screen in the app, but it exists, and closing it is on the list below.
• The consent record itself is kept after withdrawal, with the withdrawal time on it, because a consent record whose whole purpose is evidence has to outlive the number. It is deleted if you delete your account.
• Nothing is actually being delivered today. No messaging provider is connected. The delivery system records what it would have sent and sends nothing. The opt-in page says so above the form.

Under the Act a child is anyone who has not completed 18 years. India set the line at 18, not 13 or 16. Processing a child's personal data requires verifiable consent from a parent or lawful guardian, obtained through checks the Rules describe - identity and age details already held, or details voluntarily provided, or a token issued by an authorised entity such as a digital locker service.

The same duty applies with no age element at all to a person with a disability who has a lawful guardian. Section 9(1) puts the two classes in one sentence, and Rule 10's verification requirements apply to both. We have no mechanism to identify such a user and no guardian-consent flow, so an adult with a court-appointed or statutory guardian could register today and we would not know. If you act as a lawful guardian for someone, contact the grievance officer before creating an account rather than after.

Our position. This service is offered only to people aged 18 and over, as our Terms state. Please do not create an account if you are under 18, and please do not create one on a child's behalf.

What is not enforced. We ask everyone for a birth date and check only that it is not in the future. There is no age gate at signup and no parental consent flow, so nothing currently stops a person under 18 registering. We are not going to describe a gate that does not exist. An age check at signup is the proportionate fix for a product with no reason to serve minors, and it is on the list at the end of this page. If we learn an account belongs to someone under 18 we will delete it and its data; if you believe a child has an account here, tell the grievance officer.

Advertising: the one part we meet without qualification. The Act absolutely prohibits targeted advertising directed at children, and parental consent does not unlock it. We serve no advertising to anyone, of any kind. There is no analytics, no tag manager, no advertising pixel, no session recording, no marketing profile and no third-party tracker anywhere in this product - the only things your browser stores are your sign-in token and the life area you last chose. That limb is not capable of being breached here, for a child or for an adult.

Behavioural monitoring: a different question, and we are not going to answer it with the advertising evidence. The same prohibition covers tracking and behavioural monitoring, and we do keep records of behaviour, because the readings are built on them. We store the calendar days you open the app for the last ninety days, the practices you mark as kept, the life events, decisions, emotions and outcomes you log - including whether you followed the guidance we gave - an automatic topic classification of what you asked about, and patterns we infer from that history; some of it then travels to an AI provider so the reply can refer to it. None of that exists to profile you commercially, and none of it is sold or shared for advertising. But because there is no age gate we cannot say it is never applied to a child. What closes this is the age gate, not the absence of advertising, and we would rather write that down than award ourselves a tick for answering the easier half.

Detrimental effect: a separate, absolute prohibition. The Act also forbids processing likely to have a detrimental effect on a child's well-being. That has nothing to do with advertising and parental consent does not unlock it either. A service that comments on health, marriage, money and misfortune should not be pointed at a minor, and without an age gate we cannot assert that it is not. We treat this as a design constraint rather than a solved obligation, and reviewing the predictive health and misfortune language is part of the same work as the gate.

For the same reason, and for adults too: nothing this product produces is medical advice, a diagnosis, or a substitute for a registered medical practitioner, and no remedy offered here is presented as curing, treating, mitigating or preventing any disease or condition. Where a reading touches on health it is an interpretation within a traditional system, not a clinical statement. The Terms set that out at length; it is repeated here because this is the page that documents the health commentary.

The Act permits personal data to be transferred outside India, subject to any restriction the Central Government notifies for a particular country or territory. We are not aware of any country having been notified as restricted - that is an absence of findings rather than an exhaustive search of the Gazette, and it is on the list to re-check before this page is published. If a country is notified, and it affects a service we use, we will change the service or stop the feature rather than continue.

Every outbound transfer this product makes is listed below, grouped by recipient. If a recipient is not named here, your data does not go to it. We have dropped the count that used to open this paragraph: it was taken from the number of places in the server that make an outbound call, which is a count of code paths and not of the companies that receive anything, and it did not match the list underneath it.

Groq, and Anthropic - the AI providers

Both are companies based in the United States. Only one of them is actually used, and which one depends on which API key is set in the deployment: Groq is tried first, and Anthropic is used only when no Groq key is present. The provider configured in production is [AI PROVIDER CONFIGURED IN PRODUCTION] - read from the running server rather than written into this page, because which vendor receives a question is decided by which API key is set on the server, and a page naming the wrong one would be a false statement about where personal data goes. When neither is configured, a local engine in our own server answers and nothing leaves at all. When an external model does write an answer, the answer itself says so.

What is deliberately withheld: your name, your email, your birth date, your birth time, your birth place and your coordinates are not placed in the request. The payload is assembled from a fixed list of fields and those are not on it.

What is sent, stated precisely, because it is more than the previous paragraph might suggest:

• Your question, word for word, and up to six previous turns of the conversation.
• Up to five life events you logged - the description in your own words, the event type, the tags you gave it and the date you logged it - and up to three behaviour patterns we inferred from your logged history. The dates matter: a timestamp raises the re-identification risk of everything sent with it, which is why we list it rather than saying only that the descriptions go.
• Your Moon, Sun and Ascendant positions to four decimal places of longitude, plus signs, nakshatras and padas. We will not pretend this is anonymous. A longitude at that precision is a function of the exact moment and place of your birth, and a specialist could work backwards from it. It is pseudonymised birth data, not anonymised data.
• Numerology numbers derived from your birth date and from the letters of your name, your dasha periods, detected yogas and doshas, planetary strengths, your current timing layers, today's energy score, and where relevant the verdict and reasoning our own decision engine produced for you.
• For the automatic Full Reading, the same chart context but no question, no conversation history and no life events. That call fires when a profile is created or its birth details change, without you asking for it.

What we cannot tell you. How long either provider retains what it receives, and whether it is used to improve their models, is governed by contracts we have not negotiated - we use their standard terms. Other copy in this app used to say conversations are never used to train shared models. We cannot evidence that from our side today, so that claim has been removed and reduced to what we control: we train no model of our own on your conversations. Reviewing these two contracts is the highest-value item on the list at the end of this page.

Open-Meteo - turning a place name into coordinates

When a birth place is not in our bundled city list, the place name you typed is sent to Open-Meteo's geocoding service to resolve coordinates and a timezone. Only the place name goes: no name, no date, no time, no account identifier. It travels as part of a web address, which means it can appear in intermediaries' logs as well as theirs. This also happens for visitors with no account, through the place field on the free tools and during signup. Resolved results are cached in our server's memory for an hour; that cache is keyed on the place text alone with nothing identifying attached, and it is not reached by account deletion - it simply expires.

Google Fonts

The two typefaces this site uses are loaded from Google's font service on every page view, including pages you can see without an account. That discloses your IP address and browser to Google before you have interacted with anything. A web font pulls from two Google hosts, one for the stylesheet and one for the font files themselves, and they are the only third-party requests your browser makes on our pages. Self-hosting the two font files would remove them entirely, and that is on the list below.

Sharing - the one transfer you start yourself

When you share a result card, the app first tries your device's own share sheet, which sends the image through your operating system and never through us. When that is not available it falls back to opening WhatsApp with the card's text in the web address, which hands that text to WhatsApp - a Meta company - and then to whoever you send it to. Once it leaves this way it is outside our control and outside this statement. We mention it because it is a real transfer of personal content, even though nothing happens until you tap share.

Our own infrastructure

The application runs as serverless functions on [HOSTING PROVIDER NAME] and stores data in a MongoDB database operated by [DATABASE PROVIDER NAME]. Both are processors acting for us, and unlike every other recipient on this page they hold all of it rather than a subset. Our database region is [DATABASE HOSTING REGION] and our server region is [SERVER HOSTING REGION]. All four are placeholders because they are deployment facts that cannot be read out of the source code, and we would rather show you a blank than a guess - but a blank identity is a gap in the section 11(1)(b) duty, not a stylistic choice, which is why that row in the table says Partly.

How this list stays true. There are only a handful of places in the server that make an outbound call, and every one of them is named above, so a new recipient cannot be added without a code change that is visible in review. That is the mechanism; we are not claiming a change-control process that does not exist.

The Rules list what counts as a reasonable safeguard: encryption, masking or tokenisation; access control; logging and monitoring; backups; log retention; contractual safeguards with processors; and appropriate technical and organisational measures to make all of that effective in practice. That last item is the residual one, and it is the limb under which the absence of a documented security programme most obviously fails, so we are not leaving it off the list we then measure ourselves against. Only measures that exist in the running product appear under what we do.

What is in place

• Your password is stored only as a bcrypt hash. The password itself is never written anywhere and cannot be recovered from what we hold.
• The sign-in token carries only an opaque account identifier and an expiry. No name, email, birth data or plan travels inside it, and it is sent in a request header, never in a web address.
• Your birth date, birth time, coordinates, email address and chat content are never put into a web address. Two things are, and we would rather name them than write an absolute we cannot keep. As you type a place name while searching for a birth place, that text is sent to our own server as part of a web address (/api/places?q=...), so it can appear in your browser history and in our hosting platform's request logs. And sharing a card to WhatsApp puts the card's text into the WhatsApp address. Signed-in reads also carry a profile identifier in the address, which is an opaque database id and not personal content. Moving the place lookup into a request body is on the list below.
• Publicly shared cards are built on a closed schema: fields that are not on an explicit list cannot be stored, so a birth date, birth time, birth place, email, nakshatra or ascendant has no field to land in. Only a first name appears on a match card: the first word of the name, capped at 14 characters, with anything that is not a letter, an apostrophe, a full stop or a hyphen removed - which is what stops a phone number or an email address reaching a public page as a "name".
• A share address is 96 bits of randomness, not a sequential identifier, and the view counter is a plain number: no IP address, browser, referring page or per-visitor record is kept. A share stops working 90 days after you create it - the server refuses to serve an expired one, which is the part that is guaranteed - and the database is also instructed to delete the row itself.
• Your phone number is stored in exactly one field, the one the messages would be sent to, and is deleted the moment you opt out. The consent record holds only the last four digits, and the opt-in page shows only those. It is returned in full to a signed-in request on your own account through a separate settings endpoint, which is set out in the Consent section and is on the list below.
• Request bodies are capped and server errors return a generic message rather than internal detail. The free convergence reading and the three free calculators each count requests per address and refuse a caller that goes over. Read the next list before treating that as rate limiting: it is four endpoints out of the nine that are written as though they have it.
• Credentials are not committed to our source repository.

What is not in place - stated because you should know

One note on this list before it starts. Read together, these items describe how a live product holding sensitive birth data could be attacked, and publishing that while it is still true is difficult to defend as a reasonable safeguard in its own right. We are not removing it - a compliance page that hides a defect is a misrepresentation - but the four exploitable items (authentication rate limiting, security response headers, origin restriction and session revocation) are days of work, not quarters, and the right sequence is to close them and then publish this list as history. Publishing the specifics is only the honest choice once they are no longer live, which is one of the reasons this document still carries a draft banner.

• The application does not encrypt, mask or tokenise your birth details. They are stored as ordinary fields. Any encryption at rest that exists comes from our database provider's own storage encryption, not from anything this product does. Copy elsewhere in the app used to say birth data is encrypted; that copy was wrong and has been corrected.
• The application does not itself enforce an encrypted connection to the database. Whether one is used is a deployment setting.
• There is no access log and no audit trail. We could not tell you who accessed what, and that also limits our ability to detect a breach in the first place.
• Sign-in and registration have no rate limit, no failed-attempt lockout and no challenge. There is no brute-force or credential-stuffing defence.
• Five of the nine abuse counters do not run. This is a correction to an earlier draft of this page, which described them as working. The public share page, the public message-info page, creating a share, and the WhatsApp opt-in and opt-out each declare a counter as route middleware in one router, while an earlier router registers the same paths without it - so the request never reaches the guarded version. We measured this rather than inferring it: 260 requests to the public message-info endpoint in twenty seconds all returned success against a declared limit of 240 a minute, while the same probe against a calculator was refused on the twenty-first request as designed. What actually stops someone hunting for other people's shared cards is the 96 bits of randomness in the address, not any of this.
• Where a counter does run it is a brake on accidents rather than a defence: it is held in a single server process, it resets on every restart or deploy, it does not coordinate across serverless containers, and because the app never tells the framework it is sitting behind a proxy, in production every request arrives wearing the proxy's address and all address-keyed limits collapse into one global bucket. Two unauthenticated endpoints that accept birth details - the signup preview and the place lookup - declare no limit at all.
• No security response headers are set - no content security policy, no strict transport security, no clickjacking protection - and the API accepts requests from any origin.
• Sessions cannot be revoked. Logging out clears the token on your device, but a token already issued stays valid until it expires, up to 30 days.
• There is no email verification, no password reset, no password change and no two-factor authentication.
• Some server logs still contain personal data. Outside production, the messaging system prints the full composed message text next to an account identifier as a development aid. A failed place lookup no longer writes the place name you typed - it records the length of the query and the error only. No part of this product deliberately logs a password, a sign-in token, an email address or chat content. One uncontrolled path remains: when an unexpected server error occurs we write the whole error object to the log with no redaction, and some database errors quote the value that caused them - which on a duplicate registration would be an email address. Log redaction is on the list below.

Breach notification - what we would do

The Act sets no materiality threshold: every personal data breach is reportable, to the Board and to each affected person. If one occurred, we would:

• Tell each affected person without delay, through their account or the contact details they gave us, in plain language, describing the nature, extent and timing of the breach, the consequences likely to matter to them, what we have done and are doing about it, what they can do to protect themselves, and a contact who can answer their questions.
• Tell the Data Protection Board without delay with a description of the breach, its nature, extent, timing, location and likely impact.
• Follow that within 72 hours with the fuller report the Rules require: updated detail, the circumstances and reasons, mitigation measures, any findings about who caused it, what we have changed to stop it recurring, and a report of the notices we sent to affected people.

That is a documented intention, not a tested process, and we would rather say so. Because there is no logging or monitoring today, our practical ability to detect a breach quickly is limited. Access logging is therefore the first item of security work, ahead of the notification machinery that depends on it.

If you have a complaint about how your data has been handled, or about how we answered a request, raise it with us first. The Act requires you to exhaust our route before approaching the Board, and it is also the fastest way to get it fixed.

Until the contact details below are filled in, none of the by-email routes described on this page is actually reachable. That is the single blocking item before this statement can be published, and until it is done the response commitment underneath the card is an intention rather than a promise anyone can hold us to.

This one contact is designated to answer under section 8(9) of the DPDP Act, Rule 5(9) of the 2011 IT rules, and Rule 4(4) of the Consumer Protection (E-Commerce) Rules, 2020. Where those set different requirements the strictest applies - which is why the card carries a designation and a telephone number as well as an email, since the e-commerce rules require both and require them today rather than in 2027.

What we need from you. Write from the email address on your account, or tell us that address if you cannot. It is the only identifier we can match a request to, so a request from an unrelated address will get a request for verification rather than an answer. That applies to a rights request as much as to a complaint: the route is the same email, and the identifier is the same address.

How quickly we answer. We acknowledge within 48 hours and resolve within 30 days. That is not our own target: the e-commerce rules and the 2011 IT rules both require redressal within one month, and they bind us now. The DPDP Rules set a ceiling of 90 days; publishing the longest available number would be a way of promising less. If something genuinely needs longer, we will tell you why and when, before the 30 days is up.

For a rights request rather than a complaint - an export, a correction, a deletion, a nomination - we answer within 30 days on the same basis. Where the request needs manual work because the control does not exist yet, we will say so and give you a date.

If we do not resolve it. A complaint to the Data Protection Board of India is made under section 13(3), after you have exhausted our route. The Board is to receive complaints through the digital office it is required to operate under the Rules. That facility is not live, and as at the most recent source consulted for this page no Chairperson or Members had been appointed - and the Board's power to inquire and impose a penalty sits in the tranche of the Act that has not yet commenced. So we cannot give you the communication link the Rules ask us to publish, because there is not yet one to give. When the route opens we will publish the link here. In the meantime the older regime still applies and a complaint about a failure to redress a grievance can be pursued under it. This is the position as at 7 September 2026 and will change.

This is the list that makes the rest of the page worth reading. Every item is a real gap between what the Act expects and what the product does, taken from an audit of the source code rather than from a checklist. They are grouped by what they are, not by how bad they look.

Lawful basis, consent and notice

• The first item, because everything else depends on it. There is no lawful basis for the core processing under the Act as it will stand. None of the section 7 legitimate uses fits a consumer astrology service, so the basis has to be consent, and the consent step does not exist.
• No notice-and-consent step at signup, and no record of which version of a notice a user saw or when they accepted it.
• No privacy note beside the birth-time field in onboarding, although the birth date and birth place steps both carry one.
• No consent for, and no way to decline, AI processing while keeping an account. The automatic reading fires at registration before the user has used any AI feature.
• No consent mechanism for the birth details a user enters about another person - a partner, a family member, a client. That person did not agree to anything, cannot see their record, and has no route to ask us to delete it. This is the largest unaddressed obligation in the product.
• A second delivery-settings endpoint can set a phone number and switch messaging on without passing the WhatsApp consent check and without creating a consent record. It has no screen in the app, but it exists and needs closing.
• These legal pages are English only. A Hindi version is owed, given the product already speaks Hindi to its users.

Rights

• No published contact. Until the grievance officer's name, designation, email, phone and postal address are filled in, every by-email route on this page is unreachable and the section 8(9), Rule 9, Rule 14(1) and e-commerce grievance duties are all unmet.
• No machine-readable export of your data, and several categories we hold have no screen at all: your birth coordinates and timezone, your stored phone number, the delivery messages composed for you, and your chat history beyond the first hundred messages.
• Deleting a profile you created for someone else leaves the events and practice records attached to that profile behind. Deleting the whole account does now remove them.
• No nomination feature; the interim route is email.
• No way to change your email address; no edit control for your name.
• No session revocation, so deletion and logout do not invalidate a token already issued.
• No rights-request form. The route is an email described inside the Grievance section rather than a distinct, tracked channel.

Children and persons with disability

• No age check at signup and no parental consent flow, despite an 18+ requirement in the Terms.
• No way to identify a user who has a lawful guardian, and no guardian-consent flow. The duty in section 9(1) applies to that class with no age element at all.
• Because there is no age gate, we cannot assert that the behaviour records the product keeps are never applied to a child, and we cannot assert that no child is receiving readings that comment on health, marriage, money and misfortune. Reviewing the predictive health and misfortune language is part of the same work as the gate.

Retention

• No retention period is defined or enforced for anything except publicly shared cards, which expire after 90 days. Everything else is kept until the account is deleted.
• There is an unresolved question in the Rules about a minimum one-year retention of logs and associated data, which sits in tension with a promise of immediate erasure. We are not writing an unqualified delete-everything promise until counsel resolves it.

Security

• No encryption, masking or tokenisation of birth data by the application.
• No access logging, audit trail or monitoring, which also limits breach detection.
• No rate limiting or lockout on sign-in and registration.
• No security response headers, and an unrestricted cross-origin policy on the API.
• No email verification, password reset, password change or two-factor authentication.
• No documented information security programme of the kind the 2011 rules require, and no certification against one.
• Five endpoints declare an abuse counter that never runs, because an earlier router registers the same paths without it: the public share page, the public message-info page, creating a share, and the WhatsApp opt-in and opt-out. Four endpoints do carry a working counter. Where one does run it is per-process, resets on deploy, and keys on the proxy rather than the caller in production. The signup preview and the place lookup accept birth details with no limit at all.
• The birth place you type travels in a web address to our own server, so it can reach browser history and hosting request logs. Moving that lookup into a request body would close it.
• Your phone number is returned in full by the delivery settings endpoint to a signed-in request on your own account. Narrowing that endpoint to the last four digits would match what the opt-in page already does.
• Outside production, the full text of a composed message is still printed to the server console as a development aid. Birth place names no longer reach any log line.
• Unexpected server errors are written to the log in full with no redaction, and a database error can carry a field value such as an email address into that line.
• The public share page asks search engines not to index it only after the page runs in a browser, and our robots file does not cover that path. A crawler that ignores scripts would not see the instruction.

Processors and transfers

• No data processing agreement has been reviewed or executed with any recipient, so we cannot state their retention or model-training position, and we have no contractual way to make any of them erase anything.
• Fonts are loaded from Google on every page view, disclosing every visitor's IP address before any interaction. Self-hosting them removes the only third-party browser requests on the site.
• Our hosting provider and our database provider are not yet named on this page, and nor are their regions, although between them they hold everything. Section 11(1)(b) asks for identities, and a category discharges nothing.
• We cannot yet tell you which of the two AI providers is configured in production, because that is a deployment fact rather than a property of the code.

Closed since the last revision of this page

Kept here rather than deleted, because a list that only ever grew would tell you nothing about whether anything gets fixed.

• Closed. Account deletion used to leave three collections behind - your logged life events and outcome notes, your practice log and your Prashna questions - as orphaned rows keyed to an account that no longer existed. All nine user-owned collections are now deleted with the account, and a test writes a real row into each one and asserts every one is empty afterwards, so a collection added later and forgotten fails the build instead of quietly surviving your deletion. This also makes the deletion panel in Settings accurate: it says deleting removes all associated data, and as of this fix it does, subject to the four limits set out in the Erasure section.
• Closed. Onboarding, Settings, the login page and the pricing section used to say birth data is encrypted and never shared. Neither was accurate. Those strings now say what is true instead: the data is used only to build your own readings, is never sold and is never shown to other users, only values derived from it go to the AI providers named above, and you can delete it at any time.
• Closed. The chat page used to say conversations are never used to train shared models. We cannot evidence that until the provider contracts are reviewed, so the claim has been reduced to what we control: we train no model of our own on your conversations, and your question does go to those providers.
• Closed. Marketing copy described live payments through a payment gateway. No payment integration exists and no payment details are collected. The copy now says the product is free and takes no payment details, which is also why no payment data appears anywhere in this statement.
• Closed. The life area you last chose used to stay in your browser after you logged out, which matters on a shared device. Logging out now removes it.

We will keep this list here as items are closed rather than quietly deleting it. A page that only ever showed completed work would not be evidence of anything.

This statement is published in English, and the English version governs. The rest of the product renders in Hinglish, English and हिंदी; these legal pages deliberately do not, because a legal text whose meaning drifts between three translations is a liability rather than an accessibility win. If you would like this statement in Hindi, ask the grievance officer and we will provide it.

This page describes our own product against our reading of the Act and its Rules. It is not legal advice, and it is not a certification by anyone. Statutory references were taken from a reading of the Gazette text and should be verified against the Government-hosted copy. Where a statement here conflicts with the Privacy Policy, tell the grievance officer - the two are meant to agree, and a conflict is a bug in one of them.

For anything else about your data, write to [SUPPORT EMAIL].

One last honesty note about this page itself. The statutory citations were read out of a copy of the Gazette text obtained from a third-party mirror, because the Government site refused the request. The copy is strongly self-authenticating, but every section and rule number here should be checked against the Government-hosted PDF before publication, along with the commencement dates, which are the single most likely thing to have moved since this was written.