All MCP tools

Planetary aspects + 5-factor house strength scores (0-100) + deep retrograde analysis. Returns '{ chart_info, aspects: { aspected_cusps: [{ house, aspecting_planet, aspect_type, orb, applying }], aspected_planets: [{ aspected_planet, aspecting_planet, aspect_type, orb, applying, mutual }], mutual_aspects, planet_aspect_summary }, house_strength: { scores: [{ house, total_score, factor_scores: { occupants, csl_strength, house_lord_placement, aspects, self_reference }, verdict }], summary }, retrograde_analysis: { retrograde_planets, station_planets, analyses }, houseConvention }'. 'aspect_type' is a graha drishti ordinal ('3rd', '4th', '5th', '7th', '8th', '9th', '10th', '12th'), never a Western aspect name. **Not KP.** The aspects are Parashari graha drishti (every planet the 7th; Mars 4/8, Jupiter 5/9, Saturn 3/10; Rahu and Ketu the 7th only by default, a derived reading), applied here as exact degrees with an orb against Placidus cusps rather than sign to sign (for the ch. 26 rule itself, sign to sign with the sputa virupas of each pair, use 'get_graha_drishti'), and 'houseConvention' names that convention and every planet whose house differs under whole sign. The strength score is built from natural benefic/malefic class, dignity and combustion, which KP judges by none of: it decides on the stellar signification chain and the cuspal sub lord. Reference and cross-system comparison only, never an input to a KP verdict. For full Shadbala (6-fold strength of planets) use 'get_shadbala'. For a Bhava bala index of houses (three components, a Lumin index and not the BPHS computation) use 'get_bhava_bala'. Whether the nodes cast graha drishti is stated five ways (F175): 'nodeDrishti' names the reading used and lists all five with their classes; pass 'node_drishti_reading' to recompute the node rows under another. Two of the three claims are also tools of their own, named in 'methodSeams': 'get_house_strength_index' (the 0-100 index, a Lumin index) and 'get_retrograde_verdicts' (the retrograde verdicts, Parashari). Call those when a reading needs one claim; this tool returns all three in one call.

Builds the SAME chart under every ayanamsa the engine implements and reports exactly which positions change lord and which hold. Use it instead of a birth-time disclaimer: the KP and Chitrapaksha frames (kp, kp_new, khullar, lahiri, true_chitra) disagree by a fixed ~5 arcminutes, so among them the set of positions that actually move is small and nameable; Raman's zero point sits about 1 degree 27 arcminutes below Lahiri, roughly one whole sub, so with raman in the comparison most cusps move, and 'spreadByFamily' shows which frame makes the spread large. Returns per cusp and per planet the levels that move (sign / star / sub / subSub) with the lord each frame gives, the base lords always, a 'summary' with 'frameIndependentAtSub' (true for about a third of charts across the five KP and Chitrapaksha frames, which is a stronger statement than any caveat, and for none once raman is included), the dasha balance spread in days (a fixed offset carried to every later period boundary, and a flag when the frames disagree on the birth mahadasha lord outright), and 'birthTimeEquivalence': how much clock-time error each position's frame spread is worth. That last block is the reframe. On the Ascendant the five KP and Chitrapaksha frames are worth well under a minute of birth time, so the frame is noise there, and raman several minutes; on the slow planets it is worth hours or days, so the frame is the entire uncertainty and no birth-time precision can settle it. Nothing here is scored, ranked or averaged, and no frame is preferred: a position either changes lord or it does not. All six frames are computed, 'true_chitra' from Spica's apparent place and 'raman' from Raman's own zero point, so none carries an 'aliasOf'.

The opening layer of a KP birth chart, in one call. Returns '{ planets[9], houses[12], currentDasha, rulingPlanets, detail }'. Each planet carries sign, house, degree, sign/star/sub lord, retrograde and combust; each house its sign and three lords; 'currentDasha' names the running MD, AD and PD WITHOUT their subtrees. Use when: you need an overview or are starting any reading. **This is deliberately not everything the engine computed, and the 'detail' block in the response names the tool holding each deeper layer**: 'get_planets' for sub-sub lord, KP number, nakshatra, pada and dignity, 'get_house_cusps' for cusp longitudes, 'get_significators' for the 4-level matrix, 'get_dasha_periods' and 'get_pratyantardasha_periods' for the dasha tree, 'get_boundary_warnings' for sub lord credibility. Call those rather than assuming this covered them. The significator matrix in particular is NOT repeated here, because it is byte for byte what get_significators returns and the protocol calls that tool anyway.

Parashari, not KP. Which planets are functional benefics, malefics, neutrals, yogakarakas and marakas for a lagna, from BPHS ch. 34. Returns TWO answers side by side and names where they differ, because the text gives two: 'stated' is the per-lagna table as printed (vv. 19-44, each row quoting its verse), and 'derived' is the rule of vv. 2-17 applied to lordship alone (kona lords auspicious, 3/6/11 lords evil, kendra lords lose their natural quality, the lagna lord specially auspicious, the 8th lordship of Sun and Moon not evil, kendra-plus-kona lord a yogakaraka). 'departures' lists every planet on which table and rule disagree, and they do disagree: Libra's Moon is named a Raja Yoga giver while owning only the 10th, Aries' Mars is hedged to 'helpful' where the rule makes a lagna lord plainly auspicious. Neither is corrected to match the other. Reads the lagna from the birth chart; pass 'lagna' to ask about another lagna directly. Rahu and Ketu are outside the table by v. 16. Edition stated (Santhanam 1984; Sharma numbers this ch. 35).

Parashari, not KP. Graha drishti of Brihat Parashara Hora Shastra ch. 26 (Santhanam; ch. 28 in Sharma), whole sign, with houses counted from the lagna's sign and never read off the Placidus chart. Three layers, each with its own 'sources' class: (1) the FULL aspects by sign, every planet the 7th, Mars the 4th and 8th, Jupiter the 5th and 9th, Saturn the 3rd and 10th (classical); (2) the PARTIAL aspects by sign, a quarter on the 3rd and 10th, a half on the 5th and 9th, three quarters on the 4th and 8th (derived: the degree scale read at whole-sign offsets, because no sign-level verse is on disk); (3) the SPUTA VIRUPAS of each pair by degree, 0 to 60: the general scale (26.6-8), BPHS 26.9-12 for Mars, Jupiter and Saturn with Jupiter's 4th/8th-sign term per the Sanskrit ('withSpecialVirupas', 'twice') and per both English translations ('withSpecialEnglishVirupas', 'once'), 'jupiterTermDisputed' marking a pair where they differ. Returns 'planets' (the signs and whole-sign houses each of the seven aspects, with grade), 'pairs' (all 63 from the seven onto the other eight bodies and the lagna degree, zeros included), 'houses' (per whole-sign house, which planets aspect it fully and partially), 'mutualFullAspects', and the nodes: whether Rahu and Ketu cast graha drishti is reported as FIVE stated readings, defined once in 'nodeReadings' with its method note, where each is held, its class and what contradicts it (F175, Q043): the 7th only (derived, the 'all planets' rule applied to the nodes), none (modern; BPHS 9.11 gives Rahu a drishti), both nodes 5/7/9 (modern), Rahu full on 5/7/9/12 with half on 2/10 and quarter on 3/6 (later, the Khemraj BPHS 51.26; Uttara Kalamrita 2.18 denies the 12th; Ketu not stated), and Rahu 5/7/9 with Ketu 3/7/10 (the Ketu half unsourced); laid out per node in 'nodes', none folded into the seven; the nodes receive aspects in 'pairs' and cast no virupas. The sign grade and the virupas are one doctrine at two resolutions and can differ; both ship. The same sign rule the avasthas and the Sudarshana chakra use. Different from get_aspects_and_strength, which applies the offsets as exact degrees with an orb to Placidus cusps. No score. Gates no KP verdict. **'pairs' is paged**, in the engine's order and never cut inside a row; 'planets', 'houses', 'mutualFullAspects', 'nodeReadings', 'nodes', 'notes', 'sources' and 'methodSeams' repeat whole on every page, so the sign layer reads from page 1 and the virupas of every pair are reached by paging to the last page. Each of the three layers is also a tool of its own, named in 'methodSeams': 'get_graha_drishti_by_sign' (the sign layer), 'get_sputa_drishti' (the virupas of every pair) and 'get_node_drishti_spread' (the five node readings). Call those when a reading needs one layer; this tool returns all three in one call.

Parashari, not KP. Layers 1 and 2 of graha drishti, Brihat Parashara Hora Shastra ch. 26 (Santhanam; ch. 28 in Sharma), whole sign, houses counted from the lagna's sign and never read off the Placidus chart: the FULL aspects by sign, every planet the 7th, Mars the 4th and 8th, Jupiter the 5th and 9th, Saturn the 3rd and 10th ('sources.fullAspects', classical), and the PARTIAL aspects by sign, a quarter on the 3rd and 10th, a half on the 5th and 9th, three quarters on the 4th and 8th where no full aspect applies ('sources.partialAspects', derived from the degree scale because no sign-level verse is on disk). Returns '{ houseSystem: 'whole-sign', lagnaSign, planets: [{ planet, sign, wholeSignHouse, signAspects: [{ signCount, sign, wholeSignHouse, grade: full | three-quarter | half | quarter, fraction, full }] }], houses: [{ house, sign, lord, fullAspectBy, partialAspectBy: [{ planet, grade }] }], mutualFullAspects: [[planet, planet]], notes, sources }'. A claim at the resolution of signs; the virupas by degree are 'get_sputa_drishti' and can differ. The nodes' own drishti is 'get_node_drishti_spread'. No score; gates no KP verdict. The same blocks 'get_graha_drishti' returns as 'planets', 'houses' and 'mutualFullAspects'.

Placidus house-cusp positions for the 12 houses. Each cusp returns '{ siderealLongitude, sign, signLord, signDegree, nakshatra, starLord, subLord, kpNumber }'. The sub-lord (CSL, Cuspal Sub Lord) is the deciding planet for that house's significations per KP methodology. For boundary-flag warnings (cusps within 10 arc-minutes of a sub-lord boundary), see 'get_boundary_warnings'.

Longitude-based harmonic aspect engine that complements the Parashari sign-aspect set. Detects aspects at 0°/30°/36°/45°/60°/72°/90°/108°/120°/135°/144°/150°/162°/180° plus the 22.5° harmonic series (22.5°/67.5°/112.5°/157.5°) with per-aspect orbs. Each detected aspect is annotated with polarity (good/bad/neutral), magnitude (major/minor), exactness, and SUB-LORD RESONANCE — when planet A's sub-lord is B, or both share a sub-lord, the aspect intensifies during the dasha of either planet. Use to surface stressful or supportive planetary tensions invisible to sign-aspect analysis.

Daily sidereal positions for all 9 KP planets across one month. No birth data required. Returns '{ month, totalDays, days: [{ date, planets: { Sun..Ketu: { siderealLongitude, sign, isRetrograde, dailyMotion } } }], pagination, pageNote }'. **Paged by day**, since a month of 9 planets does not fit one response. If you want one date, ask for that date's page rather than reading the month. Use for: external transit-planning workflows or generating ephemeris tables.

Each planet's nakshatra, nakshatra lord and pada (quarter, 3 degrees 20 minutes), read off its sidereal longitude, with the navamsa sign that pada falls in. Returns '{ Sun..Ketu: { longitude, nakshatra_number, nakshatra_name, nakshatra_lord, pada_number (1-4), pada_start_lon, pada_end_lon, degrees_into_pada, navamsa_sign, navamsa_sign_number, navamsa_lord, is_vargottama } }'. The same block 'get_nakshatra_details' returns as 'planet_pada'.

Per-planet nakshatra (lunar mansion) details + planet friendship tables. Each nakshatra spans 13°20' and is divided into 4 padas (3°20' each). Returns '{ chart_info, planet_pada: { Sun..Ketu: { longitude, nakshatra_number, nakshatra_name, nakshatra_lord, pada_number (1-4), pada_start_lon, pada_end_lon, degrees_into_pada, navamsa_sign, navamsa_sign_number, navamsa_lord, is_vargottama } }, navamsa_chart, planet_relationships: { summary, relationships[] }, methodSeams, pagination, pageNote }'. 'planet_pada' is the part a reading usually wants and repeats on every page; **the pairwise 'planet_relationships.relationships' are paged**, since natural and temporary relationships between every pair of planets is a table, not a verdict. Two blocks are also tools of their own, named in 'methodSeams': 'get_nakshatra_pada' (the pada) and 'get_planet_relationships' (the friendship table, which is Parashari). For the full D9 use 'get_d9_chart'.

Returns the orthodox KP cascade for both nodes (Rahu and Ketu), with conjoined planets, star lord, aspecting planets, and dispositor (sign lord), showing which planets contribute to each node's significations via which mechanism. Per KP Reader 1 p.158 and Reader 6 p.221/286. Use to debug or audit any reading whose verdict depends on a node being CSL or fruitful significator.

Parashari, not KP. Whether Rahu and Ketu cast graha drishti is stated five ways (F175, Q043), and this is the spread across them, none picked and none folded into the seven: the 7th only (derived, the 'all planets' rule of BPHS 26.2-5 applied to the nodes), none (modern; BPHS 9.11 gives Rahu a drishti), both nodes 5/7/9 (modern), Rahu full on 5/7/9/12 with half on 2/10 and quarter on 3/6 (later, the Khemraj BPHS 51.26; Uttara Kalamrita 2.18 denies the 12th; Ketu not stated), and Rahu 5/7/9 with Ketu 3/7/10 (the Ketu half unsourced). Returns '{ houseSystem: 'whole-sign', lagnaSign, nodeReadings: [{ reading, label, methodNote, heldBy, source, contradictedBy }], nodes: [{ node, sign, wholeSignHouse, readings: [{ reading, stated, signCounts, signs, wholeSignHouses, partial: [{ signCount, sign, wholeSignHouse, fraction }], source }] }], notes, sources }'. 'heldBy' names which engine tool answers which way, so a node aspect read elsewhere can be traced to its reading. Name the reading whenever you cite a node's aspect. The same blocks 'get_graha_drishti' returns as 'nodeReadings' and 'nodes'.

[Vedic Parashari, non-KP reference] The five-fold friendship between every pair of planets: the natural (permanent) relationship each way, the temporary one from their house positions (counted here by Placidus house), and the composite (MAHA_MITRA / MITRA / SAMA / SHATRU / MAHA_SHATRU), with a conjunction check at 10 degrees. KP judges by the stellar signification chain, not by friendship, so never let this decide a KP verdict. Returns '{ summary: { total_pairs, maha_mitra_pairs, mitra_pairs, sama_pairs, shatru_pairs, maha_shatru_pairs }, relationships: [{ planet_a, planet_b, permanent_a_to_b, permanent_b_to_a, permanent_mutual, temp_a_to_b, temp_b_to_a, temp_mutual, composite_a_to_b, composite_b_to_a, house_a, house_b, house_count_a_to_b, house_count_b_to_a, is_in_same_house, is_conjunct, conjunction_orb, interpretation }], pagination, pageNote }'. **'relationships' is paged.** The same block 'get_nakshatra_details' returns as 'planet_relationships'.

Parashari, not KP. The five avastha families of Brihat Parashara Hora Shastra ch. 45, per planet, each with its verses: baladi (vv. 3-4: infant, youthful, adolescent, old, dead by six-degree bands, ascending in odd signs and reversed in even, graded one fourth / half / full / negligible / nil), jagradadi (vv. 5-6: awake, dreaming, asleep by dignity), deeptadi (vv. 7-10: nine states by dignity and relationship, every one that holds listed), lajjitadi (vv. 11-18: six states by placement, company and aspect, with v. 18's 'bhavaDestroyed' for Kshudhita and Kshobhita), and sayanadi (vv. 30-39: the twelve states by the stated formula, working shown). Every definition is at the SIGN level as the text states it: exaltation is the exaltation sign, conjunction the same sign, Drishti is graha drishti counted sign to sign, houses are whole sign; the moolatrikona ranges are ch. 3 vv. 51-54 and benefic/malefic follow ch. 34 vv. 8-10. The sayanadi SUB-STATE (Drishti/Cheshta/Vicheshta) needs the Anka value of the first syllable of the native's name, which no chart carries: pass 'name_anka' (1 to 5) to compute it, otherwise it is reported as not computable with the reason, never defaulted. The lajjitadi states read aspects, and whether Rahu and Ketu cast one is stated five ways (F175): they are computed with the nodes aspecting the 7th only (derived), and 'nodeDrishti.alternatives' lists each other reading with its class and the planets whose lajjitadi states it would change. Edition stated (Santhanam 1984). Gates no KP verdict.

Sidereal positions for all 9 KP planets (Sun, Moon, Mars, Mercury, Jupiter, Venus, Saturn, Rahu, Ketu). Returns '{ Sun..Ketu: { siderealLongitude, sign, signLord, signDegree, nakshatra, starLord, subLord, kpNumber (1-249), pada, dignity (EXALTED/OWN/FRIEND/NEUTRAL/ENEMY/DEBILITATED), isRetrograde, isCombust, combustionGrade (NONE/ORDINARY/FULL), house } }'. For combustion-only analysis use 'get_combust_planets'.

[Jaimini adjunct] The sign-to-sign aspect Jaimini and BPHS ch. 8 v. 9 share: a movable sign aspects the three fixed signs other than the one next after it, a fixed sign the three movable signs other than the one next before it, a dual sign the other three dual signs; symmetric. Returns for every sign the signs it aspects, the planets aspecting it and its occupants on this chart. This is the rule under the arudha aspects and the Drig dasha; it had been computed inside get_arudha_lagna since F050 corrected it and reachable from nothing else. Not the graha drishti of the planets.

Recomputes lagna and house cusps for an alternate latitude/longitude at the original birth datetime. Planets do not move (geocentric positions unchanged) but house assignments shift. Use for 'where should I move/work?' analysis, strong NRI / immigration-consultant appeal. Returns the relocated ascendant, all 12 cusps, and per-planet house-shift between natal and relocated charts.

Parashari, not KP. The five special lagnas Brihat Parashara Hora Shastra constructs, each with its verses: Bhava Lagna, Hora Lagna and Ghati Lagna advance from the Sun's longitude AT SUNRISE at 6, 12 and 30 degrees per ghati of time elapsed since that sunrise (ch. 5 vv. 2-8); Varnada Lagna is a SIGN reached by the odd/even counting rule of ch. 5 vv. 10-13 from the natal lagna and the Hora Lagna, with the working shown; Pranapada is the natal Sun advanced 120 degrees per ghati with the fixed/dual sign offset of ch. 3 vv. 71-74. The day is sunrise to sunrise, so a birth before dawn measures from the previous sunrise. Each point carries its sidereal longitude, sign, whole-sign house and Sripati house. Sree Lagna and Indu Lagna are NOT in BPHS and are returned under 'notComputed' with the reason, rather than built from a summary and labelled Parashari. Hora Lagna and Ghati Lagna are the inputs to the Jaimini longevity lagna-pairs. Source is stated with the edition (Santhanam 1984). Nothing here gates a KP verdict.

Parashari, not KP. Layer 3 of graha drishti: the sputa virupas, 0 to 60, of every pair from the seven onto the other eight bodies and the lagna degree, 63 rows with zeros included, by degree. Each row gives the general scale (BPHS 26.6-8, 'generalVirupas'), BPHS 26.9-12 for Mars, Jupiter and Saturn with Jupiter's 4th/8th-sign term per the Sanskrit ('twice', 'withSpecialVirupas', classical) and per both English translations ('once', 'withSpecialEnglishVirupas', disputed), and 'jupiterTermDisputed' where the two differ; both Jupiter readings ship, neither is picked. A row also carries the pair's sign grade, the same pair read at the resolution of signs, because the two resolutions can differ and both are reported. Returns '{ houseSystem: 'whole-sign', lagnaSign, pairs: [{ from, to, toSign, signCount, signGrade, signFraction, separationDeg, generalVirupas, withSpecialVirupas, withSpecialEnglishVirupas, jupiterTermDisputed, segment }], notes, sources, pagination, pageNote }'. The nodes receive aspects here and cast no virupas. No score; a virupa is the classical quantity and nothing is summed. **'pairs' is paged**, in the engine's order and never cut inside a row. The same block 'get_graha_drishti' returns as 'pairs'.

Flags every house cusp and natal planet that sits within 10 arc-minutes of a sub-lord boundary, where a small ayanamsa or birth-time correction can flip the sub-lord and invert the prediction. CRITICAL means within 6 arc-minutes, CAUTION within 10; both bands are Lumin conventions, not KP rules, and neither is a kala (the corpus kala is one arc-minute, 'thresholdProvenance' says so on every entry). 'distanceArcmin' and 'boundaryLongitude' are exact to the sub-lord table, and a sign line inside a sub is not a boundary because the sub lord does not change there. Run this before relying on borderline CSL verdicts; it is the cheapest credibility check available.

Quantifies how close every house cusp and planet sits to a sub-sub-lord boundary (the 2,193-cell KCIL precision grid: the 243 whole subs tiled nine ways from the sub lord, the six that straddle a sign line split there). Returns per-position arc-seconds to nearest boundary, the alternate sub-sub-lord that would apply if the position shifted across the boundary (including across a sub edge), a CRITICAL/WARNING/STABLE flag, and 'closestPosition', the one position nearest an edge with its birth-time equivalent for a planet, which is the fact a twin analysis turns on. Also a 0-100 twin-divergence index, a Lumin convention carrying 'scoreProvenance': it reads HIGH on most charts (81.8% of 400 random charts, LOW on none) because the closest of 21 positions dominates it, so do not report a HIGH as a finding about this chart. Use for birth-time precision audits, twin-chart analysis, and boundary-sensitive rectification. To compare two actual birth times, use get_twin_divergence_score or get_twin_differentiation, which read both charts; the index here reads one.

Parashari, not KP. The sub-planets of Brihat Parashara Hora Shastra ch. 3, each with its verses. The Dhuma group (vv. 61-64) is arithmetic on the natal Sun: Dhuma = Sun + 4 signs 13°20′, Vyatipata = 12 signs − Dhuma, Parivesha = Vyatipata + 6 signs, Indrachapa = 12 signs − Parivesha, Upaketu = Indrachapa + 16°40′; the text supplies its own check (Upaketu + one sign = the Sun) and it is returned as 'dhumaGroupResidual'. The kaala velas (vv. 66-70) divide the day (sunrise to sunset) or night (sunset to next sunrise) into eight parts lorded from the weekday lord by day and the fifth weekday's lord by night, the eighth lordless: Saturn's part is Gulika, the Sun's Kaala, Mars' Mrityu, Jupiter's Yamaghantaka, Mercury's Ardhaprahara. v. 70 gives Gulika's LONGITUDE as the Ascendant rising at the start of its portion; the other four are given the same rule by extension and say so. Gulika is also called Mandi; the later mid-portion reading is reported beside the BPHS point and labelled as not in the text, so a caller comparing against software can see why they differ. Every point carries whole-sign and Sripati houses. Edition stated (Santhanam 1984). Gates no KP verdict; the engine already computes Gulika as a TIME WINDOW in the panchang, and this is the POSITION.

Parashari, not KP, and the BPHS form only: whether Jaimini judges a matter BY argala is Q032's question and is not answered here. From Brihat Parashara Hora Shastra ch. 31 vv. 2-18: planets in the 2nd, 4th, 11th (and 5th) from a reference cause argala, planets in the 12th, 10th, 3rd (and 9th) obstruct it, counted from the reference per Santhanam's note; argala prevails when the causing planets outnumber the obstructors; the grade is one planet limited, two medium, more than two excellent; three or more malefics in the 3rd are vipreet argala, 'harmless and very favourable'. The reference is the lagna by default, or any bhava ('reference_house', whole sign from the lagna) or planet ('reference_planet'). Two lines the text leaves open are REPORTED BOTH WAYS rather than picked: the v. 10 quarter rule (obstruction only when the two planets sit in matching quarters, 1st with 4th, 2nd with 3rd, which much software ignores) gives the primary 'verdict', with 'verdictByHouseAlone' beside it; and the ambiguous node reversal ('counted accordingly in a reverse manner') is applied in the common reading with 'withoutNodeReversal' beside it. The strength branch ('if the Argala causing Grah is stronger than the obstructing one') decides an equal count: 'verdict' stays the count verdict ('undecided') and 'verdictByStrength' gives the tie on the BPHS ch. 27 Shadbala in virupas (never the 0-100 index), under TWO readings of 'stronger', both returned and neither picked: raw total virupas, and each planet's total over its own 27.32-33 requirement (with the Sun's minority 300 bar where the Sun is in the tie). Read 'comparison.readingsAgree' before either. Rahu and Ketu have no Shadbala, so a tie with a node in it stays undecided with that reason. The dasha timing is not applied. Subha, papa or mixed argala by ch. 34 vv. 8-10. Edition stated (Santhanam 1984; ch. 33 in Sharma). Gates no KP verdict.

[Lumin extension, not a KP verdict] A per-planet 0-1 activation INDEX from explainable feature weights: matrix level (L1=1.0, L2=0.7, L3=0.5, L4=0.3), Ruling Planet presence (+0.30), active dasha layers (+0.25 each), natal retrograde as KP reads it, Rahu and Ketu never (-0.20; 'retrogradeReading' lists the planets the astronomical flag marks, F160), denial-house overlap (up to -0.25), logistic-squashed. It is NOT a probability and the response's scoreProvenance says so: KP assigns no number to anything (Q012) and states there is no place for probabilities (KP-ABSOLUTES A7); every weight here is a Lumin convention. Returns ranked significators with per-feature contributions and a STRONG/MODERATE/WEAK/NEGLIGIBLE band that is not comparable with any other tool's band (F031). Use to ORDER candidates within one reading, never to state a likelihood; the promise verdict comes from analyze_natal_promise.

KP bhadhakasthana selection by lagna mobility class (KP Reader 3 ch.1 p.153). Movable lagna (Aries/Cancer/Libra/Capricorn) maps to 11th house, fixed lagna (Taurus/Leo/Scorpio/Aquarius) maps to 9th house, dual lagna (Gemini/Virgo/Sagittarius/Pisces) maps to 7th house. Returns the bhadhaka cusp's CSL, its star lord, all signifying planets, and a danger flag when the bhadhaka CSL also signifies maraka houses (2/7/8/12).

Kanak Bosmia's 6-Fold Significator Matrix extends KP's L1-L4 with L5 (sub-sub-lord of cusp + its star satellites) and L6 (sub-lord of occupant + sub-lord of cusp lord). Also returns the 7-Ruling-Planet set (Lagna sign/star/sub + Moon sign/star/sub + Day Lord) instead of the canonical 5. Use when standard 4-level matrix produces too few candidates or for cross-school comparisons.

[KP extended: KSK's convergence block beside S.P. Khullar's interlink score, the six-level chain with Sunil Gondhalekar's level 5, and cusp boundary sensitivity] CSL (Cuspal Sub Lord) panel (renamed from get_csl_advanced on 2026-10-08), four blocks in one call: (1) 'multiCuspConvergence', each event cusp's sub lord checked independently against the event's houses; (2) 'interlinkEventScore', cuspal interlink event scoring; (3) 'sixLevelMappings[]', the 6-level sub-lord chain (sign→star→sub→sub's sign→sub's star→sub's sub); (4) 'cuspSensitivity', cusps within the threshold (default 10 arc-minutes) of a sub boundary. Returns '{ multiCuspConvergence, interlinkEventScore, sixLevelMappings[], cuspSensitivity, summary, methodSeams[] }'. Only (1) is KSK's rule, applied cusp by cusp, and its STRONG/MODERATE/WEAK ladder is a labelled Lumin convention ('scoreProvenance'), not the promise verdict, which is analyze_natal_promise. Each block is also carried by a tool of its own, named in 'methodSeams': (1) by get_multi_cusp_convergence; (2) is S.P. Khullar's Cuspal Interlink theory, carried under his name by get_cuspal_interlink_score; (3) goes past KSK's sub lord and its level 5 is Gondhalekar's Four Step authority, carried by get_six_level_sublord_chain; (4) is get_boundary_warnings' claim, measured there exactly. All four still ship here.

[RENAMED, use get_csl_panel; KP extended] The same tool under its old name, kept for one release so existing callers keep working. It returns exactly what get_csl_panel returns: multiCuspConvergence, interlinkEventScore, sixLevelMappings and cuspSensitivity.

[KP extended, S.P. Khullar's Cuspal Interlink theory] For one event, the interlinks between its own cusps: where one required cusp's sub lord is another's sub lord (CSL_to_CSL) or star lord (CSL_to_StarLord), with a density score. Reading links ACROSS cusps is Khullar's method; KSK judges a matter by the cuspal sub lord's own significations (KP Reader 5 canon p.195), so this is a successor's reading beside the KSK verdict, not part of it. Returns '{ school, author, system, divergencePoint, event, requiredHouses, relevantInterlinks: [{ houseA, houseB, linkType, sharedPlanet, score }], totalScore, maxPossibleScore, scoreRatio, verdict, summary, scoreProvenance }'. The 2/1 weights, the maximum and the 40%/20% bands are Lumin's ('scoreProvenance'); read 'relevantInterlinks', which carry the method. For every cusp against every other, get_interlink_strength_matrix.

[KP extended, after S.P. Khullar's Cuspal Interlink theory] Computes a 12×12 cuspal interlink strength matrix. Links between every pair of cusps are Khullar's reading, not KSK's verdict rule (KSK judges by the cuspal sub lord's own significations), and the 3/2/1 weights are unsourced. Each cell scores how strongly cusp i's {sub, star, sign} lords appear among cusp j's {occupant, owner, star-of-occupant, star-of-owner}. Weights: sub-lord match = 3, star-lord = 2, sign-lord = 1. Per-cell max = 24. Returns '{ matrix, flatTopLinks, averageRatio, densestHouse, methodologyNote, summary, pagination, pageNote }'. **'matrix' is paged by row**, one row per cusp with all 12 of its cells intact, so a page is whole cusps and never half a row; the page budget counts the blocks that repeat, so a page holds a few cusps (three to six on the charts measured) and the matrix runs to two pages or more. 'flatTopLinks' (the 24 strongest links overall), 'densestHouse' and 'averageRatio' repeat on every page and are usually the answer on their own, so page into the full matrix only when you need a specific cusp pair the top links do not cover.

[KP] The condition of each of the twelve cuspal sub lords (CSLs), reported and gating nothing: the promise verdict is decided by signification alone ('motion_policy' says why, with KSK's pages). Returns '{ chart_info, cusp_conditions: [{ house, csl_planet, csl_extent, csl_combust_star, csl_motion_status }], motion_policy }', twelve rows. 'csl_extent' grades how much of a promise the cusp carries from the dignity of the CSL's star lord (KP Reader 6 canon p.265): '{ planet, planetDignity, starLord, starLordDignity, extent: MOST_SATISFACTORY|SATISFACTORY|ORDINARY|LESS|UNGRADED, gatesVerdict, gradeProvenance, reading, source }', where 'gradeProvenance' says which grades are KSK's words and which the engine's fill. 'csl_combust_star' says whether the CSL stands in a combust (eclipsed) planet's star and, if so, that cusp's result from Reader 6 canon pp.160-161: '{ planet, starLord, starLordCombustion, standsInCombustStar, cuspResult, timing, gatesVerdict, source }'. 'csl_motion_status' is '{ retrograde, combustion: NONE|ORDINARY|FULL, dignity, gates_verdict, delay_signal, note }', and on a retrograde CSL also 'delay_release: { turnsDirect, passesStartingPoint, note }': the natal reading (delivers when it turns direct, Astrology for Beginners canon p.885) and the horary one (Sutra 32, Reader 6 canon p.155, direct and past the degree it turned from), both dated and neither chosen; null for the nodes, which never turn. Retrogression is a delay at the timing phase, never a denial. Use it to read the cusp behind a verdict once rather than on every event row. The same block 'analyze_natal_promise' returns on every event row as 'extent', 'combustStar' and 'motion', keyed there by the event's 'house', with 'motion_policy' once.

Sunil Gondhalekar's Four Step Theory, as a cross-validator. A post-Krishnamurti extension, not KSK's own doctrine. KP treats the Sub Lord as the end-result indicator; Four-Step Theory treats the STAR LORD OF THE SUB LORD as the end-result indicator. Running both side-by-side per cusp produces an agreement signal: STRONG_AGREEMENT (≥75% of cusps agree) → high confidence; PARTIAL_AGREEMENT (50-74%) → moderate; DIVERGENCE (<50%) → borderline reading requiring deeper analysis. Use as a second-opinion layer after analyze_natal_promise.

S.P. Khullar's three-authority KCIL weighted verdict — produces a 0-100 KCIL score per house cusp instead of KP's binary promise/denial. Star Lord (15% weight) proposes, Sub Lord (60%) disposes, Sub-Sub Lord (25%) delivers the end result. Returns per-cusp scores with full lord-level breakdown (housesSignified, supportingHits, denialHits) and an overall score with verdict thresholds (≥70 STRONG_PROMISE, 50-69 MIXED, 30-49 WEAK, <30 DENIED). Use as a continuous-scoring alternative to analyze_natal_promise when you want a graded readout. Accepts an event name OR custom (primary_houses + house_group + denial_group).

[KP and KP extended, side by side, no blend] For one event, KSK's verdict (the promise engine's, per primary cusp) beside the verdicts of three later KP schools, each computed by its own tool's module and never re-weighed: Four Step (Sunil Gondhalekar, the sub lord's star lord decides), KCIL (S.P. Khullar, star lord, sub lord and sub-sub lord), and Bosmia's 6-fold significators filtered by the 7-member Ruling Planets. Where a school's reading differs from KSK's, 'divergence' names THE RULE that makes it differ and the planets it reads against the one KSK reads, so the difference can be checked. Returns '{ event, requiredHouses, denialHouses, primaryHouses, ksk: { school, system, rule, cusps: [{ house, cuspalSubLord, verdict, reading, housesSignified, requiredCovered }] }, schools: [{ school, author, system, rule, cusps: [{ house, verdict, reading, differsFromKsk, lords[], divergence? }], eventLevel? }], differFromKsk[], readingMap, note }'. **No score, no average, no consensus and no count of agreeing schools**: KSK is the KP verdict, the others are successors, and where they differ report both with the rule, never a tally. Measured on 300 chart-events (60 charts, 5 events): Four Step differs from KSK on 66.0%, KCIL on 41.0%, Bosmia on 35.7% (lumin-engine tests/kp-extended/kp-school-spread.test.ts). For a blended figure, get_multi_system_verdict; beyond KP, get_paradigm_panel.

T1+T26: for each of an event's required houses, that cusp's sub lord judged against all the event's houses: which of them it signifies ('coveredRequired'), the share ('coverage', percent) and whether it 'confirms' (50% or more). KSK's rule (KP Reader 5 canon p.195) applied cusp by cusp. The 50% line and the verdict ladder over the confirming share (STRONG at 80%, MODERATE at 50%, WEAK at any, else NONE) are a Lumin convention, labelled in 'scoreProvenance'; this is not the promise verdict, which is analyze_natal_promise. Returns '{ event, requiredHouses, cuspResults: [{ house, cslPlanet, housesSignified, coveredRequired, coverage, confirms }], convergenceCount, totalCusps, convergenceRatio, verdict: STRONG | MODERATE | WEAK | NONE, summary, scoreProvenance }'. The same block 'get_csl_panel' returns as 'multiCuspConvergence'.

Cross-SCHOOL verdict for an event, inside the KP lineage only. Runs orthodox KP CSL analysis, KCIL (Khullar weighted 15/60/25), 4-Step (Sunil Gondhalekar's star-lord-of-sub-lord, per F037), and Bosmia 6-fold (filtered through 7-RP), and returns four normalised verdicts with a consensus band and an average score. **Every number it emits is a Lumin convention and the response says so in 'scoreProvenance'** (F031): averaging four schools presumes they measure one quantity from four angles, and they do not, they differ on which lord carries the authority. For the same comparison with no arithmetic at all, and reaching past the KP lineage to Parashari, Jaimini and Tajik, call 'get_paradigm_panel' instead.

Run Cuspal Sub Lord (CSL) promise analysis across every defined life event. The CSL is the planet ruling the sub-division at a house cusp, KP's deciding factor for whether an event is promised at all. Each row returns the verdict AND the reasoning behind it: '{ event, house, csl, chain, verdict: ACTIVE|MIXED_ACTIVE|PARTIALLY_ACTIVE|DENIED, coverage, reason, required[], covered[], missing[], signifies[], levels: {L1..L4}, starLord, starLordSignifies[], starLordDenial, motion, notes }', plus 'mixed' on a MIXED_ACTIVE row, which is undecided at the cusp (both results operate, each in the dasa of its own significators, KP Reader 4 canon p.184; whether the matter holds is a predominance call KSK makes in prose, Reader 4 canon p.110, and the engine hands it to you with the evidence) and 'bhadhaka' on a longevity-class event. **'motion' reports the CSL's retrograde, combustion and dignity state and gates nothing** — see the response's 'motion_policy'. Paged: read 'pagination.totalItems' and request further pages rather than assuming the first page is everything. Use when: starting any life-area question, and call it BEFORE any timing tool. When the user knows the birth time only roughly, pass 'birth_time_uncertainty_minutes' and each row also carries 'timeStability' ('stable' or 'changes', with 'firstChangeMinutes'), stated once in 'birth_time_window'; a verdict marked 'changes' rests on the birth time and is not settled until it is rectified. The CSL's condition on each row ('extent', 'combustStar', 'motion' with its release dates) and 'motion_policy' are a claim about the CUSP, the same on every event that shares it, and gate nothing; that claim is also a tool of its own, named in 'methodSeams': 'get_csl_condition', one row per cusp. Every row here still carries it.

Reads ONE matter (marriage, career or health) through every system this engine implements and returns them as parallel arguments, never as a verdict. Seven systems: KP, KCIL, Four Step and Bosmia (the KP lineage, which DO define a promise procedure), plus Parashari, Jaimini and Tajik (for which the panel returns no promise verdict; Jaimini states one, argala activated by the sign dasha, which this engine has not implemented). **It is a reader, not a judge.** A system that defines no promise gate returns 'NO_VERDICT_PROCEDURE' with its findings, and a system with no route to the matter returns 'SILENT' with the reason, because manufacturing a Parashari PROMISED to fill a column would be fabricating a tradition's opinion. That is the panel's main finding: KP's distinguishing feature is that it HAS a verdict procedure, while Parashari gives significators rather than a gate and Jaimini's gate (argala) is not yet implemented here, so Jaimini contributes findings only. Tajik reads a YEAR, so it is silent on natal promise until 'target_year' is named, and what it says then is about that year and is not comparable with a natal verdict. Every claim carries a source class ('corpus', 'classical', 'disputed', 'later', 'derived', 'unsourced', 'unattributed', the last meaning standard practice this repo has not pinned to an edition and a locus), and 'unattributedClaimCount' says how many claims in the panel rest on nothing verified. **There is no score, no average, no consensus figure and no vote**: the systems disagree about what a promise is, so a tally would present incommensurable claims as commensurable ones. Instead 'disagreement.type' names HOW they relate (CONCORDANT, CONCORDANT_ON_DIFFERENT_GROUNDS, SPLIT_VERDICT, TIMING_DIVERGENCE, SINGLE_VOICE, NO_VERDICT_TO_COMPARE) and 'sharedGrounds' names the houses and planets two systems literally have in common. Each verdict-bearing reading carries 'grounds', the planets its verdict rests on and the rule that picks them (KP the cuspal sub lord, Four Step that sub lord's star lord, KCIL the cusp's star, sub and sub-sub lords, Bosmia the ruling planets among the significators), and 'disagreement.verdictGrounds' / 'sharedVerdictPlanets' compare them: CONCORDANT_ON_DIFFERENT_GROUNDS means the verdicts agree and no deciding planet is shared. It cannot occur while KP and KCIL are both in the panel, because KCIL's chain holds KP's sub lord; filter 'systems' to see it. Every KP-lineage school reads the same cusps and significator matrix, so even agreement on different grounds is robustness inside KP, not independent confirmation. **Timing** (F091): KP dates the matter by its own rule ('windows': the MD-AD pairs whose lords together signify the whole required group, Reader 4's conjoined periods, independent of today; none when KP denies), and Tajik dates it with 'target_year' (the year from that solar return to the next, when its annual gate opens the matter). Every other system says why it gives no window ('noWindowsBecause'); no window is borrowed across systems. 'disagreement.timing' compares them (NOT_COMPARED, OVERLAP, APART, or YEAR_CLOSED when Tajik's gate closes a year a KP period runs in), and 'type' is TIMING_DIVERGENCE when the verdicts do not split and the dates part, with 'verdictRelation' keeping what the verdicts alone say. So TIMING_DIVERGENCE needs 'target_year'. An overlap is two procedures naming the same stretch of time, not a stronger prediction. Jaimini's 'NO_VERDICT_PROCEDURE' is this engine's gap, not the tradition's: Q032 found argala is its gate, not yet implemented here. Pass 'frames' to cross the panel with the ayanamsa axis and learn which of these conclusions survive a change of zero point. Present the arguments to the user; do not resolve them.

KP 4-level significator matrix linking the 9 planets to the 12 houses they activate. Levels: **L1** = planet in star of house occupant (strongest), **L2** = planet directly occupying the house, **L3** = planet in star of cusp lord, **L4** = planet is the cusp lord. Returns '{ byHouse: { 1..12: [{ planet, level, throughPlanet }] }, byPlanet: { Sun..Ketu: [...] } }'. Use after 'analyze_natal_promise' to drill into WHY a dasha period activates a specific event.

[KP extended, the Four Step lineage] For each cusp of an event, six lords: the cusp's sign, star and sub lords (levels 1 to 3, KSK's, off the 249 table), then the sign, star and sub lords of the SUB LORD'S OWN position (levels 4 to 6). KSK stops at level 3. Level 5, the sub lord's star lord, is Sunil Gondhalekar's Four Step end-result indicator, named on each row as 'fourStepAuthority'. Returns '{ school, author, system, divergencePoint, levels[{ level, name, whose }], event, chains: [{ house, cuspLongitude, level1_signLord .. level6_subLordSubLord, allLevels, uniquePlanets, concentrationScore, fourStepAuthority }], scoreProvenance }'. 'concentrationScore' has no source ('scoreProvenance'). For the Four Step verdict per cusp, get_four_step_verdict.

Parashari, not KP. The Sudarshana Chakra of Brihat Parashara Hora Shastra ch. 74 (Santhanam; ch. 76 in Sharma): three rings of twelve whole-sign bhavas counted from the lagna, from the Moon's sign and from the Sun's sign (vv. 4-6), each bhava judged by the majority of benefic over malefic influences among its occupants and the planets aspecting it by graha drishti, with the lord counting for advancement (vv. 10-14), the Sun taken benefic in a ring's first bhava and malefic elsewhere and an exalted malefic exempted (v. 9). The composite reports, bhava by bhava, whether the three rings AGREE, as a word and never as a score. THE GATE IS APPLIED: vv. 19-20 say the chakra is to be used only when the Sun, the Moon and the lagna are in three different signs, otherwise 'the judgment of effects should be made from the Rasi Kundali only'; 'applicable' and its reason are returned and the rings are still shown. Also returns the Sudarshana dasha of vv. 21-26 (each bhava a year in turn from the first, twelve repeating, and a month within the year) for 'at', defaulting to now, with the assessment lists the verses give for the year-lagna; get_sudarshana_dasha carries the same block, from the same function, laid out as the years of the current round and the months of the current year. v. 13 sends an equal count to strength: every ring bhava that is 'mixed' by count carries 'tieBrokenBy', the advancing side (benefics plus the lord) against the harming side on the BPHS ch. 27 Shadbala in virupas (never the 0-100 index), under TWO readings of 'stronger', both returned and neither picked: raw total virupas, and each planet's total over its own 27.32-33 requirement. 'verdict', 'verdicts' and 'concordant' stay the count reading; 'tieBroken' and 'concordantBhavasTieBroken' give the composite under each reading, and 'tieBreak' counts how many ties each resolved, so a caller sees whether breaking ties moved the agreement. A tie with Rahu or Ketu in it stays mixed, since the nodes have no Shadbala. vv. 15-16 (a benefic in a majority of inauspicious vargas acts as a malefic, a malefic in a majority of auspicious ones as a benefic) are computed in TWO readings, both returned, neither picked: 'shadvarga', the six vargas the printed line names, and 'saptavarga', the seven the commentaries' worked examples count. 'vargaModulation' gives each planet's varga placements with their grounds (own sign, exaltation, a benefic's sign; an enemy's, a malefic's, debilitation), its tally and majority per reading, and per reading the composite re-counted with those natures and the ring bhavas whose verdict moved; how a varga on grounds of both sides is counted is the engine's stated reading ('classingSource', derived), and the nodes are not modulated. vv. 27-28 are QUOTED, not computed ('ashtakavargaCrossCheck'): the chakra's reading and the Ashtakavarga's, in full when they agree, by strength when they differ; how a year's Ashtakavarga reading is taken is stated in no edition. The dasha's months start at each year's own bhava (v. 23, F176 fixed), with the old count from the 1st beside as a labelled legacy field. This is the closest thing Parashari has to a convergence procedure and is the candidate for the panel's Parashari column. Edition stated. Gates no KP verdict. Two blocks are also tools of their own, named in 'methodSeams': 'get_sudarshana_varga_modulation' ('vargaModulation', vv. 15-16) and 'get_sudarshana_dasha' ('dasha', vv. 21-26, with the periods laid out). Call those when a reading needs one claim; this tool returns every block in one call.

Parashari, not KP. BPHS ch. 74 vv. 15-16 (Santhanam; ch. 76 in Sharma): 'a natural benefic loses his benevolence if he is in more malefic vargas; similarly a natural malefic loses his malevolence if he is in more benefic vargas'. Each of the seven planets' varga signs is classed by the verse's grounds (own sign or exaltation auspicious, debilitation inauspicious, otherwise the sign lord's natural nature and naisargika enmity; a varga on grounds of both sides counts on neither, the engine's stated reading, 'classingSource', derived), tallied, and given a majority, under TWO readings, both returned, neither picked: 'shadvarga' (D1, D2, D3, D9, D12, D30, the six the printed line names, classical) and 'saptavarga' (adding D7, the seven the commentaries' worked examples count, later). Per reading, the Sudarshana chakra's vv. 10-14 count is re-run on all three rings with each planet's nature set by its majority, giving the composite and the ring bhavas whose verdict moved against the unmodulated count. Returns '{ applicable, applicabilityReason, origins, vargaModulation: { rule, planets: [{ planet, placements: [{ varga, sign, lord, grounds, side }], byReading: { shadvarga, saptavarga: { auspicious, inauspicious, both, majority } } }], notModulated: { planets, reason }, methodology, readings: { shadvarga, saptavarga: { vargas, source } }, source, byReading: { shadvarga, saptavarga: { composite: [{ bhava, verdicts: { lagna, moon, sun }, concordant }], concordantBhavas, changed: [{ ring, bhava, countVerdict, verdict }] } }, classingSource }, notApplied }'. The nodes are not modulated. The modulated counts are count verdicts: v. 13's tie-break is not re-run on them, and the commentaries' 'medium' grade is not computed ('notApplied'). THE GATE TRAVELS WITH IT: vv. 19-20, 'applicable' with its reason and the three ring 'origins'. Reads no date. No score. Gates no KP verdict. The same block 'get_sudarshana_chakra' returns as 'vargaModulation'.

The natal promise map: for each of the twelve cusps, its sub lord (the CSL), the CSL's own star lord, the houses the CSL signifies through the four levels (L1 to L4, positional status applied), and the verdict on every life event whose primary cusp this is, judged by the SAME gate analyze_natal_promise runs, so the map cannot disagree with that tool. Each matter carries its required and denial houses, the houses covered and the detrimental ones signified. 'signifiedHistogram' counts how many of the twelve CSLs reach each house (a count, never a ranking); 'explains' on each row names the derived-house readings that land on it (the 8th is the 2nd from the 7th, the spouse's wealth; the 6th is the 12th from the 7th, loss of marriage); 'derivedHouses' is the whole table. A MIXED_ACTIVE row is reported exactly as the gate reports it, with no weighing. Retrogression and combustion are reported and gate nothing. Use it to read the whole chart's promise before asking about one matter, and drill into any row with analyze_natal_promise on the event named. Pass 'birth_time_uncertainty_minutes' when the birth time is known only roughly and every matter carries 'timeStability', with 'birthTimeWindow' stating the window once; that flag is the birth-time spread's claim, named in 'methodSeams': 'get_birth_time_spread' with the same window returns each event's row with every interval and its cause. **'rows' is paged by cusp**: 'signifiedHistogram', 'derivedHouses', 'verdictCounts' and 'birthTimeWindow' repeat whole on every page, so walk every page before reading the map as whole.

Full Vimshottari timeline (mahadashas + antardashas) annotated with house significations and event-potential scoring for each period. Returns '{ moonNakshatra, mahadashas: [{ planet, startDate, endDate, signifiedHouses[], themes, isCurrent, eventPotential: [{ event, coverage, subLordGives }], subPeriods: [{ planet, startDate, endDate, signifiedHouses[], isCurrent, eventPotential }] }], queryDateUsed, pagination, pageNote }'. 'eventPotential' lists EVERY group the period lord reaches, with its 'coverage' (the percent of the group's houses the lord signifies), highest first, so a lord that reaches one house of a three house group is an entry at 33, not an omission; a group that is absent is one the lord signifies none of. 'isCurrent' is judged at 'query_date' (default: now), and 'queryDateUsed' says which instant that was and how it was read. **Paged by mahadasha**, each returned whole with its 9 antardashas, so one page is a complete life chapter rather than a partial one; 'queryDateUsed' rides on every page. Every period also names its lord's sub lord and the houses that sub lord signifies, and each 'eventPotential' entry says whether the sub lord reaches that group ('subLordGives'); name an 'event' and every period carries 'subLordJudgement' ('gives | negates | silent', Reader 3 canon p.151, Reader 6 canon p.294). The potentials themselves are this tool's own groups, not KP's. Use when: 'show me my full life timeline' / 'which dasha is best for X?'.

[Vedic alt-dasha adjunct] 108-year cycle, 8 planets (no Ketu): Sun(6), Moon(15), Mars(8), Mercury(17), Saturn(10), Jupiter(19), Rahu(12), Venus(21). Best applied for births during day in Krishna Paksha. Returns each period with start/end dates, current/past/future flags. Cross-validates Vimshottari.

[Lumin extension] The 'Chidra' window of transition and close-out at the end of every mahadasha, under TWO definitions that both ship: the last 1/8 of the mahadasha by time (with a broader last 1/4), and the mahadasha's own last antardasha read off the dasha tree ('lastAntardasha', 5% to 17% of the mahadasha depending on its lords). Returns each MD's windows, current/past/future flags, and 'definitions'. NEITHER HAS A KP SOURCE: the KP Readers have no dasa chidra, and the fixed 1/8 has no stated locus anywhere, so say which definition you used and never present it as a KP rule. Use to advise pausing major launches as a mahadasha approaches its close.

Parashari, not KP. Brihat Parashara Hora Shastra ch. 46 names nine nakshatra dashas beside Vimshottari and says they are 'followed in special cases' (vv. 2-5): Ashtottari, Shodashottari, Dwadashottari, Panchottari, Shatabdika, Chaturashiti-sama, Dwisaptati-sama, Shashtihayani, Shat-trimshat-sama, and gives Yogini (vv. 195-199) with no case. This tool evaluates every one of the text's conditions on the chart (vv. 17-43: Rahu's place from the lagna lord, day or night birth with the paksha, the lagna's hora, the navamsa and dwadasamsa lagna, vargottama, the 10th lord in the 10th, the lagna lord in the 7th or the 7th lord in the lagna per the Sanskrit of v. 38, with Santhanam's English reading reported as a labelled mistranslation variant in 'variantReadings', the Sun in the lagna) and returns 'applicability' for all nine with the verse and the reason, 'applicable' naming those that hold, and a full timeline for each applicable system: starting lord with the counting shown, the balance at birth (v. 16, or vv. 21-22 for Ashtottari), and periods to 120 years. Pass 'system' to get one system's timeline whether or not its condition holds. Shodashottari's two readings are reported separately. Where the text's table gives a nakshatra no lord (Shashtihayani omits Chitra) the timeline says so rather than guessing. Houses are whole-sign, as the text defines them. No effect is emitted. Edition stated (Santhanam 1984; Sharma numbers this ch. 48).

Current running dasha (mahadasha + antardasha + pratyantardasha) annotated with house significations, themes, and percentage-scored event activations. Smarter than raw 'get_dasha_periods', converts MD/AD/PD lords into 'Marriage 100% active, Career 67% active, Travel 33% active' rankings. Returns '{ currentDasha: { md, ad, pd }, activatedHouses[], activeEvents: [{ event, activationPct }], themes[], rulingPlanetSync }'. Each running lord also carries its sub lord's signified houses and each activation group says whether each lord's SUB LORD reaches it ('subLords', 'gives' or 'silent'): KP judges a period lord by its sub lord (Reader 3 canon p.151, Reader 6 canon p.294), and the percentages beside it are this tool's own and unsourced. Name an 'event' for the full sub-lord judgement ('subLordJudgement', 'gives | negates | silent' against the event's required and denial houses). Use when: 'what period am I in?' / 'what's happening in my life now?'.

T7 (unit 5.3.4): when the Mahadasha and Antardasha lords signify an event at different levels (L1/L2 against L3/L4), which one prevails. Returns '{ technique, event, requiredHouses, denialHouses, detail: { mdPlanet, adPlanet, mdRequiredHouses, mdDenialHouses, adRequiredHouses, adDenialHouses, mdLevel, adLevel }, verdict: BLOCKED | PROCEEDS_WITH_OBSTACLES | CLEAR | NO_CONFLICT, explanation, summary }'. The same block 'get_dasha_timing_panel' returns as 'contradiction'.

T6 (unit 5.3.3): whether the running Mahadasha, Antardasha and Pratyantardasha lords sit in one another's nakshatras. Returns '{ technique, mahadasha, antardasha, pratyantardasha, pairs: [{ planetA, planetB, aStarLord, bStarLord, isMutual }], mutualCount, chainInsetCount, threeWayChain, verdict: FULL_STELLIUM | PARTIAL | WEAK | NONE, summary }'. Reads no event. The same block 'get_dasha_timing_panel' returns as 'stellium'.

Dasha timing panel (renamed from get_dasha_advanced on 2026-10-08): stellium detection (mutual nakshatra network between MD/AD/PD lords), contradiction resolution (L1/L2 vs L3/L4 strength when lords conflict), Sookshma-Prana integration (hour-level timing using 4th and 5th dasha levels), and MD junction overlap windows (high-probability timing at mahadasha boundaries). **'sookshmaPrana.peakWindows' is paged**; 'stellium', 'contradiction', 'dashaOverlap' and 'summary' are small and repeat whole on every page, so read the verdicts from page 1 and page on only when you need more hour-level windows. Each of the four techniques is also a tool of its own, named in 'methodSeams': 'get_dasha_stellium', 'get_dasha_contradiction_resolution', 'get_sookshma_prana_windows', 'get_dasha_overlap'. Call those when a reading needs one technique; this tool returns all four in one call.

[RENAMED, use get_dasha_timing_panel] The same tool under its old name, kept for one release so existing callers keep working. It returns exactly what get_dasha_timing_panel returns: stellium, contradiction, sookshmaPrana (paged on peakWindows) and dashaOverlap.

Find which Vimshottari dasha periods reach a specific life event. Lists EVERY antardasha under a mahadasha lord that signifies a required house, each with its own 'coverage' (the percent of the event's required houses the MD and AD lords together signify), 'matchingHouses[]' and 'missingHouses[]', so a period that reaches one house of a three house group is a row with a low coverage, not an omission; the mahadasha lords that signify none are named in 'unlistedMahadashas'. 'confidence' (Strong/Moderate/Weak) is a Lumin cut on coverage, labelled in 'scoreProvenance'. Current periods come first, then future, then past, by coverage within each, a presentation order and not a KP ranking. Returns '{ event, eventLabel, requiredHouses[], totalMatchingPeriods, periods: [{ mahadasha, antardasha, startDate, endDate, coverage, matchingHouses[], missingHouses[], confidence, isCurrent, isFuture }], unlistedMahadashas[], scoreProvenance, queryDateUsed, eventResolution }'. If 'event' is omitted, the engine derives the most active event from the running MD+AD signification with RP tie-break and says which in 'eventResolution', a field a named 'event' does not produce. **Paged by period** when the list does not fit one response (up to 81 rows): 'unlistedMahadashas', 'totalMatchingPeriods', 'scoreProvenance', 'queryDateUsed' and 'eventResolution' (when present) ride on every page, 'pagination' and 'pageNote' say how many pages remain, and nothing is dropped. For 3-level (MD+AD+PD) timing + RP filtering + transit hierarchy, prefer 'find_event_timing_v2'.

Complete 120-year Vimshottari dasha calendar with all 9 mahadashas and their full antardasha sub-periods nested. Returns '{ mahadashas: [{ planet, startDate, endDate, antardashas: [{ planet, startDate, endDate }] }] }'. Heavy payload, use only when full life-timeline export is needed. For event-relevance ranking prefer 'get_annotated_dasha'.

[Jaimini adjunct] 'Chara dasa' names several procedures (F132), and this is the spread across them, none picked and nothing merged: every lineage's whole timeline in 'lineageReadings' (knRao, pvrSjc, raghavaBhattaRangacharya, legacy), each with its rules in words, its source and class, its direction, all its mahadashas with their antardashas where the lineage states them, the current and next period, the running antardasha, what it does not compute and the points its sources leave open; and BPHS ch. 46's own reading of the same dasha in 'bphsReading' (direction from the 9th house's pada; it names its own 'system'). Returns '{ natalAscendantSign, queryDate, lineageReadings: { knRao | pvrSjc | raghavaBhattaRangacharya | legacy: { lineage, label, rules: { sequence, years, exaltation, dualLordedSigns, secondCycle, antardashas }, source, direction, periods, currentPeriod, nextPeriod, currentAntardasha, notComputed, openPoints } }, bphsReading: { system, verses, sequence, periods, currentPeriod, nextPeriod, assumptions }, pagination, pageNote }'. Where the lineages name different signs for the same date, that difference is the content: report it, never a vote. The direction itself is disputed. **The five period lists page together** (each lineage's 'periods' and 'bphsReading.periods'); everything else repeats on every page, so the current periods read from page 1. Takes no chara_lineage: the lineage only chooses which reading 'get_chara_dasha' puts in its own 'periods'. The same blocks 'get_chara_dasha' returns as 'lineageReadings' and 'bphsReading'.

[Jaimini adjunct] Sign-based dasha (rashi cycles). 'Chara dasa' names several procedures, so one timeline is computed PER LINEAGE, each with its rules, source and source class, in 'lineageReadings': knRao (K. N. Rao, Predicting through Jaimini's Chara Dasha: direction from the 9th from the lagna, each sign counted to its lord by its own footedness less one, no exaltation adjustment, his Scorpio/Aquarius rules, second cycle repeated, 12 antardashas with the running sign's own last), pvrSjc (P.V.R. Narasimha Rao 2014, the SJC line: the same count, his co-lord rules, second cycle 12 minus the first, no antardashas stated), raghavaBhattaRangacharya (padakrama order, count from the lord's sign, 10 years for a lord in the 7th, antardashas from the dasha sign; transmitted only through a practitioner blog, labelled modern) and legacy (the rule this tool shipped until 2026-09-28, which no lineage states). 'chara_lineage' picks which fills 'periods', 'currentPeriod' and 'currentAntardasha' (default knRao); 'lineage' names it. The direction itself is disputed. Also returns the BPHS ch. 46 reading as 'bphsReading'. Name the lineage whenever you cite a period. The spread across all four lineages and BPHS, with every lineage's periods whole, is also a tool of its own, named in 'methodSeams': 'get_chara_dasha_spread'. Call it to set the lineages side by side; this tool is the reading of one.

[Parashari, not KP] Kalachakra dasha in the reading where the Moon's pada row IS the nine mahadashas (Santhanam, Raman), the dasha Brihat Parashara Hora Shastra ranks above every other but Vimshottari. Returns the Moon's nakshatra pada, its chakra (savya or apsavya), the pada's nine-rasi row with Deha, Jiva and paramayu (100, 85, 83 or 86), the balance at birth measured all three ways vv. 90-93 give (kalas over 200, ghatikas over a nominal 15, ghatikas over the bhabhoga, the last declared as collapsing into kalas), and the dated schedule: each mahadasha with its nine antardashas (sub-sign years x mahadasha years / paramayu, from the mahadasha's own place in the row, wrapping; they sum to the mahadasha). 'balance_convention' is full-cycle by default, the fraction taken of the whole run, because that is the one reading under which BPHS 46.95's worked example (Krittika at 1s 4 deg 50', 3y 7m 24d of Capricorn) reproduces to the day; first-dasha takes it of the first dasha only, is attested, and is contradicted by that example. Every mahadasha change carries its gati (manduki, markati, simhavalokana, vv. 96-100) READ TWO WAYS, as the pairs the verse names and as the wheel junctions those pairs describe, because the pairs leave two apsavya leaps unnamed; both ship, neither is picked. 'dehaJiva' lists the planets in the Deha and Jiva rasis by sign (vv. 123-128) and emits no result. THE SCHEDULE STOPS AT THE END OF THE PADA'S RUN AND DOES NOT CROSS INTO THE NEXT: how it would is disputed four ways, so a query date past 'runEndsAt' returns 'beyond-the-run' with no dasha. That is common, not an edge case: measured over 200 charts ('lumin-engine/scripts/bp011-kalachakra-spread.ts') this schedule has already stopped at age 40 on 45.5% of charts, mean stopping age 46.2. The rows are read a second way by Raghavacharya (get_kalachakra_raghavacharya_dasha), and the method changes the mahadasha at a query date on 98.1% of (chart, age) pairs, so read get_kalachakra_spread before stating a Kalachakra date. Not a KP tool and never an input to a KP verdict. No effect is emitted. Edition stated (Santhanam 1984; Sharma numbers this ch. 48).

[Parashari, not KP] Kalachakra dasha in Raghavacharya's reading, where the nine-rasi pada rows are ANTARDASHA tables and the mahadashas are the KALACHAKRA NAVAMSAS of the nine padas counted forward from the Moon's, as Vimshottari counts nine nakshatras. The source is Raghavacharya's Kalachakramu (Telugu, 1930) through P.V.R. Narasimha Rao and Sanjay Rath. The Kalachakra navamsa is NOT the D9: each triad of nakshatras lays the twelve signs over its twelve padas, savya zodiacally from Aries, apsavya from Scorpio with Cancer and Leo inverted. Returns the nine mahadashas with the pada each comes from, the first running the unelapsed arc fraction of the Moon's pada, and each mahadasha's nine antardashas from its own pada's row read from the head (sub-sign years x mahadasha years / paramayu, summing to the mahadasha). Every row is its pada divided into nine consecutive Kalachakra navamsas, which is why the head is the start; the mahadasha's own sign need not be in the row at all (Aswini pada 2's Taurus is not). Gatis on every mahadasha change, read two ways as in get_kalachakra_dasha. Source class 'later': the primary is unseen here and the antardasha order and the balance are reconstructed and say so. Stops after the ninth mahadasha; nothing crosses on (mean stopping age 84.9 over 200 charts, 'lumin-engine/scripts/bp011-kalachakra-spread.ts'). Compare it with get_kalachakra_dasha through get_kalachakra_spread, which says which conclusions move between the readings on this chart. **'schedule.mahadashas' is paged**, in order and never cut inside a mahadasha, so each page carries the next mahadashas whole with their nine antardashas; 'balance', 'schedule.transitions' (the gatis), 'schedule.atBirth', 'schedule.atQuery' and the sources repeat on every page, so the running periods at 'query_date' read from page 1. Not a KP tool. No effect is emitted.

[Parashari, not KP] The sibling of get_frame_spread for the Kalachakra METHOD rather than the ayanamsa. Runs all three stated methods on one chart at one date: the Parashara reading with the whole-run balance (classical, BPHS 46.95's example reproduces under it), the Parashara reading with the first-dasha balance (disputed), and Raghavacharya's rows-as-antardashas reading (later). Returns each method's mahadasha at birth with its balance, its mahadasha and antardasha at 'query_date' (or 'before-birth' / 'beyond-the-run'), and the date its schedule stops, plus 'moves' naming which of those four conclusions change between methods and 'holding' naming the ones that do not. 'fractionMethodSpread' adds the balance axis: whether kalas and nominal ghatikas disagree about the dasha at birth. Measured over 200 charts at ages 10 to 70 ('lumin-engine/scripts/bp011-kalachakra-spread.ts'): the mahadasha at birth moves on 94.0% of charts and the mahadasha at a query date on 98.1% of (chart, age) pairs, 97.3% even where all three schedules are still running; the fraction method moves the dasha at birth on only 6.0%. So a Kalachakra date is a statement under a named method and almost never a property of the chart; say which method, or say that they disagree. NOTHING IS SCORED, RANKED, AVERAGED OR VOTED ON and there is no best method. Not a KP tool.

T9: the windows at each Mahadasha junction, the outgoing Mahadasha's last Antardasha against the incoming one's first, and whether both lords signify the event ('isHighProbability'). Returns '{ technique, event, requiredHouses, overlapWindows: [{ outgoingMD, outgoingLastAD, incomingMD, incomingFirstAD, overlapStart, overlapEnd, outgoingADSignifiesRequired, incomingADSignifiesRequired, isHighProbability }], summary }'. The same block 'get_dasha_timing_panel' returns as 'dashaOverlap'.

[Vedic Parashari] Parashari, not KP. The running Vimshottari mahadasha, antardasha and pratyantardasha lords at 'query_date' (default now), read by the Parashari checklist the curriculum names, each fact carrying the provenance of the module that computed it: (a) natural nature (BPHS ch. 34 vv. 8-10, the Moon by phase, Mercury by company), (b) functional nature by lagna, the printed ch. 34 table AND the vv. 2-17 rule side by side, with yogakaraka and maraka, (c) whole-sign placement and the bhavas it owns, (d) the BPHS ch. 27 Shadbala in virupas against the planet's own requirement (never the 0-100 index) and the ch. 45 avasthas, (e) where it stands from the lagna lord, (f) the kendra-trikona LORDSHIP yogas it is part of (Laghu Parashari 14-22 and 18; for a node BPHS 34.17's yogakaraka test), (g) navamsa sign, lord, bhava from the navamsa lagna and vargottama, (h) nakshatra lord and sign dispositor, plus 'vargaLagna', the lord in the 6th, 8th or 12th from the D-10 lagna under both D-10 readings, labelled MODERN (Nemani 2004, Kumaran 2023; no classical locus). For consecutive lords (MD-AD, AD-PD) it returns the whole-sign count from one to the other and back, its class (same sign, kendra, trikona, 2/12, 6/8, 3/11), and natural and temporal friendship reported separately (the compound table is disputed between editions). On the MD-AD pair 'valence' is FIVE STATED READINGS, each with its method note, class and locus, never combined: BPHS pair by pair (San 52-60 / GCS 54-62: the AD lord in a kendra, trikona, 11th or 3rd from the MD lord favourable, 6th, 8th or 12th adverse; the 2nd DISPUTED inside BPHS, favourable in ten verses and adverse at San 59.41, shipped as 'both-stated'), Uttara Kalamrita 6.22 (mutual 6/8 adverse, else good), Phaladeepika 20.29 (6th, 8th or 12th from the MD lord adverse, else good), Phaladeepika 20.28 (the bhukti of the MD lord's or the lagna lord's enemy adverse, each clause tested), and Laghu Parashari 29-31 (relational, no valence: whether the MD lord gives its own results in this bhukti). NO TEXT STATES A MUTUAL 2/12 RULE, so none ships; the AD-PD pair carries no reading because every verse is MD-AD. THERE IS NO OVERALL GOOD OR BAD VERDICT: where the readings disagree, say so and name them. Read each label against 'baseRate' (200 charts, 'scripts/bp025-md-ad.ts'): the MD-AD pair is 6/8 or 2/12 for 30.4% of a life, BPHS and Phaladeepika 20.29 call 21.4% adverse, Uttara Kalamrita 12.5%, the disputed 2nd is 8.9%. Rahu and Ketu as lords carry no Shadbala and no functional row; 'nodeActsThrough' gives the bhava occupied and the conjunct lords (BPHS 34.16), the aspects received (34.17), the dispositor with its classical strength (Uttara Kalamrita 6.16, 6.21), and the aspects cast under every stated node-drishti reading (F175), each with its class. Not computed, and named: named yogas, the compound friendship. **'lords' and 'pairs' are paged together, one lord per page**: page 1 is the mahadasha lord with the MD-AD pair, page 2 the antardasha lord with the AD-PD pair, page 3 the pratyantardasha lord (its 'pairs' empty, and the note says so); 'dasha', 'baseRate', 'houseConvention', 'notComputed' and 'source' repeat on every page. Read all three pages before stating anything about the period. Gates no KP verdict.

Pratyantardasha (sub-sub-period, days) detail for ONE mahadasha, optionally narrowed to one antardasha within it. Returns that mahadasha's full nested tree: every antardasha with each of its pratyantardashas, with start and end dates. **This is the level KP timing actually resolves at.** The 3-lock rule requires the mahadasha, antardasha AND pratyantardasha lords to all signify the event's houses, so a timing verdict built on MD and AD alone is incomplete. 'get_dasha_periods' returns MD and AD for all 120 years; this returns the PD layer underneath one of them, because the whole PD tree for the full cycle does not fit a single response. Call it for the mahadasha your candidate window falls in, which 'get_smart_current_dasha' or 'find_event_timing_v2' will have named.

Parashari, not KP. The ten sign-based dashas Brihat Parashara Hora Shastra gives in ch. 46, each period carrying its verses: Chara in the text's own reading (direction from the 9th house's pada, v. 167; years counted from a rasi to its lord, onwards from a vishama-pada rasi and in reverse from a sama-pada one, the dual-lorded rasis to the stronger lord by the vv. 158-166 ladder, +1 or -1 for an exalted or debilitated planet in the counted-to rasi); Sthira from the Brahma graha's rasi at 7, 8, 9 years by class (vv. 168-173, the Brahma graha's candidates and refusals listed); Yogardha as the mean of the two (v. 174); Kendradi, kendras then panaparas then apoklimas by strength from the stronger of lagna and 7th (vv. 175-177, the lagna-kendradi form some call Narayana); Karaka from the Atmakaraka in karaka order (v. 178); Manduka by jumps of three (vv. 179-180); Shula from the stronger of 2nd and 8th (vv. 181-182); Trikona from the strongest trine (vv. 183-184); Drig by the 9th, 10th and 11th and the rasis they aspect (vv. 185-187); Lagnadi from the lagna advanced by the Moon's nakshatra fraction, with the one balance at birth the text states (vv. 188-190). Every system carries 'assumptions' naming what the text leaves open (Drig and Lagnadi state no year rule, Karaka's count is read inclusive, Manduka's wording does not fit a twelve-rasi jump). Returns the Brahma graha and the BPHS Chara years for all twelve rasis as shared inputs. get_chara_dasha carries the Jaimini Sutras reading and reports this one beside it; neither is picked. **'timelines' is paged when 'system' is omitted**, whole systems in the text's order and never cut inside one, so page N carries the next few of the ten; 'charaYears', 'brahmaGraha' and 'source' repeat on every page. With 'system' passed the one timeline is returned whole and unpaged. Whole-sign houses. No effect is emitted. Edition stated (Santhanam 1984; Sharma numbers this ch. 48).

T8: hour-level timing windows at the fourth (Sookshma) and fifth (Prana) dasha levels. Each window says whether its Sookshma lord, its Prana lord and the transit Moon's star lord at its midpoint signify the event; 'isPeakWindow' is all three at once. Returns '{ technique, event, requiredHouses, moonStarLord, tripleConfirmationCount, peakWindows: [{ sookshmaPlanet, pranaPlanet, startDate, endDate, sookshmaSignifiesRequired, pranaSignifiesRequired, transitMoonStarLord, transitMoonSignifiesRequired, isPeakWindow }], summary, pagination, pageNote }'. **'peakWindows' is paged.** The same block 'get_dasha_timing_panel' returns as 'sookshmaPrana'.

For every active dasha level (MD/AD/PD) returns parallel KP and 4-Step end-result indicators: KP indicator = dasha lord's sub-lord, 4-Step indicator = star lord of the dasha lord's sub lord (Sunil Gondhalekar's Four Step Theory, as get_four_step_verdict reads it); the dasha lord's own star lord is reported separately as 'starLord'. Also includes upcoming Antardasha periods with both indicators. Use to reason about which school's timing prevails on a given event without recomputing the dasha calendar.

Parashari, not KP. The Sudarshana dasha of Brihat Parashara Hora Shastra ch. 74 vv. 21-26 (Santhanam; ch. 76 in Sharma), on its own: each whole-sign bhava from the lagna rules one year in turn from birth, the 1st first, twelve years repeating, and within each year a bhava rules each month. For 'at' (defaulting to now) returns 'dasha' (the year-lagna bhava, the month bhava, the age, and the vv. 24-26 assessment lists read with the year-lagna as the 1st: benefics in kendras, trikonas and the 8th, bhavas held by the nodes alone, benefics in the 6th or 12th, malefics in the 3rd, 6th and 11th), the year-lagna's and month's sign and lord, 'currentRound.years' (the twelve years of the current round with dates) and 'monthsOfYear' (the twelve months of the current year with dates, the first being the year's own bhava: v. 23, 'the antardashas beginning from that', decided by the worked examples of Sharma, the Sudha commentary and P.V.R. Narasimha Rao 2001). The count from the 1st bhava every year, which this tool gave until 2026-09-28, rides beside as 'monthCountFromFirst' and 'monthsOfYearCountFromFirst', labelled unsourced (F176). The 'dasha' block is identical to get_sudarshana_chakra's, computed by the same function; read get_sudarshana_chakra for the three-ring judgement of the bhavas themselves. THE GATE TRAVELS WITH IT: vv. 19-20 say the chakra is used only when the Sun, the Moon and the lagna are in three different signs, and 'applicable' with its reason is returned. 'conventions' states what the verses do not fix: a year is 365.25 days from the birth instant and a month a twelfth of it, the engine's own convention (the commentaries reckon a solar return with solar-ingress months, which is not computed), and the month rule with its sources. Edition stated. No score. Gates no KP verdict.

Compute Vimshottari dasha, KP's 120-year planetary period system. Levels: mahadasha (main period, years), antardasha (sub-period, months), pratyantardasha (sub-sub-period, days). Returns '{ mahadashas: [{ planet, startDate, endDate, subPeriods }], currentDasha: { mahadasha, antardasha, pratyantardasha } }'. **Returns mahadasha and antardasha by default. The full pratyantardasha tree for all 120 years does not fit one response, so for PD detail call 'get_pratyantardasha_periods' for the mahadasha you care about — do NOT skip PD, KP's 3-lock rule needs MD, AD and PD to all signify.** Use when: you only need raw dasha periods. For event-relevance scoring, prefer 'get_smart_current_dasha' or 'get_event_dasha'.

[Vedic alt-dasha adjunct] 36-year cycle, 8 yoginis based on natal Moon's nakshatra: Mangala(1y), Pingala(2), Dhanya(3), Bhramari(4), Bhadrika(5), Ulka(6), Siddha(7), Sankata(8). Returns each yogini period with start/end dates, quality (auspicious/inauspicious), interpretation, current/past/future flags. Cross-validates Vimshottari timing.

Saturn in the 8th sign from the natal Moon (Ashtama Sani, ~2.5 years) and in the 4th (Ardha-ashtama, also called Kantaka Sani), every window across the life, each decomposed into one entry per nakshatra Saturn crosses inside it. **The window is not the verdict.** KP Reader 5 devotes four chapters to saying so: Ch.42 "Is Chandra-Ashtama ever evil", Ch.43 "Chandrashtama and its truth", Ch.45 "Ashtama Sani and Honour", Ch.53 "Traditional Transit System - Meaningless". canon p.290: the blanket adverse reading "is incomplete", because "in which cases Sani is a benefic and in which cases Ashtama Sani is evil, has not been scientifically discussed elaborately"; canon p.286 heads a worked example "the honour and reputation conferred on a Hotel Proprietor and his success in the competition during Ashtama Sani". The KP verdict is chart-dependent and comes from 'starLordWindows[].reading', judged on that star lord's house lordship in THIS chart: signifying 8 or 12 is adverse (canon p.298), 10 or 11 benefic (canon p.297). 'currentStatus' says whether either is running now. A verdict of UNKNOWN means significators were unavailable, so report that there is no KP verdict rather than falling back on the window's name. Companion to 'get_sade_sati_phases', which returns these two families as dates only. Books: KP Reader 5 canon pp.277-290, pp.296-299.

[Lumin extension] Bhrigu Bindu = midpoint of natal Moon and Rahu, a karmic destiny point said to activate when transited by slow planets (Saturn, Jupiter, Rahu, Ketu). It is not in the KP Readers: it is a 20th-century Nadi-lineage point, and the KP star lord, sub lord and Placidus house printed on it are Lumin's overlay, not a KP rule. Returns BB's longitude, sign, house, star/sub lord, and a chronological list of upcoming slow-planet crossings over BB across the next N years (default 10). Framed as karmic windows, not deterministic events; say it is a Lumin extension whenever you use it.

Rule 1 at one moment: for each running dasha lord (Mahadasha, Antardasha, Pratyantardasha at query_datetime, default now), whether a transiting planet falls within 1 degree of the natal position of that lord's sub lord. One row per lord and transiting planet. Reads no event. Returns '{ queryDatetime, dashaTriggers: [{ triggered, dasha_lord, dasha_lord_natal_sub_lord, natal_sub_lord_longitude, transit_planet, transit_longitude, angular_separation, orb_threshold }] }'. The same block 'get_transit_analysis' returns as 'dashaTriggers'.

Locates upcoming solar and lunar eclipses (next N months, default 24) and measures arc-distance from each eclipse degree to natal sensitive points. **THE ECLIPSE IS COMPUTED, NOT SCREENED**: shadow radii, semidiameters, parallax and gamma, so every event carries its 'kind' (solar partial/annular/total, lunar penumbral/partial/total), its 'magnitude', and 'greatestDateUTC', which is the instant of greatest eclipse and differs from the syzygy by up to hours. Verified against all 50 eclipses in NASA's 2000-2010 canon, types included: 24 of 24 solar and 26 of 26 lunar, zero false positives and zero misses. The node-limit filter that used to BE the answer is now only a fast path in front of the geometry. **'countsAs' IS THE FIELD TO READ AND NOTHING HERE DECIDES FOR YOU**: a penumbral lunar eclipse is an eclipse astronomically and very nearly nothing to the naked eye, so each event reports 'astronomical' (any penumbral contact), 'naked_eye' (excludes penumbral lunar) and 'umbral' (the Moon actually enters the dark shadow). Say which convention your reading used. The previous screen enforced the narrow one silently, by using the umbral limit, and so missed 27% of lunar eclipses. Measures arc-distance to natal sensitive points (Lagna, MC, all 9 luminaries / planets). Each natal hit gets a severity band: CRITICAL ≤1°, PROXIMAL ≤5°. Books: KP Reader 5, classical eclipse interpretation. Use to flag windows of intensified life themes; never frame as deterministic prediction.

Cross-references upcoming solar and lunar eclipses with natal cusp sub-lord boundaries. Eclipses landing within 30 arc-minutes of a cusp = CRITICAL activation of that house's significations; within 30 arcmin of a sub-lord boundary = STRONG. Activation window = eclipse date + 6 months. Use to identify specific cusps the next ~18 months will activate.

Computes when transit Jupiter returns to its natal sidereal longitude. ~12-year cycle marks expansion / opportunity waves; canonical first return ~age 12, second ~24, fifth ~60. Each return event includes the primary direct-crossing date, retrograde back-passes if any, duration, and a stage-appropriate interpretation. Books: KP Reader 5.

T15, the scale of minutes: the minutes on one day (target_date, required) when the rising sub lord is one of the event's fruitful significators. Returns '{ event, technique, fruitfulPlanets, targetDate, latitude, geoLongitude, windows[], summary, eventResolution }'. The same block 'get_transit_timing_panel' returns as 'lagnaTransit', which there is null without a target_date.

T14, the scale of hours: the transit Moon's sub-division windows over the next 72 hours from start_date whose lords are the event's fruitful significators. Returns '{ event, technique, fruitfulPlanets, scanHours, windows[], summary, eventResolution }'. The same block 'get_transit_timing_panel' returns as 'moonSubTracking'.

Current Moon position with sign, star lord, sub-lord, and minutes remaining in the current sub. Moon's sub-lord changes every 2-3 hours and is the fastest hand on the KP timing clock. Returns '{ moonLongitude, sign, starLord, subLord, kpNumber, minutesRemainingInSub, nextSubLord, nextSubStartUTC }'. Use for: real-time micro-timing or 'is right now a good moment for X' queries.

T13, the scale of months: the transit nodes over the natal positions of the event's fruitful significators. Returns '{ event, technique, fruitfulPlanets, hits[], summary, eventResolution }'. The same block 'get_transit_timing_panel' returns as 'rahuKetuAxis'.

[KP extended: one state is disputed inside the KP corpus] For each cusp of an event, whether its cuspal sub lord is retrograde and in whose constellation, read the way the pages read it: the sub lord's OWN star lord, with Rahu and Ketu never retrograde (KP Reader 6 canon pp.114, 155). States: NORMAL; STATE_A_DELAYED, retrograde in a direct planet's star, delay until it turns direct and passes its turning point (Reader 6 canon p.155, corpus); STATE_B_DENIAL, retrograde in a retrograde planet's star or its own, which is **disputed**: failure at Reader 6 canon p.155 and Astrology for Beginners canon pp.317-318, delay until the retrograde lord resumes direct course at Astro Secrets canon p.1379 (Astrology and Athrishta, September 1978), both quoted on the entry as 'positions'; STATE_C_SUDDEN, retrograde under 0.05 degrees a day, a labelled Lumin convention (F063). Returns '{ system, systemNote, event, requiredHouses, scope, entries: [{ house, cslPlanet, cslIsNode, cslEngineRetrograde, cslRetrogradeForRule, cslSpeed, cslStarLord, cslStarLordRetrogradeForRule, cslInOwnStar, cuspStarLord, state, stateLabel: { standing, note }, disputed, positions?, stateByCuspStarLord, explanation }], disputedCusps, keyingMoves, summary }'. 'stateByCuspStarLord' is get_retrograde_panel's old keying, so a move is visible. The pages are question charts: on a natal chart this gates no promise (R2). Present STATE_B as both readings, never as a denial.

T10: which of the running Mahadasha, Antardasha and Pratyantardasha lords were retrograde at birth ('retroDashaLords'), and the dates in the scan when transit Jupiter or Saturn comes within 2 degrees of such a lord's natal degree, sampled every 3 days, one hit per pair per 30 days. Reads no event. No source has been found for the rule or the 2-degree orb (the corpus was searched 2026-09-28): present it as the engine's, not KSK's. Returns '{ retroDashaLords, scanStartDate, scanEndDate, hits: [{ dashaLord, natalRetroDegree, transitPlanet, transitDate, transitLongitude, orb }], summary }'. The same block 'get_retrograde_panel' returns as 'retroDashaActivation'.

Retrograde panel (renamed from get_retrograde_advanced on 2026-10-08), three blocks in one call: (1) 'retroCSLThreeState', the 3-state CSL interpretation (delayed/denied/sudden fulfilment by star lord retrogression); (2) 'retroDashaActivation', the dates transit Jupiter or Saturn crosses the natal degree of a running dasha lord that was retrograde at birth; (3) 'stationWindowMapping', the Jupiter and Saturn stations in the scan that fall near the event's significators. Scan range up to 5 years. Returns '{ retroCSLThreeState, retroDashaActivation, stationWindowMapping, summary, methodSeams[] }'. Each block is also a tool of its own, named in 'methodSeams': get_retrograde_csl_states, get_retrograde_dasha_activation, get_station_windows. **Read the CSL states from get_retrograde_csl_states, not from 'retroCSLThreeState'** (F165): this block's STATE_B_DENIAL is disputed in the corpus (failure at KP Reader 6 canon p.155, delay until the retrograde lord turns direct at Astro Secrets canon p.1379), and it keys on the cusp's star lord where the pages key on the sub lord's own. Since F160 it reads Rahu and Ketu as never retrograde, as KSK does (Reader 6 canon p.114); each entry's 'astronomical' carries the old reading (nodes always retrograde) and the state it gives, and 'astronomicalStateDiffers' names the cusps where they part. The keying ships unchanged and 'methodSeams' points at the tool that carries the corrected one. On a natal chart retrogression gates no promise (R2). The station windows are Sutra 32's release (Reader 6 canon p.155); the dasha-lord activation has no source found.

[RENAMED, use get_retrograde_panel] The same tool under its old name, kept for one release so existing callers keep working. It returns exactly what get_retrograde_panel returns: retroCSLThreeState, retroDashaActivation and stationWindowMapping.

Saturn's 7.5-year transit through 12th, 1st, and 2nd signs from the natal Moon, decomposed into the three named phases (Vraya / Janma / Patha) per cycle. Returns each cycle (past + current + future) with absolute start/end dates, current-phase status, days remaining, and auxiliary windows for Ashtama Shani (Saturn in 8th from Moon) and Ardha-ashtama (Saturn in 4th from Moon). The 12th/1st/2nd sign count is the definition KSK himself states at KP Reader 5 canon p.296; only the reading departs from tradition, and the verdict is his star-lord reading (pp.297-299). **The phase name is NOT the verdict.** KP Reader 5 defines the period at canon p.296 and then rejects the traditional reading of it, noting that people marry, get promoted and buy property during Sade Sati: "At the time when they predict adverse results, we enjoy pleasure" (p.297). The KP verdict is chart-dependent and comes from 'starLordWindows', one per nakshatra Saturn crosses inside each phase, each judged on that star lord's house lordship in THIS chart: signifying 8 or 12 is adverse (p.298), 10 or 11 benefic (p.297). 'currentStatus.currentStarLord' gives the live verdict. The traditional adverse reading is retained per phase under 'traditionalReading', tagged 'vedic-parashari' and disclaimed; report it as the traditional view if you use it, never as the KP one. A verdict of UNKNOWN means significators were unavailable, so say there is no KP verdict rather than falling back on the phase name. Books: KP Reader 5 canon pp.296-299, KP Reader 3 ch.51.

Sub-lord-resolved timeline for Saturn's sade-sati transit (the 7.5 year period of Saturn through 12th/1st/2nd from natal Moon), the fine-grained companion to 'get_sade_sati_phases'. Returns per-window '{ startDate, endDate, starLord, subLord, phase, saturnSign, starLordReading, subLordSignifications, subLordAdverse, subLordBenefic }' plus 'verdictCounts'. Read each window on two levels per KP Reader 5 canon p.299: the STAR lord's house lordship in this chart decides what is offered (8 or 12 adverse per p.298, 10 or 11 benefic per p.297), and the SUB lord decides whether it is delivered. **There is deliberately no intensity score.** The previous version returned one, keyed to which planet the sub lord was, so Jupiter scored the same in every chart ever cast; canon p.298 reads a single Saturn transit past nine lagnas to opposite conclusions, because a planet acts through the houses it owns in THIS chart. Sub-lord houses are reported rather than scored because the corpus states that role and gives no arithmetic for it, so weigh them yourself and say you did. Use to map specific months of sade-sati to what is actually promised and whether it lands. Books: KP Reader 5 canon p.296 (the 12th/1st/2nd definition), pp.297-299.

Computes when transit Saturn returns to its natal sidereal longitude, the canonical adulthood / mid-life / elder-stage thresholds (~age 28-30, 58-60, 87-90). Each return event includes the primary direct-crossing date plus any retrograde back-passes (1 or 3 crossings per return), duration in days, and a stage-appropriate interpretation. Books: KP Reader 5, classical Vedic canon.

T12: the days in the scan when Jupiter or Saturn stations ('stationPoints', retrograde or direct, found by a day-by-day change in the direction of motion), and which of the event's significators sit within 3 degrees of a station ('significatorMatches'). The release is Sutra 32 (KP Reader 6 canon p.155: a retrograde planet gives its results once it is direct again and passes the point where its retrograde motion began); the 3-degree orb is the engine's. Returns '{ event, requiredHouses, scanStartDate, scanEndDate, stationPoints: [{ planet, date, longitude, stationType: STATION_RETROGRADE | STATION_DIRECT, speedBefore, speedAfter }], significatorMatches: [{ station, significatorPlanet, significatorLongitude, orb, houses }], summary }'. The same block 'get_retrograde_panel' returns as 'stationWindowMapping'.

Hours until each planet's KP sub-lord changes next, however far off that is (a slow planet's next change can be months away). Sub-lord boundaries are when transit influence shifts. A sign line inside a sub is not a change, because the star and sub lords run across it; it is listed in 'signChangesOnTheWay'. Returns '{ fromDatetime, changes: [{ planet, currentKP, currentStarLord, currentSubLord, nextChangeUTC, nextKP, nextStarLord, nextSubLord, hoursUntilChange, signChangesOnTheWay[], searchCapReached }] }'; 'hoursUntilChange' is -1 only when 'searchCapReached' (three years with no change). For all sub-lord crossings within a date window (with minute-precision binary search) use 'get_transit_crossings'.

All KP sub-lord boundary crossings for the requested planets within a date window (max 366 days). Uses 1-hour coarse scan + binary-search refinement to minute precision. Returns '{ crossings: [{ planet, crossingTimeUTC, fromKP, toKP, fromSubLord, toSubLord, isNakshatraChange, isSignChange }], totalCrossings, planetsSearched, pagination, pageNote }'. **Paged.** A year-long scan of all 9 planets runs to hundreds of crossings, so they come back a page at a time; read 'pageNote' and call again with 'page' incremented until it says it is the last page. Narrowing 'planets' or the date window is usually better than paging through everything.

The four KP transit rules judged per event at one moment, across every event the engine defines: Rule 1 dasha lord trigger, Rule 2 the share of the event's houses the transit star lords offer, Rule 3 the RP overlap, Rule 4 whether the Moon's sub covers the houses; 'verdict' is ACTIVATED / FAVORABLE / PARTIAL / INACTIVE by rules met. 'subLordGate' says whether the sub lords of the offering transits also signify the offered houses, and is deliberately NOT counted in 'rulesSatisfied' (the corpus gives no threshold), so weigh it and say you did. On this route no ruling planets of the moment are passed, so 'rpOverlap.transit_rps' is empty and Rule 3 is never met here. Returns '{ queryDatetime, rpOverlap: { transit_rps, natal_event_significators, overlap_planets, overlap_count, strength }, eventAssessments: [{ event, verdict, rulesSatisfied, housesOffered, coverage, dashaTrigger, rpStrength, rpOverlap, moonSubCovers, subLordGate, notes }], pagination, pageNote }'. **'eventAssessments' is paged**; it takes no 'event', so read 'pagination.totalItems' and page through rather than assuming page 1 holds the event you care about. The same block 'get_transit_analysis' returns as 'eventAssessments' and 'rpOverlap'. Books: KP Reader 5 p.299.

Rule 2 and its company at one moment, before any event: for each transiting planet, the houses its STAR lord signifies natally (WHAT is offered) and those its SUB lord signifies (WHETHER it succeeds), per KP Reader 5 canon p.299; the transits whose star lord is retrograde natally (DELAYED, not denied, so never drop them); the transits within 1 degree of a natal cusp; and the transit Moon's sub. Returns '{ queryDatetime, transitPlanets: [{ planet, transit_longitude, transit_sign, transit_house, transit_star_lord, transit_sub_lord, transit_kp_number, star_lord_significations, sub_lord_significations, houses_activated, speed_deg_per_day, is_retrograde, retrograde_delay, retrograde_delay_reason }], moonTransit: { moon_longitude, moon_sign, moon_star_lord, moon_sub_lord, moon_sub_sub_lord, star_lord_significations, sub_lord_significations, time_remaining_in_sub_minutes, next_sub_lord }, cuspActivations: [{ house, transit_planet, orb, is_applying, interpretation }], retrogradeDelays: [{ transit_planet, transit_star_lord, effect, reason }] }'. The same blocks 'get_transit_analysis' returns as 'transitPlanets', 'moonTransit', 'cuspActivations' and 'retrogradeDelays'. Books: KP Reader 5 p.299.

Single-moment transit snapshot, checks 4 KP transit rules at one point in time, across every event the engine defines. Returns '{ queryDatetime, transitPlanets, moonTransit, rpOverlap, dashaTriggers, cuspActivations, retrogradeDelays, eventAssessments: [{ event, verdict, rulesSatisfied, housesOffered, coverage, dashaTrigger, rpStrength, rpOverlap, moonSubCovers, subLordGate, notes }], pagination, pageNote, methodSeams }'. **A transit whose star lord is retrograde in the natal chart is DELAYED, not denied.** It appears in 'retrogradeDelays' and still contributes every house it offers, so never drop it. KSK: "In Krishnamurti Padhdhati for natal horoscopes there is no place for exaltation, or debilitation or eclipse, or retrograde etc." The matter becomes due when that planet stations direct and re-crosses the degree it turned back from; report the window and the caveat together. **Read a transit on three levels, per KP Reader 5 canon p.299**: the transit STAR lord's house significations are WHAT is offered ('star_lord_significations' on each 'transitPlanets' row, and 'housesOffered' per event), the transiting planet is the SOURCE it arrives through, and the SUB lord decides WHETHER it succeeds ('sub_lord_significations', and 'subLordGate' per event). Do not read the sub lord as subject matter. 'subLordGate' reports whether the sub lords of the offering transits also signify the offered houses; it is deliberately NOT counted in 'rulesSatisfied', because the corpus states the rule but gives no threshold for scoring it, so weigh it yourself and say you did. A matter offered with 'subLordGate.supports = false' is promised but unsupported at the sub. **The event assessments are paged**, each carrying its full per-rule reasoning; this tool takes no 'event' parameter, so read 'pagination.totalItems' and page through rather than assuming page 1 holds the event you care about. Use when: 'what's happening now astrologically?'. For precise event-timing narrowing (Saturn → year, Jupiter → month, Sun → week, Moon → day) use 'get_transit_timing_hierarchy' instead. For triple-confirmation + Lagna minute-prediction use 'get_triple_transit_confirmation' and 'get_lagna_transit_windows' (both also in 'get_transit_timing_panel'). Each of its three steps is also a tool of its own, named in 'methodSeams': 'get_transit_significations' (what the transits offer now), 'get_dasha_lord_transit_triggers' (Rule 1) and 'get_transit_event_assessment' (the verdict per event, paged). Call those when a reading needs one step; this tool returns all three in one call. Books: KP Reader 5 p.299.

KP transit timing hierarchy: Saturn narrows to ~2.5yr window, Jupiter to the year, Sun to the month, Moon to the day. A transit in the star of a RETROGRADE natal planet is a DELAYED window, never an invalid one (F011): it stays in the hierarchy, and since F063 it carries two dated releases, neither chosen: 'turnsDirect' is the NATAL release, when that natal planet next turns direct (Astrology for Beginners canon p.885), and 'passesStartingPoint' is the HORARY one, Sutra 32, when it is direct and has re-crossed the degree it turned back from (Reader 6 canon p.155). The delayed windows are also listed in 'retroDelays', each row with its 'reason', so the delay has a date. Requires fruitful significators internally, selected with the Ruling Planets of the moment of judgement ('judgement_datetime', default now; KP Reader 4), with the birth-moment set beside them as 'atBirth'. The scan starts at 'start_date', by default that same moment of judgement, and 'startDateUsed' says which instant it started from. **A window opens only where the transiting planet's star lord AND sub lord are both fruitful significators**, per KP Reader 5 canon p.195: the star lord says what is offered, the sub lord says whether it materialises. Each window also carries 'offeredFrom', the earlier moment the star lord alone became fruitful. That is when the matter came on offer, NOT when to act: canon p.192 says "do not expect the result on the day of entry, you have to wait till the significator comes to the sub". Quote 'start', not 'offeredFrom', when giving a date. 'judgement.holdsUntil' is the next instant those Ruling Planets change, solved and never a score: 'instant' in UTC, 'local' with the offset in force then only when 'judgement_time_zone' is sent, otherwise with the judgement's own offset (read 'utcOffsetSource'), and 'changes' naming the member (the Ascendant's or the Moon's sign or star lord, or the day lord at sunrise at the place) with its old and new lord. The fruitful set holds until that instant; say so when you quote it. Books: KP Reader 5 canon pp.192, 195.

Transit timing panel (renamed from get_transit_advanced on 2026-10-08): triple transit confirmation (Jupiter star+sub AND Sun sign AND Moon nakshatra simultaneously on significator), Rahu-Ketu axis tracking (amplification/termination over significator positions), Moon sub-division tracking (2-3hr windows over 72hrs), and Lagna minute-level prediction (8-12min windows for exact event timing). The highest resolution KP timing available. Each of the four timers is also a tool of its own, named in 'methodSeams': 'get_triple_transit_confirmation', 'get_rahu_ketu_axis_transit', 'get_moon_sub_transit', 'get_lagna_transit_windows'. Call those when a reading needs one scale; this tool returns all four in one call.

[RENAMED, use get_transit_timing_panel] The same tool under its old name, kept for one release so existing callers keep working. It returns exactly what get_transit_timing_panel returns: tripleTransit, rahuKetuAxis, moonSubTracking and lagnaTransit.

T11, the scale of days: dates when transit Jupiter (by star and sub), the Sun (by sign) and the Moon (by star) fall on the event's fruitful significators at once. Returns '{ event, technique, fruitfulPlanets, matches[], matchesFound, matchesTruncated, summary, eventResolution }'. The same block 'get_transit_timing_panel' returns as 'tripleTransit'.

Traditional Hindu Gochara obstruction check, NOT a KP verdict. Saturn favourable in 3/6/11 from natal Moon with Vedha at 12/9/5; Jupiter favourable in 2/5/7/9/11 with Vedha at 12/4/3/10/8. Returns each slow planet's house from natal Moon, whether the favourable rule applies, whether the Vedha house is occupied (by which planets), the no-Vedha exceptions (Sun-Saturn, Moon-Mercury), and a final verdict (FAVOURABLE_CLEAR / FAVOURABLE_BUT_VEDHA / NEUTRAL / UNFAVOURABLE_HOUSE). Provenance: the rules are transcribed from KP Reader 5 pp.26-28, where they are presented as the Hindu system, and the SAME BOOK rejects them at p.361 as "useless, meaningless and not universally applicable", warning that reproducing them without saying they fail for most people does harm. Report it as the traditional view and say the source disputes it; never let it decide a KP verdict on its own, and prefer get_transit_analysis and get_transit_timing_hierarchy for that. Books: KP Reader 5 pp.26-28 for the rules, p.361 for the rejection.

When a querent asks the same question at multiple distinct moments (different times of day, different days), the significators that appear in every session's fruitful set carry the highest predictive certainty (T17). This tool takes at least 2 session moments and an event and computes the intersection of fruitful significators across sessions. Returns per-session details, ranked consensus list (planet, sessionCount, bestLevel), unanimous and near-unanimous planets, and a verdict: STRONG_UNANIMOUS / STRONG_PARTIAL / MIXED / WEAK.

T18: whether the ruling planets of the moment of judgement agree with the lords of the next dasha periods, one 'entries' row per period. The ruling planets are those of 'judgement_datetime' (default now, at the birth place unless a judgement place is given; KP Reader 4), and the periods are scanned from that same moment. Reads no event. The scan stops at a fixed horizon and 'entriesCap' says so and where the rest are. Returns '{ technique, rankedRPs, entries[], entriesCap, summary, rpMoment, judgement, rulingPlanetsAtBirth, atBirth }': 'judgement' is the instant, place and ruling-planet set used, and 'atBirth' is the same scan against the BIRTH ruling planets (rows, rankedRPs and summary; its 'carries' field says what the rest is), labelled for rectification only. The same block 'get_ruling_planets_panel' returns as 'dashaSyncAnalysis', plus those four judgement fields.

For every event the engine defines, which ruling planets of the MOMENT OF JUDGEMENT also signify the event's houses ('confirming_rps'), and the label 'confirmation_strength' (TRIPLE_CONFIRMED / DOUBLE_CONFIRMED / SINGLE_CONFIRMED / NOT_CONFIRMED). The moment is 'judgement_datetime', default now, at the birth place unless a judgement place is given (KP Reader 4: the planets ruling the moment the matter is judged); the result's 'judgement' says so ('datetimeDefaultedToNow'). Each row's 'csl_verdict' is 'analyze_natal_promise''s verdict for the event, and 'promise_state' names it: promised (ACTIVE, PARTIALLY_ACTIVE), undecided (MIXED_ACTIVE, which is neither promised nor denied), or denied. Only a promised verdict counts toward 'confirmation_strength'; the label is a Lumin ladder (see 'scoreProvenance'), not a KP grade, and says nothing the verdict does not. Returns '{ prediction_confirmations: [{ event, csl_verdict, promise_state, confirming_rps, confirmation_strength, notes }], rpMoment, judgement, rulingPlanetsAtBirth, atBirth, verdictFrom, scoreProvenance, pagination, pageNote }'. 'atBirth' is every row read again with the BIRTH ruling planets, labelled for rectification only; its 'carries' field says what the rest is. **'prediction_confirmations' is paged**, with 'atBirth.prediction_confirmations', page for page. The same block 'get_profession_indicators' returns as 'ruling_planet_applications.prediction_confirmations'.

T16: the event's fruitful significators ranked by their ruling-planet roles, weighted Lagna star lord 5, Moon star lord 4, Lagna sign lord 3, Moon sign lord 2, day lord 1. The weights are a Lumin convention, labelled in 'scoreProvenance'; the RP order applied is in 'orderVariant' and 'orderProvenance'. The significators are filtered by the ruling planets of the MOMENT OF JUDGEMENT (KP Reader 4), which is 'judgement_datetime', default now, at the birth place unless a judgement place is given; the birth set does not rank them. Returns '{ technique, event, requiredHouses, entries[], orderVariant, orderProvenance, scoreProvenance, summary, rpMoment, judgement, rulingPlanetsAtBirth, atBirth }': 'judgement' is the instant, place and ruling-planet set used, and 'atBirth' is the same ranking with the BIRTH ruling planets (rows and summary; its 'carries' field says what the rest is), labelled for rectification only. The same block 'get_ruling_planets_panel' returns as 'strengthHierarchy', plus those four judgement fields.

Ruling Planets (RP) computed at regular intervals over a window (e.g. every 60 min for 24 h), judged at a PLACE: the Ascendant's sign and star lords and the day lord depend on where the judgement is made, so latitude, longitude and utc_offset_minutes are required and name the place of judgement (usually where the querent or astrologer is, not the birth place). Naive datetimes are the local wall clock there. The day lord runs sunrise to sunrise at the place (KP Reader 6); the midnight lord rides beside it as 'civilDayLord'. Returns '{ place, intervals: [{ datetime, localDatetime, weekdayLord, moonSignLord, moonStarLord, ascSignLord, ascStarLord, ranked[], civilDayLord, dayLordDiffersFromCivil }], variant, nodeRule, provenanceNote, dayLordConvention, pagination, pageNote }'. 'variant', 'nodeRule', 'provenanceNote' and 'dayLordConvention' are identical on every sample, so they are returned once at the top rather than repeated per row. **Paged.** Use when: scanning a day or week for the moment whose RP set best matches a target event's significators.

Compute the Ruling Planets (RP) for the moment in the birth fields: the birth moment by default, which is the set used to rectify a birth time, or any judgement moment you pass there instead (for 'now', call 'get_ruling_planets_at_judgement', which takes the clock itself, rather than typing the time into a birth field). By default ('rp_variant: five-member-classic') the five are the weekday lord, the Moon's sign and star lords and the Ascendant's sign and star lords; 'seven-member-with-subs' adds the Ascendant and Moon sub lords. Returns '{ rulingPlanets: { weekdayLord, moonSignLord, moonStarLord, ascSignLord, ascStarLord, ranked[], variant, nodeRule, nodeAdjustments[], provenanceNote, ascSubLord?, moonSubLord? }, retrogradeScreen: { perPlanet[], variants[], variantsDisagree, nodeRule, note }, derived }'; 'ascSubLord' and 'moonSubLord' appear only on the seven-member variant. 'node_rule' decides how Rahu and Ketu join through a sign they occupy (the books substitute a node for the lord of a sign it holds alone). The corpus gives more than one RP list, so read 'variant' and 'provenanceNote' before quoting the set. In KP the dasha governs the event and the RPs select which of its significators fire at a moment; a planet absent from the RPs is a weaker candidate, not a veto on the dasha. **Not every RP is kept.** KSK, Reader 6 canon p.211: reject an RP 'deposited either in the constellation or sub of a retrograde planet'. 'retrogradeScreen' reports that screen in its three corpus forms side by side (Reader 6 star-or-sub; Beginners canon p.319 sub only; Astro Secrets canon p.969 ignore), with a retrograde RP in a direct star and sub kept and dated until it turns direct; 'ranked' is never trimmed. Rahu and Ketu are never retrograde in KP (Reader 6 canon p.114), so an RP in a node's star or sub is never a tempter. Half of all RP sets carry one under the Reader 6 form (50.7%, every 6 h through 2026, 'scripts/bp020-rp-tempters.ts'). Here the moment is whatever the birth fields hold, which through this server is the injected birth moment, the RECTIFICATION set; for the set KP times with, the moment the matter is judged, call get_ruling_planets_at_judgement.

The Ruling Planets of the moment the matter is judged ('judgement_datetime', default now, at the birth place unless a judgement place is given), which is the set KP times with (KP Reader 4 canon p.115: the planets ruling the moment the matter is judged). Same rule, variants and node rules as get_ruling_planets, which run at the birth moment give the set for RECTIFICATION. Returns '{ rpMoment, use, instant, local, place, datetimeDefaultedToNow, placeDefaultedToBirth, rulingPlanets: { weekdayLord, moonSignLord, moonStarLord, ascSignLord, ascStarLord, ranked[], variant, nodeRule, nodeAdjustments[], ... }, fruitfulFilterSet: { ranked[], nodeRule, note } }'. 'fruitfulFilterSet' is the set get_fruitful_significators and find_event_timing_v2 actually filter by at that moment, computed with no node substitution; it differs from 'rulingPlanets' only where the node rule moves a node. 'nodeRuleVariants' states all three node rules for the moment side by side, each with its methodology (what it does, source class, locus, how it differs): 'none' (the fruitful filter's, which no page states for selection, F166), 'books-substitute-when-alone' (Astrology for Beginners canon p.318, Astro Secrets canon p.512) and 'web-always-add' (KSK's own Reader 6 canon p.132, 'Rahu also should be taken as a ruling planet'); the caller's 'node_rule' is marked default. A node rule changes the list on 69.9% of skies (every 6 h through 2026, 'scripts/f166-node-rule-fruitful.ts'). 'holdsUntil' is the next instant one of the five members changes, solved and never a score: 'instant' in UTC, 'local' with the offset in force then only when 'judgement_time_zone' is sent, otherwise with the judgement's own offset (read 'utcOffsetSource'), 'changes' naming the member (the Ascendant's or the Moon's sign or star lord, or the day lord at the next sunrise at the place of judgement) with its old and new lord, 'rankedAfter', and each member's own next change in 'nextChangeByMember'. The set, and the fruitful set filtered by it, holds until that instant; say so when you quote it. The day lord runs sunrise to sunrise at the place of judgement.

Ruling planets panel (renamed from get_rp_advanced on 2026-10-08). Two parts: (1) 'strengthHierarchy', T16: the fruitful significators ranked by their ruling-planet roles, weighted Lagna star lord 5, Moon star lord 4, Lagna sign lord 3, Moon sign lord 2, day lord 1 (a Lumin weighting, labelled in 'scoreProvenance', with the RP order it applied in 'orderVariant' and 'orderProvenance'), read against one event's houses; (2) 'dashaSyncAnalysis', T18: whether the ruling planets ('rankedRPs', planet names) agree with the lords of the next dasha periods, one 'entries' row per period, the scan horizon disclosed in 'entriesCap'. Both parts read the ruling planets of the MOMENT OF JUDGEMENT (KP Reader 4: the planets ruling the moment the matter is judged), which is 'judgement_datetime', default now, at the birth place unless a judgement place is given; the dasha periods are scanned from that same moment. Returns '{ strengthHierarchy, dashaSyncAnalysis, summary, methodSeams, rpMoment, judgement, rulingPlanetsAtBirth, atBirth }': 'judgement' is the instant, place and ruling-planet set used, and 'atBirth' is both parts read again with the BIRTH ruling planets, labelled for rectification only; it holds each part's rows and summary, and its 'carries' field says what the rest of the part is. Each part is also a tool of its own: 'get_rp_strength_hierarchy' and 'get_rp_dasha_sync'.

[RENAMED, use get_ruling_planets_panel] The same tool under its old name, kept for one release so existing callers keep working. It returns exactly what get_ruling_planets_panel returns: strengthHierarchy and dashaSyncAnalysis read with the ruling planets of the moment of judgement ('judgement_datetime', default now), and the birth-set reading beside them as 'atBirth'.

9-fold Tara from natal Moon's nakshatra at any moment: Janma (neutral), Sampat (auspicious), Vipat (avoid), Kshema (auspicious), Pratyari (avoid), Sadhaka (auspicious), Vadha (strongly avoid), Mitra (auspicious), Atimitra (strongly auspicious). Use for 'is today auspicious for X?' daily checks and as a muhurta companion. Books: KP Reader 5 muhurta canon.

Enhanced KP event timing: checks all 3 dasha levels (MD+AD+PD must jointly signify required houses), filters against the Ruling Planets of the moment of judgement (fruitful significators only; 'judgement_datetime', default now, KP Reader 4; the birth-moment set rides beside it as 'atBirth'), integrates transit hierarchy for year/month/day narrowing. Use this instead of find_event_timing for precise, methodologically correct KP timing. Returns '{ event, isPromised, promise, fruitful[], candidatePeriods: [{ md, ad, pd, start, end, coverage, fruitful, confidence, subLordJudgement, strictSelection }], confidenceProvenance, subLordRule, kskSubCleared, candidateOrderings, strictSelectionRule, transitTiming, transitTimingFor, summary, pagination, pageNote }'. 'transitTimingFor' names the candidate 'transitTiming' narrows: the first in list order still running at the moment of judgement, scanned from no earlier than that moment (F260). 'candidateOrderings' states two orders of the same candidates as variants, each a list of 'candidateIndexes' with a methodology note (what it does, its source class and locus, how it differs): 'lumin-confidence', the default and the list's own order, labelled through 'scoreProvenance'; and 'ksk-sub-lord-first', the candidates whose three sub lords all give ahead of the rest, each tier earliest first (Reader 3 canon p.151, Reader 6 canon p.294). Name the order you quote; never blend them. 'promise.coverageGrade' (full/strong/thin/none) is a GRADE: only 'none', the cuspal sub lord reaching no required house, denies (F057; this tool kept a 50% denial until 2026-09-11). 'promise.cslMotion' reports whether the cuspal sub lord is retrograde and, if so, the dates it turns direct and re-crosses its turning degree (F063); reported, gating nothing. **'candidatePeriods' is paged and ordered by 'confidence'**, a Lumin ordering convention and not a KP quantity ('confidenceProvenance' names its weights as unsourced); page on when the user's real-world constraint rules the first windows out. **Read the sub lord before the order.** KSK judges every period lord by its sub lord (Reader 3 canon p.151, Reader 6 canon p.294): each candidate's 'subLordJudgement' gives, for the MD, AD and PD lords, the sub lord, the houses it signifies and 'gives | negates | silent', and 'kskSubCleared' lists the candidates whose three sub lords all give, earliest first, beside the ordered list and never instead of it. On the 48-chart spread 23.6% of candidate periods carry a lord whose sub lord reaches no required house (every candidate, measured 2026-10-08; it read 31.9% over the first ten before that list was uncapped), 24.4% of top-ranked candidates ('scripts/bp019-dasha-sublord.ts'). 'strictSelection' per candidate tests each lord on the two clauses Astrology for Beginners canon p.318 states (posited 6/8/12 to the matter; in the sub of a planet in a detrimental house), reported, removing nothing. Dates are ISO instants. 'judgement.holdsUntil' is the next instant those Ruling Planets change, solved and never a score: 'instant' in UTC, 'local' with the offset in force then only when 'judgement_time_zone' is sent, otherwise with the judgement's own offset (read 'utcOffsetSource'), and 'changes' naming the member (the Ascendant's or the Moon's sign or star lord, or the day lord at sunrise at the place) with its old and new lord. The 'fruitful' flags hold until that instant; say so when you quote them.

[KP extended, Sunil Gondhalekar's Four Step Theory] KSK's fruitful significators (the significators of the event's houses that are also Ruling Planets of the moment of judgement, 'judgement_datetime', default now), reordered inside each level by the Four Step authority: the STAR LORD of each planet's SUB LORD, counting how many required houses it signifies. KSK stops at the sub lord, so this ordering is Gondhalekar's and not KSK's; get_fruitful_significators keeps KSK's own L1 to L4 order. Returns '{ school, author, system, divergencePoint, rule, event, requiredHouses, kskOrder[], fourStepOrder[], orderChanged, rows: [{ planet, level, kskPosition, subLord, subLordStarLord, subLordStarLordSignifies, requiredHousesReached, tiebreakScore, rankWithinLevel }], scoreProvenance, note, rpMoment, judgement, nodeRuleVariants }'. The count is a Lumin ordering convention ('scoreProvenance'), never a strength. Levels are never crossed. Quote it under Gondhalekar's name, beside KSK's order. The ranking orders the fruitful set selected with no node rule; 'nodeRuleVariants' states the other two node rules (Astrology for Beginners canon p.318, substitute when alone; KP Reader 6 canon p.132, add) with the fruitful set each selects, unranked (F166). 'judgement.holdsUntil' is the next instant those Ruling Planets change, solved and never a score: 'instant' in UTC, 'local' with the offset in force then only when 'judgement_time_zone' is sent, otherwise with the judgement's own offset (read 'utcOffsetSource'), and 'changes' naming the member (the Ascendant's or the Moon's sign or star lord, or the day lord at sunrise at the place) with its old and new lord. The fruitful set holds until that instant; say so when you quote it.

Get fruitful significators for an event, meaning planets that appear in BOTH the 4-level significator matrix AND the Ruling Planets of the MOMENT OF JUDGEMENT (KP Reader 4: the planets ruling the moment the matter is judged), which is 'judgement_datetime', default now, at the birth place unless a judgement place is given. L1/L2 (strongest) are prioritized over L3/L4. Returns the fruitful set plus 'rpMoment', 'judgement' (the instant, place and RP set used), 'rulingPlanetsAtBirth' and 'atBirth', the same filter with the BIRTH Ruling Planets, labelled for rectification only. Essential for precise KP timing: only fruitful significators can deliver event results. 'strictSelection' reports KP's selection rule beside the list, never subtracting from it: clause 1, posited 6/8/12 to the matter, and clause 2, in the sub of a planet in a detrimental house, are Astrology for Beginners canon p.318 verbatim; clause 3 (signifies ANY house 6/8/12 from ANY required house) extends a Reader 5 election rule and rejects 86.4% of fruitful significators and every node row on the 48-chart spread ('scripts/bp019-dasha-sublord.ts'), so read it as contested. 'find_event_timing_v2' applies clauses 1 and 2 only, to the period lords. 'fruitfulSignificators' is KSK's list in its L1 to L4 order; the per-entry 'tiebreak' and 'rankedFruitfulSignificators' are Sunil Gondhalekar's Four Step ordering (the sub lord's star lord), not KSK's, and 'methodSeams' points at get_four_step_fruitful_ranking, which carries them under his name. **Node rule, three stated variants.** 'nodeRuleVariants' gives the moment's Ruling Planets under each rule for Rahu and Ketu, each with its methodology (what it does, source class, locus, how it differs) and the fruitful list it selects: 'none', the default this list uses (KSK's worked RP examples name no node, Reader 6 canon pp.138, 211; no page states it for fruitful selection, F166); 'books-substitute-when-alone', get_ruling_planets' default (Astrology for Beginners canon p.318, the fruitful-selection paragraph itself: a node in a ruling planet's sign is included, and preferred to the planet when alone); 'web-always-add' (added beside the planet, KSK's own Reader 6 canon p.132). A node rule changes the fruitful list on 59.7% of chart-event-moments ('scripts/f166-node-rule-fruitful.ts'). 'judgement.holdsUntil' is the next instant those Ruling Planets change, solved and never a score: 'instant' in UTC, 'local' with the offset in force then only when 'judgement_time_zone' is sent, otherwise with the judgement's own offset (read 'utcOffsetSource'), and 'changes' naming the member (the Ascendant's or the Moon's sign or star lord, or the day lord at sunrise at the place) with its old and new lord. The fruitful set holds until that instant; say so when you quote it. Name the rule you quote; the default list is unchanged.

KP horary for "when will X get here" — an awaited person, a spouse returning, a missing person coming home, a letter, or a late train or flight. Takes a question_number (1-249) and a 'subject'. **Two gates, and they do not commute:** the chart must PROMISE arrival before any timing is attempted, and a 'REFUSED' verdict is a complete answer that deliberately carries no window — no amount of favourable timing forces an event the deciding sub lord denies. The rule reads the STAR LORD OF THE DECIDING CUSP'S SUB LORD, not the sub lord itself. Per subject the deciding cusp is: person → 7th, spouse → 11th (joining 11-7-6, separation 12-7-6), missing_person → 11th (promise 2-4-6-11, timed by 2-8-11), letter → 3rd (3 and 11), conveyance → 4th (movable sign reaches soon, fixed a long delay, common a delay). Core rule: the star lord signifying 3/5/9 with 7 or 11 means the person arrives early; 5/7/11 means later but it must signify 3 and 9 without fail; 4/8/10/12 means "the expected person changes his mind and stays back". **Arrival elects on 3-9-11, never the 3-9-12 of foreign settlement** — the 12th pulls toward staying away, so it sits in the refusal set. Returns each house test with its own citation, the obstruction reading for any 6/8/12 link, a retrograde flag (read as DELAY, never denial), and a timing 'scale' from the 11th cusp sub lord's sign modality that names which hand of the clock to move (Ascendant for hours, Moon for days, Sun for longer). The scale is a scale, not a timestamp. Contested points travel in 'provenance.contestedPoints': retrogression in an arrival query is read the opposite way by some practitioners, and this tool does not rotate the chart to the awaited person's house. UNKNOWN means significators were unavailable, so report that there is no verdict. For a lost object or a stolen article use 'get_lost_or_missing' instead; a merchandise parcel is a recovery question (2-6-11), not a letter. Books: KP Reader VI (Horary Astrology), Astrology & Athrishta, KP Ezine case studies. Also returns 'rulingPlanetsVariants' (F185): [KP] KSK's ruling planets from the Ascendant rising at the moment of judgement (Reader 6 canon p.211), the set this tool reads, beside [KP-extended] Prabhakar c.2006's from the number's sign and star lords, reported only; the same block 'get_horary_ruling_planets_variants' returns for this number, moment and place with no query_event, named in 'methodSeams'. The chart is cast at the moment and place the question is judged: send 'judgement_datetime' (the local wall clock there), 'judgement_latitude', 'judgement_longitude', and 'judgement_utc_offset_minutes' or 'judgement_time_zone'. This tool needs no birth data. The result echoes 'horaryMoment' ('instant', 'local', 'place', 'source', 'utcOffsetSource') and 'deprecatedInput', which names any old field name the call used and the field to send instead.

Career horary cast at the moment of the question from a number 1-249, with no birth data: 'judgement_datetime' (the local wall clock there, default now), 'judgement_latitude', 'judgement_longitude', and 'judgement_utc_offset_minutes' or 'judgement_time_zone'. The result echoes 'horaryMoment' ('instant', 'local', 'place', 'source', 'utcOffsetSource') and 'deprecatedInput', which names any old field name the call used and the field to send instead. Seven horary modules shipped before this one and none was career, while KP Reader 6 devotes an entire block with fourteen dated worked cases to it. Fourteen sourced query types, each with its own cusp and gate: 'will_i_get_a_job' (10th, with the nature of work read off the cusp triad, R6 pp.285-288), 'when_promoted' and 'higher_status' and 'seniority_justice' (11th, R6 pp.297-303), 'interview' (11th, the CSL must be in the constellation of a direct planet and signify 3 and 9, R6 p.180 and P3 p.060), 'business_success' (11th for fulfilment and 10th for name, R6 p.295), 'transfer' (3rd, with the P3 p.049 cancellation rule where a 4th CSL signifying the 4th plus an 11th CSL on 1/2/4/10/11 gets the order cancelled and the native retained), 'change_of_job' (10th, R6 pp.306-307), 'reinstatement' (10th, judged on the star lord of the CSL, never granted if it signifies 1/5/9/12, R6 pp.309-310), 'reappointment' and 'competition_selection' (6th, R6 p.317 and the 6-or-10-or-11 win rule), 'will_i_earn' (10th, where a retrograde CSL is an absolute no, R6 p.288), 'foreign_assignment' (12th, which must also signify the 6th to be an assignment, R6 p.311), 'partnership' (7th, with the break matrix: 5+11 permanent, 6+11 take a partner, 6+12 it breaks, 5+8+12 the partner gains and you lose, R6 pp.262-263). The Moon gate runs first and a failure returns verdict WITHHELD, never a negative answer dressed as a result. The gate is the successor literature's (class 'later': L. P. Bhargava, Astrology & Athrishta 1967; K. Subramaniam, Astro Secrets and KP Part II, canon pp.600 and 603); no KSK page withholds a horary on the Moon (Q045), and KSK judges the querent's number as given (Reader 6 canon pp.34-35, p.322). So a WITHHELD result also carries 'judgedAsGiven', the same chart judged under KSK's reading with its own verdict and windows, and 'moonConnectivity.withholdResponse' carries 'source', 'kskPosition' and 'remedies' (Bhargava's re-ask at once; KSK's same number on the day of judgement). 'moonConnectivity.gateReadings' states the Moon gate, the Moon-or-Ascendant-sub-lord gate and KSK's reading, none picked. Rotates the subject lagna by relation for questions about another person's career (R3 p.389). Returns per-query overlays, retrograde gates, dated windows inside the three-year horary horizon, and ruling-planet confirmation. Also returns 'rulingPlanetsVariants' (F185): [KP] KSK's ruling planets from the Ascendant rising at the moment of judgement (Reader 6 canon p.211), the set this tool reads, beside [KP-extended] Prabhakar c.2006's from the number's sign and star lords, reported only; the same block 'get_horary_ruling_planets_variants' returns for this number, moment and place with no query_event, named in 'methodSeams'.

Do the birth chart and the horary chart select the same fruitful significators for the matter? Casts the horary chart from the number (Ascendant fixed at the commencement of its sub, KP Reader 6) at the moment of the question ('judgement_datetime', default now, at the birth place unless 'judgement_latitude'/'judgement_longitude' are given, with 'judgement_utc_offset_minutes' or 'judgement_time_zone'), takes each chart's fruitful significators for the event (significators of its houses that are also that chart's Ruling Planets; the natal set uses the BIRTH Ruling Planets, which is the rectification use), and compares them. Returns '{ technique, queryEvent, requiredHouses, natalFruitfulCount, horaryFruitfulCount, intersectionPlanets, convergenceRatio, convergenceLevel, details: [{ planet, inNatal, inHorary, natalLevel, horaryLevel }], summary, scoreProvenance, horaryAscendant, horaryMoment, deprecatedInput }'; 'deprecatedInput' names any old field name the call used and the field to send instead. A claim about the birth chart: divergence suggests checking the birth time. The ratio divides by the smaller set and the HIGH / MODERATE / LOW bands are unsourced ('scoreProvenance'). Read 'intersectionPlanets' and 'details'. Also returns 'rulingPlanetsVariants' (F185): [KP] KSK's ruling planets from the Ascendant rising at the moment of judgement (Reader 6 canon p.211), the set this tool reads, beside [KP-extended] Prabhakar c.2006's from the number's sign and star lords, reported only; the same block 'get_horary_ruling_planets_variants' returns given the same judgement_datetime, named in 'methodSeams'.

Enhanced KP horary chart with Moon connectivity validation. If query_event is provided, validates whether Moon signifies the relevant houses. If the Moon is disconnected, 'predictionAvailable' is false and a 'withhold' block is returned under the Moon gate: the successor literature reads a disconnected Moon as a question not yet settled in the querent's mind (source class 'later': L. P. Bhargava, Astrology & Athrishta 1967, the earliest; K. Subramaniam, Astro Secrets and KP Part II, canon pp.600 and 603). No KSK page withholds a horary on the Moon (Q045): KSK reads the Moon to name the query (Reader 6 canon pp.177-179, 204-205) and judges the querent's number as given, keeping the same number on the day of judgement (canon p.322). The block carries 'source', 'kskPosition', 'remedies' and 'retryGuidance': Bhargava's re-ask (clarify the query, then another number at once), KSK's same number on the day of judgement, and a fresh number after some time, which is a rule for a failed prediction and not for the Moon (canon p.601). 'gateReadings' states three readings side by side, none picked, each with its 'system', 'source' and whether the chart 'proceeds': [KP-extended] the Moon gate, the one 'withhold' and 'predictionAvailable' follow; [KP-extended] the Moon or the Ascendant sub lord ('Hints for judging a Horary chart', canon p.603, less strict); [KP] KSK's, the number judged as given, which always proceeds. Say which reading you follow. Always provide query_event for proper KP horary analysis. Also returns 'numberMethods': what the number is checked against, as four stated methods side by side, each with its 'system', 'source' class and 'methodologyNote', none picked and none gating 'predictionAvailable'. [KP] KSK: the number is valid in itself, gated only by its range (Reader 6 canon pp.34-35, 114, 279); its lords among the ruling planets strengthen an RP, never test the number. [KP-extended] the Gulbarga short method (M. S. R. Murthy and H. Purushottama, Astrology & Athrishta 1971): the number's sub lord against the Ascendant and Moon star lords of the moment gives positive / probable (ask another number) / negative, with Reader 6's five counter-cases recorded beside it; the KP E-zine 2009 test (the Moon and the Ascendant cuspal sub lord must reflect the question, both readings of 'and'); Prabhakar c.2006's number ruling planets, disputed against Reader 6 canon p.211. 'momentRulingPlanets' are taken from the Ascendant RISING at the moment, not the number's. No source makes the number's agreement with the ruling planets a validity test ('unsourcedClause'), so none is computed. Report each method under its own name. 'rulingPlanetsVariants' carries the two stated definitions of a number chart's ruling planets (F185), each with its 'system', 'source' and 'methodologyNote': [KP] KSK's, from the Ascendant RISING at the moment of judgement (Reader 6 canon p.211, number 100 is Leo while 'the lagna is Dhanus'), which 'chart.rulingPlanets' and every judgement here read; [KP-extended] Prabhakar c.2006's, from the number's sign and star lords, reported and never applied. Name which one you cite. Each of the two spreads is also a tool of its own, named in 'methodSeams': 'get_horary_number_methods' ('numberMethods') and 'get_horary_ruling_planets_variants' ('rulingPlanetsVariants'); both blocks still ship here. The chart is cast at the moment and place the question is judged: send 'judgement_datetime' (the local wall clock there), 'judgement_latitude', 'judgement_longitude', and 'judgement_utc_offset_minutes' or 'judgement_time_zone'. This tool needs no birth data. The result echoes 'horaryMoment' ('instant', 'local', 'place', 'source', 'utcOffsetSource') and 'deprecatedInput', which names any old field name the call used and the field to send instead.

Does the number the querent chose point at the question asked? Casts the horary chart at the moment of the question ('judgement_datetime', default now, at the birth place unless 'judgement_latitude'/'judgement_longitude' are given, with 'judgement_utc_offset_minutes' or 'judgement_time_zone') with the Ascendant FIXED at the commencement of the sub the number names (KP Reader 6), takes that Ascendant's sub lord, and reports which of the event's required houses it signifies in the horary chart. Returns '{ technique, questionNumber, queryEvent, requiredHouses, horaryAscendantLon, subLord, subLordSignifiedHouses, overlapHouses, overlapRatio, verdict, explanation, summary, scoreProvenance, horaryAscendant, horaryMoment, deprecatedInput, numberMethods }'; 'deprecatedInput' names any old field name the call used and the field to send instead. 'verdict' is SELF_CONFIRMATORY at an overlap of 0.67 or more, WEAKLY_CHOSEN above 0, CONTRADICTORY at 0, and **the 0.67 line is unsourced**: Q041 searched the KP Readers, Astrology & Athrishta 1963-1971 and modern KP sources and found nothing for it ('scoreProvenance'). This is not a validity test. KSK holds the number valid in itself, gated only by its range, and no source makes the number agree with the Ruling Planets. 'numberMethods' carries the methods that do exist, side by side, none picked: [KP] KSK's self-validating number with its range gates; [KP-extended] the Gulbarga short method (Murthy and Purushottama, 1971, a yes / probable / no verdict rule, with Reader 6's counter-cases), the KP E-zine 2009 Moon-and-Ascendant test, and Prabhakar c.2006's number ruling planets (disputed). Report the houses, not the label, and each method under its own name. Also returns 'rulingPlanetsVariants' (F185): [KP] KSK's ruling planets from the Ascendant rising at the moment of judgement (Reader 6 canon p.211), the set this tool reads, beside [KP-extended] Prabhakar c.2006's from the number's sign and star lords, reported only. 'numberMethods' and 'rulingPlanetsVariants' are also tools of their own, named in 'methodSeams': 'get_horary_number_methods' and 'get_horary_ruling_planets_variants' return the same blocks given the same judgement_datetime.

What a horary number is checked against, as four stated methods side by side, each with its 'system', 'source', 'alsoAt' and 'methodologyNote', none picked and none gating anything. [KP] 'ksk-self-validating': the number is valid in itself, gated only by its range ('numberValid', 'rangeGates', Reader 6 canon pp.34-35, 114, 279); its lords among the ruling planets strengthen an RP, never test the number ('strengthening'). [KP-extended] 'gulbarga-short-method' (Murthy and Purushottama, Astrology & Athrishta 1971): the number's sub lord against the moment's ruling planets gives 'answerUnderThisMethod' positive / probable-ask-another-number / negative, with 'laterForms' and Reader 6's own 'recordedCases' set against it; 'kp-ezine-2009-radical': the Moon and the Ascendant sub lord must reflect the question ('evaluation', null without query_event, both readings of 'and'); 'prabhakar-number-rps' (c.2006): the number's lords as Ascendant ruling planets, 'disputedBy' Reader 6 canon p.211. Returns '{ questionNumber, numberLords, momentRulingPlanets, methods[4], unsourcedClause, note }'. 'momentRulingPlanets' are taken from the Ascendant RISING at the moment, not the number's. No source makes the number's agreement with the ruling planets a validity test ('unsourcedClause'). Report each method under its own name. The same block 'get_horary_chart_v2' and 'get_horary_number_intuition' return as 'numberMethods'; given the same moment of judgement, the three cast the same chart. The chart is cast at the moment and place the question is judged: send 'judgement_datetime' (the local wall clock there), 'judgement_latitude', 'judgement_longitude', and 'judgement_utc_offset_minutes' or 'judgement_time_zone'. This tool needs no birth data. The result echoes 'horaryMoment' ('instant', 'local', 'place', 'source', 'utcOffsetSource') and 'deprecatedInput', which names any old field name the call used and the field to send instead.

The two stated definitions of a number chart's ruling planets side by side, each with its 'system', 'source', 'alsoAt', 'disputedBy' and 'methodologyNote', never folded together. [KP] 'ksk-moment-ascendant': the day lord, the Moon's sign and star lords, and the sign and star lords of the Ascendant RISING at the moment of judgement (Reader 6 canon pp.210-212: number 100 casts Leo while 'the lagna is Dhanus'); 'readByKpJudgement' true, the set 'chart.rulingPlanets' and every KP judgement on a horary chart read. [KP-extended] 'prabhakar-number-ascendant' (New Dimensions of K.P. Astrology, c.2006): the number's sign and star lords stand in for the Ascendant's; reported, never applied. Each variant carries its 'ascendant' and 'rulingPlanets', and with query_event its 'fruitfulSignificators' for the event (null without one). Returns '{ questionNumber, applied, appliedBecause, variants[2], difference: { onlyUnderKsk, onlyUnderPrabhakar, sameSet, sameRanked, fruitfulSetMoves }, readers, note }'; 'readers' lists every tool that reads a horary chart's ruling planets and which definition it reads. Name which one you cite. The same block 'get_horary_chart_v2', 'get_horary_validation_panel', 'get_horary_number_intuition', 'get_horary_natal_crosscheck', 'get_medical_horary', 'get_career_horary' and 'get_arrival_timing' return as 'rulingPlanetsVariants'; given the same moment of judgement, each casts the same chart. The last three read no event, so call this without query_event, with their judgement_* fields, to match them. The chart is cast at the moment and place the question is judged: send 'judgement_datetime' (the local wall clock there), 'judgement_latitude', 'judgement_longitude', and 'judgement_utc_offset_minutes' or 'judgement_time_zone'. This tool needs no birth data. The result echoes 'horaryMoment' ('instant', 'local', 'place', 'source', 'utcOffsetSource') and 'deprecatedInput', which names any old field name the call used and the field to send instead.

Horary validation panel (renamed from get_horary_advanced on 2026-10-08), on TWO charts: the natal chart from the birth data, and a horary chart cast at the moment of the question ('judgement_datetime', default now, at the birth place unless 'judgement_latitude'/'judgement_longitude' are given, with 'judgement_utc_offset_minutes' or 'judgement_time_zone') with the Ascendant FIXED by the number at the commencement of its sub and the other cusps from the latitude of judgement (KP Reader 6). Returns '{ numberIntuition, crossValidation, summary, horaryAscendant, horaryMoment, deprecatedInput, rulingPlanetsVariants, methodSeams }'; 'deprecatedInput' names any old field name the call used and the field to send instead. 'numberIntuition' checks whether that sub lord signifies the query houses (self-confirmatory vs weakly chosen); 'crossValidation' compares fruitful significators between the two charts (divergence suggests checking the birth time). 'horaryAscendant' and 'horaryMoment' let the cast be checked. The two are different claims, one about the question and one about the birth chart, and each has its own tool (get_horary_number_intuition, get_horary_natal_crosscheck), named in 'methodSeams'; both blocks still ship here. Both thresholds (0.67 for the number, 0.75 / 0.5 / 0.25 for convergence) are unsourced Lumin conventions and say so in 'scoreProvenance'. Also returns 'rulingPlanetsVariants' (F185): [KP] KSK's ruling planets from the Ascendant rising at the moment of judgement (Reader 6 canon p.211), the set this tool reads, beside [KP-extended] Prabhakar c.2006's from the number's sign and star lords, reported only; the same block 'get_horary_ruling_planets_variants' returns given the same judgement_datetime.

[RENAMED, use get_horary_validation_panel] The same tool under its old name, kept for one release so existing callers keep working. It takes the same fields and returns exactly what get_horary_validation_panel returns: numberIntuition, crossValidation, horaryAscendant, horaryMoment, deprecatedInput and rulingPlanetsVariants.

KP horary direction-finding for lost articles, theft, and missing persons. Takes a question_number (1-249) and a query_type ('theft' | 'lost' | 'missing_person'). Returns cardinal direction (E/W/N/S, derived from a planet in Kendhra or lagna fallback), distance class (SAME_PLACE / NEAR / MODERATE / FAR / ABROAD, from 7th significator's sub-lord house), in-house location (gate / middle / backyard, from lagna drekkana), recovery verdict (PROMISED / DELAYED / NOT_RECOVERED / WITHHELD), recovery dasha candidates, and a thief description with stature, age, sex, colour, shape, and whether the thief is a known relative, stranger, or neighbour. All rules grounded in KP Reader VI Slokas 1-4, 47, 49-59 and pages 50, 51, 64, 235, 237, 245. Investigative lens; not a substitute for police investigation in theft or missing-person cases. The 11th CSL's retrograde test reads motion as KP does, Rahu and Ketu never (Reader 6 canon p.114); 'recovery.retrogradeReading' carries the astronomical reading and its verdict beside it (F160). Each claim is also a tool of its own, named in 'methodSeams' and casting the same chart: 'get_lost_article_recovery' (paged), 'get_lost_article_location', 'get_lost_article_nature' and 'get_lost_article_thief'. Call those when a reading needs one; this tool returns every part in one call. The chart is cast at the moment and place the question is judged: send 'judgement_datetime' (the local wall clock there), 'judgement_latitude', 'judgement_longitude', and 'judgement_utc_offset_minutes' or 'judgement_time_zone'. This tool needs no birth data. The result echoes 'horaryMoment' ('instant', 'local', 'place', 'source', 'utcOffsetSource') and 'deprecatedInput', which names any old field name the call used and the field to send instead.

From the horary chart the question_number fixes: whether the article is mineral, wood or root, or a living being, from the lagna sign and the planets in the 1st and 7th (KP Reader 6 page 50, Slokas 52-53), or UNCERTAIN when no condition holds. 'articleNature' is null unless query_type is lost or theft. Returns '{ horaryAscendant, queryType, questionNumber, articleNature: { nature: MINERAL | WOOD_OR_ROOT | LIVING_BEING | UNCERTAIN, rationale } | null, bookCitations, disclaimer }'. 'horaryAscendant', 'queryType' and 'questionNumber' echo the cast it read. The same field 'get_lost_or_missing' returns as 'articleNature'. The chart is cast at the moment and place the question is judged: send 'judgement_datetime' (the local wall clock there), 'judgement_latitude', 'judgement_longitude', and 'judgement_utc_offset_minutes' or 'judgement_time_zone'. This tool needs no birth data. The result echoes 'horaryMoment' ('instant', 'local', 'place', 'source', 'utcOffsetSource') and 'deprecatedInput', which names any old field name the call used and the field to send instead.

From the horary chart the question_number fixes, three coordinates of one place: the direction, from the sign of a planet in a kendra (the 1st first, then 4th, 7th, 10th) or else the lagna sign (KP Reader 6 pages 51 and 64); the distance class, from the house of the sub lord of the first 7th-house significator (page 237: kendra same place, 3rd near, 9th far, 12th abroad, otherwise moderate); and the spot on the premises, from the lagna's drekkana (page 64, Sloka 2: gate, middle, rear). Returns '{ horaryAscendant, queryType, questionNumber, direction: { direction, sourceRule, indicatorPlanet, indicatorSign, rationale }, distance: { distanceClass, seventhSignificator, seventhSigInSubOf, seventhSigSubLordHouse, rationale }, inHouseLocation: { drekkana, location, rationale }, bookCitations, disclaimer }'. 'horaryAscendant', 'queryType' and 'questionNumber' echo the cast it read. The same fields 'get_lost_or_missing' returns as 'direction', 'distance' and 'inHouseLocation'. An aid to a search, not an investigative fact. The chart is cast at the moment and place the question is judged: send 'judgement_datetime' (the local wall clock there), 'judgement_latitude', 'judgement_longitude', and 'judgement_utc_offset_minutes' or 'judgement_time_zone'. This tool needs no birth data. The result echoes 'horaryMoment' ('instant', 'local', 'place', 'source', 'utcOffsetSource') and 'deprecatedInput', which names any old field name the call used and the field to send instead.

From the horary chart the question_number fixes, a description of the thief or the missing person: relation by the lagna's mobility (fixed a known relative, movable a stranger, dual a neighbour; KP Reader 6 Slokas 54-59), age and sex from the 7th cusp sub lord (page 235), stature from the lagna sign (Sloka 47), colour and shape from a 7th-house occupant or else the 7th sub lord (Slokas 49-51). 'thief' is null unless query_type is theft or missing_person. Returns '{ horaryAscendant, queryType, questionNumber, thief: { relation, seventhSubLord, age, sex, stature, appearancePlanetSignal, appearance, seventhHouseOccupants, colour, shape, rationale } | null, bookCitations, disclaimer }'. 'horaryAscendant', 'queryType' and 'questionNumber' echo the cast it read. The same field 'get_lost_or_missing' returns as 'thief'. Never use it to accuse anyone; it is an aid to a search, and the police come first. The chart is cast at the moment and place the question is judged: send 'judgement_datetime' (the local wall clock there), 'judgement_latitude', 'judgement_longitude', and 'judgement_utc_offset_minutes' or 'judgement_time_zone'. This tool needs no birth data. The result echoes 'horaryMoment' ('instant', 'local', 'place', 'source', 'utcOffsetSource') and 'deprecatedInput', which names any old field name the call used and the field to send instead.

From the horary chart the question_number fixes: the 11th cusp sub lord against the recovery houses 2/6/11 and the loss houses 5/8/12 (KP Reader 6 page 235), its retrograde state read as KP reads motion ('recovery.retrogradeReading' carries the astronomical reading beside it, F160), the Moon in the lagna and a benefic in the 11th as confirmations; then the MD-AD-PD periods whose lords signify the recovery houses (page 245), in confidence order (an engine weighting). Returns '{ horaryAscendant, queryType, questionNumber, recovery: { verdict: PROMISED | DELAYED | NOT_RECOVERED | WITHHELD, eleventhCSL, eleventhCSLRetrograde, eleventhCSLSignifies, coversRecoveryHouses, coversLossHouses, moonInLagna, beneficInEleventh, rationale, summary, retrogradeReading }, recoveryDashaCandidates: [{ startDate, endDate, mahadasha, antardasha, pratyantardasha, recoveryHousesCovered, lossHousesCovered, confidence, pattern }], bookCitations, disclaimer, pagination, pageNote }'. **'recoveryDashaCandidates' is paged.** 'horaryAscendant', 'queryType' and 'questionNumber' echo the cast it read. The same fields 'get_lost_or_missing' returns as 'recovery' and 'recoveryDashaCandidates'. An aid to a search; for a theft or a missing person, the police come first. The chart is cast at the moment and place the question is judged: send 'judgement_datetime' (the local wall clock there), 'judgement_latitude', 'judgement_longitude', and 'judgement_utc_offset_minutes' or 'judgement_time_zone'. This tool needs no birth data. The result echoes 'horaryMoment' ('instant', 'local', 'place', 'source', 'utcOffsetSource') and 'deprecatedInput', which names any old field name the call used and the field to send instead.

Canonical KSK disease horary cast at the moment of the question (no birth data): 'judgement_datetime' (the local wall clock there, default now), 'judgement_latitude', 'judgement_longitude', and 'judgement_utc_offset_minutes' or 'judgement_time_zone'. The result echoes 'horaryMoment' ('instant', 'local', 'place', 'source', 'utcOffsetSource') and 'deprecatedInput', which names any old field name the call used and the field to send instead. Rotates the patient lagna by relation (self=1st, child=5th, mother=4th, father=9th, spouse=7th) and reads every house from it: patient (rotated 1st), disease (6th), cure (11th), danger (8th) and hospital (12th) cusp sub lords. Applies the Moon gate first, the successor literature's gate (class 'later': L. P. Bhargava, Astrology & Athrishta 1967; K. Subramaniam, Astro Secrets and KP Part II, canon pp.600 and 603); no KSK page withholds a horary on the Moon (Q045). A failed gate returns verdict WITHHELD with its 'source', 'kskPosition', 'remedies' and 'retryGuidance', never a negative answer, and 'judgedAsGiven' beside it: the same chart judged under KSK's reading, the number as given, with its own verdict, overlay and recovery window. 'moonConnectivity.gateReadings' states the Moon gate, the Moon-or-Ascendant-sub-lord gate and KSK's reading, none picked. Verdict matrix RECOVERY / SLOW_RECOVERY / DETERIORATION / MIXED, plus a query-type overlay (operation success via Mars affliction + 11th CSL star check; severity via 8th-vs-11th weights; diagnosis accuracy via nodes on the 6th chain + Mercury affliction; change of treatment via the rotated 10th CSL), a horary-dasha recovery window, and ruling-planet confirmation. Supplementary lens, not medical advice or diagnosis. Also returns 'rulingPlanetsVariants' (F185): [KP] KSK's ruling planets from the Ascendant rising at the moment of judgement (Reader 6 canon p.211), the set this tool reads, beside [KP-extended] Prabhakar c.2006's from the number's sign and star lords, reported only; the same block 'get_horary_ruling_planets_variants' returns for this number, moment and place with no query_event, named in 'methodSeams'.

For an ongoing situation (court case, prolonged job search, long illness), the practitioner casts horary charts at intervals and tracks how the CSL signification evolves. Pass at least 2 session moments and a topic; the engine casts each session's chart with the Ascendant fixed by that session's number at the commencement of its sub (KP Reader 6), runs the topic CSL verdict, and emits per-session snapshots (verdict, coverage_pct, supporting/detrimental houses, the fixed horary Ascendant and its sub lord, delta vs previous). Trend mapping: OSCILLATING, RESOLUTION_NEAR (coverage trending up, verdict improving), WORSENING (coverage falling, new detrimental houses), STABLE_FAVORABLE, or STABLE_UNFAVORABLE. No birth data: each session is cast at the moment and place that session's question is judged, sent on the session as 'judgement_datetime' (the local wall clock there), 'judgement_latitude', 'judgement_longitude', and 'judgement_utc_offset_minutes' or 'judgement_time_zone'. Snapshots come back in time order, each echoing its 'horaryMoment' ('instant', 'local', 'place', 'source', 'utcOffsetSource', 'timeZone'); 'deprecatedInput' names any old field name a session used and the field to send instead.

[KP] Timing by the ruling planets alone, with NO birth chart and NO horary number: KSK, Reader 6 canon p.211, 'ruling planets help us to give precise predictions regarding any question even in the absence of birth chart.' Takes only the moment and place the matter is judged: 'judgement_datetime' (the local wall clock there), 'judgement_latitude', 'judgement_longitude', and 'judgement_utc_offset_minutes' or 'judgement_time_zone'. Takes the Ruling Planets of that moment from the real sky, screens them for tempters (an RP in the star or sub of a retrograde planet; the three corpus forms are all reported, and Rahu and Ketu are never retrograde in KP), then moves four bodies forward and returns every stretch in which the body's sign lord, star lord and sub lord are all surviving ruling planets. Which body answers which question is canon p.140: the Ascendant for the same day (canon p.139, 'When this position in that sign would rise in the east'), the Moon for days within a month, the Sun beyond a month ('When Sun transits a position in the Zodiac ruled by the ruling planets, the event will fructify'), Jupiter for years. Read the mover whose horizon fits the matter; the tool does not choose it. Sun windows carry 'moonAgrees', the stretches in which the Moon's sign and star lords are ruling planets too (canon p.212's confirmation); Ascendant windows carry 'subSubCells'. No window is picked or scored: where two qualify KSK takes the stronger ruling planet's (canon p.212), and each window names the RP role its lords hold. Defaults follow KSK's two worked examples (canon pp.138, 211): the four-member RP list (day, Moon sign, Moon star, Lagna sign), no node rule, the Reader 6 screen. Checked against both: p.211's delivery comes out Scorpio, Jupiter star, Mars sub in mid-November 1969 (the page's 18th is a day after the engine's window, when the Moon confirms), and p.138's messenger at about 4 P.M. with the screen set aside (under the screen that sky's Sun is a tempter). Returns '{ judgement, rulingPlanets, retrogradeScreen, screenApplied, timingSet[], movers: [{ mover, horizon, windows: [{ from, to, fromLocal, toLocal, sign, signLord, starLord, subLord, roles, retrogradeAtWindow, moonAgrees?, subSubCells? }] }], rules, deprecatedInput, pagination, pageNote }'; 'judgement' carries 'instant', 'local', 'place', 'utcOffsetSource' ('given' or 'time-zone') and 'timeZone', and 'deprecatedInput' names any old field name the call used and the field to send instead. **Paged by mover.** For a question WITH a number, 'get_horary_chart_v2' stays KSK's primary method.

KP auspicious moment triangulation (T40, renamed from get_muhurta_advanced on 2026-10-08), the older three-condition test kept alongside the four-layer election. Walks exact Moon sub and Ascendant sub boundaries for windows where (1) the Lagna sub lord signifies the event houses, and additionally reports whether the Ascendant's sign, star AND sub lords all agree, (2) the Moon's star lord is a fruitful significator, (3) the Day Lord is a fruitful significator. 3 of 3 is fully auspicious, 2 of 3 workable. Returns moments with 'datetime', 'datetimeEnd', 'durationMinutes', 'lagnaFullAgreement', and a 'scanSummary' carrying 'momentsFound' versus 'momentsReturned'; **'moments' is paged**. For a full election prefer 'find_election_window', which applies the dasha layer and carries provenance for the house group.

[RENAMED, use find_auspicious_triangulation] The same tool under its old name, kept for one release so existing callers keep working. It returns exactly what find_auspicious_triangulation returns: moments (paged) and scanSummary.

Elect the moment to start or reopen a business, open a shop, incorporate, or launch a venture. Elects on houses 2, 6, 10 and 11, quoted from Jyotish Astro Secrets p.980: "Whether new or old, business, houses 2,6 and 10 are to be judged. For fortune in business, 11th house has to be included. Even though the significators of 2,6 and 10 may operate in dasa and bhukthi, unless thy have connection with Mars, anything cannot be commenced, as it gives the boldness to take the risk." Check the returned 'significatorSet' for Mars and mention it either way, because the source makes that condition part of the rule. The response also carries 'cuspRule', Reader 6 pp.321-322: "The sub-lord of the 7th is to be deposited in the constellation the lord of which is the significator of the houses 6 and 11." Reported for the reader, not enforced as a filter. ASK FOR THE LAUNCH'S USABLE HOURS AND PASS THEM AS 'preferred_time_of_day'. A shop opens, a market opens, a registrar closes, and KP elects inside the window the world has already fixed. It is the single biggest improvement to this answer. Use this for the act of starting. For whether the business is viable at all, call 'get_business_viability' or 'get_job_vs_business_verdict' first: an elected opening time says nothing about whether the chart promises the venture. Returns '{ event, granularity, windows[], selection, significatorSet, scanSummary, provenanceSummary, relaxations[], cuspRule, disclaimer, summary }'. Each window carries startLocal, endLocal, durationMinutes, layersSatisfied, verdict, resolvingLayer, matchedConditions[], discriminator and rank. There is no score and no top ten. A SECOND SCHOOL CAN CROSS-CHECK THIS, AND YOU SHOULD OFFER IT FOR ANY DATE THAT MATTERS. Pass 'bosmia_lens: true' only after the user agrees. Words that work: a second KP school reads the elected moment from the muhurta chart's own cusps rather than from your birth chart, and I can run it as a cross-check. It is not an upgrade and not a premium option, it is a different school reading the same moment. With it on, each window gains 'bosmiaLens' carrying 'verdict' and a one line 'verdictLine', plus 'checks[]' naming what passed and what did not. The two schools genuinely differ, so a disagreement is expected and is information, not a warning about the date, and where they conflict the KP books decide. It never removes or reorders a moment. Bosmia's own row for starting a business reads the 10th cusp against houses 2, 10 and 11, and he separately treats how long the venture will last, which is the part of his method with no equivalent on the Krishnamurti side. It is worth offering here for that reason. Election in KP is read-only. It locates a moment this chart already points at and it does not cause the venture to succeed. Report windows in startLocal and endLocal, never in UTC.

Elect the moment to sign an agreement, a lease, a deed or any contract. Elects on houses 2, 6 and 11 and excludes 5, 8 and 12, quoted from decoded KP Reader 5 p.229: "During the conjoined periods of such planets, which are not the significators of 5, 8, 12, but they are the significators of 6 and 11 or 2, 6,11, they must bring success and profit." That one sentence carries the elected group and the excluded group together. The response also carries 'cuspRule', Reader 6's "WHICH TIME IS GOOD?" rule for this event, pp.321-322: "The sub-lord of the third cusp is to be deposited fa a cons tellation, the lord of which is the significator of the houses 6 and 11." It is reported for the reader, not enforced as a filter. Pass 'person2' to run the two chart form when both signatories want their charts read. TWO CHART ELECTION IS A LUMIN EXTENSION, NOT KP CANON, and you must say so when you use it: the corpus holds exactly one worked two chart election and it is a single chart election with a post hoc check, with no rule for what to do when the two disagree. With 'person2' each window gains 'secondaryCheck' reading CONFIRMS, PARTIAL or CONTRADICTS. ASK FOR THE SIGNING'S USABLE HOURS AND PASS THEM AS 'preferred_time_of_day'. A registrar, a notary or an office closes, and KP elects inside the window the world has already fixed. It is the single biggest improvement to this answer. Returns '{ event, granularity, windows[], selection, significatorSet, scanSummary, provenanceSummary, relaxations[], cuspRule, disclaimer, summary }', or the joint shape with 'mode', 'primary', 'secondary' and 'extensionNote' when 'person2' is present. Each window carries startLocal, endLocal, durationMinutes, layersSatisfied, verdict, resolvingLayer, matchedConditions[], discriminator and rank. There is no score and no top ten: the single chart form returns ONE moment, or up to three when the tests cannot separate them, while the two chart form returns the wider pool, up to ten, because the second chart still has to filter what the first elected. A SECOND SCHOOL CAN CROSS-CHECK THIS, AND YOU SHOULD OFFER IT FOR ANY DATE THAT MATTERS. Pass 'bosmia_lens: true' only after the user agrees. Words that work: a second KP school reads the elected moment from the muhurta chart's own cusps rather than from your birth chart, and I can run it as a cross-check. It is not an upgrade and not a premium option, it is a different school reading the same moment. With it on, each window gains 'bosmiaLens' carrying 'verdict' and a one line 'verdictLine', plus 'checks[]' naming what passed and what did not. The two schools genuinely differ, so a disagreement is expected and is information, not a warning about the date, and where they conflict the KP books decide. It never removes or reorders a moment. Bosmia's own row for signing reads the 3rd cusp against houses 3, 1, 11 and 7, with 3 or 11 required, so on a contract the two schools read genuinely different house groups and can differ for that reason alone. Election in KP is read-only. It locates a moment this chart already points at and it does not make the counterparty keep the terms. Report windows in startLocal and endLocal, never in UTC.

Elect the moment to begin a journey: the departure itself, not the booking and not the arrival. Elects on houses 3, 9 and 11, quoted from Astrology for Beginners p.786: "the 9th house indicates journey to distant places and the 11 th house shows a successful journey or that it will be pleasant without any mishap." Note the deliberate difference from the promise group. Judging whether foreign travel is promised at all uses 3, 9 and 12. The ELECTION uses 11, not 12, and the two answer different questions. For whether the journey is promised, call 'analyze_natal_promise' or 'get_foreign_settlement'. ASK FOR THE DEPARTURE'S USABLE HOURS AND PASS THEM AS 'preferred_time_of_day'. A train leaves, a flight leaves, a border post opens, and this is the corpus's own habit: KSK elects a Venus sub that "operates between 6.12 and 10.29 a.m." precisely because the train left Madras in the morning. It is the single biggest improvement to this answer. Returns '{ event, granularity, windows[], selection, significatorSet, scanSummary, provenanceSummary, relaxations[], disclaimer, summary }'. Each window carries startLocal, endLocal, durationMinutes, layersSatisfied, verdict, resolvingLayer, matchedConditions[], discriminator and rank. There is no score and no top ten. Election in KP is read-only. It locates a moment this chart already points at and it does not make a journey safe. Report windows in startLocal and endLocal, never in UTC.

Elect the moment for a business meeting, a board meeting, a client pitch or a negotiation. Defaults to houses 3, 6, 9, 10 and 11, quoted from Jyotish Astro Secrets p.912: "Agreement, interview, negotiation, etc. are all denoted by the 3rd house from the 7th, that is the 9th house ... If the negotiations to be successful or useful, 11th house is to be scrutinized ... If it is for business, houses 10 and 6 has to be judged in addition to 3 and 9." 'subject' picks between groups the books state separately, and each is quoted rather than composed: 'business' takes 3-6-9-10-11 from the page above, and 'third_party_approval' takes 3-5-9-11 from decoded Reader 5 p.232 with a second witness at Astrology for Beginners p.798. 'partnership' resolves to the same group as 'business', deliberately: THE CORPUS STATES NO SEPARATE PARTNERSHIP ELECTION. It appeared to until 2026-08-13, when the run-in heading above the 3-6-9-11 sentence on decoded Reader 5 p.233 was found to decode to "To Sign the Letter for Scholarship ?" rather than to anything about partners. That group now belongs to the event it was printed under, and a partnership meeting is elected as a business meeting. If a user asks for a partnership-specific rule, say there is not one. IT IS NOT A COMPOSED RULE, AND NO COMPOSED RULE EXISTS TO IMPLEMENT. A later school, Kanak Bosmia's KP Muhurat, was read in full for this: he gives three worked rows for a discussion, all reading the 3rd cusp, but he never states a general rule that builds a house group out of the 3rd cusp plus the subject's own houses, and two of his three rows leave the subject's own house out of the group entirely. Nothing of that shape is generated here. If a user asks where a meeting rule comes from, this is the honest answer. REPORT THE COUNTERPARTY FRAME. Each window carries 'nativeRisingFrame' with 'natalHouseRising', 'counterpartyHouse' and 'favoursTheNative'. The counterparty house is the native's house minus 6. Astrology for Beginners p.779 gives the mechanism, "the 5th house of the native is the 11 th house of the other person", and p.796 gives the reading that the native's 2, 6 and 11 rising are the moments the other party grants the request, because they are the other party's 8, 12 and 5. Say both numbers when you report a window. ASK FOR THE MEETING'S USABLE HOURS AND PASS THEM AS 'preferred_time_of_day'. Office hours, a board's calendar and a counterparty's diary all fix the window before any chart does, and KP elects inside it. It is the single biggest improvement to this answer. Returns '{ event, granularity, windows[], selection, significatorSet, scanSummary, provenanceSummary, relaxations[], disclaimer, summary }'. Each window carries startLocal, endLocal, durationMinutes, layersSatisfied, verdict, resolvingLayer, nativeRisingFrame, matchedConditions[], discriminator and rank. 'nativeRisingFrame' is null below minute granularity. There is no score and no top ten. A SECOND SCHOOL CAN CROSS-CHECK THIS, AND YOU SHOULD OFFER IT FOR ANY DATE THAT MATTERS. Pass 'bosmia_lens: true' only after the user agrees. Words that work: a second KP school reads the elected moment from the muhurta chart's own cusps rather than from your birth chart, and I can run it as a cross-check. It is not an upgrade and not a premium option, it is a different school reading the same moment. With it on, each window gains 'bosmiaLens' carrying 'verdict' and a one line 'verdictLine', plus 'checks[]' naming what passed and what did not. The two schools genuinely differ, so a disagreement is expected and is information, not a warning about the date, and where they conflict the KP books decide. It never removes or reorders a moment. On a meeting specifically, expect the second school to return 'verdict: NOT_IN_BOSMIA_TABLE', because it has no rule for a business meeting and none was invented. It still reads how long the thing being started is likely to last. Say that plainly rather than presenting it as a failure. Election in KP is read-only. It locates a moment this chart already points at and it does not cause the agreement. Report windows in startLocal and endLocal, never in UTC.

The primary electional tool. Same four-layer KP test as 'find_auspicious_time' but for one event, with a flatter response. Use for any question of the shape when should I do X, what is a good day for X, pick a muhurat for X. ASK FOR THE USER'S USABLE HOURS AND PASS THEM AS 'preferred_time_of_day'. It is the single biggest improvement to an answer here. KP elects inside a window the world has already fixed, an office day, a shop's opening hours, a registrar's appointment, rather than ranking every minute of a week. Returns ONE elected moment, or up to three when the selection tests cannot separate them. No score exists in KP, so nothing is ranked 0 to 100 and there is no top ten. Returns '{ event, granularity, windows[], selection, significatorSet, scanSummary, provenanceSummary, relaxations[], disclaimer, summary }'. 'selection.stageC.orderIsOurChoice' is true and must be honoured when explaining the pick: the five tests are KP's, the order they are applied in is Lumin's. 'windows[].discriminator' says which test decided and is the sentence to quote. 'windows[].resolvingLayer' says what fixed the window, so an hours-wide window is honest rather than a failure. 'windows[].nativeRisingFrame' says which of the native's birth houses is rising and what that house is in the other party's frame, which matters for anything a second party grants or refuses; it is null below minute granularity. Read 'scanSummary.truncated' before reporting a thin result as a thin chart: it may just be a truncated search. A SECOND SCHOOL CAN CROSS-CHECK THIS, AND YOU SHOULD OFFER IT FOR ANY DATE THAT MATTERS. Pass 'bosmia_lens: true' only after the user agrees. Words that work: a second KP school reads the elected moment from the muhurta chart's own cusps rather than from your birth chart, and I can run it as a cross-check. It is not an upgrade and not a premium option, it is a different school reading the same moment. With it on, each window gains 'bosmiaLens' carrying 'verdict' and a one line 'verdictLine', plus 'checks[]' naming what passed and what did not. The two schools genuinely differ, so a disagreement is expected and is information, not a warning about the date, and where they conflict the KP books decide. It never removes or reorders a moment. Report windows in 'startLocal' and 'endLocal', never in UTC, and frame them as the moment the chart already points at rather than as something that will make the outcome go well.

Elect the moment for a property act. 'mode' picks which of three separately sourced house groups applies, and they are genuinely different elections rather than one rule relabelled. 'purchase' (the default) elects on 4, 6 and 11 for buying or registering property, which is Table D's own worked example in Jyotish Astro Secrets p.157: "For example, purchase of house, then, 4-6-11." 'griha_pravesha' elects on 2, 4 and 11 and excludes 5, 8 and 12, for first entering or occupying a house, from decoded KP Reader 5 pp.232-3: "select the sub period of a few hours governed by a planet which is also the significator of the houses 2, 4, and 11" and "Never enter at the time when Moon and ascendant are in the sub ruled bythe significators of 5, 8 and 12." 'foundation' elects on 4 and 11 and excludes 5 and 12, for laying a foundation or breaking ground. THIS ONE IS DERIVED, NOT QUOTED, and its provenance reads DERIVED_CUSP_RULE. KP Reader 6 p.322 states a CUSP SUB LORD test, "The sub-lord of the fourth is to be deposited in the constel lation of the significator of the 11th and not a significator of 5 and 12.", and the house group is those numbers read as houses: the 4th because it is the cusp the rule names, plus the 11th it requires and the 5 and 12 it forbids. It is not Table D either, since the rule names no 6th. Say so if a user asks where it comes from. ASK FOR THE DAY'S USABLE HOURS AND PASS THEM AS 'preferred_time_of_day'. A registrar's counter, a builder's crew and a family gathering all fix the window before any chart does, and KP elects inside it. It is the single biggest improvement to this answer. Returns '{ event, granularity, windows[], selection, significatorSet, scanSummary, provenanceSummary, relaxations[], cuspRule, disclaimer, summary }'. Read 'event' back to confirm which of the three groups ran. Each window carries startLocal, endLocal, durationMinutes, layersSatisfied, verdict, resolvingLayer, matchedConditions[], discriminator and rank. There is no score and no top ten. Election in KP is read-only. It locates a moment this chart already points at and it does not cause the purchase to be sound. Report windows in startLocal and endLocal, never in UTC.

Elect the moment for a surgery or an operation. Elects on houses 1, 5 and 11, which are the CURE houses, not the disease houses. Astrology for Beginners pp.790-791: "11th house which is the 6th from the 6th house, recovery and cure" and "The 5th house, which is the 12th to the 6th house, promises cessation of suffering." This elects toward recovery, not toward the operation. Houses 6 and 8 are the disease and 12 is the hospitalisation: they describe the illness and are not what a treatment is elected on. The corpus also prefers the dasa lord's star day when the dasa lord is a strong benefic (Astrology for Beginners p.792), and its worked cataract election names three candidate star days and flags the likeliest, which is not the earliest. Read 'windows[].discriminator' before assuming the soonest window is the answer. SURGICAL SCHEDULING BELONGS TO THE SURGEON. This is a supplementary lens, not medical advice and not a reason to move, delay or decline a procedure. Say that in the same breath as any window. If the clinical timing is fixed, that decides it, and no elected moment overrides it. Never use it to argue against an urgent or emergency operation. ASK FOR THE THEATRE'S USABLE HOURS AND PASS THEM AS 'preferred_time_of_day'. Operating lists have hours, and KP elects inside the window the world has already fixed. It is the single biggest improvement to this answer, and it is also what keeps the output inside what the hospital can actually offer. For whether recovery is promised and when, call 'get_cure_window', 'get_surgery_success' or 'get_medical_timing'. Those answer a different question from this one. Returns '{ event, granularity, windows[], selection, significatorSet, scanSummary, provenanceSummary, relaxations[], disclaimer, summary }'. Each window carries startLocal, endLocal, durationMinutes, layersSatisfied, verdict, resolvingLayer, matchedConditions[], discriminator and rank. There is no score and no top ten. Election in KP is read-only. It locates a moment this chart already points at and it does not cause the outcome of the surgery. Report windows in startLocal and endLocal, never in UTC.

Elect the moment for a marriage ceremony. Elects on houses 2, 7 and 11: the 7th is the marriage itself, the 2nd the family it forms, the 11th the fulfilment of the desire. SAY WHERE THAT GROUP COMES FROM IF ASKED, because it is not a wedding muhurta rule. The corpus states no electional house group for a wedding anywhere. 2, 7 and 11 is its marriage JUDGEMENT group, printed as prose at Astrology for Beginners p.312 ("for marriage, houses 2, 7, 11 are beneficial"), as a list row at p.313, and applied to natal marriage timing at decoded Reader 4 p.127 ("Houses 2, 7 and 11 are judged."). The election reuses it. The one worked wedding election in the corpus, Jyotish Astro Secrets pp.139-142, uses no house group at all: it elects from the bride's dasa chain and the Lagna touching her natal Moon. Read 'provenanceSummary.quoteNote' for this in the response. ASK FOR THE COUPLE'S USABLE HOURS AND PASS THEM AS 'preferred_time_of_day'. A wedding is booked inside a hall's hours, a registrar's appointment or a family's plan, and KP elects inside a window the world has already fixed rather than ranking every minute of a week. It is the single biggest improvement to this answer. Pass 'person2' to run the two chart form. TWO CHART ELECTION IS A LUMIN EXTENSION, NOT KP CANON, and you must say so when you use it: the corpus holds exactly one worked two chart election in 6,465 pages and it is a single chart election with a post hoc check of the second chart, with no rule for what to do when the two disagree. With 'person2' the response gains 'secondaryCheck' per window, reading CONFIRMS, PARTIAL or CONTRADICTS, plus 'extensionNote'. Returns '{ event, granularity, windows[], selection, significatorSet, scanSummary, provenanceSummary, relaxations[], disclaimer, summary }', or the joint shape '{ mode, primary, secondary, windows[], scanSummary, provenanceSummary, extensionNote, disclaimer, summary }' when 'person2' is present. Each window carries startLocal, endLocal, durationMinutes, layersSatisfied, verdict, resolvingLayer, matchedConditions[], discriminator and rank. There is no score. KP has no numeric strength for a moment, so nothing is ranked 0 to 100 and there is no top ten. The single chart form returns ONE moment, or up to three when the selection tests cannot separate them. The two chart form deliberately returns the wider pool instead, up to ten, because the second chart still has to filter what the first elected: order matters there and 'rank' 1 is the elected moment. Quote 'discriminator' for why a moment won, and read 'resolvingLayer' before quoting a width, since an Ascendant-sub election is minutes wide and a Moon-sub election is hours wide. A SECOND SCHOOL CAN CROSS-CHECK THIS, AND YOU SHOULD OFFER IT FOR ANY DATE THAT MATTERS. Pass 'bosmia_lens: true' only after the user agrees. Words that work: a second KP school reads the elected moment from the muhurta chart's own cusps rather than from your birth chart, and I can run it as a cross-check. It is not an upgrade and not a premium option, it is a different school reading the same moment. With it on, each window gains 'bosmiaLens' carrying 'verdict' and a one line 'verdictLine', plus 'checks[]' naming what passed and what did not. The two schools genuinely differ, so a disagreement is expected and is information, not a warning about the date, and where they conflict the KP books decide. It never removes or reorders a moment. Bosmia's own row for a wedding reads the 7th cusp of the muhurta chart against houses 2, 7 and 11, so on a wedding the two schools start from the same houses and differ only on which chart they read. Election in KP is read-only. It locates a moment this chart already points at and it does not cause the marriage or its quality. Report windows in startLocal and endLocal, never in UTC.

Elect the moment for a competitive examination. Elects on houses 4, 9 and 11, quoted from KP Reader 6 p.189: "For competitive examination the houses to be judged are 4, 9 and 11 ... whether one is appearing for the first attempt or the second or the third, ever we have to judge the houses 4, 9 and 11." Defaults to day granularity, because that is the resolution the question usually has. READ THIS BEFORE CALLING. An exam date is normally fixed by the board, and KP cannot move it. What is electable is the act the candidate controls: submitting the application or registration, choosing between offered sittings or centres, or the departure for the hall. It does not elect the studying, and no elected moment substitutes for preparation. If the date is already fixed and only the hour is open, say so and use 'rank_candidate_dates' or 'find_election_window' on the fixed date instead. ASK FOR THE CANDIDATE'S USABLE HOURS AND PASS THEM AS 'preferred_time_of_day'. Exam halls and application portals both have hours, and KP elects inside a window the world has already fixed. It is the single biggest improvement to this answer. Returns '{ event, granularity, windows[], selection, significatorSet, scanSummary, provenanceSummary, relaxations[], disclaimer, summary }'. Each window carries startLocal, endLocal, durationMinutes, layersSatisfied, verdict, resolvingLayer, matchedConditions[], discriminator and rank. There is no score and no top ten: one moment comes back, or up to three when the selection tests cannot separate them. Election in KP is read-only. It locates a moment this chart already points at and it does not cause the result. Report windows in startLocal and endLocal, never in UTC.

Elect the moment for an interview, or for any request put to a person who can grant or refuse it. Elects on houses 2, 6 and 11 of the native, quoted from Astrology for Beginners p.796: "if an interview is sought on one of the star days of these significators and when any of the houses 2, 6 or 11 or the native is rising on the eastern horizon, th e other person will grant the request of the native." REPORT THE COUNTERPARTY FRAME, IT IS THE POINT OF THIS TOOL. Each window carries 'nativeRisingFrame' with 'natalHouseRising', 'counterpartyHouse' and 'favoursTheNative'. The counterparty house is the native's house minus 6, and it is why the group is 2, 6 and 11 and not some other three: those are houses 8, 12 and 5 of the person being asked. Astrology for Beginners p.779 states the mechanism, "the 5th house of the native is the 11 th house of the other person", and names the reading of the native's 6th, "the native's 6th house is the house of loss to the other". Say both numbers when you report a window. ASK FOR THE INTERVIEW'S USABLE HOURS AND PASS THEM AS 'preferred_time_of_day'. An interview slot is offered, not chosen freely, and KP elects inside the window the world has already fixed. It is the single biggest improvement to this answer. The corpus's own limit case, and repeat it: an elected interview time buys a patient hearing and sympathetic consideration. It does not buy the job. Returns '{ event, granularity, windows[], selection, significatorSet, scanSummary, provenanceSummary, relaxations[], disclaimer, summary }'. Each window carries startLocal, endLocal, durationMinutes, layersSatisfied, verdict, resolvingLayer, nativeRisingFrame, matchedConditions[], discriminator and rank. 'nativeRisingFrame' is null below minute granularity, where no Ascendant was resolved and there is no rising point to read. There is no score and no top ten. Election in KP is read-only. It locates a moment this chart already points at and it does not cause the decision. Report windows in startLocal and endLocal, never in UTC.

List every electable event with its elected house group, its principal house, the houses it excludes, its default granularity, and its PROVENANCE. Takes no birth data. Call this before guessing an event string. Provenance is one of four values. BOOK_SOURCED means the corpus states this electional group for this matter, with the citation attached. WEB_SOURCED means a published KP source outside the books. DERIVED_TABLE_D means the group was generated by the corpus's own general formula, the matter's houses plus 6 and 11. DERIVED_CUSP_RULE means the corpus states a CUSP SUB LORD rule for this matter and the group was read off that rule, which is a different claim: "the sub lord of the 2nd cusp must stand in the star of a significator of 6 and 11" is not the sentence "elect on the significators of 2, 6 and 11". Both DERIVED values carry a derivation string. Each citation also carries 'quoteKind': VERBATIM (one sentence reproduced exactly), JOINED_SENTENCES (two or more consecutive sentences, the join stated rather than elided), TABLE_ROW_NO_PROSE (the rule is printed as a table row or numbered list item, so there is no sentence to quote), or NONE. 'quoteNote' says what the quote does and does not establish, and it is where a citation admits that it names a different house list than the row elects on. Read it before repeating a quote. Repeat these distinctions when a user asks where a rule comes from, and never present a derived group as a quoted one.

Elect a moment for one or more events by the KP four-layer test, across a real date range at the place the event happens. Layer 1 builds the significator set for the event's houses; layer 2 requires the running Dasa or Bhukti lord to be in that set; layer 3 requires the Moon to transit the star then the sub of a set member, which fixes the day and then the hours; layer 4 requires the Ascendant's sign lord, star lord AND sub lord all to be in the set, which fixes the minute. Returns ONE elected moment per event, or up to three when the selection tests genuinely cannot separate them. It is not a top ten list and there is no score: KP has no numeric strength for a moment, so candidates are compared one test at a time and the first difference decides. Returns '{ events: { eventLabel: { windows: [{ startLocal, endLocal, durationMinutes, layersSatisfied, verdict, resolvingLayer, resolvingLayerNote, dasha, moon, ascendant, matchedConditions[], exclusionsCleared[], selectionKeys, discriminator, rank }], selection, significatorSet, scanSummary, provenanceSummary, relaxations[], disclaimer } } }'. 'discriminator' says which test decided, and is printed for the winner and for any runner-up. 'resolvingLayer' says what fixed the window and therefore what its width means: an Ascendant-sub election is minutes wide, a Moon-sub election is hours wide. Do not quote a fixed window width. 'layersSatisfied' is 1 to 4 and is the longest satisfied prefix, so a 2 means the Moon layer failed and nothing below it is being claimed. 'relaxations' names any layer that had to be loosened. 'provenanceSummary' says whether the house group is quoted from the KP books or generated by the general formula, the matter's houses plus 6 and 11. Election is read-only in KP: it locates a moment the chart already points at and never causes an outcome. Say so when reporting a window. Prefer 'find_election_window' for a single event, and 'rank_candidate_dates' when the user already has dates in mind.

The user names 2 to 10 dates they can realistically do, and this ranks them by the same four-layer KP test. This is the shape a real scheduling conversation takes and it is far cheaper than an open search. Prefer it whenever the user has already mentioned specific dates. Returns '{ rankedDates: [{ rank, dateLocal, layersSatisfied, verdict, bestWindow, windowsOnDay, reason }], significatorSet, provenanceSummary, disclaimer, summary }'. 'bestWindow' carries the ONE moment elected on that date, with its own 'discriminator'. There is no score: dates are ordered by the same ordered comparator the single-date surface uses, so the two can never disagree.

Elect a moment against two charts, for a wedding, a jointly signed contract, a co-purchase, or an IVF transfer. IMPORTANT, SAY THIS WHEN YOU USE IT: two chart election is a LUMIN EXTENSION, not KP canon. The KP corpus contains exactly one worked two chart election in 6,465 pages and it is a single chart election with a post hoc check of the second chart, with no rule at all for what to do when the two disagree. The default mode 'single-chart-with-check' reproduces that pattern: the moment is elected from the primary chart, then the secondary chart is evaluated at the same instant and reported as CONFIRMS, PARTIAL or CONTRADICTS. The 'both-charts-must-agree' mode returns only mutually confirmed windows and is our invention. Returns '{ mode, primary, secondary, windows: [{ ...window, secondaryCheck: { layersSatisfied, agreement, note } }], extensionNote, disclaimer, summary }'.

[Cross-system composite: KP, Parashari yoga karaka, Jaimini Amatyakaraka; every block names its system in 'blockSystems[]', and only the kp blocks belong in a KP verdict] Atomic comprehensive career analysis for career-coaching B2B. Bundles: CSL promise verdict (Career) + 8-category career signature + profession description (industry/sector/employment-mode) + job-change-vs-promotion timing + lagna yoga karaka + Jaimini Amatyakaraka + pre-verdict audit. Returns '{ promiseVerdict, careerSignature, professionNature, jobChangeVsPromotion, yogaKaraka, jaiminiAmatyakaraka, preVerdictAudit, synthesis, blockSystems[] }'. Saves 7 round-trips per reading.

Atomic comprehensive matrimonial matching for matrimonial-platform B2B. Reports THREE compatibility columns side by side, which answer different questions: 36-pt Vedic Ashta Koota (Varna+Vashya+Tara+Yoni+Graha-Maitri+Gana+Bhakoota+Nadi, Parashari, which KP Reader 4 rejects), KP-rigorous 6-CSL-factor (LOVE/MARRIAGE/FINANCE/UNION/DENIAL/DASHA-SYNC, with KSK's six individual-chart prerequisites), and the Jaimini Upapada Lagna relationship, plus the Parashari Manglik check on both partners. Returns '{ ashtaKoota, kpRigorousCompatibility, manglikCheck, upapadaLagnaRelationship, synthesis: { systems[], disagreementType, overallVerdict, confidenceBand, crossSystemConcordance: STRONG|PARTIAL|DIVERGENT, scoreProvenance } }'. Read 'synthesis.systems' per column; the concordance, verdict and band are a count of three flags, a labelled Lumin convention, not a consensus any of the three systems makes. The matrimonial flagship workflow. In the Ashta Koota the user's own chart is scored as the groom and the partner as the bride (see get_ashta_koota_milan's groomConvention).

[Cross-system composite: KP, Parashari, Jaimini; every block names its system in 'blockSystems[]', and only the kp blocks belong in a KP verdict] Atomic comprehensive marriage analysis for matrimonial-platform B2B. Bundles: CSL promise verdict ('analyze_natal_promise' for Marriage) + spouse characteristics + Manglik dosha + Upapada Lagna (Jaimini) + vargottama strength multipliers + second-marriage check + DBA timing windows + pre-verdict audit. Returns '{ promiseVerdict, spouseCharacteristics, manglikDosha, upapadaLagna, vargottamaSummary, secondMarriagePromise, timingWindows[], preVerdictAudit, synthesis, blockSystems[] }'. Saves 8 round-trips per reading.

[Cross-system composite: KP, Tajik, Parashari] Atomic year-outlook composite for annual-subscription B2B products. Bundles: 12-month annual forecast (KP, the calendar target year) + Tajik Varshaphala (solar return + Muntha) + Tithi Pravesha (soli-lunar return) + 5 key Sahams (Punya/Yasas/Karya/Karya-Siddhi/Vivah, on the annual chart as keySahams[] and on the natal chart as keySahamsNatal[]) + Yogini dasha + Ashtottari dasha + Sade Sati phases + eclipse impacts. EVERY dated block reads the target year (F157): the Tajik year from its solar return to the next, with the dashas and Sade Sati read at the return (or at query_date when it falls inside that year), every Yogini, Ashtottari and Sade Sati period overlapping the year listed, and the eclipse scan starting at the return; 'readDates' names each instant. 'blockSystems[]' names each block's system and method note. 'yearTone' is a Lumin ladder over Tajik, Parashari and eclipse instruments, labelled by 'synthesis.scoreProvenance', not a verdict any system makes. Returns '{ targetYear, varshaphala, tithiPravesha, keySahams[], yoginiCurrent, yoginiInYear[], ashtottariCurrent, ashtottariInYear[], sadeSatiStatus, sadeSatiInYear[], eclipseImpacts[], readDates, blockSystems[], synthesis: { yearTone: GROWTH|CONSOLIDATION|CAUTION|TRANSFORMATION, scoreProvenance, topMonths[] } }'. Saves 8 round-trips per annual report.

[Cross-system composite: KP sub-lord boundaries and combustion, Parashari graha yuddha and vargottama; only the boundary flags move the band] Pre-flight integrity check before any final verdict (Pattern E). Reads the KP sub-lord boundary flags ('get_boundary_warnings') and turns ONLY those into a confidence modifier (0 to -20) and band HIGH/MODERATE/LOW, a Lumin convention labelled by 'scoreProvenance': it measures whether a small birth-time error could flip a cuspal sub lord. Also reports, under 'reportedOnly', combustion (KP: gates nothing, a combust planet still gives its results) and graha yuddha and vargottama (Parashari, not KP); none of the three moves the band. Returns '{ flags, confidenceModifier, confidenceBand, scoreProvenance, reportedOnly[], recommendations[], summary }'.

Atomic spiritual / soul-purpose reading. Runs Atmakaraka identification → D9 → Karakamsa → 12th-from-Karakamsa → Ishta Devata + D20 + past-life karmic + Bhrigu Bindu in one call. Returns '{ atmakaraka, karakamsa, twelfthFromKarakamsa, ishtaDevata: { primaryDeity, mantra }, d20Spirituality, pastLifeSummary, bhriguBinduDestiny, houseFrames, spiritualPath, blockSystems[] }'. Jaimini-led: the D20 is Parashari, the past-life panel a later cross-system synthesis and the Bhrigu Bindu a modern construct, and 'blockSystems[]' names each. House numbers: 'wholeSignHouse' fields are the Jaimini (whole-sign) houses; 'natalHouse', 'saturnHouse' and 'bhriguBinduDestiny.house' are KP Placidus bhavas, as 'houseFrames' says. Pattern C. Per Sanjay Rath 'Crux of Vedic Astrology' + Jaimini Sutras.

[Cross-system composite: Parashari muhurta with KSK's hora and the Moon's KP position] Atomic daily-outlook composite for daily-content / lifestyle B2B apps. Bundles: Choghadiya (8 day + 8 night auspicious 1.5-hr periods) + Tara Bala (9-fold from native's nakshatra), both Parashari, + Hora (24 unequal planetary hours, KSK's, Reader 3 canon pp.524-527) + the Moon's KP sign, star and sub lord + next-auspicious-window list, every block read at the one query moment. 'blockSystems[]' names each block's system. 'overallToneToday' counts the auspicious flags of Choghadiya, hora and tara, a Lumin convention labelled by 'synthesis.scoreProvenance'; the KP instrument for a moment is the ruling planets (get_ruling_planets), which this composite does not vote. Returns '{ weekday, sunriseUTC, sunsetUTC, currentChoghadiya, currentHora, taraBala, moonTransit, nextAuspiciousWindows[], blockSystems[], synthesis: { overallToneToday: FAVOURABLE|MIXED|CAUTIOUS, scoreProvenance } }'. Saves 5 round-trips per daily refresh.

[Cross-system: KP Vimshottari, Parashari Yogini, Jaimini Chara, side by side] Where the DATE RANGES of three dasha systems overlap. Only the Vimshottari input is chosen for the event (the MD-AD periods whose lords signify its required houses, ranked from query_date); the Yogini and Chara inputs are the current and next period whatever the event, and Yogini starts from the Moon's nakshatra exactly as Vimshottari does, so the three are NOT independent witnesses. 'convergenceLevel' counts overlaps (STRONG = a triple overlap; PARTIAL = two or more Vimshottari-Yogini overlaps; WEAK = one; DIVERGENT = none), a Lumin convention labelled by 'scoreProvenance', and 'baseRate' gives how often each level occurs for this event over a fixed 200-chart sample: STRONG is met by most charts whatever the event (F089), so read the level against it and never as confirmation or confidence. 'inputs[]' names each system with its selection rule and method note; 'independence' names what they share. Named after K.N. Rao's practice of reading an event in more than one dasha; his convention reads the Chara dasha for the matter, which this tool does not. The Chara witness is K. N. Rao's Chara dasha by default ('charaLineage' names it; 'chara_lineage' picks another); other lineages can name a different sign. Returns '{ vimshottariWindows[], yoginiCurrent, yoginiNext, charaCurrent, charaNext, charaLineage, convergenceWindows: [{ startDate, endDate, systemsAgreeing: 2|3 }], convergenceLevel, scoreProvenance, baseRate, inputs[], independence, summary }'. For timing compared by each system's own procedure, get_paradigm_panel with target_year.

[Vedic kundli-match adjunct] 36-point Vedic Guna Milan: Varna(1) + Vashya(2) + Tara(3) + Yoni(4) + Graha-Maitri(5) + Gana(6) + Bhakoota(7) + Nadi(8). Returns each koota's score with description and 'source', total /36, score band (EXCELLENT/GOOD/AVERAGE/POOR; the 33/25 cuts are a Lumin convention named in 'scoreProvenance', 18 is the traditional minimum), Nadi-Dosha and Bhakoot-Dosha flags (Bhakoot covers 2/12, 6/8 and 5/9), 'ganaVariant' (Gana's cross scores are disputed, so the other reading and its total are given), and 'groomConvention': the user's own chart (person1) is scored as the GROOM and the partner as the bride, and Varna, Tara, Bhakoota and Yoni are directional. Yoni marks pairs KP Reader 4 names inimical. Designed for matrimonial-platform B2B embeds. NOTE: KP Reader 4 explicitly rejects Porutham; use get_compatibility_panel for KP-rigorous compatibility (CSL-based).

KP-based 7-factor compatibility analysis between two charts. Factors: Moon compatibility, Venus-Mars attraction, Jupiter harmony, sub-lord matching, dasha sync, dignity match, and aspect harmony. Returns '{ overallScore (0-100), factors: [{ name, score, weight, details }], verdict: EXCELLENT|GOOD|AVERAGE|POOR }'. For KP-rigorous 6-CSL-factor analysis (which explicitly REPLACES Vedic Porutham) use 'get_compatibility_panel'. For traditional 36-point Vedic Guna Milan use 'get_ashta_koota_milan'.

C1: the five cuspal sub lord factors read across both charts, each chart's sub lord against its house group: LOVE (5th into 2/5/11), MARRIAGE (7th into 2/7/11), FINANCE (2nd into 2/11), UNION (11th into 2/7/11), DENIAL_ABSENCE (the 7th CSL clear of 6/8/12). Reads no period. Each 'score' is an engine construction (each partner up to 50, F006). KSK's gate travels with it: 'individualPrerequisites' names his six individual-chart points (canon pp.20-21) and the tool for the four this does not cover, and 'prerequisiteNote' says why they come first. Returns '{ factors: [{ factor, score, verdict, person1Coverage, person2Coverage, rationale }], individualPrerequisites, prerequisiteNote, bookCitations, framesUsed }'. The same rows 'get_compatibility_panel' returns as the first five of 'factors'.

C10: every period of a week or more when both partners run Mahadasha and Antardasha lords that signify 7 or 11, earliest first, each with its 'confidence' (an engine figure from the overlap length) and rationale; and 'dashaSyncFactor', the DASHA_SYNC row read off those windows (window count plus total overlap days, an engine construction, F006). A shared-timing claim; the promise factors are 'get_couple_csl_factors'. Returns '{ dashaSyncWindows: [{ fromDate, toDate, person1Mahadasha, person1Antardasha, person2Mahadasha, person2Antardasha, confidence, rationale }], dashaSyncFactor: { factor, score, verdict, person1Coverage, person2Coverage, rationale }, individualPrerequisites, prerequisiteNote, bookCitations, framesUsed }'. The same blocks 'get_compatibility_panel' returns as 'dashaSyncWindows' and the sixth row of 'factors'.

Tests 8 weighted KP signals (5th CSL signifies 7+12, 7th CSL signifies 5+8, Venus+Mars in {5,7,8,12}, Rahu in 5/7/12, and others) and emits a riskBand NONE/LOW/MODERATE/NOTABLE/HIGH for the native's own self-reflection. Sensitive lens; B2B counselor-tooling only and strictly opt-in. Never disclose to a partner or third party; KP signatures describe predisposition only, never behaviour, and conscious choice dominates outcome.

KP-rigorous compatibility for two partners (renamed from get_compatibility_advanced on 2026-10-08). Replaces Vedic Porutham (which KP rejects per Reader 4) with 6 factors: LOVE (5th CSL by 5th CSL into 2/5/11), MARRIAGE (7 by 7 into 2/7/11), FINANCE (2 by 2 into 2/11), UNION (11 by 11 into 2/7/11), DENIAL_ABSENCE (no 6/8/12 from 7th CSL), and DASHA_SYNC (overlapping 7th/11th-house dasha windows when both partners are simultaneously active in marriage-house periods). Returns '{ poruthamRejected, poruthamRejectionNote, theTenPoruthams, individualPrerequisites, prerequisiteNote, factors: [{ factor, score, verdict, person1Coverage, person2Coverage, rationale }], dashaSyncWindows: [{ fromDate, toDate, person1Mahadasha, person1Antardasha, person2Mahadasha, person2Antardasha, confidence, rationale }], overallScore, overallVerdict: EXCELLENT | GOOD | AVERAGE | BELOW_AVERAGE | POOR, summary, bookCitations, framesUsed, methodSeams }'. Every score is an engine construction (F006), and 'overallScore' is an unlabelled average across both claims; KSK's six individual-chart points ('individualPrerequisites') are a gate to read first, not weights. The two claims are also tools of their own: 'get_couple_csl_factors' (the first five factors) and 'get_couple_dasha_sync' (the windows and the DASHA_SYNC row).

[RENAMED, use get_compatibility_panel] The same tool under its old name, kept for one release so existing callers keep working. It returns exactly what get_compatibility_panel returns: factors, dashaSyncWindows, overallScore and the Porutham-rejection note.

KSK's universal discord rule, KP Reader 4 canon p.73 (house numbers recovered by Q009): any planet whose SUB LORD signifies 6, 10 or 12 can cause discord, short-lived when that sub lord also signifies 2, 7 or 11; Mars has no special standing, and KSK names the manner for a Mars or Saturn sub lord only. The raw list is large by construction, so read 'fruitfulAgents' (narrowed by the Ruling Planets) and 'criticalAgents' (fruitful with no 2/7/11 link). Returns '{ universalDiscord: { agents: [{ planet, subLord, discordHouses, unionHouses, temporary, fruitful, manner, note }], permanentAgents, fruitfulAgents, criticalAgents, rulingPlanets, present, discordHouses, unionHouses, citation, note }, bookCitations, disclaimer }'. The same block 'get_marital_separation' returns as 'universalDiscord'. Supplementary lens; describes a pattern, not an outcome.

Calendar of peak-risk dasha windows for marital separation, plus structured trigger detection. Returns: trigger strength (1/6/10 signified by 7th CSL star lord), Saturn/Rahu amplifier flag, peak-risk windows ranked by net risk score (separation houses minus marriage houses), sequential mixed-active pattern flag (marriage promised AND separation promised). Books: KP Reader 4 divorce chapters, Advanced T32. Also returns 'universalDiscord', KSK's own rule (KP Reader 4 canon p.73: planets whose sub lord signifies 6, 10 or 12). Each claim is also a tool of its own, named in 'methodSeams': 'get_marital_discord_signature', 'get_separation_trigger' and 'get_separation_risk_windows' (paged). Call those when a reading needs one; this tool returns every part, with the overall score and sequential flag that read across them, in one call. Supplementary lens, not legal advice; describes pattern risk, not predetermined outcome.

Punarphoo, KP Reader 4 ch.22: the natal Moon-Saturn tie that delays the date of a marriage and never denies it. Natal only, never read from an elected moment. Each party reads the sign-level form (astrology-for-beginners p.315) and the stronger star-and-sub form (Reader 4 p.82), the house clause recovered by Q008 (Saturn in 1, 3, 5, 7 or 10 without a tie to 2, 7 or 11 reads 'delay-or-denial', a contradiction inside the sources, reported and gating nothing) and K.R. Kar's Sun cancellations (reported, never applied). Reader 4 p.82 says to check BOTH horoscopes: pass 'person2' for the partner. Returns '{ partyA: { present, reasons, strength: none | sign-level | star-and-sub, houseClause: { saturnHouse, inObstructiveHouse, saturnSignifiesMarriageHouses, severity, note }, cancellation: { cancelled, reasons, note }, note }, partyB, presentInEither, presentInBoth, note }', plus 'framesUsed' when 'person2' is given. Without 'person2', 'partyB' is null and the response is the same block 'get_second_marriage' returns as 'punarphoo'.

KP second marriage (T33, renamed from get_marriage_advanced on 2026-10-08): the 8th cusp (2nd from the 7th) sub lord against houses 2, 8 and 11 for the promise, an estimate of the first marriage from the 7th CSL and the 2/7/11 MD-AD periods, and the MD-AD-PD periods after it whose lords signify 2, 8 or 11. Returns '{ secondMarriageEventDef, cslPromise: { eighthCSLPlanet, eighthCSLStarLord, housesSignified, housesRequired, coverage, verdict, starLordDenial, isPromised, notes }, firstMarriageEstimate: { found, earliestDate, latestDate, periods, periodsCap }, candidatePeriods: [{ startDate, endDate, mahadasha, antardasha, pratyantardasha, mdHouses, adHouses, pdHouses, jointCoverage, isAfterFirstMarriage, confidence, reasons }], overallVerdict: PROMISED | PARTIALLY_PROMISED | NOT_PROMISED, punarphoo, notes, summary, methodSeams }'. 'confidence' is an engine weighting. 'punarphoo' (the natal Moon-Saturn delay, KP Reader 4 ch.22) gates nothing here and is also a tool of its own, 'get_punarphoo', which takes the partner chart for the two-chart test.

[RENAMED, use get_second_marriage] The same tool under its old name, kept for one release so existing callers keep working. It returns exactly what get_second_marriage returns: cslPromise, firstMarriageEstimate, candidatePeriods, overallVerdict and punarphoo.

The risk calendar (T32): every MD-AD-PD period whose lords jointly signify any of 1/6/10, with the 2/7/11 houses they also touch, highest 'netRiskScore' first (the engine's own weighting on the 1/6/10 convention, labelled so in the citations, F006). Returns '{ peakRiskWindows: [{ fromDate, toDate, mahadasha, antardasha, pratyantardasha, separationHousesActive, marriageHousesActive, netRiskScore, rationale }], bookCitations, disclaimer, pagination, pageNote }'. **'peakRiskWindows' is paged.** The same list 'get_marital_separation' returns as 'peakRiskWindows'. Supplementary lens, not legal advice; a period of pressure, not a predetermined outcome.

The natal trigger: the 7th cusp sub lord's star lord against 1/6/10, the marriage negation houses (the 12th from each of 2/7/11, the KP convention, not KSK's p.73 rule), with 'triggerStrength' (33 per house hit, an engine figure) and whether a Saturn or Rahu mahadasha runs in the calendar. Reads no period. Returns '{ trigger: { starLordSignifies, triggersHit, saturnRahuAmplifier, triggerStrength, rationale }, bookCitations, disclaimer }'. The same block 'get_marital_separation' returns as 'trigger'. Supplementary lens; describes a pattern, not an outcome.

Derives a structured spouse description from the 7th CSL's star lord per Advanced Technique T31. Returns profession class (industry archetype), age relationship (older / younger / same), geographic background (local / NRI-or-foreign-born / foreign), wealth relative to native (wealthier / comparable / poorer), personality archetype, and physical archetype. Designed for matrimonial-platform embeds.

[Jaimini adjunct] Upapada Lagna, Pada of the 12th house, used for marriage / spouse analysis in Jaimini tradition. Returns UL sign, lord, occupants, aspecting planets, and 'upapadaVariants': the 12th (default; Jaimini 1.4.1 in B. S. Rao's numbering, BPHS ch. 30), the 7th (B. S. Rao's 'some commentators'), the 12th or 2nd by the lagna's parity (Santhanam's note, citing a Chaukhamba commentary) and the 5th (the same note), each with its source. Also returns all 12 Arudha padas (A1-A12), each with its exception readings and co-lord fork where they apply. B2B fit for matrimonial-platform deeper-layer analysis.

KP Reader 4's rule for where the partner comes from, on the natal chart: the sub lord of the 7th cusp sub lord (and of each 7th-house significator) and the houses that sub lord OWNS. Owning the 1st or 4th: a co-tenant, one's own street, town or district, no journey after marriage. Owning the 3rd: a cousin, a neighbour, a short land journey, or a match fixed by correspondence or advertisement. Owning the 11th: a friend's family. Owning the 9th or 12th: a stranger, a love marriage, a foreigner, a long distance, which is the corpus's only statement on an inter-community or foreign partner. The extract of the page dropped its bare numerals, so every branch carries 'decodeConfidence' (the 3rd is certain from its suffix; the others are read from the page's sense) and the quote is given with its gaps. 'direction' applies Reader 6's sign-to-direction table to the sign the 7th cusp sub lord occupies and is labelled as a horary page applied natally; it gates nothing. Canon pages cited.

The seven conditions KP Reader 4 chapter 21 lists under the heading "Marriage is Promised but it comes off late in life" (canon pp.76-79). Answers the question the promise and timing tools do not: not whether marriage happens or when, but WHY it keeps slipping. **Every condition here is a DELAY and none is a denial** — whether marriage is promised at all is decided by the 7th cuspal sub lord, never by this list. **Only three of the seven are computable and the response says which.** Four invoke Uranus or a Western square, neither of which exists in KP, so they are returned with 'computed: false' and a reason rather than silently skipped or half-scored. The three that are computed: Saturn in the 1st, 3rd, 5th, 7th or 10th sign from the Lagna or the Moon while owning none of 2/7/11; Mars in the 7th; Moon conjoined with Saturn. **This is the received tradition, not KSK's method**, and the response says so: 'system' is 'vedic-parashari-with-western-aspects', and 'kpPosition' points at Punarphoo, which is what KSK gives in the same chapter (canon p.79) as his own reading and which 'get_second_marriage' carries. 'courseOfEvents' quotes what the corpus says a delay looks like — proposals falling through one after another, the bride resolving to stay unmarried, then a fresh party and a sudden celebration — instead of inventing a severity score the page does not give. Note on the source: canon pp.76-79 render every digit one higher than it should be, and the house numbers above are decoded through that shift, confirmed against a birth date, a marriage date and a stated age that only reconcile under it. Books: KP Reader 4 ch.21, canon pp.76-79.

The 7th-cusp read for starting one's own concern and for taking a partner. Tests four named denial conditions (KP Reader 3 pp.375-376, restated Jyotish Part 3 p.199): the lord or a significator of the 7th sitting in Saturn's sub; the 7th CSL in the star of a planet placed in the 5th, 8th or 12th, sharper when that planet is in an earthy sign; a significator of the 7th in the sub of a planet deposited in 5/8/12; and the Mars courage gate, where neither the running dasa lord, the bhukti lord nor the 7th cusp sub lord connects Mars. Profit is decided at the 11th CSL and never at the 7th (Part 3 p.192), with gains to the querent read at the 6th (the 12th from the 7th) and the 11th (Part 3 p.172). Returns the partnership matrix from Part 3 p.054 with break agency (6+11 take a partner, 6+12 it breaks, 5+11 permanent, 5+8+12 the partner gains and you lose) resolved through the Reader 3 p.435 agency rule (the 6th shows when he leaves, the 12th shows when you drop him), the new-partner chain, the common-sign badhaka trap as context only (Jyotish Part 2 p.094), the 7th-CSL sign modality, wind-up risk, and dated gain windows from the business gain gate. Returns '{ seventhCsl, viability: PROMISED|MARGINAL|DENIED, denialConditions[], marsCourageGate, eleventhCslProfitVerdict, businessGainGate, gainWindows[], partnership, modalityVerdict, windUpRisk, summary, disclaimer }'. Not business or investment advice.

Reads the houses the 10th cuspal sub lord does NOT signify and turns them into four named consultation answers (source: krishnamurtipaddhati.com, '4 career problems in KP astrology explained'). Prolonged unemployment: the 10th CSL signifies 6, 8 or 12 with nothing from the earning group 2/10/11. Stagnant salary: it signifies 10 and 11 but skips 2, which is recognition that does not land in pay. Blocked promotion: it signifies 10 and 2 but skips 11, which is a role that pays but does not move. Layoff exposure: it strongly signifies 8 or 12 and the running major or sub period lord reinforces it. Each diagnosis carries evidence, a resolution gate, and dated resolution windows walked from the dasha calendar. Also reports structural stagnation, read as Astro Secrets canon p.198 prints it ("10th sublord is connected to 1 and 10only"): every house the 10th sub lord signifies is 1 or 10 (a lone 1 or lone 10 holds; no house at all does not), with 'reading', 'outsideHouses', 'connectedTo1', 'connectedTo10', 'emptySet' and 'source' beside 'present', and the career-struggle signature (the 10th CSL in the star of a planet signifying 5, 8 or 12). Returns '{ tenthCsl, signifiedHouses[], missingHouses[], diagnoses[], structuralStagnation, careerStruggleViaStarLord, primaryBlockage, summary, disclaimer, queryDateUsed }'. Every pattern is period-bound by construction and none is a permanent verdict.

One-shot KP career foundation read. For each of the five career cusps (2 self-acquisition, 6 service, 7 partnership, 10 profession, 11 net profit) and each of the four negation cusps (KP Reader 3 p.394: the 1st negates the 2nd, the 5th negates the 6th, the 9th negates the 10th, the 12th is general loss) it returns the sign, star lord, cuspal sub lord, the CSL's own star lord with its full L1-L4 significations, the CSL's retrograde and combustion state, and a one-line verdict. Then classifies all nine planets career-friendly (2/6/10/11 at L1 or L2 with no 1/5/9/12 at L1 or L2) or career-hostile, sums a signed 'careerBalanceIndex' into a STRONG / FAVOURABLE / MIXED / OBSTRUCTED / HEAVILY_OBSTRUCTED band, and reports which negation houses are actually live against their targets. Returns '{ cuspReads[], planetClasses[], careerBalanceIndex, band, negationHousesActive[], bhadhakaRole, summary, disclaimer }'. The bhadhaka block is context only: Reader 2 p.332 confines bhadhakasthana to longevity and health, so it is never a career denial gate here. Call this first in any career reading; 'get_career_signature' scores category fit and 'get_job_change_vs_promotion' handles timing.

Career analysis from the 10th-house CSL (Cuspal Sub Lord). Returns '{ chart_info, profession_indicators, ruling_planet_applications: { chart_verification, prediction_confirmations[], rpMoment, judgement, rulingPlanetsAtBirth, atBirth, verdictFrom, scoreProvenance }, pagination, pageNote }'. The career verdict lives in 'profession_indicators' and 'chart_verification', both of which repeat on every page; **'prediction_confirmations' is paged** (with 'atBirth.prediction_confirmations', page for page) and is the RP audit trail across every event, not the answer. The confirmations read the ruling planets of the MOMENT OF JUDGEMENT (KP Reader 4: the planets ruling the moment the matter is judged), which is 'judgement_datetime', default now, at the birth place unless a judgement place is given; each row's 'csl_verdict' is 'analyze_natal_promise''s verdict and 'promise_state' names it (promised, undecided for MIXED_ACTIVE, denied), and only a promised verdict counts toward 'confirmation_strength'. 'atBirth' is every row read again with the BIRTH ruling planets, labelled for rectification only; 'chart_verification' is a birth-time check and keeps the birth set. For richer career signature (8 named categories: IT/government/business/military/medicine/law/arts/education) use 'get_career_signature'. For profession nature description (sector, employment mode, leadership/technical/creative scores) use 'get_profession_description'. For job-change vs promotion timing use 'get_job_change_vs_promotion'. The two RP applications are also tools of their own, named in 'methodSeams': 'get_rp_event_confirmations' (the confirmations, paged) and 'get_rp_chart_verification' (the birth-time check).

Scores the chart against 8 named career categories (IT/software, government, business, military/defence, medicine, law, arts/creative, education/academia) per KP Reader 3 ch.27-43 signatures. Each category gets a 0-100 score with concrete signature hits. Also emits cross-cutting axes: sector class (government / private / self / mixed), employment mode (employment / business / mixed), and leadership / technical / creative scores (each 0-100). Use this for 'what is this person suited for'; pair with get_profession_description for 'describe the actual profession' and get_job_change_vs_promotion for 'when promotion vs job-change'.

The earned-money read behind 'will my pay go up'. House roles are KP Reader 3 p.380 verbatim: the 2nd is receipt of money by any means including salary, the 6th is money for dues from service rendered to another, the 10th is money brought by the profession, the 11th is net profit. The core test is THE SUB GATE (Reader 3 pp.194-195, independently Jyotish Part 3 pp.175-176): a significator of 2/6/10/11 delivers only if the sub it occupies is governed by a significator of the 2nd, 6th or 11th. Also applies the Reader 3 p.218 reduction rule (significators of 2/10/11 in the sub of significators of 4/5/8/12), excludes the 10th from the profit verdict because it is the 12th to the 11th (Jyotish Part 1 p.354), checks the master rule that the lord of the 10th must connect the 2nd (Part 1 p.383), scores the salary / business / commission / windfall source mix, flags 8-and-12 leakage, and dates increment windows. Returns '{ houseRoles[], netGainEleventh, incomeGrade, gradeRationale[], lordOfTenthConnectsSecond, reductions[], incomeSourceMix[], leakageFlag, incrementWindows[], summary, disclaimer }'. QUALITATIVE ONLY: it never emits a salary figure, a currency amount or a rate of increase, because Jyotish Part 3 p.178 states exact figures are not derivable. Use get_financial_analysis for speculation and accumulated wealth, which works the 2-5-11 houses instead.

Working abroad, which get_foreign_settlement structurally cannot answer: its three stages are 3/12, 9/12 and 4/12 with no 6th or 10th house anywhere, so it reads settlement and never employment. KP Reader 3 p.330 states it plainly, stay in a foreign country is judged from the 12th, for further studies the 9th, and for a job 6 and 10 also. Promise gate, R3 p.327: the 12th CSL must signify 3, 9 or 12, and the event runs in the conjoined periods of those significators. The 6th-house term is what separates a posting from a settlement (Part 3 p.061 and R6 p.311, both independently: a 12th CSL signifying 3/9/12 AND a strong significator of the 6th gives a foreign assignment). R3 p.334's one-minute denial applies when the 12th CSL falls in the 8th bhava, the 12th from the 9th, which denies overseas entirely. 'mode' splits PAID_ABROAD, OWN_BUSINESS_ABROAD (the 6th against the 7th abroad, Part 1 pp.132-134), PROBATION (9 + 12) and PROMOTION_POSTING (11 with 6 or 10, R6 p.332), STUDY_ONLY and bare travel, each with the candidates that lost so the caller can see the margin. Also returns the abroad income gate on 2/6/11 and a permanent-residence read on 1/3/9/10/12 (Part 1 p.215). Not immigration, visa or relocation advice: verify every requirement with the relevant authority.

Dated job-change windows built on the sourced promise test rather than the invented house grammar in get_job_change_vs_promotion. Promise, Jyotish Part 3 p.103: the 10th CSL must signify 3, 5 or 9 AND must not sit in the constellation of a retrograde planet. Both published derivations of the leaving houses are reported side by side and neither is silently preferred: the orthodox 1/5/9 (the 12th from each of 2, 6 and 10, so the 1st negates self-acquisition, the 5th negates service, the 9th negates status) and Reader 6 pp.306-307's 3/5/9 (the 6th, 8th and 12th counted from the 10th). Separates the axis clients actually ask about: switching employer inside the same field is judged on the 6th cusp, switching field entirely on the 10th, and change of occupation (2/9/10/11) is distinguished from change of place inside the same job (3/10/12, Part 1 p.199). Windows are MD/AD/PD triples where the lords jointly signify the leaving houses, filtered by the bhukthi lord's own sub lord test (P3 p.104), pruned against ruling planets with retrograde RPs rejected, then narrowed by Sun transit. 'modernVariant589' carries the 5-9-8 rule as a labelled flag only, never as the verdict, because its hard 8th-house requirement would suppress every voluntary resignation. Returns '{ promised, tenthCsl, signifies359[], signifies159[], starLordRetrograde, leaveServiceGate, changeAxis, occupationVsPlace, windows[], sunTransitDates[], rpOverlap[], modernVariant589, summary, disclaimer }'.

KP job change vs promotion differentiation (T35, renamed from get_career_advanced on 2026-10-08): checks if 5th house (12th from 6th = end of current employment) is activated in the current antardasha. 5th active + 10th = job change. 10th+11th without 5th = promotion within same organization. One classification for the running period and one per upcoming period. Returns '{ scoreProvenance, currentDasha, currentOutcome: JOB_CHANGE | PROMOTION | UNCERTAIN, currentConfidence, currentReasons, adLordAnalysis, house5Significators, upcomingPeriods: [{ startDate, endDate, mahadasha, antardasha, pratyantardasha, outcome, confidence, reasons, mdAnalysis, adAnalysis, pdAnalysis }], summary }'; **'upcomingPeriods' is paged**. 'confidence' is an engine weighting labelled in 'scoreProvenance', and this reads 10 and 11 for promotion where KSK reads 2, 6, 10 and 11. The sourced siblings: 'get_promotion_verdict' (the orthodox promotion gate) and 'get_job_change_timing' (dated job-change windows on the 10th CSL promise test).

[RENAMED, use get_job_change_vs_promotion] The same tool under its old name, kept for one release so existing callers keep working. It returns exactly what get_job_change_vs_promotion returns: currentOutcome, house5Significators and upcomingPeriods (paged).

Which kinds of modern work a chart leans toward, scored off the 10th cusp TRIAD rather than a ninefold planet lookup. The method is KSK's own three steps at KP Reader 3 printed 327-328: study what each sign indicates, understand what each planet denotes, then combine the rasi and the planet at the meridian. His worked example is explicit, that the meridian's sign lord, star lord and sub lord together indicate the profession, so this tool scores those three and not the sub lord's own star lord (get_profession_description walks that deeper chain for a different question). Scoring layers: triad planet overlap, supporting planet overlap, the meridian sign, domain-house activation through the significator matrix, and the 2/6/10/11 career base. NODE HANDLING: Rahu and Ketu are never scored as themselves. In KP a node carries no karakatva of its own and acts as an agent for its star lord, its conjunctions and its sign lord (KP Reader 6 p.274; KP Reader 3 p.356, 'For Rahu and Ketu, one is to note in which constellation it is and then according to the lord of the constellation ... one is to offer the prediction'), so node slots are resolved and the resolved planet scores, with every substitution listed in 'nodeResolution[]'. PROVENANCE MODEL, read this before quoting any result: each occupation carries 'provenance', one of BOOK_SOURCED (a KP text names it directly in a profession context), ANCESTOR_DERIVED (inherited from a named older occupation the books do carry, with the ancestor recorded so the leap is one auditable step) or PRINCIPLE_DERIVED (no KP text predates the occupation, so the signature was assembled from planet, sign and house significations, which is a reasoned construction and not a citation). 'provenanceSummary' reports the mix at the top level. CONFIDENCE CAVEAT: this is the weakest tool in the career suite and is built to say so. KP is strong on whether a career is promised, on whether it runs as service or one's own concern, and on when the ground shifts; it is weakest at naming an occupation, and KP's own literature says so, since Tin Win, reviewing the standard KP profession text in KP Ezine October 2010, wrote that 'The precise rules which are valid for a bulk of empirical charts have not yet been found.' 'topFamilies' is the headline answer and 'matches' is capped at 12 as illustration, never a shortlist; 'matchesCap' and 'topFamiliesCap' give the totals before each cap. 'matches' is paged ('pagination', 'pageNote'; usually two pages), and everything else repeats on every page, so read every page before quoting a match. 'noSettledOccupationFlag' trips when the career balance is HEAVILY_OBSTRUCTED or the Jyotish Part 1 p.359 denial gate fires (a 10th CSL signifying none of 6, 7 or 10), and the matches are then inclinations rather than a career. Returns '{ tenthCuspTriad, planetLayer[], signLayer[], houseLayer, nodeResolution[], topFamilies[], matches[], noSettledOccupationFlag, provenanceSummary, summary, disclaimer, pagination, pageNote }'. Phrase every result as 'leans toward' or 'is consistent with'. Never say what someone is, and never use this to screen, rank or decide about anyone.

Derives the type of profession (not timing) from the 10th CSL's star lord per Advanced Technique T34. Returns primary and secondary industry, sector class (government / private / self), employment mode (employment vs business per R3 ch.29-31), work type, leadership / technical / creative scores (each 0-100), and a qualitative salary band. Use alongside get_job_change_vs_promotion (which handles career timing) and get_career_signature (which scores career-category fit).

The orthodox promotion gate, which the older get_job_change_vs_promotion never applied because it does not read a cusp sub lord at all. Three conditions from Jyotish Part 5 p.185 quoting KP Reader 6 p.287, restated verbatim at R6 p.297: the 11th cuspal sub lord must be direct, its star lord must be direct, and the 11th CSL must signify 2, 6, 10 or 11. The star-lord condition is returned as 'starLordRetrogradeOverride', a flag rather than a hard veto, because the source author himself overrides it on evidence at P5 pp.186-188. Returns two window sets that consultations routinely conflate: 'selectionNewsWindows' (an 11th significator that also signifies the 3rd, which is hearing of the selection, R3 p.433) and 'actualPromotionWindows' (the 11th conjoined with 2, 6 or 10, which is the order itself). Also returns 'stagnationFlag' (structural stagnation, read as Astro Secrets canon p.198 prints it, "10th sublord is connected to 1 and 10only": every house the 10th sub lord signifies is 1 or 10, a lone 1 or lone 10 holds, no house at all does not; the same reading 'get_career_blockage_diagnosis' applies, with 'reading', 'outsideHouses', 'connectedTo1', 'connectedTo10', 'emptySet' and 'source'), 'delayAgent' (Saturn owning the 11th delays until the native gives up, then delivers, R6 p.299), 'bothCuspsVariant' (the stricter applied form requiring the 6th and 10th CSLs to signify 2/6/10/11 simultaneously) and 'transferCoincides'. No salary or increment figure is derivable from a chart and none is returned.

Answers salaried service against running one's own concern by running five sourced KP rules independently and reporting each one, in the style of get_four_step_verdict. Rule A: the 2nd cusp sub lord clauses (KP Reader 3 p.154, restated Reader 5 p.175). Rule B: the star lord of the 10th CSL against the 6th and the 7th (Jyotish Part 1 p.345, Part 3 p.058). Rule C: the 10th CSL on 6-8 against 7-10-11 (Part 1 p.355). Rule D: the 6-8-12 group against the 1-7-10-11 group, compared as fractions (Part 1 p.382). Rule E: the applied exclusion sets through the 10th CSL's star lord, with the 6th-CSL and 11th-CSL fallback chain. Returns '{ verdicts[], consensus, agreement: STRONG|PARTIAL|DIVERGENT, denialGate, dualProfession, strictStellarFilterApplied, summary, disclaimer }'. Also enforces the Part 1 p.359 denial gate (a 10th CSL signifying none of 6, 7 or 10 promises no settled occupation) and the Part 1 p.356 strict stellar filter (a star lord must signify by occupation, or be in its own star as owner; mere ownership does not count), reporting which significations the filter dropped. When the rules disagree the disagreement is the answer: this tool never picks a winner silently.

The service-negation frame stated verbatim at KP Reader 3 p.394: judge houses 1, 5, 9 and 12 for termination of service, because the 1st negates the 2nd (self-acquisition), the 5th negates the 6th (service), the 9th negates the 10th (status), and the 12th is the general house of loss. The load-bearing qualifier is from Jyotish Part 5 pp.190-191, which states independently that this signifies change of work or duties or even job, or leave, or reversal in the ordinary course, and NOT necessarily punishment. P5 p.191 supplies the discriminator: punishment requires a significator of 6 or 10 to ALSO be a strong significator of the 8th, and with no 8th connection there is no harmful result. So 'punishmentGate' returns ORDINARY_CHANGE / PUNITIVE / NONE rather than a single risk number. Windows are typed LEAVE / TRANSFER / REVERSION / SUSPENSION / TERMINATION. Both published suspension house sets are returned with an agreement note (5/9/12 from R3 p.433, and the 1/8/9/12 applied variant), plus the vigilance-or-bribery pattern (10 + 12, R3 p.433) and the 6/8/12-from-both recurrence rule (a post held from A-dasa B-bhukthi comes under pressure in a C-bhukthi that is 6, 8 or 12 from both, Part 2 p.223 and R5 p.291) when 'post_start_date' is supplied. This tool deliberately ships a risk band with dated windows and never a binary firing verdict: an unhedged machine verdict on someone's livelihood is a harm the standard disclaimer does not cover.

KP accident-window detection. Identifies dasha periods with malefic activation (Mars / Saturn / Rahu) signifying risk houses, and classifies each window by accident class: VEHICULAR (3rd house), WORKPLACE (6+10), SURGICAL (1+8), ASSAULT (6+12), or GENERIC (4 or 8 with malefic). Severity bands: MINOR / MODERATE / SEVERE / LIFE_THREATENING. Returns ranked risk windows, aggregate type distribution, and the peak window. Books: KP Reader 6 case 50 and J5 p.50 worked accident case 23-7-1963. The Reader 3 citation this used to carry was wrong: it named ch.22, which is "Will stammering disappear?" (canon pp.310-313), and Reader 3 has no accident chapter. The house grammar (1st for the body, 4 and 8 supporting, 12 for confinement) is later KP practitioner literature, class modern, not KSK. Supplementary safety lens, not deterministic; flags caution windows, never predicts certain harm.

Hybrid Ayurvedic-Jyotisha lens. Maps planets to doshas (Saturn/Rahu/Mercury to Vata, Sun/Mars/Ketu to Pitta, Moon/Jupiter/Venus to Kapha) weighted by house importance (1H strongest, then 6/8/12 health, then 4 vital fluids, and so on) and adds the lagna-sign element bonus. Returns vata/pitta/kapha percentage triple summing to 100, primary plus secondary dosha, prakritiCombo (single / dual / TRIDOSHIC), and per-planet contributions. Hybrid discussion starter, not a clinical Ayurvedic prakriti reading and not standalone health advice; supplementary lens only.

Multi-disease watch-decade panel scoring 8 chronic conditions: cardiac, diabetes, kidney, liver, neurological, mental-health, respiratory, skeletal. Each disease gets (a) a 0-100 signature strength from key planets afflicting 6/8/12 plus sign affinity on 6th cusp plus 6th-CSL match, (b) a severity classification (LOW/MODERATE/HIGH/CRITICAL), (c) watch-decade dasha bands (ONSET_RISK / AGGRAVATION / CRITICAL) drawn from MD+AD where the disease's key planets activate. Books: KP Reader 3 ch.19 "Disease", canon pp.291-301, plus canon p.190 for the chronicity rule. The per-disease house assignments are this engine's and are not in those pages. **Paged by disease**, each returned whole with its watch decades, signature hits and rationale, so a page is a complete condition rather than a partial one; 'topRiskDisease', 'topRiskDecade', 'bookCitations' and the disclaimer repeat on every page. Supplementary lens, not diagnostic; never a substitute for medical evaluation.

Dated recovery/cure windows, the mirror image of surgery timing. Collects L1-L4 significators of houses 1/5/11 (body, relief/vitality, cure), excludes planets that simultaneously signify 6/8/12 at L1/L2 (Golden Rule, they promise disease more strongly than cure, reported in excludedByGoldenRule), and for movable lagnas demotes 11th-house cure claims to half weight (the 11th IS the bhadhaka). Walks the MD/AD/PD dasha calendar for windows where all three lords are filtered cure significators, scored by joint coverage and level weights, with transit Jupiter (year-band) and Sun (month) star-lord confirmations at each window midpoint plus transit-Moon refinement guidance. READ 'curePromise' FIRST: KP Reader 3 canon p.189 settles whether there is a cure at all before any date is offered, and denies it only when all three of its conditions hold together (nothing in the 11th, no planet in the star of the 11th's owner or occupants, and the 11th cusp and 11th lord both in evil subs). 'dashaLevelIncurability' reports the page's NEXT paragraph, what KSK saw in the horoscopes of lifelong sufferers (every dasa lord from the onset in the sub of the lord of 6, the 11th not strong, the lords of 11 and 1 spoiled), as a pattern word with each observation and the engine's reading of the three terms he leaves undefined; it gates nothing, because he states it as an observation and not as a rule. Returns { curePromise, dashaLevelIncurability, cureSignificators, excludedByGoldenRule, bhadhakaAdjustment, windows[], bestWindow, noCureWindowReason, disclaimer }. Supplementary lens, not medical advice.

Deterministic 'how is health pressure right now' snapshot for a moment: running MD/AD/PD (and Sookshma) lords each scored +weight for 6/8/12 significations at L1/L2 (pressure) and -weight for 1/5/11 (recovery); ruling planets of the moment overlapped with the health-hostile set (6/8/12 at L1/L2 without 1/5/11) and health-friendly set; transit Moon star/sub lord hostility flags; transit Saturn/Mars in the star of a 6/8/12 significator as slow/acute triggers. Aggregates to healthPressureScore 0-100 with status FAVOURABLE / WATCHFUL / STRAINED, ordered reasons[], and nextChangeDate = when the current pratyantardasha ends. Supplementary lens, not medical advice.

Decodes the 6th cusp sub lord into the NATURE of disease, not merely its location (KP Reader 3 canon p.295 for the procedure, canon p.190 for chronicity, canon pp.292 and 296-297 for the keyword lists). Three layers: (a) planet-to-ailment-class keywords for the 6th CSL and separately for its star lord (e.g. Saturn = chronic/degenerative, Mars = acute inflammation/surgery, Ketu = viral/autoimmune/misdiagnosed); (b) chronicity from the modality of the sign the CSL occupies (movable = ACUTE self-limiting, fixed = CHRONIC long-standing, dual = RECURRING relapsing); (c) body part from the CSL's nakshatra position via the 27-fold Kalapurusha map, with the 12-sign body part as a secondary read. Severity gates from the CSL's own significations (8 = serious/prolonged, 12 = hospitalization tendency, 11 = curable) combine into a CURABLE / MANAGEABLE / PERSISTENT curability verdict. Natal-only, no dasha walk. Supplementary lens, not a medical diagnosis.

Personal counterpart of the national epidemic scorer in get_mundane_analysis (B22), mirroring its planet set: Mercury (respiratory), Moon (fluids/lymph), Ketu (viral), Rahu (contagion). susceptibilityScore 0-100 from the 6th CSL chain carrying those planets (+18/+15/+18/+18), the same four signifying 6/8/12 at L1/L2 (+6 each, capped +24), the Mercury-Ketu 8-degree pandemic amplifier (+10) and a 12th CSL isolation link (+8). resistanceScore is the vitality index; netBand LOW/MODERATE/ELEVATED/HIGH from susceptibility minus resistance/2. personalExposureWindows are MD/AD/PD periods whose lords are signature planets signifying 6/8/12 at L1/L2, bounded to outbreak_from..outbreak_to when given (else the next 3 years). Includes respiratoryBias and isolationRisk flags and echoes the outbreak window.

Natal susceptibility panel framed strictly as tendencies and patterns, never labels or diagnoses. Core lens: the 12th CSL (indulgence/escape) and its chain — Rahu (+15, substance/escalation), Ketu (+10, relapse cycles), Venus (+10, indulgence), Saturn (+8, entrenchment), Mars (+5, risk-taking), Moon tied to Rahu/Saturn while signifying 12 (+12, emotional dependency), 12th CSL signifying 12 with 6/8 (+20). Returns susceptibilityScore 0-100 with band (LOW/MODERATE/ELEVATED/HIGH), indicated tendency types (COMPULSIVE_DIGITAL is an explicitly modern non-classical extension), protective factors (a strong 6th CSL signifying 11 means the fight is won; Jupiter on the 12th; strong 1st CSL), and Golden-Rule-filtered vulnerable/recovery MD-AD windows. Includes a warm supportNote; anyone struggling should reach a qualified professional.

One-shot KP health foundation read. For each of the six health cusps (1 vitality, 5 recuperation, 6 disease, 8 chronicity/surgery, 11 recovery, 12 hospitalization) it returns the cusp's star lord, sub lord (CSL), the CSL's star lord with its full L1-L4 house significations, and the CSL's retrograde/combustion state with a one-line verdict. Then classifies all nine planets: health-hostile (signify 6/8/12 at L1/L2 without 1/5/11 at L1/L2), health-friendly (the mirror test), or neutral; aggregates a signed healthBalanceIndex (1-5-11 weight minus 6-8-12 weight, L1=4 L2=3 L3=2 L4=1) into a disease-proneness band (RESILIENT/BALANCED/DISEASE_PRONE/HIGHLY_VULNERABLE); and reports whether the bhadhaka lord (Reader 3 mobility rule) lands in the hostile list. Supplementary lens, not medical diagnosis; no death prediction.

Sign-to-body-part affliction panel. Maps each sign to its body region (Aries=head, Taurus=throat, ..., Pisces=feet) and organ system, scores affliction 0-100 from malefics in the sign + sign-lord weakness (combust/debilitated/retrograde). Returns per-sign body-part rows, highest-risk organ, and standard medical disclaimer. NOT A KP READING: this tool touches no cusp, sub lord or significator, so none of the KP decision procedure is in it, and it is tagged vedic-parashari for that reason. The body map is melothesia shared by every tradition that uses one; KSK prints his own per-sign disease list at KP Reader 3 canon pp.296-297 and credits it at canon p.291 to Western authors. The affliction weights are a Lumin convention with no source. SUPPLEMENTARY LENS, NOT DIAGNOSTIC; never a substitute for medical evaluation.

Day-level health-vulnerability calendar over a window (default 12 months, clamped to 24). Scans transit Saturn (chronic-flare bands), Mars (acute bands), Sun (month-level vitality dips), Moon star+sub hostile days, and Rahu/Ketu axis contact within 2° of the natal 6th/8th cusps — all against the natal health-hostile significator set (6/8/12 at L1/L2 without 1/5/11, plus bhadhaka-house significators). Each merged alert band carries severity 1-3 (concurrent confirmations, +1 when the running AD/PD lord is hostile; bands under a clean 1/5/11 MD+AD are suppressed), a body-area hint, and one-line guidance. Also returns the quietest alert-free stretches. Returns '{ window: { from, to }, minSeverity, spanClampedTo24Months, natalHealthSignificators: [{ planet, hostileHouses, basis, natalSign, bodyAreas }], alerts: [{ fromDate, toDate, triggers: [{ type, transitingPlanet, from, to, hostileStarLord, contactedCusp, note }], transitingPlanets, severity, dashaAgreement, bodyAreaHint, guidance }], quietestPeriods: [{ fromDate, toDate, days, note }], suppressedByDashaAgreement, disclaimer, pagination, pageNote }'. **'alerts[].triggers' is paged.** The triggers of every alert are paged as one run in order; an alert whose triggers run past a page appears on each page it spans with its other fields repeated, and 'pagination.elements' gives its position in the full 'alerts' list and which of its triggers the page holds. The disclaimer is on every page. Supplementary perspective, not medical advice.

Natal 12th-house confinement analysis. Promise gate on the 12th CSL: signifying 6 and/or 8 makes the confinement illness-driven (PROMISED); only 3/9 reads as travel/retreat (WEAK, non-medical); neither is DENIED. Walks the MD/AD/PD calendar for windows where the three lords jointly activate the 12th with an admission driver — typed ADMISSION {12,6}, SURGICAL_OR_ICU {12,8}, CRITICAL {12,8,bhadhaka}, DAY_PROCEDURE {12,1} (the confinement group is 1/6/12 per KP Reader 3 canon p.293, "if the significator of the sixth house is also the significator of 1 and also 12 one will be confined to bed"; it used to carry the 5th, which is the CURE house) — chronological and complete, with Saturn (prolonged-stay) and Mars (emergency/acute) transit confirmation sampled at each window midpoint. Duration class from the 12th CSL's occupied sign modality: movable=SHORT_STAY, fixed=PROLONGED, dual=REPEAT_ADMISSIONS. Supplementary lens, not medical advice or diagnosis.

Six named planet-pair signatures (Jupiter-Rahu, Saturn-Mars, Moon-Rahu, Saturn-Rahu, Mars-Ketu, Sun-Saturn), each with a 0-100 strength from both planets' signification of 6/8/12 (an engine figure) and the MD-AD periods where both planets run, strongest first, with the strongest repeated as 'topSignature'. Returns '{ malignancySignatures: [{ name, planets, description, strength, activeInDasha, activeDashaPeriods: [{ startDate, endDate, mahadasha, antardasha }] }], topSignature, disclaimer }'. The same fields 'get_oncology_timing' returns as 'malignancySignatures' and 'topSignature'. Supplementary lens, not diagnostic; it does not screen for anything.

KP medical timing: surgery window analysis (the 1st, 6th and 8th cusp sub lords each signifying one of 1/6/8/12, the MD-AD-PD periods whose lords signify them, and the transit Moon's windows, star and sub both on significators of 1/5/11, inside the top period) and recovery vs chronic differentiation (compares 6th CSL star lord's signification level for 11th house vs 8th house: higher 11th = recovery, higher 8th = chronic). Returns '{ surgeryTiming, recoveryChronic, summary, disclaimer, methodSeams }'. **'surgeryTiming.candidatePeriods' is paged.** Each technique is also a tool of its own, named in 'methodSeams': 'get_surgery_dasha_periods' (T24) and 'get_chronic_recovery' (T25). Call those when a reading needs one; this tool returns both in one call. Supplementary lens, not diagnostic; never a substitute for medical evaluation.

Reflective natal panel on emotional and cognitive pressure patterns, in tendency/pattern language only (never diagnosis). Moon and Mercury affliction scores 0-100 with itemized factors (dusthana, malefic conjunctions within 8 degrees, star lord on 6/8/12 at L1/L2, waning Moon amplifier; graded combustion is itemized at zero points, reported and not scored per F066). Cusp reads for the 1st, 5th, 8th and 12th. Seven named signatures with strength: MOON_SATURN, MOON_RAHU, MOON_KETU, MOON_MARS, MERCURY_SATURN, MERCURY_RAHU, SEVERE_TIE. severityBand LOW/NOTABLE/ELEVATED/HIGH, institutionalizationRisk from the 12th read, MD/AD onsetWindows (afflictor lords signifying 6/8/12 at L1/L2) and Golden-Rule-clean reliefWindows. Always returns a crisisSupportNote alongside the disclaimer; surface it whenever this tool's output is discussed.

Deterministic diagnostic-ambiguity audit of the natal 6th-house chain, aggregated to a 0-100 score with bands LOW <25 / MODERATE <50 / ELEVATED <75 / HIGH ≥75. Flags: 6th CSL is Ketu or in Ketu's star (mystery illness — symptoms without findings), Rahu or in Rahu's star (wrong identification, drug reaction mimicking disease), CSL retrograde (diagnosis reverses on second opinion), Mercury afflicted (6/8/12 placement, node conjunction within 8°; its graded combustion is reported and adds no points, since a combust Mercury still signifies what it signifies in KP, F066), 6th cusp within 10 arc-min of a sub-lord boundary (CRITICAL ≤6' — reports the alternate sub lord and how the disease read would differ), Saturn in the CSL chain (delayed diagnosis), and the 10th CSL (the physician) signifying 6/8/12 at L1/L2 (change of doctor advised). Returns secondOpinionRecommended and physicianChangeIndicated. Supplementary lens, not medical advice or diagnosis.

KP oncology-specific lens. Decodes the body-part risk from the 6th cusp sign (12-sign to body-part map per KP Reader 3 canon pp.296-297, which KSK credits at canon p.291 to Heindel, Lilly, Zadkiel, Sepharial, Llewellyn George and Alan Leo; the KP part is the 6th cusp sub lord procedure at canon p.295, not the body map), scores 6 named malignancy signatures (Jupiter-Rahu tumor, Saturn-Mars chronic-inflammation, Moon-Rahu lymphatic-malignancy, Saturn-Rahu slow-growth, Mars-Ketu genetic-predisposition, Sun-Saturn bone/marrow), and produces a recurrence-vs-cure verdict from 6th CSL star lord's 8th-house vs 11th-house signification dominance. Returns treatment-window dasha periods (1+5+11 jointly active) and disease-onset windows (6+8+12 active). Each part is also a tool of its own, named in 'methodSeams': 'get_oncology_windows' (both window lists, paged together), 'get_malignancy_signatures', 'get_oncology_body_part_risk' and 'get_oncology_recurrence_verdict'. Call those when a reading needs one; this tool returns every part in one call. Supplementary lens, not diagnostic; never a substitute for medical evaluation.

The body part a disease would touch, from the sign on the 6th cusp through the twelve-sign body map in KP Reader 3 canon pp.296-297, which KSK credits to Heindel, Lilly, Zadkiel, Sepharial, Llewellyn George and Alan Leo: a borrowed map, not a KP rule. Malefics occupying the 6th raise 'severityScore' (an engine figure, baseline 30). Returns '{ sixthCuspSign, primaryBodyParts, secondaryBodyParts, severityScore, notes, disclaimer }'. The same block 'get_oncology_timing' returns as 'bodyPartRisk', with the disclaimer beside it. Supplementary lens, not diagnostic.

Recurrence against cure from the 6th cusp sub lord's star lord: its levels for the 8th and 12th (disease) against the 11th and 5th (cure), the 5th and 12th at half weight. The verdict thresholds are this engine's, not KSK's. Returns '{ sixthCSL, sixthCSLStarLord, starLordSignifies, eighthHouseLevel, eleventhHouseLevel, fifthHouseLevel, twelfthHouseLevel, outcome: CURE | RECURRENCE | CHRONIC | MIXED | UNCERTAIN, notes, summary, disclaimer }'. The same block 'get_oncology_timing' returns as 'recurrenceCureVerdict', with the disclaimer beside it. Supplementary lens, not diagnostic; prognosis belongs to oncologists.

The dasha calendar walked once on two house sets: treatment windows, MD-AD-PD periods whose lords signify the recovery houses 1/5/11, and onset windows, periods whose lords signify the disease houses 6/8/12. Kept together because they are one walk read against each other. Each window carries the houses on both sides and an engine confidence (not a KSK figure), highest first. Returns '{ treatmentWindows: [{ startDate, endDate, mahadasha, antardasha, pratyantardasha, recoveryHousesCovered, diseaseHousesCovered, netScore, confidence, reasons }], diseaseOnsetWindows: [same shape], disclaimer, pagination, pageNote }'. **Both lists are paged together**: page N carries the Nth page of each. The same lists 'get_oncology_timing' returns as 'treatmentWindows' and 'diseaseOnsetWindows'. Supplementary lens, not diagnostic; never a substitute for medical evaluation.

KP reflective lens on transplant-adjacent questions. RECIPIENT lens: 8th CSL (receiving another's body/resource, 2nd from the 7th) signifying 8+11 with a clean 1st CSL → PROMISED_AND_SURVIVABLE; only 6/8/12 → COMPLICATION_RISK; else UNCERTAIN. DONOR lens: 12th CSL signifying 12+6+11 favourable; 8 without 11 → donor-risk caution. Rejection overlay: Ketu on the role chain → immune-rejection flag, Saturn → delayed-graft-function flag. Organ indication from the 6th CSL's nakshatra (Kalapurusha 27-fold). Candidate MD/AD/PD windows (5-year horizon) jointly covering {8,11} or {12,11}, each with Mars-direct and Jupiter-in-11th-significator-star midpoint confirmations. Optional counterpart profile adds simple donor-recipient window sync. Transplant decisions are entirely medical; this is a supplementary reflective lens only.

Qualitative lifespan-band estimation per KP Reader 3 ch.1 p.153 (Bhadhakasthana) and Reader 5 longevity transits. Returns: bhadhakasthana house (selected by lagna mobility, movable=11, fixed=9, dual=7 per KSK), maraka houses [2, 7, 12], 1st-CSL star lord signature, lifespanBand (SHORT / MIDDLE / LONG / INDETERMINATE), expectedAgeBand (qualitative band only, never an exact age), balarishtaWarning, and criticalWindows[] (dasha periods activating bhadhaka/maraka houses, ranked CAUTION / NOTABLE / PEAK_RISK with ageStart/End). BY DESIGN THIS TOOL DOES NOT AND CANNOT PREDICT DEATH DATES OR MOMENTS; outputs are qualitative bands and risk windows only. Restricted in some jurisdictions without consent; B2B advisor-tooling signal, never consumer-facing.

T25: whether an illness resolves or persists, read from the 6th cusp sub lord's star lord: its highest signification level for the 11th (recovery) against the 8th (chronic). When that star lord also signifies the bhadhaka for the lagna's mobility (movable 11, fixed 9, dual 7) the levels are adjusted and 'bhadhaka.adjustment' says how. Reads no period and no transit. Returns '{ sixthCSL, sixthCSLStarLord, starLordSignifications, recoveryLevel, chronicLevel, recoveryLevelName, chronicLevelName, outcome: RECOVERY | CHRONIC | UNCERTAIN, bhadhaka: { lagnaSign, mobility, bhadhakaHouse, starLordSignifiesBhadhaka, adjustment, rationale }, notes, summary, disclaimer }'. The same block 'get_medical_timing' returns as 'recoveryChronic', with the disclaimer beside it. Supplementary lens, not medical advice.

T24: whether surgery is promised and when it falls due. The promise: the 1st, 6th and 8th cusp sub lords must each signify one of 1/6/8/12; the 8th CSL's star lord is reported and gates nothing (F059). The periods: every MD-AD-PD whose three lords signify 1/6/8/12, the AD lord at L1 or L2, in confidence order (an engine weighting, not a KSK figure). The Moon windows: hours in the first 90 days of the top period when the transit Moon's star and sub lords are both significators of 1/5/11, read as post-surgery recovery; they ride with the periods because they are anchored on the top one. Returns '{ isPromised, promiseDetails: { firstCSL, sixthCSL, eighthCSL, allPromise, verdict, notes }, requiredHouses, candidatePeriods: [{ startDate, endDate, mahadasha, antardasha, pratyantardasha, mdHouses, adHouses, pdHouses, adHighestLevelWeight, adIsL1L2, jointCoverage, confidence, reasons }], moonTransitWindows: [{ startDate, endDate, moonStarLord, moonSubLord, matchedSignificator, matchedHouses }], summary, disclaimer, pagination, pageNote }'. **'candidatePeriods' is paged.** The same block 'get_medical_timing' returns as 'surgeryTiming', with the disclaimer beside it. Supplementary lens, not medical advice; never delay or schedule care on it.

Answers whether an operation will go WELL (get_medical_timing answers WHEN). Natal promise: 1st CSL must not signify 8/12 at L1 (vitality through the operation), 11th CSL on 1/5/11 (fulfilment), 8th CSL on 6/8/12 without 11 (complication-risk pattern), 6th CSL on 11 (disease removed), plus a natal Mars (surgeon's karaka) retrograde caution. Mars's combustion is reported and does not disqualify the karaka or move the score: KP reads the outcome from the 8th cusp sub lord's significations (F066, Q023 section 20). Returns successVerdict FAVOURABLE/GUARDED/UNFAVOURABLE, complicationRisks (Saturn prolonged recovery, Rahu/Ketu anaesthesia and unexpected findings, Mars bleeding tendency), recoverySpeedClass. With surgery_date it also grades the day itself: MD/AD/PD lords, transit Mars retrograde means DEFER (KP retrograde invalidation), ruling planets must carry a 1/5/11 significator, transit Moon star/sub hostility; dateVerdict GO/DEFER/RESCHEDULE with deferReasons and every recommendedWindow within 90 days when the date is not clean. Never replaces medical judgment, and emergency surgery is never delayed for astrology.

Answers 'which system of medicine will work?' by reading three cusp sub lords: the 6th CSL (nature of the cure agent), the 11th CSL (what delivers the cure), and the 12th CSL (hospital vs home). Each CSL's planet maps to modalities (Sun = allopathy/hospital, Moon = diet/counselling/homeopathy, Mars = surgery, Mercury = diagnostics-led/physiotherapy/mixed pathies, Jupiter = ayurveda/herbal, Venus = comfort/naturopathy, Saturn = long-term regimen/chronic care, Rahu = experimental/foreign/strong drugs, Ketu = faith healing/alternative medicine) and is scored 11th x3, 6th x2, 12th x1 with star lords at half weight. Extra verdicts: surgical route indicated (Mars on the 6/11 cure axis plus 8th CSL signifying 8), hospital vs home care, and doctor change (10th CSL signifying 6/8/12 at L1/L2). Optionally pass current_treatment for an ALIGNED / PARTIAL / MISALIGNED verdict against the ranking. Natal-only, no dasha walk. Supplementary lens, not treatment advice.

Constitutional resilience and immunity score (0-100) with a recuperation class (FAST_HEALER/AVERAGE/SLOW_HEALER/FRAGILE). Components, each itemized in a factors array: the 1st CSL's 1-5-11 vs 6-8-12 significations (weighted L1=4..L4=1); the 1st CSL's STAR LORD on the same test, weighted higher (the real decider in KP) including its retrograde state; lagna lord placement; Sun (vital fire) and Moon (fluids/resistance) affliction via dusthana placement or Saturn/Mars/Rahu/Ketu conjunction within 8 degrees. Combustion (graded NONE/ORDINARY/FULL) and dignity are REPORTED in the factors and move no points: KP reads vitality from the 1st cusp sub lord's significations, and a planet's own dignity or combustion decides nothing (F066, Q023); a resistanceRatio from 1st-vs-6th house strength scores; and a penalty when the bhadhaka lord occupies or aspects the 1st house. Also returns susceptibilityBias (inferred weak areas). Supplementary lens, not medical diagnosis; no death prediction.

KP financial/speculative analysis: Jupiter-Rahu combination detection (highest-probability speculative gain when both signify 5th/2nd/11th and are jointly active in dasha) and 8th-12th loss confirmation (maps high-risk dasha periods and Moon transit dates when loss significators dominate). Returns '{ jupiterRahuCombination, lossConfirmation, summary, methodSeams, pagination, pageNote }'. **'lossConfirmation.lossDashaPeriods' and 'lossConfirmation.moonTransitRiskDates' are paged together**: page N carries the Nth page of each, and a list that ends first is empty on the later pages, which 'pageNote' names. Each technique is also a tool of its own, named in 'methodSeams': 'get_jupiter_rahu_combination' and 'get_financial_loss_periods'.

T28: the L1 and L2 significators of the 8th and 12th, the dasha periods whose Mahadasha, Antardasha and Pratyantardasha lords all signify a loss house, ranked by 'confidence' (a Lumin weighting of the houses covered, not a probability), and the Moon transit risk windows over the first 90 days of the first-ranked period, where the transit Moon's star and sub lords are both loss significators. Returns '{ lossHouses, l1l2Significators: [{ planet, level, houses }], lossDashaPeriods: [{ startDate, endDate, mahadasha, antardasha, pratyantardasha, mdHouses, adHouses, pdHouses, jointCoverage, confidence, reasons }], moonTransitRiskDates: [{ startDate, endDate, moonStarLord, moonSubLord, matchedSignificator, riskLevel }], notes, summary, pagination, pageNote }'. **'lossDashaPeriods' and 'moonTransitRiskDates' are paged together**: page N carries the Nth page of each, and a list that ends first is empty on the later pages, which 'pageNote' names. The same block 'get_financial_analysis' returns as 'lossConfirmation'.

T27: whether Jupiter and Rahu both signify the wealth houses 2, 5 and 11 and both run in the coming dasha periods, the speculative-gain combination. The scan reads the next 10 Jupiter or Rahu antardashas from today and stops; 'activeDashaPeriodsCap' says so. Returns '{ jupiterSignifiedHouses, rahuSignifiedHouses, wealthHouses, jupiterCoversWealth, rahuCoversWealth, bothCoverWealth, jupiterInActiveDasha, rahuInActiveDasha, bothInDasha, combinationActive, activeDashaPeriods: [{ startDate, endDate, mahadasha, antardasha, hasJupiter, hasRahu }], activeDashaPeriodsCap, notes, summary }'. The same block 'get_financial_analysis' returns as 'jupiterRahuCombination'.

Minute-by-minute scan of a target trading day finding personal-chart windows where (a) Lagna sub-lord signifies any of the KP speculation houses [2, 5, 11], (b) Moon's sub-lord is clear of [6, 8, 12] problem houses, and (c) no Saturn/Jupiter retrograde invalidation. Per-window: HH:MM bands, lagna sub-lord, speculative coverage, moon clearance, retrograde flags, score 0-100. Day label: STRONG_FAVORABLE / WEAK_FAVORABLE / NEUTRAL / UNFAVORABLE relative to the native's personal chart. THIS IS PERSONAL PATTERN MATCHING, NOT FINANCIAL ADVICE OR BUY/SELL SIGNALS; tool output must never be presented as a market call, trade recommendation, or alpha signal. Defaults to NSE hours (09:00-15:30 IST) at Mumbai; override via trading_*_utc + trading_lat/lon.

The first three children read off their own cusps, the 5th, 7th and 9th: each cusp's sub lord against 2/5/11, promised when it signifies at least two of them. Returns '{ multipleChildren: [{ childIndex, house, cuspSubLord, cslSignifies, promiseHousesCovered, isPromised, summary }], bookCitations, disclaimer }'. The same list 'get_fertility_window' returns as 'multipleChildren'. Supplementary lens, never a fertility diagnosis.

KP fertility-readiness lens. Promise check: 5th-cusp sub-lord must signify 2/5/11 (promise) and not 1/4/10 (denial), not retrograde, star lord not retrograde. Outputs overall verdict (NATURAL / IVF_OR_ASSISTED / DELAYED / DENIED / MIXED), Jupiter karaka health check, 5th-cusp sign affinity (fruitful: Cancer/Scorpio/Pisces; barren: Aries/Gemini/Leo/Virgo), per-child analysis (1st = 5th house, 2nd = 7th, 3rd = 9th), natural-conception dasha windows, IVF/assisted-reproduction signals (retrograde 5th CSL, Saturn/Mars/Rahu in 5th), miscarriage risk score (5+8 mixed-active). Retrograde is read as KP reads it, Rahu and Ketu never (Reader 6 canon p.114); the astronomical reading, nodes always retrograde, rides beside it as 'promise.retrogradeReading' with the promise verdict it gives (F160). Books: KP Reader 4 children chapters, Aryan Astrology Research Centre, bestkpastrologer.com (Partha Sarathi Rout). Supplementary lens, not diagnostic; never a substitute for clinical fertility evaluation. Hard-disable any gender-of-child output for IN deployments (illegal under PCPNDT). Each part is also a tool of its own, named in 'methodSeams': 'get_progeny_promise', 'get_conception_windows' (paged) and 'get_multiple_children'. Call those when a reading needs one; this tool returns every part in one call.

The MD-AD-PD periods whose three lords all signify one of 2/5/11, each with the loss (6/8/12) and denial (1/4/10) houses the lords also touch, in confidence order (an engine weighting, not a KSK figure). Returns '{ naturalConceptionWindows: [{ startDate, endDate, mahadasha, antardasha, pratyantardasha, promiseHousesCovered, lossHousesCovered, denialHousesCovered, confidence, rationale }], bookCitations, disclaimer, pagination, pageNote }'. **'naturalConceptionWindows' is paged.** Read 'get_progeny_promise' first: a window is a period, not a promise. The same list 'get_fertility_window' returns as 'naturalConceptionWindows'. Supplementary lens, never a fertility diagnosis.

Sensitive child-survival risk lens for paediatric / fertility / IVF advisor tooling, scored on a child's natal chart. Distinct from get_longevity_balarishta (which targets adults). Tests classical balarishta combinations (Moon in 6/8/12 plus Saturn/Mars affliction, Saturn/Mars on lagna, 8th lord in 1st, 5th CSL signifies 8/12) plus mitigating signals (Jupiter in kendra, full 2+5+11 promise, Moon dignified). Score 0-100 maps to riskBand NONE/LOW/NOTABLE/HIGH. Supplementary lens, not diagnostic. B2B advisor-tooling only; never communicate raw output to a parent or caregiver.

Whether children are promised. The 5th cusp sub lord on 2/5/11 (promise) against 1/4/10 (denial), its retrograde state and its star lord's (read as KP reads motion, the nodes never retrograde; 'promise.retrogradeReading' carries the astronomical reading beside it, F160); the Jupiter karaka on 6/8/12; the 5th cusp sign as fruitful, semi-fruitful or barren. The three combine into 'overallVerdict'; the IVF/assisted signals and the miscarriage score (an engine figure) are read off the same promise. Returns '{ overallVerdict: NATURAL | IVF_OR_ASSISTED | DELAYED | DENIED | MIXED, promise: { fifthCSL, fifthCSLStarLord, fifthCSLRetrograde, fifthCSLStarLordRetrograde, cslSignifies, promiseHousesCovered, denialHousesCovered, lossHousesCovered, miscarriageSignal, promiseVerdict, rationale, retrogradeReading }, jupiterKaraka: { jupiterSignifies, afflictedHouses, isAfflicted, rationale }, fifthCuspSign: { sign, classification, rationale }, ivfOrAssistedSignals, miscarriageRiskScore, bookCitations, disclaimer }'. The same fields 'get_fertility_window' returns under those names. Supplementary lens, never a fertility diagnosis.

Two statements the corpus makes, kept apart. The traditional general rule KSK prints in Reader 2: the 5th cusp's sign, the 5th lord's gender (BPHS ch. 3 v. 19: Sun, Mars, Jupiter male; Moon, Venus female; Mercury, Saturn neuter) and the sign it occupies, masculine for boys and feminine for girls, three testimonies counted and reported. And the one KP delivery case in Reader 4: the running antara and sookshma lords AT THE DELIVERY being male planets read a son, with KSK's own words carried, 'I never had any experience in pin-pointing the sex before birth'. Pass delivery_date to compute the second; without it the field says why it waits. The count of children is NOT computed: no Reader page searched states a number, and a count crosses the wire with its page or not at all. A disclaimer travels on the payload; nothing here is a verdict.

Scores the chart against 7 education tracks (IAS/Civil Services, IIT/Engineering, IIM/Management, Medicine, Law, PhD/Research, Arts/Creative) per KP Reader 3 ch.15, 25-26, 45 plus applied web canon. Each track gets a 0-100 score with concrete signature hits. Also returns scholarshipProbability (2nd+4th+11th+Jupiter), abroadEducationPromise (9th+12th+4th+Rahu over 9/12), and exam-success windows: dasha periods (next 15 years) where MD+AD light up the canonical exam houses [4, 9, 11], ranked PEAK/STRONG/WEAK.

Study abroad from the 12th cusp sub lord, the rule KP Reader 6 states verbatim: if the 12th cusp sub lord is a significator of the 3rd, 9th or 12th, one goes abroad; the 9th, where it is deposited or which it signifies, indicates higher studies; the 11th with the 6th together reads a scholarship. Reader 3 separates studies (the 9th) from work abroad (the 6th and 10th, which get_foreign_job_verdict reads). The page's retrograde condition (the sub lord or its star lord retrograde denies) is a HORARY denial; on a natal chart it is reported with gatesVerdict false and carried as a delay signal, and 'horaryReading' says what the page would say. Motion is read as KP reads it, Rahu and Ketu never retrograde (Reader 6 canon p.114); 'motion.astronomical' carries the chart flag's reading beside it (F160). Returns the promise, the higher-studies and scholarship reads with their basis, and a timing note for find_event_timing_v2 on 3, 9, 12. Emits no score.

KP three-stage foreign settlement analysis: Stage 1 (decision to leave, houses 3+12), Stage 2 (journey, houses 9+12), Stage 3 (permanent settlement, 4th house connected to 12th). Each stage has independent CSL promise check and dasha timing. Verifies stages are chronologically sequential.

KP timing for visa, immigration paperwork, contracts, and other documentation processes. Surfaces the 3rd-house Stage 1 from foreign-settlement as a discrete approval-milestone analysis. Returns verdict (PROMISED/DELAYED/DENIED), 3rd CSL signification of 3+9+11 (documentation promise group), all documentation-window dasha periods, and a filtered approval-likely subset (Jupiter-active windows with no retrograde impact). Retrograde is read as KP reads it, Rahu and Ketu never (Reader 6 canon p.114); the astronomical reading, nodes always retrograde, rides beside it as 'retrogradeReading' with the verdict it gives (F160). Books: KP Reader 3 ch.24-26.

KP litigation and detention analysis: litigation outcome prediction (compares 11th house L1/L2 strength vs 7th house activation, Jupiter transit for judgment year) and bail/detention timing (12th house AD = detention window, next 11th house AD = release, Moon transit = specific date).

Calendar wrapper around legal-analysis. Returns structured filing-window dates (Jupiter transits through 11th-house significators), a single judgment-month label, bail/detention windows by AD, appeal windows when verdict is UNFAVORABLE, and an imprisonment-risk score (0-100). Books: KP Reader 3 ch.47, 57-60, 69-72, pages 481, 498. Not legal advice; for advisor or litigant strategy support only, never a substitute for licensed counsel.

KP property purchase analysis. 4th cusp signifies 4+11 maps to BUY; signifies 3/12 without 4/11 maps to AVOID; retrograde 4th CSL with promise maps to DEFER; 6+9 dominance maps to RENT_ONLY. Returns verdict, risk flags (retrograde, 12th-house foreign-property risk, 3rd-house relocation tendency, rental pattern), and best-purchase windows when verdict is BUY/DEFER. Retrograde is read as KP reads it, Rahu and Ketu never (Reader 6 canon p.114); the astronomical reading, nodes always retrograde, rides beside it as 'retrogradeReading' with the verdict it gives (F160). Books: KP Reader 3 ch.13-14, 43-44, KP Reader 6 cases 41-47.

Per-relative analysis using natural karakas: Father (Sun + 9th), Mother (Moon + 4th), Siblings (Mars + 3rd/11th), Children (Jupiter + 5th), Spouse (Venus for males / Jupiter for females + 7th). Each entry returns karaka placement, dignity, combust/retrograde flags, and qualitative scores (health, relationship, longevity 0-100), plus current dasha activation. Use for any 'how is my [relative]?' question.

Andrew Dutta's Rule of Origin: a correctly-rectified birth chart will have the Lagna's star/sub lord connected to the 9th cusp's star/sub lord. Returns verdict DIRECT (same planet match — score 2, HIGH confidence in birth time), INDIRECT (third-planet bridge — score 1, MODERATE), or NONE (no connection — score 0, LOW; birth time likely needs rectification). Use as a fast pre-flight check on any birth chart before deeper readings.

Find an UNKNOWN birth time using the KP Ruling Planets method. Scans all 1440 minutes of a birth date for candidate windows whose ascendant sign/star/sub-lords match the RPs at a query moment (typically when the querent asked the question). Optional validation against known life events. Returns '{ candidates: [{ time, ascSignLord, ascStarLord, ascSubLord, score, eventMatches }], bestCandidate }'. For *refining* an approximately-known time, use 'rectify_birth_time' instead.

Refine an uncertain birth time by testing ±30 min around the stated time against known life events. Requires at least 1 known event with date and houses that should have been active. Returns '{ candidates: [{ datetime, score, eventMatches[] }], bestCandidate, originalTime, refinedTime }'. For RP-confirmation rectification using event location (more rigorous) use 'rectify_by_event_ruling_planets'. For finding entirely-unknown birth time use 'find_birth_time'.

[KP] Rebuilds the chart across the birth-time uncertainty the user states and reports exactly which cusp sub lords change, at which minute, and which promise verdicts change between which values. Use it BEFORE stating any verdict whenever the user knows their birth time only roughly ('about 7:20', 'to the nearest five minutes'): measured over 48 charts ('scripts/bp022-birth-time-spread.ts'), at plus or minus 5 minutes 72.9% of promise verdicts change inside the window and 51.3% cross DENIED. Every instant at which a cusp or planet changes sign, star, sub or house, or a node gains or loses a conjunction or aspect, is solved to the second, and the same gate analyze_natal_promise runs is re-run between those instants (never on a grid). Returns per cusp the stated lords, every change with its minute and 'subLordHoldsOver' (the stretch of birth times over which the stated sub lord holds); per planet its house and lord changes; 'nodeContactChanges'; and per event 'timeStability' ('stable' or 'changes'), 'verdictsInWindow', 'crossesDenied', 'statedVerdictHoldsOver', 'firstChangeMinutes' (the nearest minute, signed, at which the verdict becomes something else), 'intervals' with the deciding CSL, and 'changes' each naming its 'causes'. READ 'summary.eventsStable' FIRST: those verdicts rest on nothing the uncertainty moves and can be stated outright. A verdict marked 'changes' is not settled until the time is rectified (rectify_birth_time, rectify_by_event_ruling_planets): give the reading on each side of the minute that separates them, or rectify first. The source is Astro Secrets canon p.180 (a later author, not KSK): 'in case birth time given is wrong, it has to be rectified. Otherwise cuspal sublords and planet sublords will vary'. The window is the user's own figure: never invent one, and ask when it is unknown. Nothing is scored, ranked or weighed and no minute is picked. **'cusps' and 'events' are paged together**: page N carries the Nth page of each, cut to its own row weight, and a list that ends sooner is empty on the pages after its last (the page note says which); 'planets', 'nodeContactChanges' and 'summary' repeat whole on every page.

KP birth time rectification by event ruling planets (T42, renamed from get_rectification_advanced on 2026-10-08): for each candidate minute in the range, and each known life event (with date AND location), computes the Ruling Planets at that event moment and checks their overlap with the candidate chart's fruitful significators for the event, plus whether the candidate's dasha at the event date signifies its houses. Returns '{ originalTime, searchRange, knownEvents, minEventThreshold, confidence: STRONG | MODERATE | WEAK | INSUFFICIENT, confidenceRationale, candidates: [{ adjustmentMinutes, datetime, ascendantSign, ascendantDegree, rpScore, dashaScore, combinedScore, eventMatchCount, eventTotalCount, rpEventDetails, dashaDetails }], bestMatch, confidenceWindow, summary }'; **'candidates' is paged**. The scores are engine weightings; 'confidenceWindow' is the span of minutes that fit the events as well as the best one does.

[RENAMED, use rectify_by_event_ruling_planets] The same tool under its old name, kept for one release so existing callers keep working. It returns exactly what rectify_by_event_ruling_planets returns: candidates (paged), bestMatch, confidence and confidenceWindow.

A check on the birth time: whether the Ascendant's sign lord, star lord and sub lord are among the ruling planets of the birth moment. 'verification_score' is how many of the three are (0 to 3); 'verdict' is CONFIRMED (star and sub) / LIKELY_ACCURATE / UNCERTAIN / UNCONFIRMED. Returns '{ ascendant_longitude, ascendant_sign, ascendant_sign_lord, ascendant_star_lord, ascendant_sub_lord, rps_at_birth, sign_lord_in_rps, star_lord_in_rps, sub_lord_in_rps, verification_score, verdict, confidence, notes }'. For a fuller rectification use 'rectify_by_event_ruling_planets'. The same block 'get_profession_indicators' returns as 'ruling_planet_applications.chart_verification'.

Takes two birth datetimes (typically 1-10 minutes apart) and computes how the twins' KP charts diverge: per-cusp longitude shift, sign / sign-lord / star-lord / sub-lord deltas, dasha balance diff (first MD lord, balance fraction, MD-end delta-days), per-event verdict / coverage / CSL deltas, and 'first material divergence age' (earliest age where MD or AD lords meaningfully differ). KP-precision proof-of-concept lens; the single strongest counter-argument to 'all twins get the same chart'.

Computes a single weighted 0-100 divergence score between two birth charts (twins or rectification candidates). Per-cusp impact weighted by life-domain criticality (7th and 10th highest at weight 10; 8th at 9). CSL change contributes full weight, star-lord change half, sub-sub-lord change a quarter. Use to communicate "your twin diverges X/100" in a single headline number.

[Vedic Parashari adjunct] D45 divisional chart per BPHS ch.6. Each natal sign divided into 45 parts of 0.667°, character, conduct, paternal lineage. Returns D45 ascendant, placements, 1st-house readout.

[Vedic Parashari adjunct] D8 divisional chart. NOT one of BPHS's sixteen divisions and found in no classical text searched; the construction is P.V.R. Narasimha Rao (2001), a modern source that says D-8 has different versions: movable signs from Aries, fixed from Sagittarius, dual from Leo. The rule this tool used before 2026-09-27 (even signs from the 5th, no source) rides beside it in 'alternativeReadings'; each block carries 'reading' and 'readingSource', and 'notInBphsSixteen' is true. Each natal sign divided into 8 parts of 3.75°, longevity, sudden events. Returns D8 ascendant, placements, 8th-house readout. Companion to get_longevity_balarishta.

[Vedic Parashari adjunct] D4 divisional chart per BPHS ch.6. Each natal sign divided into 4 parts of 7.5°, fixed assets, real estate, vehicles, shelter. Returns D4 ascendant, placements, 4th-house readout. Pairs with get_property_decision.

[Cross-system reference tool] Chaturvimsamsa / Siddhamsa (D24) divisional chart per BPHS ch.6. Each natal sign divided into 24 parts of 1°15'. Used for education / academic-success analysis. Returns D24 ascendant, planet placements, vargottama flags, and 4th house (learning) readout. Pairs with get_education_signature for ed-tech embeds.

[Vedic Parashari, non-KP reference] Dasamsa (D10) divisional chart per BPHS ch.6. Each natal sign divided into 10 parts of 3°. Used in Vedic tradition for career analysis. D-10's even-sign rule is DISPUTED and both readings are returned, neither called classical: the top-level block counts even signs from the 9th, 'alternativeReadings' holds the always-from-the-sign block, each with 'reading' and 'readingSource', and 'readingNote' says why. Returns '{ reading, readingSource, d10Ascendant, d10Planets: [{ d10Sign, d10SignLord, d10House, isVargottama }], d10HouseLords, careerIndicators: { d10_10thLord, planetsIn10th, strongestCareerPlanet }, alternativeReadings, readingNote }'. Note: KP methodology uses 'get_profession_indicators' (10th-house CSL) and 'get_career_signature' for career, NOT D10. This tool is for cross-system / Vedic-Parashari consumers.

[Vedic Parashari adjunct] D3 (Drekkana) divisional chart per BPHS ch.6. Each natal sign divided into 3 parts of 10° each, siblings, courage, enterprise, initiative. Returns D3 ascendant, placements, vargottama flags, 3rd house readout.

[Vedic Parashari adjunct] D12 divisional chart per BPHS ch.6. Each natal sign divided into 12 parts of 2.5°, parents, lineage, prenatal karma, ancestral patterns. Returns D12 ascendant, placements, 9th-house readout. High demand for family-themed apps.

[Vedic Parashari adjunct] D2 (Hora) divisional chart per BPHS ch.6. Each natal sign halved into solar/lunar Hora, wealth-acquisition ability. Returns D2 ascendant, planet placements (split by Sun's hora vs Moon's hora), vargottama flags.

[Vedic Parashari adjunct] D40 divisional chart per BPHS ch.6. Each natal sign divided into 40 parts of 0.75°, general auspiciousness, maternal lineage. Returns D40 ascendant, placements, 4th-house readout.

[Vedic Parashari, non-KP reference] Navamsa (D9) divisional chart per BPHS ch.6. Each natal sign divided into 9 padas of 3°20'. Used in Vedic tradition for marriage assessment, dharma, and overall planetary strength. Returns '{ d9Ascendant, planets: [{ d9Sign, d9Lord, d9Dignity, d9House, isVargottama }] }'. Note: KP methodology uses 'analyze_natal_promise' (CSL-based) for marriage, NOT D9. This tool is for cross-system / Vedic-Parashari consumers.

[Cross-system reference tool] Saptamsa (D7) divisional chart per BPHS ch.6. Each natal sign divided into 7 parts of 4°17'08". Used for children / progeny analysis. Returns D7 ascendant, planet placements, vargottama flags, and a focused readout of the 5th house (children house). Pairs with get_fertility_window for fertility-clinic embeds.

[Vedic Parashari adjunct] D27 divisional chart per BPHS ch.6. Each natal sign divided into 27 parts of 1.111°, inherent personality strengths and weaknesses. Highly precise division. Returns D27 ascendant, placements, 1st-house readout.

[Vedic Parashari adjunct] D6 divisional chart. NOT one of BPHS's sixteen divisions and found in no classical text searched; the construction is P.V.R. Narasimha Rao (2001), a modern source: odd signs counted from Aries, even from Libra. The rule this tool used before 2026-09-27 (even signs from the 7th, no source) rides beside it in 'alternativeReadings'; each block carries 'reading' and 'readingSource', and 'notInBphsSixteen' is true. Each natal sign divided into 6 parts of 5°, debts, illness, conflicts. Returns D6 ascendant, placements, 6th-house readout. Companion to get_chronic_disease_panel.

[Cross-system reference tool] Shashtiamsa (D60) divisional chart per BPHS ch.6. Each natal sign divided into 60 parts of 0°30' (the highest-resolution division). Used for deep karma / total chart fingerprint. Highly birth-time-sensitive, also serves as a rectification stress-test. D-60 is computed three ways (BPHS ch.6 v.33, Santhanam): the top-level block counts the 0°30' part from the planet's own sign, which is how both translators' worked examples apply the verse (classical; the primary, and the one get_vimsopaka_bala grades), 'alternativeReadings' carries the literal count from Aries (disputed, it rests only on one English rendering) and the engine's pre-2026-09-27 even-from-7th rule (labelled unsourced), and 'readingComparison' gives each body's sign under all three. Each block names its 'reading' and 'readingSource'. Returns D60 ascendant, placements, vargottama flags, and 1st-house (karma) readout.

[Vedic Parashari adjunct] D16 divisional chart per BPHS ch.6. Each natal sign divided into 16 parts of 1.875°, movable assets, vehicles, life comforts. Returns D16 ascendant, placements, 4th-house readout.

[Vedic Parashari adjunct] D30 divisional chart per BPHS ch.6, misfortune, arishta, mental tendencies. Uses canonical Parashara mapping (odd vs even sign portions to different planet's signs). Returns D30 ascendant, placements, 6th-house readout.

[Vedic Parashari] Parashari, not KP. The sibling of get_frame_spread for the divisional charts. Two vargas are disputed in construction and the Vimsopaka has four schemes, and this reports WHICH CONCLUSIONS MOVE between them. 'bodies': every planet, both nodes and the lagna, with its D-10 sign under both readings (even signs from the 9th, primary, or always from the sign; A13 calls neither classical) and its D-60 sign under all three (the own-sign count, classical and primary; the literal count from Aries, disputed; the engine's pre-2026-09-27 rule, unsourced), each with 'moves'. 'planets' (the seven): the Vimsopaka under every scheme and every reading, one row each: Shadvarga, Saptavarga under the translators' table and under BPHS 27.4's order (the assignment is disputed, Q043), and Dasavarga and Shodasavarga under each of the 2 x 3 D-10 and D-60 readings; the 'primary' row of each scheme is exactly get_vimsopaka_bala's 'schemeTotals'. 'movesAt' names the axes that change one scheme's total with the others held at the primary; 'summary.holding' names the planets nothing moves. Measured over 200 charts (1,400 planet readings) through this tool ('lumin-engine/scripts/bp024-varga-scheme-spread.ts'): the Saptavarga assignment moves the total on 92.6% of planets (by up to 2.28 of 20), the D-60 reading moves the Dasavarga and Shodasavarga on 82.6%, the D-10 reading on 33.2%; only 2.8% of planets hold on every axis and no chart held entirely; the D-10 lagna moves on 50.0% of charts and the D-60 lagna on 92.5%. So a Vimsopaka figure is a statement under a named scheme and reading: say which. Each total is the classical sum and nothing is formed from the totals: NO SCORE, RANK, AVERAGE OR BEST scheme. Rahu and Ketu grade neutral everywhere and carry no totals. Gates no KP verdict.

[Vedic Parashari adjunct] D20 divisional chart per BPHS ch.6. Each natal sign divided into 20 parts of 1.5°, spiritual life, sadhana, religious devotion. Returns D20 ascendant, placements, 9th-house readout. Pairs with get_ishta_devata.

[Vedic Parashari] Sarvashtakavarga and Prastarashtakavarga bindu tables, the Parashari strength system counting bindus per SIGN per planet (BPHS chs.66-72). Returns '{ frame: 'sign', prastarashtakavarga: { Sun..Saturn: { matrix, sign_scores, total_bindus } }, sarvashtakavarga: { sign_scores, total_bindus, strongest_signs, weakest_signs, average_score } }'. Every 12-slot array is indexed by SIGN, index 0 = Aries. The total is always 337 and the per-sign benchmark is 28.08. Higher bindus = better activation of that sign; used alongside dasha for transit-strength weighting.

Detect 5 classical chart afflictions (doshas). **Manglik** (Mars in 1/2/4/7/8/12, marriage friction), **Kalsarpa** (all 7 visible planets between Rahu and Ketu, for variant typing use 'get_kalsarpa_variants'), **Sadhesati** (7.5-yr Saturn transit, for phase breakdown use 'get_sade_sati_phases'), **Pitra Dosha** (paternal-lineage karma signature), **Kemadruma** (Moon isolation, no planets in 2nd/12th from Moon). Returns '{ doshas: [{ name, plainName, present, severity, details, plainMeaning, cancellations[], remedies[], provenance }] }'. **Read 'provenance' before repeating any of it.** Manglik, Sadhesati and Kemadruma are 'classical' with a locus; **Kalsarpa and Pitra Dosha are 'unsourced'** — no classical text and no page of the 5,045-page KP corpus contains either, so both report 'severity: 'Present'' with no grade, and their invented Severe/Moderate bands were removed (F054). 'plainMeaning' is the reader-facing sentence and assumes no Sanskrit.

Detects Kala Sarpa Yoga and identifies the specific variant by Rahu's house (1: Anant, 2: Kulik, 3: Vasuki, 4: Shankhpal, 5: Padma, 6: Mahapadma, 7: Takshak, 8: Karkotak, 9: Shankhachoor, 10: Ghatak, 11: Vishadhar, 12: Sheshnag). Returns full vs partial classification (PARTIAL = 1-2 planets just outside the Rahu-Ketu axis), arc direction, theme description per variant, effects, and remedies. Books: KP Reader 3 ch.42, Sanatan Veda canon.

[Vedic Parashari adjunct] Shubha Kartari (lagna flanked by benefics) + Papa Kartari (lagna flanked by malefics), evaluated for the LAGNA only, flanking read from the Placidus 12th and 2nd houses. Malefics counted are Saturn, Mars, Rahu and Ketu; the Sun is not counted, and each row says so. Common in chart consultations. Returns each yoga's presence, strength, forming planets, effects.

Parashari, not KP. The 32 Nabhasa yogas of Brihat Parashara Hora Shastra ch. 35, each constructed from its verse: 3 Asraya (Rajju, Musala, Nala: all seven planets in movable, fixed or dual SIGNS), 2 Dala (Mala, Sarpa: three kendras held by benefics or by malefics), 20 Akriti (the shapes: Gada, Sakata, Vihaga, Shringataka, Hala, Vajra, Yava, Kamala, Vapi, Yupa, Shara, Shakti, Danda, Nauka, Koota, Chatra, Chapa, Ardhachandra, Chakra, Samudra, by which whole-sign bhavas from the lagna the seven occupy) and 7 Sankhya (Gola through Veena, by how many signs the seven occupy). Every one of the 32 is returned, present or not, so an absence is stated rather than omitted. Two things the text settles that a summary would not: 'all the Grahas' is the SEVEN, the nodes excluded (v. 13), and v. 17's precedence is applied as a rule: a Sankhya yoga is reported only when no other Nabhasa yoga is present, and a suppressed one is named with what it yields to. A consequence pinned by test: all seven in one sign is never Gola, because an Asraya yoga is then trivially present. Effects (vv. 18-50) are not transcribed. Benefic and malefic follow ch. 34 vv. 8-10, the same definition the avasthas use. Edition stated (Santhanam 1984). Gates no KP verdict.

[Vedic Parashari adjunct] Structural-affliction panel: Daridra (11th lord in 6/8/12), Shakata (Moon in 6/8/12 from Jupiter, counted by sign), Vish (Saturn-Moon close conjunction), Guru-Chandala (Jupiter-Rahu/Ketu conjunction). Each returns presence, strength, description, effects. Lordship and distance are whole-sign from the Lagna sign, with the Placidus house reported beside it where they differ. No classical locus was located for any of these four, so the response carries a scoreProvenance block naming the orbs and bands as Lumin conventions.

[Vedic Parashari adjunct] Sign-exchange yoga in 3 classes: Maha (kendra-trikona lord exchange, strongest fortune amplifier), Khala (3rd-lord exchange, energising effort), Dainya (exchange with dusthana lord, afflicted). Returns each detected pair with classification, forming planets, and effects.

[RENAMED, use detect_raja_and_lunar_yogas] The same tool under its old name, kept for one release so existing callers keep working. It returns exactly what detect_raja_and_lunar_yogas returns: yogas, totalPresent and summary.

Detects classical yogas not covered by detect_yogas (renamed from get_yogas_advanced on 2026-10-08): two Raja yogas and five yogas read from the Moon. Vipreet Raja (Harsha 6th-lord, Sarala 8th-lord, Vimala 12th-lord placed in dusthanas), Neecha Bhanga Raja Yoga (4 cancellation rules for debilitated planets), Adhi Yoga (benefics in the 6th/7th/8th signs from the Moon), Sunafa (planets in the 2nd sign from the Moon), Anafa (12th sign), Durdhura (both), all counted sign to sign with the Sun and nodes not eligible, the same rule check_doshas uses for Kemadruma, so the two never both fire, and Chandra-Mangal (Moon-Mars conjunction or opposition). Returns '{ yogas: [{ name, category: Vipreet | NeechaBhanga | Adhi | Lunar | Conjunction, present, strength, formingPlanets, description, effects }], totalPresent, summary, houseConvention }'.

[Vedic Parashari adjunct] Vasi (planet in the 12th SIGN from the Sun), Vesi (planet in the 2nd sign from the Sun), Ubhayachari (both occupied), counted sign to sign, the Moon and nodes not eligible. Companion to lunar yogas already in detect_raja_and_lunar_yogas. Each yoga returns presence, strength, forming planets, description, effects.

[Vedic Parashari] Detect classical planetary yogas, special combinations producing distinctive life patterns. Includes Raja Yoga (a kendra lord and a trikona lord by whole-sign lordship in exchange, in one sign, or in mutual full aspect, BPHS 34.11-12 and 39.33-38, one row per pair; pairs 34.15 cancels are listed in 'rajaYogaPairs'; Yogakaraka rows per 34.13), Dhana Yoga (the 2nd and 11th lords per BPHS 13.4-5 by the Sanskrit, with Santhanam's English reading in 'variantReadings'; the 41.16 givers of wealth, the 5th and 9th lords, in 'dhanaGivers'), Gajakesari in BOTH its BPHS recensions, labelled and neither picked (Jupiter in a kendra from the lagna or the Moon with a benefic and not debilitated, combust or in an enemy's sign, 36.3; and the Moon-only form), Lakshmi (the 9th lord in a kendra in its own, moolatrikona or exaltation sign, 36.27; the lagna lord's strength is not evaluated and the row says so), Budh-Aditya (Sun and Mercury in one sign → intellect; Mercury's combustion is reported, not applied), Pancha Mahapurusha (5 'great person' configurations, one row per qualifying planet), Saraswati, Amala, Vish, Chatursagara. Every lordship row carries 'source'. The rules these four used before 2026-09-28 (Placidus occupancy and degree orbs) ship uncounted in 'legacyRows', labelled unsourced, and 'corpusPosition' records that KP Reader 3 rejects these yogas as a method. Returns '{ yogas: [{ name, category, present, strength, formingPlanets[], description, effects, source? }], totalPresent, beneficYogas, maleficYogas, rajaYogaPairs, dhanaGivers, legacyRows, corpusPosition }'. For Vipreet/Neecha-Bhanga/Adhi/Lunar/Chandra-Mangal yogas, use 'detect_raja_and_lunar_yogas'. For Sun yogas (Vasi/Vesi/Ubhayachari) use 'get_sun_yogas'.

[Parashari] Yoga karaka by lagna, as BPHS ch. 34 names it (Santhanam; ch. 36 in Sharma), read from the verses. The KP corpus does not use the concept, so never present it as a KP rule. BPHS gives two definitions: the pair rule (34.11-12, a kendra lord and a kona lord in exchange, together, one in the other's sign or in full mutual aspect) and the single-planet rule (34.13, one planet owning both a kendra and a kona), and 34.15 denies the yoga where the lords also own an evil house. Its per-lagna verses name a single planet for Taurus, Cancer, Capricorn and Aquarius, a PAIR (the 9th lord with the 10th lord) for Virgo, Libra, Scorpio, Sagittarius and Pisces, and none for Aries, Gemini and Leo. Returns 'yogaKaraka' (one planet, null where none is named) with 'yogaKarakaSource'; 'yogaKarakaPair' (the pair, never split into a primary and a secondary, with whether the two are related in this chart, reported and gating nothing); 'bphs' (what the verse names and the planets it calls auspicious, neutral or killers); 'readings' (every stated reading, the verse first: Leo Mars and Libra Saturn are derived from 34.13, and Libra and Aquarius are disputed, so give both readings); 'lagnaLord' (the lagna lord does not count on its own at the verse, and the later and modern readings that count it are listed apart); 'tableVariant' (this tool's earlier fixed table, whole, with the names no text supports marked unsourced); 'definitions'; 'placement' (KP house and whole-sign house); whether the running mahadasha or antardasha lord is a named yoga karaka (either member of a pair); 'rationale'; and 'definitionCheck' (sign-lordship arithmetic). 'secondaryYogaKaraka' is retired and always null. Say which reading you used.

[Lumin extension] NOT the BPHS Bhava bala and not comparable with a printed one (F047): Lumin's own index per Placidus house, three 0-100 components averaged. Returns '{ houses: [{ house, lord, bhavadhipatiBala, drikBala, digBala, total, strengthBand: STRONG | MODERATE | WEAK, notes }], strongestHouse, weakestHouse, summary, method: 'lumin-strength-index', scoreProvenance, houseConvention }'. 'bhavadhipatiBala' is the cusp sign lord's score from 'get_shadbala_index' (itself an index, not virupas); 'drikBala' is an invented benefic/malefic count of aspects on the cusp; 'digBala' is a flat kendra bonus (100 for houses 1, 4, 7 and 10, 50 for the rest) and is NOT Bhava Digbala. Banded STRONG at 65 and MODERATE at 45, cuts with no source. 'scoreProvenance' names what is sourced (the three component names) and what is not. The house ORDER is the usable part. Say it is a Lumin index every time it is used. The classical virupas are 'get_classical_bhava_bala'. Gates no KP verdict. The same blocks 'get_bhava_bala' returns at its top level ('houses', 'strongestHouse', 'weakestHouse', 'summary', 'method', 'scoreProvenance', 'houseConvention').

[Vedic Parashari adjunct] TWO QUANTITIES, and which is which. 'classical' is BPHS 27.26-31 in virupas (Santhanam; ch. 29 in Sharma), per bhava on the Sripati bhava madhya (its own 'houseConvention' says so): bhavadhipati, the lord's classical Shadbala total; bhava drishti bala on the sputa scale, a quarter of each benefic aspect added and each malefic one subtracted, with the Jupiter/Mercury clause in THREE readings, each labelled: their full aspect on top of the quarter ('mercuryJupiterFullPlusQuarter', the literal line and Sripati, disputed), in place of it ('mercuryJupiterInFull', Raman, disputed), and every aspect a quarter ('quarterOnly', no source for Bhava bala, legacy); Bhava Dig bala by the verse's four sign lists (deduct the 7th from Gemini, Virgo, Libra, Aquarius, Sagittarius 0-15; the 4th from Aries, Taurus, Leo, Sagittarius 15-30, Capricorn 0-15; the lagna from Cancer and Scorpio; the 10th from Capricorn 15-30 and Pisces; fold past 180, divide by 3), with Raman's reading beside (Cancer watery, 10 virupas per bhava, modern); the 27.30-31 adjustments, +60 for Jupiter or Mercury occupying, -60 for Saturn, Mars or the Sun, and +15 for a sirshodaya sign by day, a prishtodaya sign by night and Pisces, the one ubhayodaya sign, in twilight, whose length no edition states for this rule, so it ships in two readings (BPHS 9.14, 3 ghatis on the dark side; 46.44-46, 5 ghatis either side). 'totals' gives each bhava's Bhava bala under each stated reading (six BPHS combinations and Raman's own method), each with its reading, rupas and weakest source class, and 'readings' their methodology. There is no single total and no ranking. 'sumOfComputedLegs' is the pre-dig-bala sum, kept. The top level is the older Lumin index, not the BPHS computation: Bhavadhipati (the lord's index score from get_shadbala) + Drik Bala (cusp aspects) + Dig Bala, each 0-100 and averaged, banded STRONG at 65. Its Dig Bala column is a flat kendra bonus and is NOT Bhava Digbala; that is named in scoreProvenance rather than hidden. The index returns per-house entries plus strongest and weakest house, and its house ORDER is the usable part. Each quantity is also a tool of its own, named in 'methodSeams': 'get_classical_bhava_bala' (the BPHS virupas, paged by bhava) and 'get_bhava_bala_index' (the Lumin index). This tool returns both in one call.

Parashari, not KP. Bhava bala of Brihat Parashara Hora Shastra 27.26-31 (Santhanam; 29.26-31 in Sharma) in VIRUPAS per bhava, measured on the Sripati bhava madhya. Returns '{ method: 'bphs-bhava-bala', birthPeriod: { isDayBirth, minutesFromSunrise, minutesFromSunset, minutesToNextSunrise, twilight, twilightNote }, houses: [{ bhava, madhyaLongitude, madhyaSign, lord, bhavadhipatiVirupas, wholeSignLord, bhavaDigBala: { signClass, referenceBhava, referenceLongitude, arcDegrees, virupas, raman }, bhavaDrishtiBala: { quarterOnlyVirupas, mercuryJupiterInFullVirupas, mercuryJupiterFullPlusQuarterVirupas, edges }, occupants, occupantVirupas, risingType, risingTypeByTwilight, sumOfComputedLegs, totals: [{ reading, digBala, drishti, twilight, includesOccupantAndRisingType, virupas, rupas, sourceClass }] }], readings: [{ reading, methodology, source }], componentProvenance: [{ component, source }], houseConvention, notApplied, warnings, source }'. Per bhava: bhavadhipati, the madhya lord's classical Shadbala total (the whole-sign lord beside it where it differs); Bhava Dig bala by the verse's four sign lists, with Raman's reading beside ('bhavaDigBala.raman', modern); bhava drishti bala on the sputa scale with the Jupiter/Mercury clause in THREE readings (full on top of the quarter, the literal line and Sripati, disputed; in place of it, Raman, disputed; every aspect a quarter, legacy); the 27.30-31 adjustments, +60 for Jupiter or Mercury occupying, -60 for Saturn, Mars or the Sun, and the rising-type +15 with twilight in two readings (BPHS 9.14, 3 ghatis; 46.44-46, 5 ghatis). 'totals' gives the bhava's Bhava bala under every stated reading (six BPHS combinations and Raman's own method), each with its weakest source class, defined in 'readings'. There is no single total and no ranking. 'houseConvention' is this block's own, the Sripati madhya. **'houses' is paged, one bhava per page, so page N is bhava N**, never cut inside a row; everything else repeats on every page. The Lumin 0-100 index is 'get_bhava_bala_index', a different quantity. Gates no KP verdict. The same block 'get_bhava_bala' returns as 'classical'.

Parashari, not KP. The Shadbala of Brihat Parashara Hora Shastra ch. 27 (Santhanam) in VIRUPAS, 60 to a rupa, for the seven planets; Rahu and Ketu have none (BPHS computes it for the seven only). Returns '{ method: 'bphs-shadbala', planets: [{ planet, sthana, dig: { virupas, fullStrengthHouse, measuredFromCusp, arcDeg }, kala, chesta, naisargika, drik, totalVirupas, totalRupas, requiredVirupas, requirementRatio, verdict: STRONG | WEAK, minorityRequirement, componentMinimums, ishtaPhala, kashtaPhala, rank }], strongest, weakest, variants: [{ key, reading, source, totals, verdictsChanged, strongestChanged, strongestUnderVariant }], componentProvenance: [{ component, source }], methodNote, warnings, houseConvention }'. Each planet carries every sub-part of the six balas (Sthana's Uccha, Saptavargaja, Ojha-Yugma, Kendra and Drekkana; Kala's Nathonnatha, Paksha, Tribhaga, the Abda, Masa, Vara and Hora lords, Ayana and the 27.20 graha-yuddha correction; Chesta from the motion states; Drik over the sputa drishti scale), their sum against the planet's own 27.32-33 requirement ('verdict' is absolute: Mercury at 419 against 420 is weak), the 27.34-36 component gates ('componentMinimums', with 'attainable' and 'failedAttainable' because one transmitted gate cannot be passed, F083), and Ishta and Kashta phala. 'strongest' and 'weakest' are the selector 27.37-38 asks for. 'componentProvenance' names the one component that is not the classical quantity (Chesta, which needs a mean planet this engine does not compute); 'variants' gives each editorial dispute as its own totals and what it moves, none averaged. 'houseConvention' says Dig bala is measured from the Placidus cusps (27.7). **'planets' is paged, one planet per page in rank order**, never cut inside a row; everything else repeats on every page, so 'strongest', 'weakest' and the 'variants' totals read from page 1. The Lumin 0-100 index is 'get_shadbala_index', a different quantity: never compare the two figures. Gates no KP verdict. The same block 'get_shadbala' returns as 'classical', with its 'houseConvention'.

Per-planet Astangat / combustion analysis. Returns each non-Sun planet's arc-distance from the Sun, the applicable combustion threshold (with retrograde reduction for Mercury / Venus), grade (NONE / ORDINARY / FULL, full = within 5° of Sun) and a proximity severity band. **Reported, never gated**: 'blocksSignifications' is always false, because KP does not withhold a combust planet's results. KSK, Astro Secrets canon p.1193: "the eclipsed planet, whomsoever it is, offers those results which it indicates", worked on a chart whose Mercury sat at zero separation from the Sun and still made the native Chief Engineer in its own dasa. Use for the observation, not for a verdict. Books: Astro Secrets KP canon pp.1192-1193.

[Vedic Parashari] Planetary war detection among the 5 tara grahas (Mercury, Mars, Venus, Jupiter, Saturn), the classical doctrine of Varahamihira's Brihat Samhita ch.17, not KP: the KP Readers state no planetary-war rule, so a war is a cross-system note and moves no KP verdict. Any pair within 1° is in war; the victor is the planet stationed further north (apparent latitude), with Venus taking an equal-latitude tie on brightness, and 'winnerReason' says which. 'alternativeVerdicts' reports what the later lower-longitude shortcut and a dignity ranking would have decided; neither is the Brihat Samhita criterion. Returns active wars, winner/loser, separation arc, severity (CLOSE ≤0.5° / MODERATE ≤1°), and the loser's suppressed significations (the Parashari reading). Sun, Moon, Rahu, Ketu do not participate.

[Tajik] Harsha bala on its own (CLASSICAL-SOURCES A44): four binary situations per planet, five points each, sthana (the house of joy), uccha-swakshetra (exaltation or own sign), stri-purusha (gender in a gendered house or sign) and diva-ratri (day or night return). Returns '{ frame: 'natal' | 'annual', annual?: { targetYear, age, sunReturnDateUTC, chartLagnaSign }, harsha: [{ planet, components: [{ component, points, computed, reason, source }], points, reachableTotal, genderTestVariant: { reading, onSign, onHouse, source }, statedTotal, notComputed }], gaps, methodNote, houseConvention, pagination, pageNote }'. **'points' is out of 'reachableTotal', not out of 20**: on the natal frame there is no solar return to be day or night, so diva-ratri does not run and each planet reaches 15; pass 'target_year' for that year's solar-return chart and all four run. The gender test is applied to the SIGN by A44 and to the HOUSE by Q034, so 'genderTestVariant' carries both answers, neither resolved. The planetary genders are the TAJIK ones, where Mercury and Saturn are female and BPHS treats both as neuter. 'gaps' lists what both Tajik strength systems leave open, each line prefixed with its system. Nothing is ranked. **'harsha' is paged by planet.** The same block 'get_tajik_yogas' returns as 'bala.harsha'.

A Lumin index, not KP and not a BPHS computation: a 0-100 score for each of the twelve houses, summed from five factors, 'occupants' (0-25: each occupant scored by dignity, combustion, motion and natural benefic class; an empty house 5), 'csl_strength' (0-30: the cuspal sub lord's dignity, combustion, motion and placement, and whether it also lords the cusp's sign), 'house_lord_placement' (0-20: the cusp sign's lord by the house it occupies), 'aspects' (0-15: from a neutral 7, each graha drishti offset falling within the orb of the Placidus cusp adds 5 for a benefic and takes 3 for any other planet, plus up to 2 for a close orb) and 'self_reference' (0-10: whether the CSL signifies its own house), graded VERY_STRONG (80+), STRONG (60+), MODERATE (40+), WEAK (20+), VERY_WEAK. Returns '{ chart_info, nodeDrishtiReading, house_strength: { scores: [{ house, total_score, factor_scores: { occupants, csl_strength, house_lord_placement, aspects, self_reference }, verdict, csl_planet, occupants, house_lord, house_lord_placed_in, stellium_detected, stellium_note, notes }], retrograde_reading: { applied, rule, retrograde_planets, astronomical, differs }, summary: { strongest_houses, weakest_houses, average_score, stellium_houses } }, houseConvention }'. The aspects factor reads the degree-exact aspects under 'nodeDrishtiReading' (the node reading used, default the 7th only); 'houseConvention' names the Placidus houses it is scored on and every planet whose house differs under whole sign. The motion deductions read KP motion, the nodes never retrograde ('retrograde_reading', with the astronomical flag beside). The weights are the engine's own and carry no source label yet (F031, F036). Built from natural benefic and malefic class, dignity and combustion, which KP judges by none of: reference and cross-system comparison only, never an input to a KP verdict. For the BPHS ch. 27 figure use 'get_shadbala'; for the house index of three components use 'get_bhava_bala'. The same block 'get_aspects_and_strength' returns as 'house_strength'.

[Tajik] Panchavargeeya bala on its own (CLASSICAL-SOURCES A43, from the Hayanaratna in Gansten's critical edition): each of the seven planets scored out of 80 across five components, kshetra, uccha, hadda, drekkana and navamsa. Four score the planet's relation to the lord of a division it occupies on one ladder (own the full maximum, a friend half, an enemy a quarter); uccha is continuous, (distance from the debilitation point / 180) x 20. Returns '{ frame: 'natal' | 'annual', annual?: { targetYear, age, sunReturnDateUTC, chartLagnaSign }, panchavargeeya: [{ planet, components: [{ component, maximum, virupas, virupasNeutralAsFriend, computed, divisionLord, relation, stated, source }], total, totalNeutralAsFriend, classified, classifiedNeutralAsFriend, band, bandNeutralAsFriend, ramanBand, neutralRungChangesBand, neutralRungAffects, statedTotal, notComputed, variants }], navamsaSignIndex, gaps, methodNote, pagination, pageNote }'. 'classified' is the total over four, the 0 to 20 scale the bands are defined on: Nirbali below 5, Madhya Bali 5 to 10, Poorna Bali 10 to 15, Parakrami above 15. **THE NEUTRAL RUNG IS STATED IN NO COMPONENT**, so both ends ship on every planet ('total' and 'totalNeutralAsFriend', 'band' and 'bandNeutralAsFriend'); the uccha reference point and the friendship scheme are named in 'variants'. 'gaps' lists what both Tajik strength systems leave open, each line prefixed with its system. It is A45's tie-break input but NOT the year lord: the aspect gate decides first (get_varshesha). Pass 'target_year' for that year's solar-return chart, or omit it for the natal chart. Nothing is ranked. **'panchavargeeya' is paged by planet.** The same block 'get_tajik_yogas' returns as 'bala.panchavargeeya'.

Parashari, not KP, and unsourced: the module's header says its verdict and signification-adjustment layers rest on no text on disk, and KP's own retrograde doctrine (binary, a timing rule, gating no promise) is 'get_retrograde_panel' and its steps. For each of Mars, Mercury, Jupiter, Venus and Saturn that is retrograde or within 0.05 degrees a day of a station (the Sun and Moon never retrograde; the nodes are skipped), from the positions and the Placidus cusps: the station status (STATION_RETROGRADE, STATION_DIRECT, NORMAL), the occupied house (also 'secondary_results_house') and the primary results house (the 7th from it), the sign, and dignity, combustion and Neecha Bhanga, all three REPORTED and deciding nothing ('dignity_provenance', F066); then one 'verdict' by the first rule that applies, OBSTRUCTED (in the 6th, 8th or 12th), ONSET_DELAY or RESUMING (stationing retrograde or direct), STRONG_RETROGRADE (in an angle), else MODIFIED, with its explanation and implications, and the house signification adjustment (add the 7th from the occupied house, reduce the occupied one). The type also names DELAYED_FULL, NEECHA_BHANGA, SEVERELY_WEAKENED and DENIED, which F066 retired and are no longer emitted. A planet neither retrograde nor near a station gets no row; 'retrograde_planets' and 'station_planets' name the ones that do. Returns '{ chart_info, retrograde_analysis: { retrograde_planets, station_planets, analyses: [{ planet, is_retrograde, speed_deg_per_day, station_status, occupied_house, primary_results_house, secondary_results_house, sign, dignity, is_combust, neecha_bhanga: { applies, reason, trigger_planet, trigger_house }, dignity_provenance, verdict, verdict_explanation, implications, house_signification_adjustment: { add_houses, reduce_houses } }] }, houseConvention }'. Reads no aspect. Never an input to a KP verdict. The same block 'get_aspects_and_strength' returns as 'retrograde_analysis'.

[Vedic Parashari adjunct] TWO quantities, both returned, and the response says which is which. 'classical' is the real BPHS ch. 27 computation in VIRUPAS (60 to a rupa): Sthana broken into Uccha, Saptavargaja across seven vargas, Ojha-Yugma, Kendra and Drekkana; Dig by the 27.7 cusp arc; Kala into Nathonnatha, Paksha, Tribhaga, the four Abda/Masa/Vara/Hora period lords and Ayana from declination, plus the 27.20 graha-yuddha correction; Chesta from the eight motion states; Naisargika; Drik over the sputa drishti scale. Then the six are summed and compared against this planet's own required pinda at 27.32-33, with the 27.34-36 component gates and Ishta and Kashta phala. 'componentProvenance' names the one component that is NOT the classical quantity (Chesta, because 27.24-25 needs a mean planet of classical Indian theory this engine does not compute) and 'variants' carries five editorial disputes as separate totals saying what each one MOVES. The top-level six 0-100 scores are the older Lumin index, kept because other tools read it; 'divergence' reports how far the two RANKINGS disagree, which on a 40-chart set is a lot (the same strongest planet on 30% of charts). Rahu and Ketu are carried unranked: BPHS computes strength for the seven only. Never compare an index number with a printed Shadbala; the virupas under 'classical' are the comparable figures. Each quantity is also a tool of its own, named in 'methodSeams': 'get_classical_shadbala' (the BPHS virupas, paged by planet) and 'get_shadbala_index' (the Lumin index). This tool is their spread: it returns both and 'divergence', which only it carries.

[Lumin extension] NOT the BPHS Shadbala and not comparable with a printed one (F047): Lumin's own index of six 0-100 components per planet, averaged. Returns '{ planets: [{ planet, components: { sthana, dig, kala, cheshta, naisargika, drik, total }, rank, relativeStrength: STRONG | MODERATE | WEAK, requirement: { virupas, rupas }, bandCut, requirementRatio, notes }], nodes, strongest, weakest, summary, method: 'lumin-strength-index', methodNote, scoreProvenance, houseConvention }'. Sourced: the six component names, the Dig bala directions, the Naisargika series (the one component that IS the classical quantity), the day/night assignment, the exclusion of the nodes, and the per-planet requirement of BPHS 27.32-33, whose RATIOS set each planet's own 'bandCut' on this scale ('requirementRatio' keeps the shape of the classical test, actual over required, not its number). Not sourced, and named in 'scoreProvenance': every 0-100 score, the averaging, the 65 anchor and the moderate cut. Rahu and Ketu are computed in 'nodes' and never ranked against the seven. Say it is a Lumin index every time it is used. The classical virupas are 'get_classical_shadbala', and how far the two rankings disagree is 'divergence' on 'get_shadbala'. Gates no KP verdict. The same blocks 'get_shadbala' returns at its top level ('planets', 'nodes', 'strongest', 'weakest', 'summary', 'method', 'methodNote', 'scoreProvenance', 'houseConvention').

[Tajik] The sibling of get_frame_spread, for Tajik's strength systems instead of the ayanamsa. get_tajik_yogas computes panchavargeeya and harsha bala on one reading and reports the variants beside them; this answers the question that reporting them does not, which is WHICH CONCLUSIONS MOVE when a reading the sources leave open is taken the other way. Measured over 200 charts THROUGH THIS TOOL ('scripts/bp017-tajik-variant-spread.ts'): the unstated neutral rung arises on 62.5% of planet readings, moves a planet's BAND on 17.7% of them and on 74.0% of charts, and moves the chart's greatest panchavargeeya bala (A45's year-lord tie-break input) on 15.0% of charts; the harsha gender test disagrees with itself on 49.3% of planet readings and somewhere on 98.5% of charts. READ 'movesAt' PER PLANET, NOT 'summary.variantIndependent': one planet in five (19.9%) moves on NOTHING and its strength can be stated without a hedge, but a chart where NOTHING AT ALL moves is rare (0.5%), because the gender test disagrees on some planet almost every time. The per-planet answer is the usable one and the whole-chart flag is the rare strong case. Returns per planet both panchavargeeya totals, both classificatory values, both bands, both harsha gender readings and both harsha point totals, plus 'movesAt' naming which of the four axes actually moved. READ THE EMPTY 'movesAt' FIRST: a planet listed in 'summary.holding' has a strength reading that does not rest on anything the sources leave open, and that can be said outright instead of hedged. 'greatestPanchavargeeya' names the greatest planet under each reading because A45's second test asks for it; IT IS NOT THE YEAR LORD, and reading it as one is the mistake Q034's own worked example catches, where the chart's strongest planet loses the varshesha because it does not aspect the annual ascendant. Pass 'target_year' for the annual frame and 'yearLord' carries A45's answer under each reading, with 'annual.aspecting' and 'annual.strengths' so a caller can see whether the rung was even consulted: the year lord holds far more often than the strongest planet does, because the aspect gate decides first and the tie-break only runs inside it. FOUR VARIANTS TRAVEL AND ONLY TWO ARE COMPUTED. The neutral rung (A43 states no value for a neutral relation in any of its five components) and the harsha gender test (A44 reads the sign, Q034 reports the house) are computed both ways. The uccha reference point and the friendship scheme are NAMED AND LEFT UNMEASURED, because their second readings have no stated arithmetic and inventing the transformation in order to measure it is exactly the failure this surface exists to avoid. NOTHING IS SCORED, RANKED, AVERAGED OR VOTED ON and there is no best reading: a reading either changes a conclusion or it does not.

Detects planets, and the lagna, that occupy the same sign in D1 (natal) and D9 (Navamsa), i.e. vargottama (BPHS ch.6 Santhanam, Brihat Jataka; read as strong, comparable to own sign). Returns each planet's natal sign, D9 sign, vargottama flag and 'strengthMultiplier' (1.0 or 2.0), the 'lagna' row, the count and names of all vargottama planets, and 'source'. The 2.0 is a Lumin convention, not a sourced quantity: no classical source assigns vargottama a multiplier, and 'scoreProvenance' says so. Read the flag, not the number.

[Vedic Parashari adjunct] 20-fold strength of each planet across all sixteen Shodasavarga vargas, weights summing to exactly 20 (D1 3.5, D9 3, D60 4, the rest tapering to 0.5). Each varga is graded on the classical varga-viswa ladder, own 20 / friend 15 / neutral 10 / enemy 7, which is a FRIENDSHIP ladder with no exaltation or debilitation rung. Grading uses the naisargika maitri alone where the classical method uses the compound panchadha, so the great-friend (18) and great-enemy (5) rungs are unreachable; the response states this in friendship and methodNote. Per-planet total 0-20 with band (EXCELLENT 17+, VERY_GOOD 14-17, GOOD 11-14, AVERAGE 8-11, POOR <8; the bands are a Lumin convention named in 'scoreProvenance', the total is the classical quantity), plus the grade each varga landed on. Two vargas are disputed in construction: D-60 is graded by the own-sign count and D-10 by even-from-9th ('vargaReadings'), and each planet's 'readingVariants' gives its total under every other reading, one varga swapped at a time, never averaged. 'weightedTotal' is the Shodasavarga; 'schemeTotals' gives each planet's total under all four schemes of BPHS 7.17-25, defined in 'schemes' with their classes: Shadvarga (6, 2, 4, 5, 2, 1), Saptavarga TWICE because which varga takes which of its values is disputed (the translators' tables, which every program uses, against BPHS 27.4's own order, which every textual check supports), Dasavarga (Rasi 3, Shashtiamsa 5, eight others 1.5, San 7.20), Shodasavarga. Each scheme sums to 20; schemes are different methods, never averaged. Rahu and Ketu are carried unranked. **'planets' and 'nodes' are paged together**: page N carries the Nth page of each, never cut inside a row; 'schemes', 'scoreProvenance', 'vargaReadings', 'methodNote' and 'summary' repeat on every page. The planetary 'report card'.

Generate a 12-month forecast with month-by-month predictions. Shows dasha periods, activated houses, themes, and overall tone for each month.

[Tajik] Mudda dasha for one year of life, on its own (CLASSICAL-SOURCES A46): the Vimshottari compressed into a year, each planet's Vimshottari years times three giving its days (360 in all), opening on the lord given by (natal Moon nakshatra + completed years - 2) / 9 with the remainder counted from the Sun, which is the natal Moon's nakshatra progressed one a year (Adawal's and Narasimha Rao's worked examples). Returns '{ frame: 'annual', annual: { targetYear, age, sunReturnDateUTC, returnInstant, chartLagnaSign }, mudda: { startingLord, startingLordDerivation, balance, startingLordUttaraKalamrita, uttaraKalamritaNote, annualMoonVariant, periods, periodsScaledToYear, periodsBySolarDegrees, superseded, residual, readWith, source, scalingSource }, methodNote }'; each period is '{ lord, days, startUTC, endUTC, segment, solarDegrees? }'. The first period is a BALANCE from the natal Moon and the traversed part closes the year ('segment': balance, whole, closing). Three year lengths ship and none is preferred: 'periods' the stated 360 civil days, 'periodsScaledToYear' Adawal's proportional spread over the real interval between returns, 'periodsBySolarDegrees' a mudda day as the Sun's one degree (Narasimha Rao); 'residual' says what the 360 leave open. 'annualMoonVariant' opens the year on the annual Moon's own nakshatra lord, a modern alternative. Mudda is a CROSS-CHECK by its own doctrine, read with the natal Vimshottari (get_dasha_periods), not a timing method alone. Nothing is scored. The same block 'get_tajik_dashas' returns as 'mudda' (and 'get_tajik_yogas' as 'dashas.mudda').

[Tajik] Patyayini dasha for one year of life, on its own (CLASSICAL-SOURCES A47): the one annual dasha NATIVE to Tajik, read on the annual chart. The year is divided among the seven planets AND the lagna (nodes excluded, the opposite of mudda) in ascending order of krishamsa, the longitude with the signs deleted; each lord's patyamsa is its krishamsa less the previous lord's, and each period is the year times its patyamsa over the highest krishamsa. A LONGITUDE rule, not a strength rule: nothing in it reads panchavargeeya bala. Returns '{ frame: 'annual', annual: { targetYear, age, sunReturnDateUTC, returnInstant, chartLagnaSign }, patyayini: { computed, periods: [{ lord, krishamsaDeg, krishamsaDMS, patyamsaDeg, patyamsaDMS, days, daysByConvention, startUTC, endUTC }], highestKrishamsaDeg, highestKrishamsaDMS, highestKrishamsaLord, patyamsaSumDeg, invariantHolds, yearConvention, yearDays, totalDays, variants, source, note }, methodNote }'. 'invariantHolds' reports the check both sources state, that the patyamsas total the highest krishamsa. Three year lengths are attested and all three ship per period in 'daysByConvention'; 'days' and the dates use Charak's 365 ('yearConvention': charak365), the year his worked example is computed on. Nothing is scored. The same block 'get_tajik_dashas' returns as 'patyayini' (and 'get_tajik_yogas' as 'dashas.patyayini').

[Tajik] 15 sahams as A-B+C lots: Punya, Yasas, Vidya, Vivah, Putra, Karya, Roga, Pitri, Matri, Bhratri, Rajya, Nyya, Bandhana, Krodha, Karya-Siddhi. Each returns sidereal longitude, sign, house, star lord, sub lord, the formula that ran, and per-entry PROVENANCE against the Tajika Neelakanthi (1587), read second-hand via Charak and Raman: 7 attested, 2 engine-variant, 6 unverified. formulaUsed is the arithmetic, NOT a citation. Where an attested formula differs from the one the engine takes as primary it is carried in variants[], computed, so both points ship and the caller chooses; Vivah is the live case (7th cusp - Venus + Asc here, Venus - Saturn + Asc in Charak, both real lineages). correction30 reports the contested add-30-degrees rule and is applied to nothing. Yasas and Bandhana's attested forms are CHAINED on the computed Punya saham. Sahams natively belong to the ANNUAL (varshaphala) chart: pass target_year and they are cast on that year's solar-return chart (same return instant as get_varshaphala_chart, 'frame: 'annual''); without it they are cast on the natal chart ('frame: 'natal''), which Charak also reads, a saham weak at birth cannot deliver in the annual chart. Mrityu Saham is intentionally omitted per project policy (no death framing).

[Tajik] The two annual dashas of one year of life, on a tool of their own: the same block get_tajik_yogas returns as 'dashas' on its annual frame, byte for byte, so the two cannot disagree. **Mudda** is the Vimshottari compressed into a year (each planet's years times three, 360 days), opening on the lord given by (natal Moon nakshatra + completed years - 2) / 9 with the remainder counted from the Sun, which is the natal Moon's nakshatra progressed one a year (Adawal's and Narasimha Rao's worked examples; 'superseded' shows what the engine returned before 2026-09-28). The first period is a BALANCE from the natal Moon and the traversed part closes the year ('segment'). Three year lengths ship and none is preferred: 'periods' the stated 360 civil days, 'periodsScaledToYear' Adawal's proportional spread over the real interval between returns, 'periodsBySolarDegrees' a mudda day as the Sun's one degree (Narasimha Rao). 'annualMoonVariant' opens the year on the annual Moon's own nakshatra lord, a modern alternative. **Patyayini** is the one annual dasha native to Tajik: the year divided among the seven planets AND the lagna in ascending order of krishamsa (the longitude with the signs deleted), each period the year times its patyamsa over the highest krishamsa, nodes excluded; a longitude rule, not a strength rule. 'invariantHolds' reports the check the sources state. 'annual' names the year of life and the return instant ('returnInstant'). Mudda is a cross-check on the natal Vimshottari by its own doctrine, so read it with get_dasha_periods. Nothing is scored. Each dasha is also a tool of its own, named in 'methodSeams': 'get_mudda_dasha' and 'get_patyayini_dasha'. Call one when a reading needs one; this tool returns both.

[Tajik] Tajik's OWN judgement mechanism, which this engine did not have before 2026-09-14. The sixteen shodasha yogas under the Tajikanilakanthi's own definitions (Samjnatantra ch. 2, Kedaradatta Josi's edition, read verse by verse in Gansten and Wikander, Annals of Science 68, 2011), with the orb table from Daivajnalamkrti 8.9 (Gansten's critical Hayanaratna). Every instance carries 'reading' and its own source. Returns every one of the 21 planet pairs as a 'contact' (its aspect, separation, pair orb, and whether it is ithasala/applying, isarapha/separating or partile) plus each yoga instance with the planets, the reason, a sense word, and its own locus and edition. Read 'roles': the muthasila is the faster planet applying its light and the musaripha the slower one receiving it, and which is which decides whose condition the outcome turns on. NOT PARASHARI: an aspect here is one of the five Ptolemaic angles counted sign to sign AND gated by the pair orb (half the sum of the two planets' deeptamsas), so a sign aspect is inactive unless the degrees are close enough, and application is decided by DEGREE WITHIN SIGN rather than by longitude. ALL SIXTEEN COMPUTE since 2026-09-28 (F144): 'yogas' carries the TNK readings, including khallasara (2.61, the void-of-course Moon) and duhphalikuttha (2.64). The one-line research paraphrases this tool ran before (reading 'q031', class modern), Sahl's jam' where the TNK departs from him ('sahl') and Narasimha Rao's manual where it is a third definition ('narasimha-rao') ship in 'otherReadings', with 'presentUnderOtherReadings'; none of them decides anything in 'yogas'. Kuttha and durupha are, in the TNK, per-planet LISTS of strengthening and weakening conditions with no count that makes either present, so they ship in 'strengthConditions', each condition met or not, with no verdict; the paraphrase's two-planet kuttha and duruhpha stay in 'yogas' labelled 'q031', and only that reading is 'two-sided'. 'notComputed' names what is still not computed (the TNK's sixteen kambula grades, three of Narasimha Rao's variants) with the reason. Nakta is TRANSFER (naql: separating from one, applying to the other) and yamaya COLLECTION (jam'), F143. 'contacts[].poorna' marks an ithasala within an arcminute of exact (TNK 2.18, Sahl), with 'poornaHalfMinute' and the manuals' 'poornaWithinOneDegree' beside it (F142). NOTHING IS SCORED, because Tajik judges in words and the source gives no weighting. Pass 'target_year' to scan that year's solar-return chart (Tajik's native frame, same return instant as get_varshaphala_chart) or omit it for the natal chart. 'orb_table' selects the classical values or the circulating variant that gives Mars and Mercury 12; measured over 200 charts the two disagree about which yogas are present on 24.5% of them, so 'underOtherOrbTable' is reported every time. **'bala' carries Tajik's two strength systems, both of which compute in full since 2026-09-14.** Panchavargeeya bala scores each planet out of 80 across five components and reports the total, the classificatory value (the total over four, a 0 to 20 scale) and the band: Nirbali below 5, Madhya Bali 5 to 10, Poorna Bali 10 to 15, Parakrami above 15, with Raman's parallel words beside them. Four components score the planet's relation to the lord of a division it occupies, on one ladder every time (own the full maximum, a friend half, an enemy a quarter); the fifth, uccha bala, is continuous. The hadda table is the Tajik one as transmitted, and it is verified against the Egyptian terms it descends from: the two differ in exactly two signs and those are left uncorrected, because this records what the tradition states rather than what a scholar reconstructs it should have said. Harsha bala now runs all four situations for its stated 20 (15 on the natal frame, where there is no solar return to be day or night, so that component is absent rather than zeroed); its planetary genders are the TAJIK ones, where Mercury and Saturn are female, and its sect lists are the HELLENISTIC ones, where Saturn is diurnal and Venus nocturnal, the opposite of BPHS on both. **THREE THINGS SHIP AS VARIANTS RATHER THAN CHOICES** and every reading carries all three: the neutral rung is unstated in every component so both totals ship ('total' and 'totalNeutralAsFriend'), the uccha reference point is a disagreement the source names, and the harsha gender test is applied to the sign by one source and to the house by another, so 'genderTestVariant' carries both answers. Read 'bala.gaps' for what is still open in one place. **'dashas' appears on the annual frame only** and carries Tajik's two annual dashas, both computed. **Mudda** is computed: the Vimshottari compressed into a year, each planet's Vimshottari years times three giving its days, in Vimshottari order from the lord given by (natal Moon nakshatra + completed years - 2) / 9 with the remainder COUNTED FROM THE SUN (1 Sun ... 8 Ketu, 0 Venus), which is the natal Moon's nakshatra progressed one a year; Adawal's and Narasimha Rao's worked examples fix it (until 2026-09-28 the engine opened every year one lord early, F141, and 'superseded' says what it returned). The first period is a BALANCE, the part of the natal Moon's nakshatra still to traverse, and the traversed remainder closes the year ('segment' on each period). Three year lengths ship and none is preferred: 'periods' the stated 360 civil days (ending ~5 days short of the next return), 'periodsScaledToYear' Adawal's proportional spread over the real year, 'periodsBySolarDegrees' a mudda day as the Sun's one degree (Narasimha Rao), ending at the next return. 'annualMoonVariant' opens the year on the ANNUAL Moon's own nakshatra lord with its own balance, a modern alternative; 'startingLordUttaraKalamrita' keeps its old value, a hybrid no source states, labelled. **Patyayini is computed, and it is the one annual dasha NATIVE to Tajik** rather than a compression of a Parashari nakshatra cycle, which is why it takes the ascendant as a full dasha lord and excludes Rahu and Ketu, the opposite of mudda. It divides the year among the seven planets and the lagna in ASCENDING order of krishamsa, the longitude with the signs deleted; each lord's patyamsa is its krishamsa less the previous lord's, and each period is the year times its patyamsa over the highest krishamsa. **It is a LONGITUDE rule and not a strength rule**: nothing in it reads panchavargeeya bala, and the 'divide by four' that connects the two in some summaries belongs to the year-lord classification, a different rule in a different chapter (this engine had that conflation and it cost a working technique a day; see 'invariantHolds'). The rule carries its own arithmetic check and the response reports it: the patyamsas are successive differences of a sorted list, so they MUST total the highest krishamsa. Three year lengths are attested and all three ship per period, the flat 365 being primary because it is what the source's worked example is computed on. Mudda is a CROSS-CHECK by its own doctrine, read together with the natal Vimshottari dasha, so pair it with get_dasha_periods rather than reading it alone. Four of the yogas read a planet as 'afflicted' and panchavargeeya bala is what that means; it now computes, so 'bala' and the yoga scan can be read together on one call rather than the scan naming a gap it cannot fill. Four blocks are also tools of their own, named in 'methodSeams': 'bala.panchavargeeya' is 'get_panchavargeeya_bala' and 'bala.harsha' is 'get_harsha_bala' (each paged by planet), and on the annual frame the year lord in 'annual' is 'get_varshesha' and 'dashas' is 'get_tajik_dashas'. Call those when a reading needs one claim; this tool still returns every block.

[Vedic alt-annual adjunct] Soli-lunar return ('true Vedic birthday'), chart cast when Sun returns to natal sidereal degree AND Moon occupies natal tithi. Per Sanjay Rath / PVR Narasimha Rao tradition. Returns TP datetime, chart lagna, match quality (EXACT/CLOSE/APPROXIMATE), and offsets.

[Tajik annual chart adjunct] Solar return chart cast for the moment Sun returns to its natal sidereal degree in the target year. Returns Sun-return datetime, chart lagna at that moment, Muntha sign (advances 1 sign per year of life), Muntha house from chart lagna, all planet positions at sun-return, and 'sahams': the fifteen Tajik sahams cast on THIS annual chart, their native frame, with the same per-entry provenance get_sahams carries. **THE YEAR LORD CAN BE NULL, and null is an answer rather than an error.** Since 2026-09-14 'yearLord' follows the stated rule: all five Panchadhikari are resolved (natal lagna lord, annual lagna lord, Muntha-pati, dina-ratri-pati, tri-rashi-pati) and each is tested for a Tajik aspect to the annual ascendant. Read 'varshesha' for all five with their derivations and aspect notes, and 'varshesha.basis': ASPECT_TEST (exactly one aspects, so the gate decides alone), STRENGTH_TIE_BREAK (several aspect and the greatest panchavargeeya bala separates them), MUNTHA_PATI (none aspects, the classical fallback), or UNDECIDED (an exact tie in strength between two that both aspect, for which the rule states no third test). Measured over 200 charts the first three bases cover 100% of them, the strength deciding the 35.5% that were null before 2026-09-14; UNDECIDED did not fire once and survives as a branch. **THE GATE'S ORB IS A READING NO SOURCE NAMES** (F146): 'candidates' test each planet against its own full deeptamsa (unsourced), and 'varshesha.gateVariants' gives the year lord under half that orb (derived from the pair rule) and under the sign aspect alone (Narasimha Rao's worked example, modern), with 'gateDecidesYearLord'; over 200 annual charts the sign-only gate names a different year lord on 46% and half the orb on 25.5%. 'varshesha.narasimhaRaoChain' carries that manual's whole chain (benefic aspects first, his tri-rashi table, the dina-ratri-pati as fallback) as one labelled reading. **THE GATE COMES FIRST AND STRENGTH ONLY BREAKS TIES INSIDE IT**, never the reverse: in the source's own worked example the strongest planet on the chart is NOT the year lord, because it does not aspect the annual ascendant, so a strongest-planet shortcut gets it wrong. 'varshesha.strengths' carries every total that was compared, so the decision can be checked rather than taken. 'yearLordLagnaLordOnly' carries the figure this tool returned before, the annual lagna lord taken unconditionally, which agrees with the full rule on 23.0% of charts. **THE TRI-RASHI-PATI HAS THREE ATTESTED TABLES** (Gansten, HSSA 6, 2018): method A, the Graeco-Arabic triplicities (Karmaprakasa 1.21), is the candidate used; method B, the sign-by-sign table the modern manuals print (Karmaprakasa 1.22-23), is computed beside it in 'varshesha.triRashi' with the year lord it gives ('yearLordTriRashiMethodB', null when the two agree; they differ on about one year in eight); Balabhadra's method A2 is named and not computed. Used for annual subscription-reading products. Two blocks are also tools of their own, named in 'methodSeams': the year lord ('varshesha', 'yearLord', 'yearLordRationale', 'yearLordLagnaLordOnly') is 'get_varshesha', and 'sahams' is 'get_sahams' called with the same 'target_year'. Call those when a reading needs one claim; every block still ships here.

[Tajik] The year lord of one year of life by the stated rule (CLASSICAL-SOURCES A45), on its own. All five Panchadhikari are resolved and each is tested for a Tajik aspect to the annual ascendant; THE GATE COMES FIRST AND STRENGTH ONLY BREAKS TIES INSIDE IT: among several that aspect, the greatest panchavargeeya bala wins, and when none aspects the Muntha-pati is the fallback. Returns '{ frame: 'annual', annual: { targetYear, age, sunReturnDateUTC, chartLagnaSign, munthaSign }, yearLord, yearLordRationale, varshesha, yearLordLagnaLordOnly }'. 'yearLord' CAN BE NULL, which is an answer: 'varshesha.basis' is ASPECT_TEST, STRENGTH_TIE_BREAK, MUNTHA_PATI or UNDECIDED (an exact strength tie). 'varshesha.candidates' gives each candidate's 'role', 'planet', 'derivation', 'aspectsAnnualLagna' and 'aspectNote'; 'varshesha.aspecting' and 'varshesha.strengths' are what the tie-break compared, so the decision can be checked. The readings the sources leave open ship beside the primary, none chosen: the neutral rung ('yearLordNeutralAsFriend', 'neutralRungDecidesYearLord'), the tri-rashi tables ('triRashi', 'yearLordTriRashiMethodB', 'triRashiDecidesYearLord'), the gate's orb ('gateVariants', 'gateDecidesYearLord') and Narasimha Rao's whole chain ('narasimhaRaoChain'), all under 'varshesha'. 'yearLordLagnaLordOnly' is the annual lagna lord taken unconditionally, the figure returned before 2026-09-14. Call get_tajik_variant_spread for what the neutral rung moves on this chart. Nothing is scored. The same block 'get_varshaphala_chart' returns as 'varshesha', 'yearLord', 'yearLordRationale' and 'yearLordLagnaLordOnly', and 'get_tajik_yogas' under 'annual' with a 'target_year'.

[Vedic muhurta adjunct] 8 day + 8 night auspicious 1.5-hour periods (Amrit/Shubh/Labh/Char/Udveg/Rog/Kal). Each period returns lord, quality (auspicious/inauspicious), start/end UTC, and interpretation. Also returns 'currentPeriod', the period containing the moment you asked about. Companion to get_panchang. The astrological day runs sunrise to sunrise, so 'utc_offset_minutes' decides which civil day is meant and is required.

Vedic Panchang for any date and location. Returns '{ tithi (lunar day), nakshatra (lunar mansion), yoga (Sun-Moon angular relationship), karana (half-tithi), rahuKaal: { startUTC, endUTC }, yamagandaKaal, gulikaiKaal, sunriseUTC, sunsetUTC, weekday }'. Use when: you need today's auspicious / inauspicious windows. **Pass the date you want Panchang for (e.g., today's date), NOT the person's birth date.** For 1.5-hour Choghadiya windows use 'get_choghadiya_today'.

24 planetary hours per day, each ruled by one of 7 visible planets in Chaldean order (Saturn→Jupiter→Mars→Sun→Venus→Mercury→Moon). The hours are UNEQUAL: day horas are (sunset − sunrise) / 12 and night horas (next sunrise − sunset) / 12, which is KSK's correction of the almanac's fixed sixty-minute hour, with each hora subdivided among the seven planets (KP Reader 3 canon pp.524-527). KSK treats hora as a tie-breaker between moments that already pass the chart tests, never a reason to accept one ('kpStanding'). Day starts at sunrise; first hour = weekday's lord. Returns each hour's lord, quality, start/end UTC, interpretation, plus 'currentHora' for the moment you asked about. Pairs with Choghadiya (a Vedic muhurta table) for fine-grained timing. The astrological day runs sunrise to sunrise, so 'utc_offset_minutes' decides which civil day is meant and is required.

Read the KP astrometeorology signature for a single place and moment. Builds the chart for the location and time, then scores three weather channels, temperature, precipitation, and wind/storm, each with a signal, a numeric score, a descriptive band, and the chart signatures behind it. Also returns the 4th-cusp CSL verdict, the Sapta Nadi Chakra block, a plain-language summary, and a disclaimer. Inputs: latitude, longitude, utc_offset_minutes, optional ayanamsa, optional location_label, and an optional 'datetime' (ISO 8601, defaults to now). Use when: you want the weather tendency for one place at one time. The result shows the full reasoning, every band and score names the signatures it came from.

Read the roughly 14-day weather windows for a place across a date range, each window cast from a lunation chart (the new moon or full moon that opens it). Returns a 'windows[]' array, each window carrying the full astrometeorology signature: temperature, precipitation, and wind/storm channels with signal, score, band, and every signature behind them, plus the 4th-cusp CSL verdict, the Sapta Nadi block, a summary, and a disclaimer, alongside 'pagination' and 'pageNote'. **Paged.** A three-month range is several complete windows and does not fit one response, so read 'pageNote' and call again with 'page' incremented. Inputs: latitude, longitude, utc_offset_minutes, optional ayanamsa, optional location_label, and optional 'start_date' and 'end_date' (ISO dates; default to a sensible range around now). Use when: you want fortnight-by-fortnight weather windows for a location over a span of weeks or months. The three traditions inside each window are also tools of their own, named in 'methodSeams', each called with 'cadence: 'lunations'' and the same arguments: 'get_weather_csl_fourth' (the 4th-cusp verdict), 'get_sapta_nadi' (the Sapta Nadi Chakra) and 'get_weather_rulerships' (the three channels, which carry the Sapta Nadi fold). Call those when a reading needs one method; this tool returns all of them in one call.

Read the monsoon-onset signature for a place from the Ardra Pravesha chart (the chart for the Sun's entry into the Ardra nakshatra, the classical KP marker for the monsoon). Returns one astrometeorology signature under 'weather', with temperature, precipitation, and wind/storm channels each carrying signal, score, band, and signatures, plus the 4th-cusp CSL verdict, the Sapta Nadi block, a summary, and a disclaimer, alongside an 'ardraPravesha' block describing the ingress chart itself. Inputs: latitude, longitude, utc_offset_minutes, optional ayanamsa, optional location_label, and an optional 'year' (defaults to the current year). Use when: you want a monsoon-onset and rainfall read for a location and year. The bands show the signatures behind them.

The Sapta Nadi Chakra alone, read on each chart of a cadence: 'cadence: 'seasons'' reads the four cardinal ingress charts of a year (as get_seasonal_outlook; takes 'year', 'frame'), 'cadence: 'lunations'' one lunation chart per window across a date range (as get_weather_windows; takes 'start_date', 'end_date'). Not KP: Tantric in origin (the Yamaleeya-Svarodaya), transmitted through Narapati Jayacharya and Krishi-Parashara. Per row: each planet's nadi placement, the occupancy of the seven nadis, the group counts, the Moon's nadi and whether it intensifies rain, the chakra's own precipitation score and band, the storm and drought flags, the rain-duration heuristic and the signatures behind them. Returns, for seasons, '{ year, frame, location_label, seasons: [{ season, ingress, ingress_moment_utc, saptaNadi: { placements, nadis, groupCounts, moon: { nadi, group, intensifiesRain }, precipitationScore, precipitationBand, stormFlag, droughtFlag, rainDuration: { units, descriptor }, signatures } }], provenance, disclaimer, pagination, pageNote }', and for lunations '{ location_label, range, windows: [{ lunation_type, lunation_moment_utc, window_start, window_end, saptaNadi }], provenance, disclaimer, pagination, pageNote }'; 'provenance' is the Sapta Nadi layer's attribution. The parents also fold this result into their channel scores (see get_weather_rulerships). Not a meteorological forecast; relay the 'disclaimer'. **The rows are paged.** The same block get_seasonal_outlook and get_weather_windows return as 'weather.saptaNadi' on each row.

Read the four seasonal weather themes for a place across one year, derived from the cardinal ingress charts (the Sun entering Aries, Cancer, Libra, and Capricorn). Returns a 'seasons[]' array, each season carrying the full astrometeorology signature: temperature, precipitation, and wind/storm channels with signal, score, band, and signatures, plus the 4th-cusp CSL verdict, the Sapta Nadi block, a summary, and a disclaimer. Inputs: latitude, longitude, utc_offset_minutes, optional ayanamsa, optional location_label, an optional 'year' (defaults to the current year), and an optional 'frame' ('tropical' or 'sidereal') for the ingress reference. Use when: you want a year-ahead seasonal weather picture for a location. Every seasonal band shows the signatures behind it. The three traditions inside each season are also tools of their own, named in 'methodSeams', each called with 'cadence: 'seasons'' and the same arguments: 'get_weather_csl_fourth' (the 4th-cusp verdict), 'get_sapta_nadi' (the Sapta Nadi Chakra) and 'get_weather_rulerships' (the three channels, which carry the Sapta Nadi fold). Call those when a reading needs one method; this tool returns all of them in one call.

The 4th-cusp sub lord weather verdict alone, read on each chart of a cadence: 'cadence: 'seasons'' reads the four cardinal ingress charts of a year (as get_seasonal_outlook; takes 'year', 'frame'), 'cadence: 'lunations'' one lunation chart per window across a date range (as get_weather_windows; takes 'start_date', 'end_date'). The cuspal sub lord procedure read for weather: KP machinery, with no KP originator documented for the 4th-house-as-weather extension (Q018, F055), so it is kp-extended. Per row: the 4th cusp's sub lord, its star lord, the union of houses they signify, the verdict and the reasoning chain. Returns, for seasons, '{ year, frame, location_label, seasons: [{ season, ingress, ingress_moment_utc, cslFourth: { subLord, starLord, signifiedHouses, verdict: RAIN | HEAT | DRY | MIXED | INDETERMINATE, reasoning } }], provenance, disclaimer, pagination, pageNote }', and for lunations '{ location_label, range, windows: [{ lunation_type, lunation_moment_utc, window_start, window_end, cslFourth }], provenance, disclaimer, pagination, pageNote }'; 'provenance' is the cuspal layer's attribution. Not a meteorological forecast; relay the 'disclaimer'. **The rows are paged.** The same block get_seasonal_outlook and get_weather_windows return as 'weather.cslFourth' on each row.

The three weather channels, temperature, precipitation and wind/storm, each with its signal, score, band and every signature behind it, read on each chart of a cadence: 'cadence: 'seasons'' reads the four cardinal ingress charts of a year (as get_seasonal_outlook; takes 'year', 'frame'), 'cadence: 'lunations'' one lunation chart per window across a date range (as get_weather_windows; takes 'start_date', 'end_date'). **These channel scores are not the rulership layer alone. They include the Sapta Nadi fold**: the channels start from the Western planet-to-weather rulerships (Llewellyn George, credited by KSK at Reader 2 canon pp.74-75, over Heindel's hot/cold/wet/dry scheme) of the planets on or aspecting the 4th house and the angles, then the Sapta Nadi result is added in (its precipitation score divided by 5; +5 wind/storm on its storm flag; -4 precipitation and +2 temperature on its drought flag; +2 precipitation when the Moon is in a rain nadi), and then the 4th-cusp verdict nudges them (RAIN +4 precipitation; HEAT +4 temperature, -3 precipitation; DRY -4 precipitation). Each contribution is named in the channel's 'signatures' (labels 'Sapta Nadi ...' and 'KP 4th-cusp verdict'), so read those before attributing a score to one tradition. This is exactly what the parents return, unchanged. Returns, for seasons, '{ year, frame, location_label, seasons: [{ season, ingress, ingress_moment_utc, temperature, precipitation, windStorm }], provenance, disclaimer, pagination, pageNote }', each channel '{ signal, score, band, signatures: [{ label, fired, explanation }] }', and for lunations '{ location_label, range, windows: [{ lunation_type, lunation_moment_utc, window_start, window_end, temperature, precipitation, windStorm }], provenance, disclaimer, pagination, pageNote }'; 'provenance' names every layer, because the channels carry three. The 4th-cusp verdict and the Sapta Nadi Chakra on their own are get_weather_csl_fourth and get_sapta_nadi. Not a meteorological forecast; relay the 'disclaimer'. **The rows are paged.** The same blocks get_seasonal_outlook and get_weather_windows return as 'weather.temperature', 'weather.precipitation' and 'weather.windStorm' on each row.

Cast a KP chart for the moment the Sun reaches sidereal 0° Aries (annual), 0° Cancer (Q2), 0° Libra (Q3), and 0° Capricorn (Q4) for a chosen location. Read 10th CSL for governance/status, 6th CSL for crisis windows, 1st CSL for public mood, 7th CSL for foreign relations. The Aries ingress is the annual baseline; the other three refine quarterly themes. LOCATION-BASED — provide latitude / longitude / utc_offset_minutes (not birth data).

Unified mundane-KP endpoint for a national chart (for example India 1947-08-15 IST) or a company incorporation chart. Returns: current MD/AD lord by house signification (B21), epidemic signature scorer (B22, Mercury+Moon+Ketu+6/8/12 cluster), weather signature (B23, water-sign Moon, cardinal lagna, Saturn/Venus/Mars on 4th; sparsely covered in books), disaster signature (B24, Mars-Rahu axis, Mars on 8, Rahu on 4). Each scorer returns signatures[] (only fired ones contribute), score 0-100, riskBand NONE/LOW/NOTABLE/HIGH/CRITICAL, notes. Includes topScorer for quick triage. Strict 9-graha (no outer planets). Historical and content-marketing lens, not an engineering-grade forecast; never present output as confirmed prediction of disasters, epidemics, or weather events.

Compares 2+ candidate natal charts and an election-day moment per KP Reader 3 ch.41-43 and R6 cases 90-92, 111. For each candidate: natal political-success score (cov[9,10,11] minus 0.5x cov[8,12]) plus election-day amplifiers (RP overlap, Jupiter transit through 11th-house significator, polling-close Lagna match). Returns likelyWinner, runnerUp, marginQualitative (HIGH / MODERATE / LOW / TOO_CLOSE_TO_CALL), and electionDayMuhurtaScore. Discreet B2B signal for political consultancy tooling, never standalone advice; do not present as a poll or vote forecast.

Per contestant: natalScore = cov[1,5,11] minus 0.5x cov[6,7], plus match-day amplifiers (RP overlap x 5, match-start Lagna sub-lord in contestant RPs +10). Returns likelyWinner, runnerUp, and margin (CLEAR if delta is at least 15, NARROW if at least 5, otherwise EVEN_MATCH). Entertainment and curiosity lens only; never a betting recommendation, sportsbook signal, or wagering advice.

[Jaimini adjunct] Arudha Lagna, the Pada of the 1st house, representing public image / how the world perceives the native. Calculated by counting from lagna to lagna lord, then same count again from the lord. Returns AL sign, lord, occupants, the planets aspecting it by Jaimini rashi drishti (sign aspects sign, not Parashari graha drishti) with the three aspecting signs themselves, and interpretation. The disputed parts ship as stated readings, none picked: 'exceptionVariants' where the 1st/7th exception applies (the shipped 10th from where the pada fell, BPHS ch. 29; the 10th from the house, unsourced; no exception, K. N. Rao and B. S. Rao), and for a Scorpio or Aquarius lagna 'coLordFork' (the pada counted to Ketu or Rahu, and P.V.R. Narasimha Rao's stronger co-lord by his stated rules). Foundational Jaimini concept; B2B fit for personal-branding apps.

[Jaimini adjunct] Personal deity from the 12th house from Karakamsa (Atmakaraka in D9), read in the order the sources give: a planet in it; failing that, planets aspecting it by rashi drishti; failing that, its lord (Rath; A22). Several planets at a step are all returned as 'candidates', ranked by Rath's ladder (exalted, own sign, then highest longitude), with 'significatorStep' and 'rankingRule' saying how. The Karakamsa read in the rasi chart ships as 'karakamsaInRasi', and the eight-karaka Atmakaraka's reading as 'byOtherScheme' when it differs. Deity mapping (tradition): Sun→Shiva, Moon→Parvati/Gauri, Mars→Kartikeya, Mercury→Vishnu, Jupiter→Narayana, Venus→Lakshmi, Saturn→Hanuman/Brahma, Rahu→Durga, Ketu→Ganesha. The 'mantra' string is unsourced and labelled so in 'sources.mantra'. B2B fit for spiritual / wellness apps.

[Jaimini adjunct] Chara karakas ranked by exact sidereal longitude within the sign (minutes, then seconds, decide): Atmakaraka (highest, soul) → Amatyakaraka (career) → Bhratri (siblings) → Matri (mother) → [Pitri (father), eight scheme only] → Putra (children) → Gnati (obstacles) → Darakaraka (lowest, spouse). Seven or eight is a live dispute the sutra itself leaves open, so BOTH lists are always returned ('sevenScheme', 'eightScheme' with Rahu at 30 − degree) with 'schemesDisagreeOn' naming the offices that change; 'karaka_scheme' picks which one fills 'karakas' (default seven, Sun to Saturn, no node). A tie is reported at the arc-minute (kala), never the whole degree, and 'tieReadings' carries each source's rule for it (seconds decide; Rahu fills the merged office; same-longitude planets share an office), none picked. Each karaka's 'wholeSignHouse' is the Jaimini house (whole sign from the lagna); 'house' is the KP Placidus bhava, kept for continuity. Used for soul-purpose / career-coaching B2B.

[Cross-system spiritual lens] Karmic-indicator panel: 12th house planets (carry-over signatures), Saturn position (debt patterns), Ketu sign (past-life skills), Rahu sign (unfinished desires), Karakamsa (soul-direction this lifetime), 12th from Karakamsa (moksha gate). Interpretive lens, not deterministic. B2B fit for spiritual / coaching apps.

[KP-rule remedial] Lagna-friendly gemstone via KP rule (Reader 3 ch.51 'Which gem can I use?', canon p.430, printed p.417): the 1st or 11th cusp sub-lord is the candidate, MUST NOT be connected to dusthanas (6/8/12). Returns primary + secondary recommendations with stone, planet, wearing instructions; or contraindicated verdict if both candidates afflicted. B2B fit for e-commerce gemstone shops.

[Vedic Parashari] Graha-shanti mantras, the BPHS remedial practice, not KP: the KP Readers carry no mantra rule, and KSK refuses remedies (evils "cannot be averted, dodged or prevented by doing Shanthi", Reader 3 canon p.271; Reader 6 canon p.328). Scores every planet for affliction by retrogression and 6/8/12 placement; combustion and dignity are FLAGGED and not scored, because propitiating a planet for its debilitation is later Vedic remedial accretion with no footing in orthodox KP, which selects by cuspal sub lord and ruling planets (F066, Q023 section 21). Emits remedial mantras for the most-afflicted planet, the bhadhakasthana lord (always), and any secondary affliction. Each recommendation includes beejMantra, extendedMantra (Vedic stotram), recommended weekday, repetition count (108), 40-day duration, and rationale. Parashari mitigation practice, not a cure or a guarantee; never present it as a KP remedy.