There is a genre of prompt going around: paste your birth date and time into a chatbot and ask for your Korean saju (or Chinese BaZi) chart — the four pillars, the day master, the whole thing. The answers read beautifully. They are also, structurally, guesses.
I run a saju reading service, so I care about this for selfish reasons. But the failure mode is interesting on its own, because it is the quiet kind.
What a chart actually requires
A Four Pillars chart is not text. It is the output of a calendar function:
- Map the birth instant onto the sexagenary cycle — a 60-step cycle of stem–branch pairs that has been ticking continuously for centuries. The day pillar is literally "which of the 60 is today", counted from a known epoch.
- Decide the year and month pillars from the 24 solar terms, which are astronomical instants (the sun reaching a given ecliptic longitude), not calendar dates. The year does not turn on January 1 or on lunar new year; it turns at 입춘 (ipchun) — in 2024 that was February 4, 16:27 KST.
- Correct the hour pillar for true solar time — Korea keeps time on 135°E, Seoul sits near 127°E, so civil noon and solar noon differ by ~32 minutes before you add the equation of time.
- Apply the late-night hour convention (23:00 belongs to the next day for the hour stem, under one common school).
Every one of these is exact arithmetic on instants. None of it is something you can approximate from having read a lot of astrology text.
Why a language model gets it wrong in a specific way
A general LLM does not run a sexagenary counter. It predicts what a chart usually looks like for a date that looks like yours. That works surprisingly often for the easy 95% of dates — the model has seen enough tables. It breaks at the boundaries, which are exactly the cases where a chart is decided:
- born on the morning of ipchun → it hands you the new year's pillar when you are still in the old one;
- born at 23:31 → it does not know which school's convention it silently picked;
- born abroad → it compares your local date to a Korean solar-term date, when the term is a single global instant.
And here is the part that matters: it will not say "I'm not sure." The output has the same confident register whether the day pillar is right or off by one. There is no error term. A calculator that is wrong looks exactly like a calculator that is right, until you check it against an almanac.
You can test this yourself. Ask any chatbot for the four pillars of 2024-02-04 04:00, Seoul, then run:
npx k-saju 2024-02-04 04:00
# year 癸卯 — still the old year pillar, because 04:00 < 16:27
Then try 2000-05-15 23:31 and 2000-05-05 09:30 --lon 124.7. The boundary cases are where the two answers diverge.
The architecture that follows from this
If the numbers must be exact and the prose can be fluent, the two jobs should not live in the same component. Our split:
- A deterministic engine computes the chart — solar terms stored as instants, sexagenary counting, true-solar-time correction, the hour convention written down rather than implied. It is a pure TypeScript module with golden tests for every boundary above. The calendar core is open source as
k-saju(MIT). - An LLM writes the reading — and only the reading. It receives the computed facts as input and produces prose. It is not allowed to introduce a pillar, a stem, or a number that is not in its input; a sanitizer drops any section that does.
The model is the writer, not the calculator. That sentence is the whole design.
The same split, exposed as tools
Since chat assistants are where people are asking these questions, we put the calculator where the questions are: an MCP server (ioreum.com/api/mcp) that ChatGPT and Claude can call as tools. Four of them:
| tool | returns |
|---|---|
calculate_saju |
the four pillars, elements, day master, hidden stems — computed |
luck_pillars |
the ten-year cycles with start ages |
check_zodiac_year |
which zodiac year a date falls in, with the ipchun boundary handled |
day_master_character |
reference entry for any of the sixty day pillars |
The server instructions are explicit that the tools return calculated facts and that written interpretation lives elsewhere — so the assistant has no reason to invent a reading in the chart's voice. Setup is one URL; details at ioreum.com/en/connector.
What I am not claiming
I am not claiming the interpretation of a chart is verifiable. It is not; it is a tradition, and reasonable schools disagree. The claim is narrower: the calculation is verifiable, so it should be done by something that can be verified — and a language model is the one component in the stack that cannot be.
If you build anything on top of traditional calendars — Chinese, Korean, Hindu panchang, anything with astronomical boundaries — the same rule applies. Compute first. Let the model write.
Top comments (0)