Kosmogram można zweryfikować tylko wtedy, gdy oprócz obrazu zachowano pełną metrykę obliczenia. Sama data, godzina i miejscowość nie wystarczają. Potrzebne są również zasady konwersji czasu, dokładne współrzędne, ustawienia zodiaku i domów, typy punktów obliczeniowych, źródło efemerydy, wersja programu oraz wartości przed zaokrągleniem.

Dobrze udokumentowany wykres pozwala innej osobie odtworzyć wynik bez zgadywania, porównać go w drugim narzędziu i wskazać źródło każdej rozbieżności. Dokumentacja nie jest dodatkiem redakcyjnym. Jest częścią wyniku.

Zrzut ekranu pokazuje rezultat, ale nie metodę

Koło kosmogramu może przedstawiać znaki, domy, planety i aspekty, lecz zwykle nie ujawnia wszystkich ustawień użytych do ich wyznaczenia. Nie wiadomo z niego, czy czas letni rozpoznano automatycznie, czy pozycje są tropikalne czy syderyczne, którego systemu domów użyto ani czy węzeł jest średni czy prawdziwy.

Grafika dodatkowo zaokrągla dane. Punkt opisany jako 12°34' może w pamięci programu mieć długość 12°33'30,4" albo 12°34'29,6". Oba wyniki wyglądają tak samo po zaokrągleniu do minuty, choć mogą znaleźć się po przeciwnych stronach bardzo ścisłego progu.

Minimalnym artefaktem kontroli powinna być więc para: czytelna wizualizacja oraz tekstowy rekord ustawień i surowych wartości. Plik obrazu pomaga zobaczyć strukturę, a rekord techniczny odpowiada na pytanie, jak ją policzono.

Najpierw zapisuje się dane przekazane przez użytkownika

Weryfikacja zaczyna się od rozdzielenia danych źródłowych od danych wyprowadzonych. Źródłowe są dokładnie tym, co podano: zapis daty, zapis godziny, nazwa miejsca oraz informacja o pochodzeniu godziny. Nie wolno zastępować ich od razu wartością poprawioną przez program i usuwać śladu pierwotnego zapisu.

Przy godzinie warto zanotować źródło, na przykład akt urodzenia, pamięć rodzinna, karta szpitalna lub późniejsza rektyfikacja. Osobne pole powinno określać niepewność: dokładna, zaokrąglona, przybliżona albo nieznana. Godzina 12:00 użyta z braku danych jest założeniem obliczeniowym, nie godziną urodzenia.

Przy miejscu należy zachować zarówno oryginalną nazwę, jak i rozpoznaną lokalizację. Dwie miejscowości mogą mieć tę samą nazwę. Historyczna nazwa może odpowiadać dzisiejszej jednostce administracyjnej, a geokoder może wybrać centrum gminy zamiast właściwej osady. Sam napis w nagłówku nie wystarcza do odtworzenia współrzędnych.

Czas wymaga pełnego łańcucha konwersji

Rzetelny rekord przechowuje lokalną datę i godzinę, identyfikator strefy IANA, zastosowane przesunięcie UTC oraz wynikowy moment UTC. Skrót taki jak CET, CST albo IST jest niejednoznaczny i nie zawiera reguł historycznych. Europe/Warsaw wskazuje zestaw reguł, z którego program może wybrać przesunięcie obowiązujące w danej dacie.

Warto zapisać również wersję bazy stref czasowych. IANA publikuje kolejne wydania tzdb, ponieważ przepisy zmieniają się, a dane historyczne są korygowane. Dwa programy korzystające z różnych wydań mogą inaczej rozstrzygnąć dawny zapis, nawet jeśli oba pokazują tę samą nazwę strefy.

Pełny ślad konwersji może wyglądać tak:

Jeżeli lokalna godzina przypada w luce albo powtórzeniu podczas zmiany czasu, rekord musi podać sposób rozstrzygnięcia. Automatyczne przesunięcie nieistniejącej godziny naprzód oraz arbitralny wybór pierwszego z dwóch powtórzeń nie mogą pozostać ukryte.

