Xalen Ephemeris ships 21 crates, placeholder badges and a ten arcminute test ceiling

The badges are placeholders and the registry is two majors behind

The first block on the page is a publish status note, and it says the work is not distributed anywhere yet. The Rust crates, the PyPI wheel and both npm packages, a native build and a WebAssembly build, are all described as not published to their registries. It adds that the two registry badges near the top, the crates.io and docs.rs ones, are placeholders until the first release. In other words, the links that look like proof of a downloadable library currently point at nothing that represents this code.

An availability note repeats the problem with numbers. The registry currently serves the 0.3.1 line for the leaf crates, while the 0.4 and 0.5 releases this page describes are not yet on it. So the version a user can get and the version the documentation describes are two majors apart, and the page does not attempt to reconcile them.

The install path is therefore source, and the page points at per-binding readmes inside three of the binding directories for the specifics. Four bindings are described in total, Node through a native extension, Python through an extension module, WebAssembly through a generated binding, and a C interface, so a user picking a language is picking a build recipe rather than a package manager entry.

JPL-class accuracy belongs to the kernel, not to the code

There are two engines in this library, and the difference between them is the difference between a self-contained crate and a self-contained crate plus a data file.

The analytical engine needs no data files at all. It combines a planetary theory, a lunar theory, a nutation model and a full precession and frame rotation, and the page reports its agreement with the JPL reference ephemeris as sub-arcsecond for the Sun, which is quoted at 0.21 arcseconds, and for Mercury through Saturn at 0.76 arcseconds or better. Uranus and Neptune land at roughly 1.8 to 2.5 arcseconds, the Moon at a 2.8 arcsecond root mean square with a worst case near 12 against the Swiss Ephemeris over years 1600 to 2100, and Pluto only at arcminute class.

The second engine is a reader for the real JPL binary kernel format, and loading a kernel file is what buys sub-arcsecond results on the Sun, planets and Moon plus full-range Pluto. The analytical path trades Pluto and the Moon for the convenience of shipping no data.

The practical consequence is that the headline claim depends on a step the user performs. The accuracy figures are reproducible with a single test, but only when a kernel file is present, and nothing in the repository supplies one. The call the page opens with is three lines long, converting a calendar date to a Julian day, building a Vedic almanac, subtracting an ayanamsa from the geocentric longitude and mapping the result onto a nakshatra:

let jd = calendar_to_jd(1990, 3, 15, 12.0 - 5.5, CalendarSystem::default());
let almanac = Almanac::default_vedic();
let pos = almanac.geocentric_ecliptic(Body::Moon, jd).unwrap();
let sid = (pos.longitude.to_degrees() - Ayanamsa::Lahiri.compute_deg(jd.as_f64())).rem_euclid(360.0);
println!("{}", Nakshatra::from_longitude_deg(sid)); // Swati

A ten arcminute ceiling and a house system that returns Placidus

Three admissions in the accuracy material are more useful than the claims around them.

The first is a test ceiling. For Pluto, the committed golden test asserts a regression limit of 600 arcseconds, which is ten arcminutes, against the reference ephemeris, and the page says plainly that no test asserts a tighter figure. The published fit for that body is around one arcminute, so the committed test would pass a regression ten times worse than the stated bound. That is a defensible choice for a test meant to catch drift rather than to certify accuracy, and it is unusual to see the difference admitted in the same sentence as the claim.

The second is a house system. Twenty-three are listed, from Placidus and Koch through Whole Sign, Equal, Porphyry and many regional variants, with an automatic Porphyry fallback at polar latitudes. One of them, Gauquelin sectors, is described as an experimental placeholder that currently returns Placidus cusps. So the count of twenty-three includes one entry that is not the division its name promises, and a user picking a house system by index rather than by reading would get a different result.

The third is a past bug. An earlier build applied the planet annual aberration term to the geocentric Moon, which produced a residual of roughly 11 to 31 arcseconds, and the page says the bug is fixed and points to the accuracy report. Both engines now share one apparent-place chain: full rotation precession plus nutation, two-pass annual aberration for planets and the Sun, and geocentric light time without annual aberration for the Moon. Publishing the number your bug produced is the strongest evidence on the page that the current numbers mean what they say.

Twenty one crates, and two that a plain build skips

The workspace declares twenty one members, a small library core and a wide set of tradition crates behind it: time, coordinates, the ephemeris itself, houses, ayanamsa, two star crates plus an anchors crate, the Vedic and Western layers, a C interface, WebAssembly, Chinese, numerology, a world traditions crate, the Python and Node bindings, Lal Kitab, I Ching, chart rendering, and a cloud crate.

