Why Orim Doesn't Just Ask an LLM for Your Reading
Most AI divination apps prompt a language model and hope it doesn't make something up. Here's the architecture we use instead — and why, for a product people trust with their birth chart, "hope" isn't good enough.
Ask a generic AI wellness app for your reading, and here's what's actually happening behind the screen: your birth data gets dropped into a prompt, a language model free-associates a paragraph that sounds right, and it gets shown to you as if it were derived from something. Most of the time it's plausible. Sometimes it invents a planet placement that isn't in your chart, contradicts itself between two sections, or states a traditional meaning that's simply wrong.
That's not a small bug. In this category, the reading is the entire product. An app that hallucinates a detail about your own chart doesn't just make a mistake — it breaks the one thing it was supposed to earn.
The easy way, and why we didn't take it
The fast way to build an AI reading feature is to write one clever prompt and let the model generate freely at the moment someone asks. It's quick to ship, and it's exactly what most competitors in this space do.
It's also structurally unreliable. A language model generating text has no built-in concept of "this fact about a chart is true and that one isn't" — it's producing the statistically likely next words, not consulting a source of truth. Ask it the same question twice and you can get two different, sometimes contradictory, answers. Neither one was checked against anything.
What Orim does today: no invention at read time
Every reading on Orim — every card meaning, every planet-in-sign interpretation, every star's traditional keywords — comes from a large library that a person wrote and reviewed in advance. When you draw a card or cast a chart, the app isn't asking a model to compose your reading on the spot. It's looking up the exact entries that apply to your specific result from a corpus that was locked down before you ever asked.
That's the whole trick, and it's a simple one: if nothing is generated at the moment you read it, nothing can be hallucinated at the moment you read it. The model isn't in the loop where invention could happen.
Where a language model earns its place
None of this means AI has no role. It means the role has to be the right one.
The architecture we're building toward gives an LLM exactly one job: turning retrieved, verified facts into natural language — not deciding what the facts are. The system first retrieves the specific pieces of authored knowledge relevant to your exact question or chart — think of it as a structured map of every star, palace, card, aspect, and how they relate to each other, not a flat pile of text. The model's task is narrow: take what was retrieved and communicate it clearly, in Orim's voice. It never gets to introduce a fact that wasn't handed to it.
A second check before anything ships
Even a model that's only supposed to summarize can still drift, so the design adds one more step: a second AI pass whose only job is to judge the first one's output against the facts it was given and the voice rules the reading has to follow. Did it introduce anything not in the source material? Did it contradict itself? Did it break a guardrail — predicting an outcome as certain, veering into fear, naming something it shouldn't? If so, it gets sent back before a person ever sees it.
An AI generating a reading and an AI checking that reading are different jobs, done by different passes, checking each other — not one model trusted to get everything right in a single shot.
Why this is the only acceptable way to do it here
A recipe app that hallucinates an ingredient is annoying. A reading app that hallucinates a detail about your own birth chart, or states a traditional meaning that's simply invented, has failed at the one thing it exists to do — and in a category already full of people skeptical of being scammed, one bad answer is what confirms the suspicion.
Accuracy isn't a nice-to-have layered on top of Orim's AI. It's the design constraint everything else is built inside of.
Diagram list:
- Hero: naive LLM pipeline vs. retrieval-plus-judge pipeline, side by side
- The authoring pipeline — deterministic lookup, no live generation step
- A knowledge-graph sketch — stars/palaces/cards as connected nodes, one query's subgraph highlighted
- Generation step feeding a judge step, with a rejection loop shown