DEV Community: taurus yao

The Opposite Slot Comes Free: Modelling a Paired Reading Instead of a Single Lookup

taurus yao — Thu, 29 Oct 2026 18:31:42 +0000

The Opposite Slot Comes Free: Modelling a Paired Reading Instead of a Single Lookup

Every rule-heavy domain has the same shape. A small set of conventions gets applied in a fixed order, the output is a structured record, and then a human reads that record and produces prose. The prose gets all the attention. The substrate is where the engineering actually lives.

I want to use one slot out of a twelve-slot chart as a worked example, because that slot has a property most of the other slots do not: it is fully determined by another slot.

In Zi Wei Dou Shu the slot that describes a person's life outside home ground — travel, relocation, unfamiliar places, public exposure — sits directly opposite the slot that describes the person themselves. That single geometric fact is worth more than it looks. It turns a lookup into a comparison, and comparisons are testable in ways that lookups are not.

Nothing below requires any astrology background. No forecasts, no verdicts. The subject is only the data model.

1. The slot is a congruence, not an entry in a table

The twelve slots have a fixed label order, identical for every chart. Only the rotation is personal.

LABELS = [
    "Life", "Siblings", "Spouse", "Children",
    "Wealth", "Health", "Travel", "Friends",
    "Career", "Property", "Fortune", "Parents",
]

def opposite(i: int) -> int:
    return (i + 6) % 12

assert len(LABELS) == 12 and len(set(LABELS)) == 12
assert LABELS[6] == "Travel"
assert opposite(0) == 6                                    # life at 0 -> travel at 6
assert all(opposite(opposite(i)) == i for i in range(12))   # involution
assert all(opposite(i) != i for i in range(12))             # no fixed points

Three properties fall out of that, and all three are worth exploiting:

One index determines the other. Store the rotation once, derive the pair. If the renderer and the reading engine each compute the slot independently, they can disagree, and the disagreement will look like a content bug when it is an indexing bug. Deriving both from one number makes that category of bug unrepresentable — the same argument as any single-source-of-truth change.
The relation is its own inverse. opposite(opposite(x)) == x is a free property test. It catches off-by-six errors immediately, which is the most common arithmetic mistake in a ring of this size.
No fixed points. No slot is its own mirror. That is not decoration: it means the pair always carries two distinct pieces of data, so a "paired" reading can never silently collapse into a single-record reading.

2. What a record actually holds

Four fields per slot, and only one of them is really interesting.

from dataclasses import dataclass, field

@dataclass(frozen=True)
class Palace:
    index: int                                                  # derived, never authored
    stars: tuple = ()                                           # zero, one or two main stars
    brightness: dict = field(default_factory=dict)              # star -> label, not a number
    transforms: dict = field(default_factory=dict)              # star -> transformation kind

The star set is fixed and small — fourteen of them, drawn from a closed vocabulary. A slot may hold zero, one or two. The empty case is the one that carries design weight, because the convention is that an empty slot is read by borrowing the star of the slot opposite it.

That is the point where the geometry stops being decorative and becomes load-bearing: one slot's emptiness promotes the other slot's content to primary input. If you build the pair relation as a rendering convenience, an empty slot is an edge case. If you build it as part of the model, an empty slot is just a resolution rule.

def effective_stars(palace, chart):
    """A slot with no star borrows the opposite slot's star. Do not recurse."""
    if palace.stars:
        return palace.stars
    return chart[opposite(palace.index)].stars

The comment is the whole lesson. If both slots in a pair are empty (it happens), a naive borrow recurses and you either loop forever or invent a star to break the cycle. One level of borrow, then stop, and let the caller see an empty result — the empty result is real information, not a missing value.

3. Brightness is a sign, not an adjective

Here is the modelling decision that matters most, and the one most implementations get wrong.

Each main star in each slot carries a brightness rank. Rank is not a qualifier that makes the sentence "nicer". It flips polarity. The same star in the same slot describes outward flourish at the top of the scale and drain at the bottom. Model it as an adjective and your prose templates will contradict each other; model it as a sign and the contradiction becomes a branch you can test.

The trap: published tables disagree on how many rungs the scale has — five in some, six or seven in others. So do not store an integer. Store the label, and map label to band through a versioned table:

