Gochara is the most-used Vedic technique for reading day-to-day transits. For each of the seven non-nodal grahas, the classical source assigns favourable houses from a natal reference point — usually the natal Moon's sign — and pairs each favourable house with a corresponding vedha (obstruction) house. When a transiting graha sits in a favourable house but another graha simultaneously sits in the paired vedha house, the favourable transit is obstructed.

That is the geometry. The hard design question is: how much of the surrounding interpretation should live inside Vedākṣha?

The decision: ship the geometry, leave the school

Different classical sources record slightly different vedha pair tables. Different schools — Parashari, KP, others — apply different exemption rules on top: the Sun and Moon do not vedha each other in the Parashari convention, Jupiter and Mercury do not vedha each other, and so on. Every commercial astrology product that touches Gochara picks a school and bakes the exemptions into the engine.

Vedākṣha takes the opposite line. The library returns the raw geometric picture — the favourable / unfavourable verdict per BPHS Ch.29, the house from natal, and the full unfiltered vedha candidate list. Exemption rules ship as a separate helper and a SchoolProfile enum, applied per entry by the caller.

That separation is what lets a caller use the same Vedākṣha output to render a Parashari reading on one screen and a strictly-geometric KP reading on the next, without re-computing anything.

Four design choices worth naming

Bundle, not per-planet. compute_gochara returns all seven grahas in one call. Vedha is inherently cross-planet — checking whether Saturn obstructs Sun's transit requires a simultaneous view of every other graha's position.

Vec, not Option. vedha_candidates is a Vec<YogaPlanet>, not Option<YogaPlanet>. Collapsing to a single "the obstructor" would bake one school's interpretation into the geometry. Returning every candidate keeps that decision on the caller's side.

VedhaTable enum. Even though only Bphs29 ships today, the pair-table source is a parameter, not a hard-coded constant. Future tables drop in without breaking callers.

Reference point as input. The function takes a natal reference sign index — the caller decides whether that is the natal Moon (Chandra Gochara) or the natal Lagna. Both conventions exist in the literature, and the engine should not pick.

What ships in v2.2.0

The new vedaksha_vedic::gochara module exposes:

compute_gochara(transits, natal_reference_sign, vedha_table) → Vec<GrahaGochara>

apply_vedha_exemptions(entry, school) — strips Sun/Moon and Jupiter/Mercury mutual vedha under SchoolProfile::Parashari, leaves geometry untouched under SchoolProfile::Geometry

GrahaGochara { graha, transit_rashi, natal_reference_rashi, house_from_natal, classical_effect, vedha_candidates, ashtakavarga_score: Option<u8> }

VedhaTable::Bphs29, GocharaReference::{Chandra, Lagna}, SchoolProfile::{Geometry, Parashari}

MCP tool compute_gochara and a matching WASM binding — same JSON-in / JSON-out contract as the rest of the v2.1.0 Vedic primitives

Rahu and Ketu are deliberately not iterated as Gochara grahas. BPHS Ch.29 is silent on the nodes; rather than invent a default, we leave them out and let callers extend the model if they wish.

Calling it

use vedaksha_vedic::gochara::{
    apply_vedha_exemptions, compute_gochara,
    SchoolProfile, TransitPositions, VedhaTable,
};

let transits = TransitPositions {
    sun: 0, moon: 4, mars: 2, mercury: 6,
    jupiter: 8, venus: 10, saturn: 6,
};

let mut entries = compute_gochara(
    &transits,
    /* natal_reference_sign */ 0, // 0 = Aries
    VedhaTable::Bphs29,
);

for entry in entries.iter_mut() {
    apply_vedha_exemptions(entry, SchoolProfile::Parashari);
}

The MCP equivalent takes the same eight sign indices plus optional vedha_table and school strings, and returns the same { entries: [...] } shape over JSON-RPC.

Surface-area changes

MCP tool count: 11 → 12. New tool: compute_gochara.

WASM exports: one new entry point compute_gochara(input_json).

vedaksha-vedic gains the gochara::* module alongside ashtakavarga::*, combustion::*, karaka::* and shadbala::*.

v2.1.0 callers do not need to change a line. v2.2.0 is a purely additive minor release.

Upgrade: cargo update -p vedaksha · Tool catalog: /docs/mcp · Vedic features: docs.rs/vedaksha-vedic

Vedākṣha v2.2.0 — Gochara, the way it should be designed

The decision: ship the geometry, leave the school

Four design choices worth naming

What ships in v2.2.0

Calling it

Surface-area changes