# System State Atlas 2 — scientific model and evidence review

Release 118 · reviewed 27 September 2026 · scientific integration, not a navigation certification.

## What this release establishes

The atlas can now carry an actual, dated NASA/JPL Horizons ephemeris pack. The earlier System Atlas carried a numerical transcription of JPL's lower-accuracy fitted elements and an importer; its own notes correctly said that no successful Horizons download had been included. With Earth and Galactic State Compass also used those fitted elements, used the Earth–Moon barycenter as an Earth proxy, and approximated the astronomical time arguments with browser UTC. Those remain legitimate disclosed teaching modes, but they are different from the new sampled-data mode.

The new pack has **11 targets, 1,461 retained six-hour epochs per target**, from **2026-01-01 00:00 TDB through 2027-01-01 00:00 TDB**. The original responses contain three-hour epochs. Every intervening three-hour sample was withheld from the retained interpolation grid and used to test the cubic-Hermite result: **1,460 comparisons per target, 16,060 total**. Original responses, request parameters, retrieval timestamps, hashes and source declarations are retained in `data/raw/`. The provider identifies DE441 for ten targets and **mar099** for the Mars-center target; do not call the entire pack a single DE441 body-center solution.

At retained epochs the numerical state is copied from the source sample. At intermediate epochs the state is interpolated from positions and velocities. No pack extrapolation is permitted. Outside the pack interval, a separately labeled fitted-element guide is available over 2000–2049. Its Earth object is the **Earth–Moon barycenter**, with no fabricated Moon state. Source selection must remain visible in the scene, readout and exports.

The largest tested position interpolation discrepancies were about **78.37 m for Mercury**, **19.76 m for the Moon**, and **0.355 m for Earth**. These compare interpolation with held-out values from the *same provider/model*. They are neither observational uncertainty estimates nor a bound at every instant. The full per-body numbers are in `horizons-retrieval.json`.

## USST: an explicit convention built on existing metrology

The local source `116/system-state-i-preview.html` defines **Unified System State Time (USST)** as a proposed integration and presentation framework. It introduces neither a new physical law nor an adopted astronomical standard. Its proposed coordinate basis is TCB, with an explicit origin. This release implements the display profile:

`usst-tcb-j2000/1`: `USST = (JD_TCB − 2451545.0) × 86400 seconds`.

The epoch is **JD 2451545.0 TCB**. It is not the same event as JD 2451545.0 TT, TDB or UTC. The time coordinate is not a reading from a physical universal clock, and it does not create a universal simultaneity independent of a selected coordinate system.

The IAU-defined relationship is:

`TDB = TCB − L_B × (JD_TCB − T_0) × 86400 + TDB_0`,

