DEV Community: David Webb

How a 60-Cycle Calendar System Works as a 60-Year Periodic Algorithm

David Webb — Thu, 01 Oct 2026 06:45:53 +0000

I started looking at BaZi, or Four Pillars of Destiny, because its output seemed oddly structured. It did not look like a paragraph of free-form symbolism. It looked like a compact record: four paired labels, each drawn from repeating sequences, with rules for translating a birth time into those labels.

As a data engineer, I’m inclined to ask what the schema is, where the boundaries sit, and what happens when the input is ambiguous. Those questions don’t prove anything about the system’s claims. They do make its calendar mechanics interesting to reverse-engineer.

A cycle built from two counters

The basic unit is a pair: one Heavenly Stem and one Earthly Branch. There are 10 stems and 12 branches. Both advance one position at a time, so the first pair returns when both counters have completed whole cycles. That takes the least common multiple of 10 and 12: 60 steps.

There’s a small combinatorics wrinkle. Ten times twelve gives 120 possible pairings if every stem could match every branch. But the traditional sequence advances both lists together, so only 60 pairings occur. Starting from Jia-Zi, the sequence proceeds Jia-Zi, Yi-Chou, Bing-Yin, and so on, until it returns to Jia-Zi.

In code, I might represent a position with an integer n:

Stem index: n mod 10
Branch index: n mod 12
Full pair: the two indexed symbols

Advance n by one to move to the next pair. Advance it by 60 and the pair is back where it started. That’s the core periodic algorithm: two clocks with different periods, sharing one step counter. (aa.usno.navy.mil)

The 60-step sequence can label years, months, days, and hours, but those are not one giant clock ticking at the same speed. Each unit has its own rule for finding the current position in the cycle. The shared encoding makes the labels comparable; the calendar conventions decide where one unit ends and the next begins.

Turning a timestamp into four pillars

A chart has four pillars: year, month, day, and hour. Each pillar is one stem-branch pair. A simplified software pipeline looks something like this:

Parse the birth timestamp, location, and time-zone context.
Convert the timestamp to the calendar’s working local time.
Determine which year and solar-term month contain it.
Find the sexagenary day index.
Divide the day into two-hour branch intervals, then derive the hour stem from the day stem.

The year pillar is not always switched at the same boundary across every convention. Many BaZi methods use the solar term Li Chun as the year boundary rather than Lunar New Year. Month pillars also follow solar terms: the year is divided into 12 solar months, with month changes anchored to particular terms. So a person born in early February may land on different year labels under different year-boundary conventions.

The day pillar is a position in its own 60-day sequence. The hour branch divides the day into 12 two-hour periods; for example, Zi is commonly associated with roughly 11 p.m. to 1 a.m. The hour stem is not an independent counter that can be looked up from clock time alone: its assignment is linked to the day stem.

This is why two implementations can accept the same date and still disagree. They may be using different boundaries, different day-rollover conventions, or different assumptions about what “local time” means. The symbolic lookup can be perfectly consistent while the input normalization differs.

Civil time is not solar time

A timestamp such as 01:30 is a statement about a clock, not directly about the Sun’s position. Civil clocks follow time-zone rules. Apparent solar time follows the Sun’s local position, which varies with longitude and with the equation of time.

The IANA Time Zone Database is useful here because it records time-zone offsets and daylight-saving transitions for named regions. But historical coverage and confidence vary, especially for dates before 1970. A location name alone is not enough; a robust input needs a date and a specific zone, and an ambiguous local time may also need its UTC offset or an explicit “first or second occurrence” marker. (iana.org)

Consider New York on November 7, 2021. At the end of daylight saving time, clocks moved from 2:00 a.m. daylight time back to 1:00 a.m. standard time. That means 01:30 occurred twice: once at UTC−4 and again at UTC−5. A timestamp containing only the city and wall-clock reading cannot distinguish those two instants. The IANA zone rules can resolve the transition once the input identifies which occurrence it means. (timeanddate.com)

