After Tarot, Saju --- "This Is a Whole Different Level of Complexity"

 

"Do you have the data needed for Saju? I want to build a Four Pillars program."

That was the very first message I sent to Claude, right after wrapping up my Tarot Master project. Twenty blog posts' worth of lessons learned, and I had come away with real confidence in AI-assisted development as a workflow. Naturally, I started hunting for my next challenge. But the moment I kicked off this new project, one thing became crystal clear: Four Pillars of Destiny (Saju, 四柱) is on an entirely different plane of complexity compared to Tarot.

Why Saju?

After shipping Tarot Master, I wanted to tackle something more ambitious in a similar domain --- analytical tools rooted in Eastern philosophy. As I brainstormed candidates, Saju rose to the top almost immediately.

It was a topic I found genuinely fascinating on a personal level. The idea that you could analyze someone's disposition and life trajectory from nothing more than their birth date and time --- a classification system refined over thousands of years in East Asian tradition. Could that ancient framework be faithfully translated into modern code? That curiosity was the spark.

My positive experience with AI collaboration on the Tarot project also played a role. In that project, AI generated interpretation data for all 78 cards and helped me design the reading logic. The workflow had been so effective that I wanted to stress-test it on a far more complex domain.

The Fundamental Gap Between Tarot and Saju

Tarot was a complex project, but its underlying structure was relatively straightforward. You have 78 cards, each with upright and reversed interpretations, arranged in a few spread layouts. In data-modeling terms: 78 cards, 156 interpretation texts, 3 to 4 reading layouts. That is the whole picture.

Saju starts from a fundamentally different baseline. There are 10 Heavenly Stems (Cheongan, 天干) and 12 Earthly Branches (Jiji, 地支). So far, that sounds simple enough. The problem is the web of combinations and relationships that these 22 characters generate.

The 60 Stem-Branch Cycle (Sexagenary Cycle) --- 60 pairings of Stems and Branches. The Five Elements (Oheng, 五行) --- Wood, Fire, Earth, Metal, Water and their generating/overcoming relationships. The Ten Gods (Sipsin, 十神) --- 10 relationship types between the Day Stem and every other character. Hidden Stems (Jijanggan, 地藏干) --- Heavenly Stems concealed within each Earthly Branch. The Twelve Life Stages --- a 12-phase energy lifecycle from birth through death and rebirth. And Combinations, Clashes, Punishments (合沖刑破害) --- a dizzying array of interactions between characters: Stem Combinations, Three Harmonies, Directional Combinations, Six Harmonies, Six Clashes, Punishments, Destructions, and Harms.

If Tarot is "78 cards," Saju is "a universe of relationships generated by 22 characters." The complexity is not about the volume of data --- it is about the density of relationships.

The First Question I Threw at AI

"Do you have the data needed for Saju? I want to build a Four Pillars program."

When I tossed that single sentence to Claude, the response was strikingly different from what I had experienced with Tarot. With Tarot, the structure came together relatively quickly. With Saju, the AI proactively laid out an entire terrain map of the domain.

The Heavenly Stems and Earthly Branches system, the 60 Stem-Branch Cycle, the generating and overcoming relationships of the Five Elements, Ten Gods analysis, Hidden Stems, the Twelve Life Stages, Combinations and Clashes. In under ten minutes, the core building blocks of Saju were listed out --- what each element is, how they interconnect, and what data structures they would require in code.

That moment was the project's first turning point. Once the full landscape was visible at a glance, my vague anxiety of "Can I actually build this?" transformed into a concrete plan: "If I implement these pieces in this order, I can get there." Of course, I had no idea yet just how bumpy that road would be.

Three Critical Questions from the AI

After mapping the domain, Claude posed three pivotal questions that ended up shaping the entire project.

First: "How will you implement the interpretation engine?" Pure rule-based? Entirely AI-driven? Or a hybrid? The crux of this question was where to draw the line between precise code-based calculations and AI-generated natural-language interpretation.

Second: "What is your target quality level?" A learning prototype, or production-grade? This question rippled into every subsequent decision --- calendar accuracy, UI/UX polish, interpretation depth.

