आपकी कुंडली भविष्यवाणी नहीं है।यह निर्णय लेने का लेंस है।

Birth-chart engine अपने sources का नाम लेता है। बृहत् पराशर होरा शास्त्र से आते हैं बारह लग्नों के योग कारक और पाँच पंचमहापुरुष योग। कल्याण वर्मा की सारावली से लूनर और सोलर योग, नभस चार्ट-आकृति योग, और Planetary Rays का score। भृगु सूत्र planet-in-house table के पीछे है। ज्योतिष-सिद्धान्त-सार से नवमांश निकालने की विधि और सभी सत्ताईस जन्म नक्षत्र स्वभाव आते हैं। S. Kannan की Fundamentals of Hindu Astrology से षड्बल, dignity और friendship tables, Bhinnashtakavarga contribution tables, और आपके natal Moon से पढ़े जाने वाले गोचर transit।

Numerology engines किताब के हिसाब से अलग रखे गए हैं, एक ही score में मिला नहीं दिए गए। पंकज चौहान की Advanced Vedic Numerology से Vedic Grid के combination और एक numerology दशा timing layer आती है। डॉ. ऑलिवर टैन की Power of Numbers अपना उल्टे-त्रिकोण वाला chart और Root Number देती है - मूलांक या लो शू grid से बिलकुल अलग बनावट। सेफेरियल का grid और Chaldean name numbers रचिता गुप्ता की Life With Number Magick से हैं। Chaldean letter table अपनी अलग file में है, क्योंकि बाकी जगह का name table Pythagorean है, Chaldean नहीं।

स्रोत का नाम लेने का मतलब यह भी है कि उससे क्या नहीं लिया गया, वह भी दर्ज हो। दैवज्ञ वल्लभ के पंद्रह अध्यायों में से Prashna feature छह लागू करता है; युद्ध, मृत्यु-भविष्यवाणी और वर्षा वाले अध्याय सोच-समझकर छोड़े गए हैं, चूक से नहीं। सारावली बत्तीस नभस योग बताती है और सभी बनाए गए हैं; जहाँ सारावली और BPHS किसी आकार को अलग शब्दों में कहते हैं, engine BPHS का अनुसरण करता है और सारावली का पाठ code के साथ दर्ज करता है। भृगु सूत्र के अपने रोग और मृत्यु-समय वाले हिस्से planet-in-house table में आते ही हटा दिए गए, और code यह table के साथ दर्ज करता है।

जन्म तिथि, स्थान और नाम से ही बहुत कुछ निकल आता है। कुंडली की गणना सभी नौ ग्रह Julian day से derive करता है - राशि, अंश, नक्षत्र, पाद और retrograde - और पूरी Vimshottari Dasha timeline चंद्रमा की longitude से seed होती है। Gochara आज के transits आपकी जन्म चंद्र राशि से गिनता है, इसलिए उसे ascendant की ज़रूरत ही नहीं। Numerology कैलेंडर तिथि और आपका नाम पढ़ती है। इसमें कुछ भी कमज़ोर नहीं किया गया, और यह कोई consolation prize नहीं है।

बात लग्न (ascendant) पर रुकती है। the app's code में तेरह functions एक ही guard रखते हैं - if (!chart.ascendant) - और फिर null या एक खाली list return करते हैं; इनमें Shad Bala strength, yoga और dosha scan, aspect tables, Arudha Lagna, Bhava और Graha Padas, Argala, Ashtavarga शामिल हैं। Blueprint के strength और risk index भी खुद को रोक लेते हैं, लिखी हुई वजह के साथ: houses को लग्न चाहिए, और लग्न को जन्म समय, इसलिए उसे अनुमान से बनाने के बजाय दोनों index रोक दिए जाते हैं। यहाँ खाली field आपके डेटा की कमी नहीं, एक इनकार है।

