Vedākha

वेदाक्ष·vedaksha·"vision from vedas"byArthIQ Labs

An astronomical engine and Vedic computation library, built clean-room in Rust for the agentic AI era.

BSL 1.1 → Apache 2.0 in 5 years·arthiqlabs/vedaksha

Live ephemeris · computed in your browser

SUN 06°22'14" ·MOON 104°08'39" ·MARS 303°51'02" ·MERCURY 354°44'21" ·JUPITER 020°48'17" ·VENUS 330°16'55" ·SATURN 344°12'08" ·AYANAMSHA Lahiri 24°08'22"·TITHI Krishna Saptami

Repository · github.com/arthiqlabs/vedaksha

800934e docs(readme): add Python/PyPI to the install table and fix examples 2026-07-24·✓ CI passing·v4.0.0·820 tests·9 crates·BSL 1.1·1
Chapter I — six decisions

Six architecture decisions, six receipts.

Choosing an ephemeris backend isn't faith-based. Each section names a question a developer or product manager actually asks before adopting a library, and answers it with code that runs.

01 · AI AGENTS

Will it work for AI agents?

Vedākṣha exposes a 15-tool Model Context Protocol surface that an LLM agent can discover with a single tools/list call. Schema is generated from Rust definitions; no parallel hand-edited catalog can drift.

The canonical introspection mirror at https://vedaksha.net/api/mcp answers initialize, ping, tools/list, get_version, and tools/call over JSON-RPC 2.0. Tool schemas mirror the live tool_definitions() in the Rust source; a drift-guard test (snapshot_matches_current_tool_definitions) fails CI if the published tools/mcp-tools.json snapshot diverges. To run these tools, self-host the library or build from source — the introspection mirror is read-only by design.

# Discover the canonical 15-tool catalog
curl https://vedaksha.net/api/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

For a fast no-install evaluation, a small technology showcase with 4 agent-friendly demo tools is hosted at mcp.vedaksha.net/mcp (free tier, anon, IP-rate-limited) — separate surface, not the full library.

RECEIPT · 15 tools · auto-generated · drift-guarded · last verified 2026-07-23
02 · VEDIC FEATURES

Will Vedic features work correctly?

Jyotish concepts live in the type system, not as wrappers. Sources cited inline — every enum variant traces back to BPHS chapter and verse.
// vedaksha-mcp · compute_dasha
// Sources: BPHS Ch.46–47, Jaimini Sutras
pub enum DashaSystem {
    Vimshottari, // 120-yr · 9 lords · moon
    Ashtottari,  // 108-yr · 8 lords · moon
    Yogini,      // 36-yr · 8 yoginis · moon
    Chara,       // Jaimini · lagna-based
    Narayana,    // Jaimini · lagna-based
}
5 dasha systemsBPHS Ch.46–47
27 nakshatras with padaBPHS Ch.3 vv.4–9
16 vargas (D-1 → D-60)BPHS Ch.6
44 ayanamshasIAU 2006 P03; Lahiri/KP/FB epoch-anchored
10 house systemsplacidus → sripathi
shadbala (full)BPHS Ch.27–28
ishta / kashta phalaBPHS Ch.28 vv.5–6
ashtakavarga (bhinna + sarva)BPHS Ch.66–69
combustion (per-planet orbs)BPHS Ch.7 vv.28–29
chara karakas (7 + 8 schemes)Jaimini Sutras
gochara (transit interpretation)BPHS Ch.29
graded drishtimars / jupiter / saturn special
7 languagesen · hi · sa · ta · te · kn · bn
RECEIPT · 14 Vedic systems · cited grid · last verified 2026-04-29
03 · CHART QUERIES

Can I do non-trivial chart queries?

Every chart is a property graph — 9 node types, 12 edge types — emittable to Cypher, SurrealQL, or JSON-LD.
// vedaksha-emit · CypherEmitter
// 9 node types · 12 edge types
MERGE (c:Chart {id:"chart_2024_03_20"})
MERGE (sun:Planet {name:"Sun"})
MERGE (sun)-[:Occupies]->(:Sign {name:"Pisces"})
MERGE (sun)-[:PlacedIn]->(:House {number:4})
MERGE (sun)-[:InNakshatra]->(:Nakshatra {name:"U.Bhadrapada"})

// then traverse like any graph
MATCH (m:Planet {name:'Mars'})
   -[:Aspects]->(s:Planet {name:'Saturn'})
RETURN m, s

Deterministic IDs mean re-emitting the same chart is idempotent. Multi-chart queries (matchmaking, transit synastry, RAG over a chart corpus) become graph patterns instead of bespoke loops.

RECEIPT · Cypher emit · graph traversal · last verified 2026-04-29
04 · DEPLOYMENT

Will it run where I deploy?

One Rust codebase, every modern target. Six install paths. No FFI to a C library, no platform-specific build.
rustcargo add vedakshaLinux · macOS · Windows · BSD
pythonpip install vedakshareal engine via WASM · any OS · Python ≥ 3.9
wasmnpm i vedaksha-wasmzero data files · browser & edge
dockerdocker run -e VEDAKSHA_MCP_TOKEN=<token> -p 3100:3100 ghcr.io/arthiqlabs/vedaksha-mcpMCP server on 3100 · amd64 + arm64
mcp stdiovedaksha-mcpClaude Desktop · Cursor · VS Code
sourcegit clone https://github.com/arthiqlabs/vedakshabuild & test from a fresh checkout

Run cargo test --release from a fresh clone — 820 unit tests run in under a minute. The full suite (873 tests) adds 24,350 oracle comparisons against JPL Horizons DE441 plus live-fetch validation.

