At a glance
Overview
- Industry
- Computational Vedic astrology and predictive life guidance
- Domain
- Personalized birth-chart report generation at web scale
- Problem
- Automated astrology platforms delivered template-based predictions that did not vary with individual birth data at sub-period resolution, eroding user trust at scale.
- Solution
- A deterministic three-layer Dasha computation engine calculates the governing planetary period for each of 13 consecutive months per individual, which a structured generation layer converts into jargon-free personalized roadmap reports.
- Scale
- One web application serving unlimited concurrent users, each receiving a unique 13-month forecast derived from their exact birth moment in space and time.
- Result
- Every monthly theme in every report is tied to a computed Pratyantar Dasha planet — architecturally incapable of producing the same forecast for two users with different birth data.
Executive summary
Automated Vedic period computation delivered individualized thirteen-month life roadmaps at scale. The Vimshottari Dasha system can assign a distinct planetary influence to windows as short as one to five months yet nearly every automated platform stops at the Antardasha layer, producing year-level accuracy at best.
We built a system that resolves all the way to the third resolution layer, Pratyantar Dasha, for every individual, every month. The result is a 13-month roadmap where no two rows share the same source if the underlying birth data differs.
Project gallery
Project in pictures
01 · Context
Industry Context
The Vedic astrology personalized report automation market sits inside a broader digital astrology and spiritual wellness industry serving hundreds of millions of users across South and Southeast Asia, with global reach expanding through diaspora communities.
The accuracy requirements are strict: a miscalculation at the Nakshatra boundary level — a matter of minutes of birth time — can shift the entire Dasha sequence, invalidating every downstream period assignment.
The standard approach for decades has been a tiered model: high-value clients receive manual consultations with full three-layer Dasha resolution; everyone else receives a static template applying general planetary symbolism at the year or major-period level.
Digital distribution at scale combined with user expectations shaped by personalisation in every other consumer vertical has made template-based reports no longer competitive.
02 · Challenge
The Problem
Every astrology platform operating at scale confronts the same trade-off: implement full-depth computation and accept the engineering complexity, or simplify to Mahadasha-level resolution and dress it as personalisation.
Most chose simplification — producing an industry where the product promise of a forecast specific to your birth moment is routinely delivered as a themed template.
Users who receive the same Jupiter expansion narrative for a twelve-month window regardless of their birth year lose trust quickly. If you want a forecast accurate at the month level, you must resolve to the Pratyantar layer — there is no workaround.
Language models do not reliably perform Julian Day conversion or Lahiri ayanamsa correction; they hallucinate plausible-sounding astronomical output with no consistent relationship to actual computational results.
03 · Approach
The Solution
The first and most consequential decision was to separate the computation layer from the narrative generation layer entirely.
We rejected the single-pass approach — pass birth data to a language model and ask it to handle both astronomy and writing — because the failure mode is silent: fluent, confident text that does not correspond to the individual's actual Dasha sequence.
The system generates a 13-month roadmap where every row corresponds to a real computed planetary period.
Custom-built components — the geographic resolution engine and the three-layer Dasha resolver — handle district-level location data, historical South Asian timezone rules, and Pratyantar Dasha resolution that off-the-shelf libraries do not support at batch scale.
[Name + Birth Date + Birth Time + Location] → [Geographic & Timezone Normalization] → [Sidereal Lunar Position Calculation] → [Three-Layer Dasha Period Resolution] → [13-Month Theme Mapping] → [Structured Report Generation] → [Personality Profile + Prediction Table + Strategic Advice]
04 · Engineering
Technical Deep Dive
This section explains system design choices, implementation trade-offs, and runtime behavior in a structured format for faster engineering review.
The core technical challenge was ensuring the generation layer could never produce output that contradicted the computation layer.
The architectural principle: compute everything to full resolution, validate the output, then pass a structured payload to the generation layer — never allow the model to infer an intermediate astronomical value.
- 01Technical Node
Birth Input Validation and Geographic Resolution
District-level input resolves to precise geocoordinates via hierarchical lookup; local birth time converts to universal time using location-aware historical timezone rules.
- 02Technical Node
Julian Day Conversion and Sidereal Reference Frame
Validated birth moment converts to Julian Day; Lahiri ayanamsa correction shifts from tropical to sidereal ecliptic coordinates computed for the exact birth date.
- 03Technical Node
Sidereal Lunar Longitude and Nakshatra Assignment
Moon's sidereal longitude at birth determines the entire Dasha sequence via 27 Nakshatra segments of 13.33 degrees each.
- 04Technical Node
Three-Layer Vimshottari Dasha Resolution
Mahadasha, Antardasha, and Pratyantar Dasha all resolved; for each of 13 forecast months the engine evaluates the governing planet at the calendar midpoint.
- 05Technical Node
13-Month Theme Assignment Engine
Each planet maps to a defined life-domain theme; assignments are deterministic lookups from the computed Pratyantar planet — not model-generated categories.
- 06Technical Node
Structured Report Generation Layer
The model receives only the validated period map under strict schema constraints — personality paragraph, 13-row prediction table, and strategic recommendation — with no access to raw birth data.
- 07Technical Node
Asynchronous Processing Architecture
Computation and generation services run independently, communicating through a validated structured payload supporting concurrent users at web scale.
05 · Outcomes
Results
Every monthly theme in every generated report is tied to a computed Pratyantar Dasha planet. The system is architecturally incapable of producing the same 13-month sequence for two users with different birth data.
- Deterministic, reproducible outputsIdentical birth data produces the same period map on any run — quality verification requires checking the computation, not the prose.
- Silent failure eliminatedExplicit failure in geographic resolution means no report rather than a wrong report when birth time or location data is ambiguous.
- Structural differentiation at the month levelTwo users born in the same year with different birth times receive different themes in months where Pratyantar assignments diverge.
- Admin-configurable forecast durationTimeline can shift from 13 months to 6 or multi-year without engineering changes.
- Jargon-free output languageReports are usable by general audiences without consultant mediation — the operational unlock for web-scale delivery.
- Unique report identityEvery report carries a traceable ID and generation timestamp enabling retrieval, audit, and future caching without recomputation.
06 · Process
How We Worked
Delivery roadmap across discovery, engineering, validation, and rollout.
Dasha Resolution Depth Analysis We mapped the three Vimshottari layers and identified where existing automated systems cut resolution short — determining the computation engine must resolve to Pratyantar Dasha for month-level accuracy.
STEP 1: Dasha Resolution Depth Analysis We mapped the three Vimshottari layers and identified where existing automated systems cut resolution short — determining the computation engine must resolve to Pratyantar Dasha for month-level accuracy.
Computation-Generation Separation Decision We rejected the single-pass LLM approach and designed a validated structured payload interface between computation and generation layers before any component was built.
STEP 2: Computation-Generation Separation Decision We rejected the single-pass LLM approach and designed a validated structured payload interface between computation and generation layers before any component was built.
Geographic Layer and Astronomical Engine Build Geographic normalization — historical South Asian timezone rules and district-to-geocoordinate resolution — was built first, followed by the deterministic astronomical engine with no stochastic components.
STEP 3: Geographic Layer and Astronomical Engine Build Geographic normalization — historical South Asian timezone rules and district-to-geocoordinate resolution — was built first, followed by the deterministic astronomical engine with no stochastic components.
Period Map Validation and Generation Schema Testing The period map payload was tested against manually computed Dasha assignments before connecting the generation layer — confirming schema constraints prevent theme assignments that contradict computed planets.
STEP 4: Period Map Validation and Generation Schema Testing The period map payload was tested against manually computed Dasha assignments before connecting the generation layer — confirming schema constraints prevent theme assignments that contradict computed planets.
Report Identity and Admin Configuration Deployment We wired unique report ID and timestamp systems, validated admin configuration for tone and duration settings, and confirmed the three-section output schema across birth configurations before production handoff.
STEP 5: Report Identity and Admin Configuration Deployment We wired unique report ID and timestamp systems, validated admin configuration for tone and duration settings, and confirmed the three-section output schema across birth configurations before production handoff.
07 · Future
What Comes Next
With full Pratyantar Dasha resolution running deterministically per user, the system can extend forecast windows from 13 months to 24, 36, or multi-year through configuration changes only — not a rebuild. Annual summary reports can aggregate period transitions and flag months where multiple layer transitions coincide.
The unique report ID architecture opens a path toward longitudinal tracking — comparing computed period maps against user-reported life events at web scale. That dataset is the input for the next engineering problem: correlation between computed period assignments and user-reported outcomes.