How we calculate

Daovian is built around a simple rule: if a strong claim cannot be tied to a deterministic calculation or a citable source, we do not ship it as destiny.

That sounds obvious until you look at how most “AI metaphysics” products work. They accept a birth time, call a model, and return fluent prose. The prose may mix correct calendar facts with invented classical authority. You cannot tell which is which, because calculation and storytelling share one opaque reply.

We split the stack on purpose.

1. Engine first — deterministic facts

The engine owns calendar and chart math:

• stems and branches for year, month, day, and hour
• solar terms and day notes shared with the almanac
• Bazi chart construction and rule-derived structural facts (including optional decade / yearly pillars)

Same inputs must yield the same facts for every user. No LLM sits on this path. No sampling temperature. No “creative reinterpretation” of a day master.

Rule forks we will document

Chinese calendar practice is not one global standard. Transparent software states its fork instead of hiding it:

• how the day boundary is treated around midnight / 子时
• how month pillars relate to solar terms
• whether true solar time corrections are optional
• how missing birth hour is represented (unknown hour vs assumed hour)

When the app exposes toggles, diffs must be explainable from those toggles alone. Silent forks are how two “accurate” apps disagree while both claim authority.

What “recompute” means for you

You should be able to read a fact panel, re-enter the same birth data and timezone policy, and land on the same result. If we cannot meet that bar for a feature, the feature is not ready.

2. Sources next — rules and passages

Traditional explanations need a trail:

• an algorithm rule (documented transformation from facts), and/or
• a classic passage or curated claim from open corpora

Free keeps facts and rules visible, with limited passage previews. Pro expands the citation trail. We start from open Markdown / JSON corpora with thin retrieval, then curate sources over time.

What we do when sources are missing

We show the chart or day facts without forcing an interpretation. Empty space is better than fabricated lineage. “AI sounded confident” is not a source.

3. AI only explains — never invents math

When AI features run, the model receives:

1. structured engine output
2. retrieved passages / rule descriptions

It may translate, summarize, and clarify. It must not invent new clash logic, new five-phase scoring, or new classical citations that were not retrieved.

If a Pro explanation cannot be grounded, we prefer a weaker, clearly labeled note over a strong ungrounded verdict.

4. Free vs Pro in method terms

We do not lock the chart itself behind a paywall. Verification is not a premium feature. Soft-free: signed-in users currently get the Pro column above while paid checkout is prepared — see Pricing.

5. Life reference, not absolute fate

Everything Daovian publishes is cultural and analytical reference. It is not medical, psychological, legal, financial, or guaranteed destiny advice. A skilled human practitioner may add judgment we do not claim. Use the product as an inspectable aid — not as a substitute for professional counsel or personal responsibility.

6. Ziwei (紫微斗数) — natal + decadal/yearly structure

Ziwei is available as a natal palace–star chart, plus decadal / yearly stems and mutagen star names for a target civil date (placement structure). Same stack contract: engine facts first, open rules second, AI only narrates what was computed and retrieved.

Inputs

• Civil birth date and required birth time (defaults to China Standard Time / Asia/Shanghai wall clock)
• Sex (male / female) — used by the chart construction path
• Optional true solar time: when east longitude (70–140°) is provided, wall clock is corrected by offset from 120°E plus equation of time before palace math (rule.time.true_solar.v1 / daovian.true_solar.v1)
• Optional place label (records only; not used to infer longitude)

Unknown birth hour is not supported in v1: palace placement depends on the Chinese double-hour (时辰).

Upstream fork (documented)

Construction uses iztro with:

• solar (bySolar) entry
• default leap-month adjustment (fixLeap: true)
• time index 0–12 (early Zi through late Zi), mapped from clock hour
• library defaults for star placement schools
• Decadal/yearly: iztro.horoscope(target civil date) → rule.ziwei.horoscope.iztro
• Scope: rule.ziwei.scope.no_geju_verdict (no pattern / full mutagen verdicts)

We do not silently switch schools. If a future toggle appears, it will be named and test-locked.

What the engine returns

For each of the twelve palaces: palace name, heavenly stem / earthly branch, major stars, and a short list of auxiliary stars. Also soul/body labels, five-elements class, and decadal/yearly stem–branch plus mutagen names for the target date. Same inputs (and same target date) → same JSON.

What we refuse