Lokalizacja musi być liczbą, nie tylko nazwą

Do obliczenia osi i domów potrzebne są szerokość i długość geograficzna. Dla pozycji topocentrycznych dochodzi wysokość. Metryka powinna podawać układ odniesienia, zwykle WGS84, kolejność pól, znaki kierunków i liczbę zachowanych miejsc dziesiętnych.

Zapis Warszawa jest wygodny dla człowieka, ale nie określa punktu. Zapis 52,2297 N, 21,0122 E można porównać. Jeśli współrzędne uzyskano przez geokodowanie, trzeba zachować dostawcę, identyfikator wyniku i informację, czy użytkownik zaakceptował punkt. Ręczna korekta powinna pozostawić poprzednią wartość w historii.

Nie należy zwiększać pozornej dokładności. Współrzędne odczytane z ogólnej mapy miasta nie stają się dokładniejsze przez dopisanie kolejnych cyfr. Do kontroli kosmogramu ważniejsza jest jawna niepewność punktu niż długa liczba bez wiarygodnego źródła.

Ustawienia astrologiczne tworzą osobną warstwę

Po zapisaniu faktów wejściowych przychodzi warstwa konwencji. Każdy z poniższych wyborów powinien mieć osobne pole:

• zodiak tropikalny albo syderyczny;
• dla zodiaku syderycznego nazwa i identyfikator ayanamshy;
• pozycje geocentryczne albo topocentryczne;
• system domów i jego kod w bibliotece;
• metoda syderycznych domów, jeśli dotyczy;
• węzeł średni albo prawdziwy;
• używany apogeum, Lilith lub inne punkty pomocnicze wraz z definicją;
• zestaw aspektów i orb dla każdego typu;
• zasada przypisywania planety do domu przy położeniu na wierzchołku;
• sposób traktowania retrogradacji, stacji i prędkości.

Nazwy skrócone bywają mylące. „Topocentric” może oznaczać topocentryczny punkt obserwacji planet albo system domów Policha-Page'a. „True node” nie wyjaśnia, czy program zwraca pozycję oscylującą według tej samej biblioteki co inne narzędzie. „Whole sign” powinno być nazwą systemu domów, a nie domyślnym wnioskiem wyprowadzonym z wyglądu koła.

Efemeryda i wersja programu są częścią wyniku

Swiss Ephemeris udostępnia różne tryby obliczeń, między innymi pliki Swiss Ephemeris, pliki JPL oraz algorytm Moshiera. Jeśli żądany plik nie jest dostępny, implementacja może przejść na fallback i zwrócić ostrzeżenie. Zapis samej nazwy biblioteki bez trybu, wersji i ostrzeżeń nie pozwala wykryć takiej zmiany.

Warto przechowywać co najmniej: nazwę biblioteki, jej wersję, nazwę lub serię plików efemerydy, flagi obliczeniowe, model Delta T, wybraną skalę czasu oraz komunikaty zwrotne. Dla programu internetowego potrzebna jest także wersja aplikacji albo identyfikator wydania, ponieważ interfejs może zmienić domyślne ustawienia bez zmiany samej biblioteki.

JPL Horizons ostrzega, aby przed obliczeniem sprawdzać ustawienia domyślne, w tym skalę czasu, układ współrzędnych i żądane wielkości. To ważna zasada ogólna: nazwa renomowanego źródła nie zastępuje kontroli parametrów. Dwa prawidłowe wyniki mogą opisywać inną skalę czasu, centrum obserwacji lub typ pozycji.

Surowe wartości przechowuje się przed formatowaniem

Do bazy należy zapisywać pełną wartość zwróconą przez silnik, a stopnie i minuty tworzyć dopiero w warstwie prezentacji. Zaokrąglanie po każdym etapie może kumulować błąd i utrudniać porównanie. Szczególnie ryzykowne jest ponowne przeliczanie wartości już sformatowanej do tekstu.

