Three Ways an AI Reads Your Chart. You Cannot Tell Them Apart.

I compute birth charts in deterministic code and use a language model only to narrate the result.

That split costs real engineering time, so it's fair to ask whether it's necessary. Today, any general AI assistant will happily read your birth chart if you ask it to.

So why did I build VyomaVeda?

Because I don't want an AI that simply sounds like an astrologer. I want an AI whose conclusions are anchored to the actual chart.

A language model is excellent at producing plausible interpretations. It knows how astrologers talk. It knows the common patterns and ideas from thousands of articles and discussions.

But it does not compute your chart.

That means it cannot know whether what it's saying is actually supported by your planetary placements. The result is often an interpretation that sounds insightful even when it isn't grounded in the chart at all.

So the engine computes every planetary position, house, divisional chart and timing period first. Only after the chart exists does the language model explain what those placements mean.

The AI doesn't decide what is true. It explains what the engine has already established to be true.

Last week I tested whether that extra engineering was actually necessary.

I gave a general assistant a birth date, time and city and asked what the chart said, then checked every claim against my engine, which computes from a Swiss ephemeris.

The same assistant, on the same day, given the same kind of request, did three incompatible things.

Mode one: it computes, and it is right

It returned an ascendant, a Sun sign and a current planetary period. All three were correct. The planetary period was correct to the day.

None of them were calculated.

The Sun sign is given by the birth date. Late February is Aquarius in the sidereal zodiac most years, which is a lookup rather than a computation.

The ascendant was reachable by rule. The birth was late morning, which puts the Sun near the top of the chart, around the 10th house. If the Sun is in Aquarius and Aquarius is the 10th, then the 1st is Taurus. That works on paper.

The planetary period was not derived at all. The assistant said so itself: "From our earlier conversations, this aligns with the Rahu Mahadasha timing you've mentioned." It came from something the person had told it in a previous chat. Once you have that one date, naming the period before it is reading a fixed sequence backwards.

Three correct facts, all of them either given by the date, reachable by rule, or handed back from the user's own words.

Mode two: it computes, and it is wrong

The same reading placed the Moon in Taurus, called it exalted, and built a section on it. Emotional intelligence, nurturing, strong intuition, capacity to understand people. One of the strongest features of the chart, it said.

The Moon is in Leo.

Different sign, different house, different nakshatra, and not exalted. A passage of character analysis resting on a placement that isn't in that chart.

The Moon was the one fact in the list that needed an ephemeris.

The route it took is worth following. The ascendant is Taurus, and the Moon is exalted in Taurus. It took a sign it already had, attached it to a different planet, then applied the exaltation rule correctly to the wrong input. The rule was applied perfectly. The input was invented.

To check whether that was bad luck I ran three more charts across three leading models, prose allowed, nothing constrained. Six facts each: ascendant, moon sign, birth star, sun sign, major period, sub period.

Across those three charts the models produced one correct fact between them. A sun sign. Everything else was wrong or never attempted. The sub period was not correct on any chart, in any run, by any model.

I also ran the first chart four times with an identical prompt. Three runs gave a correct birth star and major period. The fourth gave a different birth star and a different major period.

Consistent errors can be corrected. Non determinism can't be tested away, which makes it the worse of the two for anything you intend to ship.

Mode three: it declines to compute, and reads you anyway

Given a third chart, the same assistant refused to produce placements, and was clear about why:

"Since I'm not running an astronomical ephemeris here, treat the planetary positions as an interpretive reading based on the supplied birth data rather than an exact computed horoscope."

It went further, declining divisional charts because those need exact degrees, and closing with a note that it would not make claims about yogas, periods or marriage timing without a computed chart.

Every one of those statements is correct and responsible.

It then delivered a thousand words of character analysis. Nature, personality, career, wealth, relationships, family, strengths, challenges, spiritual disposition, later life. Confident, structured, and specific about the person.

None of it traces to anything computed. There was nothing to trace to, and the model had just said so.

It is also not neutral. I ran that chart. It has four planets in the first house, including an exalted Venus alongside the Moon, which is about as relationally forward and emotionally visible a first house as the system produces.

The reading described someone not emotionally demonstrative, who defines himself through competence and control rather than expression, who is difficult to know deeply, and whose partner may experience him as distant.

The interpretation is arguable. What is not arguable is whether it came from the chart, because the model had already told you it had no chart.

Where the caution gets spent

The model withheld the nakshatra because that needs exact degrees. It did not withhold the conclusion that the man struggles with vulnerability and his partner finds him emotionally unavailable.

Restraint was applied to every claim that could be checked and dropped for every claim that could not.

That is rational behaviour. A wrong nakshatra is falsifiable and embarrassing. A wrong character verdict is neither. The effect is that the caution protects the model rather than the reader, and none of it is visible on the page.

This is an architecture problem, not a prompting one

Three modes, one model, one day. Correct by rule, wrong by invention, and a character verdict standing in for a calculation. They arrive in the same register, with the same structure and the same warmth.

Prompting cannot reach this. In mode three the model behaved well. It disclosed its limits accurately and declined the checkable claims. The reading was still unmoored, because nothing in the system knew what the chart was.

Without deterministic computation there is nothing for the model to be right or wrong about, and the space fills with something unfalsifiable instead.

Correct facts are necessary and not sufficient

The engine isn't the finish line, and I underestimated that for a long time.

I have seen a version of the same failure inside my own pipeline. The payload stated that a planet was exalted, and the model wrote that it was not, explaining that the data carried no exaltation flag for it. A few turns later it described the same planet as exalted.

The correct fact was in front of it the whole time. It audited the fact instead of reading it.

That behaviour is not the failure most people guard against. It isn't the model inventing something it was never given. It is the model second guessing something it was given. Instructions that push hard against fabrication can produce it: tell a model firmly enough never to state anything the data does not support, and it starts interrogating its own source rather than reading it.

So you compute the facts, you narrow what the model can see to exactly those facts, you tell it plainly that the payload is a source and never a subject, and you still check the output in code before it reaches anyone.

The honest part

• The models are not stupid. On rule application over facts already on the table they were excellent and consistently so. The failure is narrow and specific and worth describing precisely rather than exaggerating.
• My first experiment was unfair and I threw it out. I originally demanded structured output with no prose, which suppresses the step by step working these models need. The corrected version is the one above.
• My second conclusion was also wrong. One chart made the models look far better than they are. Three more showed that chart was unusually easy, for the reason in mode one. Publishing after the first would have meant a reader testing their own chart and finding otherwise.
• Sample sizes are small. Four charts, three models, a handful of runs each. Enough to show the three modes exist and where the boundary sits. Not enough to put a rate on how often each appears.
• Tools change this. A model with a real ephemeris available would do far better on exactly the facts it failed. That tool is what an engine is. The argument is not that models cannot get there, it is that the calculation has to come from somewhere deterministic.
• This will age. Models improve and these results have a shelf life. The architectural point doesn't, because it's about which component owns the truth.

What the engine buys

An engine is unglamorous. Ephemeris code, divisional maths, period boundaries, a regression suite. None of it writes a sentence anybody reads.

It is the difference between a reading about your chart and a reading about no chart at all, and on the page those look identical.

Compute the facts. Narrow what the model sees to exactly those facts. Check the output in code. Then let the model do the part it is genuinely extraordinary at, which is turning a correct structure into language a person can use.