The most important AstroAI decision was also the least flashy: the language model does not calculate the birth chart.
AstroAI is the product work behind Astrology Insights. A user provides a birth date, time, and place. A deterministic ephemeris engine calculates the planetary positions, houses, angles, and aspects. Only then does an AI model receive the structured chart and turn it into a readable interpretation.
That boundary matters. A model can write a beautiful paragraph with the wrong Moon sign just as confidently as it can write one with the right sign. If the prose sounds authoritative, most people will not know which parts came from a calculation and which parts came from probabilistic text generation. I did not want the product to hide that distinction.
This is what “not AI slop” means to me: use software that can be checked for facts, use AI where interpretation is genuinely useful, and make the handoff visible enough that a user can understand what happened.
The Calculated Layer Comes First
A birth chart starts with astronomy, even if its interpretation belongs to astrology. Time and location determine coordinates, time zone, and the positions used to construct the chart. Those inputs are unforgiving. A plausible-looking approximation is still wrong.
AstroAI therefore treats chart generation like any other calculation-heavy feature:
- Normalize and validate the birth details.
- Resolve the location needed for the calculation.
- Compute the chart with a deterministic ephemeris.
- Store the resulting placements and aspects as structured data.
- Generate an interpretation from that computed result.
The public Birth Data Promise explains that the primary chart calculation runs on the product's own servers. It also describes the limited fallback path if that engine cannot produce a result. That is not marketing garnish. It is part of the interface contract: users should know which service does what and which data crosses each boundary.
There is another honesty requirement here. Deterministic chart calculation does not make astrology a scientific diagnosis or prediction system. It means the product faithfully calculates the symbolic chart it says it calculates. The interpretation should be framed as reflection and exploration, not objective certainty about a person's future.
AI Should Explain, Not Pretend
Once the chart exists, a language model is useful. A list of placements is technically complete but hard to synthesize. The model can connect themes across the Sun, Moon, rising sign, houses, and aspects in prose that feels coherent.
The model still needs constraints. I want an interpretation to:
- stay grounded in the placements it was given;
- distinguish a chart fact from an interpretive statement;
- use ordinary language before specialist vocabulary;
- avoid deterministic claims about health, money, relationships, or fate;
- admit when birth-time uncertainty changes a time-sensitive placement; and
- remain useful when a model call fails or produces an incomplete response.
That last point is easy to skip. Graceful failure is part of trustworthy AI. A calculated chart should not disappear because an interpretation provider is slow. A saved reading should not be regenerated on every page load. The product should preserve the durable result and isolate the probabilistic dependency.
Consent Has to Happen Before the Magic
Birth data is unusually identifying. A precise date, time, and place can feel intimate even before a user adds a name, conversation history, or notes. Treating that information like a generic form submission would be a product failure.
The current experience puts consent and explanation at the point where the data is requested. It links the plain-language promise alongside the full privacy policy and terms. The promise states what the product does not do, names the categories of services involved, and explains what each service receives.
The shipped controls follow the same idea:
- charts and related material are private by default;
- sharing requires a deliberate action and can be reversed;
- users can inspect what the product remembers;
- readings can be taken out of the product; and
- account deletion is available with retention exceptions explained rather than buried.
These controls are more convincing than a vague “we value your privacy” sentence because a user can verify them in the interface.
Plain Language Is a Technical Feature
Astrology has a large vocabulary: ascendants, houses, aspects, nodes, transits, and synastry. Using those words without explanation makes a product feel precise while leaving a new user behind.
I treated comprehension as part of correctness. The interface introduces terms where they matter, offers definitions without forcing a detour, and explains why exact birth time changes certain placements. The goal is not to remove the domain language. It is to let someone learn it without being punished for starting from zero.
The same rule applies to privacy copy. “Processor,” “retention,” and “legal basis” have precise uses, but a user first wants answers to simpler questions: Who gets my data? What do they get? Can I share a chart without sharing my conversations? Can I delete it?
A plain-language promise can answer those questions, while the legal policy remains available for the full detail. Both layers matter.
Evidence-Backed UX, Not Vibes
Trust is not established because I intended to build a trustworthy product. It is established when the rendered behavior matches the promise.
That means testing the actual path a user follows: labels, required fields, validation errors, consent state, keyboard access, loading behavior, sharing controls, and deletion paths. It also means reviewing the exact page produced by the commit that will ship. A screenshot from a nearby branch or an old local server is not evidence of the current product.
Some of this work is shipped today: deterministic chart computation, structured interpretations, plain-language data disclosures, private-by-default sharing, and user-facing data controls are all represented in the public product. Other work is continuous. Prompts need regression checks. Provider terms need re-verification. Explanations need usability feedback. Trust is a maintenance obligation, not a launch checkbox.
The product lesson is broader than astrology. If an AI feature handles personal inputs, split the system into parts you can prove and parts you can only evaluate. Make that split legible. Give users controls that match the promises. Then test the experience as a user would encounter it.
That produces something better than confident text. It produces a product people have a reason to trust.