A Domain with Multiple Right Answers --- Benchmarking Existing Saju Apps

 

You enter the same birth date and time, and every app gives you a different chart. The Hour Pillar differs. The Month Pillar differs. Sometimes even the Day Pillar is different. Which one is actually correct? This post is about the shocking reality I uncovered while benchmarking existing apps before building my own Four Pillars (Saju) analyzer --- and the design principles I derived from that discovery.

Starting Point: Why Benchmark?

Before starting any project, surveying the existing landscape is standard practice. I did the same with Tarot Master --- tried several Tarot apps, identified strengths and weaknesses, then charted my course.

I took the same approach with Saju. I installed several popular apps from Google Play and the App Store, bookmarked multiple web-based Ten-Thousand-Year Calendar (Manselyeok) sites, and entered identical birth data across all of them.

That is where the trouble began.

Every App Gives Different Results

I entered the same person's birth date and time, and the Four Pillars themselves came out differently. At first, I assumed I had made an input error. I double-checked. I re-entered the data. Same results. App A and App B disagreed on the Hour Pillar. App C even had a different Month Pillar.

In Saju, your "chart" consists of four pillars: Year, Month, Day, and Hour. Each pillar is a pair of one Heavenly Stem and one Earthly Branch. These eight characters are the starting point for every piece of Saju analysis. And yet the starting point itself varies from app to app? This is not a mere UI difference --- it is a fundamental calculation discrepancy.

As a developer, I found this both unsettling and fascinating. Deterministic output for the same input is a basic assumption in programming. Yet in the Saju domain, that assumption appeared to break down.

Root Cause #1: True Solar Time Correction

The single biggest source of divergence was True Solar Time correction. When determining the "hour" in Saju, there is a gap between the clock time we use in daily life and the actual position of the sun.

Korea Standard Time (KST) is based on the 135th meridian east. But Seoul's actual longitude is about 127 degrees. This difference means Seoul's true solar time runs roughly 30 minutes behind standard time. Add the Equation of Time --- a daily fluctuation caused by Earth's elliptical orbit and axial tilt --- and the gap between clock time and true solar time shifts every single day.

Why does this matter? Saju divides the day into two-hour intervals: the Hour of the Rat (23:00--01:00), the Hour of the Ox (01:00--03:00), and so on. A 30-minute shift can push someone into a different Hour Pillar, changing one of the four pillars entirely.

Apps that apply True Solar Time correction versus those that do not --- this was the primary reason Hour Pillars disagreed.

Root Cause #2: Late Night Hour Handling

The second major source of discrepancy was the Late Night Hour (Yajasi, 夜子時). The Hour of the Rat spans 23:00 to 01:00, and here lies the problem: does 23:00 belong to today or tomorrow?

Yajasi refers to the window from 23:00 to midnight. For someone born during this window, how should the Day Pillar be determined? Different schools of thought disagree.

One school holds that once 23:00 arrives, the energy of the next day has already begun. Therefore, the Day Pillar should be that of the following day. The other school maintains that the date changes only at midnight. Between 23:00 and midnight, it is still today, so today's Day Pillar applies.

When the Day Pillar changes, the Day Stem --- the reference point for all Ten Gods analysis --- changes with it, reshuffling the entire interpretive framework. This is one of the core reasons why the same birth data can yield wildly different readings across apps.

Root Cause #3: Daylight Saving Time

South Korea implemented Daylight Saving Time during the 1950s and 1960s. People born during those periods have birth times recorded with DST applied. To get the true solar time for Saju calculations, you need to reverse the DST offset.

The problem is that the specifics of DST application vary from app to app. Some apps account for it; others ignore it entirely. Among those that do account for it, the exact application periods sometimes differ subtly.

At this point, the users affected by DST are limited to those born in the 1950s--60s. But if the goal is "accurate results for every user," this cannot be dismissed.

Root Cause #4: Differences Between Schools of Thought

Even when the chart itself is identical, interpretations can diverge. This is not a calculation bug --- it is a difference in academic perspective.