If a method uses true solar time, there is another adjustment. First resolve the civil time-zone offset, including daylight saving time. Then account for longitude relative to the time zone’s standard meridian, and for the equation of time. As a rough rule, each degree of longitude corresponds to about four minutes of solar-time difference. New York is near 74° west, while Eastern Standard Time is based on a 75° west meridian, so the longitude correction is about four minutes ahead of standard clock time. The equation-of-time adjustment varies by date and can reach around 16 minutes. (aa.usno.navy.mil)

Those minutes matter most near a boundary. If the corrected time falls close to a two-hour branch change, different normalization choices could produce a different hour branch. Near a day boundary, a convention for when the sexagenary day turns over could affect the day pillar too. This is less a mystical mystery than a familiar data-quality issue: the model has edge cases, and the pipeline needs to state its assumptions.

The ten-year phase as a state machine

BaZi also describes longer luck cycles, often called decade pillars. In many methods, a sequence of these ten-year phases is derived from the month pillar. The direction of travel and the starting age depend on conventions that can involve the birth year and the distance to a nearby solar term. Each phase advances through the stem-branch sequence, with a new phase roughly every ten years.

That invites a state-machine analogy. The birth chart is the initial state; the decade pillar is a phase that changes at a calculated boundary; the current year and other calendar cycles provide additional inputs. A reader can describe the state at a given date by identifying which phase is active and which cycle labels apply.

The analogy has limits. A state machine tells us how labels change under stated rules. It does not establish that those labels cause or reliably describe events. Also, a ten-year phase is not simply “one sixth of a 60-year loop” in every practical calculation: its start and direction depend on conventions, and other calendar boundaries run alongside it.

Still, the algorithmic structure is elegant. A small number of cyclic counters, plus carefully defined transition rules, produce a compact time-based representation. The trickiest part is not the modulo arithmetic. It is agreeing on the exact instant and the calendar rules before the arithmetic begins.

Boundaries

I treat BaZi as a cultural-computational system for insight and reflection, not a tool for forecasting outcomes. The cycle math can be described and tested; that does not validate claims that chart labels determine a person’s character or life events. I make no outcome claims here. At most, the system can serve as entertainment or a prompt for decision-support conversations, with real-world decisions grounded in evidence relevant to the decision itself.

What I'm still unsure about

Which time-normalization convention is most faithful to historical BaZi practice: civil clock time, local mean solar time, or apparent solar time?
How much do different schools’ boundary rules change charts in practice, especially for births near midnight or a solar-term transition?
Can a software implementation clearly expose uncertainty in old time-zone records without making the chart interface unreadable?

Birth times are messy inputs: timezones, DST, and solar time

David Webb — Wed, 30 Sep 2026 13:45:50 +0000

Title: Birth times are messy inputs: timezones, DST, and solar time

I thought the evaluation engine would be the hard part. I was wrong; timestamp normalization took longer.

A local civil-time reading has to account for historical daylight-saving changes, sub-hour offset adjustments, and longitude corrections before it can yield true solar time. Then come the edge cases: solar-term transitions, and the competing rules that flip a calendar day at 23:00 or midnight. Either choice can change the state initializer.

Now I treat each raw birth timestamp as unvalidated input and send it through a strict timezone transformation pipeline.

When building a software pipeline for this calendar system, the input stage is deceptively complex. A timestamp such as 01:30 is a statement about a civil clock, not the Sun's position. Civil clocks follow regional time-zone rules, whereas apparent solar time depends on the Sun's actual position, shifting with longitude and the equation of time.

I rely on the IANA Time Zone Database (zoneinfo) to handle historical offsets and daylight-saving transitions (DST). But historical coverage varies in accuracy, especially for dates prior to 1970. A location name alone is insufficient. To resolve an ambiguous timestamp, you need a date, a specific zone, and an explicit UTC offset or occurrence marker.

