HT2 TY2022 us.all qbi_amount ingested ~6.9x low ($31.3B vs IRS $215.7B); audit all HT2 QBID rows

HT2 TY2022 us.all.qbi_amount ingested ~6.9× too low; model was right, target was wrong

Record: irs_soi.ty2022.historic_table_2.us.all.qbi_amount (aggregate fact key ledger.aggregate_fact.v2:d87950054970536ebf78fa03 in the populace 2026-06-16 release diagnostics).

Ledger value as compiled into populace calibration: $31,307,205,000 (target 31307205000.0).

IRS actual (fetched 2026-07-24 from https://www.irs.gov/pub/irs-soi/22in55cmcsv.csv, US row, AGI_STUB 0):

• A04475 (QBID amount) = 215,679,578 (thousands) = $215.68B
• N04475 (QBID returns) = 25,430,690

Evidence it distorted nothing but only because calibration ignored it: the populace June release modeled $214.8B QBID against this $31.3B target (relative error 5.86) and the optimizer did not move toward it — the model matched the IRS actual within 0.4% while the target was wrong.

Suspected mechanism: $215.68B / $31.31B ≈ 6.89 — not a units slip (thousands vs dollars would be 1000×). Looks like row/stub misalignment (e.g., a single AGI band's value bound to the us.all row) or a wrong-column bind. The fix should re-verify every HT2 QBID row — qbi_amount and qbi_claims, national and state, all AGI bands — against the source csv, not just the national total.

Downstream: populace#530 flagged this; once corrected, the re-emitted facts give populace a usable ~$215.7B national anchor (and 25.4M returns) consistent with its JCT revenue-loss target.

Start by comparing the HT2 QBID rows in 22in55cmcsv.csv with the emitted us.all and state facts, covering qbi_amount and qbi_claims across every AGI band. Done means every audited value matches the source CSV, including the national QBID amount and returns totals; the issue names no repository files or tests.