कुछ तो compute करना ही पड़ता है, इसलिए समय न हो तो 12:00 दोपहर मान लिया जाता है - और app आपको बताता है कि इसकी कीमत क्या है। एक सटीकता जाँच आपका chart जन्म के दिन के दोनों सिरों पर दोबारा निकालता है और नतीजे मिलाता है: चंद्रमा अपनी राशि रखता है या नहीं, अपना नक्षत्र रखता है या नहीं, चलती Mahadasha का स्वामी वही रहता है या नहीं, और उस period की तारीखें कितना हिलती हैं। जब दोनों सिरे सहमत हों, वह साफ़ कह देता है।

Vimshottari timeline एक ही संख्या पर टिकी है: जन्म के समय आपके Moon का sidereal longitude। वह 27 नक्षत्रों में से जिसमें पड़ता है, वही नौ planetary lords में से पहला चुनता है, और उस नक्षत्र का जितना भाग पहले ही पार हो चुका है वह उस lord के period से घटा दिया जाता है - इसलिए पहला Mahadasha अधूरा होता है, और उसके बाद की हर तारीख उसके साथ खिसक जाती है। नौ निश्चित अवधियाँ मिलकर 120 वर्ष बनाती हैं, तो पूरा क्रम जन्म से लगभग 120 वर्ष तक चलता है। यदि birth time file पर नहीं है, तो दोपहर 12 बजे मान लिया जाता है, और chart उस दिन के दोनों सिरों पर दोबारा निकाला जाता है - यह देखने के लिए कि दोनों सिरों पर एक ही Mahadasha चल रही निकलती है या नहीं।

Mahadasha के नीचे वही गणित दो बार और चलता है। Parent period नौ lords में उनकी अपनी year-lengths के अनुपात में बाँटा जाता है, शुरुआत parent के अपने lord से - एक ही function दोनों levels पर लगता है, दो अलग implementations नहीं जिन्हें मिलाकर रखना पड़े। बीच का level फिर भी चौड़ा है: उन्नीस वर्ष के Saturn Mahadasha के भीतर एक Antardasha तीन वर्ष से कुछ अधिक चलती है। उसके नीचे का Pratyantardasha हफ़्तों से महीनों का होता है, और असली निर्णय इसी scale पर बैठता है। सारे नौ Mahadashe अपने Antardasha के साथ nested publish होते हैं।

Transits दूसरी layer हैं, और वे किसी भी dasha की तारीख को नहीं हिलाते। Gochara देखता है कि आज सारे नौ ग्रह कहाँ हैं - गिनती आपके natal Moon की राशि से, ascendant से नहीं। Saturn की अपनी positions अलग से नाम पाती हैं: Moon से बारहवीं, पहली और दूसरी राशि Sade Sati के rising, peak और setting phase हैं; चौथी Ardha Ashtama Sani है, आठवीं Ashtama Sani।

Numerology को आपकी calendar जन्म-तारीख़ चाहिए। नाम optional है। कोई birth time नहीं, कोई जन्म-स्थान नहीं। Free numerology calculator अपना result 'complete' लिखकर देता है, जबकि उसके साथ वाले birth-chart calculator को बताना पड़ता है कि Moon कितना certain है, और birth time न हो तो वह houses और yogas छोड़ देता है। तारीख़ उन्हीं digits से पढ़ी जाती है जो आपने type किए, midnight पर anchor करके - UTC instant से नहीं। वरना 17 अप्रैल 1991 की 02:00 IST जन्म 16 तारीख़ पर खिसक जाती और Mulank 8 से 7 हो जाता।

ये methods अलग files में हैं क्योंकि ये सच में अलग methods हैं। Mulank और Bhagyank तारीख़ के अपने digits reduce करके निकलते हैं। Vedic Grid पुस्तक के तरीक़े से बनी grid - century छोड़कर, Mulank और Bhagyank जोड़कर - के नौ cells पर 47 geometric combinations test करता है। एक दूसरी table, 51 rows की, वही नौ-cell layout, तारीख़ के हर digit की सादी गिनती से भरा हुआ, एक दूसरे लेखक की planetary framing से पढ़ती है। तीसरा method तारीख़ के digit-pairs से एक उलटा triangle बनाता है और उसे एक Root Number तक reduce करता है, कोई master number रखे बिना। Chaldean नाम-मान उस letter table पर चलते हैं जिसमें कोई letter 9 का नहीं होता, और जिसका Y और W को vowel मानने का अपना rule है।

