BaZi Calculation Methodology: Rules, Versions & Reproducible Evidence

1. Resolve the recorded birth time

Start with the original calendar, birth date, local clock time and birthplace. Lunar inputs preserve the leap-month choice during conversion. The month pillar follows a solar-term boundary; it is not the numbered lunar month. The ordinary calculator requires a birth time. When that time is unknown, use birth-time calibration to compare candidates rather than treating an invented hour as a fact.

New app calculations use pinned IANA 2026d time data: 344 canonical zones and 253 aliases. An alias is another name for a zone, not another country. The receipt records the applied UTC offset, standard offset and daylight-saving adjustment. A skipped civil time is rejected; a repeated time keeps its possible instants unresolved until the ambiguity is handled. Pre-1970 records can be incomplete: reproducibility against IANA is not a guarantee of every historical local practice.

2. Apply the selected True Solar Time convention

True Solar Time is enabled by default. After civil-time resolution, the calculation applies longitude correction and the equation of time. Longitude contributes four minutes per degree relative to the applicable standard meridian. OpenFate uses the Meeus equation-of-time method and records both components. Turning the convention off intentionally produces a civil-time chart.

A correction can cross an hour or day boundary. The receipt therefore retains the recorded time and calculation time separately. Fractional offsets, historical seconds, negative daylight saving and large longitude differences are handled as time data, not rounded to the nearest whole-hour zone.

3. Derive the Four Pillars under explicit boundaries

The default day boundary is 23:00; midnight rollover is also supported. The selected convention is saved with the calculation. Late-Zi hour-stem handling is checked separately from the day pillar, so changing a day-boundary label alone is insufficient.

The year boundary is Li Chun and month boundaries are the twelve Jie solar terms. The app compares the resolved birth instant against the term instant. Calendar calculations use a pinned lunar-javascript dependency. Computed term timestamps and second-level formatting describe the implementation; an independent astronomical accuracy claim would require a separate reference comparison.

Hidden stems, Ten Gods, Na Yin and branch relationships are derived after the pillars. A detected combination is a relationship first; it does not automatically establish elemental transformation. Ten Gods are computed from the actual stem and Day Master, avoiding dependence on the ordering of two hidden-stem lists.

4. Calculate Luck Pillar direction and onset

Direction follows the declared gender and year-stem polarity convention. The app selects the relevant Jie boundary, measures the interval and applies its versioned three-days-per-year conversion. New app charts use DAYUN_SECOND_V2 and keep the onset timestamp and calculation basis, rather than only a rounded starting age.

The downloadable examples use the app-patched 1.1.1 calendar layer and its original Luck Pillar contract, not the app’s DAYUN_SECOND_V2. Saved reports retain their original timing version; opening a report does not silently apply a newer onset algorithm.

5. Identify patterns and use Shen Sha in context

The app documents 12 month-command frames and 19 formation paths. A frame, a formed path and a disrupted path answer different questions. Recognizing a frame does not prove formation; an unmet condition does not by itself prove disruption. Special structures have their own checks. These categories are not directly equivalent to another service’s count of named patterns.

The Shen Sha registry contains 44 labels across natal and annual scopes. All have a named source or policy disposition; 1 disputed rule, De Xiu, remains withheld. The public record distinguishes classical alignment, modern conventions, documented variants and internal policy. A source-policy decision is not a claim that every school agrees.

The app evaluates the Day Master, season, roots, Ten Gods and interactions before using Shen Sha as supporting symbolism. Repeated Shen Sha occurrences do not automatically multiply their weight. Classical references and terminology are explained in the linked Wiki; numerical strength models and arbitration policies are OpenFate’s implementation choices, not quoted universal constants.

Strength is not a simple count of the eight characters: season, roots, hidden stems and structural relationships inform the model. Useful-god selection distinguishes balancing, climate adjustment and structural requirements; conflicts or borderline cases retain conditional alternatives rather than declaring every nominated element equally favorable. Annual themes are read within the Luck Pillar context. These are declared interpretive policies, not measured probabilities of life events.

6. Explain a saved chart without changing its facts

