DEV Community: HS SANDESH

How Supastro Is Built: Inside a Computational Vedic Astrology Engine

HS SANDESH — Tue, 18 Aug 2026 06:16:35 +0000

Most people assume an astrology app is a pretty front-end wrapped around a chatbot. Supastro is the opposite. Here is the real architecture - the deterministic core, the fact layer, the reasoning layer, the proof checks, and the agents on top.

I get one question more than any other from engineers who try Supastro: so it's a chatbot with an astrology prompt on top, right? It's a fair guess, because that's what most of the category ships. It's also completely wrong for us, and that gap is the whole reason I'm writing this.

Supastro is a computational system first and a writing system a distant second. The words you read at the end of a report are the last five percent of the work. Underneath sits a stack that behaves less like a content generator and more like a scientific instrument: it measures, it derives, it checks its own answers, and only then does it speak. This is the first entry in a series where I open the hood in public. Today: the whole machine at a glance.

A deterministic astronomy core produces exact numbers. A structured layer turns those numbers into typed facts. A governed reasoning layer turns facts into language. A proof validator rejects anything that contradicts the math. An agentic layer plans and acts on top. Five layers, one direction of travel.

The shape of the system

**
Everything is arranged as a one-way pipeline. Data only moves forward: raw birth details become precise positions, positions become facts, facts become reasoning, reasoning gets validated, and validated output becomes a reading or an action. Each layer is independent and separately testable, which is exactly what lets me rework one without cracking the others.

Layer one: the deterministic core

The foundation is pure mathematics with no intelligence in it at all, and that is deliberate. Given a date, a time, and a place, it computes sidereal positions, the rising sign, the divisional charts, planetary strengths, and the full ladder of planetary periods. The same inputs always produce the same output, to the last decimal, on every run and every machine.

That reproducibility is not a nice-to-have. It is the property that everything above it depends on. Here is the sequence for a single chart:

Normalize the birth moment. Date order, twelve or twenty-four hour time, and time zone are resolved with hard guards against the classic off by a century and midnight mistakes.
Convert to a precise astronomical instant and compute sidereal longitudes for every body.
Derive the rising sign and build the divisional charts on top of it.
Score planetary strength through a multi-part classical model.
Lay out the planetary-period timeline across a lifetime.

Why determinism carries the whole product:
If two runs of the same birth can disagree, nothing above can be trusted. So I test it directly: identical inputs must return a bit-identical chart, and that check runs before any code is allowed to ship.

Layer two: structured facts, not vibes

Raw longitudes are useless to a reader and, honestly, dangerous to a model. So the second layer compiles them into a typed fact sheet: a compact, machine-readable description of the chart. Think of the difference between a pile of sensor readings and a labelled dashboard.

A lot of the real intellectual property lives here, because turning classical rules into deterministic detectors - this combination is present because these precise conditions hold - is slow, careful work. The payoff is that the next layer never has to know astrology. It is handed the facts and asked to explain them.

Layer three: the reasoning layer

Only now does language enter. The reasoning layer takes the fact sheet and produces the synthesis you actually read. Three design choices define it:

A router sits in front of the language models and picks the right one for each job, so the rest of the system never depends on any single provider or model.
A retrieval step pulls the relevant passages from a searchable library of classical texts, so interpretations are grounded in source material instead of being invented on the spot.
Structured output is requested wherever possible, so results can be parsed, validated, and rendered cleanly rather than dumped as a wall of prose.

The reasoning layer is never asked to calculate. It explains what the core already computed. Keeping calculation and explanation on opposite sides of a wall is the single most important decision in the product.
_

Layer four: the proof validator

This is the layer I am proudest of, and the one almost nobody else builds. After the reasoning layer writes something, a validator reads it back and checks every checkable claim against the computed facts. If the text cites a strength value, a period lord, or a house number that does not match the math, the claim is flagged and corrected before it ever reaches you.

"The model is allowed to be eloquent. It is not allowed to be wrong about the numbers."

That inversion - treating generated text as a suspect to be cross-examined rather than an oracle to be trusted - is why the readings hold up when a serious practitioner checks them line by line. It is also why I sleep at night shipping this to real people who are making real decisions.

The agentic layer

On top of the readings sits a set of AI Agents. These are not chat replies. They are goal-driven planners that take a real objective, pull the native's chart and history, reason across timing, and hand back a structured, executable plan. You can feel the difference the moment you use one inside the app.

The agents share memory - your confirmed life events, your recent mood from journalling - can call real tools like live weather for an outdoor date or nearby temples for a remedy, and write every run to a ledger so cost and usage stay transparent. They plan and they act. They do not just chat back.

The design patterns holding it together

For the engineers reading this, here are the patterns I would point to first:

