Vedic AI Guru — Privacy, Data Protection & Confidentiality Policy

Version: 2.3.3 · Date: 22 October 2026 · Effective: on the day it is published at vedicaiguru.com/privacy, and each later version on the day it replaces this one

Applies to: vedicaiguru.com and jyotish-almanac.onrender.com (the "Site") and all readings, almanacs and follow-up messages delivered through them (the "Service").

Part I — Privacy Notice (public)

1. Who we are

The data controller for the Service is:

THE AIFIED TECHNOLOGY LLC, a limited liability company registered in New Jersey, United States. Postal address: 9 Ferncliff Terrace, Short Hills, NJ 07078, USA Contact for all privacy matters: privacy@vedicaiguru.com

That is what happened, and this is that reissue. The controller changed when the Service was incorporated, so this notice carries a new version number rather than being amended silently — the commitment this paragraph has always made, now being kept rather than promised. It goes on binding every future change of controller.

The Service is operated from the United States, and since 9 October 2026 it is open to everyone, including people in the European Union and the United Kingdom. Art. 27 of the GDPR and Art. 27 of the UK GDPR require a controller outside those places to name a representative inside each of them. We have not appointed either representative yet. We say so here rather than leave standing the earlier sentence that the Service is not offered in the Union, which stopped being true on the day it opened. Until representatives are appointed, write to privacy@vedicaiguru.com: your rights in §8 are exercised against us directly and do not depend on a representative. When they are appointed, their names and addresses are added here in a new version of this notice (§15). The written assessment behind the earlier position, docs/privacy/art27-assessment.md, was made for a controller in Switzerland; rewriting it for the present controller has been open since 16 September 2026 and waits on counsel.

2. In one paragraph

To produce a reading we need your birth date, time and place, and — if you ask a question — the text of what you are deciding. That text is often intimate: relationships, health, money, faith, career. We treat it as sensitive personal data, process it only with your explicit consent, keep it for the shortest period the Service actually needs, and then either delete it or strip your identity from it. We do not sell, rent or share your data for advertising. We do not use your readings to train AI models unless you separately opt in. You can ask for a copy or deletion of everything we hold about you by emailing us; we will act within 30 days.

If you reserved a reading before the Service opened on 9 October 2026, we kept what you entered — your birth details, your question and your email address — and we will write to you once. §6 says how long a reservation is kept.

3. What we collect, why, and on what legal basis

Your email is required, and we ask for it first. The first reading costs no money, but it is not free of cost to you: the price is your address, and we ask for it before the reading rather than after. We are direct about why. It is how the reading and its link reach you, how the checkpoint note reaches you on the day you chose, and how we recognise you when you return. If you would rather not give an address, we cannot produce the reading — there is no other way for it to reach you.

Where it is kept. Your address is stored in a subscriber record, separate from the record of the reading itself, joined to it only by an internal identifier. We do this deliberately: the text of your question is the sensitive part, and it is not stored next to your name or address.

We do not collect: name — except where you type one yourself: the optional name on the reservation confirmation screen, or a name you put in an email. We never take a name from anywhere else, and neither place that accepts one requires it. Nor do we collect passwords (there are none — when signing in exists, it is a one-time link sent to your address), device identifiers for advertising, precise geolocation of your device, or data from third-party sources.

Automated processing. The reading is produced by software — an astronomical computation engine plus a language model that writes prose strictly from the computed values. No human reads your decision text in the normal course of the Service. The output is interpretive decision-support material; it has no legal or similarly significant effect on you within the meaning of Art. 22 GDPR, and nothing in the Service makes decisions about you.

4. Why we treat this as sensitive data, and what "explicit consent" means here

Under Art. 9 GDPR and Art. 5(c) of the Swiss Federal Act on Data Protection (FADP), data revealing religious or philosophical beliefs, health, sex life or sexual orientation, and the intimate sphere is subject to heightened protection. A request for an astrological reading can itself be taken to reveal a philosophical outlook, and the questions people bring — "should I leave my marriage", "is this diagnosis the end of my career" — routinely contain health, relationship and intimate information.