# A modelling choice, not a transcription of any one published table.
# Different tables use different rung counts, which is exactly why the
# integer must live in config and never in a stored record.
BRIGHTNESS_BANDS = {
    "table-v1": {
        "brightest": +1, "bright": +1, "favourable": +1,
        "flat": 0,
        "strained": -1, "dim": -1, "darkest": -1,
    },
}

def polarity(brightness: str, table: str = "table-v1") -> int:
    return BRIGHTNESS_BANDS[table][brightness]   # KeyError is the desired failure

Two deliberate choices in five lines:

A missing label raises instead of defaulting to zero. A silent 0 would render as a neutral reading and nobody would ever notice the record was incomplete. Fail closed.
The table is a parameter with a name. When you upgrade to a table with a different rung count, the migration is a diff of a config file, not a scan of stored records hunting for integers that used to mean something else.

4. The pair read is two projections of one record

Given the slot and its mirror, the useful output is not one sentence but two, produced from the same fields:

def read_pair(chart, life_index, table="table-v1"):
    inner = chart[life_index]
    outer = chart[opposite(life_index)]

    def describe(p):
        return {
            "slot": LABELS[p.index],
            "stars": effective_stars(p, chart),
            "polarity": [polarity(p.brightness[s], table)
                         for s in effective_stars(p, chart) if s in p.brightness],
        }

    return {"inside": describe(inner), "outside": describe(outer)}

The value of returning both is that the prose layer is forced to talk about the relationship — which side is heavier, which side is carrying the borrowed star — rather than emitting a verdict about a single slot. Structural constraint producing better prose, which is usually the opposite of how these systems get built.

5. Time layers are a cascade, not a merge

A chart is read at three time scales: natal, ten-year period, single year. Activation markers (the transformation set) can appear at any of the three, in the same slot. Two questions have to be answered explicitly, and published conventions do not agree:

When an inner layer marks a star that an outer layer already marked, does it replace or coexist?
Do you read the union of all marks, or the most specific one?

Do not resolve this inside a rendering function. Keep the ambiguity in the data:

LAYERS = ("natal", "decade", "year")

def marks_at(chart, index, layers=LAYERS):
    out = {}
    for layer in layers:
        for star, kind in chart[layer][index].transforms.items():
            out.setdefault(star, []).append((layer, kind))
    return out

Returning a list rather than a scalar means the precedence question stays visible to whoever writes the prose, and stays testable. If you fold it to one value early, you have made a convention decision in a place where nobody will look for it.

6. Three tiers, and only the first one is really yours

The most useful thing I can say about this domain is a triage:

Tier	Content	Status
1	Slot indices, the pair relation, the involution	Arithmetic. Assert it.
2	Star placement, brightness labels, transformation assignment	A table lookup. Only as good as the named table version.
3	The sentences	Interpretation. Not checkable.

Tier 1 is a handful of lines and a handful of assertions, as above. It is deterministic, fast, and it either passes or it does not.

Tier 2 is checkable against a version — which is the only meaningful sense of "checkable" for reference data. The numbers cannot be better than the table they came from, so the table gets a name and a hash, and upgrades get diffed.

Tier 3 is not checkable, and pretending otherwise is how these products rot. Whatever you conclude about whether a top-rank star in the outer slot means recognition or burnout is a judgement, in the same way that any interpretation of a structured record is a judgement.

The consequence is a rule: tier 3 must never back-propagate into tiers 1 and 2. If a bad sentence gets "fixed" by editing a reference table, an arithmetic error has been laundered into a data file and you have lost the ability to diff it.

7. Why this is worth the afternoon

Rule-heavy products fail quietly in one specific way: the deterministic layer drifts, and the prose layer keeps producing confident paragraphs on top of it. A prose error is loud — the sentence is nonsense, someone notices. An arithmetic error is silent, because the output is still fluent.

A small assertion suite on the structural layer is the cheapest instrument available. It does not make the readings better. It makes the machinery honest, which is the part that can actually be verified.

The narrow claim of this post, restated: within this chart, the outer slot is an index congruence off the inner slot, an empty slot resolves by one non-recursive borrow, brightness is an ordinal whose polarity band lives in versioned config, and time layers stay un-merged on purpose. That is checkable. The rest is reading.

