I built a deterministic engine for I Ching (六爻 / Liu Yao) hexagram casting and open-sourced the core (Apache-2.0). I want to be upfront that the interesting part here is not the divination — it s a testing problem, and I d like feedback on how I handled it.The engine takes a moment in time plus a coin toss and mechanically derives a fully annotated chart: the hexagram, its palace, the stem-branch (najia) assignments, the six relatives, moving lines, void days, and the line-strength skeleton. It does not interpret anything — it only emits hard, mechanical facts.The problem that made this interesting: the rules are ~3000 years old, written in classical Chinese, and different schools contradict each other. There is no official answer key, and human experts disagree and are sometimes wrong. So the tests I d naturally write just encode the same assumptions my code does — if I misread a rule, the code and its test are wrong together and both stay green. The self-validation paradox.My way out was differential testing against independent oracles. I diff every field of the chart against `najia` (a separate MIT implementation) and a second machine-readable rule table, over random-but-seeded samples in CI. A field is only trusted when all three agree. The calendar layer (which is zero-tolerance — a day-pillar off by one silently corrupts everything downstream) gets its own diff, sxtwl vs lunar-python, focused on the nasty boundaries: solar-term month divisions, the 23:00 day change, and cross-timezone casting.That principle ended up driving the design: anything that can t be independently cross-validated doesn t enter the core. That s why the traditional auspicious stars (神煞), true-solar-time correction, and school-mixing are all deliberately excluded — not because they re wrong, but because I have no way to prove the code computes them correctly.I m in UTC+8 (China) so replies from me may lag by a few hours during your daytime — but I ll be around all day when I m awake. Happy to go deep on any of it.