How the computation works
Most astrology software on the web describes what a reading feels like. This page describes what the software does: which library computes planetary positions, which house system divides the chart, how two charts are compared, and what a language model is and is not allowed to write once the numbers exist.
The specific numbers fixed here — the orb table, the fixed angles, the calculation flags — are constants the code uses today, not a computed chart for one visitor: this page describes the method, not a particular reading. Feed the same birth date, time, and place into a different ephemeris tool, and the positions and house cusps it computes should match this system's, within that tool's own rounding — except where the timezone limit described further down this page applies, which can move cusps and the Ascendant by a wide amount and shift the Moon's computed position by a smaller but still meaningful amount. Nothing below is a plan or an aspiration — it describes code that runs today.
The engine, the house system, the timezone
Ephemeris and flags
Every chart — natal or synastry — is computed with the Swiss Ephemeris library (pyswisseph), the ephemeris engine widely used across professional astrology software. Positions and speeds are read from a single call, swe.calc_ut, requesting the flag combination swe.FLG_SWIEPH | swe.FLG_SPEED: this returns a planet's ecliptic longitude and its instantaneous speed together, so retrograde motion is read directly off that same calculation rather than inferred separately afterward. This deployment ships no separate ephemeris data files, so the library computes from its own built-in Moshier semi-analytic model rather than reading precomputed positions off disk — still the Swiss Ephemeris library's own calculation, just not file-backed.
House system
House cusps come from swe.houses_ex, called with the Placidus method. Placidus is not a silent default: the record this system produces states its own house system by name, so a reading always says which method divided the chart into twelve houses.
Timezone
The UTC offset behind a birth time is resolved from the birth coordinates themselves, not typed in as a guess: latitude and longitude are reverse-geocoded to a timezone, and the standard, non-daylight-saving offset for that zone is what feeds the calculation. A birth place determines the offset; nothing lets a user override it by hand.
How a synastry reading is produced
A synastry reading starts from two independent natal computations, one chart per person, each carrying the same ten bodies, angles, and houses described above. Nothing in the comparison step recomputes a position — it only compares numbers that already exist.
Aspects and their orbs
The two charts are compared point by point for aspects. An aspect is counted when the angular distance between a point in one chart and a point in the other falls within a set margin — an orb — of one of five fixed angles:
| Aspect | Angle | Orb |
|---|---|---|
| Conjunction | 0° | 6° |
| Opposition | 180° | 6° |
| Square | 90° | 5° |
| Trine | 120° | 5° |
| Sextile | 60° | 3° |
When a pair of points is close enough to satisfy more than one of those five angles at once, only the tightest match — the one with the smallest orb — is kept, and the others are discarded rather than reported alongside it.
Ten bodies are compared this way, in both directions: Sun, Moon, Mercury, Venus, Mars, Jupiter, Saturn, Uranus, Neptune, and Pluto.
House overlays
Alongside aspects, the reading places one person's ten points into the other person's twelve houses — a house overlay — and attempts this in both directions: your points into their houses, and theirs into yours. Each direction depends on that chart's houses being usable, which needs a known, exact birth time for that person, so a reading can end up as a one-way overlay when one partner's birth time is approximate or unknown.
Birth time governs two of the numbers above. Without an exact, known birth time, house cusps cannot be trusted, so house overlays for that chart are left out of the reading entirely rather than computed from a guessed time. The Moon moves roughly a degree every two hours — fast enough to change sign or house within a morning — so any Moon-based placement in that case is marked time-sensitive in the underlying data rather than stated as settled fact.
What the language model does, and does not, do
The synastry reading on this page rests on two separate steps, and it matters which one does what. The astrology itself — which points fall into aspect, the exact orb, the house overlays — is computed by the ephemeris library and fixed before any text exists. No language model decides that, changes an orb, or adds a contact the chart does not contain. The prose you read is then written by a language model from that computed evidence and nothing else: it is handed the aspects, the orbs and the overlays, and is required to name in the text the contacts the system marked as the ones you must be told about. Its output is checked and rejected if it cites an identifier the system never computed, if it leaves a required contact unnamed, or if it promises an outcome the chart cannot prove. Where the model declines or fails these checks, the reading falls back to the deterministic renderer — fixed templates filled in with the same computed numbers — so the astrology you receive is the same either way; only the wording differs. The product's other feature, an open-ended chat consultation, works the same way: a language model writes the answer, drawing on the same kind of computed positions, transits, and aspects.
It cannot name a placement it never computed
Every computed aspect and house overlay carries its own identifier, and the deterministic chain that turns that evidence into a plan and then into reading text raises an error and refuses to produce a reading if anything in it ever points to an identifier that was never computed — that is exactly what runs, without exception, behind the reading on this page. The separate writing step, where it runs for other readings, is restricted to that same set of computed identifiers and fails its own attempt if it strays outside them — but that failure is caught rather than allowed to block the reading, and the system delivers the deterministic wording in its place instead. The rule that holds with no exception sits at the arithmetic layer: a claim is never assembled from an identifier the system never computed.
What this method cannot do
A remembered time is not a birth time
An exact birth time matters more than any other single input. Without one, house-based statements are not computed at all rather than approximated, and a Moon placement is still reported like any other fact — it is marked time-sensitive in the underlying data, as described above, not qualified line by line in the reading itself. A birth certificate or hospital record, not a remembered guess, is what this calculation needs to do its best work.
Two separate timezone bugs
The UTC offset behind a birth time is computed by sampling this year's timezone rules for January and July and keeping whichever offset is smaller — which is always the zone's standard, non-daylight-saving offset. That creates two separate problems, not one. The common one: any birth that actually fell during a period when the local clock was set forward for daylight saving is computed with the standard offset instead, off by the daylight-saving delta — typically an hour, enough to move the Ascendant and house cusps by roughly fifteen degrees, often into a different sign, and the Moon's computed position by about half a degree; this affects a birth in any year, not only recent ones, and does not depend on which year the sampling happens to run in. The separate, rarer one: because the sample is taken from this year rather than the birth year, a zone whose permanent, year-round offset has itself changed since the birth year is computed with today's offset instead of the birth year's — Moscow's standard offset shifted between UTC+3 and UTC+4 more than once between 2011 and 2014, and Istanbul's changed permanently in 2016, so a birth in one of those years can be off by an hour with no daylight-saving season involved at all. If a birth falls in a period when its timezone's rules, seasonal or permanent, differed from today's, treat the resulting cusps, Ascendant, and Moon placement with the same caution as an imprecise birth time.
House systems disagree
Placidus is a choice, not the only defensible answer. House division is a genuinely unsettled question in astrology: Placidus, Whole Sign, Koch, Equal, and other systems assign different cusp degrees — sometimes different house positions entirely — to the same birth data. This system states which one it uses so a reading can be compared like for like; it does not claim Placidus is the correct house system, only the one in use here.
Computation ends where interpretation begins
A planet's position at a given moment is checkable by anyone: open an ephemeris, run the same date, time, and place, and the number comes back the same. What that position is said to mean is not checkable in the same way. It is an interpretive convention rather than a measurement, and it is not predictive — a reading here does not forecast whether a relationship will succeed and passes no verdict on anyone's future.
How to verify a computed position
Every number on this page comes from arithmetic, not from the language model, which makes it falsifiable: take the same birth date, time, and place into any other tool built on an ephemeris library, request the Placidus house system, and the planetary longitudes and house cusps it returns should match what this system computes, within that tool's own rounding. Choosing a different house system on purpose will change the cusps by design — that part of a mismatch is expected. A mismatch that persists with the same house system selected in both tools is worth checking against birth-time precision and time-zone handling, covered in the limits above, before assuming it is settled by house-system choice alone.
See this computation applied to two charts
The synastry mechanics above are what runs behind every Love Astrology reading.