Advanced techniques

The Sixteen Tajik Yogas [Tajik]

get_tajik_yogas

[Tajik] Tajik's OWN judgement mechanism, which this engine did not have before 2026-09-14. The sixteen shodasha yogas from the Hayanaratna in Gansten's parallel Sanskrit-English CRITICAL EDITION (Brill, 2020), quoting Tajikabhusana 4.4-6, with the orb table from Daivajnalamkrti 8.9. 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. FOURTEEN of the sixteen have a stated definition and are computed; khallasara and duhphalikuttha are named in the verse and defined nowhere, so they come back in 'notComputed' rather than being omitted or invented. manau and kuttha are read as an obstruction by some authorities and its opposite by others: both ship with sense 'two-sided' and neither is resolved. 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, one built and one not. **Mudda** is computed: nine periods from the solar return, each planet's Vimshottari years times three giving its days, in Vimshottari order from a starting lord the sources give a formula for. Two things are reported rather than resolved: the formula's remainder-to-lord mapping is not stated, so the reading used is declared with its evidence (it is the only offset under which every nakshatra opens on its own lord in the first varsha), and the nine periods total 360 days against a real return interval of about 365.26, so 'periods' carries the stated figures (ending ~5 days short) and 'periodsScaledToYear' carries one labelled derivation that fills the year, with the residual named. Kalidasa's variant, reading the ANNUAL chart's Moon nakshatra instead of the natal one, ships beside the primary. **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.

Parameters

Example call

Send the request as a standard MCP tools/call:

POST https://mcp.lumin.guru/mcp
Authorization: Bearer mcp_yourkey...
Accept: application/json, text/event-stream
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_tajik_yogas",
    "arguments": {
      "birth_datetime": "1992-08-14T04:32:00",
      "latitude": 6.927,
      "longitude": 79.861,
      "utc_offset_minutes": 330,
      "ayanamsa": "kp"
    }
  }
}