Deterministic first. Anything that can be computed exactly is, and the model is kept well away from it.
One-way data flow. Five independent layers, each testable in isolation, each replaceable on its own.
A single choke point on the way out that strips internal detail from every response, so the browser only ever receives the reading itself.
Aggressive caching of the expensive-but-stable pieces, like charts and positions, so cost stays flat as usage climbs.
Quality gates in the pipeline. A battery of accuracy suites runs before anything ships, and a single red result blocks the release outright.

"Every one of these choices trades a little short-term convenience for long-term trust. That trade is the brand."'

Why I built it this way

Because I wanted a product that could survive scrutiny. Anyone can put a pretty front-end over a prompt in a weekend. Very few can hand a reading to a sceptic and watch it hold. Reproducibility, grounding, and validation are what make that possible, and they happen to be the same properties that make a system worth citing rather than dismissing.

In the next post I go one level deeper into layer one: how a deterministic astrology engine actually works, and why deterministic is doing so much heavy lifting in that sentence. The rest of the series lives under Founder Notes.

The Architecture Behind a Deterministic Vedic Astrology & AI System

HS SANDESH — Mon, 10 Aug 2026 08:18:11 +0000

Why Most AI Astrology Is Still Just Text Generation

There is a strange contradiction in the current AI astrology market.

Astrology apps are becoming increasingly sophisticated at generating language. They can hold conversations, explain planetary placements, produce compatibility readings, write long reports and answer questions in seconds.

But generating a convincing explanation of astrology and actually building a computational system around astrology are two very different things.

An AI model can write an impressive paragraph about Jupiter.
That does not mean it calculated Jupiter correctly.

It can discuss a Mahadasha.
That does not mean it determined the correct planetary period.

It can produce a sophisticated-sounding prediction.
That does not mean the prediction is grounded in the complete computational state of the horoscope.

This distinction is the reason Supastro was built differently.

AI is not the astrology engine

Supastro's core architectural decision is simple:

The AI does not calculate the horoscope.

The astrology layer calculates it.

The AI interprets it.

That sounds like a small distinction. It isn't.

The production codebase contains a dedicated deterministic astrology engine of approximately 40,000 lines across 92 modules. Its responsibilities include birth-instant normalization, divisional-chart mathematics, planetary-strength models, yoga and dosha detection, Dasha timelines, birth-time rectification and specialized astrological calculations.

These computations are designed to be reproducible and independent of the AI layer.

The result is a fundamentally different architecture:

Birth data → deterministic Jyotisha computation → structured astrological evidence → AI reasoning → validated interpretation

rather than:

Birth data → language model → astrology-flavored answer

The language model is therefore the final reasoning and communication layer, not the underlying source of astrological truth.

The problem with treating astrology as text

A horoscope is not a paragraph.

It is a system of interacting variables.

A planetary placement exists within a sign, house, lordship structure, Nakshatra, strength profile, aspect network and timing system. Its relevance can also change depending on divisional charts and the period in which it is being evaluated.

That means a meaningful astrological question often cannot be answered responsibly by looking at one factor in isolation.

Consider a question about career.

A simplistic system might identify the tenth house and its lord, then generate a paragraph.

A computational system can evaluate a much larger evidence surface:

natal chart structure
relevant divisional charts
planetary strength
house emphasis
lordship
Nakshatras
Yogas
Ashtakavarga
planetary aspects
Mahadasha and Antardasha
long-range transits
retrogression
other derived markers

The point is not that every answer should mention every factor.

The point is that the system can consider the relevant evidence before deciding what matters.

That is a fundamentally different problem from text generation.

From isolated factors to interacting evidence

One of the architectural ideas behind Supastro is that astrological signals should not exist as disconnected facts.

A planet is not simply "in a house."

Its significance can depend on several layers of context.

Conceptually:

Planet → Sign → House → Lordship → Nakshatra → Strength → Aspects → Derived patterns → Timing → Divisional relevance

Each layer adds information.

The intelligence problem therefore becomes:

Which signals matter for this question, how strongly do they matter, what supports them, what contradicts them, and when do they become relevant?

That is much closer to a reasoning problem than a text-generation problem.

Astrology is also a temporal system

A birth chart describes a structure.

Prediction introduces time.

This is why Supastro treats Dashas and transits as computational systems rather than simply topics for an AI model to discuss.

The astrology engine includes planetary-period timeline computation and timing-oriented analysis.

This creates a second dimension to chart interpretation:

What is indicated?

and:

When is it activated?

A useful AI astrology system therefore needs to reason across both the static chart and changing temporal state.

That distinction becomes particularly important for questions such as:

When is a career transition more likely?
Which period deserves attention?
When does a relationship signature become activated?
Which upcoming transit reinforces or contradicts a natal indication?
Is a difficult period actually active now, or merely present as a latent chart signature?

The architecture needs computation before interpretation in order to answer those questions coherently.

The AI is given evidence, not asked to invent it

