QRF donor contains aggregate-scale PUF rows (single-record home_mortgage_interest up to $236B); support_clip donor_realized is vacuous against them

[MaxGhenis]

Found during #511 forensics; latent hazard, not the realized driver of that row (base-O pool is clean of it — receipts below).

What's in the donor

Measured via puf_tax_unit_donor_from_arrays on the pinned artifact the certified O base consumed (base-o summary puf_h5 → policyengine_us_data/storage/puf_2024.h5, sha 7669f5b5…, 211,677 donor rows):

• 3,066 rows carry home_mortgage_interest ≥ $10M — up to $235.97B on a single record (three identical $236.0B rows at weight 0.13 each; $177.0B ×2; $22.0B × w1.08; $3.7B × w11). Weighted, these rows hold $2,947B of phantom mass against $418B for the other ~94k carriers. TY2015 E19200 for ALL returns was $304.5B — single-record values of this scale are not tax data; they look like IRS disclosure-aggregate rows (or their clones) whose amounts were never brought back to per-return scale.
• The same rows poison the structural columns: donor-wide implied first-mortgage rate = 31.9% of balance (34% for 2005-2010 originations, 50% for 2010-2016) vs ~4% reality.

Why nothing burned on O-1

• Weight share ~8e-10 ⇒ expected weighted-bootstrap copies ≈ 0.0002 per fit — the QRF essentially never trains on them (contrast the QRF amount forests lose donor design weights after the n-of-n bootstrap: extreme-tail draws are a seed lottery #481 case at 0.47 expected copies). Base-O pool receipts: max imputed unit home_mortgage_interest $3.09M, zero rows >$10M, pool implied first-mortgage rate 4.00%.
• The pool's structural columns are rebuilt downstream (mortgage_conversion), so the donor's broken balances don't ship.

Why it still deserves a fix

1. support_clip range: donor_realized is vacuous for every column an aggregate-scale row touches — the realized range extends to $236B, so the clip can never catch a runaway draw. That defeats the backstop exactly where it's most needed.
2. It's a seed lottery with a tiny-but-nonzero jackpot (QRF amount forests lose donor design weights after the n-of-n bootstrap: extreme-tail draws are a seed lottery #481 mechanism): one included copy of a $236B row in a leaf is catastrophic for any sparse column these rows carry.
3. Every puf_tax_detail output column shares the donor, so the exposure is not mortgage-specific.

Ask

Either screen aggregate-lineage rows out of the QRF donor path (they're identifiable by scale/weight; the disaggregate_aggregate_records op already knows the RECIDs upstream), or make them sane at ETL (per-return-scale values after disaggregation), and make support_clip robust to them (e.g., clip range from the non-aggregate donor support). Relates #481 (weight-loss lottery), #487 (donor uprating class), #511 (discovery context).

[MaxGhenis]

Claiming, queued immediately behind #515 in the same lane — both touch the puf_tax_detail donor path and its test baselines, so they're staggered to avoid conflicting fixtures. Scope per the issue ask: screen aggregate-lineage rows from the QRF donor (identifiable upstream by RECID via the disaggregation spec) and make support_clip's realized range robust to them.

[MaxGhenis]

Investigation receipts (sol, read-only, on the pinned artifact + worktree) — two corrections to this issue's framing before implementation:

1. The pathology is not aggregate lineage. The artifact's ID encoding does mark a synthetic cohort (3,985 contiguous ids 1,000,000–1,003,984, weight 1,317), but it only partially intersects the mortgage pathology: of the 3,066 rows with grouped home_mortgage_interest ≥ $10M (weight 3,684; $2.947T phantom mass; max $235.97B), 1,823 are synthetic-id and 1,243 carry ordinary ids, while 2,162 synthetic rows are healthy (<$10M). The HDF has no intrinsic lineage attribute (only qbi_simulation_version=1). So the fix must be framed as a structural mortgage-outlier screen, not lineage removal — unioning with the id range would delete 2,162 intended donors to remove only $0.7B more.
2. The support_clip donor_realized leg is moot in production: the manifest declaration is the documented-dead PUF stage manifest declares a support_clip op that no execution path honors (dead donor_realized contract) #482 surface (the generic handler requires explicit numeric bounds and never reads a donor). The live exposure is the QRF fit itself — all 64 target columns carry these rows into the donor/checkpoint, and the cohort uniquely sets 20 upper and 3 lower realized-range endpoints. Row removal at the donor kills both the QRF amount forests lose donor design weights after the n-of-n bootstrap: extreme-tail draws are a seed lottery #481 lottery exposure and the range poisoning that would bite if PUF stage manifest declares a support_clip op that no execution path honors (dead donor_realized contract) #482 ever revives the clip.
3. disaggregate_puf_aggregate_records never runs in the production puf_tax_detail path (both production branches read the HDF and call the donor constructor directly), so upstream RECID knowledge is unavailable there by construction.

Fix shape adopted: whole-row screen in puf_tax_unit_donor_from_arrays — after tax-unit grouping, before the #515 carve (post-carve screening at the same literal misses 49 rows) — with a named threshold constant, the intersection receipts in the comment, and regressions pinning exact row counts. Stacks on the #515 branch (same seam); PR follows once #525 lands.

[MaxGhenis]

Close-out receipts (auto-closed by #527's merge): whole-row structural outlier screen at the puf_tax_detail donor seam — grouped raw home_mortgage_interest ≥ $10M drops the row before the #515 carve (pinned-artifact effect: 3,066 rows / weight 3,684 / $2.947T phantom mass removed; 211,677 → 208,611 donor rows, now asserted by the real-PUF tail-bound test), checkpoint schema at v3 with stale-version rejections pinned over both v1 and v2. Every puf_tax_detail output column stops training on the cohort, which also un-poisons the donor-realized ranges that would back support_clip if #482 revives it (the clip itself stays #482's scope). One sol review round absorbed (schema-rejection parametrization, unscreened tail-bound surface, reserved-name guard).