DEV Community: FateShow

Designing a Birth-Time Form That Does Not Invent an Astrology Chart

FateShow — Wed, 04 Nov 2026 13:31:20 +0000

A birth-chart form appears to need only three inputs: date, time, and place. But those fields contain several decisions that can change the result. If the interface hides those decisions, it can produce a confident-looking chart from an incorrectly interpreted birth record.

Keep the local time and the place together

“04:10” is a clock reading, not a universal timestamp. The same instant may appear as 04:10 in Jakarta and 05:10 in Singapore. If someone was born in Jakarta, they should be able to enter the time recorded there and select Jakarta as the birthplace. The application should handle the time-zone conversion.

Asking users to convert their birth time to another city first creates an easy mistake: they may enter the converted time while still selecting their original birthplace, causing the application to convert it again.

A useful data model keeps the original local date and time, the birthplace, and the resolved time zone separate. That also makes it possible to show users which assumptions were used.

Use the rules from the birth date

A place's current UTC offset may not be the offset it used decades ago. Daylight saving rules have changed, sometimes more than once. A birth-chart calculator needs the time-zone rules that applied at the birthplace on the birth date.

The interface should also handle uncertainty honestly. If a historical local time cannot be resolved unambiguously, ask for clarification or show the uncertainty. Silently choosing an offset makes the chart look more certain than the input allows.

Unknown is a valid input state

Many people do not know their birth hour. Replacing a blank field with noon or midnight may make a form easier to process, but it changes the chart.

For BaZi, the year, month, and day pillars can still be shown while the hour pillar remains unknown. For Zi Wei Dou Shu, the missing hour affects the palace layout more substantially. In either case, the UI should explain what can be calculated and leave the rest unresolved.

Make calendar boundaries visible

Time zones are only one source of disagreement between calculators. In BaZi, the year pillar changes at Li Chun, around the beginning of February, rather than on January 1 or necessarily on Lunar New Year. The month pillar follows solar terms.

For a birth close to one of these boundaries, a short note beside the result can explain which rule the calculator used. That is more useful than presenting two different charts as though one must be a software error.

We apply these principles in the fatequery BaZi calculator: the chart is calculated from the birth details first, and an AI-assisted reading explains the chart shown on screen. A follow-up question does not need to generate a new chart.

The broader design lesson applies beyond astrology. When an application turns local time into a rule-based result, preserve the original input, expose consequential assumptions, and allow unknown information to remain unknown.

Cast the BaZi chart in code, then let the model read it

FateShow — Wed, 28 Oct 2026 12:04:08 +0000

Ask a chat model for a BaZi chart twice. Change nothing but the wording of the question, and you often get two different sets of pillars. The model is writing a chart the way it writes a paragraph. A chart is a function of a date, a clock time, and a place. Run it again with the same arguments and the characters should match.

The model never receives a blank chart

On the BaZi calculator, the order is fixed.

Take the birth date, the clock time, and the birthplace.
Restore that clock time with the timezone that place was using that day, daylight saving included. Mainland China is UTC+8 in most years. In the summers of 1986 through 1991 it was UTC+9. Using today's offset for a 1988 birth moves the hour pillar.
Cut that instant into four pillars. The year changes at Start of Spring, not on 1 January. The month follows the solar terms, not the Gregorian month and not the lunar month. The day pillar on this page flips at 23:00, not at midnight.
Only then does the model see the page. It may explain the Day Master, the Ten Gods, and the ten-year cycle already printed. It does not rewrite a stem because the question sounded urgent.

Zi Wei is the same contract with a different table. The same instant goes in. Stars and palaces come out. The model explains those fields. A follow-up such as "what about my job?" stays on that chart. It does not recast the hour.

The page is a Next.js app. The Zi Wei placement uses iztro. The chart object is produced before any prompt is sent.


js
function castBazi({ date, time, place }) {
  const instant = restoreHistoricalTimezone(date, time, place); // DST included
  return fourPillars(instant); // the model may only describe this object
}

Why FateShow Calculates the Chart Before Asking a Model to Explain It

FateShow — Fri, 16 Oct 2026 08:41:41 +0000

Most AI astrology products start with a prompt. Birth data, a place, and a question go to the model, which is asked to cast the chart, judge it, and write the report in one pass.

FateShow runs the other way. A deterministic engine casts the chart, the result is reduced to structured evidence, and the model only explains that evidence. If the explanation does not match the chart, the page returns the rule reading already computed from it.

What prompt-first generation gets wrong

Language models should not calculate calendars or planetary positions. The same input can yield different pillars, houses, or line values. Fluent prose hides the miss. Regenerating the report can change the claims underneath it.

One case showed up in our own pipeline. On the English report path the chart carried four palaces, and the model sometimes returned interpretations for only two. Asking it to fill the gap would have meant invented stars for the palaces it skipped. The missing slots are filled from the rule reading at the same index. The palace set stays as calculated. No star is added.

A second class of error sits entirely in the calculation. Converting a lunar date requires an explicit leap-month flag. Drop it, and a leap fifth month is treated as an ordinary fifth month. The month pillar is wrong, and every pillar after it follows. A model should not be asked to smooth that over.