Take New York on November 7, 2021. At the end of daylight saving time, clocks fell back from 2:00 a.m. daylight time to 1:00 a.m. standard time. That means 01:30 occurred twice: once at UTC−4 and again at UTC−5. Without an explicit occurrence marker, a wall-clock reading cannot distinguish those two instants.

If a calendar method requires true solar time, additional adjustments must be chained together. First, you resolve the civil time-zone offset and DST. Next, you apply a longitude correction relative to the zone's standard meridian. Each degree of longitude shifts solar time by roughly four minutes. New York sits near 74° west, while Eastern Standard Time is based on a 75° west meridian, placing New York about four minutes ahead of standard clock time. Finally, the equation of time must be applied, which fluctuates by date and can shift the result by up to 16 minutes.

These minutes matter most near boundaries. The hour branch divides the day into 12 two-hour intervals, such as Zi from roughly 11 p.m. to 1 a.m. Because Zi begins at 11 p.m. (23:00), some conventions flip the calendar day at 23:00, while others wait until midnight. Because the hour stem is derived from the day stem, choosing 23:00 versus midnight flips both the day pillar and the hour stem. This is why two implementations receiving the same input date can yield different charts.

I am still unsure about which time-normalization convention is most faithful to historical practice: civil clock time, local mean solar time, or apparent solar time. I also wonder how to clearly expose uncertainty in old zoneinfo records without making the chart interface unreadable—a common challenge when surfacing historical data.

Not medical, legal, or financial advice. A cultural and cognitive framework for self-reflection; outputs vary by individual.

I tried to put a 2,000-year-old calendar into one boundary rule

David Webb — Wed, 30 Sep 2026 13:45:13 +0000

Title: I tried to put a 2,000-year-old calendar into one boundary rule

I once tried to fit different traditional calendar schools into one boolean truth table. The disagreements looked like logic bugs until I saw the structural assumptions underneath.

An ancient astronomical cycle's boundary depends on which solar coordinate or epoch anchor you choose as the primary axis. Each school has a self-consistent coordinate system and its own edge definitions; one truth table can't reconcile them without flattening those differences.

Now my schema keeps core graph processing separate from boundary parsing. I made the parsing strategy configurable by calendar convention instead of baking one convention in as the absolute truth.

Early on, I expected that translating a birth time into four pillars (year, month, day, and hour) would follow a single standard. When comparing outputs across different BaZi tools, I noticed they frequently disagreed on edge cases. For instance, the year pillar boundary is not uniformly set at Lunar New Year across all schools. Many conventions anchor the year transition to the solar term Lichun instead. A person born in early February can land on completely different year labels depending on which year-boundary convention the software enforces.

Month pillars present similar branch points. The calendar divides the year into 12 solar months, anchoring month transitions to specific solar terms rather than lunar months. Meanwhile, the day pillar relies on its own 60-day position, with competing rules turning the day over at 23:00 or at midnight. Because the hour stem assignment is linked to the day stem, changing the day rollover boundary cascade-updates the hour pillar too.

Longer ten-year phases, or decade pillars, add another layer of configuration. Derived from the month pillar, their direction and starting age depend on conventions involving the birth year and the distance to a nearby solar term. Each phase advances through the stem-branch sequence every ten years. This works like a state machine where the birth chart provides the initial state and the decade pillar updates at calculated transition points, though the machine merely models label shifts under stated rules.

Attempting to hardcode all these rules into one rigid conditional block caused constant refactoring. The underlying modulo lookup is perfectly consistent; the divergence happens entirely during boundary parsing and input normalization.

To clean up the system, I refactored the pipeline. Step one parses the timestamp, location, and timezone context. Step two converts the timestamp to working local time. Step three identifies the year and solar-term month. Step four calculates the sexagenary day index. Step five divides the day into two-hour intervals and derives the hour stem.

I separated core cycle calculations from the boundary parsing rules. By keeping the schema modular and making boundary strategies configurable by calendar convention, the engine avoids declaring one school's edge definitions as universal truth.