RECEIPT · 6 install paths · last verified 2026-07-23
05 · BIRTH DATA

Will I get sued for handling birth data?

The engine never sees PII. Names, addresses, emails are not in the type system. Data classification is.
// MCP input schema for compute_natal_chart —
// the entire surface area an agent or client sees.
{
  "required": ["julian_day", "latitude", "longitude"],
  "properties": {
    "julian_day":   { "type": "number" },
    "latitude":     { "type": "number" },
    "longitude":    { "type": "number" },
    "house_system": { "type": "string" },
    "ayanamsha":    { "type": "string" }
  }
}

// fields not in the schema, by construction:
//   name, email, birth_date, address, phone,
//   user_id, ip_address, device_id

// every output graph is tagged at construction:
ChartGraph {
  …,
  classification: DataClassification::Anonymous,
}
// upgrade to Pseudonymized / Identified is an
// explicit caller decision, never the default.

Names of people never enter the engine. Every output graph carries a DataClassification tag so downstream systems can enforce retention and access policy. GDPR and HIPAA-adjacent compliance is a property of your data layer, not the math layer.

RECEIPT · DataClassification enum · ChartGraph carries the tag · last verified 2026-04-29
06 · ACCURACY

Is the math right?

Clean-room implementation. Every algorithm cited to a primary source. Accuracy measured against JPL references — Horizons DE441 and DE440s.
SpkReader — all bodies (DE440s kernel)0.106″ avg1.184″ max, vs 15,350 JPL Horizons DE441 positions, 1900–2025
Moon longitude (ELP/MPP02)0.015″J2000, vs live-fetched JPL Horizons DE441; 0.020–0.053″ over 1500–2500 CE
Moon longitude (analytical)0.17″ avg0.61″ max, vs JPL Horizons DE441, 1900–2025
Planets + Sun + Moon (analytical)2.06″ avg24.22″ max (Venus), vs JPL Horizons DE441, 1900–2025
Sun longitude (analytical)4.09″ avg7.00″ max, vs JPL Horizons DE441, 1900–2025
Osculating node0.6″ maxTrueNodeOsculating, vs JPL Horizons DE441 across 2,435 epochs, 1900–2100
Ayanamsha0.003–0.005°Lahiri · Fagan-Bradley · KP vs cited constants; other 41 range-checked
Validation24,350 oracle rows820 tests per push · 873 in scheduled full validation

Sources cited inline in the source tree: Meeus (Astronomical Algorithms), Bretagnon & Francou (VSOP87A), Chapront (ELP/MPP02), Santhanam (BPHS), JPL DE440 / DE441.

RECEIPT · 820 tests · JPL-measured accuracy table · last verified 2026-07-16
Chapter II — receipts & terms

The proof, the numbers, and the terms.

Where the engine runs in production, what we measured to back every claim above, and the license you actually buy.

Reference deployment

KundaliMCP runs on Vedākha core.

The same library described above is the compute layer for KundaliMCP — a fully-packaged managed MCP serving the full Vedic computation suite, including narrative generation and multilingual output. Built and operated by the same team at ArthIQ Labs. Engine, then product.

17 MCP tools — qualified yogas, all 5 dasha systems, vargas, transits, muhurta, narrative generation. Parashari interpretation, 7 languages. Operator-blind tenant cache; zero PII storage.

kundalimcp.com →·launch post →·Same team · two layers · engine then product

Repo hygiene

How the engine is built.

Tests, signing, scanning, drift-guards. The engineering controls we run on every commit so accuracy claims and tool catalogs don't silently rot.

Unit tests820 tests per push
Full validation suite873 tests · scheduled
Signed commitsrequired on main
Linear historyenforced on main
Dependabotalerts + security PRs
Secret scanningpush protection on
License compliancecargo-deny on PR
MCP catalog drift-guardsnapshot test

Source · .github/workflows ↗·tests/oracle_jpl ↗

Provenance

Primary sources.

Every algorithm and every Vedic rule traces back to a citable primary source. Modern astronomy from peer-reviewed papers and IAU standards; classical Jyotish from public-domain Sanskrit treatises in their canonical translations.

JPL DE440 / DE441 (SPK)high-precision planetary ephemerismodernNASA · public domain
VSOP87A · Bretagnon & Francou (1988)analytical planetary theorymodernBureau des Longitudes
ELP/MPP02 · Chapront (2002)analytical lunar theorymodernBureau des Longitudes
IAU 2006 P03 (5th-order precession)precession modelstandardIAU recommendation
IAU 2000B nutationnutation modelstandardIAU recommendation
Meeus, Astronomical Algorithms (2nd ed.)rise/set, conversions, true nodereferenceWillmann-Bell
Espenak–Meeus ΔT polynomialDelta T predictions to 2050referenceNASA/GSFC
IERS measured ΔT (1620–2025)Delta T historical tablestandardIERS · public
Brihat Parashara Hora Shastradasha, vargas, shadbala, gochara, ashtakavargaclassicalR. Santhanam transl.
Saravali · Kalyana Varmagochara vedha tablesclassicalR. Santhanam transl.
Jaimini Sutraschara karakas, char / narayana dashaclassicalP.S. Sastri transl.

Inline citations live in the source — every module that implements a cited algorithm carries a doc-comment // Source: line. Example: compute_dasha.rs ↗.

License

BSL today. Apache in five years.

$500 one-time per organization for commercial use; free for non-commercial. No subscription. No per-seat. No data retention.

Secure checkout via Stripe.·BSL 1.1 → Apache 2.0 conversion: see /legal/bsl