deep-dive

An anti-hallucination architecture for astrology AI

How the Vedika astrology API keeps AI answers grounded: deterministic ephemeris math, computed chart facts, classical citations, and a post-generation validator.

The hardest problem in putting AI on top of astrology is not generating fluent prose — any modern language model does that effortlessly. The hard problem is stopping it from confidently inventing planetary positions, fabricating dasha dates, or attributing a claim to a classical text that does not contain it. The Vedika API addresses this with a layered architecture: a deterministic ephemeris computes every astronomical fact first, a retrieval layer pulls only real classical sources, and a post-generation validator reconciles the written answer against both before it ever reaches your application.

Why astrology AI hallucinates by default

A naive integration sends a birth time and a question straight to a language model and asks it to do everything — calculate the chart and interpret it in one pass. That design fails in two distinct ways, and it is worth separating them because they need different fixes.

Numeric hallucination

Ask a general-purpose model where the Moon was at a specific minute decades ago and it will produce a plausible-looking longitude that is simply wrong. Planetary positions are the output of orbital mechanics, not of pattern-matching over text. A model that “remembers” ephemeris tables approximately will drift by degrees, and in astrology a few degrees can move a planet into a different sign, nakshatra, or house — changing the entire reading.

Interpretive hallucination

The second failure is subtler. Even with a correct chart, a model asked to justify a reading will happily cite “Brihat Parashara Hora Shastra, chapter 7, verse 23” whether or not that verse says anything of the kind. For a consumer toy this is harmless. For a B2B product whose customers build paid services on top of the answers, a fabricated citation is a liability. The fix is to never let the model be the source of truth for either the math or the provenance.

Layer one: deterministic computation before any AI

Every request that reaches the interpretation layer has already passed through the XALEN Ephemeris, Vedika’s own astronomical engine. It is open source under Apache-2.0 and published across ecosystems — crates.io/xalen, xalen on PyPI, and @xalen/wasm on npm — with roughly 2,200 tests in its own suite. It is validated against reference astronomical data (JPL DE440 and an independent ephemeris implementation), and across a five-million-chart test no chart deviated beyond 0.1 degrees.

One distinction matters here and the architecture is careful about it: that 0.1-degree figure describes astronomical precision — where a body actually sits in the sky — not “astrology accuracy,” which is interpretive and not something any engine can certify. The engine guarantees the inputs are right; it makes no claim about whether a given interpretive tradition is correct.

From the chart, the platform computes the structured facts an interpretation depends on: the ascendant and the twelve house cusps, sign and nakshatra placements, planetary aspects and lordships, divisional charts, dasha and bhukti periods, and a library of yogas detected by code rather than asserted by the model. By the time the language model is invoked, the question “where is Mars” is already answered and frozen. The model’s job is narrowed to explanation, not calculation.

Because Vedika serves three systems in one API — Vedic (sidereal), Western (tropical), and KP — the computation layer also enforces system isolation. A Western tropical chart is never silently mixed with a sidereal house system; each system computes its own facts so the AI cannot blur them together.

Layer two: retrieval over real classical sources

Grounding the interpretation is a retrieval problem. Rather than trusting the model’s parametric memory of astrological literature, the platform retrieves passages from a curated corpus of texts that practitioners are actually trained on in formal Jyotish, KP, and Western certification — Brihat Parashara Hora Shastra, Phaladeepika, Saravali, Jataka Parijata, the Jaimini Sutras, the KP Readers, and Ptolemy’s Tetrabiblos, among others. Blog summaries, encyclopedia entries, and “as commonly known” paraphrases are deliberately excluded, because those are exactly the kind of low-trust material that produces confident-but-unsourced claims.

The retrieved passages are passed to the interpretation step as the only permitted authority for any traditional claim. This inverts the usual relationship: the model does not recall a verse for the system to verify afterward; the system supplies the verse and the model works within it. When no genuine source supports a claim, the correct behaviour is to decline rather than to bluff.

Layer three: post-generation validation

The final layer runs after the model produces text and before the response is returned. It reconciles the written answer against the computed facts from layer one. If the prose says the ascendant is in one sign but the engine computed another, the discrepancy is caught and corrected rather than shipped. The same pass checks that citations correspond to retrieved material and strips internal implementation details so they never appear in customer-facing output.

This is the step most often skipped in DIY integrations, and it is the one that turns a fluent demo into a dependable service. A model can be right most of the time and still be unusable in production if you cannot tell which answers are wrong. Reconciling generated text against deterministic facts converts an unbounded failure mode into a bounded, detectable one.