I am still unsure how much different schools' boundary choices alter charts across large population datasets, especially for births occurring near midnight or solar-term transitions. Accepting that distinct coordinate systems exist made the code far more maintainable.

Not medical, legal, or financial advice. A cultural and cognitive framework for self-reflection; outputs vary by individual.

I found a 60-step cycle in a 2,000-year-old calendar

David Webb — Wed, 30 Sep 2026 13:45:03 +0000

Title: I found a 60-step cycle in a 2,000-year-old calendar

While parsing a sexagenary calendar record, I kept getting hung up on two counters: one wraps at 10, the other at 12, and both advance together. Their least common multiple is 60, so the pair repeats as a 60-step state machine. No fractional adjustments needed.

That fixed sequence indexes cyclical time markers across days, months, and years. I wrote it as a discrete modulo generator using integer arithmetic alone. It shows how ancient astronomers maintained a continuous, drift-free epoch reference for more than two millennia.

When I first started looking at BaZi, or Four Pillars records, I expected paragraphs of free-form symbolic prose. Instead, I found a compact record of four paired labels: year, month, day, and hour. Each pillar consists of one stem-branch pair drawn from two repeating counters. There are 10 Heavenly Stems and 12 Earthly Branches. If every stem could pair with every branch independently, you would get 120 combinations. But the traditional algorithm steps both lists simultaneously. Starting from Jia-Zi, the sequence proceeds to Yi-Chou, then Bing-Yin, and so on. Because both counters step in tandem, only 60 distinct pairings occur before the system returns to Jia-Zi.

In code, this periodic state can be represented with a single integer scalar n. The stem index is evaluated as n mod 10, and the branch index as n mod 12. Incrementing n by 1 advances to the next paired symbol, while incrementing n by 60 returns the system to its starting pair. It operates like two clocks with different period lengths sharing a single step counter.

This shared encoding makes cycle positions directly comparable across time scales, but those four pillars are not one giant clock ticking at a uniform speed. Each unit uses its own rules to find its current index. A day is divided by the hour branch into 12 two-hour intervals, such as Zi around 11 p.m. to 1 a.m. The hour stem is not an isolated counter looked up from clock time alone; its assignment is linked directly to the day stem.

Beyond the initial birth chart, the system extends into longer ten-year phases derived from the month pillar. These decade pillars advance through the stem-branch sequence every ten years. This invites a state-machine analogy where the birth chart acts as the initial state, the decade pillar changes at a calculated boundary, and current calendar cycles provide additional inputs. However, this state machine only tells us how labels transition under defined rules; it does not establish physical causation.

I am still unsure about which time-normalization convention is most faithful to historical practice: civil clock time, local mean solar time, or apparent solar time. What stands out to me as a data engineer is the structural elegance. Integer arithmetic alone maintains a periodic index without requiring floating-point adjustments.

Not medical, legal, or financial advice. A cultural and cognitive framework for self-reflection; outputs vary by individual.

I Modeled BaZi as a State Machine

David Webb — Wed, 30 Sep 2026 13:38:27 +0000

What happens when a birth time lands in the hour a solar term changes? A 30-minute error can swap an entire pillar.

I spent the past year building a computation engine for this system and reverse-engineering its rules. I don't treat it as a mystical practice. I think of it as a modeling system written in ancient language. Once I translated the terms into engineering concepts, the underlying structures started to look familiar.

The graph under the classical terms

The implementation starts with a directed graph of five nodes: Wood, Fire, Earth, Metal, and Water. Its edges have three action types:

fuels: A's energy pattern nourishes B
shapes: A's pattern constrains and molds B
drains: A's pattern draws energy out of B

Every classical rule maps onto the graph. The traditional vitality states a node can occupy are canonical network states under an external drive signal. Once the graph is in place, the rest is graph traversal.

What the ten roles do

The system defines ten archetypal roles, ten orthogonal dimensions for observing personality. I use a role matrix: for each input, every dimension gets an activation weight. In the product, we render them as interactive archetype animals because people parse the animals faster than abstract factors.

