_no. Some are traditional numbers (safe to display). Others are opaque catalog ids (for support traces — not a public API contract).
Names, slugs, and numbers
Most entities arrive in three forms. They can look redundant —"pisces" and "pisces" — but they are three different access patterns, and for multi-word values they diverge:
Rule: key on the slug, show the name, log the number. For single-word values (
pisces) the slug and name happen to be identical, but only the slug is guaranteed stable — build on it.
Opaque catalog numbers
Fields ending in_no (system_no, planet_no, element_no, and similar) are GEOMETRY’s opaque catalog and system identifiers. They exist for auditing, tracing, and troubleshooting, and are not part of the public contract — do not key caches, foreign keys, or application logic on them. Use names and slugs for durable integrations.
If you hit unexpected results, include the relevant _no values in your report — they let us reproduce your exact case immediately. See Support.
Tradition numbers vs catalog numbers
Tradition numbers are safe to display and reason about. Catalog numbers should be treated as opaque.
Tarot (first mention): In this product, tarot means the 78-card tradition with Rider–Waite–Smith suits on the wire (
cups / wands / pentacles / swords). That is a deck lineage / vocabulary choice — not the same thing as (a) Tarot de Marseille suit language, (b) the French card game jeu de tarot, or (c) how majors are calculated from a Gregorian date (tarot_majors.greer vs tarot_majors.tarot_school). The Cosmic card (cardology playing-card spine) is separate and maps to tarot minors.
element_no means two different things
element_no appears in two lanes, and the value is read differently in each:
Classical elements have no atomic number, so
element_no is the one key present in both lanes. That is deliberate: element_no resolves for any element block, so you never need two code paths. Read it alongside element_name and treat the classical values as opaque.
The same applies to the element_no returned inside the celtic_ogham and norse_runes blocks — those are classical elements.
Glyph fields (alchemical_symbol and friends)
Some payloads include rare Unicode glyphs — notably periodic.alchemical_symbol on get_name (Unicode Alchemical Symbols U+1F700–U+1F77F, plus classical planetary marks).
Those characters are correct on the wire. If a chat-exported JSON shows a water wave, random pictograph, or other lookalike, the LLM rewritten the glyph — cards, cipher sums, and element names in that file are usually still fine. Verify with codepoints or re-call the tool. See FAQ.
Year fields and their boundaries
Thelunar, yearly, and calendar_years blocks carry cultural year numbers — year_no, hebrew_year_no, persian_year_no, vedic_year_no, chinese_year_no, and similar.
These are tradition numbers, safe to display: Hebrew 5787 is the anno mundi year, Vedic 1948 is Shaka Samvat, Persian 1405 is the Solar Hijri year.
Which year you get depends on where the date falls relative to each system’s own boundary — and those boundaries sit in different civil timezones. The full per-system table (Chinese/Vietnamese CST, Vedic IST, Hebrew/Dreamspell neutral, Persian GMT) lives in When it covers → Calendar boundaries.
Same payload, different family: moon_phase.*_anchor_dt, season.*_anchor_dt, and retrogrades_active.retro_start_dt / retro_end_dt / cazimi_dt look identical — bare YYYY-MM-DD — but are GMT sky-event days, not civil year windows. If your dates land near a year boundary or disagree with a local almanac by one day, read When it covers → Calendar boundaries before reconciling against another library.
Named moons
Deterministic flags and measures from storedmoon_phase anchors on get_date (GMT). No interpretive meaning.
Supermoon: NASA describes a full Moon near perigee (NASA Science — Supermoons). GEOMETRY uses the common published threshold distance < 360000 km. Example:
2018-01-31 is blood + monthly blue at 360199 km → is_supermoon: false.
Micromoon: full moon and distance > 405000 km.
Zero means “not applicable”
Where a lookup has no match, or a concept does not apply to that date, GEOMETRY returns a typed placeholder rather thannull:
So
"card_no": 0 alongside "card_name": "none" means no card for this date in this system — not card number zero. Check for the placeholder, not for null.
One documented exception: day_ruler.norse.deity in get_date is null on Saturdays. Old Norse laugardagr means “bath day” and carries no deity, so the payload says so rather than inventing one.
Catalog numbers are non-negative. If you ever see a negative value in a _no field, that is a bug — please report it.