v8.0.0
2026-10-21LatestStep tools, a sharper sky, and one moment of judgement
63 new step tools and 12 renamed panels, 312 in total. The Moon and planets now sit within a fraction of an arcsecond of JPL, horary tools take one moment of judgement, and event timing reads the promise the way analyze_natal_promise does.
- For usersFor developers
- The Moon is computed from ELP/MPP02: 0.154 arcseconds from JPL DE441, down from 5.71. The planets are computed from VSOP2013 with the reduction Horizons applies: 0.09 arcseconds, down from 0.40.
- Lahiri is built from its published definition and nutation is no longer counted twice. Sidereal time reads UT1, Delta T follows JPL, and sunrise, lunations, ingresses and stations are checked against JPL Horizons, Skyfield and USNO.
- Most positions move by less than an arcsecond. A planet or cusp sitting on a sub or sub-sub boundary can change its lord, and with it a verdict.
- For usersFor developers
- Tools that returned several separate calculations in one response are split along their method seams. Each step is its own tool returning one whole calculation, and the parent names its steps in methodSeams and still returns every block, unchanged.
- Twelve tools that run steps are renamed as panels. Each old name works for this release, returns the same result and says which name to use. The release after this one removes them.
- Long lists are paged and never cut short. A tool that has more rows than one response holds says how many pages remain.
ToolsRenamed, old name kept for one releaseget_csl_advanced is now get_csl_panelget_retrograde_advanced is now get_retrograde_panelget_dasha_advanced is now get_dasha_timing_panelget_transit_advanced is now get_transit_timing_panelget_rp_advanced is now get_ruling_planets_panelget_horary_advanced is now get_horary_validation_panelget_compatibility_advanced is now get_compatibility_panelget_marriage_advanced is now get_second_marriageget_career_advanced is now get_job_change_vs_promotionget_muhurta_advanced is now find_auspicious_triangulationget_rectification_advanced is now rectify_by_event_ruling_planetsget_yogas_advanced is now detect_raja_and_lunar_yogas - For usersFor developers
- Birth offsets are worked out for the birth date, not today, and every chart tool takes time_zone so the server reads the offset in force on that date from the tz database.
- Four tools now carry the system they compute: get_hora_today is KP, get_bhrigu_bindu is a Lumin extension, get_mantra_recommendation is Parashari, and run_pre_verdict_audit is cross-system.
- The reading protocol states the rules the engine applies.
- Oversized input is refused with a clear message, and every loop a caller can steer is bounded.
- For usersFor developers
- A horary question is judged at a moment and a place, and those used to travel in fields called the birth time and the birth place. 17 tools now take them as judgement_datetime, judgement_latitude, judgement_longitude, and judgement_utc_offset_minutes or judgement_time_zone: get_horary_chart_v2, get_lost_or_missing, the four lost-article tools, get_arrival_timing, get_horary_number_methods, get_horary_ruling_planets_variants, get_horary_validation_panel, get_horary_advanced, get_horary_number_intuition, get_horary_natal_crosscheck, get_career_horary, get_medical_horary, get_rp_timing and get_horary_serial (on each of its sessions).
- Tools that read no birth no longer ask for one: the birth fields are optional on the horary tools that cast at the moment of judgement, and the call is refused with a message naming what is missing if neither set is sent.
- Every result carries horaryMoment: the instant, the local clock with its offset, the place, where each part came from (source, datetimeDefaultedToNow, placeDefaultedToBirth), and utcOffsetSource, which says given, time-zone, birth-offset or local-mean-time-from-longitude. An offset is never local mean time without saying so.
- get_ruling_planets_at_judgement, get_fruitful_significators, get_four_step_fruitful_ranking, get_transit_timing_hierarchy and find_event_timing_v2 take judgement_time_zone, so the offset in force on that date is read from the tz database, daylight saving included.
- get_event_dasha, get_promotion_verdict and get_yoga_karaka take query_date.
- For usersFor developers
- set_birth_profile returns judgementInstant { utc, local, utcOffsetMinutes, utcOffsetSource, timeZone, place, send, note }: the instant the call was made, as UTC and as the clock at the chart's place with its offset. The plan tells the model to pass it as judgement_datetime with judgement_utc_offset_minutes on every timing and horary call, so the fruitful set cannot change between two calls of one reading. You can still name another moment.
- It also returns structuredContent { plan, tier, floor, target, tools, waves, judgementInstant } with an outputSchema, so a client reads the waves as data. The text block is unchanged. plan carries the whole plan text, because a client that reads structuredContent shows the model only that.
- The judgement block of the five timing tools gains holdsUntil: the next instant any of the five ruling planets changes (the Ascendant's or the Moon's sign lord or star lord, or the day lord at the next sunrise at the place), solved and never a score. It names the member with its old and new lord, the ranked set after, and each member's own next change. It is the same ruling planet rule read forward in time. local carries the offset in force then only when judgement_time_zone is sent; otherwise it carries the judgement's own offset and utcOffsetSource says which.
- The routed plan no longer sends a tool that cannot run on the question. get_career_horary is planned once the horary topic matched, a two-chart tool only on a two-person question, a horary question lists its chart and every tool that reads its number before the natal spine, and the list follows the taxonomy's prerequisites so it agrees with the dispatch waves. No tool left the catalogue.
- For usersFor developers
- A query_date sent without a zone is read as UTC, whatever the server's own zone, and the result echoes queryDateUsed { instant, input, read }. Before, it was read in the server's zone. Send it with its zone (Z or +05:30).
- A wall clock that a daylight saving change skipped (New York, 2026-03-08 02:30) is read with the offset before the change and labelled wallClockSkipped, with a note. One that happened twice (2026-11-01 01:30) keeps the earlier reading and is labelled wallClockRepeated. Neither is refused. A typed offset beside the zone in a skipped hour may name either reading.
- The recordings the engine tests replay, and the golden payload capture, no longer read the wall clock, so a recording does not go red on the day a running period changes.
- For usersFor developers
- find_event_timing_v2 now judges the promise with the same gate as analyze_natal_promise, so the two tools no longer disagree on a chart. isPromised is true only for ACTIVE and PARTIALLY_ACTIVE; a MIXED_ACTIVE promise is undecided, not promised. The old meaning, that the required link is present, is kept as promiseDetails.requiredLinkPresent. Each result adds verdictFrom, promiseState, mixedResult, denialHousesSignified and gateNote. A custom house_group led by a house outside 1 to 12 is refused.
- The ruling-planet confirmations read the real promise of each row: every row carries promise_state, and only promised rows count toward a confirmation. The ruling-planets panel, the strength hierarchy and the dasha sync read the ruling planets at the moment of judgement, with the birth set beside them as atBirth.
- get_event_dasha keeps every period. The cut that hid periods below 34 percent coverage is gone; a long list is paged and nothing is dropped. The mahadasha lords that signify no required house are named in unlistedMahadashas.
- get_smart_current_dasha reads the nodes as KP does (isRetrogradeKP, beside astronomicalRetrograde) and takes query_date. get_career_blockage_diagnosis reads "connected to 1 and 10 only" as Astro Secrets p.198 prints it, adds connectedTo1 and connectedTo10, and takes query_date.
- For usersFor developers
- When a question needs something only you can give, the plan says so first. A horary question with no number, or a compatibility question with one chart, gets an ASK FIRST line before the tool list, and a two-chart tool is never planned until both charts are given.
- The transit tools read the running dasha at the transit moment, not at the time of the call. A query_datetime without a zone is UTC, the result echoes queryDateUsed, and a query_datetime that is not ISO 8601 is refused with a message instead of being guessed at.
- In a repeated hour (New York, 2026-11-01 01:30) a typed offset beside the time zone now selects either reading, and the result is labelled wallClockRepeated, on the birth and the judgement paths alike.