Every chart built from a fixed rule set has an anchoring step — the one computation that everything else is indexed to. Get it wrong and no amount of careful reading downstream will reveal why the output looks off. In Zi Wei Dou Shu, that step is locating the Life Palace.
It is a short computation, which is exactly why it is worth writing down precisely. It is also the step where two implementations most often disagree without either one making an arithmetic mistake — the disagreement is usually about the inputs, not the formula. That distinction is worth internalizing if you build anything in a rule-heavy domain.
What the anchor decides
The Life Palace is a position in a twelve-slot cycle (the twelve "palaces", or sectors). It is not a label on a fixed grid. It is the reference point from which the other eleven slots are counted, and two of its properties feed every later layer:
- Its branch (slot) sets the order of the other eleven.
- Its stem-and-branch pair produces a value called the Five Element Bureau, which is the key the star-placement layer uses.
So the chain is:
month + hour -> Life Palace branch
Life Palace + year -> bureau
bureau + lunar day -> Zi Wei star position
Zi Wei + Tian Fu -> all fourteen main stars
One position changes, and every layer below it changes. That is the whole reason the anchor step deserves its own treatment.
The inputs, stated exactly
Two inputs, and only two:
- M — the lunar birth month, 1–12.
- H — the birth-hour branch index, counting the first double-hour (Zi) as 0 through 11.
Both are derived values, not raw inputs. M comes from a Gregorian-to-lunar conversion. H comes from the birth clock time, optionally corrected to true solar time. If either derivation differs between two implementations, the formula below can be identical and the results will still differ — this is the point people miss.
The formula
Using branch indices where Zi = 0:
Life Palace: L = (M + 1 - H) mod 12
Body Palace: S = (M + 1 + H) mod 12
Two things are worth noticing before the example.
Same inputs, opposite direction. The classical procedure is: set the Yin palace (branch index 2) as lunar month 1, count forward to the birth month, then from there count backward to the birth hour. That backward count is why the formula subtracts H. The Body Palace runs the same count in the opposite direction — hence the plus.
The Body Palace has only six reachable slots. Because S - L = 2H (mod 12), the Body Palace can only land on an even offset from the Life Palace: the Life, Spouse, Wealth, Travel, Career and Fortune palaces. That is a property of the arithmetic, not a rule of interpretation — but it is a fast consistency check when you are validating a chart.
Worked example
Take a birth in lunar month 8, at the sixth double-hour (Si, index 5).
Life Palace. L = (8 + 1 - 5) mod 12 = 4 -> branch index 4 = Chen.
Body Palace. S = (8 + 1 + 5) mod 12 = 2 -> branch index 2 = Yin.
The hand-count version of the same thing, to confirm the formula is not doing something the procedure does not:
- month forward: Yin(month 1) -> Mao(2) -> Chen(3) -> Si(4) -> Wu(5) -> Wei(6) -> Shen(7) -> You(8)
- hour backward from You: You(hour 0) -> Shen(1) -> Wei(2) -> Wu(3) -> Si(4) -> Chen(5)
Both paths land the Life Palace on Chen. The Body Palace counts the same six steps forward from You instead:
- You(0) -> Xu(1) -> Hai(2) -> Zi(3) -> Chou(4) -> Yin(5)
and lands on Yin.
Laying out the rest
Once the anchor is fixed, the remaining eleven slots are assigned in reverse branch order starting from the Life Palace. Enumerating that is mechanical:
| Palace | Branch |
|---|---|
| Life | Chen |
| Siblings | Mao |
| Spouse | Yin |
| Children | Chou |
| Wealth | Zi |
| Health | Hai |
| Travel | Xu |
| Friends | You |
| Career | Shen |
| Property | Wei |
| Fortune | Wu |
| Parents | Si |
In this example the Body Palace (Yin) coincides with the Spouse slot. That is a normal outcome — it just records where the chart puts its emphasis.
Why "same inputs, different chart" usually is not a bug
This is the part that transfers to any rule engine with historical conventions baked in. The formula is standard. When two tools disagree on a chart, the disagreement is nearly always about M or H:
- Count direction. Implementations occasionally differ on which direction one of the two movements runs, or which slot the count starts from. Check this first.
- True solar time. If one method corrects clock time to true solar time, a birth near a double-hour boundary shifts H by one — and the anchor moves with it.
- Late Zi-hour births. Births between 23:00 and midnight raise a genuine ambiguity: does that double-hour belong to the current day or the next? Both answers are arithmetically valid.
- Month boundaries and leap months. If two converters disagree about whether a date falls in lunar month 7 or 8 — a new-moon boundary, or how an intercalary month is numbered — then M differs by one and the anchor moves.
- Display conventions. Two tools can agree on the anchor and still look different, because one labels slots by branch and the other by palace name. Compare the branch first; it is unambiguous.
None of these is a mistake. They are places where an old procedure has more than one defensible reading — and a chart is only fully checkable when the reading it used is stated. If you are building in a domain like this, that is the design lesson: make the conventions explicit and inspectable, because the arithmetic being right is not enough for the output to be reproducible.
The takeaway
An anchor step should be small enough to verify by hand and stated precisely enough that two implementations agree. Here the count is four lines of arithmetic, but the failure modes live entirely in the inputs. That is why a comparison of two charts should start at the anchor rather than at the reading: if the anchor differs, the two readings are not describing the same chart, and comparing their conclusions is not a comparison at all.
I walk through this step and the star rules that follow it in the reference guide here: https://askziwei.com/blog/en/life-palace-calculation-formula.html?utm_source=devto
Top comments (0)