Methodology
Calculation-first approach
- Structured inputs are resolved before any result is shown.
- Birth date, birth time, place, coordinates, and timezone are kept explicit.
- Unavailable source data is shown as unavailable rather than guessed.
Vedic conventions
- The platform uses sidereal Vedic calculation conventions where astrology engines require them.
- Named conventions are kept visible in calculation details where a result surface supports it.
- Interpretation remains separate from raw calculation output.
Deterministic QA
- Core calculation modules are checked with repeatable debug and regression scripts.
- Boundary cases are tested for dates, timezones, rise and set events, and unavailable states.
- Changes are validated before release with typecheck, lint, build, and targeted QA scripts.
Independent reference checks
- Reference fixtures and differential checks are used where the platform has approved them.
- Cross-checks support engineering assurance; they are not public accuracy claims.
- Provider and licensing questions remain separate business or legal decisions.
Controlled unavailable states
- High-latitude, provider, timeout, and missing-data cases use controlled fallback states.
- The UI should avoid replacing missing results with fabricated times or interpretations.
- Users are directed to consultation or contact when a safe result cannot be shown.
Data and privacy principles
- Sensitive birth details should be sent only to the route needed for the requested calculation.
- Authentication-gated data stays inside protected account routes.
- Secrets, provider keys, tokens, and private payloads must not appear in public UI.
For personal decisions, use the consultation path rather than treating calculation output as a standalone instruction.
Consult