Changelog

Ingested 2 new monthly reports (Trueblood-Report-2026-07.pdf, -2026-08.pdf), adding periods 2026-06 and 2026-07 to the panel. Per this pipeline's own report-redundancy convention (keep the newest report's successful read of a given month), every facility/stage/setting row's citation for these 12 already-published periods moved to Trueblood-Report-2026-08.pdf, since its own 13-month table window now covers all of them. For 6 specific rows -- all period 2026-05 -- the underlying value itself also changed by +-1 (WSH/ESH eval-jail orders_signed, WSH/ESH/TOTAL restoration-inpatient orders_signed or orders_completed, TOTAL eval-jail both counts): this is a source-side revision WA's own report explicitly discloses via 'matured data' lavender-highlighted cells in Table 3/6/9 (see Trueblood-Report-2026-07.pdf and -2026-08.pdf's own 'Class Member Status Data Tables' intro note: 'data highlighted in lavender indicate a data value that has matured and has been updated during the most recent reporting period') -- not a pipeline defect. All 22 new rows (2026-06, 2026-07) and all 6 revised values were hand-verified directly against the source PDF tables before this commit.

Maximum-security waitlist_count was pulled from Table 10's "Maximum Security" row -- the not-yet-facility-assigned subset of the waitlist, per HHSC's own footnote ("people do not directly admit from the maximum security list") -- instead of the Total row, which is the true full MSU waitlist (unassigned + already-assigned-but-still-waiting). Found in a full source-PDF audit (meta/docs/data_validation_2026-09-11/tx_pass1_findings.md), independently confirmed by direct inspection of each cited PDF page. Understated the true count by 5-16% across all 8 affected quarters (e.g. 2025-08: 419 shown, 484 actual). avg_wait_days for these same rows remains an intentional, disclosed gap (see dashboard/code/tx_hhsc.py comments) -- not part of this correction.

The is_multi_month_avg disclosure column (added earlier this same day, commit f748f1b) was wrong for these 4 rows (both tiers, 2024-07 and 2024-10): shipped False (true single month) when the source is actually a 3-month rolling average. Cause: sm_2025-05-28.pdf's range-column headers glue the dash directly onto the month with no space ("May–", "Aug–"), which the month-detection regex didn't match, silently dropping that month from range detection. Fixed the regex to tolerate a glued dash; confirmed via corpus-wide scan this exact pattern occurs only on this one page. The underlying `value` for these rows did not change, only the disclosure flag.

A pipeline fix this same day (recovering rows previously dropped when a table's day/percent columns are all genuinely "n/a") surfaced a genuine revision in DSHS's own published data: Trueblood-Report-2021-09.pdf originally printed Aug-2021 OCRP as 1 order signed / 1 completed / 3.0 avg days / 100% compliance; Trueblood-Report-2022-09.pdf (a year later) revised the SAME Aug-2021 row down to 0 signed / 0 completed / n/a. Confirmed directly against both PDF pages -- not a parsing error. Per this pipeline's existing convention, the most recent report's figure is kept.

pct_within_alt3 was shipping as 43% (from Trueblood-Report-2023-06.pdf), but the same row was revised to 50% the following month (Trueblood-Report-2023-07.pdf p.19) -- every other field identical between both reports. Normally the newest report wins automatically, but 2023-07.pdf is one of the reports whose table-detection this pipeline can't currently recover (see wa_batch2_findings.md Part 5), and Jun-22 rolls out of every later report's 13-month window, so it can't self-heal. Hand-corrected after directly verifying both source PDF pages.

Same issue and fix as the ESH/evaluation/jail 2022-06 entry above, for the WSH+ESH combined total: pct_within_alt3 shipping as 78% (Trueblood-Report-2023-06.pdf), revised to 82% in Trueblood-Report-2023-07.pdf p.22 (a report whose table-detection this pipeline can't currently recover). Hand-corrected after directly verifying both source PDF pages.

is_multi_month_avg shipped blank (unknown) for all 4 of sm_109331.pdf's wait-day columns -- found by the 10-agent public-repo audit (data_validation_public_2026-09-11/co_pass1_findings.md). Root cause: the 2020-01 column's header prints its completing year as a single glued token "2019/20" (every other range header in the corpus uses a plain "2020"), which the year-detection regex didn't match at all, so the column's own multi-month-ness could never be determined. Fixing that regex also exposed a second, previously-dormant bug in the same function: a 45px header-search radius that let one header word satisfy two adjacent narrow-spaced columns at once (this file's columns sit closer together than the rest of the corpus), which had been silently masked by the first bug. Fixed both; the underlying `value` for all 4 rows is unchanged -- period 2020-01 is now correctly True (a genuine "Nov-Jan 2019/20" 3-month range), periods 2020-02/03/04 are now explicitly False instead of blank.

is_multi_month_avg shipped blank (unknown) for these 10 Tier-2 wait-day rows across sm_109331.pdf/sm_2023-11-28.pdf/sm_2024-02-28.pdf/sm_2024-05-28.pdf, while the parallel Tier-1 rows for the identical periods were already correctly flagged -- found by the same public-repo audit (data_validation_public_2026-09-11/co_pass1_findings.md), which identified it as a reproducible Tier-2-specific pattern. Root cause: a range-header column that wraps its completing month onto a second physical PDF text line sits far enough above a Tier-2 row that this file's header-search band (deliberately kept narrow after an earlier, unrelated widening caused a real regression on count-table rows, reverted the same session) doesn't reach it, while the closer Tier-1 row's own band does. Fixed by borrowing the already-correctly-resolved header axis from the sibling Tier-1 row in the same table when a row's own axis can't be resolved (same fix pattern as wa_trueblood.py's sibling-row column-layout borrowing). The underlying `value` for all 10 rows is unchanged, only the flag.