Third: "How will you handle the Ten-Thousand-Year Calendar (Manselyeok) data?" Build it from scratch? Use an open-source library? Call an external API? The first step in any Saju analysis is converting a birth date and time into the Four Pillars, and the calendar data powering that conversion forms the technical foundation of the entire project.

Why I Chose a Hybrid Architecture

My answer to the first question was "hybrid" --- a structure combining a rule-based engine with AI interpretation.

The reasoning was clear. In Saju, "calculation" and "interpretation" are fundamentally different tasks. Determining which Element a Stem belongs to, identifying Ten Gods relationships, checking whether a Clash exists --- these follow explicit, deterministic rules. The Stem Gap belongs to Wood. Gap and Gi combine. In-Myo-Jin form a Directional Combination. These must be implemented precisely in code.

On the other hand, holistic readings like "What is the overall flow of this person's chart?" or "What does this Combination mean in the context of their life?" demand nuance and contextual understanding. That is where AI's natural language capabilities shine.

The rule-based engine produces accurate analytical data; the AI then transforms that data into human-readable comprehensive interpretations. Each layer plays to its strengths. This decision became the architectural backbone of the project.

Aiming for Production Quality

My answer to the second question was "production-grade." I could have started with a learning prototype, but the Tarot project had raised my ambitions.

Aiming for production quality meant, concretely: calendar conversions must be accurate --- not just Gregorian-to-Lunar, but Solar Term-based month determination, True Solar Time correction, Daylight Saving Time adjustments, and Late Night Hour (Yajasi) handling. The UI/UX must be usable by real people. Interpretation depth must go beyond toy-level outputs.

This decision dramatically raised the difficulty. But looking back, it was the right call. A "good enough" prototype teaches you little --- during the build or after. Pursuing accuracy forces you deep into the domain, and that journey is where the real learning happens.

An Open-Source Calendar Library

For the third question --- how to handle calendar data --- I chose an open-source library. Specifically, the korean-lunar-calendar npm package as a foundation, supplemented by separate Solar Term data from the Korea Astronomy and Space Science Institute (KASI).

Building a calendar engine from scratch was possible, but the heart of this project is the Saju analysis engine, not the calendar itself. The calendar is merely "a tool that produces accurate input data." Investing development resources there instead of leveraging a proven library and focusing on the analysis engine would have been irrational.

That said, it was not as simple as plugging in a library. Solar Term-based month determination was not something the library provided out of the box, and True Solar Time corrections and Daylight Saving Time handling had to be implemented from scratch. Those stories will come in later installments.

The Value of a Terrain Map Drawn in Ten Minutes

Looking back, the most important moment in this project was when I asked the AI that first question and had a complete domain map within ten minutes. The instant the full contours of Saju --- a vast domain --- became visible at a glance, I felt genuine confidence that "I can do this."

I had a similar experience during the Tarot project. But those ten minutes with Saju were far more valuable. Saju is the kind of domain where mapping the terrain on your own could take weeks. Understanding what Heavenly Stems are, grasping the Five Elements, learning about Ten Gods, and then figuring out how they all connect --- doing all of that independently requires serious time.

AI compressed that timeline to ten minutes. Of course, deep understanding of each element still had to be built through hands-on implementation. But seeing the whole landscape first and then drilling into details versus starting from details and trying to assemble the big picture --- the difference in efficiency is enormous.

What I Learned Along the Way

First, a project's complexity is determined not by the volume of data but by the density of relationships. Saju's 22 characters are far more complex than Tarot's 78 cards because the relationships between those characters are layered and interwoven.

Second, the more complex the domain, the greater the value of "mapping the terrain first." The domain map AI laid out in ten minutes became the compass for every design and implementation decision that followed.

Third, getting good answers from AI does not require good questions. Honest questions are enough. A single candid sentence --- "I want to build a Saju program" --- set the direction for the entire project.

Next Up

The project's direction was set: hybrid architecture, production quality, open-source calendar. But before I could start coding, I stumbled on a shocking discovery. The same birth date and time produces different results depending on which Saju app you use. Why? How do you design for a domain where multiple correct answers exist? Part 2 picks up there.