किसी भी चीज़ को मिलाकर एक consensus number नहीं बनाया जाता। 51-row वाली table कई जगह Vedic Grid के arrows के वही cell-sets पर आती है; सिर्फ़ planetary framing और शब्द अलग होते हैं, और उसे replacement नहीं, दूसरी reading की तरह रखा गया है। जहाँ source किताब ख़ुद अपने से उलट जाती है, वह भी दर्ज है - Power of Numbers किताब का एक worked example अपने ही गणित से मेल नहीं खाता।

दो गणनाएँ एक ही birth record पर चलती हैं और एक-दूसरे को छूती भी नहीं। astrology वाला हिस्सा आपके जन्म के Moon से निकला Vimshottari Mahadasha पढ़ता है; numerology वाला हिस्सा आपके जन्म के दिन और महीने को calendar year के साथ जोड़कर निकला Personal Year। दोनों पक्षों के लिए पहले से मौजूद एक tone rule किसी अवधि का tone तय करता है, और वही tone एक तीन-शब्द वाले axis पर rename होते हैं, दोबारा गणना नहीं: expand, build, hold। चूँकि दोनों हिस्से उन्हीं तीन शब्दों पर आते हैं, सहमति एक शब्दशः equality check बन जाती है - दो अलग-अलग निकाले गए values के बीच - भरोसे पर माँगा गया दावा नहीं।

axis क्रम में रखा गया है, इसलिए दोनों stance के बीच का अंतर एक दूरी बन जाता है: शून्य, एक या दो। शून्य को सहमति बताया जाता है। एक का अंतर partial split के रूप में आता है - किस पक्ष ने क्या पढ़ा, यह नाम लेकर - और दोनों में से जो अधिक सतर्क stance है, उसी को कार्य करने के लिए आगे रखा जाता है। दो का अंतर विरोधाभास कहलाता है, इन्हीं शब्दों में, इस सलाह के साथ कि साल को छोटे परीक्षण के लिए लें, बड़े commitment के लिए नहीं। दोनों readings का औसत निकालकर कोई बीच का उत्तर नहीं बनाया जाता; दोनों अपने stance के साथ page पर बनी रहती हैं।

verdict के साथ कोई confidence percentage नहीं जुड़ा होता। page इसके बजाय यह बताता है कि उत्तर उन बातों पर कितना टिका है जो आपने दी नहीं: जन्म-समय न हो तो chart 00:00 और 23:59 दोनों पर दोबारा compute होता है, और page बताता है कि उस दिन के भीतर ruling Mahadasha वाकई बदलता है या नहीं - बदलता है तो दोनों संभावित rulers का नाम लेता है, और नहीं बदलता तो साफ़ कह देता है। अलग track-record engine भी वही नियम मानता है: तीन feedback measures अलग-अलग, कभी एक score में average नहीं, और कुछ भी quote नहीं होता जब तक उसके पीछे कम से कम पाँच entries न हों।

यहाँ कोई Gemstone Recommender नहीं है, और कोई Rudraksha Recommender भी नहीं। यह app जो remedies देता है वे remedy engines के अपने लिखे design से behavioural हैं - कुछ जो आप desk पर या एक बातचीत में कर सकते हैं - क्योंकि, जैसा remedy engine का अपना shipped text कहता है, जिस remedy को ख़रीदना या मानना पड़े वह जाँची नहीं जा सकती। एक lucky gemstone और एक associated deity पहले यहाँ ship होते थे। दोनों हटा दिए गए, और अब एक API assertion fail हो जाता है अगर कोई भी field वापस आ जाए। इनसे इनकार करना ही हमारी position है, कोई कमी नहीं।

