How horoscopes are derived

Content endpoints are in development

The live API currently serves computation endpoints only — horoscope content endpoints do not exist yet. This page documents the method they will use, published ahead of launch, deliberately: you should be able to audit a provider’s methodology before you build on it, not after.

Most horoscope APIs serve editorial content — text written by hand or generated loosely by a language model, at best vaguely inspired by the sky. That content can’t be tested, can’t be explained, and quietly contradicts itself across a week.

We take the opposite position. Both major traditions define, with considerable precision, what a daily or weekly prediction is computed from. So a horoscope here is a derivation, not a composition: facts are computed, prose is rendered, and the prose is never allowed to contain a claim absent from the facts.

Every claim maps to a checkable fact

Every horoscope is generated from a structured fact sheet produced by deterministic stages: the day’s sky state is extracted by the calculation engine, projected through classical rule tables for each audience segment, then ranked and selected under coherence constraints. Only after the fact sheet is fixed does text generation begin — and the text layer may verbalize, prioritize, and adjust tone, but it may never introduce an astrological claim, entity, or judgment that isn’t in the sheet.

That separation is enforced mechanically, not by convention. Before any generated text is published, it must pass an automated validation gate:

• Claim mapping. An automated pass lists every astrological entity and claim in the prose; each must map to a fact-sheet entry. An unmapped claim is a rejection, full stop.
• Sentiment-vs-rating consistency. The tone of the prose is checked against the computed overall and per-domain ratings. Text can’t read as glowing over a day the facts scored as difficult.
• Style and safety checks. Banned constructs (medical, financial, and legal directives; deterministic doom phrasing), length bounds, and per-language sensitivity rules.

Rejected text is regenerated a bounded number of times; if it still fails, the system falls back to a deterministic template renderer built from the same fact sheet. That fallback is what lets the gate stay strict: no publishing deadline ever pressures a bad generation through.

The Western sun-sign method: solar charts

Sun-sign horoscopes here use the solar chart method — the professional columnist’s technique, systematized. For each of the twelve signs, a solar chart is erected: the sign itself becomes the 1st house, with whole-sign houses following in zodiacal order. The day’s actual sky — the same positions the computation API serves — is then projected into all twelve charts:

1. Transit-to-house projection. Every transiting planet lands in a specific house of each solar chart. Mars in Capricorn is the 10th house for Aries but the 8th for Gemini — the same planet, a genuinely different life domain per sign.
2. Mundane aspects, localized. Each exact or applying aspect between transiting planets is read through each chart’s rulerships: Venus trine Jupiter is one event in the sky, but per chart it connects the specific houses those planets occupy and rule, producing a domain-specific event for each sign.
3. The Moon layer. The Moon’s solar-house position is the daily mood driver, the lunar phase sets the framing (initiation at the new Moon, culmination at the full), and void-of-course windows supply concrete timing notes — a feature serious Western readers watch for and incumbent APIs don’t surface.
4. Slow-planet arcs. Jupiter, Saturn, and outer-planet ingresses and stations into each solar house form the multi-week storylines behind weekly, monthly, and yearly readings; the yearly reading is structured around them and the eclipse pairs falling in each chart’s houses.

This is why twelve genuinely different horoscopes come out of one sky. The lazy alternative — one text with the sign name swapped — is structurally impossible here, because each sign’s fact sheet is a different projection of the same events.

Domain splits can never contradict each other

Love, career, and finance readings are filters over the same event list: the love horoscope selects the Venus, Moon, and 5th/7th-house events from the sign’s fact sheet; the career reading selects the 10th/6th-house and Saturn material. They are never independently generated texts. A love reading and a career reading for the same sign on the same day are two views of one derivation, so they cannot disagree about what the sky is doing.

Coherence is a hard constraint

Two guarantees are enforced structurally, when the fact sheet is built — before prose exists to check:

• Cadence containment. Weekly fact sheets are built from the seven daily fact sheets plus week-scale events; monthly from weekly. A “challenging week” containing five favorable days isn’t caught by review — it can’t be emitted, because the weekly rating is a defined aggregate of the days it contains.
• Temporal explainability. If a sign’s rating moves more than a bounded amount between consecutive days, the sky-state diff must contain a qualifying event — a Moon sign change, a station, an ingress, a phase change — and that event is forced into the day’s selection so the text explains the shift. Mood swings without astronomical cause don’t pass.

The overall rating itself is a defined function of the selected events’ polarities and intensities — never an independent editorial judgment that could drift from the details beneath it.

The same engine as the computation API

The sky-state extraction that feeds this pipeline runs the same engine, at the same calculation version, as the live computation API. Call the positions endpoint for a given moment and read the horoscope derived for that day, and they are answers from one calculation — the content can never disagree with the API about where the planets are. Each fact sheet records the engine version and the rules version (the versioned classical interpretation tables) that produced it, so every published reading is traceable to its exact inputs.

The Vedic tradition follows the same fact-first architecture, with its own classical rules tables (Gochara transit results with the mandatory vedha obstructions, nakshatra-based Tara Bala) documented separately.

Where determinism ends, honestly

The fact layer is fully deterministic: same date, same rules version, same engine version — same fact sheet, byte for byte, golden-tested like the computation API itself.

The prose realization is not deterministic — it is generated, then held to the gate above, with the template fallback behind it. We state that boundary plainly rather than claiming determinism where it doesn’t hold. What makes it safe to build on is that the fact sheet ships alongside the prose: every published horoscope carries its machine-readable derivation — the triggering configurations, domains, polarities, intensities, and ratings. If your product needs guarantees stronger than gated text, build your UI on the facts and treat the prose as one rendering of them.

Audit this method

The derivation rules are versioned data with classical citations, the coherence constraints are validation checks rather than editorial guidelines, and the fact sheet is part of the product surface. When the content endpoints launch, every claim on this page will be checkable against live responses — which is the point of publishing it now.