Skip to content

Bind SOI Table 2.1 mortgage targets to the capped deductible concept (#511 target-side leg) - #517

Merged
MaxGhenis merged 3 commits into
mainfrom
mortgage-target-deducted-concept
Jul 24, 2026
Merged

Bind SOI Table 2.1 mortgage targets to the capped deductible concept (#511 target-side leg)#517
MaxGhenis merged 3 commits into
mainfrom
mortgage-target-deducted-concept

Conversation

@MaxGhenis

@MaxGhenis MaxGhenis commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

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_interest export input over itemizers. The target column therefore measured a strictly larger concept than the fact it was pinned to.

Two commits:

  1. Remap both Table 2.1 mortgage measures (home_mortgage_interest_amount, home_mortgage_interest_returns) to the engine's capped deductible_mortgage_interest_tax_unit, adding the concept to _SOI_ITEMIZED_ONLY_VARIABLES so 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).
  2. Register the rows as critical (sol review, finding 1 — the adoption-gate gap Mortgage-interest dollars run ~25-30% hot (ht2 +29.5%, JCT expenditure +23.3% on certified O-1) — first-order for deduction-replacement analyses #511 flagged): the amount row at an interim 0.20 with a dated ratchet condition (to US_CRITICAL_DEDUCTION_MAX_ABS_RELATIVE_ERROR once 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)

itemizer-masked mass at final weights value vs $186.31B aged fact
gross home_mortgage_interest (shipped target column) $241.27B +29.5%
capped deductible_mortgage_interest_tax_unit (this PR) $214.20B +15.0%
÷1.0758 donor E19200→A19300 concept scale (#515, donor-side leg) $199.11B +6.9%
  • The cap haircut alone is a $27.1B pure concept gap in the target column; SOI's fact already embeds it.
  • Carrier set: a positive-balance unit's deductible share is always positive; gross and structural columns are independently imputed, so carrier equality is a data property verified on O-1 post-itemizer-mask — identical weighted carrier totals (11,929,444.9), minimum deductible share 0.0835, the only gross-vs-structural divergent units are non-itemizers (returns row +2.45% untouched).
  • Pull-through preserved: the capped formula is linear in the first/second_home_mortgage_interest export inputs — balances/origination years only set the deductible share — so calibration still binds the export mass Build H wanted to pin.
  • Not a carrier/tail defect: diagnose_us_target_support shows 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:

  • Round 1 verdict: request changes — (1) Medium: no critical-register entry, a +30% miss could re-certify (fixed in commit 2); (2) Low: "carriers unchanged" comments overclaimed a data-contingent fact as a formula invariant (reworded in commit 2). Confirmed clean: materializer entity handling, base_variable consumers (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.
  • Independent reproduction in review: gross $241.269B / capped $214.205B / identical return-carrier totals on the certified artifacts.

Scope

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

…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>
MaxGhenis and others added 2 commits July 23, 2026 18:35
…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>
@MaxGhenis

Copy link
Copy Markdown
Contributor Author

Cross-family review record (sol, gpt-5.6-sol ultra, read-only, committed-diff scoped)

Round 1 (remap commit e667648): request changes.

  • Medium/blocking: the corrected mortgage target had no critical-register entry — a +29.5%-class miss could still certify (the adoption-gate gap Mortgage-interest dollars run ~25-30% hot (ht2 +29.5%, JCT expenditure +23.3% on certified O-1) — first-order for deduction-replacement analyses #511 flagged). → Fixed in 67c98ee: both Table 2.1 mortgage rows registered by exact name (amount at interim 0.20 with a dated ratchet to US_CRITICAL_DEDUCTION_MAX_ABS_RELATIVE_ERROR once PUF donor home_mortgage_interest carries the E19200 total-interest concept (+7.6% vs the Table 2.1 mortgage-only leg) #515 lands; returns at 0.15; no incumbent-improvement escape), plus a builder-side regression pinning the exact shipped O-1 diagnostics failing the release gate.
  • Low: "carriers unchanged" comments overclaimed a data-contingent fact as a formula invariant. → Reworded to the O-1 post-itemizer-mask verification.
  • Confirmed clean: materializer entity handling; base_variable consumers (mortgage rows cannot take the person-entity age-band path); no missed old-concept consumer repo-wide; pe-us formula acyclic, computable on the target frame (79,729 finite values); the regression test fails on pre-diff code. Independent reproduction on the certified artifacts: gross $241.269B / capped $214.205B / identical weighted return-carrier totals (11,929,444.9), minimum deductible share 0.0835.

Round 2 (register commit 67c98ee): approve, three low-severity test-hardening suggestions, all taken in b083869:

  1. Pin allow_incumbent_improvement=False inside the 0.20–0.25 band (+22.5% with an improving incumbent must still fail — the +30% case alone also trips the 0.25 hard stop and can't tell the flag regressed).
  2. Returns requirement gets its own negative (+20% > 0.15) and removal (required-presence) regressions.
  3. Builder O-1 regression asserts relative_error=0.294986 + exceeding 0.2 so the missing-row formatter (same row name + label) can't satisfy it.
  • Verified: exact-name-only matching (semantic/pattern selectors can't fire); required-present semantics fail closed on both publisher and builder consumers, with no dense/sparse path where absence certifies (registry compiled once before the split); fixture family counts consistent in both mirrors; the passing arm of the builder regression is non-vacuous.

Local test state after b083869: populace-data suite green (1 unrelated skip), builder release-gate/critical battery green, full test_us_fiscal_refresh_builder.py + test_us_fiscal_targets.py + test_us_plan.py + test_gates.py green, ruff format/check clean.

@MaxGhenis
MaxGhenis merged commit 39ab94a into main Jul 24, 2026
4 checks passed
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>
@MaxGhenis
MaxGhenis deleted the mortgage-target-deducted-concept branch July 24, 2026 11:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant