[KongchangAI]
· 4 min read· 2,296 words

Why FateShow Computes the Chart Before Letting AI Interpret It: Decoupling Evidence from Generation

Why FateShow Computes the Chart Before Letting AI Interpret It: Decoupling Evidence from Generation

FateShow separates chart computation from interpretation: a deterministic engine casts the chart and compresses it into structured evidence, and the model only interprets it, falling back to rule results on failure.

FateShow uses a 'compute first, explain later' architecture in which a deterministic engine completes chart casting and compresses results into structured, id-tagged evidence, while the model only interprets without participating in computation — eliminating AI hallucinations in calendars, planetary positions, and star derivations. Strict validation discards palaces not in the input, backfills missing ones by original index, and rejects empty summaries, always falling back to rule-based readings on failure. Multiple divination systems share input validation and report contracts but not computation models. Three real failures drove engineering fixes. This approach transfers to finance, law, and health.

Most AI astrology products work like this: the user submits birth data, location, and a question, and the model handles chart casting, judgment, and report writing all in one pass. FateShow does the opposite — it first uses a deterministic engine to compute the chart, compresses the result into structured evidence, and the model only interprets that evidence. If the interpretation doesn't match the chart, the page falls back to the already-computed rule-based reading.

FateShow's product logic: compute the chart first, interpret second

What's Wrong with Prompt-First Generation

Language models should not be asked to compute calendars or planetary positions. The same input can produce different Four Pillars, palace assignments, or line values, and fluent prose conveniently hides that drift. Regenerate a report once, and the underlying conclusions may have quietly changed.

FateShow observed a real case in its own pipeline: on the English report path, the chart contained four palaces, but the model sometimes returned readings for only two. If you then ask the model to "fill in" the rest, you're effectively asking it to fabricate stars for the palaces it skipped. FateShow's approach is to backfill missing palaces from the rule-based reading by original index — the palace set stays exactly as computed, with no star added.

Another class of errors lives entirely at the computation layer. Converting a lunar date requires an explicit leap-month flag. Drop that flag and a leap fifth month is treated as an ordinary fifth month, the month pillar goes wrong, and every pillar after it follows. This is not something the model should be asked to "smooth over."

True solar time is the conversion of clock time into the moment the sun actually crosses the meridian. Earth's orbit is elliptical and its axis is tilted, so within the same time zone, locations at different longitudes see the sun reach noon at different moments. A birthplace on the western side of a time zone usually has true solar time later than civil time; on the eastern side, earlier. In China, the country spans roughly five time zones' worth of width but uses Beijing time uniformly, so the offset can reach one to two hours — enough to shift the hour boundary or even the day boundary, which in turn affects the Four Pillars or the Zi Wei life palace. Whether to enable this switch is therefore an input parameter that must be explicitly recorded on the chart, not a detail to be left to the model's guesswork.

Leap month is a compensatory month in the lunisolar calendar used to reconcile the difference between synodic months and the tropical year. A lunar synodic month is about 29.53 days, so twelve months total only about 354 days — roughly 11 days short of the tropical year, which would cause the seasons to drift within a few years. The intercalation rule is roughly seven leap months in nineteen years, and which specific month becomes the leap month is determined by the position of solar terms. A leap month is prefixed with "闰" (leap) before its month name, such as leap fifth month, and is a month independent of the ordinary fifth month. Chart casting must explicitly carry the leap-month flag, or the month pillar and every subsequent pillar will fail in a chain.

Computation First: A Strict Production Pipeline

Zi Wei Dou Shu readings execute in the following order:

  1. Validate birth data, calendar, time zone, true solar time switch, day boundary, and the question asked.
  2. Run the deterministic chart-casting engine.
  3. Compress the chart into evidence: palaces, main stars, auxiliary stars, Four Transformations, and rule judgments already tagged with ids.
  4. Hand only this evidence packet to the model. The prompt declares the number of evidence lines, requires palace names to be copied verbatim, and restricts temporal claims to existing rules.
  5. Validate the JSON. Discard palaces not present in the input, discard facts not belonging to that palace's star list, discard rule ids not emitted by the rule layer. Backfill missing palaces from the rule-based reading by original index. If the summary, evidence, or action recommendations are empty, reject outright.
  6. On rejection, timeout, or provider error, return the rule-based reading and release the reserved quota. The same input hits a thirty-minute cache, and retries never silently swap wording. Simplified and Traditional Chinese never share a cache key.

