> ## Documentation Index > Fetch the complete documentation index at: https://docs.geometry.app/llms.txt > Use this file to discover all available pages before exploring further. # Field glossary > What the numbers in the payload mean — and which ones to build on. # Field glossary Every GEOMETRY payload carries numeric fields ending in `_no`. Some are traditional numbers you already know. Others are internal identifiers. This page tells you which is which. ## Internal catalog numbers Fields ending in `_no` (`system_no`, `planet_no`, `element_no`, and similar) are GEOMETRY's internal 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](/support). ## Tradition numbers vs catalog numbers | Field | Kind | What it means | | --------------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `card_no` | **Tradition** | Cosmic deck position, 0–53. Suits run hearts → clubs → diamonds → spades: A♥ = 1 … K♥ = 13, A♣ = 14 … K♣ = 26, A♦ = 27 … K♦ = 39, A♠ = 40 … K♠ = 52. Jokers are **0** and **53**. | | `tarot_no` | **Tradition** | Standard tarot numbering. Majors 0–21, minors continue the sequence. | | `iching_no` | **Tradition** | King Wen hexagram number, 1–64. | | `atomic_no` | **Tradition** | Periodic table atomic number. Hydrogen = 1. | | `chakra_no` | **Tradition** | Chakra position, 1–7 (13 in the extended set). | | `house_no`, `pada_no` | **Tradition** | Astrological house 1–12; nakshatra pada 1–4. | | `nakshatra_no` | **Tradition** | Standard Vedic order, 1–27. Ashwini = 1 … Revati = 27. | | `planet_no` | **Catalog** | Internal body id. **Not** orbital order, Swiss Ephemeris index, or any astronomical numbering — don't infer meaning from the value. Use `planet_name`. | | `system_no` | **Catalog** | Registry id for a symbolic system. Not a rank, not an API version. Use the system slug or name. | | `element_no` | **Catalog** | Element id — see below. | | `sign_no` | **Catalog** | Position on *that wheel's* own catalog, not a universal zodiac index. Different wheels reuse the same numbers for different signs. Use `sign_name`. | | `unicard_no` | **Catalog** | Position within one deck's own catalog. Ranges differ per deck, so the same value means different things in different decks. Use `unicard_name`. | | `geomancy_no` | **Catalog** | Our ordering of the sixteen traditional geomantic figures, 1–16. The figures are traditional; the numbering is internal. Use `geomancy_name`. | Tradition numbers are safe to display and reason about. Catalog numbers should be treated as opaque. ## `element_no` means two different things `element_no` appears in two lanes, and the value is read differently in each: | Block | Example | Reading | | ------------------- | ------------------------------------------- | -------------------------------------------------------------------------------- | | `periodic_element` | `element_no: 34`, `atomic_no: 34` | Periodic lane — matches the atomic number. | | `classical_element` | `element_no: 1700`, `element_name: "earth"` | Classical lane — an internal catalog id. Earth is **not** periodic element 1700. | 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. ## Year fields and their boundaries The `lunar`, `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 that system's boundary — and those boundaries are **not all in the same timezone**. Chinese and Vietnamese use CST, Vedic uses IST, Hebrew and Dreamspell are timezone-neutral, and Persian uses GMT rather than Iran's Tehran-local rule. **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 [Calendar boundaries](/calendar-boundaries) before reconciling against another library. ## 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 than `null`: | Type | Placeholder | | ---------------------- | ----------- | | Numbers | `0` | | Names and text | `"none"` | | Symbols, glyphs, emoji | `""` | | Lists | `[]` | 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_day_card`](/tools/get-day-card) 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](/support). ## Rule of thumb Build on **names and slugs**. Display **tradition numbers** when they are meaningful to your users. Log **catalog numbers** so support can trace your exact case.