Core package launch readiness audit
Report date: 2026-10-27
Period reviewed: working tree at 5769df6 on the report date; competitor documentation accessed the same day.
Time zone: Asia/Kolkata; no production deployment timeline was reviewed.
Scope: calculation packages, shipped rulebooks, runtime, in-process API adapters and HTTP contracts. This is a source and local runtime assessment, not a production certification or a frontend audit.
Start here: launch decision
Recommendation: hold a broad “complete Vedic and Western platform” launch. Prepare a narrowly scoped developer beta after restoring the repository gates and reviewing the default rulebook. The architecture supports a credible calculation product: shared astronomy, explicit conventions, versioned rulebooks, integrity checks, provenance and omission reporting. The largest gaps are rule coverage, independent domain validation and developer onboarding, rather than a need to replace the package structure.
Local verification found 392 passing package/tool tests and one failing logger test, plus 12 passing HTTP-app tests. All ten package/tool type checks passed. The aggregate package check fails its architecture boundary assertion. Passing tests establish the behavior they exercise; they do not establish a universal API accuracy percentage.
The default Vedic rulebook includes a draft travel-muhurta pack. Yoga/dosha coverage is three rules, and the divisional-chart table contains 16 named divisions, not every integer D1 through D60. Western secondary progressions deliberately omit the progressed ascendant and houses. These limits need to be explicit in discovery, documentation and sales claims.
No calculation implementation was changed by this audit. No production artifact, competitor account, paid API response or independent practitioner sign-off was available for verification.
What is already strong
| Area | Evidence in this repository | Product value |
|---|---|---|
| Shared calculation boundaries | Package structure, runtime | One astronomy and chart-composition foundation across traditions |
| Reproducibility | Vedic rulebooks, Western rulebooks | Exact versions and content hashes prevent silently mixing rule resources |
| Explicit omissions | Vedic result contract, Western result contract | Callers can distinguish complete calculations from omitted features |
| Native safeguards | Swiss tests | Pinned files, isolated native state, polar-house rejection and refusal of analytical fallback are tested |
| Independent provider comparison support | Drift tool, Horizons tests | Useful infrastructure for numerical verification, with comparison-context checks |
| Transport separation | API service, HTTP app | Domain calculations can be reused without Express |
How the rulebook compares
Competitor documentation is evidence of advertised interfaces and coverage, not proof that their calculations are correct. Internal rulebook structures generally are not public, so no claim that our integrity architecture is uniquely superior is justified.
| Comparison | Our shipped behavior | External evidence | Refinement |
|---|---|---|---|
| Vedic conventions | Bundled Lahiri profiles v1/v2; alternative profiles/rulebooks can be injected | Asterwise ayanamsa reference documents Lahiri, Raman and KP choices | Publish supported presets and exact node, ayanamsa and house choices; add reviewed alternatives only where demanded |
| Vedic feature breadth | Vimshottari; 16 divisional rows; ashtakavarga; strengths; matching; panchang; three yoga/dosha rules; travel muhurta | Prokerala lists kundli, matching, separate doshas, porutham, panchang and auspicious periods; its getting-started guide also lists KP and calendar features | Launch with an exact coverage inventory; prioritize domain-reviewed yoga/dosha expansion over adding unrelated product categories |
| Western conventions | One bundled tropical/Placidus profile, traditional rulership, five major aspect types; eight technique registrations | AstrologyAPI natal reference exposes multiple house systems and optional asteroids | Add reviewed whole-sign and modern-rulership presets if those users are in scope; distinguish provider support from a selectable service preset |
| Developer integration | Examples in READMEs and HTTP request files; JSON-facing methods accept unknown |
Prokerala onboarding includes OpenAPI/Postman import; Asterwise docs link SDKs, OpenAPI and response-envelope guidance | Provide machine-readable contracts and typed consumer methods |
| Explanation and presentation | Structured rule IDs, facts, hashes and evidence; no packaged multilingual narratives or report renderer | AstrologyAPI natal reference documents language selection; Prokerala offers PDF reports | Sell a calculation API unless those presentation features are implemented; keep explanatory rendering outside the mathematical core |
The existing competitor research is useful background, but its blanket claim that no product unifies advanced Western and Vedic calculation is not established by this audit. Current Asterwise documentation advertises both traditions. Do not use uniqueness, endpoint-count or accuracy-superiority claims without a defined, current comparison.
Rulebook refinements needed before launch
- Review or explicitly gate draft rules. Yatra rules carry
status: 'draft'and say a primary edition is pending. Default assembly includes them in both bundled rulebooks. The result preserves draft status, but feature discovery reports support without a maturity distinction. Require explicit experimental opt-in or a reviewed replacement before advertising production muhurta. - Add a rule review ledger. Manifest sources are broad text/chapter strings, not an independent review record. Record edition/translation, chapter/verse/page, school, formula/table transcription, reviewer, review date and external expected cases for each shipped family. Hashes establish identity and integrity, not domain truth.
- Expose exact coverage. The yoga pack has Gajakesari, Budhaditya and lagna-based Kuja with one cancellation. Do not imply a comprehensive yoga catalogue or all regional Manglik rules. The varga table has D1, D2, D3, D4, D7, D9, D10, D12, D16, D20, D24, D27, D30, D40, D45 and D60. Replace ambiguous “D1–D60” wording with this list.
- Preserve convention identity when expanding. Node drishti, strength scales, dasha year lengths, matching subject order and cancellation schools are policy choices. Document them as such; a competitor disagreement is not automatically a defect. Introduce a new profile/rulebook version when numerical conventions change.
- Name approximations precisely. Directions use a constant Naibod mean arc, not a true solar arc or primary directions. Progressions use day-for-tropical-year and Naibod MC, with no progressed ascendant or houses. Make those method names visible at the entry point.
How easy the APIs are to use
Assessment: workable for a developer who reads the repository, too much discovery work for a self-service customer. Factories, shortcut methods, capability endpoints and examples provide a good starting point. The following friction is directly visible in the contracts or was reproduced locally.
| Finding | Evidence and effect | Recommended package-level change |
|---|---|---|
| JSON admission doubles as the developer SDK | Western API signatures accept unknown; TypeScript cannot catch misspelled fields at that boundary |
Retain runtime JSON admission and add typed consumer inputs/overloads generated from the same contracts |
| Unknown keys disappear | Input copying drops unrecognized chart fields. A live natal request with requset was accepted and returned a complete default result |
Reject unknown keys or report structured warnings at the public boundary; define compatibility policy for future fields |
| Method names do not imply one response shape | Natal returns value.natal; composite/progressions/returns expose their technique result directly in value; transit/synastry declare unions; compose returns a snapshot |
Publish a per-method contract now; converge through a versioned response contract or typed facade |
| Combined chart does not support every registered operation | HTTP guide explicitly excludes dedicated composite/progression/return calls from combined chart dispatch | Discovery should state call modes and required fields, with runnable examples |
| Solver internals burden ordinary callers | Solar returns require an explicit multi-field probe budget, anchor and location policy | Offer bounded server/package defaults and retain an advanced override; return resolved search limits |
| Partial output needs careful handling | A live default progression call returned complete: false, with missing-angles, despite a supplied birth observer |
Document supported output up front; distinguish intentionally unsupported outputs from runtime omissions and genuine failures |
| Time ownership needs a clear public contract | Runtime README requires application-owned TT conversion; API convenience factory supplies one | Document accepted ISO offsets and epoch units, supported dates, historical calendar and birth-time uncertainty; put place/time-zone resolution in an optional adapter |
An OpenAPI document was not found in the inspected repository inventory. Add generated request/response schemas, error examples, discriminators, units and field-level validation paths. Ship a quickstart that creates the provider API, casts one chart, checks complete, interprets missing and saves provenance. Validate it from a fresh consumer project rather than only through workspace imports. All inspected package manifests are private; public npm distribution needs a separate packaging/release decision.
How accurate the responses are
Assessment: strong adapter-level evidence; insufficient independent evidence to certify every domain result. Three different questions must stay separate:
| Meaning of accuracy | What can be said now | What remains |
|---|---|---|
| Astronomical numerical agreement | Swiss tests compare native positions/houses against stored C swetest values; Horizons fixture tests provide cross-provider checks |
A versioned, representative end-to-end validation corpus across the supported range |
| Faithful execution of the chosen rule school | Domain suites exercise formulas, boundaries and explicit conventions | Independent transcription review and reference outputs for each advertised rule family |
| Predictive validity of interpretations | This audit establishes no predictive validity | Do not translate numerical precision or test success into claims that predictions are scientifically proven |
Numerical check performed through the public API
Using createProviderApi, western.compose, the bundled tropical profile and J2000 UTC with a Mumbai house observer, all 11 bodies were compared to the stored independently compiled C CLI fixture in swetest.ts. Maximum absolute differences were:
| Quantity | Observed maximum |
|---|---|
| Wrapped longitude | 0.000013681 arcseconds |
| Latitude | 0.000012421 arcseconds |
| Distance | 3.50 × 10⁻¹³ AU |
These are integration/rounding differences for one fixture, not absolute celestial accuracy or a market-wide comparison. Both paths use Swiss/DE441; shared engine errors can remain undetected. Provider precisionArcsec was null, which correctly avoids inventing an accuracy guarantee. This audit did not contact a competitor calculation endpoint or run a new live Horizons survey.
Time-model inconsistency needs a focused fix
The API’s default TT resolver adds a ΔT polynomial to UTC epoch Julian day. ΔT is TT minus UT1; UTC conversion requires a distinct treatment. For pre-1900 dates the implementation uses a single parabola rather than NASA’s intermediate historical branches. Its “about a second for 1900–2050” comment is not supported as a present-day guarantee by the linked NASA polynomial source, whose 2005–2050 branch is based on extrapolation.
Crucially, Binder uses this resolver for routing, while the Swiss engine calculates its own TT/UT1 through utc_to_jd. The default resolver therefore does not directly shift ordinary Swiss positions. At the J2000 check, its TT offset from the UTC Julian date was approximately 63.873844 seconds; the provider declaration implied approximately 64.184 seconds. The demonstrated issue is inconsistent time models, with potential coverage-edge effects; this audit did not reproduce a wrongly routed request. Align routing and provider time conversion and verify coverage boundaries. Swiss’s time-conversion documentation explains the separate TT and UT1 outputs.
Independent validation required for release
Create fixtures with external expected outputs, settings, source version, capture date and reviewer. Reusing a calculator’s own rules to construct its expected values is useful for regression but cannot validate the rules themselves.
| Family | Cases needed | Acceptance requirement |
|---|---|---|
| Positions and houses | Multiple modern/historical epochs, retrograde stations, 0° seams, latitude extremes, geocentric/topocentric, each advertised ayanamsa and house preset | Compare equivalent frames/time scales; establish measured per-body angular budgets, house-angle budgets and explicit exclusions |
| Panchang and event solvers | Sunrise boundaries, local midnight, offset transitions, no-rise/no-set, short limbs and multiple cities/seasons | Compare actual event times, not just limb names; define sunrise/refraction conventions and a separate event-time budget |
| Varga and dasha | Every supported division, every unequal span, boundary ±epsilon, all nine lords and each supported year length | Exact categorical agreement and independently calculated timeline endpoints under matching conventions |
| Strengths and ashtakavarga | Complete worked charts with all subfactors, reductions and intermediate sums | Compare components before totals; explain each discrepancy with source/convention evidence |
| Matching and yogas | All table entries where practical, ordered subject pairs, positive/negative/cancelled rules | Exact outputs under the named school; explicit supported-rule inventory |
| Western derived techniques | Composite wraparound, progression mapping, mean directions and solved solar-return roots | Independently check mapped dates/angles and root residuals; publish intentional missing outputs |
Use the existing drift tool for astronomical comparisons; extend validation around domain outputs rather than putting competitor integrations into runtime packages. Its current tests use synthetic adapters and validate comparison behavior, not a new empirical accuracy survey. Existing Horizons tests do include captured real-response comparisons, so independent evidence is not entirely absent. Match conventions before judging disagreements: Asterwise’s documented mean/true ayanamsa correction illustrates why apparently similar sidereal outputs can differ.
Prioritized launch work
P0 means required before a public launch claim within the affected scope. P1 means required for a smooth self-service API launch. P2 is demand-led expansion.
| Priority | Owner/package | Work | Reviewable completion criterion |
|---|---|---|---|
| P0 | logger / architecture checks | Resolve stale logger expectation and Vedic engine calculator-boundary violation | Full test and aggregate check commands pass without bypassing the intended architecture rule |
| P0 | vedic / rulebooks | Review/gate draft muhurta; publish exact yoga/varga/matching schools and maturity | No unreviewed rule is advertised as production-ready; discovery and route docs match defaults |
| P0 | runtime / api-service / ephemeris | Align time resolution, supported date policy and coverage admission | Independent UTC/TT/UT1 and coverage-edge fixtures pass; approximation claims corrected |
| P0 | domain packages / validation tool | Establish release accuracy corpus for each advertised endpoint | Recorded source/settings, numerical budgets, component comparisons and explained discrepancies; no unexplained breach |
| P0 for hosted service | HTTP host / gateway | Provide authentication, quotas, abuse protection and operational readiness; verify Swiss licensing choice | Public ingress cannot run anonymous unbounded calculations; readiness checks real provider/data availability; license decision recorded |
| P1 | api-service / public contracts | Typed caller inputs, machine-readable schemas, unknown-field behavior and stable response documentation | Fresh consumer can make and validate its first chart from a quickstart; invalid/partial examples are executable |
| P1 | service discovery | Report maturity, exact variants, units, required inputs, call modes and intentional omissions | Consumer can determine support before starting an expensive operation |
| P1 | runtime / HTTP host | Measure latency, throughput, queue saturation, cancellation and bounded solver behavior | Published measurements for representative operations and concurrency, with an agreed service target; no target is claimed from this audit |
| P2 | vedic / western | Expand reviewed yoga/dosha coverage and requested convention presets; add further dashas/returns if justified | Each addition includes source review, independent fixtures and versioned capability changes |
Authentication belongs to the host/gateway, not pure calculators. The HTTP guide explicitly lists authentication and rate limits as absent; CORS is not API authentication. Astrodienst’s licensing documentation requires the applicable license choice before activating a public service. This audit does not determine which license obligations the product currently satisfies.
Verification record and limitations
Environment: Node 26.7.0, existing installed native assets; clean tracked working tree before adding this report. All results are local, with no deployment inference.
| Command / check | Result |
|---|---|
pnpm test:packages |
Build passed; recursive testing stopped at logger failure |
pnpm --filter './packages/*' --filter './tools/*' -r --no-bail test |
393 tests: 392 passed, 1 failed; ten package/tool scripts ran, no skips |
pnpm check:packages |
Package builds passed; boundary check failed on packages/vedic/src/application/engine/engine.ts importing ../../calculations/matching/index.js |
pnpm --filter './packages/*' --filter './tools/*' -r --no-bail check |
All ten package/tool type checks passed |
pnpm test:astrology-api |
Dependency/app build passed; 12 tests passed, no skips |
| Public API smoke checks | Natal, dasha and yogas returned complete results; progression returned the documented missing-angles partial result; misspelled requset was silently ignored |
| Public API numerical sample | 11 J2000 bodies compared to stored C CLI fixture, maxima reported above |
The logger failure is in logger.test.ts: expected @astrology/api.requests, actual @astrology/astrology-api.requests. This is a concrete verification failure, not evidence of incorrect astronomy. Logs from this run were stored temporarily under /tmp/astrology-launch-*.log; these are not durable repository artifacts. Numerical and smoke procedures used direct ESM imports of built public package entries and the existing CLI fixture, without editing source or tests.
This assessment is not exhaustive fuzzing, load testing, a security audit, a public-package install test or domain-expert certification. No browser check was necessary for this package/HTTP scope. Final launch approval needs the P0 evidence for the exact features offered, rather than a larger endpoint catalogue.