Locationdex — the place axis (Framework Extension)

Status: framework extension · Opened: 2026-06-19 · Owner: Mike (mental model) + Claude (engine room) · Parent: docs/event-spine-framework.md, docs/dex-data-model.md, and the sibling docs/yeardex-framework.md.

Mike coined Locationdex on 2026-06-19 while draining the admin datasource backlog, on reaching the safecast radiation feed: "maybe the next dex type could be Locationdex, so each slot is the geographical location of the sensor." It is a first-class third family, not a side branch.

The one idea

The dex organizes measured data into indexed slots. Two axes already exist:

• Eventdex — a slot is one event (a tornado, an eruption, a chirp). Indexed by when it happened.
• Yeardex — a slot is one year of a statistical series. Indexed by which year.

Locationdex adds the third natural axis:

• Locationdex — a slot is one fixed place that hosts a sensor: a station, an observatory, a gauge, a monitoring site. Indexed by where it is.

A station is a stable, addressable, revisitable thing with an ID (its station code and its coordinates), exactly as an event has a stable ID and a year has its number. So a place qualifies as a slot under the same rules that let a hurricane or a year be a slot. The difference is only the axis: Eventdex indexes by event, Yeardex by year, Locationdex by place.

Why it was needed: the orphaned station networks

The dex coverage map had a whole category filed under "not dex material — continuous monitoring time series": magnetic observatories (INTERMAGNET), tide gauges (NOAA), streamgauges (USGS), neutron monitors (NMDB), fixed radiation posts. They are neither events nor years. But they are not un-indexable — they are places that report over time. Locationdex is their home. The reason they read as "not dex material" was that the dex had only an event axis and a year axis; the place axis they actually live on was missing.

What qualifies for Locationdex (vs Event / Year)

Use Locationdex when the data is a network of fixed sites, each reporting a continuous or repeated measurement from one stable location:

• A stable place ID — a station code and coordinates that do not move. A roving sensor (a car-mounted radiation logger; a research vessel) is not a Locationdex slot; its location is a track, not a place. (Mobile data is organized differently — by geographic cell — and is the considered-later case, not this family's slot.)
• Measured-reality provenance — the site records what is physically measured at it (a count rate, a water level, a field strength), not a model of it.
• A network worth a roster — several sites, deep enough to backfill the full published roster on day one (no-spiking: the full network, not the handful a live fetcher happens to stream).

The qualification test mirrors the spine test: a stable slot ID, measured provenance, and a roster with mass.

What a station slot holds

A Locationdex slot is catalog-first: the slot is the place plus what we know and measure there.

• Identity + place: code, name, jurisdiction, latitude, longitude, altitude, coordinate provenance.
• Instrument character: the permanent properties that distinguish this site from its peers (a neutron monitor's cutoff rigidity; a tide gauge's datum; an observatory's baseline).
• Measured-series summary, cited: a roll-up of the site's staged time series (coverage span, count, central value and range) with a pointer to the underlying observations. The raw series stays where it is (the platform's normalized observations); the slot summarizes and cites it.

A place is genuinely a place, so — unlike a Yeardex year, where "a year is not a place" makes a spatial sweep meaningless — a Locationdex slot can support a spatial sweep later (what else our sensors recorded near this site). That is an allowed extension, deferred until a kind needs it; the base family is catalog + series-summary.

Multi-source cited slots (universal rule applies)

A station slot obeys the universal cited-slot rule (docs/yeardex-framework.md Part 2): it accretes data from more than one source, each datum cited. The pilot already shows two: the registry that says where the station is, and the measured series that says what it records, each attributed. A second catalog describing the same station (a different network's metadata for the same site) would enrich the one slot, cited, never duplicate it.

Storage

A third sibling storehouse, data/location_storehouse/<kind>/<slot_id>.json, beside event_storehouse/ and year_storehouse/. It reuses the shared event_storehouse write + disk-rebuilt-index machinery via the base_dir argument, exactly as the Yeardex did — parallel lists per the data model, stitched into a combined view only if a whole-dex walk is ever wanted.

Measured-reality bright line

Binding, unchanged: a slot accretes measurements of what physically happened at the place, never a model's estimate. A recorded count rate is in; a modeled or interpolated grid value standing in for a missing station is out.

Frozen vs open

Frozen (2026-06-19, Mike):

• Locationdex exists as a first-class third family: the slot may be a fixed place (a station/site).
• A roving sensor is not a slot; its location is a track. Mobile data is organized by geographic cell, a separate later question, not this family.
• The measured-reality bright line and the multi-source cited-slot rule both bind.

Open (decided per kind, in each docs/scope-*.md freeze):

• Which network; roster source and slot-JSON shape; whether and when a kind turns on the spatial sweep; how (and whether) mobile/roving data gets a binned-cell treatment.

Sequencing

1. This framework doc — defines the family. ✅ (this file).
2. First Locationdex kind — neutron_monitor (NMDB), docs/scope-neutron-monitor-locationdex.md, 64-station deep-pull roster. Proves slot = place end to end. ✅ 2026-06-19.
3. Scale across the other fixed-station networks (tide gauges, magnetic observatories, streamgauges), each its own scope freeze. Bring safecast in later as the binned-mobile special case.

Same discipline as every kind: scope frozen before backfill and never tuned to results; full-roster deep pull, not the thin live slice; Mike rules the load-bearing categorization calls.