Calculate first

A Zi Wei reading runs in this order:

Validate birth data, calendar, time zone, true-solar-time switch, day boundary, and the question.
Run the deterministic chart engine.
Reduce the chart to evidence: palaces, major stars, auxiliary stars, transformations, and rule verdicts that already have ids.
Give the model only that packet. The prompt states how many evidence rows exist, requires palace names to be copied as given, and limits timing claims to rules already present.
Validate the JSON. Drop palaces that are not in the input. Drop facts that are not in that palace’s star list. Drop rule ids the rule layer did not emit. Backfill missing palaces from the rule reading at the original index. Reject the report if the summary, the evidence, or the actions are empty.
On rejection, timeout, or provider error, return the rule reading and release the reserved credit. The same input hits a thirty-minute cache, so a retry does not silently replace the wording. Simplified and Traditional Chinese never share a cache key.

Liu Yao freezes the facts earlier. The server stores the six line values when the chart is cast. Reloading that id does not recast. Interpretation receives the finished Najia chart. The model must cite at least two strings that appear in the chart text. If the citations miss, the call times out, or no key is configured, the page still shows the rule reading.

This is the production shape, shortened:

async function readChart(input) {
  const chart = await createChart(input);          // deterministic engine
  const packet = toEvidence(chart);                // 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' };
  }
}

BaZi is assembled the same way. A shared birth model restores the civil time, applies true solar time when that switch is on, builds the four pillars, then runs the analysis layer on that same chart.

What the split is for

Chart facts are reproducible. The year boundary at Start of Spring, the day boundary at 23:00 or 00:00, the two-hour branches, and the true-solar-time switch decide the pillars. Those switches stay on the chart. When two charts disagree, compare the switches before comparing the prose.

Debugging has a seam. A wrong star is an engine or calendar bug. An empty sentence, a palace that does not match, or a rule id that was never emitted is an interpretation bug. Retrying the model does not move a pillar, a palace, or a line.

Tests split the same way. Chart tests assert fields for a fixed input. Interpretation tests use a fixture packet and check that extra stars are stripped, missing palaces are backfilled, and an empty summary is rejected.

The model is replaceable. DeepSeek or another provider receives the same evidence. If the provider times out, the user still sees the rule reading of this chart.

Several systems, no shared calculator

The site casts BaZi, Zi Wei Dou Shu, Western astrology, Vedic astrology, Human Design, numerology, Liu Yao, Plum Blossom, Qi Men, and Lenormand. They share input validation, time-zone resolution, and a report contract of “evidence in, prose out.” They do not share a calculation model.

The shared layer is the birth record, historical time zones and daylight saving, solar terms, stems and branches, and true solar time. BaZi, Zi Wei, and Western astrology sit side by side. A domain does not call another domain. When a combined reading is needed, a layer above joins two finished charts.

What stays specific:

System	How time is used	What the engine emits
BaZi	Start of Spring, solar-term months, day boundary, optional true solar time	Pillars, ten gods, hidden stems, strength and pattern
Zi Wei	Year boundary and leap month set the Life Palace; true solar time can move a palace	Twelve palaces, stars, transformations, decade spans
Western / Vedic / Human Design	Civil time restored to UT; no true solar time	Planets and houses, sidereal positions and dasha, or gates and type
Numerology	Gregorian date only	Number layers
Liu Yao / Plum Blossom / Qi Men	The question clock, frozen at submit; not a birth time	Line values and Najia, body and use, or duty star and duty door

Numerology should not require a birthplace. Western charts should not inherit a 23:00 Chinese day boundary. Liu Yao’s month and day come from the moment of the question. Folding all of that into one generic chart JSON leaves fields that mean nothing in some systems, and the model fills them with vocabulary from another system.

Three changes that came from failures

The engine and the analysis layer did not share a key language. The BaZi engine emitted English keys. The analysis layer read Chinese keys. Both sides looked implemented, and every analysis field was empty. The fix is one shape conversion in the assembly layer, so both layers read the same chart.

A Chinese character budget was applied to English. The summary cap was about 500 characters. One hundred English words are closer to 600 characters, so sentences were cut mid-phrase. The cap was raised enough to hold a full English sentence, and the Chinese and English length rules are written separately.

Palace names were matched exactly. The input said soul; the model returned Soul or another translation, and the whole evidence row disappeared. Matching now ignores case and maps translations back through the glossary. Backfill uses the original index, so the facts are not paired by name a second time.

The Liu Yao demo has a separate constraint. The Najia library’s license does not belong in the main site bundle, and an in-memory cast disappears when the process restarts. The site keeps the same rule — freeze the lines, then explain them — and integrates that step on its own.

What transfers

When generated prose has to stay tied to a source, finish the source first, store it, and hand the model only the evidence it is allowed to cite. When validation fails, return that source. Do not ask the model to patch the hole.

The same constraint shows up in finance, legal research, health information, and education. The model’s job is to say what the facts already are. Calculation, retrieval, and rules are what make the facts hold.

FateShow uses that order for natal charts, synastry, and divination: fateshow.site.