Published April 2026 · Last verified April 2026
AstroRattan.
A production Vedic-astrology platform. Birth-chart generation, 16+ divisional charts, AI-powered io-gita semantic analysis, and a full consultation marketplace.
Divisional charts
16+
From D1 to D108
[ A ] · The problem
Vedic astrology software is either a calculator or a storyteller. Never both.
On one side you have ephemeris calculators - accurate planetary positions, house cusps, and divisional chart tables. They are mathematically correct and spiritually empty. The user receives a grid of numbers and is expected to know what a debilitated Venus in D10 means for their career.
On the other side you have astrology apps that generate daily horoscopes and personality readings. They are engaging and computationally hollow - the same paragraph is served to millions of people born under the same Sun sign, with no reference to the actual chart.
AstroRattan was built to bridge the gap. Every interpretation traces back to a computed planetary position from Swiss Ephemeris. The D60 Shashtiamsa for past-life karma, the D9 Navamsa for marriage, the D10 Dasamsa for career - each is a mathematical transformation of the birth longitude. The io-gita engine then maps these nine planetary forces onto sixteen Sanatan atoms to identify the seeker's attractor basin. No generic copy. No guesswork.
[ B ] · The argument
The chart is the ground truth. The interpretation is topology over geometry.
Every interpretation in AstroRattan is anchored to a deterministic astronomical computation. The same birth date, time, latitude and longitude always produce identical planetary positions. The same longitudes always produce identical divisional chart placements. The same placements always feed the same io-gita atom vector. There is no temperature parameter, no sampling variance, no hallucination. The geometry is fixed; the topology - the meaning layered on top - is inspectable, testable, and versioned.
[ C ] · Architecture
Two surfaces. Eight layers. One ephemeris.
Each layer is a contract - defined, versioned, tested. The ephemeris layer knows nothing about the frontend. The frontend knows nothing about pyswisseph. The io-gita engine only needs planet positions and a Dasha lord.
Ephemeris core
Swiss Ephemeris · pyswisseph · sidereal longitudes · house cusps · ayanamsa
Chart engines
D1–D108 varga calculators · Dasha systems · Gochara transit · Shadbala · Ashtakvarga
Interpretation layer
Lal Kitab · Yoga rules · Dosha analysis · KP · Numerology · Vastu · Palmistry
io-gita layer
16 Sanatan atoms × 9 planets · 8 attractor basins · semantic gravity · escape analysis
API surface
FastAPI 0.135 · Pydantic V2 · 255+ endpoints · 20 routers · JWT auth · rate limiting
Database
PostgreSQL · 22 tables · threaded pool (2–30) · pgcrypto · dead-connection self-heal
Control surface
React 19 · Vite · Tailwind · shadcn/ui · GSAP · Three.js cosmic background
Test harness
pytest · Playwright · 1,850+ tests · 71 test files · engine contract validation
[ D ] · The numbers
Backend LOC
103K+
Python · 149 engine modules
Frontend LOC
78K+
React 19 · TypeScript · Vite
API endpoints
255+
FastAPI · 20 router modules
Divisional charts
17
D1 through D108
Test functions
1,850+
pytest · Playwright E2E
Database tables
22
PostgreSQL · pgcrypto
[ E ] · The charts
Seventeen lenses. One birth moment.
Each divisional chart is a different resolution at which to inspect the same birth data. D1 is the wide shot. D60 is the electron microscope. The astrologer selects the lens based on the question.
C/01
Rashi (D1) - The root chart
Twelve signs, nine planets, twelve houses. The birth snapshot. Every other divisional chart is a mathematical transformation of the longitudes computed here. D1 shows body, health, and the material stage.
C/02
Navamsa (D9) - Marriage and dharma
Each sign divided into nine parts (3° 20′ each). The fortune of a planet in D9 can override its weakness in D1. D9 is the second most important chart after Rashi for assessing marital harmony and spiritual path.
C/03
Dasamsa (D10) - Career and authority
Ten divisions per sign (3° each). Shows professional rise, fall, public reputation, and government or institutional standing. A debilitated planet in D1 may excel in D10 if its Dasamsa placement is strong.
C/04
Shashtiamsa (D60) - Past-life karma
Sixty divisions per sign - each 0.5°. The finest sieve. Named divisions (Ghora, Deva, Amrita…) carry benefic, malefic, or mixed nature. D60 is extremely sensitive: a 30-second birth-time error can shift a planet to a different division entirely.
[ F ] · Operations
What the operator actually touches.
The astrology is automatic. The human work is interpretation, remedy guidance, and client relationship - supported by computed data that arrives in seconds.
O/01
Kundli generation
User enters birth date, time, and place. The backend queries Swiss Ephemeris for sidereal longitudes, computes all 16+ divisional charts, calculates Dasha timelines, and assembles a comprehensive report with planetary dignities, aspect patterns, and house significations.
O/02
io-gita analysis
Planet positions and the current Mahadasha lord feed into the 16-atom vector builder. The engine normalizes atom activations, identifies the dominant attractor basin, and generates a unified insight that bridges Vedic dignity rules with topological attractor dynamics.
O/03
Lal Kitab reading
A separate Urdu-astrology system with unique house significations, planetary friendships, and debt (Karz) analysis. The engine matches chart patterns to remedy prescriptions, tracks them through a 43-day check-in schema, and correlates results with palmistry markers.
O/04
Consultation booking
Users browse astrologer profiles, view per-minute rates, and book chat or scheduled sessions. A wallet system tracks recharge and spend. Astrologers manage client lists, notes per chart, and session history through a dedicated dashboard.
[ G ] · Under the hood
What's actually in the source files.
Every layer below traces back to a real source path, a real dependency version, or a real test count. No aspirational names. What isn't built yet sits in the Roadmap section.
S/01
Ephemeris Core
pyswisseph 2.10.3.2 · Swiss Ephemeris
Astronomical computation engine
Computes sidereal planetary longitudes, house cusps, ayanamsa (Lahiri default), and ephemeris data for any date between 3000 BCE and 3000 CE. Drives charts - D1 through D108 - from a single set of geocentric coordinates.
Engineering twist
All calculations are deterministic: the same birth date, time, latitude and longitude always produce identical planetary positions. No stochastic layers, no generative guesswork - the chart is a geometric fact.
S/02
Chart Engines
divisional_charts.py + 40+ engine modules
Varga calculator suite
Supports all 16 standard divisional charts (D1–D60) plus D108 Ashtottaramsha. Each varga applies a distinct mathematical partition - D2 Hora (2 parts), D3 Drekkana (3 parts), D9 Navamsa (9 parts), D60 Shashtiamsa (60 parts at 0.5° each). Includes D60 Sanskrit name lookup, karmic debt detection, and birth-time sensitivity warnings.
Engineering twist
D60 includes 60 named divisions (Ghora, Deva, Kubera, Amrita…) with per-planet past-life interpretations and remedy-accessibility scoring. A 30-second birth-time error can shift a planet into a different D60 division - the engine surfaces this uncertainty explicitly.
S/03
Interpretation Layer
Lal Kitab · Transit · Yoga · KP · Numerology · Vastu
Multi-system reading engines
Lal Kitab engine (1,150+ LOC) with 43-day remedy tracker, debt analysis, and palmistry correlation. Transit engine (10,130+ LOC) with 108 variant interpretations per planet-sign-house combination. KP engine with cusp/sub-lord logic. Numerology engine with Loshu grid, pinnacles, and forecast cycles. Vastu engine with YOLOv8 floor-plan object detection.
Engineering twist
Transit variants are not generic templates - they are structured per planet, sign, and house with Hindi-English bilingual output. The Lal Kitab system links chart debts to concrete remedies (feed crows, donate oil) and tracks completion via a 43-day check-in schema in PostgreSQL.
S/04
io-gita Engine
astro_iogita_engine.py · D=10,000 · seed=42
Semantic gravity attractor analysis
Maps 9 Vedic planets onto 16 Sanatan atoms (DHARMA, SATYA, TYAGA, AHANKAR, ATMA, MOKSHA, KULA, RAJYA, NYAYA, KRODHA, NITI, SHAKTI, BHAKTI, KAAM, LOBH, MOH) using the same high-dimensional bipolar vector space as the standalone io-gita engine. Builds a 16-element activation vector, identifies the dominant attractor basin, and estimates escape trajectory.
Engineering twist
Eight attractor basins are defined (Dharma-Yukta, Moksha-Marga, Shakti-Krodha, Kama-Moha, Bhakti-Kula, Rajya-Niti, Ahankar-Trap, Nyaya-Satya) with escape triggers and warnings. The engine combines normal astrology dignity scoring with io-gita topology - not two separate reports, one unified gravitational field.
S/05
Auth & Security
PyJWT + passlib[bcrypt] + slowapi
Identity and rate-limiting layer
JWT access tokens with versioned revocation (token_version in users table). Bcrypt password hashing. Slowapi rate limiting keyed by client IP with configurable per-minute limits. Security headers middleware adds X-Content-Type-Options, X-Frame-Options, HSTS, and Referrer-Policy on every response.
Engineering twist
Token versioning means a single database column invalidates all existing tokens for a user without touching a session store. Refresh-token rotation is enforced on use. Rate limits are applied before route handlers run, so expensive astrology engines never execute under brute-force load.
S/06
Backend API
FastAPI 0.135.1 · Pydantic V2 · 255+ endpoints
Schema-validated control plane
FastAPI on Python 3.11 with Pydantic V2 contracts. 20 router modules cover auth, kundli, panchang, KP/Lal Kitab, numerology, mundane, clients, admin, analytics, feedback, muhurat, horoscope, vastu, yoga search, astro map, dasha, interpretations, remedies, and astrologer dashboards.
Engineering twist
The kundli router alone exposes 76 endpoints - chart generation, divisional chart exports, matching (Ashtakoota), Dasha timelines, transit reports, and PDF download tokens. Download tokens are short-lived PostgreSQL rows (not JWT-in-URL) - an audit-hardening pattern that prevents credential leakage in server logs.
S/07
Database
PostgreSQL + psycopg2-binary threaded pool
Persistent storage layer
22 tables including users (with role-based access), clients, kundlis, horoscopes, panchang cache, content library, festivals, astrologer profiles, consultations, orders, products, remedy trackers, and AI chat logs. Threaded connection pool with 2–30 connections, dead-connection replacement, and pgcrypto for UUID generation.
Engineering twist
The PgConnection wrapper provides a sqlite3-like execute API over psycopg2, so engine modules can use parameterized queries without ORM overhead. The pool self-heals: if a connection fails the ping test, the entire pool is closed, recreated, and a fresh connection is returned - no request sees a stale handle.
S/08
Frontend
React 19.2 · Vite 7.2 · Tailwind 3.4 · shadcn/ui
Browser interface
228 source files, ~78K LOC. React 19 with TypeScript 5.9, Vite build system, Tailwind CSS, Radix UI primitives (Dialog, Select, Tabs), GSAP animations, Lucide icons, and React Router DOM 7.1. Three.js cosmic background on the landing page.
Engineering twist
The build pipeline runs i18n key validation, sitemap generation, and linting before every production build. No generic UI kit - components are built from Radix primitives with an observatory theme (black + gold) that adapts to both mobile and desktop without a separate codebase.
S/09
PDF & Reports
fpdf2 · Kundli report assembler
Document generation
fpdf2 generates downloadable Kundli reports with planetary tables, divisional chart summaries, Dasha timelines, and remedy recommendations. Reports are rendered server-side from computed chart data, not static templates.
Engineering twist
PDF generation runs in the same Python process as the chart engines, so the document always matches the live API response. No headless browser overhead - pure Python PDF construction with embedded Devanagari font support for Hindi output.
S/10
Test Harness
pytest + Playwright · 71 test files
Verification layer
1,850+ test functions across 71 test files. Backend tests cover engine correctness (panchang accuracy, D60 division boundaries, Lal Kitab debt rules, transit variant coverage), auth flows, and API contracts. Frontend Playwright specs cover form submission, mobile responsiveness, and cross-browser compatibility.
Engineering twist
Every astrology engine has contract tests against known reference data - for example, D60 unit boundaries are tested at 0.5° precision, and panchang calculations are verified against published ephemeris for 2024–2026. A failing engine test blocks deployment because the schema migration runner runs before the backend starts.
[ H ] · Roadmap
What ships next.
The architecture leaves room for the next milestones on purpose. Each item below is scoped to a real gap in the current codebase - not aspiration, planned work.
R/01 · Payments
Stripe / Razorpay checkout integration
The `orders` and `products` tables exist in `app/database.py`, and the frontend has a payments ledger (`ClientPaymentsSection` in `ClientProfile.tsx`). What is missing is the payment gateway SDK - neither Stripe nor Razorpay appears in `requirements.txt`, and no payment-intent or webhook routes exist. The roadmap adds server-side capture with idempotency keys and webhook signature verification.
R/02 · Real-time media
WebRTC video / voice consultation
The `consultations` table supports `audio` and `video` types, and the astrologer dashboard shows booking slots. There is no WebRTC, Twilio, or Agora stack in the backend or frontend. The roadmap is a lightweight WebRTC mesh or SFU integration so astrologers and clients can connect without leaving the platform.
R/03 · Native mobile
iOS and Android apps
Today the platform is a responsive web app with PWA support. A native mobile app is not in the repository. The roadmap is a React Native or Flutter shell that reuses the existing FastAPI backend and provides offline chart caching for areas with intermittent connectivity.
R/04 · AI chat
Dedicated /api/ai/chat streaming endpoint
The README mentions Gemini / OpenAI integration, but there is no `ai_chat_logs` table in `app/database.py`, no OpenAI or Gemini client import in the backend, and no streaming chat endpoint. The roadmap adds a dedicated `/api/ai/chat` endpoint with context-window management, rate limiting, and chart-aware prompting that injects the user's live kundli data into the system message.
R/05 · Push notifications
Service worker and push infrastructure
No service worker, push subscription, or notification scheduler exists in the frontend build. The roadmap adds reminder push for muhurat windows, consultation start times, and remedy check-ins using the Web Push API with VAPID keys.
R/06 · i18n runtime
Full Hindi-English translation layer
`scripts/i18n-sanitize.py` exists for build-time validation, and many engine outputs already include bilingual fields (`en` / `hi`). What is missing is the runtime translation JSON catalog and locale switching UI. The roadmap completes the i18n loop so every user-facing string is overridable per locale.
[ I ] · In production
Three workloads. One ephemeris.
U/01
Birth chart consultation - from data entry to 16-chart report in under 3 seconds.
A user enters birth details on the frontend. The FastAPI backend computes planetary positions via pyswisseph, generates D1 through D60 charts, runs Dasha and transit analysis, and returns a structured JSON payload. The astrologer reviews the same computed data - no manual calculations, no ephemeris lookup books.
U/02
Lal Kitab remedy tracking - 43-day disciplined practice with measurable check-ins.
A Lal Kitab reading identifies a planetary debt and prescribes a daily remedy. The user starts a remedy tracker in the app, receives daily reminders, and logs check-ins. Progress is stored in PostgreSQL and surfaced to both the user and the astrologer as a compliance chart.
U/03
Astrologer marketplace - independent practitioners on a shared computation backend.
Independent astrologers register, set per-minute rates, and manage their client rosters. Every practitioner uses the same chart computation backend - the differentiation is interpretation skill, not software access. The platform handles scheduling, wallet billing, and note archival.
Argument · AstroRattan
Planets show where the energy is.
The charts show where it goes.
Next system
Back to all systems