• Simulated sample charts that cannot be recomputed
• AI palace / pattern verdicts without a rule or passage trail
• Treating palace–star or cycle structure as absolute destiny

Module page: Ziwei.

7. Liuyao (six lines)

Liuyao in Daovian is Najia packing facts, not a full yuanchen verdict.

Inputs

• Six coin values from bottom (初爻) to top (上爻): 6 old yin, 7 young yang, 8 young yin, 9 old yang
• Cast date and time (defaults to China Standard Time wall clock) for day pillar / six gods
• Optional true solar time with east longitude (70–140°) before Najia packing (rule.time.true_solar.v1)
• Optional note / label (records only; does not affect packing)

Line values come from either:

1. Electronic three-coin cast — server-side cryptographic randomness for three coins (yang=3, yin=2), summing to 6/7/8/9; faces are HMAC-bound to your account. Cast time is China Standard Time when the sixth line finishes
2. Manual entry — values from a cast you already made offline, with a time you choose

The packing engine consumes the final line values and time; the shake procedure does not change the Najia algorithm. Unknown hour is not supported in v1.

Upstream fork (documented)

Packing is self-hosted Jing Fang Najia in packages/engine (liuyaoLib: daovian.najia):

• Hexagram name from binary lines; palace / 世应 via Jing Fang游魂归魂 rules
• Najia stems-branches per trigram; six relatives from palace five-element; six gods from day stem (tyme4ts)
• Changed hexagram when moving lines exist; six relatives on the changed plate use the original palace element; 世/应 are recomputed from the changed hexagram’s own Jing Fang palace

We will not silently switch schools. If we add another fork later, it will be named and locked with tests.

What the engine returns

Original (and optional changed) hexagram names, palace, six line rows (value, Najia, relative, six god, 世/应, hidden spirit), day pillar, month branch. Same inputs → same JSON.

What we refuse

• Random “demo” lines that are not recomputable from saved inputs
• AI yes/no fate answers without a rule or passage trail
• Pretending packing facts are a complete reading

Module page: Liuyao.

8. Qimen Dunjia

Qimen in Daovian is hourly Chaibu zhuanpan packing facts, not pattern verdicts or auspicious-direction advice.

Inputs

• Cast date and time (defaults to China Standard Time wall clock); hour required
• Optional true solar time with east longitude (70–140°) before Qimen packing (rule.time.true_solar.v1)
• Optional note / label (records only; does not affect packing)

Unknown hour is not supported in v1.

Upstream fork (documented)

• Calendar pillars and solar terms: tyme4ts (same zi-hour policy as Bazi; solar term from cast moment, not whole-day jump on term-change days)
• Ju + plate: MIT package bigfishmarquis-qimen (qimenLib: bigfishmarquis.chaibu_zhuanpan)
  • Chaibu ju: current solar term + day-pillar 符头 (甲/己) → yang/yin dun, shang/zhong/xia yuan, ju 1–9; unknown term names reject packing
  • Zhuanpan packing: hourly earth/sky plates, eight doors, nine stars, eight gods (upstream swapped earth/sky stem fields are corrected in our adapter)

We will not silently switch to feipan, Maoshan, or Zhirun. If we add another fork later, it will be named and locked with tests. Upstream pattern-interpretation text is not exposed in engine JSON / AI claims.

What the engine returns

Four pillars, solar term, yuan, yang/yin dun, ju number, duty star/door (with palaces), nine palace rows (earth stem, sky stem, star, door, god), hour xun voids. Same inputs → same JSON.

What we refuse

• Random “demo” plates that are not recomputable from saved inputs
• AI yes/no fate or direction answers without a rule or passage trail
• Pretending packing facts are a complete decision system

Module page: Qimen.

9. Yijing

Daovian Yijing is King Wen study facts (structure + public-domain judgment text), not an oracle. For Najia casting see Liu Yao.

Inputs

• King Wen number 1–64 (dropdown in the app)
• Optional note (records only; does not affect lookup)

The engine also resolves by Chinese name (exact full or short name only — no substring fuzzy match) or six-bit binary (bottom→top, 1=yang 0=yin); v1 UI is number-first.

Upstream fork (documented)

• Sequence + names: self-hosted King Wen tables in packages/engine (yijingLib: daovian.king_wen), sharing the same six-line binary convention as Liu Yao
• Judgment text: public-domain Zhouyi 卦辞 (not a modern copyrighted full edition)
• No Najia, shi/ying, six relatives, or six gods — those stay in Liu Yao

