GetBirthChart

Technical validation

Calculation Validation

GetBirthChart validates deterministic calculation behavior. It does not claim that astrology itself has been scientifically validated.

Editorial standards overseen by Luis PhamMethodology

What is being validated

The validation target is the software behavior that turns supported birth inputs into structured chart output: time normalization, coordinates, planetary positions, houses, angles, aspects, relationship geometry and schema stability.

A passing calculation test means that the implementation produced the expected deterministic output or explicit error for a defined case. It is not evidence that an astrological interpretation or prediction is scientifically true.

Test strategy

The engine repository contains unit, integration, regression, boundary and differential test tracks. The public golden-test document identifies the small release-facing set copied from trusted fixtures; the complete repository test suite contains additional implementation coverage.

  • Golden fixtures for known-time natal and relationship results.
  • Contract tests for unknown-time omission and explicit warnings.
  • Boundary tests for dates, timezones, zodiac wrapping, house cusps and aspect orbs.
  • Differential geometry/parity tests where an independent reference track is available.
  • Schema and API tests for stable structured output and error envelopes.

Public golden and regression cases

The public golden-test documentation (opens in a new tab) lists known-time natal values, relationship output, timezone normalization, unknown-time behavior and hostile boundary coverage. The repository describes those fixtures as copied from existing trusted tests rather than invented for marketing copy.

  • Known-time Hanoi natal chart: Sun, Moon, Chiron, Ascendant, Midheaven, first house cusp, Big Three labels and major-aspect count.
  • Relationship regression: composite positions, derived angles, overlays and aspect counts.
  • DST gaps and overlaps, historical timezone rules, date-line cases and leap days.
  • Zodiac wrapping, house cusps, high-latitude house limits and retrograde stations.

Numerical precision and tolerances

Tolerances are track-specific rather than one universal accuracy number. The public house-reference methodology reports a measured agreement of about 1.9e-06 degrees and sets that geometry gate at 1e-05 degrees. That value applies to the documented geometry track; it should not be quoted as a tolerance for every engine field.

Other golden cases pin expected values or structural behavior according to the test that owns them. A change to a frozen value requires a deliberate engine or methodology change, not a silent fixture refresh.

Reproducibility

The reproducibility identity is gbc-astro package 1.12.2, calculation engine 1.12.1, natal schema 1.3.0, the declared calculation profile and the configured Swiss Ephemeris data. The package source is public on GitHub (opens in a new tab) and the release is archived on Zenodo (opens in a new tab).

A developer can install the package, provision the required `.se1` files, set `GBC_SWISS_EPHE_PATH`, and run the public golden-test command in the repository documentation. The web app also vendors the API contract for the pinned engine release.

Known limitations

Unknown birth time removes Ascendant, Midheaven, house cusps and house assignments. The engine computes bodies at local-date start as an explicit approximation and warns about the uncertainty; the web product checks Moon sign movement across the local date before presenting it as stable.

Place search and geocoding are website concerns; the calculation package accepts coordinates and an IANA timezone. Historical results depend on the timezone data available to the runtime. Swiss Ephemeris files are provisioned separately and are not bundled in the PyPI distribution.