AI receives the completed chart and structured evidence for the report and Orb follow-ups. It explains relationships between chart factors; the deterministic chart remains authoritative if prose conflicts with it. Software checks inspect report structure and evidence consistency, while the quality of a reading still needs separate evaluation.

Saved reports render their original evidence and version receipts. A new calculation can use updated rules without rewriting an older report. This preserves what was calculated and explained at the time. Calculation reproducibility, rule conformance and useful interpretation are separate qualities; none alone establishes predictive accuracy.

What has actually been checked?

These are separate evidence sets. The pinned public source passed 157 tests. Its 8-case replay has 8 full matches and 0 known receipt differences. The app’s 150-zone benchmark is an internal comparison against independently generated IANA/TZif references; its full fixtures remain private. Hashes identify retained artifacts, not independent certification. These counts are not added together as charts tested.

App dependency (patched)

1.1.1

Public synthetic calendar cases

8

Time zones in the app benchmark

150

Fixed UTC offset comparisons

30,600

Checks around transition instants

22,953

Nonexistent local times checked

3,869

Repeated local times checked

3,782

Ten-God stem relations checked

100

Hidden-stem assertions checked

910

Registered Shen Sha labels

44

Withheld Shen Sha rules

1

Download the version and evidence manifest · Browse the evidence version index

Inspect real outputs from the public example set

Synthetic inputs with expected outputs verified against app-patched package 1.1.1. Pillars appear in year, month, day, hour order. The JSON contains settings and complete expected output. The separate manifest supplements its incomplete package provenance without changing the frozen file. These are not customer records or expert-adjudicated predictions.

Reproduce the public calculation

In a temporary directory with Node.js and Git installed, check out the exact published engine revision, install its locked dependencies without lifecycle scripts, and run its public test suite. The manifest also links the downloadable 8-case dataset. This replays the public calendar engine, not the private app’s complete interpretation engine.

Observed result: public source revision 694adfe passed 157 tests, and 8 of 8 examples match in full. The Shanghai historical-DST case now matches the frozen pillars, calendar, True Solar Time, Luck Pillars and metadata.dstOffset receipt. This is a scoped, reproducible result for the published fields—not proof of whole-engine or predictive accuracy. Public npm package 1.1.3 contains the fix; the app dependency remains separately versioned.

Download the replay script

git clone https://github.com/openfate-ai/bazi-engine.git
cd bazi-engine
git checkout 694adfe64b5f17602c3f4e7359ae97d7232a6426
npm ci --ignore-scripts
npm test
curl -fSLo bazi-validation-v1.json https://openfate.ai/bazi-validation-v1.json
curl -fSLo bazi-public-replay-v1.mjs https://openfate.ai/bazi-public-replay-v1.mjs.txt
node --import tsx bazi-public-replay-v1.mjs . bazi-validation-v1.json

Corrections, versions and review policy

Issue #1’s hidden-stem mismatch is corrected in public source 694adfe and the app’s patch to dependency 1.1.1. The app-patched installation passed 100 stem-relation checks and 910 hidden-stem assertions. Unmodified npm 1.1.1 retains the old mapping; public npm 1.1.3 contains the correction. The source fix, app patch and npm release remain separately identified.

New app calculations use IANA 2026d. Historical 2026c receipts and reference files remain preserved for old reports. The public true-solar-time package has its own release history; its version and test totals must not be substituted for the app’s pinned resolver.

To report a discrepancy, include the calculation version, calendar, timezone, longitude and settings with the differing output. Send personal birth data privately through support. Confirmed corrections receive a versioned regression case. This page’s review date changes only after evidence is checked.

GitHub #1 · 694adfe

We publish conventions, selected synthetic examples, aggregate results and artifact hashes. Private prompts, complete rule tables, weights and full review corpora remain protected. Confidential reviewer identities can stay private; independent endorsement is stated only when a completed review supports it.

Sources and further reading

• Public calendar engine and tests
• 8 reproducible calendar examples
• Shen Sha verification summary
• IANA historical-time source
• Pattern definitions and source notes
• Shen Sha knowledge library
• Report a calculation discrepancy