What this looks like in your code

The natural-language path is a single endpoint. You send the question and the birth details; the layered pipeline runs server-side and returns a grounded answer.

curl -X POST https://api.vedika.io/api/v1/astrology/query \
  -H "x-api-key: vk_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "question": "What does my chart say about career timing this year?",
    "birthDetails": {
      "datetime": "1990-08-15T08:45:00",
      "latitude": 19.0760,
      "longitude": 72.8777,
      "timezone": "Asia/Kolkata"
    }
  }'

If you want to audit the grounding facts directly — the layer the explanation is built on — call the V2 computation endpoints, which return the structured chart with flat coordinate fields:

const res = await fetch("https://api.vedika.io/v2/astrology/chart", {
  method: "POST",
  headers: {
    "x-api-key": "vk_live_your_key_here",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    datetime: "1990-08-15T08:45:00",
    latitude: 19.0760,
    longitude: 72.8777,
    timezone: "Asia/Kolkata",
  }),
});

const chart = await res.json();
// chart.ascendant, chart.planets, chart.houses, chart.dashas ...
// these are the deterministic facts the AI answer is constrained to

For interactive experiences, the streaming variant emits the answer over Server-Sent Events:

curl -N -X POST https://api.vedika.io/api/v1/astrology/query/stream \
  -H "x-api-key: vk_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{ "question": "...", "birthDetails": { "...": "..." } }'

Add "speed": "fast" to the query body when latency matters more than maximum depth; the fast path is available on the Business and Enterprise plans. Both paths run the same grounding pipeline, so the fast option trades response time, not factual discipline.

Wiring it into LLM agents and tools

The same grounding guarantees apply when an AI assistant calls Vedika as a tool. Vedika publishes a public astrology MCP server — npx @vedika-io/mcp-server, exposing 36 tools — so an MCP-compatible client or IDE can request charts and readings without your having to hand-roll function schemas. Because the heavy lifting (computation, retrieval, validation) happens behind the endpoint, a function-calling model orchestrating the workflow inherits the anti-hallucination properties for free: it receives computed facts and sourced interpretations, not raw guesses it then has to second-guess.

This is the right division of labour. Let your own LLM agent decide when to ask an astrological question and how to present the answer to the user; let Vedika own the part where being wrong is expensive.

Key facts

How it compares

Several established astrology APIs do their core job well. Prokerala (around $19/mo) offers broad Vedic coverage and a long track record; AstrologyAPI.com (around $29/mo) has a mature catalogue of calculation endpoints; RoxyAPI (around $39/mo) provides solid Western data. If your need is purely raw computation, any of them may fit.

Where Vedika differs is the combination of a self-owned, openly auditable ephemeris, three astrological systems behind one key, a natural-language layer with the grounding pipeline described above, and classical-source citations that a domain expert can check. Starter access is $12/mo, scaling to Professional at $60, Business at $120, and Enterprise at $240, with per-query usage in the $0.01–$0.05 range. You can compare plans on the pricing page and read the integration details in the docs.

Try it without a key

The architecture is easiest to understand by poking at the responses. The free sandbox exposes mock endpoints with no authentication, so you can see the request and response shapes — including the structured chart facts that feed the AI — before you write a line of integration code. When you are ready for live charts, drop in a vk_live_ key and point at api.vedika.io. For a deeper look at how the citation layer chooses sources, see our companion piece on classical-source citations in the API.

FAQ

Does the astrology AI compute the chart, or does the language model guess the positions?

The chart is computed deterministically by the XALEN Ephemeris engine before any language model runs. The AI receives those facts as fixed inputs and only explains them, so it never invents a planetary position.

How are astrological interpretations kept from being made up?

Every interpretive claim is traced to a classical source actually used in formal training. A retrieval layer surfaces the relevant passages, and a post-generation validator checks the answer against the computed facts and the cited material before it is returned.

What is the difference between ephemeris precision and astrology accuracy?

Ephemeris precision is an astronomical measurement of where a body actually is. The engine is validated to within 0.1 degrees across a five-million-chart test. Astrology accuracy is interpretive and subjective; the architecture keeps interpretations sourced and consistent with the math but makes no claim to measure it.

Can I see the grounding facts the AI used for an answer?

Yes. The computed chart is available through the V2 computation endpoints under /v2/astrology/*, and the natural-language answer is built on that same layer, so you can audit what fed the explanation.

Build on the Vedika astrology API

700+ operations, Vedic + Western + KP, 30 languages, an open-source XALEN ephemeris, and a built-in LLM. Free sandbox — no signup.

Try the free sandbox