If you want to see the same structure rendered from real birth data rather than from my toy dicts, the chart generator is here: https://askziwei.com/?utm_source=devto

Palace Ring Arithmetic: Why Every Zi Wei Dou Shu Reading Is a Four-Node Query

taurus yao — Thu, 22 Oct 2026 18:31:52 +0000

Most write-ups about Zi Wei Dou Shu treat it as an interpretive art, and the interpretation layer is genuinely that. But underneath the interpretation sits something much more boring and much more checkable: a twelve-slot ring, a fixed label order, and a small set of table lookups. If you are building anything in a rule-heavy domain — or if you just want to know whether two charts agree for structural rather than stylistic reasons — it pays to look at the substrate first.

This post walks through the ring as a data model. No astrology background needed. The claim is narrow: the palace layer is pure index arithmetic plus joins, and that is the part you can verify.

The ring is fixed; only its rotation is personal

A chart has exactly twelve sectors. Their labels are not chosen per person. The label order is the same for every chart in existence:

0  Life
1  Siblings
2  Spouse
3  Children
4  Wealth
5  Health
6  Travel
7  Friends
8  Career
9  Property
10 Fortune
11 Parents

What varies between people is where the ring gets pinned. The Life Palace lands on a sector determined by birth month and hour; from there, the other eleven labels follow in the order above, walking the ring in one fixed direction.

So if L is the sector index that carries the Life Palace, every other label is:

ORDER = ["Life", "Siblings", "Spouse", "Children", "Wealth", "Health",
         "Travel", "Friends", "Career", "Property", "Fortune", "Parents"]

def palace_at(sector, life_sector):
    return ORDER[(sector - life_sector) % 12]

Twelve slots, one offset, twelve answers. Nothing here depends on the person, the year, the stars, or the reading. Two implementations that disagree about which label sits on which sector differ on life_sector (or on the direction of travel), and you can prove which one is wrong by drawing twelve boxes.

Six opposite pairs fall out of the arithmetic

Because twelve slots pair up across the centre, every palace has an opposite at +6:

offset	pairs
0 <-> 6	Life / Travel
1 <-> 7	Siblings / Friends
2 <-> 8	Spouse / Career
3 <-> 9	Children / Property
4 <-> 10	Wealth / Fortune
5 <-> 11	Health / Parents

Notice that this list is derived, not memorised. Once the label order and the +6 rule are fixed, the six pairs are the only possible output. The interpretive claim attached to each pair — that career reads against partnership, that money reads against how content you feel — is a separate layer sitting on top of the geometry. Keeping those two layers apart is the difference between a system you can test and a system you can only argue about.

Every reading is a four-node query

Here is the part that surprises people who assume a "reading" means one box. In practice a palace is never judged alone. It is read together with two more palaces at -4 and +4, plus the opposite at +6. That four-slot set is the standard unit of analysis.

def reading_set(sector):
    return sorted({(sector + d) % 12 for d in (0, -4, 4, 6)})

Run it for the Life Palace at sector 0: you get {0, 4, 6, 8} — Life, Wealth, Travel, Career. Run it for Travel at sector 6: {0, 2, 6, 10} → Life, Spouse, Travel, Fortune.

Both sets contain the same two axis nodes and nothing else in common. A palace and its opposite are linked but not equivalent: they share the axis, while each brings its own ±4 pair. That is the exact sense in which the pair reads as one topic seen from two directions — the shared part is the conflict, the unshared part is what each side adds.

for p in range(12):
    opp = (p + 6) % 12
    assert opp in reading_set(p)                                   # opposite is in the set
    assert reading_set(p) & reading_set(opp) == {p, opp}           # trine pairs are disjoint
    assert (opp + 6) % 12 == p                                     # the relation inverts itself

Three one-line assertions, and you have pinned down the entire read-time topology. If your implementation of "the three-parties-and-four-positions" rule fails any of them, it is wrong, and it is wrong in a way you can point at.

