Bind SOI Table 2.1 mortgage targets to the capped deductible concept (#511 target-side leg) - #517
Merged
Merged
Conversation
…511) SOI Table 2.1 "Home mortgage interest" reports the amount DEDUCTED on Schedule A — after the section 163(h)(3) acquisition-debt caps — while the Build H mapping summed the gross home_mortgage_interest export input. On certified O-1 the gross column ran +29.5% over itemizers ($241.3B vs the $186.3B aged fact) while the engine's capped deductible_mortgage_interest_tax_unit summed $214.2B (+15.0%): the cap haircut alone was a $27.1B pure concept gap in the target column. Remap both Table 2.1 mortgage measures to the capped tax-unit concept. The formula is linear in the first/second_home_mortgage_interest export inputs (balances and origination years only set the deductible share), so the calibration pull-through to the export mass that Build H wanted is preserved, and the carrier set matches the gross indicator exactly on O-1 (a positive-balance unit's deductible share is always positive; 0 divergent units). The residual overshoot is the donor-side E19200 total-interest lineage, tracked as populace#515. Fixes the target-side leg of #511. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ms to O-1 (sol review) Cross-family review findings on the remap commit: 1. Medium/blocking: the corrected mortgage target had no critical-register entry, so a +29.5%-class miss could still certify — the exact adoption- gate gap populace#511 flagged. Register both Table 2.1 mortgage rows by exact name: the amount row at an interim 0.20 (catches the shipped O-1 +29.5% with margin over the +15.0% the capped column measured at O-1 final weights; ratchet to US_CRITICAL_DEDUCTION_MAX_ABS_RELATIVE_ERROR once the populace#515 donor concept carve lands), the returns row at the standard 0.15 (O-1: +2.45%), both with no incumbent-improvement escape, matching their itemized siblings. A builder-side regression pins the exact shipped O-1 diagnostics failing the release gate and the expected post-remap fit passing; the contract-side deduction parametrizations now cover the mortgage row (fixtures updated in both mirrors). 2. Low: the "carriers unchanged" comments claimed a formula invariant; gross and structural interest are independently imputed columns, so carrier equality is a data property. Reworded to the O-1 post-itemizer-mask verification (the only divergent units are non-itemizers). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Round-2 review approved the register commit and flagged three low-severity regression gaps, all taken: 1. Pin allow_incumbent_improvement=False on the amount row inside the 0.20-0.25 band, where the improvement escape would fire if the flag ever regressed to true (+22.5% with a genuinely improving incumbent must still fail; the existing +30% case also trips the 0.25 hard stop and could not tell the difference). 2. Give the returns requirement its own negative and removal regressions (+20% must exceed the 0.15 cap; deleting the row must fail required-presence on its own, not as a rider on the amount row). 3. Disambiguate the builder-side O-1 regression from the missing-row formatter, which also names the row and label: assert the shipped relative_error=0.294986 and the exceeding-0.2 fragment. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
Author
Cross-family review record (sol, gpt-5.6-sol ultra, read-only, committed-diff scoped)Round 1 (remap commit
Round 2 (register commit
Local test state after |
This was referenced Jul 24, 2026
MaxGhenis
added a commit
that referenced
this pull request
Jul 24, 2026
… interim) The puf_tax_detail donor's home_mortgage_interest (and its mirrored first/second structural legs) carry E19200 — Schedule A "Interest paid deduction, Total" — i.e. home-mortgage interest + deductible points + qualified mortgage insurance premiums + investment interest, with the investment leg zeroed. The SOI Table 2.1 concept the calibration binds (and pe-us semantics want) is the home-mortgage-only leg: at TY2015 the total is $304,461,163k vs $283,004,465k mortgage-only, so every donor draw was concept-inflated by ~1.0758. On certified O-1 this was the donor-side ~8% of the mortgage row's +29.5% (see #511 forensics; the target-side leg landed in #517). Scale the three E19200-lineage donor columns (plus the guarded interest_deduction compatibility alias) by US_PUF_E19200_HOME_MORTGAGE_SHARE = 283_004_465 / 304_461_163 once, in puf_tax_unit_donor_from_arrays — before the QRF learns levels and the donor-realized support range — so both QRF paths and support_clip see the carved concept. Balances and origination years are untouched; investment_interest_expense stays all-zero because a uniform carve cannot place the removed mass on the right records (the per-record ETL carve remains open on #515). The #486 support_value_repairs surface was deliberately not used: it is a release-time total pin, not a per-record donor concept transform. Regression proves exactly the four lineage columns scale (symbolically, from the two cited SOI integers) while real_estate_taxes, both balances, both origination years, and the zero investment-interest leaf are unchanged; live donor assertions now encode the share symbolically. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
MaxGhenis
added a commit
that referenced
this pull request
Jul 24, 2026
… interim) (#525) * Carve the PUF donor's E19200 lineage to the mortgage-only concept (#515 interim) The puf_tax_detail donor's home_mortgage_interest (and its mirrored first/second structural legs) carry E19200 — Schedule A "Interest paid deduction, Total" — i.e. home-mortgage interest + deductible points + qualified mortgage insurance premiums + investment interest, with the investment leg zeroed. The SOI Table 2.1 concept the calibration binds (and pe-us semantics want) is the home-mortgage-only leg: at TY2015 the total is $304,461,163k vs $283,004,465k mortgage-only, so every donor draw was concept-inflated by ~1.0758. On certified O-1 this was the donor-side ~8% of the mortgage row's +29.5% (see #511 forensics; the target-side leg landed in #517). Scale the three E19200-lineage donor columns (plus the guarded interest_deduction compatibility alias) by US_PUF_E19200_HOME_MORTGAGE_SHARE = 283_004_465 / 304_461_163 once, in puf_tax_unit_donor_from_arrays — before the QRF learns levels and the donor-realized support range — so both QRF paths and support_clip see the carved concept. Balances and origination years are untouched; investment_interest_expense stays all-zero because a uniform carve cannot place the removed mass on the right records (the per-record ETL carve remains open on #515). The #486 support_value_repairs surface was deliberately not used: it is a release-time total pin, not a per-record donor concept transform. Regression proves exactly the four lineage columns scale (symbolically, from the two cited SOI integers) while real_estate_taxes, both balances, both origination years, and the zero investment-interest leaf are unchanged; live donor assertions now encode the share symbolically. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Invalidate pre-carve QRF checkpoints + close the carve regression gaps (sol round-1) Cross-family review findings on the carve commit, all taken: 1. Medium: the primary-QRF checkpoint stores the donor frame itself and loading validates only schema/digest/kind/role, so a checkpoint initialized pre-carve would keep fitting and drawing uncarved E19200 levels under carved code. Bump PRIMARY_QRF_CHECKPOINT_SCHEMA_VERSION to 2 so every pre-carve checkpoint is rejected and re-initialized through the carved constructor. (The outer builder was already protected by its source fingerprint; the standalone worker API was not.) 2. Medium: the lineage regression failed open for investment_interest_expense -- a zero fixture cannot distinguish scaled from unscaled (0 x share == 0), so appending it to the lineage tuple passed silently. Pin the tuple by exact membership and give the control a nonzero sentinel (the root #515 ETL carve will make the column nonzero, and it must stay uncarved then). 3. Low: document why the carve must stay before _add_predictor_aliases (a future mortgage predictor alias must derive carved; aliases skip already-present columns). 4. Low: document that the raw-audit label for E19200 ("mortgage_interest_paid" in puf_aggregate_records) is Schedule A TOTAL interest, kept stable as an audit-payload key -- raw audit figures must be un-carved before comparison with donor masses. The review also corrected a PR-body claim: the manifest support_clip for this stage is the documented-dead #482 surface, so the carve protects QRF training support (draws come from carved leaves), not an executed clip. The PR description is updated accordingly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Validate target-checkpoint schema + pin the v1 rejection (sol round-2) Round-2 findings on the checkpoint-invalidation commit, both taken: 1. The raw-target checkpoints wrote schema_version since v1 but the loader never validated it, so a v1-marked target riding under a valid v2 root manifest was accepted on worker resume, supervisor resume, prediction loading, and finalization. Add schema_version to the loader's expected-metadata comparison. 2. The schema bump and both rejection paths had no regression: a revert to 1, a dropped comparison, or a permissive migration would have kept every existing chain test green. New test pins a v1 root manifest rejected on load and run, and a v1 target checkpoint rejected under a valid v2 root. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Target-side leg of #511 (mortgage dollars +29.5% on certified O-1), plus the release-gate hardening from cross-family review. SOI Table 2.1 "Home mortgage interest" reports the amount deducted on Schedule A — post the section 163(h)(3) acquisition-debt caps — while the Build H mapping (#299) summed the gross
home_mortgage_interestexport input over itemizers. The target column therefore measured a strictly larger concept than the fact it was pinned to.Two commits:
home_mortgage_interest_amount,home_mortgage_interest_returns) to the engine's cappeddeductible_mortgage_interest_tax_unit, adding the concept to_SOI_ITEMIZED_ONLY_VARIABLESso any future record set carrying these measures stays itemizer-masked regardless of universe. Regression test pins the mapping (verified to fail on the pre-diff code).US_CRITICAL_DEDUCTION_MAX_ABS_RELATIVE_ERRORonce the PUF donor home_mortgage_interest carries the E19200 total-interest concept (+7.6% vs the Table 2.1 mortgage-only leg) #515 donor carve lands and a run holds 0.15), the returns row at the standard 0.15, both with no incumbent-improvement escape, matching their itemized siblings. A builder-side regression pins the exact shipped O-1 diagnostics failing the release gate and the expected post-remap fit passing; the contract-side deduction parametrizations now cover the mortgage row.Receipts (certified O-1,
buildo-sparse-rmloss100-22bd902, exact reproduction of the diagnostics rows)home_mortgage_interest(shipped target column)deductible_mortgage_interest_tax_unit(this PR)first/second_home_mortgage_interestexport inputs — balances/origination years only set the deductible share — so calibration still binds the export mass Build H wanted to pin.diagnose_us_target_supportshows 5,762 carriers, top-1 2.6%, top-5 5.4% (design +84.9% → final +29.5% = broad per-holder level excess).Cross-family review
Two independent sol (gpt-5.6-sol, ultra) passes over the committed diff, read-only, worktree-scoped:
base_variableconsumers (mortgage rows can't take the person-entity age-band path), no missed old-concept consumer repo-wide, pe-us formula acyclic and computable on the target frame (79,729 finite values), regression test fails pre-diff.Scope
fiscal_targets.pymeasure/concept maps + comments;us_critical_targets.pyregister entries; test fixtures in both register mirrors. No build stages, no calibration knobs (Loss shape: flat cap at 1.0 makes past-cap rows free dumping grounds (17 rows pushed out in Build N); bounded-tail experiment + past-cap census diagnostic #492 doctrine).populace-datasuite green;test_us_fiscal_refresh_builder.py+test_us_fiscal_targets.py+test_us_plan.py+test_gates.pygreen (worktree sources via PYTHONPATH); ruff format/check clean.Fixes the target-side leg of #511. Relates #515 (donor concept), #516 (donor integrity hazard found in the same forensics), #299 (Build H mapping this supersedes).
🤖 Generated with Claude Code