Hi DBnomics team,
I’d like to report a data issue in the ism-fetcher
(dbnomics-fetchers / ism-fetcher · GitLab).
Summary
Starting with the September 2025 observation, the pmi dataset
(ISM/pmi/pm) returns values that match the “% Higher” component
of the ISM Manufacturing Report On Business rather than the
headline Manufacturing PMI Index. The other 10 manufacturing
datasets (neword, production, employment, supdel, inventories,
cusinv, prices, bacord, newexpord, imports) look correct.
Evidence
DBnomics ISM/pmi/pm vs. the headline PMI published by ISM
(https://www.ismworld.org/supply-management-news-and-reports/reports/ism-report-on-business/):
Month DBnomics pmi/pm ISM published PMI
2025-07 48.0 48.0
2025-08 48.7 48.7
2025-09 11.1 ~49 (per ISM)
2025-10 10.0 ~49
2025-11 10.0 ~49
2025-12 10.3 ~49
The values from September onward are in the magnitude range of
the “% Higher” component of an ISM diffusion index, not the Index
itself (which is bounded ~30–70 historically).
Reproducer
curl -s ‘https://api.db.nomics.world/v22/series/ISM/pmi?observations=1’
| jq ‘.series.docs[0] | {series_code, last:
[.period_start_day[-6:], .value[-6:]] | transpose}’
Cross-check: sub-indices look correct
Every sub-index dataset exposes 5 series (hi, in, lo, ne, sa);
the in (Index) series matches the ISM release in every case
I checked. For example, ISM/neword/in 2025-12 = 47.7, matching
the published New Orders Index for that month.
The pmi dataset is the only one that exposes a single series
(pm, nb_series: 1). That asymmetry suggests the parser has a
dedicated code path for the PMI summary table which became
misaligned when the upstream HTML changed.
Suspected cause
The README notes each indicator’s HTML table contains multiple
columns (“% Higher”, “% Same”, “% Lower”, Net, Index). The
pattern of the bad values — small single-digit-to-low-teens
numbers appearing consistently from one specific release onward —
is the signature of a fixed column-index becoming wrong after an
upstream layout change. The August 2025 ISM release is the last
month before the regression, so a layout change at ismworld.org
around that release is the most likely trigger.
Suggested remediation
- Compare a cached source HTML file from September 2025 onward
against the August 2025 version to confirm whether the column
ordering or table structure differs. - If so, switch the PMI parser from positional column extraction
to header-name lookup (“Index” / “PMI”), matching what the
sub-index parser already appears to do. - Re-run the fetcher for 2025-09 through latest to backfill
corrected values.
Impact
Downstream consumers pulling ISM/pmi/pm are silently showing
values that look like a historic recession indicator. We caught
this while building a heatmap that flagged the >37-point
month-over-month “drop” as an anomaly.
Happy to provide more detail or help test a patch.
Thanks!