Article 13 Notice
The information that has to be given at the moment data is collected — on the age gate, the birth-data screen and the quiz consent card. A separate obligation from the privacy policy, and a commonly missed one.
This is not a shorter privacy policy. Art. 13 GDPR is a separate obligation with a separate trigger: the information must be given at the moment the data is obtained, on the screen doing the obtaining, before the person hands anything over. A privacy policy linked from Settings does not discharge it, and a link alone at the point of collection does not discharge it either.
It is commonly missed because it looks like duplication. It is not: the privacy policy is the full layer a user can go and read; this is the first layer they cannot avoid seeing. The EDPB's transparency guidelines endorse exactly this layering, and it is the only way to satisfy Art. 13 on a phone screen without a wall of text nobody reads.
1. Where this notice fires
| # | Screen | Apps | What is obtained there |
|---|---|---|---|
| N1 | Age gate | All three | A date of birth, entered neutrally. In European it is retained and carried forward as the product's birth date; in Crystal and Vedic it produces an age band and, on failure, a device-local block flag |
| N2 | Birth-data screen | Vedic, European | Date of birth (confirmed, not re-asked in European), birth time, birth place |
| N3 | Quiz consent card | Crystal | Intention and energy answers, treated as Art. 9 special-category data, on explicit consent |
N1 and N2 are different collections in European even though the field looks the same. The age-gate date is the product birth date, shown once for confirmation and never re-asked — one collection, one retention basis. That is a good minimisation decision and it creates an Art. 13 consequence people miss: the retention disclosure has to be made at the age gate, because that is where the data is obtained. A gate screen that implies the value is discarded, followed by silent retention, is the defect.
⚠ Consequently, European's age-gate copy cannot be the same string as Crystal's and Vedic's. Crystal and Vedic genuinely discard the date and keep a band; European keeps it. One shared string across three apps would be false in one of them. This is a build item, not a copy nicety.
2. N1 — age gate, first layer
Crystal and Vedic (date discarded)
Why we're asking for your date of birth
To check you meet the minimum age. We don't keep this date — we keep only whether you're old enough. If you're not, we store a marker on this device so the check isn't simply retried, and nothing else.
Infoash UG (haftungsbeschränkt) is responsible for this. → How we handle your data
European (date retained)
Why we're asking for your date of birth
Two reasons, and we'd rather say both now than ask twice. It checks you meet the minimum age — and, because it's the same date, we keep it and use it to work out your sign, so you won't be asked again on the next screen. If you're not old enough, we store a marker on this device and nothing else.
Infoash UG (haftungsbeschränkt) is responsible for this. → How we handle your data
Both variants must state, or link one tap away: legal basis, retention, the right to withdraw or delete, and the supervisory-authority complaint route. The link opens the relevant section of the privacy policy, not the top of the document.
3. N2 — birth-data screen, first layer
What we do with your birth details
Date tells us your sign. Time places your ascendant — in the Vedic app, your nakshatra and pada as well. Place lets us compute the chart against the correct local time for where and when you were born.
We use them for that and nothing else. We don't sell them, we don't advertise, and there are no third-party analytics or advertising SDKs in this app.
Don't know your birth time? Say so. You'll still get a reading — the app will mark it as reduced-confidence, and it will say so before you're ever asked to pay, not after.
You can delete all of it from Settings at any time, without asking us and without giving a reason.
Controller: Infoash UG (haftungsbeschränkt), Germany. → Full details, your rights, and how to complain
Notes binding on the build, not suggestions:
- The reduced-confidence line is here because the terms and the European plan both commit to disclosing precision limits before purchase. If the disclosure only appears on the reading, this notice is inaccurate and the commitment is broken at its only load-bearing moment.
- European R1 stores birth time and consumes it for nothing. The notice must not imply otherwise. Suggested R1 wording: "We'll store it now so you don't have to come back for it — the features that use it arrive in a later update." At R2 this string changes; it is a versioned string, and it changes when the feature ships, not when someone remembers.
⚠ Vedic's geocoding decision is load-bearing here. With an offline dataset, this notice can honestly say the birth place never leaves the app's own infrastructure — a real minimisation claim. With a hosted geocoding API, that is a recipient and it must be named. The notice text is blocked on that architecture decision. Do not write the stronger sentence and then choose the hosted API.
4. N3 — Crystal quiz, consent card
This card carries a double duty: Art. 13 information and an Art. 9(2)(a) explicit-consent request. Explicit consent must be specific, informed, unambiguous, freely given, and as easy to withdraw as to give.
This part is optional, and here's what you'd be sharing
The quiz asks what you're hoping for and how you want to feel. Answers like these can say something about your beliefs, so European law treats them as a special category and we won't use them without your explicit yes.
We store what your answers add up to, not the answers themselves.
You can skip this entirely. Choose your own stone instead and you get the full app — the quiz is a route in, never the only one.
If you change your mind later, we delete what we derived, and we'll show you what that does to your match before you confirm.
[ Yes, use my answers ] [ No thanks — I'll choose myself ]
Controller: Infoash UG (haftungsbeschränkt). → How we handle your data
| Requirement | Source |
|---|---|
| The decline is recorded, not just obeyed once — "never appears again" needs state behind it | Claims gate |
| Both buttons are equally prominent. A greyed-out decline is not freely given consent | Art. 7(4) |
| The self-select path stays whole. It is legally load-bearing — it is what makes Art. 6(1)(b) unavailable and what makes this consent freely given — and may not be weakened for product reasons | Suite standard |
| Withdrawal has a designed consequence. Not a no-op, not silent product destruction | Entitlements |
| Every entrance to the quiz instrument shows this card — the fork, the compare hook, the progressive-profiling card, the Personal Crystal Reading intake, and any re-quiz. Generated from the code paths, not written from memory, with a build-time check that fails the build | Claims gate |
| Journal and mood fields need their own collection surface and their own withdrawal row. They cannot ship as a build default | Claims gate |
| An under-16 user routed out by Art. 8 is never offered the instrument, so the exclusion is enforced at the product screen and not discovered here | Entitlements |
⚠ Open question 1, carried forward. Whether astrology-derived output is Art. 9 data at all is unresolved. If counsel rules that it is, this card's scope widens well beyond the quiz — it would reach the birth-data screen at N2 in both other apps, which today has no consent card and no decline. N2 and N3 cannot both be finalised before that answer. Design the card so N2 can adopt it, rather than assuming it never will.
5. The mandatory content checklist
Art. 13 lists what must be conveyed. Layering is permitted; omission is not.
| Art. 13 item | Where it lives |
|---|---|
| Identity and contact details of the controller | First layer, every card |
| Contact details of the DPO | ⚠ Open — is one required? Art. 37(1)(b) turns on large-scale regular and systematic monitoring; Art. 37(1)(c) on large-scale Art. 9 processing. Three apps processing birth data plus a belief-revealing quiz under one German controller is close enough to the line that "obviously not" is not a safe answer. A counsel question additional to the four in the privacy policy. § 38 BDSG also has its own headcount trigger |
| Purposes and legal basis | First layer, in plain words, per collection |
| Legitimate interests where relied on | Full layer — diagnostics and age-appropriate access |
| Recipients or categories of recipient | Full layer: Supabase, RevenueCat, Apple/Google, Expo. ⚠ Region and transfer mechanism unconfirmed; no project exists yet |
| Third-country transfers and safeguards | Full layer. ⚠ Same |
| Retention period or the criteria for it | First layer at N1 — the material fact is whether the date is kept; full layer elsewhere |
| Rights: access, rectification, erasure, restriction, portability, objection | Full layer, plus the in-app self-serve routes |
| Right to withdraw consent | First layer on N3, because it is a consent card |
| Right to complain to a supervisory authority | Full layer. ⚠ Authority not yet named — depends on the registered seat |
| Whether provision is statutory or contractual, and the consequences of not providing | First layer where a skip exists — the birth-time skip at N2, the decline at N3 |
| Automated decision-making, including profiling, with meaningful information about the logic | Yes, and say it plainly. A weighted rules engine matching a user to a crystal is automated processing. It produces no legal or similarly significant effect, so Art. 22 is not engaged — but Art. 13(2)(f) transparency is cheap here and the honest sentence is a product asset: "A rules engine matches your answers to a stone. It's deterministic — the same answers give the same result — and a person wrote and reviewed everything it can say." |
6. Timing, and the failure mode to design against
- The notice appears before the field is fillable, not on submit and not on a screen the user can scroll past.
- The gate ordering is: age gate → residency question → session. Sibling review rounds found a session being created ahead of the gate in three separate places across two rounds. A session created before the gate means data obtained before the notice, which is an Art. 13 failure and not merely an ordering bug.
⚠ Open question 3, carried forward. Residency is a self-declared country question. Whether self-declaration is adequate for the Art. 8 child-consent provisions is counsel-owed — and if it is not, the residency screen needs its own first layer for whatever stronger signal replaces it.
⚠ Open question 4, carried forward. If DPDP requires verifiable parental consent for under-18s, the India storefront's first screen changes, and the first notice a user sees changes with it. These strings are on that critical path.
Notices are versioned with the app. A string that stops being true when a feature ships — European's birth-time line is the clear case — must have a version, an owner and a release it changes in.
⚠ Translation. Every localised string re-enters the claims gate: a translated claim is a new claim, and a translator is not a compliance reviewer. Whether DPDP obliges Eighth Schedule notice languages at launch is counsel-owed and a real cost item if the answer is yes.
7. Contact
Infoash UG (haftungsbeschränkt) · [registered address] · [privacy contact]
⚠ A named, monitored inbox must exist before any of this is published. A first-layer notice is the most-read legal text in the product — it is the one a user actually sees — and pointing it at an address nobody reads is the worst place in the suite to do it.