We will not silently turn study into casting. If we add line statements / Ten Wings later, versions and sources will be named.

What the engine returns

Number, full/short name, bits, upper/lower trigrams, six line yin/yang rows, judgment text. Same query → same JSON.

What we refuse

• Random “demo” hexagrams that are not recomputable from saved inputs
• AI fate answers without a rule or passage trail
• Pretending study facts are a complete divination verdict

Module page: Yijing.

10. Naming

Daovian Naming is structure analysis of a user-proposed name (strokes + radical five-phase + pinyin + optional Chinese–English对照 + optional day-master relations), not marketing lists or luck scores.

Inputs

• Mode: zh (Chinese) or zh_en (Chinese–English对照)
• Surname 1–2 characters (compound surnames OK) + given name 1–3 characters
• zh_en: Latin given name (required) + optional Latin surname
• Optional day stem, or use the primary Bazi day stem
• Optional note (records only)

Upstream fork (documented)

• Dictionary: self-hosted daovian.naming.v1 seed in packages/engine; other Han characters resolve live via cnchar with the same rules (source: dict|live)
• Five-phase: radical map radical_v1 (not an arbitrary whole-char table, not 数理 luck)
• Pinyin: pinyinSource: cnchar_low_v (tone-less; ü→v)
• Bilingual crosswalk: rule.naming.bilingual.crosswalk_v1 (normalize + initial flags; syllable match is English-token exact or ≥3-letter prefix, not bare substring; no Western letter-element scores)
• Day-master link: stem→element only, then structural generation/control labels

We will not silently switch stroke or wuxing tables. Characters with no stroke/radical mapping are rejected.

What the engine returns

Full name, per-character strokes/radical/element/pinyin, surname/given/total strokes; in zh_en, English normalize + crosswalk flags; optional day stem and relations. Same input → same JSON.

What we refuse

• Bulk name generation
• Luck scores / “destined wealth”
• Treating structural relations or crosswalk flags as fate guarantees
• Pretending pure English letter-element systems are a settled standard here

Module page: Naming.

11. Company naming

Daovian Company Naming is structure analysis of a user-proposed brand (whole Chinese string + optional Chinese–English对照). It shares the personal-naming dictionary and radical_v1, but has no surname/given split and no day-stem link.

Inputs

• Mode: zh or zh_en
• Chinese brand 2–8 characters
• zh_en: Latin brand (required)
• Optional note (records only)

Upstream fork (documented)

• Dictionary / strokes / radical / pinyin: same as daovian.naming.v1 / radical_v1 / cnchar_low_v
• Method version: daovian.company_naming.v1 (whole brand string, no day stem)
• Crosswalk: bilingual token/initial semantics for brands
• Non-legal: not business registration, trademark search, or legal advice (rule.company_naming.scope.non_legal)

What the engine returns

Brand, per-character strokes/radical/element/pinyin, total strokes and char count; in zh_en, English normalize + crosswalk flags. Same input → same JSON.

What we refuse

• Luck scores / “business fortune” verdicts
• Bulk brand generation
• Trademark / registration availability claims
• Western letter-element scores

Module page: Company naming.

12. Logo Wuxing

Daovian Logo Wuxing is a public map of confirmed colors (and optional shape). You may upload a logo for browser-local palette, shape heuristics, and OCR; five-phase mapping still uses only confirmed hex/shape — not an aggregate score.

Inputs

• Optional: image upload (local daovian.logo_extract.v1 + Tesseract OCR; decode ≤512px side; animated GIF usually first frame; not stored server-side)
• Primary #RRGGBB (required)
• Secondary hex (optional)
• Shape: circle | square | triangle | line | compound | other (optional)
• Optional note (records only; OCR text may be copied in)

Upstream fork (documented)

• Method version: daovian.logo_wuxing.v1
• Upload assist: daovian.logo_extract.v1 + OCR (rule.logo_wuxing.extract.assist_v1) — suggestions require confirmation
• Color map: daovian.color_wuxing.hue_v1 (rule.logo_wuxing.color.map_hue_v1)
  • Chromatic (s≥12): fire [345,360)∪[0,30), earth [30,75), wood [75,165), metal [165,210), water [210,345)
  • Achromatic (s<12): white (L≥80)→metal, black (L≤18)→water, gray→earth