We therefore do not rely on "necessary for the contract" for this data. Before a reading is generated you are asked to tick a box confirming that you consent to our processing of your birth data and question for the purpose of producing an interpretive reading, that you understand the reading is generated automatically, and that you may withdraw consent at any time. Withdrawal does not affect processing that already happened, but it triggers deletion under §6.

If you do not consent, the Service cannot be provided. There is no alternative version without birth data.

5. Who receives your data (sub-processors)

We do not sell or share personal data for advertising or with data brokers. The following providers process data on our behalf under written data-processing terms:

We will update this table before adding any provider that receives personal data. The current list is also available on request.

The GitHub row was wrong from 07.09 until 29.09, and it is recorded here rather than quietly corrected. It read "No personal data — the trigger only calls our endpoint", which described how we first intended to run the retention sweep and not how it has actually run since the day it was built: the job connects to the database itself. Nothing was disclosed beyond that processor, and the processing itself was the deletion this notice promises. We are not saying more than that: the same correction records that the runner's region and the transfer basis have not been established, and a sentence claiming no exposure at all would rest on the thing we have just said is unread. A recipients table that describes a recipient incorrectly is what this notice exists to get right, so this is recorded as a correction and not as an edit.

Confidentiality of the language-model step. Your decision text is sent to the language model provider to write the reading. Checked against the provider's current commercial terms on 09.09.2026, and the two halves of that sentence do not stand equally. Training: confirmed — the terms state that Anthropic may not train models on customer content from the services. Retention: not confirmed, and we would rather say so — the commercial terms name no retention period, and configurable retention is documented as an enterprise-plan control we do not have. So we do not claim a zero-retention position we cannot evidence. The DPA was read on 10.09.2026 and answers half of this. It commits the provider to delete customer data within thirty days of the agreement ending — a bound at termination, not a limit while the agreement runs, which is the number this paragraph is about. So the gap above stands: nothing states how long your decision text sits there while we remain a customer. This is a gap we looked into, not one we left unexamined, and we would rather publish it than withhold the notice: the published documents state a period only at termination, and that is what we can evidence. Whether a zero-retention option is purchasable at our size is a commercial question we have not put to the provider; answering it would improve this paragraph rather than correct it, and we will say so here when we do. We do not use consumer chat products for client data.

6. How long we keep your data

This schedule was decided before the first permanent store of readings was built, and our storage layer refuses to write a record that has no retention period attached. "Forever" is not a default here.

A pseudonymised reading contains birth date, time and place. We recognise that for some people this combination is rare enough to be re-identifying in principle. We mitigate this by holding no link table back to your email after the 24-month point, by never publishing pseudonymised readings individually, and by giving you the right to full deletion instead (§8) — which we honour even after pseudonymisation if you can supply the reading id or the original email.

7. Payments

When the subscription opens, it will be paid by card through Stripe (§5), on Stripe's own page. Until then no payment is taken.

What Stripe receives is in its row in §5.

What we will keep from Stripe: the identifiers of your Stripe customer record, your subscription and its latest invoice; the subscription's status, the dates of its current period, whether it is set to end at the end of that period, and when access ended after a refund; for each refund, its amount, currency, reason, status and the charge it refunds; and a log of the Stripe events we received, each with its identifier, type and time. We use them to decide whether you have access and for billing and tax, on the basis of our contract with you (Art. 6(1)(b)) and of our legal obligations (Art. 6(1)(c)).

How long: 10 years, as accounting records.

Reserving a place costs nothing and is not a purchase: no card is entered and no payment is taken.

8. Your rights

Under the GDPR, the FADP and — where applicable — US state privacy laws, you can:

• Access — get a copy of everything we hold about you, including the reading and the decision text if still retained;
• Rectify — correct birth data (a corrected reading is issued as a new reading; the old one is deleted on request);
• Erase — have your data deleted, including the pseudonymised reading; payment records (§7) are kept for their period. This is our default answer to any deletion request; we will not argue a legitimate-interest exception against a person who wants their reading gone;
• Restrict or object to processing based on legitimate interest;
• Withdraw consent at any time, with the effect of erasure for consent-based data;
• Portability — receive your birth data and readings in a machine-readable form (JSON) if you want to take them elsewhere;
• Unsubscribe from the checkpoint note in one click; the note is a single message, not a mailing list;
• Complain to a supervisory authority: in Switzerland the Federal Data Protection and Information Commissioner (FDPIC), in the EU your national authority, in the UK the ICO. We would rather hear from you first.

How: email privacy@vedicaiguru.com from the address you used, or quote your reading id. We answer within 30 days (one month under the GDPR; extendable once by two months for complex requests, which we will tell you about). We do not charge for the first request. We may ask for one piece of information to confirm you are the person concerned; we will not ask for identity documents.

Deletion is a tested route. A deletion request is executable by one documented procedure — scripts/delete_subject.py, covering every table that holds a reading — and it is exercised end-to-end on a test record by an automated check that runs with the rest of the test suite (evals/test_delete_subject.py, green on 08.09.2026). It can therefore be honoured within a week even if the founder is unavailable.

9. Why we keep pseudonymised readings at all

Vedic AI Guru's method is built on pre-registered statements, each with the condition under which it would be wrong. That claim is only honest if we can reproduce a reading exactly as it was issued and score it later against what happened. Pseudonymisation is the compromise: the method keeps its evidence, and you stop being identifiable in it. You can opt out of even this by asking for deletion.

10. Where your data is processed and how it is protected

The Service is operated from the United States — that is where the controller is, not where your data sits. The storage locations are listed in §5: the application and the database are in Frankfurt, and mail is sent from Ireland. Since 09.09.2026 the application and the database both run in Frankfurt, so hosting involves no transfer outside the EEA — your birth data, your question and your reading are stored in Germany. Four paths to the United States remain, and we name them rather than imply they are gone. Not a fifth: mail you sent us up to 22.10.2026 is held by Microsoft on a tenant whose region is the EU, read on 16.09.2026 from Microsoft's own public endpoint, which returns tenant_region_scope: "EU" — a source you can check yourself rather than take from us, and the per-service storage location in the admin centre has not been read yet. The reading itself: the prose is written by a model run by Anthropic, PBC in the United States, which receives the computed chart values and the decision text you typed (§5). It is the most personal thing you give us and it is the one we could not keep in the EEA. Email: our provider, Resend, sends from Ireland but stores account data, message metadata and delivery logs in the United States whatever sending region is chosen — so your address, and the checkpoint sentence quoted inside a check-in note, are stored there. We chose that provider knowing it, on 09.09.2026; the alternative was a longer wait, and we would rather say what is true than imply a boundary the setup does not have. Payments: when the subscription opens, Stripe (§5) will receive your email address, an internal account identifier and what you type on its page, and nothing of a reading. Correspondence: since 22.10.2026 our mailboxes are held by Google (§5), on a plan with no setting for where mail is stored, so anything you write to us may be stored in the United States. Apart from those, nothing about a reading leaves the EEA — and note what that does not say: if you quote your own reading or your own question in an email to us, that copy goes where your email goes. We do not send it there; you may. Transfers out of Switzerland and the EEA rely on (a) the EU-US and Swiss-US Data Privacy Framework where the recipient is certified, or (b) the European Commission's Standard Contractual Clauses with the Swiss FDPIC addendum, plus a transfer risk assessment. Copies of the clauses are available on request.