The practical consequence: a reading is a query over four nodes, not a property of one node. That is why two readers can look at the same chart and emphasise different things without contradicting each other — they may be weighting different nodes in the same four-element set. It also means a cached interpretation keyed on a single palace is under-keyed. Key it on the four-slot set plus the star set inside those slots, and the cache stops returning stale text when a neighbouring palace changes.

Where the arithmetic stops and the tables start

It would be tidy if everything downstream were modular arithmetic. It isn't, and pretending otherwise is how rule-heavy products rot. There are at least two layers that are tables, not formulas:

Brightness. A star in a given sector has a strength grade — usually rendered as four levels from brightest to dimmest. There is no closed-form function that produces it. It is a lookup keyed on (star, sector), sourced from a classical reference and transcribed once. The engineering risk is transcription error, not arithmetic error, so the only faithful test is a diff against the source table.

Transformations. Four of the stars carry a state that changes with the year (and, at coarser granularity, with a ten-year period). The mapping is again a table keyed on a derived input, and it is injected at read time, not stored in the chart. Two consecutive years can change the state of a palace without changing a single star position.

So the correct mental model is a pipeline with clearly separated stages:

birth inputs
  -> derived inputs (calendar conversion, hour index)
  -> index arithmetic      (deterministic, assertable)
  -> table lookups         (deterministic, but must be transcribed and diffed)
  -> set expansion         (deterministic, assertable)
  -> interpretation text   (the only non-deterministic stage)

The first four stages are computer science. Only the last one is prose. Mixing them — letting a language model re-derive a sector index while it writes the paragraph — is the failure mode that makes otherwise sensible products unreproducible: the same input yields a different number in the second paragraph than in the first, and nobody can tell which one came from the table.

Why separation is the feature, not the housekeeping

Two concrete payoffs, both boring in the way that good infrastructure is boring.

Reproducibility. If stages one through four are pure functions of the inputs, then the same birth data always produces the same structural facts, byte for byte, on any machine. Any disagreement is a bug with a bisectable cause: either a derived input differs (calendar conversion, hour convention) or a table entry was transcribed differently. That is a debugging session, not a debate.

Auditability. When the structure is computed and the prose is generated against that structure, the prose can be checked. Does the paragraph mention the same palace set the query returned? Does the strength claim match the table? Where a claim cannot be checked, you can at least see that it came from stage five rather than stage two.

This is also the honest limit of the whole exercise. The arithmetic decides where things sit and which four slots belong together. It does not decide what they mean, and no amount of formula-fiddling will turn a position into advice. Anyone who presents a chart position as a verdict — you will move abroad, you will change careers — has left the deterministic part and is improvising.

Try it against a real chart

The ring, the six pairs, the four-node set, the two tables — that is the entire mechanical skeleton of a chart. If you want to check the model against live output rather than a diagram, the site's own guides cover how each palace is read, and the calculator will render all twelve sectors from birth data:

https://askziwei.com/?utm_source=devto

Generate a chart, take the sector carrying the Life Palace, and compute its four-node set by hand with the modulo expression above. If your hand count and the rendered chart agree, the ring is what this post says it is. If they don't, you have found either a convention difference or a bug — and either way you have learned more than another paragraph of interpretation would have told you.

If you are building something similar in another rule-heavy domain, the transferable lesson is the layer boundary: compute what can be computed, transcribe what must be transcribed, diff what must be diffed, and keep the prose at the end where it can be checked against the other three.

The Anchor Step: One Mod-12 Formula That Determines Every Position in a Zi Wei Dou Shu Chart

taurus yao — Thu, 15 Oct 2026 18:31:45 +0000

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

The 5-Step Algorithm Behind a Zi Wei Dou Shu Chart - Worked by Hand, With Every Convention Flagged

taurus yao — Fri, 09 Oct 2026 13:47:47 +0000

Most chart-based systems are pipelines. A small, well-defined input goes through a fixed sequence of deterministic transforms and comes out the other side as a large, structured artifact. Zi Wei Dou Shu - a Chinese system of charting built on the lunar calendar - is a clean case study, because its arithmetic is fixed and auditable, and almost every genuinely hard question lives at the boundaries rather than in the interpretation.

