Check settings when results differ

Build a comparison that changes one thing at a time

Keep the original data fixed and preserve both outputs before experimenting. Write down the settings visible in each tool and the versions or comparison date. Then select one evidenced difference to investigate. If time, place and method are changed together, a matching result will not reveal which change mattered.

The goal is not to make two systems agree at any cost. It is to discover whether a difference comes from input meaning, conversion, a method convention, a calculated field or later interpretation. Different definitions may legitimately remain different after the investigation.

These are inspection categories, not a promise that every interface exposes the same controls. Check only what is relevant, but do not declare unchecked fields equivalent.

Confirm that the displayed text has the same meaning

Identical date numerals can be treated as different calendars. A time can be local civil time in one interface and an already adjusted value in another. A familiar place label can resolve to a different location. The strings can match while the calculation inputs do not.

Start from verified birth data, including the original notation and uncertainty. Do not quietly alter the record while testing settings. Otherwise the exercise stops being a comparison of processing conditions and becomes a comparison of new inputs.

A simple arithmetic example illustrates the issue without a birth date. A 10:00 clock reading under a verified UTC+08:00 offset corresponds to 02:00 UTC. Under UTC+09:00 it corresponds to 01:00 UTC. Both subtractions follow their premises, but the premises identify instants an hour apart. The example does not assign either offset to an unspecified city.

Using the converted 02:00 as though it were still the original local time could cause a second adjustment. Read what the field requests and what the tool already does. Do not add or subtract time merely because a different output looks more familiar.

Check the rules that are actually in use

IANA's time-zone documentation describes historical local-time rules and their updates. This is a reason to retain the applicable date, zone and data version rather than applying today's offset indiscriminately. Missing historical information should remain an identified gap.

For a technical astrology example, Swiss Ephemeris house calculations explicitly take time, geographic coordinates and a house-system choice. Extended interfaces also distinguish calculation flags. Those parameters show why settings belong to the calculation; they do not show which personal interpretation is more accurate.

Other relevant categories may include a Bazi day-boundary convention, solar-time handling, zodiac choice or a Ziwei placement convention. The list is not an assertion that every tool implements each option. If a necessary setting is undocumented, mark it unknown instead of inventing a default on the tool's behalf.

Open the full-size diagram

Original BaZiFlow settings diagram. The paths locate differences and do not rank particular tools.

The final split matters: a field comparison and a wording comparison are different tests. Their results should be recorded separately.

Preserve the difference between a new draw and a new explanation

In a method with an extraction or drawing step, repeating the same question can produce a different input. A fresh tarot draw is not a rerun of the same recorded spread. To compare interpretations, retain the actual cards, positions and upright or reversed handling under discussion.

Similarly, two methods can intentionally define their frames differently. Keep both conventions visible rather than tuning settings until the diagrams look alike. If a tool claims the same data and convention but produces different fields, then examine its data or implementation version. Calling a discrepancy a “school difference” should not conceal a demonstrable processing error.

After aligning a condition, record which fields changed and which did not. A small, reasoned comparison is more informative than a large collection of screenshots without fixed premises. There is no need to rerun unrelated fields merely to make the record look extensive.

Stop changing the input when the fields already match

If the underlying numbers and symbols agree but the prose differs, examine the interpretive selection, weighting and wording. Further edits to birth data are unlikely to explain that particular discrepancy. Locating conflicting conclusions addresses the next layer.

State the result narrowly: the inspected fields match under these settings, or this remaining difference follows from these conventions. Neither sentence establishes that all fields match or that a forecast has been validated. Unchecked auxiliary fields and time layers remain unchecked.

When an actual error is corrected, retain the previous value, the reason and the affected explanations. A reusable comparison needs only clear fixed conditions, a named change and an observed result. Those details make the next investigation easier after a software update or a move to another device.

1. 1

   Keep the original pair

   Both clocks show 10:00: A uses +08 and produces 02, while B uses +09 and produces 01.

2. 2

   Change only B’s offset

   Suppose documentation establishes +08 for B. Keep its clock and place fixed; its UTC result becomes 02.

3. 3

   Limit the finding

   This locates the UTC discrepancy only. House method, other fields and explanatory language remain separate checks.