Security measures include: TLS on every connection — the application checks the database connection string when it starts and refuses to run at all if that string permits an unencrypted connection, rather than relying on the database provider to insist; encryption at rest, AES-256, applied by Neon to the stored database and to its backups (checked 09.09.2026 against Neon's published security documentation, which states AES-256 at rest and TLS 1.2/1.3 in transit, and requires SSL/TLS on all connections); the application host has no persistent disk — everything of yours normally lives only in the database, with one exception we would rather write down than leave you to discover: if the database is briefly unreachable, a generated reading can be cached to the application container's own temporary storage, which is wiped on every deploy and restart and is not separately encrypted at rest by us. Those files carry a retention date like every other copy, and the service deletes one the moment it is asked for after that date has passed — it is never served stale. Our scheduled deletion job does not reach them: it runs on a separate machine, which has no access to the hosting container's own temporary storage. Two other things delete them instead — the read described above, which removes an expired file rather than serving it, and the replacement of the container itself, which in practice happens long before any of this matters. Apart from that cached reading, there is no running state in which anything of yours is kept on the container instead of in the database: the deployed service refuses to start at all without a database configured, and the stores holding your address, your birth data and your reading write to files only in that configuration, which cannot be deployed; no shared or personal devices holding client data; access to production limited to the founder and any named engineer under a confidentiality agreement; the retention field enforced by the storage schema; and scheduled deletion jobs, whose failures are recorded — we are honest that a job which stopped running altogether would not raise an alarm of its own today, and building that alarm is open work.

On the usage journal. It records that something happened, never what you wrote. The list of event names is fixed in the code and every field on them is a fixed choice, a yes/no or a small number, so there is no place in it for a sentence — and a test refuses any field the list does not name. It is also walled off from the part of the Service that judges whether a reading was relevant: that must not learn from what people click, because a service optimised for clicks and a service optimised for being right are not the same service.

Breach notification. If a breach is likely to result in a risk to you, we notify the FDPIC and/or the competent EU authority within 72 hours of becoming aware of it, notify affected individuals without undue delay, and — for US residents — follow the notification law of your state.

11. Cookies and tracking

The Site currently sets no advertising or analytics cookies and uses no third-party trackers. Only strictly necessary technical storage (e.g. keeping your form state during the ~70-second generation) is used, which does not require consent. If we add analytics in future, we will use a privacy-preserving tool, update this section first, and ask for consent where the law requires it.

12. Children

The Service is for adults. We do not knowingly accept birth data or questions from anyone under 18 (or under 16 where that is the local age of digital consent). Readings about a minor — e.g. a parent asking about a child's chart — are not offered through the Site; if such data reaches us we delete it.

One more thing we have not finished, said here rather than only in our own notes. Parts of this notice are still written on Swiss law — the legal-basis column in §3 names the FADP, §4 reasons from Art. 5(c) FADP, §8 tells you how to complain to the Swiss FDPIC, and §5's transfer mechanisms for Anthropic and Resend turn on Swiss addenda. All of that was chosen when the controller was a Swiss sole proprietor. The controller is now a company in New Jersey, and we have not yet redone that reading.

What does not change either way: where your data sits (Frankfurt), what we do with it, and your rights under the GDPR — those rest on where the processing happens, not on where we are. What may change is which regulator you complain to and which clauses cover the two transfers to the United States. We would rather publish that than leave you reading a legal basis we have not checked, which is the same choice made about New Jersey below and about our model provider's retention in §5.

13. Information for United States residents

We are a small operator and do not currently meet the revenue or volume thresholds of the California Consumer Privacy Act (CCPA/CPRA) or of the comparable laws of Virginia, Colorado, Connecticut, Texas, Oregon and other states. New Jersey is not in that sentence, and the omission is deliberate — see below. The basis is our own size, which we can state: as at 10 September 2026 the Service has no paying customers and holds data for fewer than ten people — below every threshold those statutes set, by orders of magnitude, so the question does not turn on a close reading of them. No claim in this section covers New Jersey, which is treated on its own below: the controller is registered there, the statute is newer than this paragraph, and we have not done the reading. Reviewed each September, next in September 2027, and sooner if we grow: these thresholds turn on revenue and on how many people's data we hold, so this changes as we grow rather than being something we have yet to find out. New Jersey, and why it is marked unchecked rather than assumed. The New Jersey Data Privacy Act applies on thresholds of its own, and the reasoning above — fewer than ten people, no paying customers, no sale or sharing of personal information — very probably reaches the same answer. Probably is not a finding. The Art. 30 record and the thresholds have to be re-read against New Jersey law now that the controller has moved. That is open since 17 September 2026 and waits on counsel; neither document has moved since. This line is replaced by the answer when it exists. We would rather publish the gap than publish a conclusion we have not done the work for — the same choice made in §5 about the model provider's retention.

We nevertheless apply the substance of those laws voluntarily:

• We do not sell personal information and do not share it for cross-context behavioural advertising. No "Do Not Sell or Share" link is needed because there is nothing to opt out of.
• Sensitive personal information (your question, and birth data used for an interpretive reading) is used only for the purpose you requested; you may limit its use by not providing it, and delete it at any time.
• Notice at collection is given on the form where you enter data, linking here.
• Washington residents: your decision text may include health information within the meaning of the My Health My Data Act. We process it only with your consent, for the reading you asked for, share it only with the language-model provider needed to produce it, and delete it on the schedule in §6.
• Non-discrimination: exercising any right will not change the price or quality of the Service.
• CAN-SPAM: the only email we send unprompted is the single checkpoint note you asked for. It carries a working unsubscribe.

14. The nature of the Service

Readings are symbolic and interpretive material produced by computation and automated writing. The Service is offered for information and entertainment only (founder decision, 08.09.2026). They are decision-support, not medical, legal, financial or psychological advice, and not a substitute for a licensed professional. Nothing in a reading is a prediction of an outcome, a probability, or a recommendation to take or refrain from any medical, legal or financial action; where a decision has consequences of that kind, take it with a qualified person. This framing is the same in the EU and the United States, and it is the reason five subjects — health, death, pregnancy, court cases and investments — are refused outright by the Service rather than answered carefully (§3 of the seven rules; enforced in code, not in tone).

15. Changes

We will post changes here with a new version number and date. Where a change would use existing data for a new purpose or extend retention, we will ask for fresh consent rather than apply the change retroactively — a shorter retention can be applied to old data; a longer one cannot.

2.3.3 — mail. On 22.10.2026 our mailboxes moved from Microsoft to Google. §10 said anything you write to us stays in the EEA; it no longer does, because Google may store it in the United States. §5 adds Google and keeps Microsoft for mail received up to that date, §10 counts correspondence as a fourth path to the United States, and §12 no longer says the mailboxes are in the EU. Nothing else changed.

2.3.2 — payments, ahead of the subscription. §7 said the Service takes none; it still takes none, and §7 now says what Stripe will receive, what we will keep from it, why, and for how long. §5 adds Stripe, §10 counts it as a third path to the United States, and §8 names payment records as kept for their period after an erasure request. Nothing else changed.

2.3.1 — one correction, in §9. It said our method rests on "pre-registered, falsifiable predictions and a published calibration record". The word "predictions" contradicted §14 of this notice, which says nothing in a reading is a prediction of an outcome, and the way we describe the Service; and no calibration record is published. §9 now says "pre-registered statements, each with the condition under which it would be wrong". Nothing about what we collect, why, or for how long has changed, and no new recipient was added.

2.3 — because the Service opened on 9 October 2026. §1 said the Service is not offered to people in the European Union; it now is, to them and to people in the United Kingdom, and §1 says so and says that the Art. 27 representatives required in both places have not been appointed yet. §2 said the Service is not open; it now speaks only to people who reserved before it opened. 2.2 said a representative in an EU/EEA member state would be appointed before the Service was opened to people in the Union; that did not happen — the Service opened on 9 October 2026 without one, and the controller withdrew the commitment that day. Nothing about what we collect has changed, and no new recipient was added.

2.2 — one addition, and it is a path we had not described. The form on the front page is an ordinary HTML form, so a browser with JavaScript switched off submits the question inside a web address, and the address line of a request is written to the host's log. With JavaScript on the question never goes there. The behaviour is unchanged and deliberate — losing a reader's words would be worse than logging them for fourteen days — and §5 and §6 now say so instead of a comment in the page's source claiming the address never carries it. Nothing about what we collect, why, or for how long has changed, and no new recipient was added.

2.1 — one change, and it closes a line 2.0 left open. The §5 row for GitHub Actions said the runner region was not established and that this line would be replaced when it was read. It was read on 02.10.2026, and what it returned is that there is nothing to read: GitHub reports no region for its own runners, offers no setting to choose one on this account, and the features that would allow a choice are not available here. The row now says that, and says that we therefore still do not know whether this is a path outside the EEA — which is a different statement from 2.0's and a weaker one about the provider, not about our checking. Nothing about what we collect, why, or for how long has changed.

2.0 — one change, and it is a correction rather than a new purpose. The §5 row for GitHub Actions said "No personal data — the trigger only calls our endpoint". That has been wrong since 07.09. Three things have happened there and none was a trigger: the daily retention sweep connects to the database itself, so stored data passes through the runner while rows are deleted and pseudonymised; and the waitlist export, when we start it by hand, writes a file of addresses, names, birth details and questions which is held for one day; and, from 08.09 until 30.09.2026, the automated test suite ran on every change we pushed against a clone of the database that carried the same rows — that credential and that clone were deleted on 30.09.2026, which is where this third flow stops. The row now says all three, and says plainly that the runner's region and the transfer basis have not been established rather than naming ones we have not checked. Nothing about what we collect, why, or for how long has changed, and no new recipient was added — this recipient was already receiving data and the table described it wrongly.

1.8 — the compatibility panel is no longer on the site, so §3 no longer describes it. It was the one place you could type another person's name, and that name already stopped being stored in 1.6; removing the panel removes the field as well. Nothing else changed.

1.7 — one change, and it is the sentence you tick. While the Service is not open, the reading consent says what is actually happening: your birth details are kept until the service opens, rather than used to produce a reading now. Both wordings are kept and the form shows whichever is true at the moment you are looking at it, so there is no day on which the box you tick and this notice describe different things. Nothing else moved: the purposes, the retention rows and the recipients are the ones 1.5 and 1.6 set.

1.6 — two changes, and the second is a deletion of data we already held. The two name fields on the compatibility panel are no longer stored, sent to the model, or used to key a cached reading; §3 names the panel as a place whose names are discarded instead of listing it as a place we collect one, so the three places 1.5 named become two. And the store was swept for cached readings written before this version, whose prose could repeat those names, rather than left to expire on their own clock — changing the key makes a row unfindable, not absent, and §3 says never stored. The sweep runs daily from this version on. Nothing else in §3 moved: we still never take a name from anywhere else, and neither place that accepts one requires it.

1.5 — four changes. The controller changed to THE AIFIED TECHNOLOGY LLC. §1 no longer states an Art. 27 representative obligation and then withdraws it two sentences later; it states the assessment's position once. The Microsoft tenant's region is sourced from Microsoft's own public endpoint rather than attributed to a reading in the admin centre that was not made, and it says EU, which is what that source establishes. And a new purpose was added: holding a reservation until the Service opens, with a twelve-month ceiling in §6.

Part II — Confidentiality Commitment (public, for advisory clients)

This applies to bespoke almanacs, business synastry, incorporation-timing work and any engagement beyond the self-service reading.

1. Identity. We do not disclose that you are a client. Client names are not used in marketing, case studies or conversation without written permission.
2. Content. Your charts, questions, business plans, co-founder data and readings are held in confidence and used only to deliver your engagement. Third parties whose birth data you provide (partners, co-founders) are treated with the same confidentiality; you confirm you have the right to share their data with us, and we will delete it on their request as well as yours.
3. Examples and publications. Method examples, calibration statistics and track-record pages use only pseudonymised or aggregated data, or the founder's own chart. If we ever want to use a recognisable element of your case, we ask first, in writing, and you can say no without consequence.
4. AI tools. Engagement material is processed through commercial AI services under no-training terms — the same terms cited in §5, which state that the provider may not train models on customer content from the services, checked 09.09.2026; it is never pasted into consumer chat products.
5. People. Only the founder and any named engineer bound by a written confidentiality agreement have access to engagement material.
6. Duration. These commitments survive the end of the engagement and the deletion of your data.
7. Limits. We may disclose information if the law compels us to, and we will tell you unless legally prevented.