Definitional, coverage and schema incompatibilities encountered while building the elder-care baseline. Per housing's precedent, this list is itself an output — the places where a data source's own schema is a trap are findings about the measurement system, not housekeeping.
| # | Incompatibility | Consequence | Disposition |
|---|---|---|---|
| 1 | ACS table-based Summary File .dat rows are GEO_ID|E001|M001|E002|M002|... — estimate E_n sits at 0-indexed field 2n-1, not 2n. A first-pass build script off-by-one pulled the margin-of-error column for the total-population variable instead of the estimate, and MOE for a Census-controlled total is the jam value -555555555 |
Produced a nonsensical negative national population (-555,555,555) that was caught immediately on inspection, not silently reported | Fixed in build_baseline.py; the row-index derivation is now commented inline with the field-layout math shown |
| 2 | The Census geography lookup file's SUMLEVEL column alone (010=national, 040=state) is not sufficient to isolate the 50 states + DC + national: each state also carries SUMLEVEL 040 sub-breakdowns by metro/micro status (COMPONENT A0/C0/C1/C2/E0/E1/E2/G0/H0 — "in metropolitan statistical area", "not in principal city", etc.), and B01001 (age) is published at that geography granularity even though housing's B-tables were not |
A SUMLEVEL-only join silently admitted ~550 extra geographies (603 vs. the correct 53), each a real sub-state aggregate, not an error value — harder to catch than incompatibility #1 because the numbers all looked plausible individually |
build_baseline.py matches GEO_ID by exact string form (0100000US, 0400000US##) instead of joining through SUMLEVEL/COMPONENT — the same defensive pattern housing/baseline/scripts/build_baseline.py:265 already uses (g.startswith("0400000US")), which is why housing's own baseline was never exposed to this bug: its tables simply weren't published at the contaminating geography level, not because its join logic checked for it |