Remedy endpoint के weekly और yearly horizons को test suite की एक assertion scan करती है - हर title, action और reason जो वे horizons publish करते हैं - और अगर कोई डराने वाला शब्द मिल जाए तो run fail हो जाता है। दूसरी तरफ़ के वादे भी यहाँ ख़त्म हो जाते हैं: terms साफ़ कहते हैं कि कोई prediction, timing window, compatibility score या verdict सही होने या सच होने की guarantee नहीं है, और हर फ़ैसला आपका ही रहता है।

Career और money read उस number को भरता नहीं जिसका data नहीं है। Birth time के बिना Ascendant नहीं निकलता, और उसके साथ कोई house, Shad Bala या Ashtakavarga आँकड़ा भी नहीं - तो वह engine 'unavailable' return करता है और यही वजह नाम से बताता है, सिर्फ़ dignity पर बना एक आँकड़ा पूरे read की तरह पेश नहीं करता। जहाँ कम data पर भी एक read मुमकिन है, वहाँ behavioural engine अपनी ही ग़लती की direction बताता है: mental clarity index पर लिखा है कि वह birth time के बिना 'biased high' है, क्योंकि aspects, जहाँ खिंचाव दिखता है, बिलकुल पढ़े नहीं जा सकते, और Moon और Venus वाला read कहता है कि अच्छे result को confirmed नहीं, unconfirmed मानें।

Public calculators और Convergence page unauthenticated routes पर चलते हैं, और उनके handlers कुछ भी persist नहीं करते - कोई document नहीं बनता और किसी model पर कोई counter नहीं बढ़ता, इसलिए calculation ख़ुद database में कोई निशान नहीं छोड़ती। Anonymous visit का बस उतना record बनता है जितना privacy policy के usage statistics में लिखा है - कोई पहचान नहीं जब तक आपने cookie banner में अनुमति न दी हो, और आपका type किया हुआ कभी नहीं। आप birth date type करके पूरा result पढ़ सकते हैं, झलक नहीं, और tab बंद कर सकते हैं। Birth-place field इसका एक अपवाद है, और यह एक request नहीं है। आप जैसे ही दूसरा character type करते हैं, और जब तक कोई suggestion नहीं चुनते, वह text matching places ढूँढने के लिए हमारे ही server पर जाता है; और जब तक bundled city list अकेली suggestions भर न दे, हमारा server उसे Open-Meteo को आगे भेज देता है। ग़लत latitude ascendant और उस पर बने हर house को चुपचाप ख़राब कर देता, इसीलिए यह lookup है।

Account इससे ज़्यादा रखता है, और privacy policy उसे category के हिसाब से नहीं, field के हिसाब से गिनाती है: उन्नीस fields जो आप देते हैं, तेरह derived values, और बाईस चीज़ें जो automatically collect होती हैं। Account record ख़ुद आपका नाम, email, आपकी language और आपका goal, और एक birth record रखता है - date और time बिल्कुल जैसे आपने type किया, time दिया था या नहीं, place label, latitude, longitude, timezone offset, और उनसे निकाला गया UTC instant।

Deletion एक असली route है, कोई email address नहीं। Settings में, डेटा और प्राइवेसी के नीचे, यह पहले confirm माँगता है और फिर DELETE /auth/account call करता है। वह handler एक declared list पर चलता है - चौबीस collections, profiles, chat, life events और Prashna questions से लेकर usage statistics और signed-in devices तक - और account row सबसे आख़िर में हटाता है, ताकि बीच में fail होने पर एक ऐसा account बचे जो दोबारा कोशिश कर सके, न कि ऐसी rows जिन्हें कोई ढूँढ न पाए। Purchase और refund records delete नहीं होते, बल्कि account से अलग कर दिए जाते हैं, क्योंकि invoice records रखने पड़ते हैं। List हाथ से लिखी sequence की जगह declared है क्योंकि पहले collections छूट चुकी हैं; API tests listed collections में rows लिखते हैं और delete के बाद कोई भी बची रहे तो fail हो जाते हैं।