A prime example is Hidden Stems (Jijanggan, 地藏干) assignment. Which Heavenly Stems are concealed within each Earthly Branch? Schools disagree. Some say the Branch Ja (子) contains both Im (壬) and Gye (癸); others say only Gye. The direction of the Twelve Life Stages for Yin Stems --- forward or reverse --- also varies by school.

These differences are the root cause of varying results across apps. And crucially, they are not bugs. Saju is not a single unified system. It is a domain where multiple schools of interpretation coexist.

The Importance of KASI Data

One detail I paid particular attention to during benchmarking was whether an app used data from the Korea Astronomy and Space Science Institute (KASI). In Saju, the Month Pillar is determined not by the lunar calendar date but by Solar Terms (Jeolgi, 節氣). The new year begins at the Start of Spring, and the second month starts at the Awakening of Insects.

The precise timing of each Solar Term is determined by astronomical calculation. KASI provides this data down to the minute. Accurate Solar Term timing means an accurate Month Pillar, and an accurate Month Pillar means an accurate chart overall.

Among the apps I benchmarked, those that explicitly cited KASI data showed a clear accuracy advantage --- especially for people born on Solar Term boundary dates, such as the day of the Start of Spring. KASI-based apps use the exact time of the Start of Spring to determine the Month Pillar; others rely on approximate dates.

The Wonkwang Digital University Example

During benchmarking, I came across an interesting case: a Saju analysis app that had undergone academic verification by the Department of Oriental Studies at Wonkwang Digital University. Academic validation means that, at minimum, the calculations were verified for accuracy within that school's theoretical framework.

This example matters because it illustrates the correct approach in the Saju domain: declare which school of thought you follow, and pursue accuracy within that framework. There is no "absolutely correct" Saju chart. But there can be "a chart calculated accurately within this theoretical system."

Design Principles for a Domain with Multiple Right Answers

The benchmarking conclusion was clear. Saju is a domain where multiple right answers exist. Depending on True Solar Time correction, Late Night Hour handling, and school-specific interpretive choices, the same input can yield different outputs --- and neither side can be declared "wrong."

From this reality, I established three design principles.

First, set sensible defaults. Apply True Solar Time correction. Treat the Late Night Hour as the current day. Use KASI data for Solar Terms. Adopt the approach most commonly used in modern Saju practice as the default.

Second, build a flexible architecture. Defaults exist, but users should be able to change them via settings. Someone who wants to treat the Late Night Hour as the next day, or who prefers not to apply True Solar Time correction, must be accommodated.

Third, make the applied criteria transparent. "This result applies True Solar Time correction and treats the Late Night Hour as the current day." That kind of disclosure is necessary. Transparency builds trust.

These principles became the foundation for every design decision that followed.

How Benchmarking Changed the Design

Had I jumped straight into development without benchmarking, I would almost certainly have designed around the assumption that "there is one right answer in Saju." That would have meant a painful structural overhaul the moment I discovered school-based differences.

Identifying the domain's essential characteristics early --- thanks to benchmarking --- was a stroke of good fortune. Because the design started from the premise that "multiple answers are valid," every subsequent implementation naturally incorporated flexibility.

With Tarot, this level of benchmarking was unnecessary. Tarot has a comparatively simple structure --- 78 cards, interpretation texts, a few spread types --- and apps did not diverge much. Saju's complexity made benchmarking indispensable from the very first step.

What I Learned Along the Way

First, benchmarking is not "competitive analysis." It is "discovering the essential characteristics of the domain." The fact that existing apps disagreed on results was itself the key insight into this domain's nature.

Second, in a domain with multiple right answers, a flexible architecture can matter more than precise computation. Choose the best default, but build a structure that accommodates other choices.

Third, the quality of a Saju app is determined not by its UI or interpretation text but by the accuracy of its calendar engine and the rigor of its correction logic. The precision of the invisible engine determines the trustworthiness of the results.

Next Up

The domain is mapped. Benchmarking has yielded design principles. It is time to start building. But unlike Tarot, I did not jump straight to code this time. Instead, I wrote design documents first --- including a 35-page domain model document. Why I made that choice, and how it transformed AI collaboration entirely, continues in Part 3.