Shipping in a Domain I Knew Nothing About

I built Astro Rattan, a Vedic astrology platform, without knowing Vedic astrology. That constraint shaped the architecture: when you cannot judge an output, fluency is not evidence that it is right.

You can't check work you don't understand

How do you build software in a field you don't understand?

You can't rely on reading output in an unfamiliar domain. A model can produce confident vocabulary and plausible structure while pattern-matching against text rather than computing a chart. I needed a visible failure handle before I could trust the platform.

Take the model out of the answer path

Should an LLM be in the calculation path?

Not for the final answer a user sees. The model helped build the system; deterministic code checked against a real reference source runs it.

The engines cover planetary strength, dasha timing, transit effects, yoga and dosha detection, and more. I checked that none imports an LLM client. Planetary positions trace to pyswisseph, pinned to an exact dependency version. A wrong deterministic rule is a bug I can point at; a generated paragraph has no comparable reference.

Domain knowledge as data, not weights

The astrological rules themselves live as data files, not as anything baked into a model or buried in a prompt. Counted at the level of individual rule entries, the tables in app/data hold 762 of them, spread across eleven JSON files. Two tables carry most of that weight — nakshatra_predictions.json (351 entries) and lagna_profiles.json (108) — with yogas.json (71 classical planetary combinations) and conjunction_effects.json (45) making up most of the rest. The remaining seven files hold smaller, more specific tables: which planet governs which body part, what a given house placement indicates, and similar mappings.

The property that matters is who can read the file. A domain expert can open a rule keyed by planet, house, or nakshatra and argue with it without knowing model weights or prompts. A correction changes one value under one key, so the scope of the fix matches the scope of the bug.

The expert is the verification mechanism

How do you verify output you personally can't check?

Find a verifier with the standing to say a specific claim is wrong and prove it — someone who can falsify the work, not just tell you it looks fine. A model checking its own output fails that test twice over, since it can't independently confirm what it generated; a domain expert reading a codified rule against a resulting output can.

I could not judge whether the output was astrologically correct, so the platform was reviewed by a practising astrologer with the standing to say what was wrong and why. One round covered requirements and scope; a second, on the same day, found specific defects. The fix landed before the day was out in a commit whose message states the count: twelve astrologer-reported issues.

Some of this a reader can check; some they can't, and I want to be explicit about which is which. Every other number in this post — 61 engines, 762 rule entries, 260 endpoints, 1,402 commits — is something anyone with the repository can reproduce by running the command that produced it. The same-day fix is different: the commit is real, dated, and pushed — I confirmed its timestamp myself — but it sits in a private repository, so a reader can't pull the thread the way they can with the counts above. The feedback log behind the "twelve" figure lives outside the repository entirely, in an internal record. I'm citing it because it's the strongest example I have of an expert with real authority saying "this is wrong" and getting a same-day fix, not because it's as checkable as everything else here.

One more number, stated precisely: the codebase contains 1,871 test functions across 67 files, counted from def test_ definitions — not "1,871 tests pass," since running the full suite wasn't part of writing this post. Asking pytest to collect the suite instead returns a larger number, because collection expands parametrized cases into multiple items apiece. Both counts are correct; they're just counting different things.