Physically anchored sidereal reference, GNSA-JP1 realization, and SSM-JA-GNSA browser implementation
GNSA โ Galactic Nuclear-System Ayanamsa โ has been admitted under the declared SOR v2 project contract: ADMIT_GNSA.
GNSA defines an independently derived Galactic nuclear-system sidereal reference and deterministic transport. GNSA-JP1 provides its explicit Jyotisha phase realization, with tested modern sub-arcsecond continuity after J2000 binding to the Chitra Paksha Ayanamsa / Lahiri Ayanamsa phase.
independent Galactic reference -> ADMIT_GNSA -> GNSA-JP1 -> SSM-JA-GNSA
Outside-party end-to-end replication remains OPEN_NOT_YET_CONFIRMED.
Launch SSM-JA-GNSA v0.4.1 โ Live Panchang & Jyotish Software
GNSA-JP1 Panchang, charts, Vimshottari Dasha and transit observation โ directly in your browser.
Open directly in your preferred language:
English ย ย |ย ย เคนเคฟเคจเฅเคฆเฅ โ Hindi ย ย |ย ย เฒเฒจเณเฒจเฒก โ Kannada ย ย |ย ย เดฎเดฒเดฏเดพเดณเด โ Malayalam ย ย |ย ย เฎคเฎฎเฎฟเฎดเฏ โ Tamil ย ย |ย ย เฐคเฑเฐฒเฑเฐเฑ โ Telugu
All six links open the same frozen SSM-JA-GNSA v0.4.1 application with the selected presentation language.
GNSA-JP1 provides a strong modern-astronomical continuity result consistent with the operational stability of the Chitra Paksha Ayanamsa / Lahiri Ayanamsa โ without claiming independent proof of its absolute zodiac phase.
GNSA itself was constructed independently from a physically anchored Galactic nuclear-system reference and deterministic IAU 2006/P03 transport. GNSA-JP1 then binds that independently defined transport to the standard Lahiri Ayanamsa phase at J2000 TT. After that one-point phase binding, the tested modern-period differential remains sub-arcsecond.
This is scientifically meaningful because the modern continuity is obtained under the GNSA physical transport rather than by simply continuing the original Lahiri Ayanamsa implementation. It supports the operational stability and continuity of the Chitra Paksha Ayanamsa / Lahiri Ayanamsa over the tested modern period, while preserving the important boundary that GNSA-JP1 does not independently prove the inherited absolute zodiac zero.
The numerical difference is extremely small in ordinary chart position, while long-horizon Dasha boundary times can still separate by hours.
For one worked comparison:
13 August 2026, 09:00:00 PM โ New Delhi
Lagna
- GNSA-JP1:
8ยฐ19'40" Pisces - Chitra Paksha / Lahiri:
8ยฐ19'42" Pisces - displayed difference: approximately
2 arcseconds
Vimshottari Maha Dasha
| Boundary | GNSA-JP1 | Chitra Paksha / Lahiri | Difference |
|---|---|---|---|
| Ketu Maha Dasha start | 22 Dec 2021 08:17:57 |
22 Dec 2021 07:28:12 |
00:49:45 |
| Ketu Maha Dasha end | 22 Dec 2028 03:22:04 |
22 Dec 2028 01:28:12 |
01:53:52 |
| Mercury Maha Dasha start | 23 Dec 2124 18:01:16 |
23 Dec 2124 01:28:12 |
16:33:04 |
| Mercury Maha Dasha end | 24 Dec 2141 02:36:58 |
23 Dec 2141 07:28:12 |
19:08:46 |
This illustrates an important practical point:
very small angular difference -> nearly identical chart geometry, while long-horizon Dasha boundaries may differ by hours
The example is illustrative rather than a universal bound. Exact differences depend on the chart input, lunar position, Dasha boundary being compared, and the respective ayanamsa transport.
SSM-JA-GNSA is built on the same deterministic browser-observatory architecture previously exercised extensively through SSM-JA โ Runtime-Ephemeris-Independent Jyotish Atlas.
The same class of deterministic realization consistency is preserved in SSM-JA-GNSA under GNSA-JP1.
Earlier published SSM-JA observational checks include:
- Chicago sunrise and sunset continuity: multi-day realization from
15 May 2026through23 May 2026compared with corresponding post-event published timeanddate.com values. - Six-city Indian sunrise and sunset witness: New Delhi, Chennai, Kolkata, Mumbai, Nagpur and Guwahati compared with corresponding post-event Regional Meteorological Centre published values for
28 May 2026. - Long-horizon Vimshottari Dasha stability: geographically and timezone-sensitive cases exercised over century-scale Dasha timelines.
- Astana/Tashkent regional comparison: the same declared UTC-offset assumption produced the same corresponding long-horizon Dasha realization within the tested SSM-JA comparison.
- Explicit civil-time realization: timezone and UTC-offset assumptions remain visible, replayable and testable instead of being silently absorbed into an unknown calculation pathway.
These checks remain directly relevant to SSM-JA-GNSA.
Sunrise and sunset realization is ayanamsa-independent in this application architecture, so those observational continuity checks are unaffected by the change from Chitra Paksha / Lahiri to GNSA-JP1.
For sidereal outputs such as Nakshatra and Vimshottari Dasha, GNSA-JP1 introduces the expected small change in sidereal position. Exact Dasha boundary times therefore shift accordingly, while the underlying deterministic civil-time handling, Dasha arithmetic, replay behavior and long-horizon consistency remain governed by the same observatory architecture.
same observatory architecture + GNSA-JP1 sidereal realization -> deterministic GNSA Panchang and Jyotish observation
The GNSA release additionally verifies its own implementation through the frozen SSM-JA-GNSA self-contained acceptance suite:
75/75 PASS
SELF_CONTAINED_APPLICATION_ACCEPTANCE_PASSED
The earlier SSM-JA evidence and the current GNSA verification therefore complement each other:
exercised SSM-JA observatory architecture + GNSA scientific authority + GNSA-JP1 transport + GNSA application verification -> SSM-JA-GNSA
In SSM-JA-GNSA v0.4.1, no additional ayanamsa setting is required. The application already implements the frozen GNSA-JP1 realization.
For other software, exact GNSA-JP1 requires a custom/user-defined sidereal ayanamsa together with the GNSA time-dependent transport:
reference epoch = J2000 TT
reference JD = 2451545.0 TT
A_JP1(J2000 TT) = 23.8570923254552 deg
gamma_JP1 = 242.99462849792616 deg
A_JP1(t) = wrap360(G_GNSA(t) - gamma_JP1)
with:
transport = GNSA IAU 2006/P03 mean-ecliptic/equinox-of-date transport
A software package that permits only a fixed custom J2000 offset can reproduce the GNSA-JP1 phase at J2000, but cannot automatically be assumed to reproduce exact GNSA-JP1 at other epochs unless it also implements the same GNSA transport.
Accordingly:
built-in Lahiri != exact GNSA-JP1
and:
custom J2000 offset alone != complete GNSA-JP1
For exact use, either run SSM-JA-GNSA or use software capable of implementing both the frozen J2000 phase and the declared GNSA transport law.
The application is designed as a deterministic, offline, runtime-ephemeris-independent observational atlas. Its central reproducibility principle is:
supported_output = resolve(declared_structure)
and, within the declared release boundary:
same declared structure + same release conditions -> same realization
Current SOR v2 project-admission status: ADMIT_GNSA
Retained historical SOR v1 verdict: NOT_SCIENTIFICALLY_ESTABLISHED
Outside-party end-to-end replication: OPEN_NOT_YET_CONFIRMED
The retained v1 verdict has not been rewritten. ADMIT_GNSA means admitted under the declared SOR v2 project contract. It does not mean universal ayanamsa correctness, outside scientific-community establishment, or predictive validation of sidereal astrology.
SOR
|
v
GNSA
physical Galactic nuclear-system reference + deterministic transport
|
+--> GNSA-GC0
| physical-zero realization
|
v
GNSA-JP1
explicit Jyotisha phase realization
|
v
SSM-JA-GNSA v0.4.1
standalone browser implementation
GNSA uses a fixed barycentric ICRS J2000 ray representing the common Galactic nuclear-system direction and deterministic IAU 2006/P03 mean-ecliptic transport. GNSA is not a Chitra Paksha Ayanamsa refinement and does not depend on the retained Revati-Ashvini / Zeta Piscium bounded constraint.
gamma_JP1 = 242.99462849792616 deg
A_JP1(J2000 TT) = 23.8570923254552 deg
A_JP1(t) = wrap360(G_GNSA(t) - gamma_JP1)
The recorded J2000 phase provenance is the standard Lahiri Ayanamsa value from the declared historical Swiss Ephemeris research environment. The frozen constants define GNSA-JP1; the third-party implementation is not a live dependency of this primary package.
GNSA-JP1 does not independently prove the absolute Chitra Paksha Ayanamsa / Lahiri Ayanamsa zodiac zero. Modern closeness to the Lahiri Ayanamsa is continuity after one-point phase binding plus the GNSA transport law.
For software that supports a custom or user-defined sidereal ayanamsa, the exact SOR v2 GNSA-JP1 realization requires both the frozen J2000 phase and the GNSA time-dependent transport.
Use the following definition:
sidereal mode = custom/user-defined ayanamsa
reference epoch = J2000 TT
reference JD = 2451545.0 TT
A_JP1(J2000 TT) = 23.8570923254552 deg
gamma_JP1 = 242.99462849792616 deg
transport = GNSA IAU 2006/P03 mean-ecliptic/equinox-of-date transport
A_JP1(t) = wrap360(G_GNSA(t) - gamma_JP1)
A software setting that only accepts a fixed J2000 offset, or that applies a different built-in precession/ayanamsa time law, can match the GNSA-JP1 phase at J2000 but cannot be assumed to reproduce exact GNSA-JP1 values at other epochs.
Accordingly, selecting a built-in Lahiri Ayanamsa setting is not the same as selecting GNSA-JP1. The standard Lahiri Ayanamsa supplies the recorded J2000 phase provenance; GNSA supplies the independently defined physical transport used by GNSA-JP1.
Current release characteristics:
- single-file HTML application;
- approximately
40 MBinternal source Golden CSV distilled into an approximately6 MBstandalone HTML release; - supported input range:
01 Jan 1950through31 Dec 2100; - embedded deterministic position kernel and non-Moon speed payload;
- GNSA-JP1 ayanamsa transport;
- Rasi and Navamsa charts;
- Vimshottari Mahadasha, Antardasha, Pratyantardasha and Sookshma hierarchy;
- Panchang and Transit observation;
- six presentation languages: English, Hindi, Kannada, Malayalam, Tamil, and Telugu;
- direct language startup through
?lang=en,?lang=hi,?lang=kn,?lang=ml,?lang=ta, and?lang=te; - Share State replay/import and JSON export;
- Brief and Detailed print/report workflows;
- responsive desktop and mobile presentation;
- browser-side embedded-kernel SHA-256 integrity verification;
- project-assembled 3,277-location factual atlas;
- no external CSV loading at runtime;
- no external ephemeris API at runtime;
- no cloud/server calculation dependency;
- no runtime HTTP/geocoding lookup endpoint.
Core invariant:
same file + same inputs + compatible browser conditions -> same deterministic realization
v0.4.1 is an offline-hardening maintenance release over v0.4.0. The dormant legacy external-geocoding handler was removed and application identity strings were advanced to v0.4.1. No astronomical constants, kernels, interpolation rules, GNSA/GNSA-JP1 mathematics, Dasha rules, Panchang rules or chart calculations were changed.
The hardened source has no runtime fetch(), XMLHttpRequest, WebSocket, EventSource, sendBeacon, external script URL or external stylesheet URL path.
The primary package contains no executable project Python script that imports Swiss Ephemeris or pyswisseph.
Historical project research and verification environments used Swiss Ephemeris / pyswisseph for selected provenance and cross-toolchain checks. Relevant project-generated result receipts are retained as frozen research records; the third-party executable dependency itself is not distributed in the primary package.
This preserves the evidence record while separating it from the runnable primary distribution.
Current primary verifier:
GNSA_JP1_Application_Self_Contained_Acceptance_Suite_v1_1_1.py
Current result:
75/75 PASS
SELF_CONTAINED_APPLICATION_ACCEPTANCE_PASSED
runtime HTTP requests observed = 0
page errors = 0
The suite checks source identity, frozen constants, strict-offline behavior, runtime kernel-integrity state, five exact frozen regression vectors across the supported range, deterministic replay, Dasha/Transit/Panchang behavior, language and Share State, export/print paths, input boundaries and retained-receipt consistency.
The v1.1.1 verifier is read-only by default. It does not rewrite the frozen v1.1.0 stored receipt during normal verification. An explicit --write-result option creates a local v1.1.1 receipt outside the package SHA manifest.
Historical cross-toolchain application receipt retained:
GNSA_JP1_Application_Acceptance_v1_0_2_Result.json
76/76 PASS
APPLICATION_LEVEL_ACCEPTANCE_PASSED
page_errors = []
That historical receipt records the earlier 10,000-instant direct cross-toolchain holdout. It is retained as evidence and is not live-rerun by the primary package.
Open or download:
SSM-JA-GNSA v0.4.1 standalone HTML
Then open the file in a modern browser. No server, account, cloud service or external ephemeris service is required for the application itself.
Chart, Panchang, Dasha and Transit calculations run locally in the browser. The application requires no account, login or cloud calculation service, and does not transmit chart inputs to a remote calculation engine.
Optional user-saved location presets are retained locally in the browser.
local calculation + no runtime calculation service -> user-controlled observation
Requirements:
Python 3
Playwright for Python
Playwright-managed Chromium or compatible browser
Example:
python -m pip install playwright
python -m playwright install chromium
python -B GNSA_JP1_Application_Self_Contained_Acceptance_Suite_v1_1_1.py
Playwright/browser software is a verification toolchain, not an application runtime dependency and is not bundled in this package.
The guarded Golden CSV is an internal project reference and is not included in this repository package.
The standalone HTML contains compact project-generated deterministic kernel data produced through the project Golden workflow. It does not load the guarded CSV at runtime. The Golden CSV is not required to define GNSA or GNSA-JP1.
The embedded location atlas contains 3,277 place-name, coordinate and timezone records.
The atlas was assembled within the project from individually resolved factual geographic metadata. It was not copied, imported, scraped or extracted as a database from any third-party location database.
The underlying place names, coordinates and timezone identifiers are treated as factual metadata; the project does not claim ownership of underlying geographic facts.
The application performs no runtime geocoding request and contains no runtime dependency on a third-party location database or geocoding service.
The repository does not relicense third-party software, source material, catalogues, services, translations or externally governed datasets.
- Swiss Ephemeris / pyswisseph is not bundled and no executable primary-package project script imports it.
- Historical project-generated receipts from declared Swiss/pyswisseph verification environments may be retained.
- The guarded Golden CSV is not distributed.
- G2 source catalogues are not distributed as bulk source objects.
- The historical G1/G2 precommit filename and SHA-256 are preserved as provenance; the exact historical precommit object is not distributed and no byte-identity claim is made for the packaged precomparison object.
- The location atlas is project-assembled from individually resolved factual metadata rather than copied as a third-party database.
GNSA / GNSA-JP1 / SSM-JA-GNSA does not claim universal or sole correctness, rewriting of the retained SOR v1 verdict, outside-party end-to-end confirmation, independent proof of the inherited absolute Chitra Paksha Ayanamsa / Lahiri Ayanamsa phase, formal astronomical certification, predictive validation of sidereal astrology, or professional/legal/medical/financial/safety authority.
The historical GNSA-JP1 v0.10.0 expected-output commitment is preserved unchanged, but its recorded reveal hash does not match the current distributed reveal/comparison file. The historical commitment is therefore not claimed to authenticate that distributed file.
- GNSA release SHA-256 manifest
- Scientific status
- Scientific chain
- Claim boundaries
- Evidence status levels
- Reproducibility scope
- Independent replication receipt schema
- Structural Observatory architecture
See: LICENSE
See also: THIRD_PARTY_NOTICES.txt
The GNSA / GNSA-JP1 / SSM-JA-GNSA reference implementation and verification artifacts are free to use, copy, modify, test, study, and redistribute without a license fee, subject to the terms stated in the LICENSE.
Documentation, architecture materials, specifications, diagrams, and explanatory content are subject to the separate terms stated in the LICENSE, including applicable non-commercial use conditions.
Third-party software, dependencies, source material, catalogues, services, translations, datasets, and other externally governed materials remain subject to their own applicable rights and terms and are not relicensed by this repository. The Third-Party Notices define the declared third-party and provenance boundary.
This repository does not claim recognition as a formal technical standard, scientific certification, production qualification, or third-party verification.
physical reference -> deterministic transport -> explicit phase -> offline reproducible realization
Part of the Shunyaya Framework.