Tier structure code में मौजूद है: चार named tiers - free tier और तीन passes - और हर एक के पीछे अपना feature matrix। लेकिन free-for-all switch हर call पर तय करता है कि free-for-all mode चालू है या नहीं, और server पर Cashfree की keys न हों तो वह चालू रहता है - जब तक a table in the app environment value 'false' न हो, जैसा gated test API पर होता है। Keys set होने पर वह a table in the app की launch date बीतने के बाद बंद हो जाता है, या उससे पहले अगर Super Admin उसे बंद कर दे - और Super Admin उसे किसी भी तारीख़ पर चालू रख सकता है। चालू रहने पर plan check हर खाते को top tier का feature set देता है, खाते का अपना tier देखने से पहले ही। इसलिए आपको मिलता है AI चैट, advanced reasoning level पर, पूरी कुंडली, गहरे अंकशास्त्र वाले हिस्से, सभी मुहूर्त समय-खिड़कियाँ, पूरा आठ-कूट अनुकूलता विश्लेषण और दैनिक से करियर तक हर रिपोर्ट, और AI उत्तर, प्रोफ़ाइल और प्रश्न-कुंडली प्रश्न गिने नहीं जाते। Mode बंद होने पर मुफ़्त प्लान और हर पास के अपने तय भत्ते होते हैं: AI उत्तर, जन्म कुंडलियाँ और सहेजी गई प्रोफ़ाइल।

इसके लिए paid structure में से कुछ भी delete नहीं किया गया। चार tiers, per-tier feature matrix और बारह-row वाला comparison table सब code में वैसे ही हैं, और हर gate - chat replies, reasoning depth, पूरी कुंडली, अंकशास्त्र, मुहूर्त, अनुकूलता, प्रश्न-कुंडली, प्रोफ़ाइल और रिपोर्ट - server पर plan check से ही होकर जाता है। Test suite API से पढ़ता है कि कौन सा mode live है, मान कर नहीं चलता, और free mode में assert करता है कि कोई दाम और कोई Unlock link दिखता न रह जाए। Mode बंद होने पर pass the app's code के Cashfree checkout से ख़रीदा जाता है: server हर order की कीमत ख़ुद तय करता है और payment पर Cashfree का signature सही निकलने के बाद ही pass देता है।

सबसे स्पष्ट fit वह है जिसके सामने एक specific निर्णय खड़ा हो - कोई launch, resignation या proposal - और जो तय करने से पहले एक दूसरा read चाहता हो। पूछिए, और YES, WAIT या NO मिलता है, साथ में एक confidence figure जो ठीक दो terms से बनता है: आपकी वर्तमान महादशा उस तरह के निर्णय के लिए कैसी पढ़ी जाती है - 60 अंक तक - और सम्बन्धित भाव के स्वामी की Shad Bala शक्ति - 40 अंक तक। दोनों terms screen पर नाम से दिखते हैं। निर्णय log किया जा सकता है, और बाद में दर्ज किया जा सकता है कि वास्तव में क्या हुआ।

यह उन पाठकों के लिए भी है जो काम को मान लेने के बजाय जाँचना चाहते हैं। अध्याय के सन्दर्भ readings के साथ छपते हैं और तीनों भाषाओं में जान-बूझकर English में रहते हैं, क्योंकि अनूदित पुस्तक-नाम से कोई अंश नहीं मिलता - "BPHS Ch.68, Sloka 1-6" इसीलिए है कि उसे देखा जा सके।

तीन तरह के लोगों के लिए यह ठीक नहीं है। जो guarantee चाहते हैं: एक ही category के दो options की तुलना करने पर यह मना कर देता है, क्योंकि same category का अर्थ है वही भाव, वही स्वामी और वही आँकड़े - और उनके बीच चुना गया winner केवल एक coin toss होगा जिस पर कुंडली बनी हो। जो खरीदने वाला उपाय चाहते हैं: जो gemstone और deity fields पहले थे, वे हटा दिए गए। जो diagnosis या investment call चाहते हैं: body section किसी condition का नाम नहीं लेता, और money timing स्वयं कहता है कि यह timing quality है, financial advice नहीं।