This post walks the five mechanical steps on a single worked example, and flags at each step the places where independent implementations legitimately diverge. Those divergence points are the reason two tools can disagree about a chart without either one being wrong, and knowing where they are is what makes a chart checkable in the first place.

The input is unglamorous: a Gregorian date, a clock time, and a sex. The output is a 12-slot grid (the "palaces"), each slot carrying a palace name, a branch, a stem, a Five Element Bureau, and a set of stars. Everything in between is arithmetic.

Worked example throughout: born 12 September 1992, 10:20, female.

Step 1 - Convert the birth data, and decide about true solar time

The chart is built on the lunar calendar, not the Gregorian one, so the first step converts the civil date to a lunar date and expresses the birth time as a double-hour (a two-hour block), not as clock minutes.

Worked example: 1992-09-12 10:20 becomes lunar year 1992, month 8, day 16, in the Si double-hour. The year pillar is Ren-Shen.

This step looks objective and is not entirely so:

True solar time. Clock time is not solar time. A 10:20 birth can fall in a different double-hour once longitude correction (and, in some methods, the equation of time) is applied. Some implementations correct for this, others take the clock as given. Near a boundary, this alone moves the chart.
Where the correction is anchored. Correction needs a birthplace. Historical moves and the choice of a nearby city both introduce small differences.
Lunar month boundaries. Whether a lunar month starts at the astronomical new moon or an adopted civil date can differ by a day between data sources, which is enough to shift the month count.
Leap months. For a birth in an intercalary month, systems differ on whether to count it in its own right or fold it into the preceding month.

Step 2 - Locate the Life Palace and the Body Palace

The twelve palaces are anchored by the Life Palace. The classical procedure runs the month count forward from the Yin palace, then the hour count backward from wherever the month count landed.

BRANCHES = ["Zi", "Chou", "Yin", "Mao", "Chen", "Si",
            "Wu", "Wei", "Shen", "You", "Xu", "Hai"]

def palaces(lunar_month, hour_index):
    # hour_index: 0 = Zi, 1 = Chou, ... 5 = Si, ... 11 = Hai
    # movement 1 - Yin holds month 1, count forward to the birth month
    month_pos = (2 + (lunar_month - 1)) % 12
    # movement 2 - put Zi at month_pos; life counts backward, body forward
    life = (month_pos - hour_index) % 12
    body = (month_pos + hour_index) % 12
    return BRANCHES[life], BRANCHES[body]

palaces(8, 5)   # -> ('Chen', 'Yin')

Worked example, movement 1: Yin as month 1, counting forward to month 8, gives the You palace.
Movement 2, Life: from You, set Zi there and count backward to the Si hour: You, Shen, Wei, Wu, Si, Chen - the Life Palace is Chen.
Movement 2, Body: same start, opposite direction: You, Xu, Hai, Zi, Chou, Yin - the Body Palace is Yin.

Two useful invariants fall out of the arithmetic. First, the Body Palace uses the same starting position as the Life count and runs the other way, so it can only ever land on six of the twelve palaces. Second, the hour index that drives both movements is a double-hour index, so every ambiguity from Step 1 inherits straight into this step.

Divergence points here: the direction convention used for each of the two movements; which double-hour actually feeds the count (inherited from Step 1); and late-Zi births, between 23:00 and midnight, where implementations disagree on whether that hour belongs to the current day or the next.

Step 3 - Fix the Five Element Bureau

The Life Palace is not only a position - it also takes a stem, assigned by the same stem cycle that assigns stems to the months of the year: the year stem anchors the Yin palace and the cycle runs forward from there. Life Palace stem and branch together form a sexagenary pair, and that pair's associated element and number give the Five Element Bureau.

Worked example: the year stem is Ren. Anchoring Yin with Ren and counting forward: Yin = Ren, Mao = Gui, Chen = Jia. The Life Palace is Jia-Chen, the pair for the Fire Six Bureau.

Element	Bureau	Number
Water	Water Two	2
Wood	Wood Three	3
Metal	Metal Four	4
Earth	Earth Five	5
Fire	Fire Six	6

That number is not decorative. The next step consumes it.

Divergence at this step is almost always inherited: the mapping is a standard table, so a different bureau usually means Step 2 produced a different Life Palace.

Step 4 - Place the Zi Wei star

