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.
A Four Pillars chart is not text. It is the output of a calendar function:
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.
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:
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
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.
If the numbers must be exact and the prose can be fluent, the two jobs should not live in the same component. Our split:
k-saju
The model is the writer, not the calculator. That sentence is the whole design.
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.
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.