Parashar: Building an AI Product from Domain Expertise

Executive Summary

Parashar is an AI consumer product that applies predictive analysis to a complex traditional knowledge domain. The system operates on astronomical positional data (Swiss Ephemeris) combined with thousands of interpretive rules — a computation-heavy domain requiring precise inputs and layered reasoning. The product challenge was strategic: which analytical systems to prioritize, how to engineer AI loops that apply interdependent rules correctly, and how to make dense multi-dimensional outputs usable by non-experts. This is a side project born from genuine intellectual interest — and a real-world test of how domain expertise shapes AI product thinking.

1. The Problem

The target domain has three characteristics that make it difficult to serve with software:

Rule complexity. The domain operates on thousands of interdependent variables derived from astronomical positional data (computed via Swiss Ephemeris). A single analysis requires cross-referencing multiple analytical systems, each with its own rules, exceptions, and contextual modifiers. Expert practitioners spend years learning to navigate these interactions.

Computation intensity. Producing a complete analysis manually requires calculating planetary positions to arc-minute precision, then applying layered interpretive rules across dozens of data points. An expert can spend hours on a single reading. The computation is deterministic at the astronomical layer (positions are mathematically derivable) but the interpretive layer requires contextual judgment across competing systems.

Expertise gatekeeping. Access to quality analysis requires finding a skilled practitioner. There’s no standardized certification, quality varies enormously, and the knowledge is traditionally transmitted through apprenticeship. Most consumers can’t distinguish rigorous analysis from superficial work.

The Opportunity

If the astronomical data is precise (Swiss Ephemeris provides this) and the rules are codifiable, an AI system can learn to apply them at scale. The product thesis: democratize access to expert-level analysis by combining precise scientific computation with AI-driven rule application and contextual reasoning.

2. Product Strategy: What to Build

Scoping the system

The domain has 10+ analytical systems, each covering different dimensions. Including all of them produces comprehensive but overwhelming output. Including too few produces shallow work that an expert would dismiss.

The strategic question: what’s the minimum system coverage that produces a useful, credible analysis? Classic v1 scoping — the same problem every PM faces when deciding what to include.

The approach: rank analytical systems by three criteria:

1. Coverage — what percentage of user questions does this system address?
2. Computational determinism — can the rules be encoded reliably, or do they require subjective judgment?
3. Inter-system dependency — does this system’s output feed into others? (If yes, it’s infrastructure, not optional)

Systems that score high on all three ship first. Systems that require heavy contextual judgment get flagged for future iterations.

Deciding what the AI should do vs what it shouldn’t

Not every part of the domain should be automated. The strategic framework:

3. AI Loop Engineering

The core challenge

Standard AI products learn from data patterns. Parashar needs to learn rule systems — thousands of interdependent if-then conditions, hierarchical overrides, and contextual weights. The AI loops are engineered to:

1. Ingest precise astronomical data — Swiss Ephemeris provides planetary positions, aspects, and timing to arc-minute accuracy.
2. Apply rule cascades — multiple analytical systems run in sequence; each produces intermediate outputs that feed the next.
3. Resolve conflicts — when two systems contradict, a weighted resolution framework follows domain conventions.
4. Generate layered output — primary signal first, supporting analysis second, edge cases and caveats third.

Engineering evaluation criteria

“Correct” here goes beyond statistical accuracy:

• Positional accuracy — calculations match Swiss Ephemeris to arc-minute precision
• Rule fidelity — each system’s rules applied as a domain expert would apply them
• System weighting — conflict resolution matches expert consensus on system hierarchy
• Completeness — output covers relevant systems for the query type without omitting dimensions that would change the conclusion

These criteria come from domain expertise, not labeled datasets. The person defining “what correct looks like” needs to be the domain expert — not an ML engineer approximating correctness from training data.

4. UX: Making Complexity Accessible

The domain produces dense, multi-dimensional outputs. A complete analysis might cover 10+ dimensions simultaneously. Presenting everything at once overwhelms; presenting too little makes the product feel shallow.

5. What This Shows About Product Thinking

Domain expertise as strategic advantage

Most AI products are built by teams who learn enough about a domain to ship. Parashar inverts this — the product strategist is the domain expert. That cuts the translation loss that typically degrades AI products:

• No spec-to-implementation gap. The person scoping the product understands edge cases, system interactions, and the quality bar.
• Evaluation criteria reflect real expertise. “Correct output” is set by someone who knows what an expert would produce.
• UX priorities are domain-informed. What to surface first, how to handle conflict, what progressive disclosure means here — grounded in practice.

Product strategy + AI engineering, not ML engineering

The role spans product vision, AI loop engineering, system architecture, and UX strategy — not model training or infrastructure:

6. Current Status

Active side project (2024–present). Product vision defined, analytical systems scoped and prioritized, AI loop architecture specified, evaluation criteria established, UX strategy designed. Built from genuine intellectual interest in the domain — a scientifically grounded computation layer plus rule-based interpretation, and a real-world test of AI product strategy.

7. Key Takeaways

On domain-to-product translation: The hardest part of an AI product isn’t the AI — it’s strategic scoping. Which rules to encode, which systems to defer, where the AI adds value versus creates false confidence. Product decisions, not engineering decisions.

On AI loop engineering: When the AI applies rule systems (not pattern-finding), the challenge shifts from training data to rule fidelity. Evaluation criteria must come from domain expertise, not statistical benchmarks alone.

On making complexity accessible: Progressive disclosure is a product strategy, not only a UX pattern. What you push to Level 2 or 3 decides whether the product empowers or overwhelms.

Takeaway

Same product judgment as trading/risk AI: know what’s deterministic, what’s interpretive, and what you surface first when the user can’t audit every layer.