Rekord pozycji powinien obejmować co najmniej długość, szerokość, odległość i prędkość długości, jeśli są używane. Wierzchołki domów i osie powinny zachować pełną precyzję. Aspekty najlepiej wyprowadzać z surowych długości i zapisywać także rzeczywistą odległość kątową oraz odchylenie od aspektu, nie tylko nazwę „trygon” albo „kwadratura”.

Format wyświetlania jest oddzielnym ustawieniem. Wynik 29°59'59,6" może po zaokrągleniu do minuty pojawić się jako 0°00' następnego znaku. Metryka powinna umożliwiać sprawdzenie, czy zmiana znaku jest wynikiem surowym, czy efektem prezentacji.

Wzorcowy rekord można odczytać bez instrukcji autora

Poniższy skrócony przykład pokazuje strukturę, nie narzuca konkretnego formatu pliku:

{
  "input": {
    "localDateTime": "2026-09-25T14:00:00",
    "timeZone": "Europe/Warsaw",
    "utcOffset": "+02:00",
    "utc": "2026-09-25T12:00:00Z",
    "place": "Warszawa, Polska",
    "latitude": 52.2297,
    "longitude": 21.0122,
    "coordinateReference": "WGS84",
    "timeCertainty": "exact"
  },
  "calculation": {
    "zodiac": "tropical",
    "referenceCenter": "geocentric",
    "houseSystem": "Placidus",
    "node": "mean",
    "ephemeris": "Swiss Ephemeris",
    "libraryVersion": "2.10.03",
    "rounding": "display only"
  }
}

Do rekordu produkcyjnego dochodzą wersja tzdb, wersja aplikacji, identyfikator plików efemerydy, lista flag, wartości planet, osie, cuspy, aspekty i ostrzeżenia. Jeżeli czas jest przybliżony, potrzebny jest także przedział niepewności i informacja, które elementy zmieniają się w tym przedziale.

Weryfikacja przebiega od wejścia do interpretacji

Najskuteczniejsza kontrola nie zaczyna się od pytania, który program „ma rację”. Najpierw porównuje się kolejne warstwy:

1. Czy oba narzędzia otrzymały identyczny zapis lokalnej daty i godziny?
2. Czy użyły tej samej strefy IANA, reguły czasu letniego i momentu UTC?
3. Czy współrzędne mają tę samą kolejność, znaki i punkt na mapie?
4. Czy obie efemerydy liczą ten sam typ pozycji, z tej samej skali czasu i centrum odniesienia?
5. Czy zodiak, ayanamsha, domy, węzły i punkty pomocnicze są identyczne?
6. Czy porównywane są wartości surowe, a nie zaokrąglone etykiety?
7. Czy dopiero po zgodności geometrii porównuje się aspekty i interpretację?

Taka kolejność lokalizuje błąd. Różnica wszystkich planet o podobny kąt sugeruje zodiak lub ayanamshę. Rozbieżne osie przy zgodnych planetach wskazują na czas albo miejsce. Zgodne osie i odmienne pośrednie cuspy kierują uwagę na system domów. Rozbieżność tylko w węźle zwykle wynika z wyboru wersji średniej lub prawdziwej.

Niezależna kontrola nie polega na drugim ekranie tego samego programu

Najsilniejsza weryfikacja korzysta z drugiego silnika lub usługi o jawnej dokumentacji. Dla pozycji astronomicznych można przygotować porównanie ze Swiss Ephemeris, JPL Horizons albo usługą USNO, ale trzeba dopasować centrum, skalę czasu, układ odniesienia i rodzaj współrzędnych. Bez tego różnica nie dowodzi błędu.

Druga instancja tej samej aplikacji z tym samym kodem wykryje błąd wpisywania, lecz nie wykryje wspólnego błędu algorytmu. Z kolei porównanie dwóch niezależnych bibliotek może ujawnić rozbieżność modelu, ale wymaga tolerancji odpowiedniej do użytych danych. Oczekiwanie identyczności do ostatniej cyfry jest niewłaściwe, jeśli narzędzia używają różnych efemeryd lub teorii precesji.