Supastro's AI layer sits above the deterministic computation system.

The application contains an internal model-routing layer, a structured prompt system and a chat pipeline that assembles chart facts with user memory and retrieval context.

The purpose is not to make the model "become an astrologer."

The purpose is to give the model a structured astrological state that it can reason over.

This distinction also makes the AI layer replaceable.

As language models improve, the computational astrology layer does not need to be rebuilt.

The same chart evidence can be interpreted by different models, workflows or reasoning strategies.

The astrology engine remains the underlying source of truth.

Multiple reasoning passes instead of one-shot generation

Supastro's architecture also experiments with agentic workflows rather than treating every question as a single model completion.

The application exposes multiple analysis workflows, including parallel agent passes, deeper research modes and adversarial review patterns.

The conceptual purpose is simple:

Don't let one interpretation become the answer simply because it was generated first.

Different analytical passes can examine different aspects of the chart and then contribute to synthesis.

The system's own interface describes this as multiple expert perspectives, with parallel passes cross-checking major signatures and weighing timing and strength alongside houses.

That matters because complex astrological questions often contain competing signals.

One factor may support an outcome.

Another may weaken it.

A timing factor may activate one signature while another remains dormant.

The interesting problem is therefore not finding one astrological factor.

It is resolving the interaction between them.

The AI is not allowed to rewrite the computed chart

This is where Supastro goes beyond simply using an astrology API.

The system contains a proof and accuracy validation layer that checks generated AI output against computed astrological values.

For example, if an AI response cites an incorrect planetary strength or an incorrect current period, the validation layer can flag the discrepancy.

This creates an additional stage after generation:

Compute → Interpret → Validate → Respond

The principle is deliberately conservative:

The AI can interpret the chart. It cannot rewrite the chart.

That distinction is important because fluent language can hide factual errors.

An answer can sound authoritative and still be inconsistent with the underlying calculation.

Supastro treats computational consistency as a separate engineering problem.

Reproducibility matters

The deterministic astrology layer is explicitly tested for reproducibility.

The same input is expected to produce bit-identical computational output.

This is important because AI-generated language is inherently probabilistic.

If the underlying chart itself changed because an AI model changed, debugging would become almost impossible.

Instead, Supastro separates the two.

The computational state should remain reproducible.

The language used to explain that state can evolve.

That makes it possible to improve prompts, models and reasoning workflows without silently changing the underlying horoscope.

Accuracy is treated as a software problem

The codebase includes automated accuracy suites covering areas such as birth calculations, Dashas, proof validation, golden charts, planetary strength, Yogas, specialized calculations, report enrichment, chat quality, prediction capture and birth-time rectification.

These checks are integrated into the development workflow and can block a push when a required accuracy check fails.

This is a different mindset from evaluating an astrology product purely through subjective user satisfaction.

A beautiful interface is useful.

A fluent answer is useful.

But neither can compensate for a broken calculation.

The system therefore treats astrology accuracy as something that can be tested, versioned and regression-checked like other computational software.

The architecture is designed around evidence

This leads to a broader idea behind Supastro.

The future of AI astrology should not simply be:

better prompts + better models + more content.

It should be:

better computation + better evidence + better reasoning.

The AI becomes the interface through which a person can interrogate a much deeper computational model.

Instead of asking a model to guess what an astrologer might say, the system can first establish what the chart actually contains, identify the relevant evidence, evaluate timing and relationships between factors, and then use AI to explain the resulting interpretation in human language.

That is the direction in which Supastro is being built.

From AI astrologer to Vedic decision intelligence

The larger opportunity goes beyond generating horoscope reports.

Once Vedic astrology is represented as structured computational evidence, it becomes possible to build higher-level reasoning systems on top of it.

A future decision-intelligence layer could ask:

What evidence supports this conclusion?
What evidence contradicts it?
How strong is the signal?
When is it activated?
Which astrological systems independently support the same conclusion?
What changes if the birth time is uncertain?
What is the confidence of the interpretation?

These are fundamentally different questions from "What does my horoscope say?"

They move astrology from a static reading toward an interactive reasoning system.

The philosophy behind Supastro

The core idea can be summarized in one line:

Computation first. Intelligence second.

The deterministic layer establishes the astrological state.
The reasoning layer examines that state.
The validation layer checks the resulting claims.

The AI layer turns the final interpretation into something a human can understand and interact with.

That architecture does not guarantee that every prediction will be correct. Astrology itself remains an interpretive discipline, and no software architecture can turn interpretation into mathematical certainty.

But it can establish a much stronger engineering foundation for AI-assisted Jyotisha.

And that is the problem Supastro is trying to solve.
Not how to make an AI sound like an astrologer.

How to build an intelligence system that can actually reason over a computed Vedic horoscope.

Supastro thus has now become a Native AI App.