Advanced techniques
Paradigm Panel (one matter, every system, as parallel arguments)
get_paradigm_panel
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.
Parameters
| Name | Type | Required | Description |
|---|---|---|---|
| birth_datetime | string | Yes | Birth date and time in ISO 8601 format (e.g., "1990-05-15T14:30:00"). |
| latitude | number | Yes | Birth location latitude. Range: -90 to 90. |
| longitude | number | Yes | Birth location longitude. Range: -180 to 180. |
| utc_offset_minutes | number | Yes | UTC offset in minutes (e.g., 330 for IST, -300 for EST). |
| ayanamsa | enum: kp | kp_new | lahiri | raman | true_chitra | khullar | No | Ayanamsa system. Defaults to kp. |
| matter | unknown | Yes | The matter to read. Required. |
| systems | unknown | No | Systems to include. Default: all seven. |
| event | unknown | No | Override the matter's default KP event key (marriage -> Marriage, career -> Career / Job Start, health -> Chronic Illness). |
| target_year | unknown | No | Naming a year is the only thing that makes Tajik speak. |
| frames | unknown | No | no description |
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_paradigm_panel",
"arguments": {
"birth_datetime": "1992-08-14T04:32:00",
"latitude": 6.927,
"longitude": 79.861,
"utc_offset_minutes": 330,
"ayanamsa": "kp"
}
}
}Birth data
This tool requires birth data on every call. The MCP server is stateless, so calling set_birth_profile first validates the data and returns the reading plan, but it does not store anything. Repeat the same five fields here.