-
-
Notifications
You must be signed in to change notification settings - Fork 2
VALIDATION_ASTROLOGY
Version: 1.1 Date: 2026-03-23 Runtime target: Python 3.14 Validation philosophy: external astrology software where stable and meaningful; canonical formulas and doctrine tables where no stable oracle exists; Moira as regression baseline once behavior is validated
This document covers the astrological convention layer of Moira: techniques that are built on top of the astronomy engine but involve definitional choices specific to astrological tradition.
The validation standard here differs from the astronomy layer:
- Swiss Ephemeris / Astro.com
swetestis used as a sanity oracle where a stable external chart-software reference actually exists. - Some astrological techniques do not have one universally authoritative external oracle. Those are validated by canonical formulas, structural invariants, doctrine documentation, and deterministic test surfaces instead of pretending a nonexistent oracle exists.
- Where Moira diverges from Swiss or other software, the cause is audited: model difference (expected) vs. implementation bug (must be fixed).
- Once a technique is confirmed correct, Moira's own output is locked in as the regression baseline.
- Thresholds are technique-appropriate: pure geometry can hold to microdegree scales, while predictive or doctrine-driven techniques are validated at the level their own assumptions make meaningful.
| Domain | Oracle / basis | Enforcement | Status |
|---|---|---|---|
| Sidereal systems / ayanamshas (30 systems) | Astro.com swetest offline fixture |
pytest |
Validated |
| House systems (15 systems, 3168 iterations) | Swiss setest/t.exp offline fixture |
pytest + validator script |
Validated |
| Aspects (major, tight-orb) | Horizons-validated position substrate + angular-distance geometry | pytest |
Validated |
| Antiscia / contra-antiscia | Formula derivation + invariants (Valens, Lilly) | pytest |
Validated |
| Midpoints | Formula derivation + invariants (Ebertin, Witte) | pytest |
Validated |
| Lots / Arabic Parts | Formula derivation, day/night reversal (Paulus, Valens) | pytest |
Validated |
| Dignities | Essential table lookups, accidental scoring (Lilly, Ptolemy) | pytest |
Validated |
| Harmonics | Formula derivation + round-trip invariant (Addey) | pytest |
Validated |
| Profections | Annual/monthly arithmetic, 12-year cycle (Brennan, Valens) | pytest |
Validated |
| Planetary hours | Chaldean sequence + day-ruler derivation (Porphyry, Hephaestio) | pytest |
Validated |
| Secondary progressions | Offline Swiss swetest fixture at progressed dates + doctrine validation |
pytest |
Validated |
| Solar arc directions | Offline Swiss swetest fixture for arc and directed longitudes + doctrine validation |
pytest |
Validated |
| Primary directions | Placidus speculum doctrine, arc algebra, and symbolic time-key validation | pytest |
Validated |
| Dashas | Canonical Vimshottari doctrine: nakshatra entry, proportional hierarchy, ayanamsa/year-basis settings | pytest |
Validated |
| Parans | Horizons-derived offline paran fixture + validated event substrate + paran logic tests | pytest |
Validated |
| Gauquelin sectors | Canonical diurnal-arc formula + plus-zone invariants (Gauquelin) | pytest |
Validated |
| Manazil / lunar mansions | Equal-station arithmetic + canonical boundary assignments (al-Biruni) | pytest |
Validated |
| Timelords (Firdaria / Zodiacal Releasing) | Canonical tables, structural invariants, and doctrine validation | pytest |
Validated |
Status language in this table is intentional:
-
Validatedmeans there is a finished validation story appropriate to the technique as currently implemented. -
Internally validatedmeans the subsystem has substantial doctrinal, structural, and invariant coverage but the project is still intentionally reserving a stronger validation label for a later external comparison. -
Needs external oraclemeans the technique still lacks the external comparison needed to close that part of the validation story.
Oracle: Official Astro.com swetest CGI output, captured offline
Fixture: tests/fixtures/sidereal_swetest_reference.json
Threshold: 0.001 degrees (3.6 arcseconds)
Test file: tests/integration/test_sidereal_external_reference.py
30 ayanamsha systems are exposed. 29 have direct Swiss-mappable validation.
1 (Galactic Center 5 Sag) is validated by invariant: Galactic Center 0 Sag
- 5 degrees.
Validated systems include Lahiri, Fagan-Bradley, Krishnamurti, Raman, Yukteshwar, Djwhal Khul, Hipparchos, Suryasiddhanta, Aryabhata, SS Revati, SS Citra, True Chitrapaksha, True Revati, True Pushya, Aldebaran (15 Tau), Babylonian variants, Galactic Center (0 Sag), Galactic Center (Cochrane), Galactic Center (RGB), and others.
Fixture coverage is 2 epochs x 29 systems x 2 modes (mean/true) plus invariant and coverage guards.
Oracle: Official Swiss Ephemeris setest/t.exp
Fixture: tests/fixtures/swe_t.exp
Threshold: 0.001 degrees (3.6 arcseconds)
Test files:
tests/integration/test_houses_external_reference.pytests/unit/test_polar_houses.pyscripts/compare_swetest.py --offline
15 house systems are validated: Placidus, Koch, Campanus, Regiomontanus, Porphyry, Equal, Whole Sign, Alcabitius, Morinus, Topocentric, Vehlow, Meridian, Azimuthal, Krusinski-Pisa, APC.
Stress cases covered:
- equatorial latitudes
- polar edge and polar fallback behavior
- deep southern latitudes
- multiple east/west longitudes
Two systems (Azimuthal, APC) were found genuinely wrong during validation and fixed. The offline Swiss comparison now passes across the curated matrix.
Validation layers:
-
Layer A - position substrate: ecliptic longitudes are produced by
Moira's
planet_at()pipeline, which is externally validated against JPL Horizons. Storing those positions in the fixture anchors aspect geometry to a validated astronomical substrate. - Layer C - angular-distance arithmetic: for every body pair the fixture records the expected angular separation. The tests recompute those separations from scratch and verify they match the stored values to within a pure-geometry threshold.
Fixture: tests/fixtures/aspects_reference.json
Generated by: scripts/build_aspects_fixture.py
Threshold: 1e-6 degrees
Test file: tests/integration/test_aspects_external_reference.py
Aspect tier: major aspects only
Tight-orb window: 1.0 degree
Epochs: J1900, J1950, J2000, J2024
Bodies: 10 major bodies (Sun through Pluto)
Minor aspects remain covered by the larger unit suite in
tests/unit/test_aspects.py.
Primary test file: tests/unit/test_rule_engine_validation.py
The following modules are pure arithmetic / rule-table engines with no ephemeris dependency. Their validation is therefore formula-derivation and invariant-based rather than external-oracle comparison.
Canon: Vettius Valens, Anthology II.37; William Lilly, Christian
Astrology (1647) p. 90
Formula: antiscion = (180 - lon) mod 360; contra = (360 - lon) mod 360
Validation: hand-derived reference table, round-trip invariants, contact
detection, and seam-edge cases
Canon: Reinhold Ebertin, The Combination of Stellar Influences (1940);
Alfred Witte, Rules for Planetary Pictures
Formula: shorter-arc midpoint; 90-degree dial projection
Validation: hand-derived midpoint table, commutativity, self-midpoint,
pair-count, sort-order, and seam-crossing invariants
Canon: Chris Brennan, Hellenistic Astrology (2017), Ch. 9; Vettius
Valens, Anthology, Book IV
Formula: profected ASC = (natal_asc + age * 30) mod 360; house =
(age mod 12) + 1
Validation: hand-derived table across ages 0-30, house-range guard,
monthly-lord length and first-lord invariants, and 12-year cycle identity
Canon: Porphyry, Introduction to Tetrabiblos; Hephaestio of Thebes,
Apotelesmatika I
Validation: Chaldean sequence, weekday day-ruler mapping, first night-hour
derivation, 24-hour completeness, and the next-day +3 shift invariant
Canon: John Addey, Harmonics in Astrology (1976)
Formula: harmonic longitude = (natal_lon * H) mod 360
Validation: hand-derived table, H1 identity, output-range invariant,
sorting, and harmonic-number clamping
Canon: Paulus Alexandrinus, Introductory Matters; Vettius Valens,
Anthology Books II-IV
Formula: ASC + Add - Sub modulo 360, with night reversal where doctrine
requires it
Validation: Fortune and Spirit day/night formulas, range guards, and the
Fortune/Spirit complement invariant
Canon: William Lilly, Christian Astrology Book I; Ptolemy,
Tetrabiblos I.17-22
Validation: essential dignity cases, accidental scoring bands, retrograde
penalties, cazimi / combust boundaries, mutual reception, total-score
invariant, traditional sort order, sect-light logic, and hayz conditions
The techniques below are not correctly described as "untested." They already have real validation surfaces. The distinction is whether that surface is a finished external-oracle comparison or a strong internal / doctrinal pass.
Current validation surface: tests/unit/test_progressions.py,
tests/integration/test_progressions_external_reference.py
Backend standard: moira/docs/PROGRESSIONS_BACKEND_STANDARD.md
What is already validated:
- secondary progression time-key mapping (1 day = 1 year)
- solar arc as progressed Sun minus natal Sun
- Naibod longitude and right-ascension variants
- converse forms of supported progression techniques
- tertiary, tertiary II, and minor progression mapping rules
- ascendant-arc and daily-house-frame doctrine
- doctrine/classification/relation/condition-profile invariants
- policy override behavior and deterministic failure modes
- Swiss
swetestlongitudes for secondary progressions at curated progressed dates - Swiss-derived solar-arc values and directed longitudes from the same curated cases
What is not yet externally validated:
- progressed Ascendant / MC against an external chart oracle
- published historical examples as software-to-software spot checks
Fixture: tests/fixtures/progressions_swetest_reference.json
Builder: scripts/build_progressions_swetest_fixture.py
Threshold: 1.0 arcsecond
Status: externally validated for planetary positions and solar-arc values against offline Swiss references; angle-specific extensions remain desirable.
Current validation surface: tests/unit/test_dasha.py
Backend standard: moira/docs/DASHA_BACKEND_STANDARD.md
What is already validated:
- Vimshottari year-basis doctrine and policy handling
- birth nakshatra capture and nakshatra-fraction preservation
- Mahadasha through Prana hierarchy generation
- active-line, condition-profile, sequence-profile, and lord-pair layers
- structural invariants, containment checks, and malformed-input rejection
- fixed lord sequence and canonical year allocations
- antardasha and deeper-level proportional duration doctrine
- ayanamsa-sensitive nakshatra entry through the declared policy surface
Research conclusion:
- there is no stable Swiss-like oracle for Vimshottari that can be treated as final authority across software without first fixing doctrine settings
- public and commercial software vary on at least ayanamsa and year basis
- therefore the authoritative validation target for Vimshottari is doctrine, not software mimicry
Oracle harness now present:
- manual fixture template:
tests/fixtures/vimshottari_reference.manual.json - normalizer:
scripts/build_vimshottari_manual_fixture.py - offline integration suite:
tests/integration/test_vimshottari_external_reference.py
Reference doctrine adopted for Moira validation:
- ayanamsa:
Lahiri - year basis:
julian_365.25by default, with alternate basis handling tested explicitly
Status: validated against doctrine and invariants. External Vedic software comparison is optional supplemental cross-checking, not a prerequisite for claiming a truthful validation story.
Current validation surface: tests/unit/test_primary_directions.py
What is now validated:
- Placidus mundane speculum construction on analytically simple equatorial cases
- semi-arc and mundane-fraction behavior across upper and lower hemisphere cases
- direct and converse arc algebra for simple speculum pairs
- symbolic time-key conversion for Ptolemy, Naibod, and solar keys
- arc filtering, ordering, self-direction exclusion, and solar-rate handling
Status:
- validated by doctrine, explicit speculum math, and invariant-based unit tests
- external software comparison remains useful as supplemental cross-checking, but the subsystem is no longer undocumented or validation-empty
Current validation surface: tests/unit/test_parans.py,
tests/integration/test_parans_external_reference.py
Backend standard: moira/docs/PARANS_BACKEND_STANDARD.md
What is already validated:
- crossing extraction delegates consistently to the validated rise/set/transit engine
- paran matching, classification, policy filters, strength, and stability layers
- field sampling, contour extraction, contour consolidation, and structure analysis
- deterministic failure behavior and invariant preservation
- offline Horizons-derived expected paran matches for curated multi-body cases
- a high-latitude no-paran case derived from the same external event oracle
Fixture: tests/fixtures/parans_horizons_reference.json
Builder: scripts/build_parans_horizons_fixture.py
Status: validated against an external event oracle for curated paran cases, plus the existing internal coverage for matching, policy, and field behavior.
Current validation surface: tests/unit/test_experimental_validation.py
Validated against the canonical diurnal-arc sector model:
- sector always falls in 1-36
- plus zones are exactly sectors 1-3, 10-12, 19-21, 28-30
- zone labels match plus-zone membership
- circumpolar and horizon-edge inputs stay structurally valid
This technique is already validated and should not be described as merely "mentioned."
Current validation surface: tests/unit/test_experimental_validation.py
Validated as canonical equal-station arithmetic:
MANSION_SPAN = 360 / 28- all 28 mansions are reachable
- boundary advancement and wraparound are correct
-
degrees_instays in range for all tested longitudes
This is a real validation pass for the current doctrine. A future comparison to published mansion tables would be supplemental, not the first validation.
Current validation surface: tests/unit/test_timelords.py and
moira/docs/VALIDATION_EXPERIMENTAL.md
What is already validated:
- diurnal / nocturnal Firdaria tables and Bonatti variant behavior
- node handling, sub-period structure, and sequence totals
- Zodiacal Releasing minor-year table integrity and level scaling
- current-period helpers, grouping helpers, active-pair helpers, condition profiles, sequence profiles, and validation guards
Status: validated against doctrine and invariants. External software comparison may still be useful as supplemental cross-checking.
Recommended oracle: Astro.com chart output or Solar Fire
Threshold: 0.001 degrees
Useful next checks:
- minor-aspect software comparison
- applying vs separating determination
- partile detection
- out-of-sign aspect behavior
- orb-calculation consistency across chart software
The current Placidus mundane implementation is now doctrine-validated.
Useful supplemental expansion:
- software-to-software spot checks against one declared model only
- converse examples from published traditional sources
- angle-specific historical examples
- explicit variant separation if Regiomontanus or topocentric directions are added
External oracle coverage is already in place via the offline Swiss swetest
fixture in tests/fixtures/progressions_swetest_reference.json.
Useful supplemental expansion:
- progressed Ascendant and MC
- progressed lunation cycle
- known historical examples
External oracle coverage is already in place for solar-arc values and directed
planetary longitudes via the offline Swiss swetest fixture.
Useful supplemental expansion:
- converse solar arcs
- directed angles
- known historical examples
External-software comparison for Vimshottari is now treated as supplemental, not foundational.
If performed, it must declare at minimum:
- ayanamsa
- year basis
- hierarchy depth being compared
Useful supplemental checks:
- Mahadasha / Antardasha dates for a few known charts in JHora or Parashara's Light
- birth nakshatra agreement under explicit Lahiri settings
Implementation note:
- the repo contains a manual-oracle harness for optional software-to-software comparison, but doctrine validation is the primary standard
The subsystem is now externally anchored through Horizons-derived event timing for curated paran cases.
Useful supplemental expansion:
- dedicated paran-software spot checks where the software's paran doctrine is declared
- named-star focused examples beyond the current planet-heavy external corpus
- more latitude-sensitive mixed-event cases
Recommended oracle: published lunar-mansion tables (Ibn Arabi, Picatrix, al-Biruni variants as implemented)
What to validate:
- mansion boundary calculation against published tables
- Moon mansion assignment for known dates
- name-map consistency across Arabic / Sanskrit naming layers if both are exposed