Methodology
Show the math.
Every date, window and score on bela.so is computed — deterministically — by a classical Vedic-astrology (drik ganit) engine: Swiss Ephemeris positions, Lahiri ayanamsa, mean nodes. No LLM writes a single number. Each muhurat lists its per-rule breakdown, and this page states plainly what is modelled and what is not yet.
The engine
Bela is a precision instrument for sacred timing, not a content farm. The same input always produces the same answer, and the answer carries its reasoning with it.
- Ephemeris: Swiss Ephemeris (full DE-series files; never the Moshier fallback), verified at process start.
- Ayanamsa: Lahiri (Chitrapaksha), frozen process-wide; mean Rahu/Ketu, per classical practice.
- Ganit: drik ganit — tithi, nakshatra, yoga and karana from true solar/lunar longitudes; sunrise/sunset with disc-centre + refraction.
- Panchang convention: the day's limbs are evaluated at the local sunrise instant, the classical rule.
- Reference city: national lists are computed for Delhi (IST, 28.61°N 77.21°E); city panchang pages recompute per location.
How a muhurat date is chosen
For each activity the engine scans every choghadiya window of the year (16 per day) and scores it by documented classical rules:
- Gates. A window is disqualified if it overlaps Rahu Kaal, Yamaganda, Gulika, Durmuhurtam or a bad Panchaka (Mrityu, Agni, Raja, Chora, Roga).
- Weights. Amrit/Shubh choghadiyas, activity-suited nakshatras (Saptadha classification), non-rikta tithis, benign yogas and the Abhijit Muhurat add strength; harsher combinations subtract.
- Inclusion. A date is listed only if its best window clears the gates, the nakshatra suits the activity, the tithi is not rikta/Amavasya, and the yoga is not Vyatipata or Vaidhriti.
- Prohibitions. For marriage and griha pravesh, dates inside Chaturmas, Kharmas (Malmas) and Adhik Maasa are excluded, as in traditional panchang lists.
The published 0–100 score is a fixed, public mapping of the engine's internal score: score = clamp(round((engine_score + 40) × 100 / 95), 0, 100). 70+ reads as auspicious, 40–69 moderate, below 40 avoid. Every date on the muhurat pages shows the full ✓/✕/~ breakdown — that breakdown is the product, not decoration.
What is modelled — and what is not (yet)
Trust comes from stating the boundary. Here is the honest scope of the current engine:
| Area | How Bela treats it | Status |
|---|---|---|
| Panchang limbs | Tithi, nakshatra (with pada), yoga, karana — from true solar/lunar longitudes, evaluated at the local sunrise instant. | Modelled |
| Rise/set | Sunrise/sunset with disc-centre + atmospheric refraction, per location. | Modelled |
| Inauspicious windows | Rahu Kaal, Yamaganda, Gulika, Durmuhurtam — windows overlapping them are disqualified. | Modelled |
| Choghadiya | All 16 Gauri choghadiya slots per day; Amrit/Shubh/Labh/Char preferred. | Modelled |
| Panchaka | Panchaka-rahita check — Mrityu, Agni, Raja, Chora, Roga Panchakas fail the window. | Modelled |
| Nakshatra suitability | Saptadha (seven-fold) classification matched to each activity. | Modelled |
| Tithi fitness | Rikta tithis (4th, 9th, 14th) and Amavasya excluded. | Modelled |
| Harsh yogas | Vyatipata and Vaidhriti excluded; other bad yogas flagged as caution. | Modelled |
| Abhijit Muhurat | The universally shubh midday window adds strength (info when not hit). | Modelled |
| Prohibited periods | Chaturmas, Kharmas (Malmas) and Adhik Maasa exclude marriage and griha pravesh dates. | Modelled |
| Tara Bala / Chandra Bala | Judged against your birth star — impossible for a generic list. App-tier, per profile. | App feature |
| Shukra/Guru asta (combustion) | Venus/Jupiter combustion prohibitions are not yet applied. | Coming |
| Holashtak | The 8 pre-Holi days some traditions treat as prohibited — not yet applied. | Coming |
| Nishita windows | Festival-specific midnight/day-part puja muhurats (e.g. Shivaratri nishita) — not yet computed. | Coming |
| Activity rules gaps | Vehicle, property and signing currently reuse the general rule set (the engine lacks dedicated rows); property's classical sthira-only preference is not yet modelled. Flagged on the affected pages. | Coming |
| DST / regional calendars | Fixed UTC offsets per city (no DST model); ±1-day festival shifts across longitudes and Smarta/Vaishnava traditions are expected. | Known limit |
No generic list — ours included — can apply Tara Bala or Chandra Bala, which judge the day's Moon against your birth star. That needs a chart; the Bela app applies both, per family member, to every window.
No LLM, no fabricated prose, no data leaving the process
Large language models are eloquent and frequently wrong about ephemeris arithmetic. So the pipeline is strict: dates, windows, tithis and scores come only from the engine; the prose around them is authored to describe those computed facts, never to invent new ones. Site JSON is regenerated deterministically — no wall-clock stamps inside the data, and the same engine version reproduces the same files byte-for-byte.
Privacy follows the same discipline. Computation runs on a vendored, hash-pinned engine (PyJHora-class, v4.8.7, audited) — fully offline, no network calls. In the app, birth details are computed on-device and never uploaded; we cannot leak or sell data we never receive.
Classical sources
The rule set is drawn from the standard muhurta literature rather than invented: the Muhurta Chintamani of Rama Daivajna (the reference for Rahu Kaal, Panchaka-rahita, tithi and nakshatra fitness and the prohibited periods), the Kalaprakasika (the South-Indian muhurta tradition, including choghadiya practice), and the electional chapters of Varahamihira's Brihat Samhita. The Saptadha nakshatra classification and the Abhijit Muhurat follow these authorities as reflected in living panchang practice.
Where traditions differ — Smarta vs Vaishnava Ekadashi, regional calendars, Holi's Bhadra split — we follow the popular North-Indian convention for Delhi and say so on the page. Computed festival dates are cross-checked against widely used calendars each regeneration.
Verify us
The same data this site renders is downloadable — CSV and JSON, CC-BY — on the datasets page, with the per-rule breakdown included. If you find a date that fails a rule we claim it passes, that is a bug we want to hear about.
Frequently asked questions
Is Bela's muhurat data generated by an LLM?
No. Every date, window and score is computed by a deterministic classical Vedic-astrology (drik ganit) engine: Swiss Ephemeris positions, Lahiri ayanamsa, mean nodes. The same input always produces the same answer. LLMs are used nowhere in the numbers pipeline — prose on data pages is authored around the computed facts.
Which ayanamsa does Bela use?
Lahiri (Chitrapaksha), the reference standard of the Indian national calendar, frozen process-wide so no computation can silently drift. Nodes are mean Rahu/Ketu, per classical practice. The app additionally offers ayanamsa reconciliation (Ultra tier) so you can compare how windows shift under other ayanamsas.
Can I verify a Bela date against another panchang?
Yes — that is the point of showing the breakdown. Each published date lists its tithi, nakshatra, choghadiya and every rule verdict (Rahu Kaal ✓, Panchaka ✓, yoga ~…), so any panchang or pandit can check the same limbs. Small differences vs other sources usually trace to ayanamsa, sunrise convention, or city; ours are stated above.
What happens to my birth data in the app?
Computation is fully offline: the engine is vendored and hash-pinned, makes no network calls, and birth details never leave the device process. There is no account requirement for the calculators, no analytics on birth data, and nothing to leak — we cannot sell what we never receive.