where `L_B = 1.550519768×10⁻⁸`, `T_0 = 2443144.5003725` and `TDB_0 = −6.55×10⁻⁵ s`. The code rearranges this relation before evaluating it, retaining seconds relative to the chosen epoch. At JD 2451545.0 TDB, the USST coordinate label is about **11.253787268 s**, not zero. The derivative `dTDB/dTCB = 1 − L_B` is a coordinate scaling convention, not the measured drift of an Earth clock. [IAU Resolution B3](https://iauarchive.eso.org/static/resolutions/IAU2006_Resol3.pdf)

**The ephemeris vectors remain TDB-compatible.** Displaying a TCB coordinate label does not relabel their units or dynamical convention. A genuinely TCB-compatible representation requires consistent spatial and gravitational-parameter scaling: for the standard linear scaling factor `F = 1 − L_B`, `x_TDB = F x_TCB` and `μ_TDB = F μ_TCB`; when both time and position are scaled consistently the velocity ratio is unchanged. This atlas exports the retained state convention explicitly and does not claim to have created a TCB-scaled dynamical solution. [NAIF time documentation](https://naif.jpl.nasa.gov/pub/naif/toolkit_docs/C/req/time.html), [Klioner 2008, relativistic scaling](https://www.aanda.org/articles/aa/pdf/2008/06/aa7786-07.pdf)

## UTC, TT, TDB, UT1 and what the browser knows

For an ordinary browser UTC label:

1. UTC→TAI uses a historical leap-second table covering the supported interval.
2. `TT = TAI + 32.184 s`.
3. TT→TDB uses the explicitly approximate NAIF leap-seconds-kernel periodic model, whose constants are pinned in `naif0012.tls`.
4. TDB→TCB uses the linear IAU definition above.
5. Earth rotation uses **UT1**, obtained from the carried Earth-orientation table when covered, rather than using TDB or TT as the rotation angle argument.

IERS Bulletin C 72 confirms no leap second at the end of December 2026 and `TAI−UTC = 37 s`. Future UTC labels beyond the supported announcement interval are marked as a **projection holding 37 s**, not an established future conversion. JavaScript Date represents ordinary timestamps but cannot represent the explicit `23:59:60` leap-second label; that input is rejected. Single-double Julian dates and millisecond browser timestamps also limit numeric resolution. Displaying more digits cannot remove these limits. [Bulletin C 72](https://datacenter.iers.org/data/16/bulletinc-072.txt), [NAIF kernel](https://naif.jpl.nasa.gov/pub/naif/generic_kernels/lsk/naif0012.tls)

The independent ERFA comparison at 15 selected epochs gave a maximum TT→TDB approximation discrepancy of **26.554 microseconds**, relative to the reference's geocentric TDB−TT model. This is a sampled numerical comparison, not an all-date guarantee, and not a local proper-time conversion. Clock synchronization, device-time accuracy, gravitational potential, an actual observer trajectory and instrument calibration remain separate requirements.

## Frames, origin and body identity

The NASA pack requests **geometric, solar-system-barycenter-centered ICRF Cartesian state vectors**, using kilometers and kilometers per second and TDB epochs. Its declared request is `CENTER=500@0`, `REF_SYSTEM=ICRF`, `REF_PLANE=FRAME`, `VEC_CORR=NONE`, `OUT_UNITS=KM-S`, `VEC_TABLE=2`. This is simultaneous-coordinate geometry, not an observer's apparent sky. Body IDs are retained. Jupiter through Neptune use **planetary-system barycenters**; Earth is **399, the Earth center**, and the Moon is **301**. [Horizons API](https://ssd-api.jpl.nasa.gov/doc/horizons.html)

The scene can translate its origin by subtracting compatible states. A heliocentric view does not alter the underlying ephemeris. For a J2000-ecliptic display, ICRF vectors are rotated by the explicitly declared IAU76/80 obliquity **84381.448 arcseconds**, matching the Horizons fixed-ecliptic convention. This display rotation is not the time-varying orbital plane or the invariable plane. [Horizons reference frames](https://ssd.jpl.nasa.gov/horizons/manual.html#frames)

Display sizes of planets, arrows and grids are separate from state-vector units. A Moon inset or enlarged Earth sphere must not silently replace scale-accurate distances. Emission/reception timing, stellar aberration, light bending and refraction are not included in these geometric vectors.

## Earth and observer frame: an explicit upgrade

`astro.js` implements IAU 2006 bias/precession using Fukushima–Williams angles, ERFA-derived IAU 2000B nutation with the small P03 adjustments, a truncated equation-of-equinoxes expression, Earth rotation using UT1, and polar motion using the carried `x_p,y_p`. The TT and UT1 arguments stay distinct. The reference formulas and ERFA license are retained. This is a reduced-accuracy model derived from established formulas, **not the full SOFA apparent-place pipeline**. [SOFA](https://www.iausofa.org/2023-10-11c), [ERFA source](https://github.com/liberfa/erfa)

The carried IERS Bulletin A series was retrieved over verified TLS from the **official USNO mirror** after the IERS download host's certificate chain failed local verification. The failure was not worked around by disabling TLS. It contains **368 daily rows**, MJD UTC 61040–61407, including **100 predicted UT1 rows**. Prediction status and source uncertainty columns are retained. Linear interpolation is used within the covered range. Outside it, the code explicitly reports `UT1=UTC` and zero polar motion as assumptions. Celestial-pole offsets `dX,dY` and length-of-day corrections are omitted. [USNO IERS series](https://maia.usno.navy.mil/ser7/finals2000A.all)

Independent local validation used **pyerfa 2.0.1.5**, without importing the atlas formulas into the reference calculation. At 15 epochs covering 2000, 2010, every month of 2026, and 2049, transformed basis directions differed from full ERFA IAU2006/2000A `c2t06a` by at most **0.000410 arcsecond** when both calculations used the same supplied EOP. That agreement does not remove EOP prediction uncertainty, omissions, timing error or observer-input error. No physical phone or telescope pointing accuracy is claimed. The reference dependency is for tests only; the public application needs no Python.

The observer is a WGS84 geodetic location with optional ellipsoidal height. The local frame is **east, north, up**. Azimuth increases clockwise from true north; elevation is measured from the geometric tangent horizon. Observer position is subtracted before determining geometric Sun/Moon direction. Atmospheric bending, terrain, sea-horizon dip, solar limb, and optical visibility are separate and absent. At a geographic pole, longitude selects a conventional meridian; at a vertical direction azimuth is undefined. Zero spin at a pole has no physically meaningful azimuth.

## Galactic orientation without an absolute-motion claim

There are **two different transforms**. The conventional Galactic longitude/latitude rotation supplies the coordinate north pole. The **Galactocentric** model additionally adopts a center, solar displacement and velocity; it is not identical to a celestial-sphere Galactic coordinate rotation.

This release keeps the earlier explicit Astropy v4.0 parameter set: center ICRS RA 266.4051°, declination −28.936175°, Sun-center distance 8.122 kpc, solar height 20.8 pc, roll 58.5986320306°, solar velocity `(12.9,245.6,7.78) km/s` in those adopted Galactocentric axes. These are pinned conventions with an observational basis, not automatically the newest measurements and not a unique absolute velocity. [Astropy frame construction and defaults](https://docs.astropy.org/en/stable/coordinates/galactocentric.html)

The direction toward the Galactic center, Galactic north, solar Galactic velocity, Earth's heliocentric velocity and local spin are different vector types. They retain their identities. Gaze is a unit direction transformed by rotations only. A combined velocity is a **Newtonian sum after rotating all velocity components into compatible axes**, not a sum of speed magnitudes or a relativistic absolute speed.

Procedural stars or spiral arms are **illustrative structure**, not a measured star catalog. No source should describe them as NASA positions. A rectilinear stellar-propagation helper is supplied for future catalog data; it requires positive parallax, epoch, RA, declination, radial velocity and both proper-motion components, with `pmRA` explicitly including `cos(dec)`. Missing or negative parallax is not inverted. It includes perspective changes through 3D vector propagation but excludes binary orbits, Galactic acceleration, covariance propagation and apparent-sky corrections. Do not imply that merely including this helper imports a catalog.

## Proposed project terminology: implementation boundaries

| Term | Physical or conventional basis | This release's disciplined use |
|---|---|---|
| System State | Solar-system scale of attention and coordination | Project purpose, not an extra physical reference frame |
| USST | Declared TCB offset/epoch profile | Numeric coordinate label with explicit source/time model |
| Planetarydian | Identified body's meridian and rotation model | Earth orientation is implemented; no single spin law inferred from mass or orbit |
| Solartation | Chosen solar reference-grid rotation | NAIF `BODY10_PM = 84.176 + 14.18440 d` degrees in its TDB convention; 25.379994924-day sidereal grid period, not all plasma or a synodic day |
| Solorbitron | Sun's barycentric trajectory | Can inspect the actual carried Sun states; no universal fixed orbital period invented |
| Solardian | Heliocentric spherical coordinates with light-distance radius | Origin, axes, units, angle ranges and undefined pole/origin angles retained |
| SSD | Optional synthetic System State Day | No duration adopted; averaging periods versus frequencies gives different designed units |
| System Year | Phase in an adopted Galactic-orbit model | No exact clock/calendar year inferred from the approximate Galactic orbital timescale |
| Frozen display plane | Angular-momentum-weighted orientation at a declared epoch | If shown, retain body set, mass/GM source, epoch and matrix; do not recompute old conventions silently |

The solar-grid constant is retained in [NASA NAIF pck00011](https://naif.jpl.nasa.gov/pub/naif/generic_kernels/pck/pck00011.tpc). Exact SI `c=299792458 m/s` and IAU `au=149597870700 m` define light-distance conversions; measured positions remain uncertain. [JPL astrodynamic parameters](https://ssd.jpl.nasa.gov/astro_par.html)

## Data service and later deployment

The default deliverable is a static, reproducible snapshot. No key or external service is required to explore it. Future refresh should run **server-side**, query Horizons sequentially, cache and validate returned records, publish a versioned pack plus a hash manifest, and serve that static product from the atlas's own origin. JPL's public policy explicitly excludes embedding its API calls directly in arbitrary websites and asks for serial requests. A cached build or scheduled worker fits this boundary better than every visitor making NASA calls. [JPL API policy](https://ssd-api.jpl.nasa.gov/doc/index.php)

An AI service may help classify documents or explain source provenance, but it should not invent astronomical samples, overwrite authoritative values, remove error flags, or supply fake uncertainty bounds. Google/Gemini is not necessary for the numeric pipeline. A later Cloudflare deployment needs its own credentials, publishing authority, cache policy and monitoring; a local proof of concept is not a deployed service.

## Test record and reproducibility

Run `node tests/astro-tests.cjs`. The current science-kernel suite passes **41 checks**, including imported-pack validation, unchanged stored samples, no extrapolation, scale transformations, leap accounting, geometry singularities, body identity, future-UTC labeling, and known degraded modes. The original test author initially typed two incorrect expected constants (the J2000 TCB offset and the solar-grid period); those test fixtures were corrected against ERFA and direct arithmetic, not by changing recovered ephemeris bytes or weakening a failed physical check.

For the optional independent reference test, install `pyerfa==2.0.1.5` in the documented local test dependency location and run `python tests/check-erfa.py`. The retained report records the exact reference package. `tools/fetch-horizons.py` reconstructs the numeric pack from cached original responses by default; fetching new responses creates a new provenance event and must not silently replace the published snapshot. `tools/prepare-science-data.py` rebuilds the EOP subset, retained approximate elements and ERFA-derived nutation coefficients from their identified source files.

The review supports a **scientifically traceable educational and research interface**. It does not establish a certified spacecraft navigator, universal physical clock, measured human orientation, operational galactic orbit solver, or empirical proof of the separate Earth-for-life policy proposal.