Liu Yao freezes facts even earlier: the server stores the six line values at the moment of casting, and reloading that id does not recast. The interpretation step receives an already-completed Na Jia chart. The model must cite at least two strings that appear in the hexagram text. If the citation doesn't match, the call times out, or no key is configured, the page still shows the rule-based reading.

The core logic can be simplified like this:

async function readChart(input) {
  const chart = await createChart(input);          // deterministic engine
  const packet = toEvidence(chart);                // keep only citable facts
  try {
    const raw = await model.explain(packet);
    const report = normalize(raw, packet);          // palaces, stars, rule ids must match
    return { report, source: 'ai' };
  } catch {
    return { report: ruleReport(packet), source: 'rules' };
  }
}

Ba Zi is assembled the same way: a shared birth model first reconstructs civil time, applies true solar time when the switch is on, builds the Four Pillars, and then runs the analysis layer on the same chart.

Four Transformations (Si Hua) are a set of star-energy transformation rules in Zi Wei Dou Shu determined by the birth-year heavenly stem, manifesting as four markers — Hua Lu, Hua Quan, Hua Ke, and Hua Ji — attached to specific main stars, altering their nature and direction of effect. Because the Four Transformations are derived entirely from the birth-year heavenly stem, they are deterministic: once the stem is fixed, the transformation combination is fixed.

Na Jia is the method in Liu Yao divination of assigning heavenly stems and earthly branches to each line of the sixty-four hexagrams, so that every line carries a Five Elements attribute and a stem-branch coordinate, allowing judgments of fortune based on the generating-and-overcoming relationships of the Five Elements. The Na Jia chart is a complete structure generated in one pass after casting; the correspondence between line values and stem-branch is frozen at the instant of casting, and subsequent interpretation is merely textual explanation of that established fact.

The true solar time switch and the day boundary are two independent boundary parameters in Ba Zi chart casting. The day boundary determines whether a day starts at 23:00 or 00:00, directly affecting day-pillar assignment; the true solar time switch determines whether longitude correction is applied to civil time. Both can cause the same birth data to fall into different pillars or palaces, so they must be stored as explicit fields on the chart, making it possible to compare parameters before comparing prose when discrepancies arise.

Practical Benefits of Splitting the Engine from the Interpretation Layer

Chart facts are reproducible. The year boundary determined by Li Chun, the day boundary determined by 23:00 or 00:00, the two-hour hour blocks, and the true solar time switch together determine the Four Pillars. These switches are preserved on the chart. When two charts disagree, compare the switches first, then the prose.

Debugging thereby has a clean seam. Wrong stars mean a bug in the engine or the calendar; hollow sentences, mismatched palaces, or rule ids that were never emitted mean a bug in the interpretation layer. Retrying the model won't move a single pillar, palace, or line value.

Testing splits the same way. Chart tests assert fields against fixed inputs; interpretation tests use a fixed evidence packet to check whether extra stars are stripped, missing palaces are backfilled, and empty summaries are rejected.

The model is replaceable. DeepSeekAd or any other provider receives the same evidence. If the provider times out, the user still sees the rule-based reading for that chart.

Multiple Systems, No Shared Calculator

FateShow covers Ba Zi, Zi Wei Dou Shu, Western astrology, Vedic astrology, Human Design, numerology, Liu Yao, Mei Hua Yi Shu, Qi Men Dun Jia, and Lenormand. They share input validation, time zone resolution, and the "evidence in, prose out" report contract — but they do not share computation models.

The shared layer is birth records, historical time zones and daylight saving time, solar terms, heavenly stems and earthly branches, and true solar time. Ba Zi, Zi Wei, and Western astrology are laid out side by side; one domain does not call another. When combined readings are needed, an upper layer stitches together two already-completed charts.

The differences among systems are as follows:

SystemHow time is usedWhat the engine outputs
Ba ZiLi Chun, solar-term months, day boundary, optional true solar timeFour Pillars, Ten Gods, hidden stems, strength and structure
Zi WeiYear boundary and leap month determine the life palace; true solar time may shift palacesTwelve palaces, stars, Four Transformations, major limits
Western/Vedic/Human DesignCivil time reconstructed to universal time; no true solar timePlanets and houses, sidereal positions and dashas, or gates and types
NumerologyUses only the Gregorian dateNumber hierarchy
Liu Yao/Mei Hua/Qi MenThe moment of asking, frozen at submission; not birth timeLine values and Na Jia, body-and-function, or duty symbols and envoys

Numerology should not require a birthplace, a Western chart should not inherit the Chinese 23:00 day boundary, and Liu Yao's month and day come from the moment of asking. Cramming all of this into one generic chart JSON leaves fields that are meaningless in some systems, and the model will fill them with vocabulary from another system.

Human Design synthesizes Western astrology's planetary positions, the I Ching's sixty-four hexagrams, the Kabbalistic Tree of Life, and the chakra system. It maps the ecliptic longitude of planets at the birth moment into "gates" and "lines," forming a network of energy centers and channels. Its time handling is close to Western astrology: civil time is reconstructed to universal time before planetary positions are computed, with no involvement of true solar time or lunar leap months.

Vedic astrology uses the sidereal zodiac, which differs from Western astrology's tropical zodiac by about 24 degrees of precession, so the same moment's planetary house placements can differ. Its dasha system (Vimshottari Dasha) divides time by planetary periods, with scales precise down to year, month, and day.

Qi Men Dun Jia constructs a nine-palace chart from the stem-branch of the moment of asking, including dynamic symbols such as duty symbols and envoys. It is a time-sensitive divination method unrelated to birth time. Lenormand uses a fixed deck and spread positions, with even lower time involvement. The systems' dependence on time varies enormously, and sharing a single time model would inevitably introduce errors.

Three Corrections Bought by Three Failures

The engine and the analysis layer didn't share the same key names. The Ba Zi engine output English keys, the analysis layer read Chinese keys. Both sides looked implemented, but every analysis field ended up empty. The fix was a shape conversion at the assembly layer so both layers read the same chart.

A Chinese character budget was applied to English. The summary limit was about 500 characters, while 100 English words approach 600 characters, so sentences were truncated mid-way. The limit was raised enough to accommodate a complete English sentence, and length rules for Chinese and English were written separately.

Palace names were handled by exact match. The input said soul, the model returned Soul or another translation, and the entire evidence line vanished. Matching now ignores case and maps translations back via a glossary. Backfilling uses original indices, so facts are not re-paired by name.

The Liu Yao demo had one additional constraint: the Na Jia library's license was not suitable for bundling into the main site, and in-memory casting would disappear on process restart. The site kept the same principle — freeze the line values, then interpret — and integrated that step at its own layer.

Where This Approach Can Transfer

When generated text must be bound to a source, complete the source first, store the source, and then hand the model only the evidence it is allowed to cite. On validation failure, return the source itself — don't let the model patch the hole.

The same constraint appears in finance, legal retrieval, health information, and education. The model's job is to articulate what the facts already are, while computation, retrieval, and rules are what make the facts stand up. This is the order FateShow uses across charts, compatibility readings, and divination.

One-line Summary

FateShow separates chart computation from interpretation: a deterministic engine casts the chart and compresses it into structured evidence, and the model only interprets it, falling back to rule results on failure.

Paragraph Summary

FateShow uses a "compute first, explain later" architecture: a deterministic engine completes the chart casting and compresses results into structured evidence with ids, and the model interprets only the evidence without participating in computation, eliminating AI hallucinations in calendars, planetary positions, and star derivations at the root. The pipeline includes strict validation: discarding palaces not in the input, backfilling missing palaces by original index, rejecting empty summaries, and returning rule-based readings on any failure. Multiple divination systems share input validation and report contracts but not computation models, avoiding cross-system vocabulary contamination from generic JSON. Three real failures drove engineering fixes: inconsistent key names, a Chinese character budget misapplied to English, and excessively strict exact matching of palace names. This approach can transfer to finance, law, health, and other domains with high demands for factual accuracy.

#FateShow#AI hallucination prevention#deterministic chart engine#evidence-generation decoupling#Ba Zi#Zi Wei Dou Shu#structured evidence#AI astrology#LLM validation pipeline
Share:

Related articles