The roles describe dynamics. One may fuel or drain you, and pressure changes which one activates.

Time has two layers

Long phases: The lifespan is segmented into extended phases, each with a different dominant graph configuration.
Annual drive: Each year contributes an external input that perturbs the network.

Put together, these form what I call an energy-weather layer, a rolling state simulation over time. The weather comparison only goes so far. A forecast can say rain may be coming; packing an umbrella is your decision. The system leaves that decision alone.

The day node is the reference

The baseline activation state is the day node among the four time pillars. I measure every other node relative to it using the graph's edges. That reference frame keeps the calculation from turning into interpretive mush.

The boundary cases take the work

Most of the engineering effort went into handling boundaries.

True solar time: Clock time follows your time zone's central meridian. Solar position at the actual birthplace can differ by tens of minutes. Usually that's harmless. Near an hour when a solar term changes, a 30-minute error can swap an entire pillar.
Daylight saving: North America changed its DST rules in 2007, and the southern hemisphere shifts in the opposite direction. I delegate conversions to the platform's IANA time-zone data rather than maintaining a table by hand.
Half-hour offsets: Adelaide is UTC+9:30; Kolkata is UTC+5:30. Any conversion that assumes whole-hour offsets breaks.
Year and month boundaries: Lichun in early February sets the year boundary. Lunar New Year doesn't. Month boundaries follow solar terms, not calendar days. Two schools disagree about the day boundary at 23:00, so I exposed that choice as a config flag. It's a schema decision.

The part I'm still unsure about

My working theory is that these systems began as observation-based models, recording patterns in human behavior in its time and place, using the formal language available then. I suspect the mystical framing accumulated in later centuries. I can't establish that history from the implementation, so I keep it as a theory.

We show the computed pattern from someone's birth data. It doesn't tell them who they are.

The full derivation is documented on the AcrosStar blog.

Disclaimer: this post is not medical, legal, or financial advice. The system described is a cultural and cognitive framework for self-observation; outputs vary by individual.

Launching on Product Hunt this Tuesday — the build-in-public log of a decision tool

David Webb — Sun, 27 Sep 2026 12:10:07 +0000

Six months ago I started logging my own decisions after noticing I kept repeating the same mistakes — not from lack of information, but from never looking at how I decide. That habit became TangoEra: a quiz that maps your decision profile (how you weigh risk, how you handle trade-offs, where you stall) plus a decision log that turns your real choices into data, so the profile sharpens with every decision you record.

We're in free beta: 3 Starter report seats open every day.

Tomorrow (Wednesday) we're launching TangoEra on Product Hunt. If decision fatigue is your thing, we'd genuinely love your support — and your honest feedback.

Beta seats: https://tangoera.com/beta-tester

What decision are you procrastinating on right now?

We Built a Decision-Making Tool: 30 Days of Funnel Data

David Webb — Fri, 25 Sep 2026 16:32:22 +0000

For the last 30 days we've been building TangoEra — a decision-support tool that turns a short structured assessment into a visual "decision profile": how you weigh risk, time horizons, compensation vs. growth, and the other dimensions that actually drive your big calls.

This is the honest build-in-public report: what we shipped, what the funnel data says, and the uncomfortable lesson week one taught us.

What we built first

We went against the usual indie playbook. Instead of shipping fast and instrumenting later, we spent the early weeks on the unglamorous layer:

A 7-dimension assessment (quiz) with per-step telemetry, so we can see exactly where people drop off
A results/paywall flow with UTM-tagged sources (blog CTA, embedded quiz, result page) so every channel is separately measurable
Three lead-capture pages wired into the same event pipeline
An analytics-events worker streaming into a queryable dataset (we learned the hard way that eventually-consistent key-value lists lie to you at small volume — direct SQL on the event table is the only read we trust now)
An SEO/content layer: a decision-framework blog, Open Graph cards, hreflang for six languages

By launch-plus-one-week the engineering checklist was 79/79 green, 20 Pinterest pins were scheduled, and a 232-URL audit of the site came back clean.