Nineteen of those build by default, and both exclusions are commented in the manifest rather than left as a puzzle. The Python binding is a member but not a default member, because its extension module needs Python present at link time, so a plain workspace build cannot produce it and the manifest names the development command to use instead. The star data crate is excluded for a different reason: it is a data crate that must not be compiled by a bare build, and it is compiled on demand as a dependency of the star layer when a feature that loads the full catalogue is switched on.

That is careful work, and it is worth reading as a signal about how the rest of the build behaves. Two members out of twenty one have build conditions that a newcomer will hit, and the manifest documents both in comments rather than leaving a contributor to discover them through a failed build.

Three star catalogues, two of them compiled into the binary

The fixed star story is layered, and the numbers describe three different scopes.

The Western layer carries 506 built-in stars with proper motion and precession correction, covering the brightest stars, the named asterism systems, the yogatara stars of the nakshatra tradition, and IAU-named stars down to roughly magnitude five. A separate star crate adds 8,870 compiled-in records from the Hipparcos catalogue, taken at every record fainter than none and brighter than magnitude 6.5, propagated from one epoch to another so that the binary needs no data file at all. Those 8,870 sit on top of a curated core of 108 stars.

And on top of that, the same crate can still read the full Hipparcos catalogue of 118,218 stars from a comma separated file at run time.

So the same feature, fixed star positions, is available at three scales: a few hundred always present, nearly nine thousand compiled in with no data file, and the entire hundred thousand record catalogue if a user supplies it. That is a sensible design for an astrology library where the inner planets matter far more than the faint catalogue, and it is also why the data crate that holds the full table is excluded from default builds, since compiling it for everyone who does not need it would be a waste.

A cloud crate the feature list never mentions

One workspace member is named for cloud, and the feature list never mentions it. Nothing on the page describes a hosted service, a sync layer, an account, a network call or a remote component, in a project whose headline is a pure library with no unsafe code in its core and Apache-2.0 terms. The root also holds a playground directory, which implies something runnable in a browser, and the homepage is a separate domain from the repository, so the surrounding infrastructure is larger than what the page documents.

The legal side is similarly larger. The repository carries a licence file, a notice, a commercial licence document, a trademark document, a credits file, a contributor licence agreement and an enterprise document. The page states Apache-2.0 and stops there. For a library whose whole argument is that you can inspect it, that is the area to read rather than assume: a commercial licence document next to an Apache one usually marks a boundary, and the credits file is what would explain the I Ching material, where all 384 line texts are reproduced verbatim from a named nineteenth-century translation.

None of that makes the licensing hostile. It makes it undocumented on the front page, which for a project inviting you to publish commercial figures from its output is the gap worth closing.

Accuracy you can re-run, on references you must supply

The validation section is the strongest part of the documentation, and its structure matters. The library is checked against the JPL reference ephemeris, against the real binary kernel, against the Swiss Ephemeris, and against a list of public calculators that cover the astrological side rather than the astronomical one, including two well known Indian panchang sites and a prominent Western site. The eclipse engine is validated against NASA figures for two specific dates, the 2017 and 2024 total solar eclipses, and a separate document holds the full report.

What makes it checkable is a single command with one missing input: a test scoped to the ephemeris crate, named for the comparison against the reference, run only when a kernel file is present. Alongside it the repository carries benchmark notes and a benchmarks directory, so the timing claims have somewhere to live.

The time side is handled with the same seriousness, which matters more than it sounds. The Julian day types distinguish the uniform, terrestrial and barycentric scales, the leap second table is complete rather than approximate, and the difference between civil and dynamical time uses a published 2016 model with a stated uncertainty envelope per epoch. For a library that a caller will use to place a birth chart decades or centuries from now, that is the part that quietly decides whether two computations agree with each other.

Editorial conclusion

This is a serious piece of numerical work with an unusually honest accuracy report, and the honesty extends to the parts that would normally be buried, including a past numerical bug in the Moon's aberration handling and a regression test with a deliberately loose ceiling. That combination makes it worth reading whatever your astrological tradition. What it is not yet is a dependency you can add to a manifest. Read the publish status before planning around it, because the registry line and the version this page describes are not the same, and the accuracy figures you will quote to someone else depend on whether they loaded a kernel. Three things to settle. Decide which of the two engines you actually need, since the analytical one needs no data file and the kernel one needs a JPL file you must obtain. Check the house systems you plan to use against the list, since one of the twenty-three is a placeholder returning a different division. And read the commercial, trademark and credits documents yourself, because the page names Apache-2.0 and the repository carries four other legal files whose terms are not summarised there.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. vedika-io/xalen-ephemeris on GitHub