How Birth Time Rectification Works: A Technical Guide for Developers

A professional rectification consultation costs $200-$500. The astrologer spends 2-6 hours cross-referencing transits, progressions, and solar arcs against your life events, checking each candidate birth minute by hand. Marriage on June 15, 2018? They look for Saturn hitting an angle, progressed Moon in the 7th, solar arc Venus to the Descendant.

We automated that entire process into a single REST endpoint. Submit life events, get ranked candidate times with full scoring evidence in under 60 seconds.

Nobody else has built this. We checked every provider.

Why birth time matters (the 4-minute problem)

Here's the thing about birth time in astrology: the Ascendant (rising sign) moves about 1 degree every 4 minutes. That means a 20-minute error shifts your entire house system by 5 degrees. House cusps land in different signs. Planets change houses. Every house-based technique breaks.

Transit analysis? Needs accurate angles. "Saturn conjunct MC" triggers career events, but if your MC is 5 degrees off, Saturn was actually conjuncting empty space when you got promoted. Secondary progressions? The progressed Moon moves 1 degree per month, so even small birth time errors cascade into years of timing offset. Solar arc directions? Same problem. The directed Ascendant sweeps ~1 degree per year, and a birth time error of 4 minutes means your solar arc predictions are off by about 4 years.

For app developers, this creates a real UX problem. About 30-40% of users don't know their exact birth time. Their birth certificate says "approximately 2 PM" or just "afternoon." Every feature you build on top of an inaccurate chart produces inaccurate results. Rectification is the fix.

What rectification actually does

Rectification works backward. Instead of predicting future events from a chart (the normal direction), you take known past events and ask: "which birth time produces a chart that best explains all of these?"

The logic:

1. Generate candidate birth times at regular intervals (say, every 4 minutes across a 2-hour window)
2. For each candidate, compute the natal chart
3. For each candidate + each life event, compute the transit chart, progressed chart, and solar-arc chart at the event date
4. Score how well each candidate's charts correlate with the life events
5. The candidate whose chart best explains all events wins

Simple concept. Hard to implement well.

Why "just counting transits" doesn't work

The naive approach is tempting: for each candidate time, count how many transits hit natal angles at each event date. Most hits wins.

Three problems with this:

How our engine actually scores candidates

We built 18 factor evaluators organized into three technique families:

Transit evaluators (8 checks)

These fire when a transiting planet at the event date makes a significant contact with the candidate's natal chart:

• Outer planet conjunction to angle - Saturn, Uranus, Neptune, or Pluto conjunct ASC/MC/DSC/IC. The classic rectification signal. If Saturn was conjunct your MC when you got promoted, that angle position is likely correct.
• Outer planet hard aspect to angle - Squares and oppositions. Less definitive than conjunctions but still discriminating.
• Outer planet conjunction to house ruler - Saturn conjunct the ruler of the 7th house at marriage. Tests both the angle (which sets the house) and the ruler assignment.
• Outer planet in relevant house - Looser check. Pluto transiting through the 8th house during a financial crisis.
• Jupiter to angle - Benefic timing for positive events.
• Mars to angle - Acute event trigger (surgery, accidents).
• Eclipse on angle - Per Brady, the single strongest rectification signal. An eclipse hitting a natal angle within 1 degree for a Tier-1 event (death, marriage, surgery) is near-diagnostic.
• Lunar nodes on angle - North/South node conjunctions to angles at event dates.

Progression evaluators (5 checks)

Secondary progressions advance the chart ~1 day per year of life:

• Progressed ASC/MC conjunct natal planet - The progressed angle sweeping over a natal planet at the event time.
• Progressed Moon in relevant house - Moon enters the natal 7th house around the time of marriage.
• Progressed Moon aspecting natal angles - With applying-aspect boost (Hand/Brady doctrine: applying contacts trigger events, separating contacts describe aftermath).
• Progressed Sun sign change - When the progressed Sun changes signs near a major life transition.
• Progressed New/Full Moon - Lunation events in the progressed chart near life events.

Solar arc evaluators (3 checks)

Solar arc moves everything at the Sun's progressed rate (~1 degree/year):

• SA planet to natal angle - Directed Pluto conjunct natal ASC at a transformative event.
• SA angle to natal planet - The directed MC sweeping over natal Saturn at a career crisis.
• SA planet to house ruler - SA Mars conjunct the ruler of the 6th house at a health event.

All three technique families fire simultaneously for every (candidate, event) pair. The engine doesn't pick one technique. It runs all of them and aggregates.

Schmidt sect doctrine: the multiplier that matters

This is especially important because many rectification searches involve candidate times that straddle dawn or dusk. Without twilight smoothing, scores would show a discontinuous cliff right at the horizon. That's noise, not signal.

Eclipse-on-angle anchoring (the Brady doctrine)

Here's how it works in our engine:

1. For each event, we check if a solar or lunar eclipse occurred near the event date
2. If it did, we check if the eclipse position falls within 1 degree of any natal angle (ASC/MC/DSC/IC) for the candidate birth time
3. If both conditions are true AND the event is Tier-1 (death, marriage, surgery, accident, divorce, child birth), the candidate gets anchor_grade: true

Saros-family resonance

On top of eclipse anchoring, we implement Brady's Saros-family doctrine. Every native has a "prenatal lunation" (the New or Full Moon immediately before birth). If that lunation was itself an eclipse, the native carries that eclipse's Saros series number.

When an eclipse at an event date belongs to the same Saros family as the native's prenatal eclipse, the eclipse evaluator gets a 1.25x boost. This follows Brady's strict model: one Saros family per native, not two.

It fires rarely. When it does, it's significant.

The normalization problem (and our fix)

The problem: a candidate that fires only 2 weak checks can outscore a candidate that fires 5 strong checks because its denominator (sum of those 2 checks' max points) is much smaller. The strong candidate gets diluted by the checks it rightfully fired.

The theoretical max includes the upper-bound sect boost (1.20x) and applying-aspect boost (1.20x) for eligible evaluators, plus event-affinity and Saros boosts where applicable. This keeps the normalized score between 0 and 100 and makes scores comparable across candidates.

The API: one endpoint, full evidence

1POST /api/v3/rectification/search

1{
2  "subject": {
3    "name": "Anna",
4    "birth_data": {
5      "year": 1985, "month": 5, "day": 11,
6      "hour": 14, "minute": 0, "second": 0,
7      "city": "Kharkiv", "country_code": "UA"
8    }
9  },
10  "time_search": { "delta_minutes": 60, "step_minutes": 4 },
11  "events": [
12    { "date": "2018-06-15", "category": "marriage" },
13    { "date": "2015-12-03", "category": "death_family" },
14    { "date": "2020-03", "date_precision": "month", "category": "career_change" }
15  ]
16}

This searches 120 minutes (plus-minus 60 around 14:00) in 4-minute steps, testing 30 candidate times against 3 life events. Each candidate gets a full natal chart, plus transit/progressed/solar-arc charts per event.

• candidates - Ranked list with aggregate score, normalized score (0-100), grade (excellent/good/fair/caution/poor), full chart data, per-event scoring with individual checks
• density - Time + score for every candidate (for histogram rendering)
• summary - Confidence level (high/medium/low), peak time, score statistics, quality advisory, peak window (when top candidates cluster), twin window flag

• check_id (e.g., "transit.outer_conj_angle")
• description ("Tr. Saturn conjunct natal MC")
• point1, point2, aspect_type, orb, max_orb
• raw_points, adjusted_points
• applied_multipliers (orb_factor, applying, sect, event_affinity, saros_family)

Full receipts. Every score is traceable to specific astrological evidence.

18 event categories with NLP synonyms

The engine supports these life event categories, each with a default astrological weight and associated house/planet signatures:

Confidence assessment: when to trust the results

Not every rectification produces a clear answer. Our engine returns a statistical confidence assessment:

• gap_ratio - Score gap between #1 and #2, divided by #1. High gap = one candidate clearly separates.
• lift_ratio - #1 score divided by the mean score. High lift = the peak stands out from the baseline.
• level - "high" (clear winner), "medium" (likely candidate with some uncertainty), "low" (scores too close to call), "n_a" (insufficient data)

When to build vs when to use the API

If you're thinking about building rectification in-house, here's what you need:

• Swiss Ephemeris integration for planetary positions (or equivalent)
• Secondary progression engine (day-for-a-year calculation)
• Solar arc direction engine (uniform 1-degree-per-year advancement)
• Eclipse lookup and Saros series identification
• Sect doctrine implementation (not just day/night, but the full Schmidt model)
• House cusp calculation for multiple systems
• Aspect calculation with configurable orbs
• Normalization that doesn't break on edge cases
• Event category weight system with affinity pairings

We have 282 tests covering this. It took us months to get the scoring formula right, including multiple calibration cycles against published case studies. The Schmidt sect doctrine alone went through 5 iterations.

Or you can POST to one endpoint and get it all for 15 credits.

Getting started

Free tier: 50 requests per month. No credit card.

1curl -X POST https://api.astrology-api.io/api/v3/rectification/search \
2  -H "Authorization: Bearer YOUR_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "subject": {
6      "name": "Test",
7      "birth_data": {
8        "year": 1990, "month": 3, "day": 15,
9        "hour": 12, "minute": 0,
10        "city": "New York", "country_code": "US"
11      }
12    },
13    "time_search": { "delta_minutes": 30, "step_minutes": 4 },
14    "events": [
15      { "date": "2018-06-15", "category": "marriage" },
16      { "date": "2022-01-10", "category": "career_change" }
17    ]
18  }'

Response comes back with ranked candidates, per-event evidence, confidence level, and everything described above.