Then we opened the window and measured

We gave the funnel a clean measurement window (T0 + ~28 hours of stable, fully instrumented production) and pulled the authoritative dataset directly.

External funnel events: 0.

Not near-zero. Zero. The daily event ledger confirmed it: every single event in the window traced back to our own smoke tests and probes. No quiz completions, no CTA clicks, no leads — from real visitors — in the entire window. Site UVs sat in the "hundreds per day" range on a good day, and the distribution channels we'd stood up (Pinterest, directories) hadn't produced their first outbound click yet.

The lesson: we built a product and forgot a distribution engine

Here's the part that stung. The conversion copy was fine. The instrumentation was fine. The drop-off analysis we wanted to run? Statistically impossible — you can't analyze a funnel with n = 0.

When the sample size is zero, every A/B test, every headline tweak, every paywall experiment is theater. We had optimized a machine that nothing was flowing through.

So week two got re-planned around a single sentence from our review doc: the funnel experiment is short on traffic, not copy.

What changed:

Distribution became a first-class workstream, not an afterthought — one owner, daily cadence, its own backlog
Content moved from "support docs for SEO" to an actual channel: decision-framework articles targeting long-tail queries, each with a hard CTA into the quiz
We started measuring channels individually (separate UTM sources per surface) so that when traffic does arrive, we already know which door it came through
We set explicit kill criteria: a channel that can't produce outbound clicks in 30 days gets cut, no sentiment involved

Where the data actually helped

Zero is a useful number. Because the instrumentation was solid before traffic existed, we can state the null result with confidence instead of wondering if the analytics are lying. We also caught a real bug class early — our first read of the "zero" was itself wrong (a stale list API masked 11 probe events that should have been there), which taught us to verify reads with strong-consistency queries before making decisions on them.

That meta-lesson — instrument the instrument — turned out to be worth the week by itself.

What's next

Ship the distribution backlog (channels already live: Pinterest, startup directories, guest posts on decision-making content)
Re-open the funnel window with the same rigor once inbound traffic crosses a threshold where numbers mean something
Publish the week-2 review the same way: real data, no varnish

If you're building something too and you've also stared at a dashboard full of zeros — you're not behind, you're just at the step most people skip over. The fix isn't more features. It's more doors.

Follow along — we're posting these reviews weekly. And if decision-making content is your thing, the TangoEra quiz is free: three questions, one visual decision profile.

Building an AI Tarot Decision Engine: Turning Seven Dimensions into Structured Reports

David Webb — Tue, 15 Sep 2026 12:39:58 +0000

Some weeks, I ship everything on my list. Other weeks, I stare at a half-written email for two hours and call it a day. I used to blame focus, sleep, or motivation—until I started treating my decisions as data instead of feelings.
That habit became a product: an AI-assisted decision report engine that presents structured analysis as a tarot-style reading. This post is about the model underneath—no mysticism required—and what building it taught me.

The observation

For years, whenever I faced a decision I was avoiding, I’d pull tarot cards. Not to predict the future, but because a spread forces you to look at a situation from angles you’d rather skip. Positions like “what you fear” or “what you refuse to see” are basically ready-made journal prompts.
I realized I kept asking the same seven questions. So I wrote them down, scored them, and mapped them onto continuous dimensions.

The seven dimensions

Every decision report reduces the situation to seven indices on a 0–100 scale. In practice, they’re calibrated to an observed 12–88 band, because humans rarely live at the extremes:
| Dim | Name | What it measures |
|---|---|---|
| R | Risk appetite | tolerance for irreversible downside |
| I | Intuitive synthesis | how much you trust pattern-recognition vs. explicit reasoning |
| P | Temporal patience | willingness to wait for compounding |
| S | Social dynamic | how much alignment/consensus you need |
| A | Action bias | commit-fast vs. deliberate |
| Rf | Reflection depth | tendency to re-analyze |
| St | Stability | preference for known structures over flux |
A quiz (about 3 minutes) scores the question, not the person. The result is a seven-dimension radar, plus the two or three tensions hiding inside it. For example, high reflection and low action under load reads as “decision fatigue wearing a costume.”

