Most AI astrology products put a language model in front of the user and let it talk. That works until someone asks "when will my job change?" and the model answers with a month it made up, a planetary position that is not in the chart, and a remedy that happens to be for sale.
We built AI Jyotish for SugamPuja with one rule: the model is not allowed to know anything the engine did not compute.
Two layers, one job each
| Layer | What it does | Why |
|---|---|---|
| Jyotish engine (TypeScript) | Computes the chart, 3-level Vimshottari dasha, divisional charts, ashtakavarga, dosh checks and the remedy table | Maths has to be exact and repeatable. A model is neither |
| Claude Opus 5.5 | Reads the computed facts for the question asked and writes the answer in Hindi or English | Reasoning across many factors and explaining it plainly is what the model is good at |
| Guardrails | Hard refusals and banned certainty words, enforced in the prompt and checked in evaluation | Some questions should never be answered, however they are phrased |
The model receives chart facts and topic facts as data, plus a trimmed conversation history. It cannot see a planetary longitude the engine did not hand it, so it has nothing to invent from.
Testing the maths separately from the AI
Before trusting a single answer, we tested the engine on its own:
- Own suite: 28 of 28 tests pass.
- Independent cross-check: 200 random charts from 1950 to 2025, across 12 places including daylight-saving cities, compared against a separate astronomy library that shares no code with our ephemeris. 4,200 checks, 0 failures. The worst gap was 42 arc-seconds on a planet and under one day on a dasha boundary.
- Published charts: well-known public birth charts reproduce the documented lagna, nakshatra and dasha periods.
Evaluating the answers
A harness replays the production chat path: 68 answers across 5 charts, covering career, marriage, money, multi-turn follow-ups, unknown birth times and edge cases.
| Check | Result |
|---|---|
| Dates in answers vs computed windows | 0 invented |
| Remedies (mantra, daan, conduct) | 0 invented; every line traced to the engine's remedy table |
| Same question in a fresh thread | 3 of 3 gave identical windows |
| Unknown birth time | Says so every time and reads from the Moon chart instead |
| Guardrail prompts (health, death, gambling, court cases, guarantees, prompt injection and more) | 9 of 9 refused |
The finding that mattered most was our own bug
The evaluation's sharpest result was not about the model. Our dosh rules were too broad: run across 5,000 random charts, 95.7% of people were told they had at least one dosh, and 80.5% a Mangal dosh. Every marriage answer could then point to a puja.
That is exactly the fear-driven pattern users complain about in this category, and it was coming from our code, not from Claude. We moved Mangal dosh to the lagna as the primary check with the Moon as secondary, added the classical cancellations, and narrowed Pitru dosh to its standard conditions. A cancelled dosh no longer triggers any puja suggestion. Gemstones are now advised only for a planet that is benefic for that chart.
| Before | After | |
|---|---|---|
| Mangal dosh flagged (5,000 charts) | 80.5% | 27.5% |
| Pitru dosh flagged | 53.7% | 29.2% |
| Evaluated answers naming a puja | 16 | 8 |
Cost and speed
Each answer averages about ₹4.4 with a cold prompt cache. We later moved the cache marker to the newest message, so repeated tool rounds inside one answer stop re-paying for the whole thread, and switched the answer to streaming so users see text as it is written instead of waiting on a spinner.
What we would tell a client
The model was never the hard part. The hard part was deciding what the model is allowed to know, building the layer that computes it, and running an evaluation honest enough to catch your own mistakes before users do. That is the same pattern we use for any business assistant: facts from your systems, reasoning from Claude, and a test set that runs before every release.