• Shape map: daovian.shape_wuxing.v1 (circle→metal, square→earth, triangle→fire, line→wood; compound/other have no single element)
• No aggregate score: rule.logo_wuxing.scope.no_aggregate_score

What the engine returns

Normalized hex, RGB/HSL, primary/secondary elements and mapping kinds; optional structural color relation and shape element. Same confirmed input → same JSON.

What we refuse

• Aggregate luck / design scores
• Treating unconfirmed vision output as verdicts
• Trademark or design-availability claims

Module page: Logo Wuxing.

13. Fengshui (Eight Mansions + Xuan Kong)

The Fengshui module offers two named methods (pick explicitly; never mixed):

1. Bazhai (daovian.bazhai.v1): facing → house gua and wandering-star labels; optional ming gua
2. Xuan Kong v2 (daovian.xuankong.v2, default): period plate + 24-mountain plates + one published substitute-star table
3. Xuan Kong v1 (daovian.xuankong.v1, optional): period plate + eight-direction Tian Yuan plates (simplified; no substitute-gua)

Neither is a construction remedy map.

Bazhai inputs

• Facing (required): eight directions n|ne|e|se|s|sw|w|nw
• Birth year + sex (optional): Gregorian year → ming gua
• Optional note (not used in calculation)

Bazhai rules

• House gua: rule.fengshui.bazhai.house_gua
• Wandering stars: rule.fengshui.bazhai.wandering_stars
• Ming gua: rule.fengshui.bazhai.ming_gua (立春; Jun 15 noon when only year given)
• Scope: rule.fengshui.scope.non_engineering

Xuan Kong inputs (v2 default)

• Facing / sitting mountain (required): 24 mountains; sitting defaults to opposite (+12), override optional
• Period 1–9 (optional pick); if omitted, inferred from build/renovate year or current year (coarse table 1884–2063; out-of-range rejected)
• Optional note (not used in calculation)

Xuan Kong inputs (v1 simplified)

• Facing (required, eight directions)
• Period / build year as above

Xuan Kong rules

• Period plate: rule.fengshui.xuankong.period_plate
• Mountain/facing: rule.fengshui.xuankong.mountain_facing
• v1 eight directions only: rule.fengshui.xuankong.eight_direction_only
• v2 24 mountains: rule.fengshui.xuankong.twenty_four_mountains
• v2 substitute stars: rule.fengshui.xuankong.substitute_stars (one published table; not universal)
• Scope: rule.fengshui.xuankong.non_engineering

Xuan Kong forward/reverse (same fork in v1 and v2)

After a star enters the center, fly direction follows that star’s Lo Shu home-palace Tian Yuan yin/yang (star 5 uses the mountain’s eight-direction palace) — same as v1.
We do not use “center-star yin/yang × per-mountain dragon yin/yang”. This published fork keeps anchors such as Period-7 午坐子向 aligned with v1; it is not claimed as universal truth.

What the engine returns

Bazhai: facing/sitting, house gua/group, wandering-star labels; optional ming tags.
Xuan Kong: period, period plate, mountain/facing plates, center stars and fly direction; v2 also includes 24-mountain names and substitute-gua flags.
Same method + inputs → same JSON.

What we refuse

• Aggregate luck / daily fengshui luck scores
• Scare copy and undocumented “universal cures”
• Floor-plan upload verdicts and construction remedy commands
• Implying other schools’ substitute tables or full 24-mountain precision (v1 has no substitute-gua; v2 uses one published table only)
• Undocumented pattern verdicts (same for Bazi / Ziwei: structure facts only)

Module page: Fengshui.

13b. Bazi decade luck / yearly (structure)

When sex is male/female, the Bazi chart also includes:

• Default four pillars from China Standard Time wall clock; optional true solar time (rule.time.true_solar.v1) requires a known hour and east longitude 70–140°
• Decades: rule.bazi.dayun.tyme_child_limit (tyme4ts ChildLimit)
• Yearly pillar: rule.bazi.liunian.year_pillar
• Scope: rule.bazi.scope.no_geju_verdict (no pattern / useful-god verdicts)

Without sex, decades are omitted. Module page: Bazi.

14. Current status

The product app is live at app.daovian.com. This page is the public method contract for what we ship: catalog modules expose recomputable structure facts with named forks and refusals. Deeper features keep the same URLs — document method and boundaries first, then ship calculation; we do not publish fake plates with an undocumented school fork.