Archetypes as geometry

Ten recurring vectors emerged from the calibration data. Each is just a shape across the seven axes:
| Archetype | R | I | P | S | A | Rf | St | Failure mode |
|---|---|---|---|---|---|---|---|---|
| Alchemist | 66 | 22 | 58 | 30 | 64 | 44 | 34 | solitary conviction without alignment |
| Sage | 40 | 78 | 74 | 52 | 20 | 72 | 56 | over-analysis; missed asymmetric upside |
| Challenger | 76 | 40 | 28 | 44 | 84 | 30 | 32 | hyperactive interference; burn rate |
| Builder | 44 | 62 | 74 | 52 | 50 | 58 | 76 | rigidity past optimal pivot points |
| Creator | 60 | 30 | 30 | 42 | 76 | 30 | 28 | draft overload; consolidation lag |
| Opportunist | 74 | 50 | 34 | 46 | 72 | 34 | 30 | shallow commitment; option chasing |
| Architect | 38 | 78 | 76 | 50 | 58 | 74 | 76 | inelasticity in fast-changing terrain |
| Leader | 56 | 56 | 64 | 82 | 72 | 52 | 64 | high consensus load; diluted velocity |
| Maverick | 76 | 40 | 30 | 22 | 78 | 30 | 26 | key-person isolation |
| Competitor | 70 | 50 | 40 | 58 | 78 | 40 | 48 | scoreboard fixation |
These aren’t personality verdicts; they’re operating modes. The same person can switch vectors depending on the domain—work, relationships, or money.

Engineering notes

Quiz-gated queue. The free beta allows 3 readings/day, with the quiz as a gate so the queue stays human-scale and bots can’t burn the LLM budget.
The LLM does framing, not fortune-telling. It turns the scored dimensions into tensions and next steps; the tarot layer is a presentation skin over a structured report.
Honest statistics. The birth-timestamp mapping that seeds the archetype guess has a weak statistical correlation. The product says so in the UI and in the copy. Users trust it more, not less, for that.
Naming is the intervention. The most common feedback is: “I froze less once the pattern had a name.” A labeled failure mode is fixable; unnamed anxiety isn’t. ## What I’d do differently
Ship the radar before the tarot skin. The mystical frame is great for reach, but retention comes from the structured report.
Score the question first, person second. Question-scoring generalizes; profiling feels invasive.
Ship with the disclosure. Every A/B test said honesty converts better than mystique. If you’re stuck in a decision loop, try tracking one dimension—risk or action—for a week. Naming the pattern is half the fix. --- I’m building this in public—the engine is in free beta (tangoera.com), and the longer build log lives on Indie Hackers. Happy to answer questions about the calibration data or quiz design.  tokens used

Building an AI Tarot Decision Engine: Why I Used Tarot as a Framing Layer (and What the 7-Dimension Radar Actually Models)

David Webb — Tue, 15 Sep 2026 12:39:10 +0000

A few months ago I caught myself doing the thing every solo founder does: re-reading the same pros-and-cons list for the fourth time, hoping the answer would change. I wasn't lacking information. I was stuck in a loop — re-analyzing instead of committing.

That loop is what I ended up building a product around. TangoEra is an AI-powered decision report tool, currently in a free beta. This post is the engineering story: why tarot, what the engine actually computes, and the mistakes I made along the way.

Why tarot is a framing layer, not a prediction layer

The obvious objection: "AI tarot? So it predicts the future?" No — and this distinction is the whole design.

Tarot survived for centuries not because it predicts outcomes, but because a card spread is a forced perspective machine. The Fool, the Tower, the Two of Swords — each card is a lens that drags your thinking onto an axis you were avoiding. When you draw "restraint" on a day you're fired up to quit your job, the value isn't mystical. It's a structured interruption of your default narrative.