Zi Wei is positioned by a two-input lookup: the bureau number and the lunar day of birth. Given both, a fixed table returns the palace where Zi Wei sits. This star anchors the largest group of the main stars.

Worked example: bureau Fire Six, lunar day 16 -> Zi Wei sits in the Wu palace.

Divergence points: published tables have historically differed, especially for higher bureau numbers and the later days of a lunar month; and the wrap-around adjustment some presentations apply at month end varies in how aggressive it is. Because everything in Step 5 hangs off Zi Wei, a one-palace difference here propagates widely.

Step 5 - Distribute the fourteen main stars

The fourteen main stars travel in two groups. The Zi Wei group is placed relative to Zi Wei, running stepwise in one direction. The Tian Fu group is anchored by Tian Fu, positioned by a mirror relationship to Zi Wei, and runs stepwise in the opposite direction.

Worked example: Zi Wei in Wu, Tian Fu in Xu. Applying the two sequences gives:

Palace	Main star(s)
Life	Qi Sha
Siblings	Tai Yang, Tian Liang
Spouse	Wu Qu, Tian Xiang
Children	Tian Tong, Ju Men
Wealth	Tan Lang
Health	Tai Yin
Travel	Lian Zhen, Tian Fu
Friends	-
Career	Po Jun
Property	-
Fortune	Zi Wei
Parents	Tian Ji

Two palaces hold no main star at all, which is normal: twelve palaces outnumber fourteen stars, and empty palaces are read through their opposite palace and the surrounding triangle rather than treated as blank.

Divergence points: which auxiliary and minor stars are included at all (the widest area of disagreement); how the Four Transformations that arise from the decade and the year are treated versus those from birth; and how much of the result a tool chooses to display.

Why two tools can disagree without either being wrong

Collect the divergence points and the picture is clean. Two charts for the same birth data can differ because of:

whether true solar time was applied, and how;
how the double-hour boundary and the late-Zi hour were treated;
lunar month boundary and leap month handling;
the direction convention used for the Life and Body palaces;
which published table variant placed Zi Wei;
which auxiliary and minor stars were included.

Almost none of these are disagreements about interpretation. They are disagreements about input and mechanics, and they happen before interpretation begins. That is why a comparison that looks only at the final reading is so often confusing: the two readings may not be describing the same chart at all.

How to check a calculator

Reproduce Steps 1 to 3 by hand. They are arithmetic you can do on paper. If a tool's Life Palace or bureau disagrees with your own count, stop and find out why.
Test a boundary case. Pick a birth a few minutes either side of a double-hour edge and see whether the chart moves. That tells you immediately whether solar-time correction is in play.
Ask what is being shown. A sparse chart may simply be filtered, not wrong.
Prefer tools that state their conventions. A chart with visible assumptions can be reasoned about; one with hidden assumptions cannot.

What the calculation does not do

All of the above produces a chart. It does not produce a reading. Interpretation is a separate layer: relationships between palaces, the transformations stars carry, and the decade and year cycles that activate different parts of the chart over time. Keeping the two layers distinct is the same discipline as keeping a deterministic core separate from the layer that narrates it, and it is what makes the core testable.

If you want to run the whole sequence on your own birth data, the full step-by-step walkthrough behind this post lives here: How a Zi Wei Dou Shu Chart Is Calculated.

Let the engine do the math: a two-stage architecture for rule-heavy LLM products

taurus yao — Mon, 05 Oct 2026 14:27:16 +0000

Most LLM products in rule-heavy domains break the same way: they let the model do the arithmetic.

I build an app that reads Chinese metaphysics charts (Zi Wei Dou Shu / BaZi). It's a good stress test for this problem, because the domain splits cleanly in two. The calculation side is fully deterministic — given birth date, birth time and gender there is exactly one correct chart, and the rules that produce it are fixed tables that haven't moved in centuries. The interpretation side is prose. Those two jobs want completely different machinery, and the bugs show up the moment you let them blur.

Here's the separation I landed on, plus the parts that were not obvious.

The failure mode: plausible instead of correct

An LLM asked to "generate a chart" will produce something that looks like a chart. The star names are right. The palace structure is right. The formatting is beautiful. And the placements are wrong, because placement depends on calendar facts the model has no way to compute reliably.

