Concept

Expert reading patterns

Beyond the 7-phase reading protocol, Lumin's orchestration prompt teaches the LLM six named patterns from senior practitioners. Pattern A through F. Each turns a verbose 5-15 step recipe into a single recognisable name.

Note

Three of these patterns are also exposed as deterministic composite workflow tools (Pattern B, C, E), for when latency or consistency matters more than model reasoning. The rest are chained from the protocol.

The protocol reaches the model through the server instructions string, which clients truncate, and through get_reading_protocol, which returns all six patterns as a tool result. If your client drops instructions, that call is how the patterns survive.

Pattern A: KSK Strict CSL-DBA Marriage Formula

Krishnamurti's own procedure in his Reader 4 worked cases. For marriage timing:

Run analyze_natal_promise, confirm the 7th-house CSL signifies houses 2/7/11.
Run get_significators, list the significators of houses 2, 7 and 11 at every level, and the strongest of each house by L1>L2>L3>L4.
Run get_fruitful_significators, keep the ones the ruling planets of the moment of judgement also hold. That elimination is Krishnamurti's step.
Run find_event_timing_v2, find the DBA whose mahadasha, antardasha and pratyantardasha lords are among those fruitful significators, each lord judged by its own sub lord.
Run get_transit_timing_panel, triple transit confirmation on the predicted day.
Run get_ruling_planets at the predicted moment, must overlap fruitful significators.

The result names the DBA exactly: "marriage in [MD] mahadasha, [AD] antardasha, [PD] pratyantardasha, because each lord signifies houses [2/7/11] and the ruling planets of the moment of judgement kept it."

Pattern B: Timing beside other dasha systems

KP timing is the Vimshottari dasha of the significators. Other systems' dashas can be read beside it, each with its system named, and none of them votes on it:

get_event_dasha, Vimshottari, the KP periods chosen for the event.
get_yogini_dasha, Parashari. It starts from the same Moon nakshatra as Vimshottari, so it is not an independent witness.
get_chara_dasha, Jaimini sign-based dasha, with its lineage named.

Where their date ranges overlap is not confirmation: the overlap is met by most charts whatever the event, so a miss is not low certainty either. Report each system's dates with the rule behind them, and where they part, say so and do not choose. For timing compared by each system's own procedure, use get_paradigm_panel with a target year.

Also exposed as the atomic workflow run_triple_dasha_consensus, which reports its own base rate beside every overlap.

Pattern C: Sanjay Rath Karakamsa Spiritual Lens

A Jaimini reading, for soul-purpose / dharma / spiritual questions:

get_chara_karakas, identify Atmakaraka (planet at highest degree within own sign).
get_d9_chart, a Parashari division read here by Jaimini: Atmakaraka's sign in D9 = Karakamsa.
get_ishta_devata, 12th from Karakamsa = personal deity / liberation gate.
get_d20_chart, spirituality (Vimshamsa).
get_past_life_karmic_panel, Saturn + Ketu + 12th + Karakamsa moksha-gate synthesis.

Also exposed as the atomic workflow run_karakamsa_spiritual_lens.

Pattern D: Cross-System Reading, never reconciled

When KP and another system disagree, Lumin presents BOTH, attributed, and names the rule the disagreement turns on. Never hide a disagreement, and never score agreement: two systems agreeing counts only when their reasons share nothing.

Marriage: KP analyze_natal_promise (7th CSL → 2/7/11) beside Jaimini get_upapada_lagna; Parashari get_ashta_koota_milan only for a Vedic-matrimonial consumer, labelled Parashari, since KP rejects it.
Career: KP get_job_change_vs_promotion + get_career_signature beside Parashari get_d10_chart and Jaimini Amatyakaraka in get_chara_karakas.
Children: KP get_fertility_window beside Parashari get_d7_chart and Jaimini Putrakaraka.

For marriage, career and health, get_paradigm_panel reads every system side by side and names how they relate, with no vote.

Pattern E: Strict Pre-Promise Audit

Before committing to ANY promise verdict:

get_boundary_warnings, any cusp within 6 arc-minutes of a sub-lord boundary? Only this check softens confidence, because only it says the verdict rests on the data.
get_combust_planets, reported, never subtracted. In KP a combust planet still gives its results.
get_graha_yuddha, Parashari, not KP: a war on a key planet is a cross-system note.
get_vargottama_planets, Parashari, not KP: reported the same way.

If (1) fires, present the verdict with explicit confidence-reduction language. (2) to (4) never move it. Also exposed as the atomic workflow run_pre_verdict_audit.

Pattern F: Multi-Varga Strength Aggregation

For "is this person/event truly strong" questions in Parashari terms, run get_vimsopaka_bala. It aggregates dignity across the vargas, which is Parashari and not KP. Report the 0-20 total and the band the tool itself labels; the protocol sets no cut point of its own, because none is sourced.

PreviousKP / Vedic / Jaimini / Tajik NextContact support