Data-quality bug: ISM pmi dataset returning "% Higher" values instead of headline PMI since 2025-09

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

  1. 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.
  2. 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.
  3. 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!