So the product framing is: the AI generates an archetype profile and a decision report, and the tarot visual layer is the interface that makes people slow down and actually read the analysis instead of skimming bullet points. The cards are UI, not oracle. Every report carries the honest disclaimer: this is a self-reflection and decision-support tool based on statistical weak correlation, not prediction, not advice.

I think of it as putting a decision matrix inside a story people will finish.

The engine: archetype vectors, not a black box LLM

Under the hood there are two layers.

Layer 1 — the calibration engine. We model each user's decision style as a vector over seven continuous dimensions: risk appetite, intuitive synthesis, temporal patience, social dynamic, action bias, reflection depth, and stability. Scores live on a 0–100 index, but real profiles only occupy an observed 12–88 band, which matters for normalization.

We maintain 10 prototype archetype vectors — the Alchemist, the Sage, the Challenger, the Builder, the Architect, the Maverick, and so on. Each archetype is a distinct geometric shape across the seven dimensions, with an operational strength and a primary failure mode. The Sage scores high on reflection and patience, low on action bias — brilliant at verification, prone to missing asymmetric upside through over-analysis. The Challenger is the mirror image. When a user's quiz answers come in, we project them onto this prototype space (nearest-shape matching with soft membership, not hard classification) rather than asking an LLM to freestyle a personality type. That keeps output stable, testable, and cheap to regression-test.

Layer 2 — the report radar. The seven dimensions the user sees in their report are translated into decision-facing axes: clarity, risk appetite, timing, relationships, resources, blind spots, and next move. This is where the tarot cards bind to computed values — a card is selected because a dimension score (plus its distance from the archetype's own baseline) triggers it, not at random.

The tension rendering is the part I'm proudest of. A report that says "you're high risk, high reflection" is useless. A report that says "your reflection score is 38 points above your action score — that gap is your frozen-week pattern, and here is the specific next step sized to close it" is a tool. Reports render two sections: tensions (pairs of dimensions that are far apart and therefore in internal conflict) and next steps (one concrete, low-commitment action per tension). One next step, not five. Choice overload is the disease; a report with five action items is just more of it.

This borrows directly from the decision-matrix tradition (Stuart Pugh's concept-selection matrices): score dimensions, weight by importance, let arithmetic surface structure instead of opinions. Our quiz is essentially a weighted scoring instrument wearing a tarot costume.

The 3-minute quiz as a queue gate

The quiz exists for two reasons. First, calibration: we need ~20 weighted answers to place you in the seven-dimensional space with enough confidence that the radar isn't noise. Second — and this is a product decision, not a technical one — it gates the daily report queue.

We generate a limited number of full AI-written reports per day, with a daily 3 seats for the free beta. The quiz is the gate: it filters out drive-by traffic and makes sure every generated report gets a human who actually engaged with their inputs. As a solo dev, this isn't artificial scarcity — it's capacity management. Each report is reviewed for template drift, and human-scale volume is the only way I can catch the LLM quietly going off-script. If you've ever run a generative feature unattended, you know the failure mode: output slowly drifts and nobody notices for weeks.

Honest limitations

The birth-timestamp-to-dimension mapping is a weak statistical correlation, not science. It's a vocabulary generator, not a verdict. I'm upfront about this in-product.
Quiz self-reporting has all the usual biases. People answer who they want to be on Monday morning.
The report is a mirror. If a user wants certainty, no tool sells that honestly.

Solo-dev lessons

Constrain the LLM with geometry. Let the model write prose inside a computed skeleton (archetype vectors, tension pairs, threshold rules), never invent the skeleton. Testability went from "vibes" to unit tests on vectors.
Human-scale queues are a feature. A daily cap forces review loops, which catch drift, which builds trust.
Own the weird framing. Tarot gets attention that "decision support SaaS" never would, and the card constraint genuinely improves the writing — forced metaphors beat blank pages.

If you're building something similar, steal the pattern: compute hard, narrate softly, and always label the correlation honestly.

Try the free beta: https://tangoera.com/?utm_source=devto