Problem
The US calibration target surface (target_surface_raw.npz) persists each target only as a flattened slash-joined string name, under three inconsistent conventions:
state/<source>/<variable>/<STATE_ABBR> — e.g. state/bea/wages_and_salaries/AL
nation/<source>/<variable>[/<dims>] — e.g. nation/irs/adjusted gross income/total/AGI in 10k-15k/taxable/All
US<fips>/<metric> — e.g. US01/snap-cost
Any consumer that wants to group, filter, or display targets by criteria (geography, source, variable, breakdown) has to re-parse these strings. The populace.dev /calibration page does exactly this today (scripts/build_dashboard_data.py: parse_target) — brittle and convention-dependent, and it loses information where the conventions disagree (e.g. US<fips> rows carry no source).
The target registry already knows the structured fields at construction time; the surface just drops them on export.
Ask
Have the exported target surface carry structured per-target fields alongside (or instead of) the flattened name — geography (+ level), source, variable, breakdown — mirroring the long-format schema the policyengine-us-data calibration targets already use:
DATA_SOURCE, GEO_ID, GEO_NAME, VARIABLE, VALUE, IS_COUNT, BREAKDOWN_VARIABLE, LOWER_BOUND, UPPER_BOUND
Acceptance criteria
- The exported target surface includes structured per-target fields (geography + level, source, variable, breakdown) with a stable, documented schema.
- A consistent geography key across the three conventions (national / state-abbr / state-FIPS).
- Diagnostics consumers (populace.dev
/calibration, the observatory) read the structured fields directly — no slash-string parsing in the consumer.
Related
Problem
The US calibration target surface (
target_surface_raw.npz) persists each target only as a flattened slash-joined stringname, under three inconsistent conventions:state/<source>/<variable>/<STATE_ABBR>— e.g.state/bea/wages_and_salaries/ALnation/<source>/<variable>[/<dims>]— e.g.nation/irs/adjusted gross income/total/AGI in 10k-15k/taxable/AllUS<fips>/<metric>— e.g.US01/snap-costAny consumer that wants to group, filter, or display targets by criteria (geography, source, variable, breakdown) has to re-parse these strings. The populace.dev
/calibrationpage does exactly this today (scripts/build_dashboard_data.py: parse_target) — brittle and convention-dependent, and it loses information where the conventions disagree (e.g.US<fips>rows carry no source).The target registry already knows the structured fields at construction time; the surface just drops them on export.
Ask
Have the exported target surface carry structured per-target fields alongside (or instead of) the flattened name —
geography(+level),source,variable,breakdown— mirroring the long-format schema the policyengine-us-data calibration targets already use:Acceptance criteria
/calibration, the observatory) read the structured fields directly — no slash-string parsing in the consumer.Related
/calibrationpage now realizes this, parsing the slash names as a stopgap until this issue lands.