Work

Private, chart-first Jyotish software.

Vedic AI is a live Android application for exploring traditional Jyotish through personal birth charts and questions. People can create a birth profile, generate a Kundali, and explore subjects such as career, relationships, and timing.

I started the project because there was a gap between the information in a calculated chart and how software explains it to an ordinary person.

A chart may contain planetary positions, house relationships, divisional charts, Dashas, and other interacting conditions. Producing a clear answer from those things is a separate problem. A language model can write a convincing interpretation even when it hasn't checked the underlying facts.

So I've been working to keep calculation, traditional-source retrieval, evaluation, and the final explanation as distinguishable responsibilities.

1. Calculate, rather than invent.

   Birth data is used to compute the relevant chart information. Planetary positions, Lagna, Dashas, and divisional charts belong to calculation tools, not to a language model's imagination.

2. Retrieve knowledge with conditions.

   Traditional Jyotish rules often have prerequisites and exceptions. I've worked on source-linked, structured records that describe when a rule applies and what else must be checked.

3. Consider competing indications.

   One chart factor rarely tells the full story. A useful system needs to consider modifiers, supporting conditions, and evidence that weakens an interpretation instead of turning one retrieved rule into a confident prediction.

4. Explain with appropriate limits.

   The model's job is to communicate the assembled material clearly. Computation and source checks can improve consistency within a Jyotish framework; they do not establish scientific proof of astrological predictions.

Separating these jobs also makes it easier to test individual failures instead of treating every bad answer as a prompt problem.

An agent that requests the information a particular question needs.

Different questions shouldn't trigger an identical sequence of tool calls. A career-timing question may need different calculations from a relationship question. Drishti is designed to select relevant tools, retrieve classical material, and connect the findings across a conversation.

That creates engineering tradeoffs: what to calculate, what to reuse, how much context to carry, when another retrieval is worthwhile, and when the agent should stop searching and answer.

One problem I worked through was the context growth caused by chart information repeated through nested tool responses. We narrowed the model-facing evidence and kept the fuller details separately for inspection.

The product challenges matter just as much: useful first answers, natural follow-up questions, predictable credit usage, and returning to the same conversation after access changes. Some of those are still active product work, not features I'm claiming have all shipped.

Read the technical account →

A lot of the work is turning text written for human interpretation into knowledge that software can apply and test. A passage can have a rule, a condition, an exception, a dependency, and a source context that shouldn't disappear when it's placed into a search index.

I've worked with structured Jyotish rule records, source references, calculation requirements, and evaluation cases. The essential distinction is that finding a passage isn't enough: the system also has to determine whether the passage is relevant to the computed chart.

I'm interested in this as a broader AI systems problem: how can a domain-specific application use governed evidence instead of presenting plausible retrieved text as authority?