Wynik kontroli powinien podawać obie wartości, różnicę liczbową, ustaloną tolerancję i werdykt. Zdanie „sprawdzone w drugim programie” nie jest protokołem. Protokół wyjaśnia, co porównano i które ustawienia zostały zrównane.

Historia zmian chroni odtwarzalność w czasie

Kosmogram zapisany dziś może zostać ponownie otwarty po aktualizacji tzdb, efemerydy albo aplikacji. System powinien przechowywać pierwotny wynik i jego metrykę, zamiast bez ostrzeżenia przeliczać wszystko według nowych domyślnych ustawień.

Jeśli ponowne obliczenie daje inną wartość, raport powinien rozróżnić zmianę danych wejściowych od zmiany silnika. Przydatne są wersje rekordu, data wygenerowania, suma kontrolna konfiguracji i lista migracji. Użytkownik może wtedy zobaczyć, czy zmieniła się godzina, współrzędne, baza stref czasowych, plik efemerydy czy reguła obliczeń.

Publiczne narzędzie Kosmogram urodzeniowy może upraszczać formularz, ale eksport wyniku powinien zachowywać techniczną metrykę. Dzięki temu wykres pozostaje użyteczny nie tylko jako obraz, lecz także jako odtwarzalny zapis obliczenia.

Lista kontrolna przed publikacją

Przed uznaniem kosmogramu za zweryfikowany trzeba móc odpowiedzieć „tak” na następujące pytania:

• Czy zachowano oryginalne dane i oznaczono ich niepewność?
• Czy zapisano strefę IANA, przesunięcie i moment UTC?
• Czy można wskazać dokładny punkt geograficzny i jego źródło?
• Czy określono zodiak, ayanamshę, centrum odniesienia, system domów i typ węzła?
• Czy znane są biblioteka, wersja, tryb efemerydy, flagi i ostrzeżenia?
• Czy surowe pozycje istnieją niezależnie od sformatowanych etykiet?
• Czy przykład da się odtworzyć w świeżej sesji?
• Czy niezależne porównanie używa zgodnych parametrów i jawnej tolerancji?
• Czy rekord zachowa wynik po przyszłej aktualizacji oprogramowania?

Jeśli któregoś elementu brakuje, nadal można korzystać z wykresu orientacyjnie, lecz nie należy przedstawiać go jako w pełni odtwarzalnego. Dobra dokumentacja nie usuwa wszystkich różnic między szkołami. Pozwala natomiast dokładnie ustalić, z którego wyboru każda różnica wynika.

Bibliografia

• Astrodienst, Swiss Ephemeris Programmer's Manual, flagi obliczeniowe, wybór efemerydy, czas UT i TT, funkcje domów, topocentrum oraz komunikaty błędów. Dokumentacja programistyczna (dostęp: 25.09.2026).
• Astrodienst, Swiss Ephemeris Documentation, zakres danych, porównywanie wyników z JPL Horizons oraz różnice między trybami efemerydy. Dokumentacja (dostęp: 25.09.2026).
• Internet Assigned Numbers Authority, Theory and pragmatics of the tz code and data, zakres tzdb, identyfikatory stref, wersjonowanie i ograniczenia danych historycznych. IANA Time Zone Database (dostęp: 25.09.2026).
• Internet Assigned Numbers Authority, How to Read the tz Database, budowa rekordów Zone i Rule oraz historyczne zmiany przesunięć. IANA (dostęp: 25.09.2026).
• Jet Propulsion Laboratory, Horizons System Manual, skale czasu, centra obserwacji, układy odniesienia i konieczność kontroli ustawień domyślnych. JPL Solar System Dynamics (dostęp: 25.09.2026).
• United States Naval Observatory, Astronomical Applications Glossary, definicje czasu uniwersalnego, dnia juliańskiego, ekliptyki i paralaksy. USNO (dostęp: 25.09.2026).