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 writers 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: a deterministic fact layer feeds a strictly gated prose layer, and the two never blur.

Reduced to one sentence: facts are computed, prose is rendered, and prose is never allowed to contain a claim absent from the facts.

The fact/prose wall

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.

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

• Claim extraction. 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 lint. 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. The fallback path means the gate can afford to be strict: there is never a publishing deadline that 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 artifacts; 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, at fact-sheet construction — 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 is not caught by review — it cannot 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 force-included in 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 monotone function of the selected events’ polarities and intensities — never an independent editorial judgment that could drift from the details beneath it.

Same engine, same calc_version

The sky-state extraction that feeds this pipeline runs the same engine, at the same calc_version, as the live computation API. If you call the positions endpoint for a given moment and read the horoscope derived for that day, they are answers from one calculation — the content can never disagree with the API about where the planets are. Fact sheets record the calc_version (engine) and rules_version (the versioned classical interpretation tables) that produced them, so every published artifact 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 gates 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.