The nasty part is that nobody can tell by looking. A user who doesn't already know their chart can't audit it. So wrong output and right output are indistinguishable at the UI level — which means the whole product is unverifiable, no matter how polished the prose on top is.

That's the actual defect. Not "the AI is inaccurate" — the output is unauditable.

Stage 1: compute, don't generate

Stage 1 takes birth data and returns a chart. Every value comes from a fixed rule table or a calendar conversion. No model call, no sampling, no temperature.

Two things make this stage harder than it sounds:

Calendar conversion is the real trap. Converting a Gregorian birth date into the calendar system the rules operate on is not a formatting problem. You're dealing with historical timezone offsets, daylight-saving periods that existed in some regions and not others, and the difference between clock time and true solar time — which is a function of longitude and the equation of time. Get any of those wrong and every downstream placement shifts by one palace. I stopped writing this myself and pinned a well-tested calendar library instead, because the edge cases are historical data, not logic.

Rule tables have to be data, not prompt text. Star placement is a set of lookup rules keyed on things like the value and parity of specific cycle indices. If those tables live in a prompt, they're re-interpreted on every call and drift. If they live in code as tables, they're diffable, testable, and reviewable — and when a disputed rule shows up, you can point at one line.

The output of Stage 1 is a plain data structure. That matters for what comes next.

Stage 2: the model explains what already exists

Stage 2 receives the computed chart and produces human language. It explains what a star sitting in a particular palace means in this system. It does not decide what's in the palace — that's already settled.

This split buys a specific property: the reading can be traced back to a fixed rule. When someone asks "why does it say that?", the chain is: this sentence interpreted this fact, and this fact came from this table at this line. Not "the model felt that way."

I'm deliberately not claiming the interpretation is objective — it's a traditional reading system, and reasonable practitioners read the same chart differently. What I can claim is that the mechanical layer is reproducible and the interpretation layer is constrained to it. Those are separate promises and it's worth keeping them separate in how you talk about them.

Testing is unusually easy here, and that's the tell

Because Stage 1 is deterministic, tests are exact-match fixtures: input birth data → expected chart. No fuzzy scoring, no LLM-as-judge, no "does this look reasonable."

That property is a good smell test for architecture. If your core layer needs a model to grade it, you don't have a deterministic core — you have a second model, and now you need to validate that.

The interpretation layer is different and I test it differently: regression fixtures on the facts handed to the model, plus checks that it never contradicts the computed chart. Checking "did the model stay inside the box it was given" is a much better-behaved test than trying to grade prose.

Boring infrastructure on purpose

The whole thing runs as a small Python service behind a tunnel:

one application process, bound to 127.0.0.1 only — the tunnel is the only way in, so there's no directly exposed port to misconfigure
SQLite for state, single file, included in the daily backup rather than run as a server
a process supervisor that restarts the app if it dies, plus a separate watchdog that checks the app answers before declaring anything healthy

Two operational lessons that cost me real time:

"The service responded 200" is not the same as "the supervisor is running the service." You can end up with a stray process serving traffic while the managed one is dead, and then the next restart takes down a service you thought was supervised. Compare the supervisor's PID against the PID actually holding the port. If they differ, you have a ghost.

A watchdog that auto-restarts on a timer will happily restart you mid-deploy. Pause it during deployments and restore it after, with a trap so it comes back even if the deploy fails.

What I'd pass on

If your domain has one correct answer, compute it in code and never let the model near it.
Make the mechanical layer auditable before you invest in prose quality. Prose on top of an unauditable core is a confidence trick, even when it's accidental.
Exact-match fixtures are a gift. If your core can't have them, that's worth investigating.
Keep your claims as narrow as what you can actually verify. "Reproducible computation" and "meaningful interpretation" are different promises; conflating them is how products end up overclaiming.

The two-stage split is the only structural decision in this project I'd defend without caveats. Everything else is details.

I write about this build in more detail — architecture, the bilingual pipeline, and the calendar edge cases — at askziwei.com. If you're working on a rule-heavy LLM product, I'd genuinely like to hear how you drew the line between computed and generated.